[vdr] Re: Stream conversion from DVB-T buggy on VDR (all versions?)

[Gregor Lawatscheck <gpel@mpex.net>]

At 17:11 13/01/2003, I wrote:
> I have been playing around with the TS -> PS remux.c converter in vdr 
> where I believe the problem sits without much luck. Ultimately what one 
> wants to do is to try and integrate the working ts2ps routine from the DVB 
> driver's mpegtools or dvbstream (same thing) into vdr and see if that 
> fixes it. I believe however this might be fairly complicated to a novice 
> programmer like me who barely understands vdr's structure.
I did some more looking at code and luckily it seems the TS 2 PES with all 
it's goodies like instant_repack etc. in mpegtools, dvbstream, tuxzap and 
hence vdr are all very similar in structure. However I what I did notice: 
vdr's handling of PTS is almost none-existing. Now I have not much of a 
clue what PTS are good for but - google says something to do with 
audio/video sync / jitters... that again does sound familiar if I look at 
the picture :)


For example mpegtools, tuxzap and dvbstream do
                        if (p->mpeg == 2 && (p->flag2 & PTS_ONLY) &&
                            p->found < 14){
                                while (c < count && p->found < 14){
                                        p->pts[p->found-9] = buf[c];
                                     write_ipack(p, buf+c, 1);
                                        c++;
                                        p->found++;
                                }

whereas vdr would only do

            if (mpeg == 2 && (flag2 & PTS_ONLY) && found < 14) {
               while (c < Count && found < 14) {
                     write_ipack(Buf + c, 1);
                     c++;
                     found++;
                }

Now could it be that this works for 99% of the streams but not 100% ?

From http://www.linuxdvb.tv/mailarchive/msg04156.html

Der Player beachtet die Timecodes der Pakete und sorgt dafür, daß sie
zum richtigen Zeitpunkt wiedergegeben werden.
Wenn eins fehlt, wird das alte Paket nochmal wiedergegeben (bzw. Bild
nochmal angezeigt), wenn eins zuviel ist, wird es verworfen.

[quick translation: the player looks at the timecodes [PTS i guess] and 
makes sure they are played back at the right point in time. If one is 
missing packet (or more so picture) will be repeated, if there's one too 
much it's discarded]

Now this sounds very familiar to what I'm seeing in the b0rked stream.

I guess the way to test would be to implement that pts handling, but I'm 
not quite sure where that array is defined. Experts: Would you rule it out 
as cause or is this definitely something I should be going after?

I was looking at 
http://www.linuxtv.org/mailinglists/linux-dvb/2001/08-2001/msg00583.html 
and there it said something how the firmware also deals with PTS but can't 
always make up for it if it's set wrong? Could this also explain the RTL 
problem etc. - possibly going a bit too far here, I thought I had read 
people managed to get those streams working with dvbstream / tuxzap and the 
new firmware but not vdr?

- Gregor 


--
Info:
To unsubscribe send a mail to listar@linuxtv.org with "unsubscribe vdr" as subject.