[MPEGIF Discuss] AVC-derived scalable video coding?

[Ben Waggoner]

Robert,
    I'm looking for some kind of scalability in deployed MPEG-4
technologies.  If I can't have FGS, or even enhancement layers, I'll at
least take stream scalability (which is all that RealMedia and Windows Media
offer today).  As it is, none of the mainstream MPEG-4 solutions support
streaming scalability of any sort (well, maybe dynamically dropping
B-frames, but that's quite limited in the range of data rates it can
provide).  PacketVideo obviously has Simple Scalable in their products, but
I'm looking for something that could compete with Windows Media and
RealMedia (QuickTime also lacks meaningful scalability).
    While scalable coding does have some theoretical efficiency
disadvantages, it's important to realize that stream scalability only offers
discreet bands.  So if there are 500 and 750 Kbps bands, at 700 Kbps,
scalable coding might offer better quality than the 500 Kbps band that would
otherwise be delivered.  It'd take an efficiency hit of 40% before the 700
Kbps scalable wouldn't be better than the 500 stream.  And sure, one can put
more and more scalable streams in there, but each is a significant hit for
file size and encoding time, and makes multicasting more problematic.
    Codec engineers seem to focus on the specific compression efficiency at
a given data rate, when the important measure is the delivered quality
across the range of possible data rates.  In essence, I don't care which
technology is better at 500 Kbps, I care which technology has the best mean
quality in the range of 100-1000 Kbps.
Ben Waggoner <http://www.benwaggoner.com>
Compressed Video Consulting, Training, and Encoding
My Book:            <http://www.benwaggoner.com/books.htm>
Cleaner e-book:     <http://www.cmpbooks.com/cleaner>
on 9/19/03 3:54 PM, Robert Bleidt at rbleidt hdtv.com wrote:
> Perhaps I'm just adding confusion, but I'm guessing what you want is stream
> scalability, not scalable coding. Unless there's something new, (which I'd
> like to learn about), most of the proprietary codecs seem to use stream
> switching, not scalable coding.
> 
> To explain: (you might also take a look at the illustration in
> http://www.eet.com/story/OEG20011112S0043)
> Generally, you can achieve scalable coding in three ways:
> 1. Switching from a stream to one encoded at a lower rate. (stream switching)
> 2. Dropping B-frames (temporal scalability)
> 3. Dropping enhancement layers (scalable coding or fine-grained scalability)
> 
> Scalable coding has the feeling of being the intellectually "right" way to
> do it, and gets a lot of interest from the research community.
> Unfortunately, in practice, as far as I know, it tends to work best over
> only a one-octave or so range of bitrates, after which the coding overhead
> of the enhancement streams starts to hurt the perceived quality. Stream
> switching doesn't have this efficiency loss and is fairly simple to
> implement - that's why it's used in practice. This is true both in audio
> and video coding - The BSAC audio codec using an coefficient encoding
> scheme very similar to the FGS profile of part 2 video.
> 
> I haven't done any work in this area, so I'm just repeating what I've heard
> and seen. Please voice your opinion...
> 
> Except for issues of switching streams (which the Extended AVC profile is
> supposed to have tools to address), there is no additional IP needed to do
> stream switching in AVC. There is room for innovation outside the standard
> in deciding when and how to switch streams.