[vdr] BUG: Incorrect playback times for radio channels

Patrick Mackin patrick.mackin at bakervaluation.com
Tue Mar 6 00:38:15 CET 2007


> VDR derives the playback times for a recording  by a hard coded
> relationship from the number of an index entry in the recording's index
> file (see recording.h, FRAMESPERSEC). The default relationship of 25
> frames per second doesn't suit to NTSC broadcasts with 30 frames per
> second, so VDR reports a larger playtime than the recording will
> actually play.

I should have also mentioned that I patched my vdr FRAMESPERSEC to 30 from 
25, and regular NTSC video recordings generally report the correct time, 
except for the problems I described earlier.

> Regarding radio recordings, the biggest problem is, that there is no
> video stream which would generate an index entry every 40 ms (for the
> default value of 25 frames per second). Since the introduction of my
> cAudioRepacker, things got even worse but more predictable: now every
> audio frame generates an index entry.

Unfortunately I don't have any ideas on how to fix the problem with every 
audio frame generating an index entry, and changing the method that vdr 
calculates the time of a recording would be a major undertaking.  I don't 
use HDTV at all, but from what I understand, something is "broken" there as 
well, that may require a substantial change in how vdr calculates the time 
of a recording.  Progressive video (ie 720p) uses twice the framerate of 
interlaced (standard NTSC or PAL) so this may be the source of the problem. 
Also, as I mentioned, some north american providers [SDTV] use a variable 
frame rate *during* playback of a small percentage of programming, which 
causes the reported time to be less than the actual recording time (by 
approximately 20% in my tests).  I would assume this is done for bandwidth 
optimization reasons.  I'm also guessing it is not allowed by dvb-s 
standards, and therefore may not be an issue that affects enough people for 
it to be worth fixing.

> But as the duration of an audio frame depends on bitrate, sample rate,
> and further audio stream parameters, it typically isn't 40 ms, but
> should be constant until the stream parameters change. That's why you
> get a consistent error for playback times of radio recordings.

What is interesting is that on 64kb, 96 kb and 128kb audio channels, the 
recording times were all basically identical.  But perhaps you are saying 
that only if a stream switches from say 64 to 96 kb *during* a recording 
would this affect the recording times.

> I've already thought about patching VDR that it determines FRAMESPERSEC
> dynamically by looking at the duration of the first frame of a
> recording, but I've dropped that idea as there are channels which
> provide more than one radio stream. So, to fix this issue I'd have to
> fix cRemux to not generate an index entry for every audio frame. I have
> an idea now how to achieve this -- don't know why it didn't come into my
> mind earlier already ;-)

My only idea would be to perhaps use vdr's internal clock for timing, as 
that would produce correct results regardless of the content recorded, but 
that would involve a substantial rewrite and may have some unforeseen 
disadvantages that I'm unaware of.  I don't quite understand the solution 
you mention here--you say you could fix cRemux to not generate an index 
entry for every audio frame (as currently audio frames are generated faster 
than every 40ms) but then what would the timer be based on?  I'm not 
familiar with how regular audio players interpret the time of a recording, 
but it would be interesting to see how audacity or an open source audio 
program would interpret the time of the very same recording vdr incorrectly 
interprets. 




More information about the vdr mailing list