[Mp4-tech] Re: [Audio] a few questions with regard to MPEG-2 AAC

[Ralph Sperschneider]

Yueshi Shen wrote:
> Hello, Ralph
>  
> I think I am now having a better idea about the adts_buffer_fullness 
> than before, could you please check whether my understanding of what 
> you told me is correct?
>  
> > To be precise: The difference between the values of adts_buffer_fullness
> > of two consecutive frames tells the difference between current frame
> > size and average frame size. Any further history is out of scope.
> > Consequently, when the frame size is constant, the values of
> > adts_buffer_fullness are always the same.
>
> > It should be used to derive the time to start playback, i.e. when in the
> > worst cases the decoder input buffer will not run dry (this may happen,
> > if you start playback to soon and the encoder delivers  a rather long
> > frame), nor  the decoder input buffer will  overflow (this may happen,
> > if you start playback tool late, and the encoder delivers a couple of
> > rather short frames).
>  
> > An adts_buffer_fullness of 0 means, that the bit reservoir is empty. In
> > that case the encoder may send only frames being equal in length or
> > shorter than the average. Hence, the decoder should start playback
> > immediately.
>
> > An adts_buffer_fullness of 6144-<mean_frame_length> means, that the bit
> > reservoir is full. In that case the encoder may spend bits by sending
> > frames being longer than the average. Hence, the decoder needs to 
> wait a
> > certain time before it starts playback (it needs to wait until it has
> > received further <adts_buffer_fullness> bits), since otherwise it might
> > not have the next frame ready (since it is not yet received 
> completely),
> > when it should.
>  
> So, the adts_buffer_fullness is about how many extra bytes are 
> available for encoding the next audio frame, if its size needs to 
> exceed the average.  (Before I was thinking the bytes in the adts 
> buffer are those previous audio frames transmitted and stored, before 
> being removed for decoding.)
>  
> Since adts_buffer_fullness tells us how much difference does an audio 
> frame have comparing with average frames in terms of size, it can 
> further indicate the player when to start playback (earlier or later 
> than normal).
>
> > In general, it is all about writing and reading bits in the decoder
> > input buffer. In the case of a constant bitrate channel, writing happens
> > on a continuous basis. Reading happens burst-wise, where a bust is a
> > frame. The frame length may vary, so some care has to be taken, that the
> > bits to be read are always present, and that the available buffer
> > (decoder input buffer) is always capable to store all the bits it 
> receives.
>  
> So, if the encoder encodes at a constantly higher or lower bitrate 
> than it is supposed to, the adts_buffer_fullness will eventually 
> underflow or overflow.
>  
>  
> Hope you have a fantastic Christmas holiday (and receive a lot of 
> gifts), and thanks once again for your very kind help.
>  
> Sincerely
> Yueshi
>

Dear Yueshi,
sorry for the delayed replay. Your statements seem to be correct.
Note: A standard conform encoder needs to avoid a buffer under- or 
overrun by sending fill bits or by a more coarse quantization.
Best regards,
Ralph
-- 
Dipl.-Ing. Ralph Sperschneider  | Phone: +49 9131 776 344
Fraunhofer IIS                  | Fax:   +49 9131 776 398
Am Wolfsmantel 33               | mailto:ralph.sperschneider iis.fraunhofer.de
D 91058 Erlangen                | http://www.iis.fraunhofer.de/amm/