Re: [vdr] Possibly corrupt stream for VDR frontends in 1.7.4?
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: 0118x continuity errors (PAT) > PID: 97 OK (PMT) > PID: 51111x continuity errors (VIDEO) > PID: 5158x 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 gandalf ~ # cat /proc/interrupts CPU0 CPU1 CPU2 CPU3 0: 12888914411337786258 18240210 IO-APIC-edge timer 1: 0 13 58134 IO-APIC-edge i8042 4: 42230616 1199 IO-APIC-edge serial 7: 1 0 0 0 IO-APIC-edge 9: 0 0 0 0 IO-APIC-fasteoi acpi 16: 102657 89697935682647024913 IO-APIC-fasteoi cx88[0], cx88[0] 18: 83562 70885627779035382382 IO-APIC-fasteoi Technisat/B2C2 FlexCop II/IIb/III Digital TV PCI Driver 19: 33750 28102715365825602839 IO-APIC-fasteoi saa7146 (0), nvidia 20: 1159 6958 22822 49299 IO-APIC-fasteoi ohci_hcd:usb3, nvidia 21:870 5186 14223 31689 IO-APIC-fasteoi ehci_hcd:usb2, HDA Intel 22: 1362511764611 11889259 42501600 IO-APIC-fasteoi ehci_hcd:usb1 23: 9 40122328 IO-APIC-fasteoi ohci_hcd:usb4 27: 5469 44304 205020 528868 PCI-MSI-edge ahci 28: 57293 40614114404702949035 PCI-MSI-edge eth0 NMI: 0 0 0 0 Non-maskable interrupts LOC:8139882570818551826192852078 Local timer interrupts RES:10141995513238 110955565177732 Rescheduling interrupts CAL: 15782 5712 16844 13890 Function call interrupts TLB: 31047 54416 56527 42984 TLB shootdowns TRM: 0 0 0 0 Thermal event interrupts THR: 0 0 0 0 Threshold APIC interrupts SPU: 0 0 0 0 Spurious interrupts ERR: 1 MIS: 0 ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Possibly corrupt stream for VDR frontends in 1.7.4?
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: 0118x continuity errors (PAT) PID: 97 OK (PMT) PID: 51111x continuity errors (VIDEO) PID: 5158x 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. >> >> 1) Streamdev >> wget -q -O - http://:3000/TS/ > streamdev.ts >> >> 2) Xineliboutput (xineliboutput will use the current channel) >> wget -q -O - http://:37890/ > xineliboutput.ts >> >> If you want to use dvbsnoop pipe the output instead of redirecting to >> file with: >> >> | 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:1 > > Thanks, Artem > > ___ > vdr mailing list > vdr@linuxtv.org > http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr > ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Possibly corrupt stream for VDR frontends in 1.7.4?
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://:3000/TS/ > streamdev.ts > > 2) Xineliboutput (xineliboutput will use the current channel) > wget -q -O - http://:37890/ > xineliboutput.ts > > If you want to use dvbsnoop pipe the output instead of redirecting to > file with: > > | 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:1 Thanks, Artem ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Possibly corrupt stream for VDR frontends in 1.7.4?
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 (1.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://:3000/TS/ > streamdev.ts 2) Xineliboutput (xineliboutput will use the current channel) wget -q -O - http://:37890/ > xineliboutput.ts If you want to use dvbsnoop pipe the output instead of redirecting to file with: | dvbsnoop -nph -s ts -tssubdecode -if - After it is a matter of analysing. Rgds, Alex ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
