[Live-devel] Kasenna support with MediaBase 7.2 ?

[Derk-Jan Hartman]

On 13 okt 2005, at 15:46, Glen Gray wrote:
> 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 ?
>
The exact concern here is that each lost or out of date UDP packet is  
dumped. 16k means that as soon as one out of 85 packets is skipped,  
you will loose an entire TS frame which will cause quite a  
significant corruption in your decoding. Smaller TS frames means it  
will withstand network strain better. So for instance in case you are  
thinking of doing UDP over the internet (which Trax is doing for  
instance), then having large frames is a VERY bad idea. However the  
closer to the server your clients are, the better they can get away  
with large frames.

DJ

>
> 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
>
> _______________________________________________
> live-devel mailing list
> live-devel at lists.live555.com
> http://lists.live555.com/mailman/listinfo/live-devel
>
>
>