After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 578052 - gstavidemux: support seeking and duration query in default format
gstavidemux: support seeking and duration query in default format
Status: RESOLVED FIXED
Product: GStreamer
Classification: Platform
Component: gst-plugins-good
git master
Other All
: Normal enhancement
: 0.10.16
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2009-04-05 17:44 UTC by LRN
Modified: 2009-07-29 11:59 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Adds duration and seek support for default format. (1.90 KB, patch)
2009-04-05 17:46 UTC, LRN
committed Details | Review
The intended code that sets buffer offset (2.05 KB, patch)
2009-07-15 19:35 UTC, LRN
none Details | Review
Improved version (uses TIME->DEFAULT conversion by default) (3.95 KB, patch)
2009-07-16 22:09 UTC, LRN
none 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) (4.18 KB, patch)
2009-07-18 10:41 UTC, LRN
none Details | Review
Same as above, but shameful GST_SECOND/2 is replaced with 0.5 (4.20 KB, patch)
2009-07-24 15:11 UTC, LRN
committed Details | Review

Description LRN 2009-04-05 17:44:25 UTC
subj
Comment 1 LRN 2009-04-05 17:46:10 UTC
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...
Comment 2 LRN 2009-04-07 18:40:43 UTC
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.
Comment 3 Wim Taymans 2009-04-09 22:25:32 UTC
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.
Comment 4 LRN 2009-07-15 19:35:32 UTC
Created attachment 138470 [details] [review]
The intended code that sets buffer offset
Comment 5 LRN 2009-07-15 19:39:02 UTC
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.
Comment 6 LRN 2009-07-16 22:09:06 UTC
Created attachment 138563 [details] [review]
Improved version (uses TIME->DEFAULT conversion by default)
Comment 7 LRN 2009-07-18 10:41:43 UTC
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)
Comment 8 LRN 2009-07-18 10:45:10 UTC
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.
Comment 9 LRN 2009-07-24 15:11:41 UTC
Created attachment 139163 [details] [review]
Same as above, but shameful GST_SECOND/2 is replaced with 0.5
Comment 10 Sebastian Dröge (slomo) 2009-07-29 11:59:33 UTC
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.