On Tue, Dec 9, 2008 at 3:50 PM, Bernhard Kuhn <kuhn at l1nuxh4ck3r.de>
wrote:>
> Hi!
>
> Before going into details, i'd like to thank to all swfdec
> developers for their hard work on this nicely architected
> piece of software! Please not that I'm a swfdec noob, so
> please be patient with me :-)
>
Thanks. :)
> However, when trying to play youtube videos, i just got
> a blank screen. I did some debugging (using 0.8.2) and
> figured out that i needed to increase the source priority
> for swfmoz_player_idle_redraw() from SWFDEC_GTK_PRIORITY_REDRAW
> to GDK_PRIORITY_REDRAW (swfmoz_player.c, line 289).
>
As you read the design doc at
http://lists.freedesktop.org/archives/swfdec/2008-March/001306.html
you should already know this, but anyways:
The short version is that user input > redraws from user input >
advancing the flash file > redraws from advancing. Unfortunately, if
advancing takes longer than real time, no redraws ever happen. Oops.
What you've done is increase the priority of redraws from advancing to
be higher than advancing priority. This (as you figured out) a) causes
advancing to not happen in real time anymore and b) causes every frame
to be rendered.
I haven't yet found a satisfactory way to handle this so it doesn't
cause problems. I was thinking about forcing redraws after $TIME, but
that'd only be a stop-gap solution, too.
The Mozilla player implements the same mechanism btw
> Then, video playback was basically working, but *very* slow
> (maybe around two frames per seconds). So i did some profiling
> (with oprofile) and learned that swfdec obviously does a lot
> of un-necessary alpha blending operations that you can just
> omit (i uncommented "cairo_push_group (cr);" in swfdec_movie()
> around line 787 in swfdec_movie_render() and ifdef'ed out
> the corresponding "movie->masked_by" if-clause at the
> end of the function). However video playback was still
> unwatchable slow.
>
Interesting - I wasn't aware that any masking is going on in the
Youtube player. This is likely gonna cause you problems on non-Youtube
files as you disabled masks, but I guess you know that.
> So i did some more profiling and enhanced some functions
> in libpixman (running X-Server on top of fbdev) and replaced
> the i420 to rgb color conversion with a faster hand-written
> function. So i now ended up at about 10 to 15 FPS.
>
Yeah, the I420 => RGB conversion sucks a lot, as it's using liboil,
and that part of liboil doesn't optimized on anything but x86. My end
goal is to be able to create cairo surfaces directly from the I420
data, but that would currently only work on DirectFB, as noone else
seems to export those formats (in particular not Xrender and Cairo).
> All graphical operations required for video playback are
> accountable for about 35% of the CPU usage (see attached
> oprofile break downs for libraries and sysbols). swfdec
> itself takes only 15% CPU cycles for the flash decoding.
> The remaining 50% CPU cycles seem to be overhead caused
> by the system.
>
> I fear, there is not much i could further optimize?! For
> the time being, 10-15 FPS wouldn't be that bad but there is
> another problem: the video plays back in "slow motion" (means:
> all frames are rendered) rather than skipping rendering frames
> now and then.
>
"overhead caused by the system" is a nice way to put glib and libc
time ;)
You should probably set the priority back, so that frames get skipped
properly again and then run another oprofile to get a focus on the
real hotspots which seem to be inside swfdec.
You could also try removing all the debugging stuff by exporting
CFLAGS="-DG_DISABLE_CHECKS -DG_DISABLE_ASSERT -DG_DISABLE_CAST_CHECKS
-DSWFDEC_DISABLE_DEBUG"
or parts of that which gives quite a performance boost at a pretty
high debuggability cost.
If all of that doesn't help, the script engine needs to be made
faster. 0.9 has some speed improvements already, but I've not
benchmarked it enough to know if it's anything major.
But yeah, the script engine is known to be slow as we never optimized
our code for speed, but correctness and easy debugging and refactoring
whenever we figured out it's not correct. So we're missing all the
cool optimizations from Mozilla or Webkit.
> P.S.: i tried out 0.9.2, but this causes some error messages and
doesn't
> actually play videos (i will prepare a separate mail in this topic).
>
We should get the error messages fixed (if we haven't already in git
master).
Not playing video is bad, but excusable as I'm in the process of
rewriting the video playback parts to make them work with RTMP, so
0.9.4 gets all new ones. Nonetheless, 0.9.2 does show video for me,
even though it always omits rendering the first frame.
Cheers,
Benjamin