Hello,
currently watching HDTV channels using a VDR frontend (streamdev and xineliboutput - current CVS builds) is impossible for me.
Watching the recordings (00001.ts) using xine (with VDPAU) works like a charm.
I am wondering if there could be a bug in how VDR is presenting the TS data to the frontends.
I have just a corrupt video and audio using both plugins. I have also glitches in MPEG2 streams some times, which do not occour when watching the .ts recording directly.
Can somebody validate this?
Thanks, Artem
PS: I saw similar problems while testing the multicast output of streamdev. The STBs I have used for playback did not liked 1500 bytes large packets which streamdev had send out (Xine had no problems in playing them back). When streamdev was changed to send 1316 (7*188) bytes packets the problem was solved for the STBs. Maybe there is something similar with VDR 1.7.4?
For what its worth, and its not worth much. I was watching live TV using Mplayer (on a Nintendo Wii) to streamdev on 1.7.4. the PES (http://xxx:3000/PES/1) stream worked quite well, whereas the TS stream only worked for a few seconds and then crashed. It was not corrupt though and the problem is no doubt due to the Mplayer port.
-- Scott
On Sun, 5 Apr 2009 10:26:05 +0200, Artem Makhutov artem@makhutov.org wrote:
Hello,
currently watching HDTV channels using a VDR frontend (streamdev and xineliboutput - current CVS builds) is impossible for me.
Watching the recordings (00001.ts) using xine (with VDPAU) works like a charm.
I am wondering if there could be a bug in how VDR is presenting the TS
data
to the frontends.
I have just a corrupt video and audio using both plugins. I have also glitches in MPEG2 streams some times, which do not occour when watching the .ts recording directly.
Can somebody validate this?
Thanks, Artem
PS: I saw similar problems while testing the multicast output of
streamdev.
The STBs I have used for playback did not liked 1500 bytes large packets
which
streamdev had send out (Xine had no problems in playing them back). When streamdev was changed to send 1316 (7*188) bytes packets the problem was solved for the STBs. Maybe there is something similar with VDR 1.7.4?
vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Artem Makhutov wrote:
Hello,
currently watching HDTV channels using a VDR frontend (streamdev and xineliboutput - current CVS builds) is impossible for me.
Watching the recordings (00001.ts) using xine (with VDPAU) works like a charm.
I am wondering if there could be a bug in how VDR is presenting the TS data to the frontends.
I have just a corrupt video and audio using both plugins. I have also glitches in MPEG2 streams some times, which do not occour when watching the .ts recording directly.
Can somebody validate this?
Thanks, Artem
PS: I saw similar problems while testing the multicast output of streamdev. The STBs I have used for playback did not liked 1500 bytes large packets which streamdev had send out (Xine had no problems in playing them back). When streamdev was changed to send 1316 (7*188) bytes packets the problem was solved for the STBs. Maybe there is something similar with VDR 1.7.4?
vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
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.
Rgds,
Alex
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.
- Streamdev
wget -q -O - http://<vdr ip>:3000/TS/<channel> > streamdev.ts
- 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 - http://192.168.10.2:3000/TS/S19.2E-1-1007-4901.ts > 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
Hi,
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 value?
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.
Cheers,
Alex
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.
- Streamdev
wget -q -O - http://<vdr ip>:3000/TS/<channel> > streamdev.ts
- 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 - http://192.168.10.2:3000/TS/S19.2E-1-1007-4901.ts > 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
Hi,
On Tue, Apr 14, 2009 at 11:31:07AM +0200, alexw wrote:
Hi,
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
Thanks for the info.
It seems that you are loosing packets from your DVB frontends/receiver.
Yes, it looks so.
Is your computer overloaded during the transmission?
No, my computer is not overloaded.
Is your DVB card or network card is using shared IRQ?
Yes, it looks like it is using shared IRQ's. I have attached a cat /proc/interrupts.
Did you play with the PCI bus latency value?
No.
Could you please try the latest VDR version 1.7.5.
I have just tried out 1.7.5. It looks like it got a little bit better, but it stil has not solved my problems.
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.
I have tried playing back the stream from 127.0.0.1. The problems are the same. So it has nothing to do with my network card. I will try to remove some of my DVB-Cards and also disable my onboard video card. Maybe it is really a problem with the IRQs.
Thanks, Artem
-
alexw -
Artem Makhutov -
scott