[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