[mythtv] What is the recordedmarkup table for?
ou401cru02 at sneakemail.com
Wed Jun 11 11:51:26 EDT 2003
On Wed, 11 Jun 2003, "Chris Pinkham cpinkham-at-bc2va.org
|mythtv/1.0-Allow|" <nc8phcq8iz0t at sneakemail.com> said:
>> 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.
> 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
Okay, this is what I was missing. i didn't know about the mpeg2
limitiation, and didn't understand the mpeg4/rtjpeg reason. I am not
sure it is valid to say we'd never transcode to mpeg2. The only reason I
can think of why you'd want to is to make it possible to write DVDs (and
I don't think we have an MPEG2 encoder in myth today).
> 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:
Well this is a good point. It all depends on whether the transcoder is
processing cutlists or not. If we are, we should delay the transcoder
while the commercial-checker is running (or the program is being viewed),
and nuke it whenever the user modifies the commercial-table in a fle
we're currently transcoding. It'll get a bit messy, but seems necessary.
>> 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.
Yes I agree. I had originally thought it wouldn't matter if we weren't
using the uctlist while transcoding, but since I need to modify the
offsets it is still an issue if they change while transcoding. I still
can't directly modify the recordedmarkup file, since if the user decides
to start watching a program we are in the middle of transcoding (or the
transcoding fails), we end up with a corrupted recordedmarkup.
So my proposal is:
All changes to the recordedmarkup will occur in a seperate table. this
table will replace the program data in recordedmarkup when the file
replaces the original .nuv
If transcoding to mpeg4/rtjpeg, we will not retain the type '7' fields,
as we gaurantee that a successful transcode writes a 'Q' frame.
If transcoding is to mpeg2, we will probably do nothing (as it isn't
possible to do this now anyhow), but in this case, we would create the
necessary type '6' records.
The transcoder will not be allowed to start if the commerical code is
running or the video is being watched.
If the user starts watching the video while the transcoder is running,
and the user does any commercial flagging, the transcoder will be nuked
and will restart when the program is no longer being watched.
During transcoding whne not using the cutlist, all entries in the
recordedmarkup of types 3-5 will be added to the new table with their
Does this sound reasonable?
More information about the mythtv-dev