[Live-devel] dummy ADUs while scaling up

[Ross Finlayson]

Matt,

Sorry for taking so long to answer this.

>I turned on full debugging output for the liveMedia library, and it looks 
>like the 8 identical pts values are due to dummy ADU frames being 
>inserted.  The debugging output snippet below shows before and after 
>sections of a "Scale:" command being acknowledged by the server.
>
>The comments in your code state "This situation should occur only if an 
>intermediate ADU was lost", which is by definition the case for this 
>implementation when scaling since we're skipping over audio frames. As I'm 
>not entirely familiar with the innards of mp3 data and how you're handling 
>all this, where do you think is the best place to resolve this?

Here's the issue:

Most MP3 frames are not self-contained - meaning that, in general, it's not 
possible to take an individual MP3 frame - all by itself - and play it, 
without error.  The reason for this is that MP3 frames (in general) make 
use of data that is actually stored in the preceding frame.  (This is 
sometimes called a "bit reservoir".)  I.e., each MP3 frame includes a 
back-pointer to data from the previous frame.

Similarly, you can't play a MP3 file at N-times speed by just selecting 
every Nth frame.

To overcome this problem when streaming MP3 audio using 'trick play', we 
(at the server end) convert the sequence of MP3 frames to 'ADUs' 
(application data units, see <http://www.live.com/rtp-mp3.txt>), then 
select every Nth *ADU*, and then reassemble the resulting sequence of ADUs 
back into a sequence of MP3 frames.

This usually works well, except that, occasionally, the resulting sequence 
of ADUs (formed by selecting every Nth ADU from the original sequence) 
can't be reassembled one-for-one back into a corresponding sequence of MP3 
frames.  This can happen if the back-pointer for one ADU would - if the ADU 
were reassembled into a MP3 frame - overlap the data from the previous 
ADU.  (Note that this happens only because we removed ADUs from the 
original sequence; otherwise, the translation MP3 frame -> ADU -> MP3 frame 
is completely one-to-one.)  When this situation happens, we have to add a 
dummy (empty) ADU into the sequence, before we reassemble the ADU sequence 
into MP3 frames.  So, the resulting MP3 stream will contain occasional 
short gaps (caused by the dummy frames).

Unfortunately the version of the code that you used contained a bug, which 
caused 8 dummy ADUs to be inserted, instead of just one.  (The bug got 
introduced after I had tested this code originally.)  This bug has now been 
fixed in the latest software release (2005.02.28).  If you build with this 
new version of the software, MP3 streaming at 'fast forward' should sound a 
lot better (although, because of the need for occasional dummy ADUs/frames, 
it can never be perfect.)


	Ross Finlayson
	LIVE.COM
	<http://www.live.com/>