MBR, Multiple bitrates from one encoder, is it possible?

[wqpaul]

The requirement is come from delivery HD content. When you streaming the HD game, you may need several-Mbps bandwidth, but not all end-user have adequate bandwidth. To balance the quality and cover all end use, we may need multiple bitrate for one channel. E.g. 3M, 2M, 1.2M, 800k and 400k. End user may select the appropriate bitrate manually or automatically. So to provide multiple bitrate (MBR) channel, you need to duplicate your environments, more signals, more capture-cards and more machines.

But we all know that the content of these streams are all same, the MB partitions may same, moving vector almost same. I just interesting to know if it is possible to share these information between each codec and greatly increase the overall encode speed (we may accept a little quality decrease).

Here are my questions:
Is it possible or just a fancy?
If it work, how many cpu time we can save? One stream is 100%, five streams is 500%, what about the MBR five streams?
How much information can we share between these streams? E.g. slice type, MB partitions, MB type, MB reference information and MV information.
It is doable for different resolutions e.g 720P, 540P, 480P and SD?
Is these anybody is implementing it and How can I join? Where can I start it?

Please do not talk about Scalable Video Coding(SVC), It is still in lab and no player support.

Thanks in advance.

[Dark Shikari]

The information is a lot less similar than you'd think: partition types chosen (and even motion vectors) depend heavily on bitrate.

You could in theory design an encoder to do a single main search and then refine it separately for each of the various bitrates.

[Trahald]

Im really impressed by move networks player (FOX.com, ABC.com). It generally only pauses if you disconnect the internet. otherwise , the only thing traffic does is lower the bitrate of the data sent, it will automatically raise if conditions improve. I've only seen move network player do offline content (ie they had plenty of time to encode it). but i wouldnt be surprised if near real time could be done (no real basis for this, mostly gut and what ive observed)
Im not sure if its a progressive download (although latency is very short, so either they hide it well or its streaming). generally when play begins its instant , but at the lower rate for a few second then improves.

I think im mostly impressed with it because I havent seen it any place else that the masses have access to.

[wqpaul]

Yes, But do you know how many encode machine movenetwork using for one HD channel? More than a dozen machines. How long is the delay of live channel? 90 seconds. It using VP7 codec and is not very open.

Similar tech is Adobe's adaptive streaming in FMS3.5 and Microsoft's Smooth HD.

The MBR is now a hot point in delivery, I just got wanna to know if codec can help to save the huge CPU usage.

[CruNcher]

As you said yourself the current stuff is only chunked encoding workarounds but it works nicely though you need a big massive encoding system based on your goal and then keep that under control also (talking about heat) though these days you can scale nicely using multicore systems, but i guess you really want something more advanced and so you have to wait for SVC unless you want to reinvent the wheel again ;)
Microsofts Setup for Bejing was relatively seen small compared to how many user it delivered and how stable it was operating with the clever multiple CDN setup (especially the management system behind it) but yeah not everyone has those resources to setup such a massive project and manage it. I guess another possible solution might be if you can't really afford the Encoding setup or want to lower the costs there looking into a Distributed Encoding (P2P) supported setup, though then you also have a lot of other problems to solve their and so it might come out @ the same costs in the end.

[wqpaul]

but i guess you really want something more advanced and so you have to wait for SVC unless you want to reinvent the wheel again ;)
You are right, First of all , I want to know if it is possible or we should go with SVC?


looking into a Distributed Encoding (P2P) supported setup, though then you also have a lot of other problems to solve their and so it might come out @ the same costs in the end.
Distributed Encoding/Cloud Computing maybe another way, each encoding unit may got lower price but it's quit complex to setup and maintain.

[benwaggoner]

You are right, First of all , I want to know if it is possible or we should go with SVC?
This was a big topic of discussion at NAB, but mainly just discussion. It feels like the whole industry is just waiting for someone else to adopt it or not, and then follow that lead. Myself included :).

My big picture take on SVC versus bitrate switching:
Pro:

SVC makes for easy adaption to less complex streams to decode, since the higher layers can just be ignored. Stream switching requires a new stream to be requested, which has some latency to arrive.
SVC saves a bunch in storage and caches, since to get to a 4 Mbps top rate requires just 4 Mbps, instead of a set of4 Mbps + 3 Mbps + 2 Mbps + 1500 Kbps...
Generally the lower the latency, the more interesting SVC is. That's why it's probably a lock for videoconferencing.

Con:

SVC is less efficient as the layers go up, particularly with spatial scalability. Maybe a 10-15% net loss compared to doing a single bitrate for the final layer.
SVC is harder to parallelize in practice, since you're really encoding once and splitting it into layers. Now, one can imagine a staggered approach where different threads are used to build different layers up, but that would wind up impacting latency. So low-latency HD encoding could be quite challenging for software in SVC, while in stream switching there's no latency impact at all.
SVC is more complex to decode in software. Quite a bit slower in current implementations, but I doubt they're fully optimized yet
SVC has no installed base of ASIC decoders, so it's a non-starter for any device currently in the market or coming soon.
SVC is very early, and doesn't have mature encoders, servers, clients, etcetera. Since the industry isn't sure if it's going to be a hit or not, it could get stalled by chicken-and-egg.


In Smooth Streaming, we're doing the bitrate switching model, and it's working quite well for the existing content, use models, and network topology.

MBR encoding is an interesting field. We've made some good process in doing a single analysis pass for MBR encoding, but are still doing the final encode in parallel. The first implementation of our new SDK for this is available for Inlet Armada, with other vendors shipping soon.

The important thing in MBR encoding is to make sure that switching points are aligned; we start a new Closed GOP with sequence header at the same point in each stream, so that the bitrates can be switched at a higher layer, the a concatenated bitstream can be fed to the decoder which doesn't know that it's even doing MBR decode.

It requires some inter-stream management to makes sure that I-frame insertion triggered in one bitrate but not another doesn't lead to GOP misalignment.

[benwaggoner]

Microsofts Setup for Bejing was relatively seen small compared to how many user it delivered and how stable it was operating with the clever multiple CDN setup (especially the management system behind it) but yeah not everyone has those resources to setup such a massive project and manage it.
Well, don't overestimate the challenge of multi-stream encoding. The highest stream is going to be far the biggest consumer of computing resources. All those lower resolution sub-streams are proportionally quicker to install. Last I looked at the math, a 10 bitrate set didn't require even 4x the CPU power that the top stream did by itself. And that was with a completely parallel encode; just a bunch of instances running on their own with capture and preprocessing the only economy of scale.

Also, we can relax a little on the most expensive encoding techniques; sacrificing 5-10% efficiency to get 2x better encoding time is a lot less painful when the top bitrate is 4 Mbps compared to a 600 Kbps lowest-common-denominator stream.

Put another way, if one traded 10% less efficiency per stream to double the number of streams, so that the ratio between streams was 1.4x instead of 2x, the average user would be within 20% of their real bandwidth instead of within 50%, and thus improving the average experience substantially.

Those are made-up numbers, but once you realize the key thing about bitrate switching is delivering much higher bitrates on average, then the drawbacks don't seem all that bad :).


I guess another possible solution might be if you can't really afford the Encoding setup or want to lower the costs there looking into a Distributed Encoding (P2P) supported setup, though then you also have a lot of other problems to solve their and so it might come out @ the same costs in the end.[/QUOTE]