[mythtv] [PATCH] Mpeg Seeking

[Mike Wilcox]

Kenneth Aafloy wrote:

>Hi All,
>
>here's a patch which *should* fix most seeking problems in mpeg streams.
>  
>
After my earlier build faux-pas, I now have the patch applied, but with 
the dvb-alpha-0.4 version of dvbrecorder.

Seeking is *much* improved on playback & editting of recorded shows - 
certainly I don't see the kind of regular lock-up anymore - so thanks go 
to Kenneth for that fix - as well as to the rest of the work going on!

However, I do still have a couple of issues, but there nearer to 
nitpicking now :-)

1) REW during playback, at start of recording

When playing back (or editting), and I attempt to go backward in the 
stream into a *very* early frame, I get the error "Unknown seek 
position: 0". I then get the frame after the current one displayed.

This occurs at every "rewind" that takes me back to *close* to the 
beginning, or beyond the beginning - whether it is a 10 minute jump 
back, or while editting, a single frame back from the second key frame 
(in my test cases trying to step back from timecode 0:00:00.12 to 
0:00:00.11).

 From playing with the code in AvFormatDecoder::DoRewind() it seems to 
happen whenever the desired frame is one that requires the very first 
key frame in the file - where "keyPos" read from positionMap[] is a 
value of zero. If I comment out the test for "keyPos == 0" and the error 
output, to allow the ringbuffer to actually seek to position 0, 
everything goes right - I am perfectly able to get the first key frame, 
and the subsequent normal frames.

I surmise from this that it is actually valid to seek to position 0 - 
for a recording at least.

Is this test something that applies to analog handling, or is it a 
sentine value for protection against rewinding too far for live TV?

2) FF during editting, at end of file

I have seen some similar behaviour when editting at the end of a 
recording. In this case, it seems to be restricted to stepping on, in 
single-frame mode, from the last "normal" frame, where the systems 
actually jumps back to the previous key frame.

Haven't had a chance to investigate this more.

3) Initial switch into edit mode

When I first hit 'e' and go into editting mode, the display pauses, and 
displays a timecode.

If I then change to 'single frame mode', and attempt to move the image 
by a single frame (either forward or back), the display changes to quite 
a different image that is definitely more than one frame away from the 
paused frame. However, the timecode only changes by a single frame 
count. From this point on, all single-frame changes, and keyframe 
changes, do indeed seem to work correctly, and the timecode alters 
correctly (and then correctly  counts frames back to 0:00:00.1 as the 
very first frame)

It seems that the initial frame displayed, and the initial timecode 
displayed, when entering the "edit" mode aren't quite in sync, but a 
subsequent seek gets everything back into sync. Is there some kind of 
latency issue between the backend & frontend causing this?

4) One file with incorrect duration time

I have one recording that still stubbornly shows a total duration of 2 
mins 9 secs when hitting the "i" button, but is actually 4 mins 56 secs 
long when the playback is timed. Other files that I thought had the 
wrong duration are now showing the right duration, but this one does 
not. It is also, coincidentally, the only recording that I have run 
mythcommflag on since I did the patch.

Is this duration calculated at playback, or stored at recording? If 
calculated, can someone give me a quick clue about where in the code, so 
I can start tracking down the problem...

Cheers,

   Mike