GNOME Bugzilla – Bug 595930
[matroskamux] Finalize matroska files upon custom event
Last modified: 2009-09-26 05:47:46 UTC
This patch introduces support for finalizing matroska files upon custom event (Currently files are finalized only at EOS). example: GstPad *src_pad = gst_element_get_static_pad (matroska, "src"); /* Tell matroska muxer to finalize the file */ gst_pad_send_event (src_pad, gst_event_new_custom (GST_EVENT_CUSTOM_BOTH, gst_structure_empty_new ("FinalizeMatroskaFile")));
Created attachment 143678 [details] [review] finalize matroska files upon custom event
Created attachment 143680 [details] [review] finalize matroska files upon custom event
I'm not sure why this is useful. Why not just send an EOS event to close things out?
I would like some more information about the exact use cases here as well. If it is indeed useful, it seems like something that should maybe be standardised so it can be used everywhere in the same way, instead of cooking up custom events for each muxer.
Oops, didn't mean to change bug status.
Well, i need to split a live stream(h264) into multiple matroska files but i also have a queue in the pipeline and i don't want any buffers from that queue to be discarded at any cost. So what i am basically doing is issuing segment seeks and changing file upon SEGMENT_DONE. If i was using regular seeks and changing file upon EOS i would also have to do either flushing seeks or perform PAUSED->READY->PAUSED state transitions to cancel the EOS state, but that would discard the buffers that are in the queue ;(
I don't think this will work without putting a block on the queue src pad. And your second file will have timestamps starting at non-zero, which results in faulty playback. Also filesink will not open a new file unless you bring it down to NULL state and back to PLAYING again. What I do is sending an EOS event down to the queue's peer pad before disconnecting the mux-filesink chain. And I have a resettime element to reset the timestamps back to zero.
Yep, i break the link mux-filesink and set filesinks state to NULL in order to be able to change the file and also reset the timestamps so new files have timestamps always starting from zero. Blocking the queues src pad is not necessary.
Well putting a block on the queue src pad is necessary in the general case when file change is made right away upon SEGMENT_DONE but doing that may also result into lost delta units. I have an extra element within the pipeline that handles this nicely.
Sending an EOS event down to the queue's peer pad(when i want to switch file) worked fine so this patch is not really useful.