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

Submitted by:  Sandro Santilli <strk>
Submitted on:  Sun May 6 09:58:56 2007  
Category: videoSeverity: 4 - Important
Release: NoneStatus: Fixed
Privacy: PublicAssigned to: Tomas Groth <tgc>
Open/Closed: Closed

Add a New Comment (Rich MarkupRich Markup):

You are not logged in

Please log in, so followups can be emailed to you.


(Jump to the original submission Jump to the original submission)

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

can't reproduce with current head.

Sandro Santilli <strk>
Project Member
Wed May 16 17:24:34 2007, 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>
Project Member
Wed May 16 07:45:54 2007, comment #9:

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


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>
Project Member
Mon May 7 12:15:50 2007, 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>
Project Member
Mon May 7 09:59:04 2007, comment #7:

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

Sandro Santilli <strk>
Project Member
Mon May 7 09:58:21 2007, 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>
Project Member
Mon May 7 07:28:01 2007, 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>
Project Member
Mon May 7 06:39:51 2007, 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>
Project Member
Mon May 7 06:02:32 2007, comment #3:

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

Sandro Santilli <strk>
Project Member
Sun May 6 20:04:47 2007, comment #2:

Should be fixed now, please test.

Tomas Groth <tgc>In charge of this item.
Sun May 6 11:29:01 2007, 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>
Project Member
Sun May 6 09:58:56 2007, 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>
Project Member


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

Attach File(s):

No files currently attached


Depends on the following items: None found

Items that depend on this one: None found


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

    Do you think this task is very important?
    If so, you can click here to add your encouragement to it.
    This task has 0 encouragements so far.

    Only logged-in users can vote.


    Please enter the title of George Orwell's famous dystopian book (it's a date):



    Follow 7 latest changes.

    Date Changed By Updated Field Previous Value => Replaced By
    Thu Jan 24 09:51:32 2008strkStatusIn Progress=>Fixed
    Mon May 28 18:17:04 2007strkSeverity5 - Blocker=>4 - Important
    Mon May 7 09:59:04 2007strkStatusReady For Test=>In Progress
      Assigned toNone=>tgc
    Sun May 6 20:04:47 2007tgcStatusNone=>Ready For Test
    Sun May 6 09:58:56 2007strkCarbon-Copy-=>Added tgc

    Back to the top

    Powered by Savane 3.1-cleanup1