[mythtv-users] table recordedmarkup is very big

[Michael T. Dean]

On 09/25/06 10:58, Adam Egger wrote:

>On 9/17/06, Michael T. Dean <mtdean at thirdcontact.com> wrote:
>
>>No problem.  That's what allows you to seek instantaneously in MPEG-2
>>recordings.
>>
>But what's the reason for this seek table in mythtv, other video
>applications don't create gigantic tables just to be able to play back
>MPEG-2 recordings.
>

Notice, also, that in MythTV, while playing back variable bitrate MPEG-2 
(i.e. from a PVR-x50), if you seek forward 15 seconds, you move forward 
15 seconds; or if you seek forward 30 seconds, you move forward 30 
seconds; or if you seek forward 4 minutes, you move forward 4 minutes.  
Further examples may be interpolated and/or extrapolated from this pattern.

However, in xine, for example, when playing back the same video, if you 
press SeekRelative+15 (by default mapped to Ctrl+Right), you sometimes 
jump forward 15 seconds, sometimes jump forward 3 seconds, sometimes 23 
seconds.  Unfortunately, extrapolating or interpolating from these 
examples is impossible (because the behavior is only defined by the 
video itself and the specific location in the video at which the 
SeekRelative command was issued and, to some extent, to the amount of 
video past the current position that's been played back).  If you use 
SeekRelative+7, it's even worse--sometimes you'll seek /backwards/ by a 
few seconds.  (MPlayer does the same type of approximation, but I don't 
use it, so I don't know the commands/keystrokes.)

Why doesn't xine's seek work with VBR MPEG-2?  Because there's no 
seeking information in MPEG-2, so xine does a "best guess" at 
approximating the location within the file where that position within 
the video should exist.  However, best guess isn't good enough for 
Myth--since people complain about things like having a table whose 
pupose they don't understand, imagine how often we'd get complaints if 
seeking worked like it does in xine.  ;)  So, Myth does it right--it 
builds up a seek table (while recording, but can be rebuilt later using 
mythcommflag) that can be used "to seek instantaneously [and exactly] in 
MPEG-2 recordings [played back by MythTV]."

You may have noticed that when editing these videos in avidemux2, it 
builds an index before allowing you to open the video.  That index 
serves the same purpose as MythTV's seek table.

OK, so if (as I mentioned before--possibly in other threads), the 
seektable won't exist for transcoded recordings or recordings made with 
frame grabbers (i.e. like the BTTV cards), why don't we have seeking 
problems with them?  Because Isaac was smart enough to choose a 
container for any video "recorded" by MythTV (includes recording by 
transcoding) that's much more appropriate for a PVR than MPEG System 
stream--the NuppelVideo container.  NuppelVideo contains seeking 
information within the file.

Oh, and lastly, I /really/ think you need to modify your definition of a 
"gigantic table."  The recordedseek table in my database is 53,767,248 
bytes (with an index of 42,945,536 bytes) with 138 VBR MPEG-2 recordings 
totaling 6 days 14 hrs 21 mins of video.  That 50MB of seek table plus 
40MB of index (rounded up to 95MB) is still less than 5 minutes of video 
using the extremely low-bitrate (=low quality recordings) I'm using (my 
recordings are about 1.15GiB/hr of recorded video).

Mike