keeleysam / tenfourfox

Automatically exported from code.google.com/p/tenfourfox
0 stars 0 forks source link

Reduce WebM filtering for performance #55

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago
Oh, Mozilla, I'd send you this code, but you probably don't care and wish I'd 
go away. But I might anyway, just so you can ignore it and I can tell you I 
told you so. You don't care about the little guys anymore.

Anyway, PoLiYa on the blog made the most excellent suggestion that deblocking 
should be configurable. Now that I know the VP8 SDK allows dynamic 
reconfiguration of the codec, this is totally doable.

http://www.webmproject.org/tools/vp8-sdk/example__postproc.html
http://src.chromium.org/svn/trunk/deps/third_party/libvpx/include/vpx/vp8.h

We're gonna sneak a pref into /content/media/webm/nsWebMReader.cpp 
"media.webm.disable_deblocking" which will be FALSE for 7450 and G5 (and the 
default), and TRUE for G3 and 7400. And, what the hell, I'll run off a diff for 
Mozilla when we're done.

Original issue reported on code.google.com by classi...@floodgap.com on 16 Apr 2011 at 11:00

GoogleCodeExporter commented 9 years ago
Bad news, after investigating flags it turns out that Mozilla runs libvpx 
without postproc, so deblocking never actually gets done. This *is* without it.

We should do a pref to enable/disable the loop filter, but we will first back 
out the changes, and disable postproc in the config.h files *just in case* 
there is a performance impact.

Original comment by classi...@floodgap.com on 17 Apr 2011 at 3:06

GoogleCodeExporter commented 9 years ago
We can do that by hooking into the codec config control. 0.9.6 mentions 
something about disabling the loop filter, but I'd prefer not to update to 
0.9.6 just yet.

Original comment by classi...@floodgap.com on 17 Apr 2011 at 3:08

GoogleCodeExporter commented 9 years ago
Postproc is backed out.

Deferred to 4.0.3.

Original comment by classi...@floodgap.com on 27 Apr 2011 at 9:13

GoogleCodeExporter commented 9 years ago
Setting MAX_LOOP_FILTER down to 1 from 63 made little or no difference and 
seems difficult to implement. This might be helpful on marginal cases but we 
should try for more productive changes first.

Original comment by classi...@floodgap.com on 1 Jun 2011 at 1:02

GoogleCodeExporter commented 9 years ago
I take that back. 1 did improve complex video, but unacceptably blocky on some 
images. 8 seems a good compromise and we'll ship that in the beta.

Original comment by classi...@floodgap.com on 2 Jun 2011 at 6:02

GoogleCodeExporter commented 9 years ago
Seems fine. Closing.

Original comment by classi...@floodgap.com on 10 Jun 2011 at 4:28