[mythtv-users] I'd like to find out more about the recordedmarkup table and MARK_GOP_START

[Michael T. Dean]

On 06/06/2006 10:30 PM, Richard Bronosky wrote:

>On 6/6/06, Michael T. Dean <mtdean at thirdcontact.com> wrote:
>  
>
>>Actually, if you're recording MPEG-2 streams (i.e. from a PVR-x50/500),
>>you'll write around 2 records per second into the recordedmarkup table.
>>That table is used to store the "seektable" information, which includes
>>every keyframe in MPEG-2 videos, where PVR-x50's generally use one
>>keyframe per group of 15 pictures.
>>    
>>
>
>I think I'm starting to understand this.  The type 6, or
>MARK_GOP_START, entries in the recordedmarkup table indicate the frame
>offset of the keyframe of a group or pictures.
>

Exactly.

>  (since Hauppage card
>use a GOP size of 15, and NTSC is 29.97f/s that's about 3 inserts per
>minute.)
>  
>

Confusing units?  Assuming 15 frames/GOP and 30 frames/second (for easy 
math), that's 2 GOP starts per second, meaning 120 per minute = 7200 per 
hour.

Note, though, that you can change the number of frames/GOP with ivtvctl 
("-c"/"--set-codec-params" option).

Preface the rest of the response with AIUI...

Larger GOP size should result in lower quality for scenes with a lot of 
movement.  Smaller GOP size would result in larger files (less 
compression) assuming bitrate were allowed to grow.  Since we specify 
bitrate, a smaller GOP size would mean we have fewer "quality" bits 
available (because more bits are being used for I-frames--which take the 
most space), so quality can actually decrease.  You would have to 
specify a larger bitrate to get better quality from smaller GOP's.  The 
most-commonly used sizes are 15 and 12 frames.

>Is the "seektable information" the mysql table, or is it actually meta
>data in the recording file?
>  
>

It's in the MySQL table called recordedmarkup, but so is other 
information.  That being said, the information can be derived from 
reading the MPEG stream, so you could say the information is "in the 
recording file; however, it has not yet been coalesced into a 
"seektable":  the information is spread throughout the entire 
recording.  However, by deriving the information before it's necessary, 
skipping/jumping (a.k.a. seeking) can be made much faster (thus, 
"seektable").

I think someone (Stuart?) is working on pulling the seektable 
information out of recordedmarkup or pulling the other information out 
of recordedmarkup so that we'll have a table with just the seektable 
information and a table with just the other information (markup like 
bookmarks, commercial flagging information, etc.).

>I originally understood that the seektable was in the recording.  I
>was confused as to where MythTV had to add that info to the recording,
>or if my Hauppage did that for me.
>  
>

Actually, the information is pulled from the recording (i.e. from frame 
types I, P, and B--which are generated by the PVR-x50 according to the 
structure specified using ivtvctl) by Myth and stored in the database to 
allow for fast seeking.

Mike