GNOME Bugzilla – Bug 578052
gstavidemux: support seeking and duration query in default format
Last modified: 2009-07-29 11:59:33 UTC
subj
Created attachment 132140 [details] [review] Adds duration and seek support for default format. Now you can do: GstFormat fmt = GST_FORMAT_DEFAULT; gint64 len; gst_element_query_duration (pipeline, &fmt, &len); and you can call gst_element_seek() with GST_FORMAT_DEFAULT too. Conversion implementation was in place, but it was used for internal conversions only (and there are a lot of #if 0). Now, it's time to test just how accurate it is...
Seems to be accurate enough. I've tested it on AVI file (v2.0) and it seemed that it seeks accurately - i've written a test app that enables seeking (with GUI) and dumps video frames as png images. With it i was able to seek to a random frame N in the middle of the stream, then let it play 10 or more frames, then seek to a frame N+10, let it dump it and kill the application. Then i compared 10th frame taken after 1st seek and 1st frame taken after 2nd seek. They were the same. With http://bugzilla.gnome.org/show_bug.cgi?id=578278 (which enables my test app to show frame numbers instead of '-1's) i was able to see the numbers, and i can confirm that it seeks exactly to the frame specified by user.
Author: LRN <lrn1986 at gmail.com> Date: Fri Apr 10 00:26:44 2009 +0200 avidemux: add convert query, fix duration query Fix the duration query so that it also works with formats other than TIME, such as DEFAULT to get the number of frames. Add a convert function. Fixes #578052.
Created attachment 138470 [details] [review] The intended code that sets buffer offset
My intention (which may or may not be obvious from my comments) was not only to report correct duration (for which correct convert and duration query handlers were needed), but also to push downstream video frames with frame numbers (offsets) properly set. Somehow that last bit of code was left out of patch, i never checked the changes you've committed and assumed that it is there. Today i found out that it is not :), so...here it is. Attached above.
Created attachment 138563 [details] [review] Improved version (uses TIME->DEFAULT conversion by default)
Created attachment 138659 [details] [review] Backfix: don't use TIME->DEFAULT conversion by default (current_frame appears to be precise after all). Also fixes the conversion itself (so it's actually safe to use it instead of stored values)
Conversion for TIME->DEFAULT values was bugged and produced wrong results for some frame rates. The patch above fixes that. Ironically, the conversion itself is not necessary anymore, because frame number deviation happened because of ffmpegdec, not because of avidemux's incorrect current_frame and total_frames values.
Created attachment 139163 [details] [review] Same as above, but shameful GST_SECOND/2 is replaced with 0.5
commit b3b7085b10b3b400493d345a1cb26e7fb7b11d7c Author: Руслан Ижбулатов <lrn1986@gmail.com> Date: Fri Jul 24 19:04:31 2009 +0400 Fixed the fix for TIME->DEFAULT conversion. Fixes bug #578052 again.