[Bug 778690] qtdemux: Possible bug on gst-1.11 gst_element_seek

[GStreamer (GNOME Bugzilla)]

https://bugzilla.gnome.org/show_bug.cgi?id=778690

--- Comment #29 from christophe vr <christophevr at telenet.be> ---
(In reply to Jan Schmidt from comment #25)
> commit 488e8edba4527d7e8da9b45a42ffd3927f7ac449
> Author: Jan Schmidt <jan at centricular.com>
> Date:   Fri Feb 17 13:07:05 2017 +1100
> 
>     Revert "qtdemux: Always snap to the start of the keyframe"
>     
>     This reverts commit 107902ec514bd826aa29d2298107e2c091e1c779.
>     
>     This commit intended to ensure that keyframe seeks land at the
>     start timestamp of a keyframe, rather than in the middle of one,
>     but they cause trouble on files with sparse streams, or with
>     JPEG 'cover art' tracks that have only one or a few JPEG samples
>     with very long durations.
>     
>     That's still desirable for doing seamless cutting of videos,
>     but needs a rethink for implementation.
>     
>     https://bugzilla.gnome.org/show_bug.cgi?id=778690
> 
> Leaving the bug open, because just reverting that commit breaks the seamless
> cutting use case.

I've investigated further, indeed it is not easy to solve here.
But Yes if a media sample does have a image/ codec track that image codec track
is like it told and in some cases is one single image one buffer and yes does
only have one key-unit holder which covers so what the whole media length.

Perhaps limit the keyframe seek only to the real audio:video tracks could
solve.
The audio/video needs somehow to be threaded together (at last the active ones)
think about for example dts audio does have two key frames for one video key
frame (or perhaps the opposed).

Also think it's best to exclude the subtitles complete from this key-unit seek,
there as well we do have key units which may differ from the one by video or
audio. It is even possible to have a pts on a srt sub which needs algnement on
frame 2 off the three frames some h264 may contain. for one pts. But well do a
kind of async seek on the subtitle which after all is an overlay.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.