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

[Chris Pinkham]

(replying to both this and the parent email in context)

* On Tue Mar 02, 2010 at 10:05:14PM -0800, Jim Stichnoth wrote:
> 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:

The FPS calculation is based on the actual flagging start time.  This does
not include the time at the beginning where the flagger sits and waits for
the recorder to get far enough ahead where logo detection can be performed.
So, when the flagger actually starts flagging, it is now minutes behind
realtime.  This allows the flagger to run at a higher FPS then the
recording rate.  This allows the flagger to catch up to the recorder so
that it can finish as quickly as possible when the recording finishes.

>> 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!

The big questions are: 1) does this occur only during the logo detection
phase which means that the flagger is seeking around in the video, and 2) does
this also occur during normal playback and/or seeking.

>> 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 don't doubt the these come from the flagger, but if the flagger uses the same
decoder as normal playback (unless you're using hardware assisted decoding),
so if you get these during flagging, I'd expect them to occur under similar
circumstances during viewing of the recording.  By similar, I mean if they occur
during the logo detection phase which requires exact-frame seeking, then I'd
expect them to occur during viewing when seeking to exact frames.  If the
errors occur during the normal frame-by-frame processing in mythcommflag, then
I'd expect to see them during normal playback of the recording using the
software decoder.

The speed of the ~realtime flagger is already throttled so that it doesn't
catch up to the recorder.  If it did catch up to the recorder, it should get
an EOF and would stop flagging.

> 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?

The bottom of ::go() already has throttling code in it set to keep the
flagger 30 seconds behind the recorder.  This is based on actual time, so
the flagger will slow down if it detects that it is within 30 seconds of
realtime.  That's why I normally refer to the 'realtime' flagger as
~realtime since it's not quite realtime, it should be 30 seconds behind
as long as the recording is still in progress.  There could be a few
things causing it to run less than 30 seconds behind.  We want to stay
30 seconds behind, but the actual 30 second difference is converted to
a frame count, so if the frame rate in a file changes, that would mess
up our calculation.  It might also be possible if there are missed/corrupted
frames in the recording since we this 'stay behind 30 seconds' frame
count is based on the number of frames we've processed which may be be
equal to the frame number returned by the decoder.

--
Chris