[Live-devel] dummy ADUs while scaling up

[Matthew Romaine]

Ross,

Awesome - thanks for the clear explanation and update!
Looking forward to testing this out.

Cheers,
Matt

On 2005/02/28, at 19:03, Ross Finlayson wrote:


> 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/>
>
> _______________________________________________
> live-devel mailing list
> live-devel at lists.live.com
> http://lists.live.com/mailman/listinfo/live-devel
-----------------------------------------------------
Tel: +81-3-5448-6065
Fax: +81-3-5448-5617
Audio Codec Development Department
Personal Communications Business Division

ITCNC, Sony Corporation, Japan
-----------------------------------------------------