[mythtv-commits] Ticket #12031: mythcommflag needs to handle streams where the frame rate changes

[MythTV]

#12031: mythcommflag needs to handle streams where the frame rate changes
---------------------------------------+------------------------
     Reporter:  brian@…                |      Owner:  cpinkham
         Type:  Bug Report - General   |     Status:  new
     Priority:  minor                  |  Milestone:  unknown
    Component:  MythTV - Mythcommflag  |    Version:  0.27-fixes
     Severity:  medium                 |   Keywords:
Ticket locked:  0                      |
---------------------------------------+------------------------
 Per the repeated complaints of inaccurate commflagging on the mythtv-users
 mailing list I dug in this weekend to see if I could figure out what was
 going wrong.  My observations have been since I changed from recording
 from analog encoder cards (i.e. Hauppage PVR-* cards) to capturing digital
 streams from clearqam that accuracy of commercial flagging has suffered.

 Moreover since I still do have a couple of these encoding cards but they
 record at the lowest priority (i.e. so most infrequently) I believe that
 commercial flagging on recordings recorded from them is still superior in
 accuracy compared to clearqam streams.

 I had feared that this was a problem with ffmpeg not properly dealing with
 these already encrypted streams and missing "blank" frames, etc.
 Fortunately my suspicions were incorrect and blank frames are being found
 quite accurately.

 But my suspicious were correct about this inaccuracy problem being with
 capturing upstream-encrypted streams, just not for the reason I originally
 suspected.  The problem seems to be that mythcommflag is assuming constant
 frame rate streams when what you get from clearqam is anything but.  There
 seems to be quite a bit of switching between 24000/1001 and 30000/1001.
 Because the stream will usually be detected at 30000/1001 when that rate
 is applied to a commercial that is actually 24000/1001 of course the run-
 time of it is inaccurate and it fails to match one of the pre-defined run-
 lengths for commercials and thus fails to be detected as a commercial.

 What's worse is that I believe I've even seen single commercials where the
 frame rate changes in the commercial.  I had one that when measured by the
 wall-clock was bang on 30s but when frame count of it was divided by
 30000/1001 it was under 30s (~27s) and when divided by 24000/1001 it was
 over 30s (~32s).

 So, I think what needs to happen is that the frame rate of every frame
 needs to be available to mythcommflag so that it's (the frame's) real run
 time can be added to the commercial run length to arrive at an accurate
 total run time for the commercial.

 I was hoping I could have hacked this up this weekend but I could not find
 a source of frame rate per frame within the context of the mythcommflag
 processing.  Unfortunately frame->frame_rate in
 ClassicCommDetector::ProcessFrame() has every frame with a rate of "-1"
 there.

 At that point I was out of the depth of hacking I could get into for a
 day.

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