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

[Chris Pinkham]

* On Fri Mar 12, 2010 at 02:26:11AM -0800, Yeechang Lee wrote:
> Chris Pinkham <cpinkham at bc2va.org> says:
> > After thinking about this, I think we'd end up being slower, since I
> > assume the norm would be that the commercials would be at a higher
> > FPS than normal in this case (ie, 29.97 commercials, 24 movie, or
> > similar).  So, I think we'd end up being behind more than the 30
> > seconds desired.
> 
> But isn't that what is desired in this situation? The issue seems to
> be that sometimes the realtime commflagging gets too "fast," gets too
> close to the end of the ongoing recording, and thus errors. Hopefully
> setting the current 30-seconds delay to a slightly larger figure would
> avoid this.

Maybe I didn't word that well enough.  I was trying to say that I think
that we'd be more than 30 seconds behind if the commercials are at a
faster FPS than the show because we'd ~realtime process the commercials
at the slower show FPS which would cause use to slowly drive more
and more behind realtime (which is what you guys are talking about
doing by setting the 30 to 45).  In other words, I don't see a need
to modify the code to handle that situation because odds are we're
always playing a clip where the show is at an equal or lower FPS than
the commercials are at.

I don't know how often this occurs out in the wild, it may occur more
on HD cable.  I don't think I've ever seen it in any broadcasts I record.
But..  Here's an example using 24 FPS show and 29.97 FPS commercials ignoring
any delay caused by logo detection:

The show runs from 00:00:00 to 00:05:00, commercials from 05:01 to 07:00 and
show from 07:01 to 09:59.  The flagger tries to run at 24 FPS since it
wants to stay 30 seconds behind realtime and the only FPS it knows about
is the primary FPS at the start of the recording.  Now, I just thought
of something else that might affect this.  If the recording starts on a
commercial, and does have mixed FPS, we are really messed up because
we assume the whole video is at the faster FPS.  I'll come back to that
later.

               Frame Counts
Timestamp   Recorded  Flagged
---------   --------  --------
00:00:00        0         0
00:00:30      720         0
00:00:31      744        24  
00:00:32      768        48   
...
00:05:00     7200      6480   < recording FPS shifts here, but flagging
...                             FPS stays at 24
00:05:30     8099.10   7200   < now flagger is actually 37.462 seconds
...                             behind at 24 flagging FPS
00:06:00     8998.20   7920   < now flagger is 44.925 seconds behind
...                             at 24 flagging FPS
00:07:00    10796.40   9360   < now flagger is 59.85 seconds behind at 24
...                             flagging FPS, recording FPS goes back to 24
00:07:30    11516.40  10080   < flagger is still 59.85 seconds behind
...
00:08:00    12236.40  10800   < flagger is still 59.85 seconds behind
...

In this example, the flagger doesn't know that the commercials have a
higher FPS, so it assumes that only 24 FPS are being recorded.  Since
the recorder is recording more FPS during the commercials, this makes
the flagger gradually fall more and more behind for every second of
commercial that is recorded.  When the show comes back on, the flagger
maintains it's position, but it falls further behind the next time
a higher-FPS commercial comes on.

Now, the case I mentiond above that I said I'd get back to...

Consider the case where we start recording in the middle of one of these
higher FPS commercials and the actual show is at a slower FPS.  The
flagger would happilly run along at 29.97 FPS and would catch up to
the recorder in only a few minutes of actual show being recorded if the
show is recording at a slower 24 FPS.  We need to store (at record time)
the primary FPS of the video, then the flagger could use this info
if it was available (ie, after the start delay which accounts for
preroll and the logo detection buffer).  I have something I plan on
working on after 0.23 that will let us store multiple files per
recording (ie, a high-def version, a transcoded SD version, and maybe
a transcoded .mp4 version for your iPod), all tracked by Myth.  This
would also include the DB table to put the info about the file, so
we know that HD file is 1920x1080, the transcoded version is only
640x360 and the iPod version is 480x270.  We could also store the
FPS of each, bitrate, etc..

--
Chris