[vdr] DVB-T appears to require PTS to demux (was: DVB-T based systems - does anyone have one that really is usable ?)

[Gregor Lawatscheck <gpel@mpex.net>]

At 20:09 12/05/2003, you wrote:
> At 19:25 12/05/2003, you wrote:
> > I doubt that it has something to do with EPG per se. The EPG scan just
> > happens to tune to all possible channels and is therefore more likely to
> > hit the bug. IMO it is a tuning bug - not a EPG problem.
> > By the way: reloading dvb-ttpci.o gets the card going again.
> Interesting. Yes, it appears to be a demux bug. I've looked at changes in 
> av7110* and saa7146* between old and newstruct and changes are very 
> minimal. Reworking them doesn't fix it.
Just to recap: I'm using a TT Budget DVB-T to feed a full featured Siemens 
DVB-s in transfer mode and get almost constant blank screens on various 
channels with new struct drivers. This bug has been confirmed by I believe 
up to 4-5 people in the UK with the same setup (notably people with dxr3 
don't have this problem).

I've done some more work on this and finally managed to make a recording of 
the "blank screen" - of about 15 seconds in length. Finally with a new 
driver and vdr 1.1.31 it wasn't zero-sized anymore and did actually contain 
data.

Trying playback with Mplayer yielded the same results as vdr trying to play 
it back: Sound for a second and then "hang". Looking at it with 
pvastrumento showed the first PTS (timestamp) to be at 4,5 seconds and gave 
a warning message about audio delay. After remuxing with pvsastrumento the 
stream now had the first PTS at the very beginning (10 ms or so) and played 
back fine in vdr. Now for the interesting bit: The second of audio that 
could be heard from the broken stream before it died was actually at 
posititon 4,5 seconds! Now this really narrows this specific "blank screen" 
bug down to PTS handling I think.

What we're seeing here seems like a "replay" issue (as transfer mode is 
kind of a live playback mode), so this wouldn't happen on full featured 
DVB-T cards. Some recorded streams might not play back on FF-cards though 
when the PTS is out by a couple of seconds (RTL problems comes back to 
mind?!). Somehow the old drivers don't have a problem dealing with this, 
newstruct appears to gets confused with channels sending PTS less 
regularly. It almost seems as if replay works if the channels in question 
happen to send a PTS at the right time, but not at other times, when they 
don't. It's not the firmware this time - I've tried almost every possible 
combintion with 10 firmware-versions from the past two years.

We've had a discussion about PTS about half a year ago when fixing the 
Channel 5 "oversized" TS stuff and it struck me as odd back then that vdr 
doesn't deal with PTS. Please see 
http://linvdr.org/mailinglists/vdr/2003/01/msg00717.html and 
http://www.linuxtv.org/mailinglists/vdr/2003/02-2003/msg00753.html for the 
discussions and more thoughts about PTS.

The line of argument back then was that it's not necessary as the PTS is 
just passed on in the PES stream and decoder deals with it. True, however 
it might be a good idea if vdr would "sync" on the first PTS it sees or 
like pvastrumento set one at the beginning of a stream. Setting and early 
PTS to the stream might also be important for things like subtitling 
plugins (I believe someone was working on it), vdr2divx / vdr2vcd 
or  avoiding artifacts at the beginning of the screen?

If anyone has ideas how to tackle this: I have the 15 sec capture of the 
stream that doesn't play back knocking about - it's 5,8 MB - if you'd like 
to have a look at it, let me know.

BTW: I've also toyed around with setting the PCR values for the channels in 
question received by dvbsak, those don't make a difference.

I hope we can get this sorted out :)

- Gregor 


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