GNOME Bugzilla – Bug 578052
gstavidemux: support seeking and duration query in default format
Last modified: 2009-07-29 11:59:33 UTC
Created attachment 132140 [details] [review]
Adds duration and seek support for default format.
Now you can do:
GstFormat fmt = GST_FORMAT_DEFAULT;
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.
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
Author: Руслан Ижбулатов <firstname.lastname@example.org>
Date: Fri Jul 24 19:04:31 2009 +0400
Fixed the fix for TIME->DEFAULT conversion.
Fixes bug #578052 again.