id summary reporter owner description type status priority milestone component version severity resolution keywords cc mlocked 12031 mythcommflag needs to handle streams where the frame rate changes brian@… cpinkham "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." Bug Report - General closed minor unknown MythTV - Mythcommflag 0.27-fixes medium Unverified 0