[gst-devel] accuracy of seek event in MPEG1 video

[Joshua N Pritikin]

I meant to respond to this email a few days ago but I forgot
about it.  I hope I'm not too late!

On Wed, Nov 12, 2003 at 05:41:34PM -0500, Jeremy Gwinnup wrote:
> It's geen a while (Been busy with other tasks), but I've figured out how
> to performing seeking in my application.
> 
> The question I have now is how to improve the accuracy of seek events. 
> I require to seek to a given frame in my MPEG1 datafile, so I can
> overlay a particular frame's metadata. 
> 
> These videos are 25 Mbit I frame MPEG1 encoded videos with a null audio
> track, and are recorded at a 29.97 fps rate (dropframe video) Each frame
> of the video is an I frame, which means we should be able to directly
> seek to any given frame.

Even with only I frames, it seems doubtful that the default
guestimation algorithm will guess the right place to restart MPEG
parsing after a seek.  You probably need to use a fileindex.

> My pipeline looks like the following:
> 
> filesrc -> mpeg2dec -> "videosink"
> 
> On starting the application, I create an index on the pipeline (like the
> indexing example in gstreamer/examples) to determine the length of the
> clip (since querying total length in time on the decoder element returns
> zero)

Hrm, I don't see which indexing example you are referring to.

> After the index is created, I reset the stream and allow the user to
> start playback.

Hrm .. I've had this type of thing working for quite a while,
modulo some possible bit-rot.  See version 0.9.5 here:

  http://savannah.nongnu.org/files/?group=aleader

The gstreamer stuff is in the film subdir.

> If the user slides the seek bar, I pause the pipeline and do the
> following: (where offset is the new framenumber multiplied by the
> time-per-frame constant, which is 33366666 for 29.97 frames/sec)
> offset and result are gint64, and id is the index writer ID of the
> decoder element
> 
>     entry = gst_index_get_assoc_entry (idx,
> 				       id,
> 				       GST_INDEX_LOOKUP_EXACT,
> 				       0,
> 				       GST_FORMAT_TIME,
> 				       offset);
>     
>     gst_index_entry_assoc_map (entry, GST_FORMAT_TIME, &result);
>     
> 
>     event = gst_event_new_seek (GST_FORMAT_TIME | 
> 				GST_SEEK_METHOD_SET |
> 				GST_SEEK_FLAG_FLUSH |
> 				GST_SEEK_FLAG_ACCURATE |
> 				GST_SEEK_FLAG_KEY_UNIT, result);
> 
>     g_print("Think: %lld  Want: %lld\n", offset, result);
>     
>     g_print("Event accuracy: %lld\n", GST_EVENT_SEEK_ACCURACY(event));
>     g_print("Event offset:   %lld\n", GST_EVENT_SEEK_OFFSET(event));
> 
> result and order wind up being equal (which is expected)
> 
> The event accuracy appears to be way off. Here is an example:
> 
> Seeking to 967
> Think: 32265566022  Want: 32265566022
> Event accuracy: 30064771072
> Event offset:   32265566022
> 
> I expect accuracy to either be zero, or the amount of the offset.  Since
> it's neither, the seek event goes to some portion of the video other
> than where it should be. This causes discrepancies for my metadata
> display, since that portion expects to be at frame 967, not somewhere
> around frame 901.
> 
> So my big question is: How can I get the seek event accuracy higher?

I'm pretty sure I get exact frame accurate seek.  I checked
against cinelerra and it appeared to show the same frame
as my gstreamer based code for any given time offset.

> Do I use a higher resolution GstClock?

No.  The clock doesn't matter.

> I am not worried about playback speed, just playback accuracy.

-- 
A new cognitive theory of emotion, http://savannah.nongnu.org/projects/aleader