EyeIO & Netflix (H.264)

[raceviper13]

http://gigaom.com/video/eyeio-video-encoding-netflix/

Article quote, "EyeIO CEO Rodolfo Vargas told me during a phone conversation on Tuesday that his company’s encoding technology can achieve better-looking results than most established encoders with 20 percent bandwidth savings and that eyeIO can still deliver similar quality to other encoders with up to 50 percent bandwidth savings."

Interesting.:thanks:

[amtm]

How is it interesting? Their website is devoid of anything useful and is just full of the usual marketing hype for a new "revolutionary" encoder.

[Blue_MiSfit]

I've heard that Netflix has used Mainconcept for quite awhile (and x264 on their PS3 and iOS streams I believe). Marketing is marketing, but I'm guessing this is some kind of pre-processing...

[amtm]

That's sort of the problem, you can't tell what it is they are actually pushing. They just talk about their "breakthrough...Next Generation video encoding technology". Companies making these claims are a dime a dozen these days. And there's no way they can do ultra-low bandwidth encoding with no sacrifice in quality. That's just more nonsense marketing claims.

[Dark Shikari]

It's a safe assumption that any claims of "magical new compression technology" are a scam.

In the real world, if someone has an amazing new compression technique, they benchmark it against existing techniques -- preferably in a controlled environment by a third party, or you post exactly what's necessary for others to replicate it.

The H.265 proposal, for example, is showing gains of up to 30-50% PSNR against H.264. This is believable because their test results are detailed and replicable with software you can download. Even if EyeIO was obsessed about not distributing their libraries, they could still post sample output streams to demonstrate their claims, or at least get a third party to do benchmarks.

Remember, if you have something that really is revolutionary and amazing, it couldn't possibly hurt to do such a thing, and surely the publicity would make you tons of sales.

Thus, if someone claims such "amazing technology" but doesn't publicly test it and doesn't show real results, they must have motivation for doing that -- almost always the fact that their "technology" doesn't live up to their claims.

Also, I have a purple dragon in my basement. But I can't show her to you, she's too amazing and revolutionary for that.

[amtm]

To retain hardware compatibility and to back up their claims of it being a "fully standard-compliant coding solution" and "eyeIO is not yet another new proprietary video codec", it's gotta be an H.264, or VC-1 I guess, encoder with some sort of fancy interface and, as Blue_MiSfit says, maybe some sort of preprocessing filter to enhance compressibility. One would assume there must be SOMETHING to it if Netflix has licensed this technology, but clearly their website is completely vacuous marketing claims that will never live up to the hype. We all know how well On2's claims about VP8 lived up to reality as well. :rolleyes:

[CruNcher]

Another one ;) http://www.streamingmedia.com/Articles/Editorial/Featured-Articles/Digital-Blonde-Promises-Better-Encoding%3b-We-Say-Prove-it!-80052.aspx

Hehe this also shows the first win for x264 in a wide public media many inet compressionists (wannabe) read ;)
though testing vs vp6 and claiming that it's still majorly used hmmm from an expert in the field of fak ehh bending results (he worked on the Fractal Revolution ;) )
But at least he debunked that Digital Blonde stuff with his knowledge in this marketing field, who might have thought he wouldn't use x264 :D

this is the best http://www.betterencoding.com/pdf/xcoder_techspecs.pdf

there the super adaptive content analyzer in action ;) (Scotty Beam me up)

That's the cool new world of the Cloud too, as those guys feel very safe now making claims and just showing results some screenshots of some magic analyzer and are safe as they provide a service and customers are happy with it (and so they look legit in practice they are even legit with their service) ;)
Though i don't want to know how many times we actually even help such persons on doom9 and elsewhere without knowing it, but that's life and everyone here can do it too we just aren't clever enough ;)



It's a safe assumption that any claims of "magical new compression technology" are a scam.

In the real world, if someone has an amazing new compression technique, they benchmark it against existing techniques -- preferably in a controlled environment by a third party, or you post exactly what's necessary for others to replicate it.

The H.265 proposal, for example, is showing gains of up to 30-50% PSNR against H.264. This is believable because their test results are detailed and replicable with software you can download. Even if EyeIO was obsessed about not distributing their libraries, they could still post sample output streams to demonstrate their claims, or at least get a third party to do benchmarks.

Remember, if you have something that really is revolutionary and amazing, it couldn't possibly hurt to do such a thing, and surely the publicity would make you tons of sales.

Thus, if someone claims such "amazing technology" but doesn't publicly test it and doesn't show real results, they must have motivation for doing that -- almost always the fact that their "technology" doesn't live up to their claims.

Also, I have a purple dragon in my basement. But I can't show her to you, she's too amazing and revolutionary for that.

Though Dark EyeIO looks @ least legit also seeing that the head worked as CTO on the XVD codec, though that says nothing about the claims of course ;)

That Digital Blonde stuff on the other side looks pure ridiculous, the whole marketing the whole website the whole customers (yep those surely have knowledged tech staff ;) ), the whitepaper the tech-specs everything :)
The idea is also pretty simple everyone can have cloud encoding with x264 so what does it need to differentiate, yes some "clever" cloud encoding so what are you doing ?
You change some options analyze the targets current used system and adapt yours to look slightly or if possible even much better do a nice presentation and are set, give that whole thing a nice name (Xcoder) make a nice .sh file with some cool looking text and here you are then you register some company name (don't forget to push that you are a Innovative new Startup) and the E-mails to those you analyzed go around but make sure as targets you really only search for the last experienced customers you can find, presumably those with the lowest quality you can find) ;)
Now we tell them they get a price reduction if you can use their names for advertising on your companies Website (or they feel so happy with it they give you the right for free) and boom you have customers :)
Now look for media (that you know uses weak stuff to test things or @ least weaker then your used one in this case x264) and that's where Digital Blonde fall big time on its nose surely they didn't expected it would be tested vs x264 but Mainconcept ;)

Though with Netflix i have my doubts it was that easy somehow to get them as customer or did they also used Mainconcept with weak settings ? ;)


Also, I have a purple dragon in my basement. But I can't show her to you, she's too amazing and revolutionary for
Cute also want one, how much ??? :D

[nm]

Now look for media (that you know uses weak stuff to test things or @ least weaker then your used one in this case x264) and that's where Digital Blonde fall big time on its nose surely they didn't expected it would be tested vs x264 but Mainconcept ;)

Apparently they failed so badly at setting their x264 options that they lost a comparison to another x264 frontend.

[CruNcher]

btw i thought about how EyeIOs (Vargas) could have improved the Encoder the way they claim to and "Adaptive Deadzone" decisions immediately came to my mind ?

http://www.faqs.org/patents/app/20080240235

This is still something in the X264 Encoder that could be optimized (currently hard set, or manual) and fine tuned with AQ and PSY RD

[benwaggoner]

http://gigaom.com/video/eyeio-video-encoding-netflix/

Article quote, "EyeIO CEO Rodolfo Vargas told me during a phone conversation on Tuesday that his company’s encoding technology can achieve better-looking results than most established encoders with 20 percent bandwidth savings and that eyeIO can still deliver similar quality to other encoders with up to 50 percent bandwidth savings."
Well, I've certainly gotten 50% or more bandwidth savings compared to "another encoder" by using better preprocessing and tuning the settings better for the scenario. Heck, for progressive download content, just switching from CBR to 2-pass VBR can be worth 50% on movie/TV content.

I bet that there's some case they've found where they get a 50% advantage, but I highly doubt they get anywhere near that much compared to appropriately tuned professional workflows.

But this would be a HUGE gap for an apples-to-apples comparison (unless it's x264-to-Apple's H.264...).

That said, there's quite a lot of medium-hanging fruit right now as we move to adaptive streaming. Way too many workflows are fixed-cadence CBR only. There's plenty of bits to squeeze out of Smooth Streaming/Apple HLS/Flash HDS/DASH. But the improvements are more in coordinated encoding of parallel streams and rate control than magic low-level codec improvements.

H.264 year-on-year improvements are slowing down, with H.265 probably where we see the next big jumps.

[Blue_MiSfit]

@benwaggoner:

I'm curious about your mention of fixed cadence, CBR workflows for the various adaptive streaming systems being sub-optimal. Two questions:

1) What do you mean by fixed cadence? Hard pulldown?
2) Since adaptive streaming is by definition streaming, and in streaming your vbv-maxrate should equal your allowed bandwidth usage (minus audio and overhead), why would you chose any option other than CBR in this case? Using a lower average bitrate would be a waste... right? Am I missing something?

Thanks!

Derek

[benwaggoner]

@benwaggoner:

I'm curious about your mention of fixed cadence, CBR workflows for the various adaptive streaming systems being sub-optimal. Two questions:

1) What do you mean by fixed cadence? Hard pulldown?
Fixed GOP duration. Commonly an IDR every 2, 5, or 10 seconds, irrespective of scene changes. So you might get an IDR frame an an I-frame immediately following, instead of expanding the first GOP by one frame and having what would have been the I the IDR.

2) Since adaptive streaming is by definition streaming, and in streaming your vbv-maxrate should equal your allowed bandwidth usage (minus audio and overhead), why would you chose any option other than CBR in this case? Using a lower average bitrate would be a waste... right? Am I missing something?
Using more bits than needed is wasting bandwidth cap/costs of the customer and publisher. Also, sometimes we get lucky and the encode uses fewer bits when bandwidth is limited.

Lastly, if each stream is encoded at fixed frame size, and if a given chunk is easy to encode, the client could request a higher resolution version of the same chunk that fits within available bandwidth. Don't think of each bitstream as a "stream" but one line of an array of chunks that a client finds the optimal path through.

[sonnati]

Well, I've certainly gotten 50% or more bandwidth savings compared to "another encoder" by using better preprocessing and tuning the settings better for the scenario.

I agree with Ben, today there's a lot more room for improvements in how an encoder is used in an encoding workflow than in the low level encoding techniques.

For xample, I'm a big fan of adaptive encoding, where content is classiied for complexity and encoded accordingly.
For a huge library like netflix, this approach can have much more benefits than improve x264 efficiency of, let's say, 10% in every situation.

[benwaggoner]

For xample, I'm a big fan of adaptive encoding, where content is classiied for complexity and encoded accordingly.
For a huge library like netflix, this approach can have much more benefits than improve x264 efficiency of, let's say, 10% in every situation.
The best implementation I've seen of this so far was in the (sadly never really marketed) Smooth Streaming VC-1 VBR implementation. It would dynamically pick the optimum coded resolution for each GOP. For high-action scenes, it would typically compress more on the primary axis of motion, so a vertical pan might get encoded as 1920x544 and a horizontal pan at 960x1080. With motion blur, you didn't need much detail along that axis.

This allows much larger frame sizes be used for a given bitrate, since the encoder would only use the maximum frame size when it could, and would drop down as much as needed to keep distracting block artifacts from appearing.

It'd be nice to see someone do something similar with H.264. For example, allowing a "max CRF" to be set and frame size reduced for a GOP to the largest that doesn't exceed the CRF.

[Dark Shikari]

For example, I'm a big fan of adaptive encoding, where content is classiied for complexity and encoded accordingly.Why do you need to "classify for complexity"? A proper constant quality mode should aim to achieve the same quality across all video, regardless of complexity. If you have a way to make it better, you fold it into the constant quality mode, not add some external classifier.

It would dynamically pick the optimum coded resolution for each GOP.This shouldn't help much unless you're really pressed for bitrate. In my experience, dropping the resolution doesn't help quality until the effective CRF is well over ~30ish.

[Blue_MiSfit]

Thanks for the clarification, Ben.

In principle I really like the description you provided of Smooth Streaming VC-1 VBR. I'm curious how much this approach (if applied to x264 or Mainconcept H.264) would affect end-user experience. Does this implementation require offline / 2 pass encoding to do a good job, or is there support for live encoding? I'm sure offline / 2 pass was preferred in any case!

Thanks,
Derek

[benwaggoner]

Thanks for the clarification, Ben.

In principle I really like the description you provided of Smooth Streaming VC-1 VBR. I'm curious how much this approach (if applied to x264 or Mainconcept H.264) would affect end-user experience. Does this implementation require offline / 2 pass encoding to do a good job, or is there support for live encoding? I'm sure offline / 2 pass was preferred in any case!
This implementation was does as 2-pass, but certainly could be done single-pass with adequate lookahead.

The challenge with end-user experience is mainly having hardware decoders that can handle arbitrary changes in frame size, of course, most premium content with adaptive streaming is software-decoder only right now for DRM reasons, as there are hardware/driver issues with key rotation and other advanced features.

Just when we got DXVA for H.264 pretty much nailed, now we've got all these streams it doesn't handle well.

One of the reasons why the VBR VC-1 was well-suited to Silverlight is that VC-1 is a lighter-weight decode in software. Also, dynamic resolution meant that harder to decode GOPs had fewer pixels to decode, and so CPU decode load was somewhat flatter than with fixed-size content.

[sonnati]

Why do you need to "classify for complexity"? A proper constant quality mode should aim to achieve the same quality across all video, regardless of complexity.

Constant quality is perfect for storage or progressive downloading or in single rendition streaming (if joined with a max bitrate constraint) but it's not suited, for example, for dynamic streaming.

When I mention a "Classification for complexity" I mean that
instead of encoding every content at a target average bitrate that is good for every complexity (common approach today),
low complexity video could be encoded at a lower average bitrates (in a single rendition but also in multiple renditions if Dynamic Streaming is involved) while higher complexity contents could be encoded at higher bitrates or at the same bitrate but lower resolution and using dedicated presets (slower and/or with filters).

So instead of encode every content in 1280x720@2Mbit/s with the same preset,
encode low complexity at 1280x720@1M (for example), medium complexity 1280x720@1.5M and high complexity at 1024x720@1.8M. At the end you probably will have a negligible loss in perceived quality with an overall save in bandwith consumption of around 30%. For first class streamers this could mean millions$ saved.
I mention single rendition but immagine that below you have a complete set of sub renditions for dynamic streaming scaled accordingly.

A company like NetFlix can have huge overall improvements from a smart encoding "configuration". Even because they usually have dumb "configurations" like strict CBR, costant GOP size, poor deinterlacing, wrong Dynamic Streaming set, unbalanced resolutions-target bitrate mix and, finally, poor h264 encoders.
So I would not be surprised to discover that EyeIO is simply applying a smart x264 pipeline to the huge NetFlix's library to obtain a 30-50% overall improvement in bandwidth consumption compared to the former pipeline.

[CruNcher]

This implementation was does as 2-pass, but certainly could be done single-pass with adequate lookahead.

The challenge with end-user experience is mainly having hardware decoders that can handle arbitrary changes in frame size, of course, most premium content with adaptive streaming is software-decoder only right now for DRM reasons, as there are hardware/driver issues with key rotation and other advanced features.

Just when we got DXVA for H.264 pretty much nailed, now we've got all these streams it doesn't handle well.

One of the reasons why the VBR VC-1 was well-suited to Silverlight is that VC-1 is a lighter-weight decode in software. Also, dynamic resolution meant that harder to decode GOPs had fewer pixels to decode, and so CPU decode load was somewhat flatter than with fixed-size content.

Is it your fault that a minority of users create out off spec bitstreams was it forseable ?