Progress bar display shows excessive times for radio programmes (no video).
A recording of about 5 minutes starts at 5:22:13 and ends at 27404:47:54. The actual recording is fine. Recording is from BBC Radio 3 using DVB-T. ffmpeg -i shows:
Input #0, mpegts, from '00001.ts': Duration: 00:05:06.12, start: 38666.622211, bitrate: 225 kb/s Program 132 Stream #0.0[0x1b6](eng): Audio: mp2, 48000 Hz, stereo, s16, 192 kb/s
I see the same playing with dvbhddevice or xineliboutput.
Recordings made with previous versions of vdr (including 1.7.19 with suggested reversion to 1.7.18 recording code) display correct times playing with 1.7.20.
Chris
On 27.08.2011 15:35, Chris Mayo wrote:
Progress bar display shows excessive times for radio programmes (no video).
A recording of about 5 minutes starts at 5:22:13 and ends at 27404:47:54. The actual recording is fine. Recording is from BBC Radio 3 using DVB-T. ffmpeg -i shows:
Input #0, mpegts, from '00001.ts': Duration: 00:05:06.12, start: 38666.622211, bitrate: 225 kb/s Program 132 Stream #0.0[0x1b6](eng): Audio: mp2, 48000 Hz, stereo, s16, 192 kb/s
I see the same playing with dvbhddevice or xineliboutput.
Recordings made with previous versions of vdr (including 1.7.19 with suggested reversion to 1.7.18 recording code) display correct times playing with 1.7.20.
Please try this patch:
--- remux.c 2011/08/20 09:07:26 2.59 +++ remux.c 2011/08/27 14:20:18 @@ -840,7 +840,7 @@ return Processed; // flush everything before this new payload if (framesPerSecond <= 0.0) { // frame rate unknown, so collect a sequence of PTS values: - if (numPtsValues < MaxPtsValues && numIFrames < 2) { // collect a sequence containing at least two I-frames + if (numPtsValues < 2 || numPtsValues < MaxPtsValues && numIFrames < 2) { // collect a sequence containing at least two I-frames const uchar *Pes = Data + TsPayloadOffset(Data); if (numIFrames && PesHasPts(Pes)) { ptsValues[numPtsValues] = PesGetPts(Pes);
Apparently it got only a single PTS value and then was unable to calculate a difference. This patch fixed it for me (on the German radio channel ANTENNE BAYERN, which also showed the effect you reported).
Klaus
On 27/08/11 15:24, Klaus Schmidinger wrote:
On 27.08.2011 15:35, Chris Mayo wrote:
Progress bar display shows excessive times for radio programmes (no video).
A recording of about 5 minutes starts at 5:22:13 and ends at 27404:47:54. The actual recording is fine. Recording is from BBC Radio 3 using DVB-T. ffmpeg -i shows:
Input #0, mpegts, from '00001.ts': Duration: 00:05:06.12, start: 38666.622211, bitrate: 225 kb/s Program 132 Stream #0.0[0x1b6](eng): Audio: mp2, 48000 Hz, stereo, s16, 192 kb/s
I see the same playing with dvbhddevice or xineliboutput.
Recordings made with previous versions of vdr (including 1.7.19 with suggested reversion to 1.7.18 recording code) display correct times playing with 1.7.20.
Please try this patch:
--- remux.c 2011/08/20 09:07:26 2.59 +++ remux.c 2011/08/27 14:20:18 @@ -840,7 +840,7 @@ return Processed; // flush everything before this new payload if (framesPerSecond <= 0.0) { // frame rate unknown, so collect a sequence of PTS values:
if (numPtsValues < MaxPtsValues && numIFrames < 2){ // collect a sequence containing at least two I-frames
if (numPtsValues < 2 || numPtsValues < MaxPtsValues&& numIFrames < 2) { // collect a sequence containing at least two I-frames const uchar *Pes = Data + TsPayloadOffset(Data); if (numIFrames && PesHasPts(Pes)) { ptsValues[numPtsValues] = PesGetPts(Pes);
Apparently it got only a single PTS value and then was unable to calculate a difference. This patch fixed it for me (on the German radio channel ANTENNE BAYERN, which also showed the effect you reported).
Klaus
That's fixed it for me too. Many thanks.
Chris
-
Chris Mayo -
Klaus Schmidinger