GNOME Bugzilla – Bug 338810
[matroskademux] blocks on segmenting seek (and other seek/segment glitches)
Last modified: 2006-04-21 13:07:57 UTC
A few glitches with matroska-demux seek/segment handling. Firstly, due to keeping the object lock too long when processing a seek, it blocks when posting segment_start message. Secondly, the new_segment event sent in response to a seek can have a different start time than requested in the seek by the application (so possibly more is shown/passed than should be). Lastly, it does send segment_done at the end of the segment-ing seek, but does not send end-of-stream if the seek was not-segment-ing.
Created attachment 63732 [details] [review] Possible patch Combined patch for items mentioned. - object lock is released sooner (alternative one might forego the object lock as the stream lock is also taken) - start-time of a seek is now only changed to index-entry time if it is non-precise seek request
Thanks for the patch, looks good. I already fixed the key unit seek / segment_start stuff in my local copy, but ran into some issues with ffdec_* that I don't quite understand yet, that's why it's not in CVS yet.
(marking accepted-commit-now so it's not forgotten before the release)
(In reply to comment #2) Without knowing the issue referred to of course, but it is likely (in my case at least) that ffdec_* can complain about being fed a non-keyframe after seek. This follows from e.g. GStreamer's matroska-mux creating clusters of 2 seconds in duration and matroska cue data only having "cluster-resolution". So, cluster boundary and key-frame need not coincide. But that's another matter ...
Committed the segment-seek related part of the patch: 2006-04-20 Tim-Philipp Müller <tim at centricular dot net> Patch by: Mark Nauwelaerts <manauw at skynet dot be> * gst/matroska/matroska-demux.c: (gst_matroska_demux_handle_seek_event), (gst_matroska_demux_loop): Handle end of segment properly when set; don't dead-lock when posting start of segment message when doing a segment seek. Fixes #338810. The key unit stuff should also be fixed in CVS now. The issue I meant was indeed ffdec_* complaining about not receiving a keyframe as first frame. What startled me was that I didn't seem to remember there being such an issue before when we'd used entry->time for segment start unconditionally. Any improvements to GStreamer's matroska muxer would be very welcome of course, so feel free to fix this :) I've seen these issues with the sample videos from the matroska.org as well though, and I'm fairly sure those haven't been produced by GStreamer.
Thanks. There may be an explanation for those issues happening with matroska.org files: matroska cue data can also include a block number (relative to cluster), which is currently not used by matroska-demux. I may feel free to look into this as well :)