mythcommflag needs to handle streams where the frame rate changes

[brian@…]

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.

[brian@…]

s/encrypted/encoded/g in the above.

No comment on the above, confirming or even denying my analysis?

[cpinkham]

Your analysis is correct, mythcommflag does not support variable frame rates. The initial frame rate is pulled in ClassicCommDetector::Init() in the 4th line down "fps = player->GetFrameRate?();". I don't believe we store the changing framerate information in the recordedmarkup table, so I think changing mythcommflag to support this will be a bit more invasive to allow it to handle knowing that frames X and Y are 30 seconds apart even if there is not a constant framerate during that 30 second period. Individual frame times will have to be considered and added up which may also make flagging slower unless the code is only used when variable framerates do occur. Unfortunately I do not have the time right now to undertake these changes. I too suffer from lack of "perfect skip" on a certain channels due to this issue. If someone wants to tackle making a patch, I'm happy to provide any insight I can.

[brian@…]

Ahhh. Really, super good to know my understanding of the problem is at least correct.

I'd imagine that the inaccuracies of mythcommflag relate equally well to any frame->time based operation, such as a "skip 30 seconds" operation (for example), yes?

If so, it seems that the first step to solving all of these problems is to make the frame rate flags in the recordmarkup table actually accurate. Would you agree or disagree with that statement/analysis?

[Jim Stichnoth]

Chris, as of #10104, the recorders produce both duration and file offset at each keyframe, adding MARK_DURATION_MS marks in the recordedseek table. This information should be available to the mythcommflag player, and there are methods to map frame number to duration and vice versa. Mythcommflag --rebuild also recomputes the duration marks. So all the information should be there, but I haven't looked any deeper into the commflagger's specific needs.

[Stuart Auchterlonie]

Closing all old tickets in trac.

If your issue still persists, please open an issue in Github ​https://github.com/MythTV/mythtv/issues

and reference the existing trac ticket.