On Wed, 20 Apr 2011, Martin Storsjö wrote:
> On Wed, 20 Apr 2011, Ronald S. Bultje wrote:
>
> > Hi,
> >
> > On Wed, Apr 20, 2011 at 8:05 AM, Martin Storsjö <mar...@martin.st> wrote:
> > > On Wed, 20 Apr 2011, Ronald S. Bultje wrote:
> > >> On Wed, Apr 20, 2011 at 7:49 AM, Martin Storsjö <mar...@martin.st> wrote:
> > >> > This helps callers to intelligently switch between bitrate
> > >> > variants.
> > >> > ---
> > >> > libavformat/applehttp.c | 3 +++
> > >> > 1 files changed, 3 insertions(+), 0 deletions(-)
> > >>
> > >> Doesn't AVCodecContext have a bit_rate integer for this purpose?
> > >
> > > It does, but this is for a slightly different use. The bitrate in
> > > AVCodecContext is for the actual bitrate of that stream only, while this
> > > would convey the total bitrate of the whole bitrate variant that this
> > > stream belongs to. So for that, a different name perhaps would be better,
> > > like "variant_total_bitrate" or something similar?
> >
> > What's the difference?
>
> As Vladimir explained on irc - it's the total bitrate of all streams
> within the same bitrate variants. If I've got a stream with two variants,
> 100 kbps and 500 kbps, both having audio and video, I'd set "100 kbps" as
> variant_total_bitrate on the two streams from the first variant and "500
> kbps" on the other two. The audio stream bitrate may well be the same,
> e.g. 32 kbps in both of them, while the video would be 68 in the former
> and 468 in the latter.
>
> Therefore, when switching, the caller needs to know which streams belong
> to the same bitrate variant, so that he doesn't accidentally pull from
> more than one variant at a time, and preferrably also know what their
> total bitrate is.
To add more to the explanation - currently, the info about which AVStream
belongs to which variant stream actually is available, it's stored in
AVStream->id, where the int value says which variant it is a part of - all
AVStreams with identical id belong together. But someone from XBMC asked
me yesterday to provide the variant's total bitrate, too, which is useful
for making better decisions on switching variants.
// Martin
_______________________________________________
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
