[Live-devel] Kasenna support with MediaBase 7.2 ?

[Glen Gray]

Further follow up. All debugging pointed to problems with the data
coming in not being cable of syncing when the packets size was not a
multiple of 188 (the mpeg sync byte 0x47 should appear every 188 bytes).

This is a "known" issue with Kasenna servers as their packet sizes are
16Kb, which is not a multiple of 188. Packet loss ensues in these
scenarios. 

For those not in the "know", there's a secret masonic variable that
Kasenna's uds.config can have. It wasn't in mine and isn't mentioned
anywhere in the documentation that I could find. However a kind soul
passed it on. Basically, set PACKET_SIZE=<multiple of 188>. 1316 is
below Ethernet MTU and is also a multiple of 188 (7*188) and so is a
recommended figure to use. This will however increase load on the server
and reduce overall maximum bandwidth. 

I've also tested with 16356 which is as close to 16Kb as a 188 multiple
will get. I had no problems there, however I've been warned that such
large packets sizes can lead to fragmentation issues. I didn't see any,
but perhaps in conjunction with (well on linux clients anyway) IP
de-fragmentation in the kernel it would be fine ? Anyone experience with
that ?


On Wed, 2005-10-12 at 12:08 +0100, Glen Gray wrote:
> Just to follow up on my own email, I've made some progress.
> 
> In MediaSubsession::initiate, around line 659, where it deals with the
> Protocol, there is the following.
> 
>     // Check "fProtocolName"
>     if (strcmp(fProtocolName, "UDP") == 0) {
>       // A UDP-packetized stream (*not* a RTP stream)
>       fReadSource = BasicUDPSource::createNew(env(), fRTPSocket);
>       fRTPSource = NULL; // Note!
> 
>       if (strcmp(fCodecName, "MP2T") == 0) { // MPEG-2 Transport Stream
>         fReadSource = MPEG2TransportStreamFramer::createNew(env(), 
>                              fReadSource);
>        // this sets "durationInMicroseconds" correctly, 
>        // based on the PCR values
>       }
>     } else {
> 
> 
> I belive dermot added the "MP2T" in an effort to resolve some sync
> issues. However, all the missing byte issues etc. seem to be coming from
> the MediaSubsession class for the stream and so I commented this code
> out. It made a huge difference to the playback of the stream. There's
> only a fraction of the amount of image corruption in the played stream.
> However, there is enough to make it look pretty bad still.
> 
> By increasing the VLC debug output I can see that there is lots of
> discontinuity errors being reported as follows
> ...
> [00000249] livedotcom demuxer debug: duration = 0
> [00000251] ts demuxer warning: lost synchro
> [00000251] ts demuxer debug: skipping 0 bytes of garbage
> [00000251] ts demuxer warning: discontinuity received 0x6 instead of 0x5
> (pid=4131)
> [00000249] livedotcom demuxer debug: duration = 0
> [00000251] ts demuxer warning: lost synchro
> [00000251] ts demuxer debug: skipping 0 bytes of garbage
> [00000251] ts demuxer warning: discontinuity received 0xd instead of 0xc
> (pid=4131)
> ...
> 
> I don't think there's anything wrong with the stream, but then, I can't
> confirm this as the Kasenna media player for windows wouldn't even work
> for me (kept segfaulting). I've a ticket logged with Kasenna support on
> that, hopefully they'll get back to me soon.
-- 
Glen Gray <glen at lincor.com>              Digital Depot, Thomas Street
Senior Software Engineer                            Dublin 8, Ireland
Lincor Solutions Ltd.                          Ph: +353 (0) 1 4893682