I have noticed a potential bug in playing back radio channels. The playback time of recorded radio channels is inflated by almost 40%. This has been confirmed on four North American satellites on three different providers. The reported time for a 10 minute recording will consistently appear as 13:47. Some have hypothesized the problem comes from the fact that vdr's timers are based on video frame rates, which of course don't exist on radio channels.
World Radio Network (wrn.org) is one example, and is broadcast on satellite worldwide, so perhaps this can be confirmed on other sats outside NA. The timing problem makes it very difficult to skip commercials or "top of the hour" news reports or to skip between programming that occurs, for example, every 30 minutes. In America, I have made observations on Telstar5. In Europe, you can try Sky Digital (Eurobird 1, 28.5E) or Eutelsat Hotbird 6 (13E) or Afristar (paytv).
Additionally, there appears to be a problem that some have reported with certain NA provider varying the video frame rate, causing *underreporting* of playback time, which would seem to confirm this hypothesis.
Hi,
Patrick Mackin wrote:
I have noticed a potential bug in playing back radio channels. The playback time of recorded radio channels is inflated by almost 40%. This has been confirmed on four North American satellites on three different providers. The reported time for a 10 minute recording will consistently appear as 13:47. Some have hypothesized the problem comes from the fact that vdr's timers are based on video frame rates, which of course don't exist on radio channels.
World Radio Network (wrn.org http://www.org) is one example, and is broadcast on satellite worldwide, so perhaps this can be confirmed on other sats outside NA. The timing problem makes it very difficult to skip commercials or "top of the hour" news reports or to skip between programming that occurs, for example, every 30 minutes. In America, I have made observations on Telstar5. In Europe, you can try Sky Digital (Eurobird 1, 28.5E) or Eutelsat Hotbird 6 (13E) or Afristar (paytv).
Additionally, there appears to be a problem that some have reported with certain NA provider varying the video frame rate, causing *underreporting* of playback time, which would seem to confirm this hypothesis.
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.
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.
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.
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 ;-)
Bye.
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.
Hi,
Patrick Mackin wrote:
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.
I'd like to have a look at such recordings. Can you provide me some URLs?
Regarding HDTV: I'm currently experimenting with H.264 coded 1080i streams and what I've found so far is that the encoder may choose on the fly whether to use a single frame or two fields for a picture. But it looks like I've found a way (at least for this single stream) which will suit to VDR's way of determining playback times.
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 found this code in my vdr-xine plugin to determine the duration of an audio frame in PTS (90000 PTS == 1 second):
static int samplingFrequencies[ 2 ][ 4 ] = // all values are specified in Hz { { 44100, 48000, 32000, -1 }, // MPEG 1 { 22050, 24000, 16000, -1 } // MPEG 2 };
static int slots_per_frame[ 2 ][ 3 ] = { { 12, 144, 144 }, // MPEG 1, Layer I, II, III { 12, 144, 72 } // MPEG 2, Layer I, II, III };
int mpegIndex = 1 - id; int layerIndex = 3 - layer;
// Layer I (i. e., layerIndex == 0) has a larger slot size int slotSize = (layerIndex == 0) ? 4 : 1; // bytes
int sf = samplingFrequencies[ mpegIndex ][ sampling_frequency ];
return 90000.0 * 8 * slotSize * slots_per_frame[ mpegIndex ][ layerIndex ] / sf;
In the case of MPEG 1 Layer II, there is only "sf" which varies with the sampling frequency (sampling_frequency is a 2 bit field in the audio frame's header). But as there is no dependency on bitrate_index (a 4 bit field in the audio frame's header), I was simply wrong :-(
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.
Well my idea is to simply accumulate the above calculated frame durations and whenever the result exceeds a multiple of 40 ms (for 25 frames per second), an index entry is generated. To be more precise the PTS of the audio PES packets needs to be considered too but that's a little bit too complicated to explain.
Bye.
-
Patrick Mackin -
Reinhard Nissl