Mailing List archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[linux-dvb] Re: Network: a new hope



Emard writes:
 > While testing some more on network packet loss, 
 > here I must review my statement about TS and PID bandwidth!
 > 
 > I think that so called 'section' code in dvb_demux.c is 
 > not working 100% correctly and must be reviewed.

How exactly do you measure the packet loss?
Can you determine exactly which packets are missing? With this I mean
if you can see which TS packet seems to contain packets but is not
demuxed as having an IP/MPE section.

I have a completetly rewritten section demux code. I test it in user
space with the complete TS as input. It should be easy to see
this way which packets are not handled correctly. 


 > SO in my observation, the network packet loss occurs when
 > PID_8191_bandwidth < 0.5 * full TS bandwidth
 > 
 > This means that there should be packet loss for every TS that is using 
 > more than half of its bandwidth with useful data and less than half
 > of its bandwidth for padding with dummy PID 8191.
 > 
 > So why is half bandwidth important point:
 > 
 > PID 8191 bandwidth > 0.5 * full TS bandwidth
 > * means that each network encapsulation packet can be interlaced
 >   with zero pad packet of PID 8191
 > 
 > PID 8191 bandwidth < 0.5 * full TS bandwidth
 > * means that at least two network encapsulation packets
 >   must be sent one immediately after another (back-to-back)
 >   without zero pad packet of PID 8191 inbetween them

But I do not see how this could have any influence on the 
workings of the section demuxer. The 0x1fff packets are just skipped.

Or is the demuxer too slow and processes already overwritten data?
But then this 0.5 TS bandwidth limit would depend on the CPU speed.


Ralph


-- 
Info:
To unsubscribe send a mail to ecartis@linuxtv.org with "unsubscribe linux-dvb" as subject.



Home | Main Index | Thread Index