[mythtv-commits] Ticket #13332: Some recordings put MythPlayer in a bad state where timestamp is wrong

MythTV noreply at mythtv.org
Thu Oct 11 09:04:35 UTC 2018


#13332: Some recordings put MythPlayer in a bad state where timestamp is wrong
--------------------------------------+--------------------------
     Reporter:  ggervasio             |      Owner:  (none)
         Type:  Bug Report - General  |     Status:  new
     Priority:  minor                 |  Milestone:  needs_triage
    Component:  MythTV - General      |    Version:  Unspecified
     Severity:  medium                |   Keywords:
Ticket locked:  0                     |
--------------------------------------+--------------------------
 I have been using master and starting a few months ago, some recordings
 seem to have a few bad frames(?) that cause MythPlayer to get into a state
 where, among other things:

 - video constantly stutters as if frames are skipped (audio is fine and in
 sync)
 - player timestamp runs at half the correct rate (ie. timestamp OSD
 increments 1 second for every 2 seconds played).  This causes seeks and
 bookmarks to behave incorrectly.  Saving a bookmark at 10 minutes after
 the bad frame places it at 5 minutes after (which is what the timestamp
 shows).

 It doesn't recover from this state.  Exiting and restarting the player
 works fine until it hits another "bad frame".

 So far, I have only noticed this behavior on some (not all) recordings of
 the local NBC affiliate (KNTV in the SF Bay Area) which broadcasts in
 1080i MPEG-2.

 I was able to find a recording where the problem happens almost from the
 start.  The first 500MB and a log of "mythavtest -v
 playback,libav,timestamp" (based on git:
 3d6f3e2e475322b462ac14cf9f0ca14a8e52aab8) have been uploaded here:

 https://filebin.net/tzd83eg4fj5xrc99

 I'm guessing this is where it goes wrong --
 MythPlayer::SetFrameRate/SetFrameInterval is called to double the frame
 rate when there's a frame interval that's only 16ms (5381872 -> 5381888):
 {{{
 2018-10-10 23:30:37.673077 I  AFD: video timecode 484368500 5381872
 5381872 5381838

 2018-10-10 23:30:37.699914 I  Player(0): A/V timecodes audio 5380994 video
 5380904 frameinterval 33367 avdel -7 avg -1113 tcoffset 0 avp 0 avpen 0
 avdc -84334 diverge -0.0333563

 2018-10-10 23:30:37.708173 I  Player(0): SetFrameInterval ps:1 scan:3
 2018-10-10 23:30:37.708181 I  AFD: video timecode 484370001 5381888
 5381888 5381872

 2018-10-10 23:30:37.732172 I  Player(0): A/V timecodes audio 5381027 video
 5380937 frameinterval 16683 avdel -8 avg -2251 tcoffset 0 avp 0 avpen 1
 avdc -83240 diverge -0.0674619
 }}}

 I think this is the relevant section of
 AvFormatDecoder::ProcessVideoFrame:
 {{{
     // Calculate actual fps from the pts values.
     long long ptsdiff = temppts - lastvpts;
     double calcfps = 1000.0 / ptsdiff;
     if (calcfps < 121.0 && calcfps > 3.0)
     {
         // If fps has doubled due to frame-doubling deinterlace
         // Set fps to double value.
         double fpschange = calcfps / fps;
         int prior = fpsMultiplier;
         if (fpschange > 1.9 && fpschange < 2.1)
             fpsMultiplier = 2;
         if (fpschange > 0.4 && fpschange < 0.6)
             fpsMultiplier = 1;
         if (fpsMultiplier != prior)
             m_parent->SetFrameRate(fps);
     }
 }}}

 If I comment out this section, the problem goes away.

-- 
Ticket URL: <https://code.mythtv.org/trac/ticket/13332>
MythTV <http://www.mythtv.org>
MythTV Media Center


More information about the mythtv-commits mailing list