Comment by gmartres | Hacker News Reader

Comment by gmartres | Hacker News Reader

From beamrvideo.com, Clip1_mini.mov contains:

  videomini ver. 90.15 options: cabac=1 ref=3 deblock=1:0:0 analyse=0x3:0x113 me=umh subme=8 psy=1 psy_rd=1.00:0.00 mixed_ref=1 me_range=16 chroma_me=1 trellis=1 8x8dct=1 cqm=0 deadzone=21,11 fast_pskip=1 chroma_qp_offset=-2 threads=1 sliced_threads=0 nr=0 decimate=1 interlaced=0 bluray_compat=0 constrained_intra=0 bframes=0 weightp=2 keyint=250 keyint_min=25 scenecut=40 intra_refresh=0 rc_lookahead=40 rc=crf mbtree=1 crf=23.0 qcomp=0.60 qpmin=10 qpmax=51 qpstep=4 ip_ratio=1.41 aq=1:1.00

And Clip2_mini.mov contains:

  videomini ver. 89.15 options: cabac=1 ref=3 deblock=1:0:0 analyse=0x3:0x113 me=umh subme=8 psy=0 mixed_ref=1 me_range=16 chroma_me=1 trellis=1 8x8dct=1 cqm=0 deadzone=21,11 fast_pskip=1 chroma_qp_offset=0 threads=1 sliced_threads=0 nr=0 decimate=1 interlaced=0 bluray_compat=0 constrained_intra=0 bframes=0 weightp=2 keyint=250 keyint_min=25 scenecut=40 intra_refresh=0 rc=crf mbtree=0 crf=23.0 qcomp=0.60 qpmin=10 qpmax=51 qpstep=4 ip_ratio=1.40 aq=1:1.00

For comparaison, here's what a clip encoded with x264 contains: x264 - core 125 r2200 999b753 - H.264/MPEG-4 AVC codec - Copyleft 2003-2012 - http://www.videolan.org/x264.html - options: cabac=1 ref=1 deblock=1:0:0 analyse=0x1:0x111 me=hex subme=5 psy=1 psy_rd=1.00:0.00 mixed_ref=0 me_range=16 chroma_me=1 trellis=0 8x8dct=0 cqm=0 deadzone=21,11 fast_pskip=1 chroma_qp_offset=0 threads=6 lookahead_threads=1 sliced_threads=0 nr=0 decimate=1 interlaced=0 bluray_compat=0 constrained_intra=0 bframes=0 weightp=2 keyint=240 keyint_min=23 scenecut=40 intra_refresh=0 rc_lookahead=40 rc=2pass mbtree=1 bitrate=373 ratetol=1.0 qcomp=0.60 qpmin=10 qpmax=51 qpstep=4 cplxblur=20.0 qblur=0.5 ip_ratio=1.40 aq=1:1.00

So their encoder is based on x264 (without credit). The settings are slightly different between the clips, so maybe they have some magic thing to detect which settings to use. In any case, it'd be interesting to reencode the original clip using plain x264, once using the same options they used and once using some sane x264 preset.

>In any case, it'd be interesting to reencode the original clip using plain x264, once using the same options they used and once using some sane x264 preset.

I'm up for that. It'll take a while to download all the source videos, but I'll report back with results and videos when I'm done.

I already did a test encode with x264 --preset veryslow --tune film --level 4.0 --crf 21 on the Bourne Identity clip, and the result is within the same realm than the Beamr video with ~58% the filesize. Which is not surprising at all, considering Beamr's settings.

EDIT: Testing with nearly identical settings (x264 --bframes 0 -- subme 8 --no-psy --no-mbtree) using the latest x264 gives me about 40% the bitrate of the Beamr example for the Bourne Identity clip, which unsurprisingly looks notably worse. So maybe Beamr's "magical" encoding technology is all about fiddling with x264's CRF to make it double the bitrate at a given value compared to vanilla x264?

Justin from Zencoder here... I've been doing a bit of similar testing and seeing similar results. So they're obviously controlling the settings per frame (or per segment) during the encode, meaning the values in that encoder line are not very useful in analyzing what they're doing.

I'm definitely seeing a loss in quality on the "mini" encodes relative to the source -- mostly in loss of grain, and fine details (in hair, etc).

However, if they're analyzing the motion within the video and using perceptual algorithms to determine what the focal points are, etc. then it's totally fair to throw away details in sections that are peripheral, and likewise getting rid of grain in a blurred-out portion of the screen that's panning makes sense if your eye wouldn't perceive that anyway. This seems to be a much more aggressive version of x264's "psy" optimizations, essentially.

So the resulting video might look very similar in quality to someone watching the movie, but not to someone analyzing the frames and details. There's a hard line to draw on how that's marketed -- it's not actually "without losing quality", but it might be "without looking worse"?

Based on the comparing I've done on the second clip so far, they seem to be doing absolutely nothing special - at approximately the same bitrate and settings, the videos are practically identical quality-wise (in fact, the most recent x264 seems to fare a small bit better).

I'm going to do two sets of comparisons for each clip: Beamr's video compared to x264 with similar settings and bitrate, and then Beamr-like settings and high quality settings compared at a much more realistic bitrate that you would actually see in use in digital video on the internet.

I just came back to add that, encoding 2-pass to the same bitrate that theirs results at, I have a very hard time telling the difference. I look forward to your comparison sets.

I've finished my comparisons now. HN submission here: http://news.ycombinator.com/item?id=5289532

> (without credit)

Just to note, no credit is necessarily required. x264 is now dual-licensed under GPL2 + commercial license. If they bought a commercial license, there's nothing illegal or wrong in what they do.

>If they bought a commercial license, there's nothing illegal or wrong in what they do.

Looking into it, they seem to have actually done that. ICVT, the company behind Beamr, can be found on the list of x264 commercial adopters[1].

Doesn't change the fact that they're major Snake Oil Salesmen, though. Also, the claims on their technology page[2] are still incredibly dubious.

[1] http://x264licensing.com/adopters

[2] http://beamrvideo.com/main/technology

There would be nothing wrong apart from claiming technology as their own if they did this under the GPL2+ as well.

Reply on news.ycombinator.com