[Bug 654799] Add force-key-unit support to mpegtsmux

[GStreamer (bugzilla.gnome.org)]

https://bugzilla.gnome.org/show_bug.cgi?id=654799
  GStreamer | gst-plugins-bad | git

--- Comment #4 from Alessandro Decina <alessandro.d at gmail.com> 2011-07-20 20:13:10 UTC ---
Thanks for looking at this. I don't like some aspects of the patch either. In
fact I decided to try this since I'm not entirely convinced about the proposed
force-key-unit API and wanted to see how it works out in practice.

To answer your questions:

- why the muxer handles upstream events

Imagine: a number of inputs... ! mpegtsmux name=mux ! multifilesink
next-file=key-unit-event

Say you want to create a new file and you want the new file to start with PAT,
PMT and keyframes. How would you do it?

The way it's implemented right now you would just send an event to mux:src. 
The muxer forwards the event upstream, waits until it has a downstream
force-key-unit queued for each stream and then it pushes a downstream
force-key-unit event to multifilesink. multifilesink closes the current file,
opens a new one and then the muxer starts pushing again, starting with PAT and
a PMT for each stream.


- why not forward to audio pads too

Because that's how the proposed force-key-unit API works right now. I haven't
followed the whole discussion about it but it seems it was decided to implement
it for video only. The latest patch adds API to libgstvideo in fact.

This is probably what I dislike the most about the proposed API. I would just
make force-key-unit a core event.


- what's the use case for storing the upstream event in the muxer and waiting
for downstream events with the same seqnum

Because if you send an upstream force-key-unit event to the muxer and then
quickly send another before all the muxed streams have replied with matching
downstream events, you are going to get a bunch of downstream force-key-unit
events from encoders and you need to decide how to handle it:

* One option would be to queue upstream events - I don't like this one.
* Another would be to refuse an upstream event if there's one being handled
already - I could live with this.
* The way it's implemented is: sending upstream events never fails, if two
events overlap, the latest replaces the previous one - this is the option i
personally prefer but i'm not married to it.

Finally, i have implemented this in mpegtsmux now but once we come up with a
stable API, i'd like to move the code to collectpads. 99% of the code is
generic in fact, the only thing mpegtsmux specific is setting the flags to
force PAT and PMTs to be output. That could be done with a collectpads vfunc or
something.

-- 
Configure bugmail: https://bugzilla.gnome.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
You are the assignee for the bug.