[gst-devel] accuracy of seek event in MPEG1 video
Joshua N Pritikin
jpritikin at pobox.com
Wed Nov 19 09:43:04 CET 2003
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
More information about the gstreamer-devel
mailing list