LinuxTV Patchwork VDR 1.7.20 - Incorrect Progress Bar Times for Radio Programmes

login
register
mail settings
Submitter Klaus Schmidinger
Date Aug. 27, 2011, 2:24 p.m.
Message ID <4E58FE21.50600@tvdr.de>
Download mbox | patch
Permalink /patch/12902/
State New
Headers show

Comments

Klaus Schmidinger - Aug. 27, 2011, 2:24 p.m.
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
Chris Mayo - Aug. 27, 2011, 2:55 p.m.
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

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);

Privacy Policy