VDR 1.7.20 - Incorrect Progress Bar Times for Radio Programmes
Commit Message
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:
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
Comments
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
@@ -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);