x266 VVC Encoder

[Z2697]

What does "Average Speedup 0.01x" mean ? I have a suspicion but cannot be sure.

I think it means the x266 is 100x slower than x265, or x266 is 100x faster than VTM. (x265 is also ~100x faster than HM)
Which one is you suspect?

[birdie]

Apparently they're still working on it: https://www.youtube.com/watch?v=GE4xMNnMEyE

It's alive!!

Why is it a very low bitrate 720p stream, I've no idea.

What does "Average Speedup 0.01x" mean ? I have a suspicion but cannot be sure.

It means it's 100 times slower. One of the slides says:

"Additional ASM and performance Optimization" (sic)

Looks like they started relatively late, maybe a year ago. Of course they couldn't show us anything at the beginning of 2024.

[birdie]

The most pertinent details from the clip above.

I wonder how x266 compares to svt-av1-psy/libaom and VVenc.

Comparisons were made at a very high bitrate, so there's hope that x266 won't blur everything like VVEnc/libaom do by default.

[rwill]

I think it means the x266 is 100x slower than x265, or x266 is 100x faster than VTM. (x265 is also ~100x faster than HM)
Which one is you suspect?

I suspect its ~100x slower than x265.

And one thing I tried to reproduce was the x265 Netflix-Tango YUV PSNR of 41.7db but whatever I do at veryslow or placebo I fail. Their x265 must have much better performance than the binary I got.

[Z2697]

If that's true why they call 100x slower 0.01x speedup LOL.
I don't think it's really 100x slower. Even VVenC is not 100x slower than x265.
(We can throw reference encoder out of the window)

There are ASM optimizations already in x266, according to the "enabled features" slide in that video.

[ksec]

The most pertinent details from the clip above.

I wonder how x266 compares to svt-av1-psy/libaom and VVenc.

Comparisons were made at a very high bitrate, so there's hope that x266 won't blur everything like VVEnc/libaom do by default.

Well at least the Samsung clip is 4.8Mbps for 4K 60Fps. I think that is pretty low bitrate if you ask me. Youtube serve 1080P 50fps with VP9 at 4Mbps.

Would be interesting to see how it compares, but AV1 is now extremely weak tuned, while x266 doesn't even have all of its features implemented yet.

[GeoffreyA]

If that's true why they call 100x slower 0.01x speedup LOL.
I don't think it's really 100x slower. Even VVenC is not 100x slower than x265.
(We can throw reference encoder out of the window)

There are ASM optimizations already in x266, according to the "enabled features" slide in that video.

It looks like it's relative to x265. So that could be a trick way of obscuring the number. Surprising for it to be 100x slower, but perhaps they're using preset placebo or something.

VVenC was up and running and in the public's hands almost five years ago. x266 really has its work cut out for it.

[Z2697]

I'm being (maybe too) optimistic ;)

[GeoffreyA]

I'm being (maybe too) optimistic ;)

Dark Shikari and akupenguin are sorely needed to come back and do some codec magic in 2025 :)

[FranceBB]

Dark Shikari and akupenguin are sorely needed to come back and do some codec magic in 2025 :)

It would be a dream, but unfortunately I don't really see Jason ever making a comeback... :(
There's been a lot going on in his personal life and he even changed name (I won't comment further on this out of respect). I don't personally know him, but there are still people here who have been knowing him for a long time and they hinted at this a while ago.

But... you know, although highly unlikely, I'd say "never say never"... We've seen Avisynth legends like Didee and Dogway making a comeback, so who knows...

Regardless, he will forever be considered a legend on Doom9 for everything he has done (and not only around here but pretty much everywhere on the web).

[benwaggoner]

I suspect its ~100x slower than x265.

And one thing I tried to reproduce was the x265 Netflix-Tango YUV PSNR of 41.7db but whatever I do at veryslow or placebo I fail. Their x265 must have much better performance than the binary I got.
If they're testing PSNR, they might have used --tune psnr?

[benwaggoner]

Dark Shikari and akupenguin are sorely needed to come back and do some codec magic in 2025 :)
It would be nice, but they didn't have much of a role in x265, or anything with x264 for more than a decade.

Lots of good stuff here: https://web.archive.org/web/20121221131527/http://x264dev.multimedia.cx/

[rwill]

If they're testing PSNR, they might have used --tune psnr?

This is very likely, but so have I.

The most simple command would be:

./x265 --input Netflix_Tango_4096x2160_60fps_10bit_420.y4m --profile main10 --tune psnr --bitrate 10900 --pass 1 -o trash.265 --preset veryslow --psnr -I 300
./x265 --input Netflix_Tango_4096x2160_60fps_10bit_420.y4m --profile main10 --tune psnr --bitrate 10900 --pass 2 -o trash.265 --preset veryslow --psnr -I 300


For this I get a Global YUV PSNR of 40.8045db.

I got the Netflix_Tango sequence from Derf's collection.

[Z2697]

.5 more to go
had to use pbratio=1.4 to get into < 10900 kbps bitrate
with default pbratio the bitrate is 11197.41 kbps psnr is 41.263
I use the same source downloaded from Derf's collection, I just encoded it with x264 lossless fastdecode (it really get slow to decode without it)

>ffmpeg -v 0 -i X:\Netflix_Tango_4096x2160_60fps_10bit_420.lossless.mkv -f yuv4mpegpipe -strict -1 - | x265 --input - --y4m^
--profile main10 --qp 29 --tune psnr --psnr -oNUL -I300 --rdoq 2 -b3 --asm avx512 --ref 6 --tu-intra-depth 2 --tu-inter-depth 2^
--limit-refs 0 --rd 6 --no-early-skip --no-strong-intra-smoothing --subme 7 --max-merge 5 --pbratio 1.4

y4m [info]: 4096x2160 fps 60/1 i420p10 sar 1:1 unknown frame count
raw [info]: output file: NUL
x265 [info]: HEVC encoder version 4.1+96-5de5f564
x265 [info]: build info [Windows][clang 19.1.7][64 bit] 10bit
x265 [info]: using cpu capabilities: MMX2 SSE2Fast LZCNT SSSE3 SSE4.2 AVX FMA3 BMI2 AVX2 AVX512
x265 [info]: Main 10 profile, Level-6 (Main tier)
x265 [info]: Thread pool created using 32 threads
x265 [info]: Slices : 1
x265 [info]: frame threads / pool features : 6 / wpp(34 rows)
x265 [info]: Coding QT: max CU size, min CU size : 64 / 8
x265 [info]: Residual QT: max TU size, max depth : 32 / 2 inter / 2 intra
x265 [info]: ME / range / subpel / merge : hex / 57 / 7 / 5
x265 [info]: Keyframe min / max / scenecut / bias : 30 / 300 / 40 / 5.00
x265 [info]: Lookahead / bframes / badapt : 20 / 3 / 2
x265 [info]: b-pyramid / weightp / weightb : 1 / 1 / 0
x265 [info]: References / ref-limit cu / depth : 6 / off / off
x265 [info]: Rate Control : CQP-29
x265 [info]: tools: rd=6 rdoq=2 rskip mode=1 signhide tmvp b-intra lslices=8
x265 [info]: tools: deblock sao dhdr10-info
x265 [info]: frame I: 1, Avg QP:26.00 kb/s: 57963.36 PSNR Mean: Y:40.464 U:48.380 V:46.834
x265 [info]: frame P: 74, Avg QP:29.00 kb/s: 25317.55 PSNR Mean: Y:39.710 U:47.284 V:45.060
x265 [info]: frame B: 219, Avg QP:31.33 kb/s: 5735.02 PSNR Mean: Y:39.524 U:47.394 V:45.138
x265 [info]: Weighted P-Frames: Y:0.0% UV:0.0%

encoded 294 frames in 61.10s (4.81 fps), 10841.60 kb/s, Avg QP:30.73, Global PSNR: 41.242

[rwill]

the bitrate is 11197.41 kbps psnr is 41.263 [...]

[some other run:]

encoded 294 frames in 61.10s (4.81 fps), 10841.60 kb/s, Avg QP:30.73, Global PSNR: 41.242


Please note that what x265 reports as the Global PSNR is not what one expects when wanting the Global YUV PSNR, that encoders like VVEnc or such report. I have not searched really hard but never have seen Multicorewares way of calculating it somewhere else - whatever it is, it not the Global YUV PSNR and results in higher values most of the time.

You should use a third party tool to calculate the true Global YUV PSNR to be able to compare it to other encoders.

[Z2697]

double globalPsnr = (m_analyzeAll[layer].m_psnrSumY * 6 + m_analyzeAll[layer].m_psnrSumU + m_analyzeAll[layer].m_psnrSumV) / (8 * m_analyzeAll[layer].m_numPics);


I thought you are using x265's PSNR calculation because you used --psnr

in FFmpeg the plane weights are calculated by their resolution:

sum = 0;
for (j = 0; j < s->nb_components; j++)
sum += s->planeheight[j] * s->planewidth[j];
average_max = 0;
for (j = 0; j < s->nb_components; j++) {
s->planeweight[j] = (double) s->planeheight[j] * s->planewidth[j] / sum;
average_max += s->max[j] * s->planeweight[j];
}


Which is a bit weird, the chroma planes (which have higher PSNR) have higher weights in FFmpeg, but the final average PSNR is lower... maybe it's because FFmpeg is averaging the MSE then calculate PSNR at the end, rahter than averaging PSNR? I have no idea.


av_log(ctx, AV_LOG_INFO, "PSNR%s average:%f min:%f max:%f\n",
buf,
get_psnr(s->mse, s->nb_frames, s->average_max),
get_psnr(s->max_mse, 1, s->average_max),
get_psnr(s->min_mse, 1, s->average_max));
}


Anyway, if they are comparing two of their encoders, I assume that doesn't hurt. x266 should have the same way of PSNR calculation as x265.

[ksec]

It would be a dream, but unfortunately I don't really see Jason ever making a comeback... :(
There's been a lot going on in his personal life and he even changed name (I won't comment further on this out of respect). I don't personally know him, but there are still people here who have been knowing him for a long time and they hinted at this a while ago.

But... you know, although highly unlikely, I'd say "never say never"... We've seen Avisynth legends like Didee and Dogway making a comeback, so who knows...

Regardless, he will forever be considered a legend on Doom9 for everything he has done (and not only around here but pretty much everywhere on the web).

I know money isn't everything and I am not a millionaire that could bootstrap the whole thing. But I could easily see myself donating a thousand dollar just to see this dream come true. I am sure if we get enough company and people together the sum of money could be something.

I really want another encoder that takes the no nonsense approach. As a matter of fact I wish they could be back to work on x264 in a way that breaks H.264 limitation but in a completely patent free way.

[filler56789]

<!-- snip -->

Well, you really should not expect Dark Shikari to return if you insist on being a proud transphobe...

I know this is "off-topic", but so are your misplaced ""thoughts"" or ""opinions"".

[/END_OF_DISCUSSION]

[FranceBB]

I know money isn't everything and I am not a millionaire that could bootstrap the whole thing. But I could easily see myself donating a thousand dollar just to see this dream come true. I am sure if we get enough company and people together the sum of money could be something.

Speaking of money, I'm a technical guy, not a financial guy, so I don't know what the agreement between Comcast / Sky and Multicoreware is, but all I know is that we're sponsoring the development and I'm very proud that the company I work for is using some of the revenues to finance open source projects. :)

[kurkosdr]

<!-- snip -->

I know this is "off-topic", but so are your misplaced ""thoughts"" or ""opinions"".

[/END_OF_DISCUSSION]
And what you don't understand is that you can't drop in the middle of a conversation, accuse someone else of being <whatever>, provide zero context, and then unilaterally end the discussion, not without coming off as a complete and utter moron.

And yes, I know my post is also insulting, but since this is apparently allowed, I might as well join the fun.

[kurkosdr]

Dark Shikari and akupenguin are sorely needed to come back and do some codec magic in 2025 :)
What are the chances even fairly techy people owning VVC-capable hardware? Why would they spend effort improving an encoder for a standard they probably can't play? x264 benefited from all that H.264 decoding hardware in GPUs, as well as H.264 being the chosen format for HD resolutions in most consumer electronics. This meant volunteers had an incentive to improve x264 to see better pictures on their hardware. But for UHD resolutions (and HDR content), this spot is now occupied by HEVC and to a degree AV1.

In this sense, it's good that x266 is commercially sponsored, since we may eventually see it happening. Who knows, it might prove useful in the future.

[Z2697]

What are the chances even fairly techy people owning VVC-capable hardware? Why would they spend effort improving an encoder for a standard they probably can't play? x264 benefited from all that H.264 decoding hardware in GPUs, as well as H.264 being the chosen format for HD resolutions in most consumer electronics. This meant volunteers had an incentive to improve x264 to see better pictures on their hardware. But for UHD resolutions (and HDR content), this spot is now occupied by HEVC and to a degree AV1.

In this sense, it's good that x266 is commercially sponsored, since we may eventually see it happening. Who knows, it might prove useful in the future.

You knew software decoders do exist, right?
That being said, having HW decoder is certainly better.

[kurkosdr]

You knew software decoders do exist, right?
That being said, having HW decoder is certainly better.
Hmm... Can VVC be decoded in software without having the latest and greatest CPU? And with what software?

[FranceBB]

There are two main software decoders: VVDec and Libav.
The latter was created later compared to VVDec and was originally written in plain C, but then it got manually written intrinsics in assembly and it has been closing the gap over the last year.
In particular, the open source decoder inside libav was written by Nou Mi and Frank Plowman. I was able to chat to them both but in particular Frank recently held a workshop at Sky in which he detailed what led to the creation of the decoder and how to detect issues with it.

https://i.imgur.com/223V2te.png


The reason why this is particularly important is that when they introduced the decoder, it ended up spreading everywhere, from Avisynth and VapourSynth indexers like LWLibavVideoSource() and FFVideoSource(), to players like MPV and VLC and of course FFMpeg itself which is used pretty much universally. It was a major thing. When it was first released, it surely struggled to decode videos on most CPUs, but then again, it was just plain C without any assembly, while nowadays the picture is very different.

Here's the decoding benchmark (and remember that you only really need the fps to match the one of the content when you're actually watching something and not indexing to re-encode):


Test 1:
Chicago Fire FULL HD H266 Main10 12Mbits 25p YV12 BT709 SDR 10bit AC3 2ch 48000Hz.ts

120 fps
Intel Xeon E5-2637 v4 3.50GHz dual socket 8c/16th, 64GB RAM

111 fps
Intel i7 5930K 3.50GHz single socket 6c/12th 32GB RAM


Test 2:
Judas and the Black Messiah SD H266 Main10 3Mbits 25p YV12 BT601 SDR 10bit AC3 2ch 48000Hz.ts

620 fps
Intel Xeon E5-2637 v4 3.50GHz dual socket 8c/16th, 64GB RAM

631 fps
Intel i7 5930K 3.50GHz single socket 6c/12th 32GB RAM

Test 3:
The Creator FULL HD H266 Main10 12Mbits 25p YV12 BT709 SDR 10bit AC3 2ch 48000Hz.ts

121 fps
Intel Xeon E5-2637 v4 3.50GHz dual socket 8c/16th, 64GB RAM

116 fps
Intel i7 5930K 3.50GHz single socket 6c/12th 32GB RAM


If you need the samples let me know and I'll send them over (trimmed down obviously, not the whole thing). To test it yourself you just need to download the latest version of MPV from master ;)
I'll generate some UHD files too to see how well it copes, but the future definitely looks exciting, software wise. :)

[Z2697]

Frank recently held a workshop at Sky in which he detailed what led to the creation of the decoder and how to detect issues with it.


I'm very curious about the details here, there's patchset for libvvdec (and libvvenc) inclusion as 3rd party components before the native vvc decoder, at least what we can see in public ffvvc fork.
Eventually libvvenc did get into official FFmpeg, but not libvvdec.

vvdec is still faster than libav vvcdec, by 1.37x (1T) or more depending on the requested threads, on Zen 5.
I think FFmpeg has a "tradition" of implementing MPEG decoders natively AND not support 3rd party ones?
(while VP series have libvpx and libdav1d as well as native VP9 and AV1(HW decoding only))

Is it OK for you to share some stories?

[GeoffreyA]

I'm very curious about the details here, there's patchset for libvvdec (and libvvenc) inclusion as 3rd party components before the native vvc decoder, at least what we can see in public ffvvc fork.
Eventually libvvenc did get into official FFmpeg, but not libvvdec.

vvdec is still faster than libav vvcdec, by 1.37x (1T) or more depending on the requested threads, on Zen 5.
I think FFmpeg has a "tradition" of implementing MPEG decoders natively AND not support 3rd party ones?
(while VP series have libvpx and libdav1d as well as native VP9 and AV1(HW decoding only))

Is it OK for you to share some stories?

There was some mild controversy a few years back about using vvdec. Nuo Mi argued that it would speed up work getting the infrastructure ready for the native decoder, which was already being developed at that time.

[GeoffreyA]

But... you know, although highly unlikely, I'd say "never say never"... We've seen Avisynth legends like Didee and Dogway making a comeback, so who knows...

Regardless, he will forever be considered a legend on Doom9 for everything he has done (and not only around here but pretty much everywhere on the web).

I agree, it's unlikely. But never say never!

I really want another encoder that takes the no nonsense approach. As a matter of fact I wish they could be back to work on x264 in a way that breaks H.264 limitation but in a completely patent free way.

Indeed, there's probably compression and quality to be had by backporting some modern techniques to x264.

[ksec]

Hmm... Can VVC be decoded in software without having the latest and greatest CPU? And with what software?

Hmm...... VVC is already being software decoded on Smartphone for nearly 3 years in Apps for certain regions.

[GeoffreyA]

Hmm...... VVC is already being software decoded on Smartphone for nearly 3 years in Apps for certain regions.

With libdav1d, we've seen what continuous optimisation can achieve, so FFmpeg's VVC decoder could, in theory, reach something similar.

[Z2697]

As a matter of fact I wish they could be back to work on x264 in a way that breaks H.264 limitation but in a completely patent free way.

When you break H.264 limitation in a certain way you've essentially created... H.265.
Or anything. It will be a new codec anyway.
New codec means incompatible with existing decoders, you need to at least hack the decoder for it to work.

[birdie]

Test 1:
Chicago Fire FULL HD H266 Main10 12Mbits 25p YV12 BT709 SDR 10bit AC3 2ch 48000Hz.ts

120 fps
Intel Xeon E5-2637 v4 3.50GHz dual socket 8c/16th, 64GB RAM

111 fps
Intel i7 5930K 3.50GHz single socket 6c/12th 32GB RAM

Test 3:
The Creator FULL HD H266 Main10 12Mbits 25p YV12 BT709 SDR 10bit AC3 2ch 48000Hz.ts

121 fps
Intel Xeon E5-2637 v4 3.50GHz dual socket 8c/16th, 64GB RAM

116 fps
Intel i7 5930K 3.50GHz single socket 6c/12th 32GB RAM



1080p and such massive beasts of CPUs don't really look too good IMO.

Would be great if you compared ffmpeg's native H266 decoder with VVdec.

[BlueSwordM]

To be honest, these numbers are not great, but the CPUs aren't great anymore; they're not massive beasts anymore.

The 5930K is Haswell, and Xeon E5 v4 chips are Broadwell.

[benwaggoner]

Indeed, there's probably compression and quality to be had by backporting some modern techniques to x264.
What do you mean by " no nonsense approach?"

Arguably, x264's brilliance was from ignoring PSNR and focusing on all sorts of nonsense like adaptive quantization, psychovisually weighted QP, tuning for anime content, etc. It was really a big departure from how encoders had traditionally been designed and tuned, by a very different set of people than normally worked on encoders historically.

We can forget what a brilliant weirdo x264 was sometimes because so many of its crazy ideas inspired so much that followed that they seem obvious and standard in retrospect.

But CRF and MB-Tree were not obvious before x264 implemented them. Single pass at constant perceptual quality but VBV enforcement was also very novel.

[rwill]

We can forget what a brilliant weirdo x264 was sometimes because so many of its crazy ideas inspired so much that followed that they seem obvious and standard in retrospect.

Did not take long for the industry to go full "VMAF approved" style after that. I blame people being too lazy to look at their videos after encoding, they just want the computer to say "its ok" and be done.

[LigH]

will not mention MVCD or KVCD ever again :o

[ksec]

When you break H.264 limitation in a certain way you've essentially created... H.265.
Or anything. It will be a new codec anyway.
New codec means incompatible with existing decoders, you need to at least hack the decoder for it to work.

Indeed incompatible, I am thinking a much higher resources usage, but patent free / patent expired codec. I think Main Profile is near Patent Free, we are a few more years till High Profile is mostly patent free as well.

With Larger block size, macroblock, more / higher aggressive transform adaptivity basically brute force everything we have in H.264. I am wondering if we could reach compression that is HEVC+.

[benwaggoner]

Did not take long for the industry to go full "VMAF approved" style after that. I blame people being too lazy to look at their videos after encoding, they just want the computer to say "its ok" and be done.
Well, it sure would be so convenient to have an AI that tunes quality based on ratings from an AI that rates quality!

Alas, quality is only as good as humans perceive it to be, not AIs, and subjective correlation still isn't great. P1204.3 can outdo VMAF, but they are both ML-trained metrics and such reliant on the quality of their ground truth training data. VMAF was quite limited originally by being tested only on a relatively small set of x264 variations (mainly just varying CRF and frame size).

But AI optimizing for AI scoring can yield some weird results. For example, as VMAF excludes chroma, enabling chroma qp offset turning for VMAF will make chroma look much worse in exchange for slightly improved luma.

And no one has a good, practical metric for noise/grain similarity yet.

[kurkosdr]

Indeed incompatible, I am thinking a much higher resources usage, but patent free / patent expired codec. I think Main Profile is near Patent Free, we are a few more years till High Profile is mostly patent free as well.

With Larger block size, macroblock, more / higher aggressive transform adaptivity basically brute force everything we have in H.264. I am wondering if we could reach compression that is HEVC+.
It seems like you are looking to make something like EVC Baseline. Can't you use EVC Baseline instead? An open-source encoder and decoder called "xeve" exists.

Problem is hardware support for standalone players. OEMs add support for formats only when they are needed to implement some headline feature.

[Z2697]

It seems like you are looking to make something like EVC Baseline. Can't you use EVC Baseline instead? An open-source encoder and decoder called "xeve" exists.

Problem is hardware support for standalone players. OEMs add support for formats only when they are needed to implement some headline feature.

I think the point is x264-level quality, both the encoding outcome and the design of encoder itself.
XEVE is not of that level of quality... yet? Or will it?

[kurkosdr]

I think the point is x264-level quality, both the encoding outcome and the design of encoder itself.
XEVE is not of that level of quality... yet? Or will it?
The authors of xeve claim better-than-x264-level quality for EVC Baseline: https://github.com/mpeg5/xeve

So it can probably achieve x264-level quality.

[benwaggoner]

The authors of xeve claim better-than-x264-level quality for EVC Baseline: https://github.com/mpeg5/xeve

So it can probably achieve x264-level quality.
It's impossible to extrapolate without knowing how the other encoders were tuned. The "twice as good as HEVC" seems really, really implausible, particularly given that we have much more mature HEVC encoders available, like x265.

As always: https://web.archive.org/web/20141103202912/http://x264dev.multimedia.cx/archives/472

[benwaggoner]

The authors of xeve claim better-than-x264-level quality for EVC Baseline: https://github.com/mpeg5/xeve

So it can probably achieve x264-level quality.
Based on codec features, yeah, I suspect an equivalently well optimized EVC Baseline could outperform x264.

x264 has a crazy amount of optimization for a wide variety of use cases and content types, so making something in x264's ballpark is pretty monumental class. x265 itself got a big head start by building on top of x264's source code and algorithms.

[birdie]

Multicoreware Inc. claims the x266 encoder is not dead (https://multicorewareinc.com/beyond-x265-and-on-to-x266/) while providing zero new information about the state of its development.

[soresu]

Mmmph, sounds like they probably had little interest in putting any significant resource into x266, until they saw the AV2 announcement and got spooked.

[rwill]

Hey if you need some samples of what EVC Baseline is capable of just drop a request with the link to the (clean plz) source here.

[LigH]

I remember Jamaika providing xeve/xevd for a longer while, and MABS can compile it and link it into ffmpeg. But EVC is somewhere in between, by far not as complex as VVC.

[rwill]

I remember Jamaika providing xeve/xevd for a longer while, and MABS can compile it and link it into ffmpeg. But EVC is somewhere in between, by far not as complex as VVC.

Was this in response to my post? Because I would not use xeve to encode.

[LigH]

Yes.

Is there any serious reason why you discourage the use of xeve?

[rwill]

Xeve is untuned and is missing a lot of things state of the art encoders have.

[Z2697]

Was this in response to my post? Because I would not use xeve to encode.

Is it your in-house encoder? Could you perhaps drop *cough* *cough* an executable? ;)

Unlikely things aside, I think Big Buck Bunny or Tears of Steel is good for a "widedly accepted benchmark".