bugGnash - The GNU Flash player - Bugs: bug #19811, High CPU usage at end of YouTube...

 
 

bug #19811: High CPU usage at end of YouTube video

Submitter:  Sandro Santilli <strk>
Submitted:  Sun 06 May 2007 09:58:56 AM UTC
   
 
Category:  video Severity:  4 - Important
Release:  None Status:  Fixed
Privacy:  Public Assigned to:  tgc
Open/Closed:  Closed
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Thu 24 Jan 2008 09:51:32 AM UTC, comment #11: 

can't reproduce with current head.

Sandro Santilli <strk>
Group Member
Wed 16 May 2007 05:24:34 PM UTC, comment #10: 

News: with current CVS reproducing the bug is a bit harder, a single full play won't suffice. After clicking the "watch again"
it still happens.

Sandro Santilli <strk>
Group Member
Wed 16 May 2007 07:45:54 AM UTC, comment #9: 

Instructions on how to setup a full-online configuration can be found here:

http://www.gnashdev.org/wiki/index.php/YouTube#Full_off-line_testing

The problem turns out the be only with gstreamer-0.10.6 or 0.10.7, whichs is what Ubuntu Dapper ships.

In particular the problem is that setting the pipeline to NULL
state doesn't interrupt handsoff signals.
With current CVS this can be verified by running gnash with the -v switch and getting these messages multiple times instead of only once:

Playback paused
Load completed, setting playStop status and shutting down pipeline

Sandro Santilli <strk>
Group Member
Mon 07 May 2007 12:15:50 PM UTC, comment #8: 

More info: I found it harder to reproduce the problem while downloading the FLV from youtube, but I can reproduce it consistently downloading the FLV from localhost httpd, with both fast and reduced-bandwidth load.

The 100% CPU is with both -r2 and -r1 (only audio or only video).

Sandro Santilli <strk>
Group Member
Mon 07 May 2007 09:59:04 AM UTC, comment #7: 

Also, notifications stop by clicking the "watch again", so the CPU hog and notifications might be related.

Sandro Santilli <strk>
Group Member
Mon 07 May 2007 09:58:21 AM UTC, comment #6: 

Just found out that clicking on the 'watch again' buttun, which calls a seek(), takes CPU down to acceptable usage.
This is despite the fact that seeking doesn't work, and video
is not watched again...

Sandro Santilli <strk>
Group Member
Mon 07 May 2007 07:28:01 AM UTC, comment #5: 

I committed a patch making use of thread compile-time selectable.
The patch sets the default to NOT use thread (in LoadThread class).
With this setup I can still see the CPU @ 100% bug.

Note that CPU is at 100% during initial load, which is a performance problem in curl_adapter, gets down during playback
and gets back high at the end of the video, which is what
this bug is about.

By compiling-out threads we can see this is not locking-related.

Sandro Santilli <strk>
Group Member
Mon 07 May 2007 06:39:51 AM UTC, comment #4: 

Note that these notifications keep being sent:

Processing 2 status notifications
 Invoking onStatus(NetStream.Play.Stop)
 Invoking onStatus(NetStream.Buffer.Empty)

And I don't seen NetConnection::eof() even called.

Sandro Santilli <strk>
Group Member
Mon 07 May 2007 06:02:32 AM UTC, comment #3: 

Not fixed. Same behaviour here. Shall we try NOT using the mutex
if NO thread is alive ?

Sandro Santilli <strk>
Group Member
Sun 06 May 2007 08:04:47 PM UTC, comment #2: 

Should be fixed now, please test.

Tomas Groth <tgc>
Sun 06 May 2007 11:29:01 AM UTC, comment #1: 

Trying to automate testing for profiling purpose I found that eventually a segfault is encountered.
This is using -t (timeout) switch to gnash.
Playing (locally) the RMS file reduced to 512k, and using
-t120 (works) and -t300 (segfaults)

Sandro Santilli <strk>
Group Member
Sun 06 May 2007 09:58:56 AM UTC, original submission:  

To reproduce you can setup the simplest posible layout, which is
full offline loading with a very small FLV as input.
See http://www.gnashdev.org/wiki/index.php/YouTube#Full_off-line_testing
for instructions about how to do so.

You will note that at the very end of the video playback (when the "play again" widget is shown) CPU usage gets 100% and keeps in that  position for a long time. I think eventually it will freeze or crash, but I haven't tested that.

Sandro Santilli <strk>
Group Member

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by tgc (Posted a comment)
  • -email is unavailable- added by strk (Submitted the item)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only logged-in users can vote.

     

    Follow 7 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2008-01-24 strk StatusIn Progress Fixed
        Open/ClosedOpen Closed
    2007-05-28 strk Severity5 - Blocker 4 - Important
    2007-05-07 strk StatusReady For Test In Progress
        Assigned toNone tgc
    2007-05-06 tgc StatusNone Ready For Test
    2007-05-06 strk Carbon-Copy- Added tgc

    Back to the top

    Powered by Savane 3.13-3230.
    Corresponding source code