[mythtv-users] comm flagging hdpvr file while recording results in errors

[Jim Stichnoth]

On Tue, Mar 2, 2010 at 12:37 PM, sp <analogue at yahoo.com> wrote:
> My backend is able to comm flag HDPVR recordings while they are still recording but it seems like the comm flagging routine is not as accurate compared to doing the comm flagging after the recording has finished. My backend it able to comm flag at a rate faster than the file is recorded (720p HDPVR recording is 60fps but the comments in the jobqueue table indicate that comm flagging fps is faster -- "84% Completed @ 61.2766 fps")  This results in multiple errors spewed in the mythbackend log:
>
> 2010-03-02 14:22:21.543 AFD Error: Unknown decoding error
> 2010-03-02 14:22:22.604 [h264 @ 0x5636e0]B picture before any references, skipping
> 2010-03-02 14:22:22.605 [h264 @ 0x5636e0]decode_slice_header error
> 2010-03-02 14:22:22.605 [h264 @ 0x5636e0]no frame!
> 2010-03-02 14:22:22.606 AFD Error: Unknown decoding error
> 2010-03-02 14:22:22.606 [h264 @ 0x5636e0]B picture before any references, skipping
> 2010-03-02 14:22:22.607 [h264 @ 0x5636e0]decode_slice_header error
> 2010-03-02 14:22:22.607 [h264 @ 0x5636e0]no frame!
>
> I've verified the errors are in fact generated by the mythcommflag process by sending a SIGSTOP signal (errors cease to show up in log) and then a SIGCONT signal (errors start spewing again).  Is this a known issue? Is there some way to throttle the speed of the comm flagger so it does not continually run into these problems?

I took a look at the code and I'm inclined to agree with your theory.
By the way, how do you judge the quality difference between real-time
and delayed commflagging?

Those errors in the log seem to show up especially when skipping
around in the file.  I see them in the playback logs when skipping
forward or backward.  I see them in the logo detection phase of
commflagging (regardless of whether it is real-time or delayed), where
one frame out of every two seconds is sampled.  And it looks like
you're seeing them in the commercial detection phase when it catches
up to real-time.  Maybe these errors are because of dependencies on
future frames?  I don't know.

In any case, it would be easy enough to modify the end of
ClassicCommDetector::go() to make sure the commercial detection phase
stays at least 30 seconds behind the recording, which should get rid
of the errors after the logo detection completes.  Are you in a
position to test a patch?

Jim