Thu 24 Jan 2008 09:51:32 AM UTC, comment #11:
can't reproduce with current head.
|
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.
|
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
|
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).
|
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.
|
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...
|
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.
|
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.
|
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 ?
|
Sun 06 May 2007 08:04:47 PM UTC, comment #2:
Should be fixed now, please test.
|
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)
|
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.
|