PDA

View Full Version : Trying some real-world WebM tests


benwaggoner
24th November 2011, 00:20
So, there's been a whole lot of talk about WebM's viability a technology and ecosystem, but I've not seen a good head-to-head comparing the latest vpxenc and x264 versions.

I'm starting off with 720p30 "best" perceptual quality, not worring about encoding time. Getting apples-to-apples is tricky, particularly in rate control.

I'm trying to compare a High 4.0 encode to VP8, at 3Mbps with VBR and other constraints appropriate for Level 4.0. Beyond rate control, I want to allow each codec to use its different bitstream and encoder features as best possible.

I want to see what each can do in terms of quality, and what each requires in terms of decoder performance.

For WebM:
Hawaii_720p30_overlay_stereo.avi -o Hawaii_vp8test.webm --best -w 1280 -h 720 --target-bitrate=3000 -p 2 --end-usage=vbr --buf-sz=8333 --maxsection-pct=833 --buf-initial-sz=750 --buf-optimal-sz=8333 --kf-max-dist=240 --auto-alt-ref=1 --lag-in-frames=25 --tune=ssim --threads=4 --fps=30000/1001 --resize-allowed=1 --verbose --psnr

Which the encoder tells me works out to be:
Encoder parameters:
g_usage = 0
g_threads = 4
g_profile = 0
g_w = 1280
g_h = 720
g_timebase.num = 1
g_timebase.den = 1000
g_error_resilient = 0
g_pass = 0
g_lag_in_frames = 25
rc_dropframe_thresh = 0
rc_resize_allowed = 1
rc_resize_up_thresh = 60
rc_resize_down_thresh = 30
rc_end_usage = 0
rc_target_bitrate = 3000
rc_min_quantizer = 4
rc_max_quantizer = 63
rc_undershoot_pct = 100
rc_overshoot_pct = 100
rc_buf_sz = 8333
rc_buf_initial_sz = 750
rc_buf_optimal_sz = 8333
rc_2pass_vbr_bias_pct = 50
rc_2pass_vbr_minsection_pct = 0
rc_2pass_vbr_maxsection_pct = 833
kf_mode = 1
kf_min_dist = 0
kf_max_dist = 240

And for x264:
--level 4 --preset placebo --tune film --pass 3 --bitrate 3000 --keyint 240 --open-gop --ref 9 --slices 1

Thoughts? WebM's documentation is pretty vague; a long VPx tradition continued :)...

smok3
24th November 2011, 08:17
Html5 video has so many problems, that its just plain boring (that includes slow webm encoding, no full-screen, browsers not being honest about their abilities to play certain format, ect), so what do you plan to achieve?

some older detection test:
http://www.shrani.si/t/1j/S4/48BV1LPK/h264browser.jpg (http://www.shrani.si/f/1j/S4/48BV1LPK/h264browser.png)
(chromium certainly does not play h.264 without additional system decoders.., basically a detection library would have to know every single browser by its name, boring.)

Even if you solve all the mysteries and try to do a webm web video delivery, you will still end-up with some sort of (silly) library (or better: user deciding what would want - switches) that will have to decide what to deliver to each and every browser (flash, html5, quicktime maybe?) - and i'am not even counting different ipods here. So, say the delivery would want to be something else than your usual youtab clone, you are into a huge coding pain (And i'am not saying it is not solvable, i just didn't happen to see any decent solution till now).

CruNcher
24th November 2011, 11:24
Didn't Adobe with a big open mouth announced VP8 support for the Flash Player back then ;)

nm
24th November 2011, 11:28
Html5 video has so many problems, that its just plain boring (that includes slow webm encoding, no full-screen, browsers not being honest about their abilities to play certain format, ect), so what do you plan to achieve?

Ben is doing a pure codec test, ecosystems issues aside, as he said in the very first sentence.

smok3
24th November 2011, 12:37
Didn't Adobe with a big open mouth announced VP8 support for the Flash Player back then ;)
well, that makes even less sense then (if you count out licensing issues), however I'am not claiming anything, just sharing my experience with mentioned format so far, it was a question.