[Live-devel] mp3 ADUs

[Ross Finlayson]

>Does one of your test clients re-convert ADU frames back to mp3 so that 
>one might output to a file to do a bit-level comparison?

Note that that is already being done when the LIVE.COM RTSP server is 
streaming a MP3 file.  I.e., the server is converting MP3 frames -> ADU 
frames -> MP3 frames, before streaming.  (The server does this so that it 
is able to do a proper 'seek', or fast-forward, if necessary.)  Remember 
that the RTSP client (e.g., VLC or openRTSP) sees only MP3 frames.  So, if 
you really want to, you can compare the original MP3 file data (at the 
server) with the MP3 data that's received by the client.  If you're not 
doing 'fast forward', then the data should be equivalent.

If you want to do this, I suggest using "openRTSP" to play the stream, so 
that the streamed MP3 data will be recorded to a file.  (If you want to 
simulate 'fast forward', then you'll need to hack the 'scale' parameter in 
openRTSP's call to "play...()".)

>-) StreamRead in VLC's livedotcom.cpp still gets called every few frames 
>(albeit seemingly sporadically) with a pts difference of 0 (compared to 
>the previous frame) after a "Scale: x" request is sent with x > 
>1.0.  Should StreamRead really be called with a seemingly redundant frame?

Remember that these 'dummy' MP3 frames were inserted - by the server - to 
ensure that the resulting stream of MP3 frames would be well-formed, even 
after removing many of the ADUs (to implement fast forward).  Therefore, 
the dummy MP3 frames *have to* be passed to the MP3 decoder.

>-) the mad library loaded for decoding mp3s in the VLC client returns a 
>number of errors after trickplay has been initiated, most notably "bad 
>main_data_begin pointer", "bad audio data length", and "Huffman data 
>overrun". My hunch is that the second error, which according to the mad 
>library occurs when "channel->part2_3_length - part2_length < 0", is 
>triggered by a miscalculation somewhere when handling ADUs.  If these 
>errors are expected at times due to the nature of frame skipping, please 
>let me know

No, the MP3 stream that gets sent to the client (after removing ADUs for 
fast forward, and inserting dummy ADUs as necessary) is supposed to be 
well-formed, without errors.  The only way this could not happen is if 
there's packet loss.  (If, however, there's no packet loss, and you're 
seeing data errors, then there may well be a bug in the server's 
MP3->ADU->MP3 conversion mechanism.)


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