DeathTheSheep
17th August 2005, 23:29
Upon probing the old container documentations for methods of dynamic streaming control, I found nothing to allow dynamic datarate-controlled container-to-video-stream recompilation/reconstruction, before realizing that such a thing, if possible, would be next to worthless due to the massive amount of encoding time necessary to achieve the desired array of streams, to say nothing of the coding work which would inevitably go into this fundamental redefinition of a container. A bit frazzled, I then turned to actual codec specs.
And what do you know--I happened upon good old MBR.
MBR (F-GS fine granularity scalability) is a part of the universal MPEG-4 specifications. ISO-MPEG-4 10 (AVC) is obviously no exception to this rule, and so therefore must allow such a feature. MBR (multiple bit rate) profiles allow one (1) HD quality stream to be transmitted from a server. This signal, upon reaching a client device/player, will automatically scale down to that particular unit's connection speed, thereby ensuring maximum playback quality at each client's maximum connection speed. This is particularly useful in the age of EV-DO wireless internet (NOW), wherein it is possible to access internet from a much wider area than customary WiFi access points, but at significantly lower speeds. Unlike in Windows Media (which has its own version of "MBR" or RealMedia, which supposedly has a form of streaming bitrate scalability, AVC MBR does not use separate copies of video streams within the same container. In AVC (and the entire MPEG-4 spectrum), there's a "base
layer," upon which various "enhancement layers" are stacked. Each enhancement layer has a certain job. Different layers boost resolution to make the video progressively larger and clearer. Another layer is the "frame rate" layer, which increases the framerate based on the availability of bandwidth. These filters work together, of course. Certain filters residing in the level 2 layer, for instance, must all be activated before filters of a higher level can be instantiated into the local datastream.
Due to MBR's ability to scale from below dialup rates to the highest rates on the net today, everything from satellite boxes to PDAs to yes, cell phones, would be able to seamlessly stream any video file and achieve the maximum possible quality that its connection would allow.
Now for the problems. There are clearly a few.
Firstly, the compression quality of MBR-encoded streams tends to be significantly lower than that of an equal quality stream without MBR. However, with time and a bit of experimentation, such a gap can be bridged.
Secondly (and quite unfortunately), I happened across evidence that such a feat may be hard and long in coming.
I have only seen one piece of software that includes the "functionality to create 3GPP [a subset of MP4] multi bit rate (MBR) files,... a licensed feature that [supposedly] REQUIRES a Compression Master Mobile license."
For the future of streaming AVC, MBR encoding support is all but essential in networks such as EV-DO, which has a notoriously variable connection rate.
However, due to the relatively young age of both MBR and H.264, such encoders may take very long to develop on the public level.
MY SUGGESTIONS:
<> When such encoders become readily available and well-tested, experiment with them. MBR guides, much like MBR-enabled software, will be long in coming, but when available to you, try them out. One cannot possibly know if streaming of this level is suitable for his/her own use unless experimentation is performed (remember Doom9's classic 'try until you find what's best for you' advice? I sure do).
<> If you have a certain target audience, consider only using NORMAL (non-MBR) streams; if you intend a certain stream for dialup users, make it a standard dialup stream (follow my AVC Guide (http://forum.doom9.org/showthread.php?t=98247), if you need a few pointers).
<> If you do have use for a few different datarates, I'd still recommend you stick with hosting a separate stream due to the lower individual quality such methods are likely to produce. In the future, this advice may change.
<> Consider using MBR only if you are very highly concerned with conserving space and bandwidth and you plan on streaming long files to large audiences in all different layers of the speed spectrum. In this particular case, MBR is the only high-quality solution that is viable; if you were to host a 1mbps MBR file, dialup users, for instance, would only use a fraction of your bandwidth (thus sparing you the bulkier enhancement layers), and the need for separate files and long downloads would be eliminated.
-----------------------------------------------------------------------
However, AVC-MBR is hardly my area of expertise, and any comments/corrections/additions would be more than welcome.
And what do you know--I happened upon good old MBR.
MBR (F-GS fine granularity scalability) is a part of the universal MPEG-4 specifications. ISO-MPEG-4 10 (AVC) is obviously no exception to this rule, and so therefore must allow such a feature. MBR (multiple bit rate) profiles allow one (1) HD quality stream to be transmitted from a server. This signal, upon reaching a client device/player, will automatically scale down to that particular unit's connection speed, thereby ensuring maximum playback quality at each client's maximum connection speed. This is particularly useful in the age of EV-DO wireless internet (NOW), wherein it is possible to access internet from a much wider area than customary WiFi access points, but at significantly lower speeds. Unlike in Windows Media (which has its own version of "MBR" or RealMedia, which supposedly has a form of streaming bitrate scalability, AVC MBR does not use separate copies of video streams within the same container. In AVC (and the entire MPEG-4 spectrum), there's a "base
layer," upon which various "enhancement layers" are stacked. Each enhancement layer has a certain job. Different layers boost resolution to make the video progressively larger and clearer. Another layer is the "frame rate" layer, which increases the framerate based on the availability of bandwidth. These filters work together, of course. Certain filters residing in the level 2 layer, for instance, must all be activated before filters of a higher level can be instantiated into the local datastream.
Due to MBR's ability to scale from below dialup rates to the highest rates on the net today, everything from satellite boxes to PDAs to yes, cell phones, would be able to seamlessly stream any video file and achieve the maximum possible quality that its connection would allow.
Now for the problems. There are clearly a few.
Firstly, the compression quality of MBR-encoded streams tends to be significantly lower than that of an equal quality stream without MBR. However, with time and a bit of experimentation, such a gap can be bridged.
Secondly (and quite unfortunately), I happened across evidence that such a feat may be hard and long in coming.
I have only seen one piece of software that includes the "functionality to create 3GPP [a subset of MP4] multi bit rate (MBR) files,... a licensed feature that [supposedly] REQUIRES a Compression Master Mobile license."
For the future of streaming AVC, MBR encoding support is all but essential in networks such as EV-DO, which has a notoriously variable connection rate.
However, due to the relatively young age of both MBR and H.264, such encoders may take very long to develop on the public level.
MY SUGGESTIONS:
<> When such encoders become readily available and well-tested, experiment with them. MBR guides, much like MBR-enabled software, will be long in coming, but when available to you, try them out. One cannot possibly know if streaming of this level is suitable for his/her own use unless experimentation is performed (remember Doom9's classic 'try until you find what's best for you' advice? I sure do).
<> If you have a certain target audience, consider only using NORMAL (non-MBR) streams; if you intend a certain stream for dialup users, make it a standard dialup stream (follow my AVC Guide (http://forum.doom9.org/showthread.php?t=98247), if you need a few pointers).
<> If you do have use for a few different datarates, I'd still recommend you stick with hosting a separate stream due to the lower individual quality such methods are likely to produce. In the future, this advice may change.
<> Consider using MBR only if you are very highly concerned with conserving space and bandwidth and you plan on streaming long files to large audiences in all different layers of the speed spectrum. In this particular case, MBR is the only high-quality solution that is viable; if you were to host a 1mbps MBR file, dialup users, for instance, would only use a fraction of your bandwidth (thus sparing you the bulkier enhancement layers), and the need for separate files and long downloads would be eliminated.
-----------------------------------------------------------------------
However, AVC-MBR is hardly my area of expertise, and any comments/corrections/additions would be more than welcome.