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
Artem Makhutov wrote:
> alexw schrieb:
>> 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:
> (wget -q -O - http://192.168.10.2:3000/TS/S19.2E-1-1007-4901.ts >
> What helps is increasing the buffers in .xine/config, but this does not
> solve the issues:
> Thanks, Artem
> vdr mailing list
vdr mailing list