[Live-devel] [PATCH]MPEG1-Audio for Kasenna

[Glen Gray]

Hey Ross/Guys,

Here is a set of 3 patches we've been working on, to enable MPEG-Audio 
playback from Kasenna.

live_mpa_sdp_fix.diff:: modified RTSPClient.cpp to allow it to generate 
a valid SDP string from Kasenna's Description data. Previously it was 
hardcoded to just generate a Video SDP. This was done by me back in March.

The next 2 patches where made by Greg Farrell <greg at lincor.com>. If 
these are accepted, please ensure he gets the credit for them.

live_mpeg_audio.diff:: this is effectively the final part of the above 
patch and was implemented by Greg after I moved off the project onto 
something else. This basically wraps the in coming UDP data with 
MPEG1or2AudioStreamFramer, based on the fCodeName string, in much the 
same way that MPEG2TransportStreamFramer was called to enable Mpeg2-ts 
video playback from the Kasenna.

With the first patch above, we got our version of VLC establishing and 
playing back an MPEG1-Audio stream from our Kasenna, however we didn't 
get to hear the Audio (no pts's on the raw data). With the second patch 
we could hear the audio, but noticed a problem. After a while we lost 
sync and eventually the stream collapsed.

live555_udp.diff::

Quote from Greg
> The StreamParser class uses two receive buffers or 'banks'. It receives data into
> one bank until it is full then swaps to the other bank and so on.
> 
> How the StreamParser class decides if there is enough room in the current buffer
> to perform a receive is by checking if the space left is greater than the number
> of bytes of data requested from the StreamParser.
> 
> However if the underlying data source is UDP (BasicUdpSource) then a receive with
> a max length of less than the size of incoming UDP packets will result in the rest of
> the packet being silently dropped in GroupsockHelper/readSocket().
> 
> This will happen whenever there is enough room for a frame (the length of data
> StreamParser will be asked for) in a bank buffer but not enough room for a full
> UDP packet. Kasenna's will put multiple mpeg audio frames in one UDP packet
> for efficiency I assume and this will result in lost data on most bank buffer swaps.
> 
> To fix it I've changed the StreamParser to swap banks whenever it believes there is
> not enough room left for a packet as well as a frame. As you can't tell in advance what
> size incoming UDP packets will be the StreamParser defaults to a guess of 512 bytes
> and increases that whenever it sees larger packets.

We are still experiencing some problems however. Namely, pts drifts out 
of sync and eventually the streams break down. We'd put a hack in place 
to force the pts values to stay synced and that was when we noticed that 
we where loosing UDP data. Fixing that with the final patch listed 
above, we've put all these patches into our VLC build and noticed that 
we are still experiencing pts drift (which we'd assumed was happening 
because of the lost UDP data).

We're continuing to investigate.
Kind regards,
-- 
Glen Gray <glen at lincor.com>              Digital Depot, Thomas Street
Senior Software Engineer                            Dublin 8, Ireland
Lincor Solutions Ltd.                          Ph: +353 (0) 1 4893682
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: live555_udp.diff
Url: http://lists.live555.com/pipermail/live-devel/attachments/20060704/b62517d2/attachment-0003.ksh 
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: live_mpa_sdp_fix.diff
Url: http://lists.live555.com/pipermail/live-devel/attachments/20060704/b62517d2/attachment-0004.ksh 
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: live_mpeg_audio.diff
Url: http://lists.live555.com/pipermail/live-devel/attachments/20060704/b62517d2/attachment-0005.ksh