GNOME Bugzilla – Bug 680444
matroskademux negative rate in gap
Last modified: 2018-11-03 14:47:17 UTC
in the latest update matroskademux is extended to be able to use new-gap-time is bigger then max-gap-time but why it's not working for negative rate? in the code: ---------------------------------- if (demux->max_gap_time && GST_CLOCK_TIME_IS_VALID (demux->last_stop_end) && demux->common.segment.rate > 0.0) { ---------------------------------- why is the last condition?
*** Bug 680443 has been marked as a duplicate of this bug. ***
Is this breaking something, is this still a problem with 1.0?
we still use 0.10 until enterprise linux will support 1.0 (ie newer glib2).
And what exactly is the problem here? Is there one at all? :)
you can't use max-gap-time properties in case of negative rate.
For reverse playback you will jump gop by gop, so there will be rather large gaps every now and then. I guess that's the reason for this. Is it causing any problems, if so, how to reproduce?
max-gap-time is used for the time delay wait before the next frame played. eg we've video with 1 frame/10 minites but we'd like to play it with 1fps in this case we can use max-gap-time. but we're not able to play the same video backward with the same way:-(
It would be helpful if you could provide a test video that demonstrates the problem.
Created attachment 253811 [details] here is an example
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/issues/69.