[vdr] Possibly corrupt stream for VDR frontends in 1.7.4?
alexw
alexw at undercover.mine.nu
Mon Apr 6 11:14:19 CEST 2009
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 at 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
More information about the vdr
mailing list