Sat 11 Feb 2012 03:47:08 PM UTC, comment #12:
Issue is in debian packaging, missing optimization in CXXFLAGS.
To reproduce, try disabling optimization DEB_BUILD_OPTIONS=noopt or CXXFLAGS+=-O0.
Forwarded http://bugs.debian.org/659495
|
Sat 11 Feb 2012 03:47:40 AM UTC, comment #11:
d) master built on 20110618 sid .... ok
So problem is on debian side, current build system.
|
Tue 07 Feb 2012 07:51:41 PM UTC, comment #10:
Found out ffmpeg/libav is not the problem cause I reproduced it with gst too.
Built c925c14e on current sid and the issue came out again.
a) c925c14e built on 20110618 sid (from [0]) ok
b) c925c14e built on current sid bad
c) master built on current sid bad
At [1] I've uploaded 2 screencast tests: gnash-test-0.8.10~git20110618-3.ogv was produced with (a), gnash-test-0.8.10.ogv with (c)
[0] http://snapshot.debian.org/package/gnash/0.8.10~git20110618-3
[1] http://www.mediafire.com/file/9c9sab9lbvxqxu3/bug34759.tar.xz
|
Thu 19 Jan 2012 06:34:51 PM UTC, comment #9:
Rather than just claiming this is wrong, I've been testing the adjustable frame rate for over a month, and I've seen zero problems. It's very likely it'll be released the way things work now, as a lower CPU load is desirable. For some SWF files, I've seen a 30% reduction in CPU load. I'd prefer to see a real SWF file that fails to work with master before I get concerned.
Note that the bug report was on choppiness & stuttering, which I can't reproduce with master. If nobody else can reproduce this with master, I'd close this bug report.
|
Thu 19 Jan 2012 06:27:03 PM UTC, comment #8:
There are many things that rely on a delay of 10ms: sockets, timers, netstream, sounds, netconnection (including all remoting), and all sub-frame-resolution events, to name just a few.
Setting it to anything else is wrong, and can cause all sorts of unexpected regressions in movies that you won't test.
|
Thu 19 Jan 2012 05:47:20 PM UTC, comment #7:
I see no difference between a Gnash built from c925c14e and master as far as video performance. My testing was done on Fedora, and I also used Gstreamer (which is the default for all packages). Note that c925c14e still has the bug were the video is not the correct size. If there is a problem with ffmpeg versions, that's a Debian issue more than a Gnash one.
|
Thu 19 Jan 2012 02:58:13 PM UTC, comment #6:
> I haven't seen that much choppiness nor stuttering myself when viewing youtube
Have you compared it with c925c14e?
I only compared released debian versions as said in comment #1. Someone suggested that what could make the difference is that c925c14e was built against pre-fork ffmpeg and the latest def15623 against libav.
|
Wed 18 Jan 2012 01:01:22 AM UTC, comment #5:
The time interval set to 10ms is a cpu hog, and only useful for video. For animations, it can be a performance killer, especially on lower end hardware. I haven't seen that much choppiness nor stuttering myself when viewing youtube, so prefer the interval the way it is now. That said, the interval could probably be adjusted differently than using the SWF frame rate.
|
Tue 17 Jan 2012 09:22:54 AM UTC, comment #4:
There's code that relies on the heartbeat being 10ms.
The code pushing audio samples to the audio card output buffer is one such case. It is in NetStream_as.cpp.
Long time ago, internal code requested their own interval value when registering as callbacks. Then Benjamin (IIRC) dropped that argument because it was unused at that time.
Actually, 10ms revealed as being a perfect time for pushing 44100hz samples into the sink, somewhat confirming the 10ms delay requirement.
It would take changing the interface to register internal timers and threat them accordingly from movie_root. Then NetStream should tweak the timer value based on streaming media frame rate (may be higher or lower than the SWF rate). The topmost hearbeat should then of course take into account the changes which may occur during playback as an 1FPS SWF movie may load a 20FPS video stream after some time thus requiring higher beat.
I hope I didn't overload you with informations, but this seems to be the best I can do to help with the time I have available at the moment.
|
Sun 15 Jan 2012 07:28:58 PM UTC, comment #3:
Just as a test, try setting "set delay 10" in your ~/.gnashrc file, or use -d to specify a different time interval. Currently the time interval is calculated from the frame rate, which for youtube works out to about a 33ms time interval. The default used to be 10ms. The longer the time interval, the lower the cpu load, so there is a trade-off...
|
Sat 14 Jan 2012 04:18:33 PM UTC, comment #2:
Both versions play without pauses. Difference is c925c14e plays more flawlessly than master. I'm sure there is a better way to describe that than using choppyness/stuttering. Try to also build c925c14e and compare.
|
Fri 13 Jan 2012 05:48:44 PM UTC, comment #1:
Is this still a problem for you ? Using current master (#8efba96), I get smooth video performance with youtube, and the CPU load is mostly under 50%. I don't even see any buffering problems.
|
Sun 06 Nov 2011 08:12:36 PM UTC, original submission:
Current master and 0.8.10~git20111001-1 (def15623), compared to 0.8.10~git20110618-3 (c925c14e) version, show choppyness/stuttering by playing youtube movies.
|