[mythtv-users] commercial skipping recorded shows

[Bruce Markey]

Isaac Richards wrote:
> On Friday 09 May 2003 06:49 am, Bruce Markey wrote:
> 
>>While Isaac is correct about decoding hardware encoding,
>>what you describe is consistent with the lack of a "seektable".
>>This is used for rapid navigation around the file but is
>>appended to the end of the file when the recording finishes.
>>Until the seektable is written, playback needs to search
>>through the file without this road map.
>>
>>So, if you record a show from 8:00 until 9:00 and start watching
>>it at 8:30, any seeks (commercial skips, ff/rew, jumps, etc.)
>>will all be slow and commercial skips on a remote frontend are
>>no fun at all. You can't Save Position even if it says so on
>>screen and edit mode doesn't even try to pretend it might work.
>>
>>However, if you exit playback at 9:01 then start watching it
>>again, all these features work correctly and your commercial
>>skips will be instantaneous.
>>
>>So it's not the fact that you are watching the recording in
>>progress that's slowing things down, it's the fact that the
>>recording hasn't finished.
> 
> 
> That's pretty much completely false.

A-ha! Not completely false ;-). I apologize If I misrepresented
the specific causes and effects but each of the things I mentioned
are adversely affected by the lack of a seektable when watching
a recording in progress rather than watching a recording after
it has finished and the seektable has been written.

Edit mode is disable if haspositionmap is false. If I go into
a recording in progress or a file leftover from the backend
crash, there is no edit mode. After a file finishes correctly
the edit mode works.

Save position during a recording in progress does write a value
into "bookmark" in the recorded table. However, if I exit and
restart playback while the recording is in progress, playback
starts from the beginning. If I wait until the recording finishes
then restart playback, it starts from the bookmark position.

Seeking from a remote frontend can be conspicuously slower
during a recording in progress. The longer the seek, the
longer the wait. After the seek table has been written, seeks
of any distance are reasonably quick.

> ... The recorder (with both software and 
> hardware encoding) builds the seek table as the program is being recorded 
> (and with live tv).  The player, if requested to seek to a portion of the 
> program it hasn't seen itself yet simply queries the recorder for the proper 
> position to seek to.  It's only slightly slower than seeking around after the 
> recording has finished.

The problem is that the sequential requests for each keyframe
can be painfully slow. To demonstrate, I started a recording
on a backend across a 10Mb network and printed the transactions
with time stamps. I waited until it had recorded for more than
ten minutes so I cound time a ten minute jump.

[Hit "Page Up" to jump forward 10 minutes]
14:55:27 50      QUERY_FILETRANSFER 21[]:[]REQUEST_BLOCK[]:[]128000
14:55:27 50      QUERY_FILETRANSFER 21[]:[]REQUEST_BLOCK[]:[]128000
14:55:27 39      QUERY_RECORDER 1[]:[]GET_FRAMES_WRITTEN
14:55:28 50      QUERY_FILETRANSFER 21[]:[]REQUEST_BLOCK[]:[]128000
14:55:28 39      QUERY_RECORDER 1[]:[]GET_FRAMES_WRITTEN
14:55:28 49      QUERY_RECORDER 1[]:[]GET_KEYFRAME_POS[]:[]0[]:[]6
14:55:28 49      QUERY_RECORDER 1[]:[]GET_KEYFRAME_POS[]:[]0[]:[]7
14:55:28 49      QUERY_RECORDER 1[]:[]GET_KEYFRAME_POS[]:[]0[]:[]8
...(36 seconds later)...
14:56:04 51      QUERY_RECORDER 1[]:[]GET_KEYFRAME_POS[]:[]0[]:[]603
14:56:04 51      QUERY_RECORDER 1[]:[]GET_KEYFRAME_POS[]:[]0[]:[]604
14:56:05 51      QUERY_RECORDER 1[]:[]GET_KEYFRAME_POS[]:[]0[]:[]605
14:56:05 31      QUERY_FILETRANSFER 21[]:[]PAUSE
14:56:05 74      QUERY_FILETRANSFER 21[]:[]SEEK[]:[]0[]:[]202468455[]:[]1[]:[]0[]:[]2436550
14:56:05 50      QUERY_FILETRANSFER 21[]:[]REQUEST_BLOCK[]:[]128000
14:56:05 50      QUERY_FILETRANSFER 21[]:[]REQUEST_BLOCK[]:[]128000

The same 10 minute jump from the beginning when starting playback
two minutes after the the show finished recording.

[Hit "Page Up" to jump forward 10 minutes]
15:02:54 50      QUERY_FILETRANSFER 17[]:[]REQUEST_BLOCK[]:[]128000
15:02:55 50      QUERY_FILETRANSFER 17[]:[]REQUEST_BLOCK[]:[]128000
15:02:55 50      QUERY_FILETRANSFER 17[]:[]REQUEST_BLOCK[]:[]128000
15:02:56 31      QUERY_FILETRANSFER 17[]:[]PAUSE
15:02:56 74      QUERY_FILETRANSFER 17[]:[]SEEK[]:[]0[]:[]202433477[]:[]1[]:[]0[]:[]2813748
15:02:56 48      QUERY_FILETRANSFER 17[]:[]REQUEST_BLOCK[]:[]2048
15:02:56 50      QUERY_FILETRANSFER 17[]:[]REQUEST_BLOCK[]:[]128000
15:02:56 50      QUERY_FILETRANSFER 17[]:[]REQUEST_BLOCK[]:[]128000


I'm sure you'll agree that 37 seconds vs. less than 2 seconds is
more than "only slightly slower" =). However, this could probably
be improved. It looks like NuppelDecoder::DoFastForward() has a
loop requesting GetKeyframePosition(i) to fill in the position
map one item at a time. Therefore, the RemoteEncoder function
requests these one at a time. Perhaps a function could request
an array of keyframes. DoFastForward already knows the range
of numbers it needs so maybe they could all be sent in a single
network transaction. Then it would be only slightly slower.

--  bjm