In your capture file, I can see the PAT insertion have a bad TS 
continuity counter. But his should not prevent from getting the PMT and 
decoding the stream.

PID: 0        118x continuity errors (PAT)
PID: 97     OK (PMT)
PID: 511    11x continuity errors (VIDEO)
PID: 515    8x continuity errors (AUDIO)
PID: 18      OK (EIT)
PID: 2687  OK
PID: 2736  OK
PID: 4070  OK
PID: 5663  OK

It seems that you are loosing packets from your DVB frontends/receiver. 
Is your computer overloaded during the transmission? Is your DVB card or 
network card is using shared IRQ? Did you play with the PCI bus latency 

Could you please try the latest VDR version 1.7.5.

I made some HD h264 streaming tests with a popcorn hour as client device 
over a wifi network and the video plays perfectly smooth with the 1.7.5 
VDR version. With version 1.7.4 the video was jerky due to TS error on 
video stream.



Artem Makhutov wrote:
> Hello,
> alexw schrieb:
>> Hi,
>> Could you please check the TS continuity with dvbsnoop when using 
>> streamdev or xineliboutput over the network? If not please make a 
>> network recording (~ 5 minutes) for both case.
>> 1) Streamdev
>> wget -q -O - http://<vdr ip>:3000/TS/<channel> > streamdev.ts
>> 2) Xineliboutput (xineliboutput will use the current channel)
>> wget -q -O - http://<vdr ip>:37890/ > xineliboutput.ts
>> If you want to use dvbsnoop pipe the output instead of redirecting to 
>> file with:
>> <wget cmd> | dvbsnoop -nph -s ts -tssubdecode -if -
>> After it is a matter of analysing.
> I have uploaded a corrupt stream: 
> http://www.makhutov.org/downloads/vdr/streamdev3.ts
> (wget -q -O - > 
> streamdev3.ts)
> What helps is increasing the buffers in .xine/config, but this does not 
> solve the issues:
> engine.buffers.audio_num_buffers:5000
> engine.buffers.video_num_buffers:10000
> Thanks, Artem
> _______________________________________________
> vdr mailing list
> vdr@linuxtv.org
> http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

vdr mailing list

Reply via email to