[mythtv] Re:What is the recordedmarkup table for?

[Chris Pinkham]

> > 6 = offset of mpeg2 gop
> > 7 = offset of rtjpeg/mpeg4 keyframe
> 
> > If you look at how the ProgramInfo::SetPositionMap function is
> > used, then you should be able to easily update the recordedmarkup table

> I guess my question is what are the type '6' and '7' records used for? 

The 6 records mark the file offset of every GOP in the file.  This is the
main method for allowing mpeg2 recordings to skip forward/backward quickly
since they have no internal seektable.

The 7 records were added recently to do the same thing for rtjpeg/mpeg4
recordings.  This is stored in addition to the seektable that gets written
to the recorded file when the recording completes.  By storing the
keyframe offsets in the database, if a recorded file is ever damaged
or does not complete recording successfully, the "seektable" is still
available since there is this copy in the database.  Right now it is
mainly a workaround but should have other uses in the future.

> During 'raw' encodings, I can easily update the fileposition (well it's
> not that easy, but it can be done).  During full-transcoding (where I
> don't preserve the sync-frames), I'd need to delete all type '6' and '7'
> entries, and rebuild the table from scratch.  (Actually i would probably
> do it this way in both cases as I mention below).

This is why I mentioned looking at ProgramInfo::SetPositionMap.  If
you notice in both recorders the seektable/positionmap is stored in
a QMap during recording.  This QMap gets written to the recordedmarkup
table periodically during recording and at when the recording completes.

Going on the assumption that you are transcoding in order to get to a
smaller filesize, then you probably will never be transcoding to mpeg2
(if it's even possible with the current libraries).  Since you're
writing a mpeg4 file then you don't really need the 7 records in the
recordedmarkup table since your newly created file should have a seektable
in it already.  If you were encoding to mpeg2 you'd have to create the
GOP map in recordedmarkup since mpeg2 format files don't have the seektable
builtin.

> If the transcoder is using the cutlist, than I believe all the commercial
> and blank frame entries in recordedmarkup can be deleted (In fact,
> perhaps all entries for that program can be deleted).

This is correct since the blank frame numbers and commercial break start/end
frame numbers are no longer valid and you should have the seektable in your
newly transcoded file.  You might want to check the MARK_PROCESSING flag
before nuking the entries though just in case commercial flagging (or
any other future process that utilizes the MARK_PROCESSING flag) is not
working with the file.  The mythcommflag external commercial flagging
program checks this to make sure 2 instances don't try to flag the same
program at the same time.  You can check it by code similar to this:

if (program_info->CheckMarkupFlag(MARK_PROCESSING, db))
{
	// true so the file is in use by commercial skip or something else.
}

It would probably be good for the transcoding code to set and unset this
flag to prevent mythcommflag from trying to flag a program that is being
transcoded.  You can set it by using code like this:

program_info->SetMarkupFlag(MARK_PROCESSING, true, db);

and when you're done and want to unset,

program_info->SetMarkupFlag(MARK_PROCESSING, false, db);

> If the cutlist is
> not being used, then somehow the file-offsets need to be updated for all
> of these entries (which is not very easy to do, since we don't store the
> timestamp info, just the file offset)

Timestamps don't matter, the seektable is based upon frame numbers.  So
it translates a keyframe/GOP to a file offset.  Look at how the recorder
uses the positionmap variable and it might be a little clearer than how
I'm explaining it.

> This is further complicated by the fact that we don't want to modify the
> recordedmarkup table until the file is actually switched (the user could
> be watching the stream while we are transcoding it), which means that I
> either need to regenerate the info after the transcoding is done, when

Well, you don't want to touch the file really while someone is watching it.
Even though Linux will allow the user to keep watching the original file
if you overwrite with the new one, if they bookmark or edit the cutlist
things will get screwey if you are transcoding at the same time.

> need to understand what info needs to be preserved.  It may end up being
> beneficial to store the timestamps along with the file-offsets in
> recordedmarkup to make this process easier, but I don't think I need to
> do that, and I'd prefer not to if I don't have to.

You shouldn't need to when transcoding to mpeg4 or any format that has the
seektable in the file itself.

Chris