How to switch element exactly on force key unit event

jmz jmzheng at gmail.com
Thu Nov 23 10:34:24 UTC 2017


jmz wrote
> Where do the other frames (appearing at the beginning of the new file)
> come
> from? I block queue's src pad, switch filesink, and pass the force key
> unit
> to the new filesink. The new file should start with the key unit.

I found the reason that the new file does not contain SPS and PPS at the
beginning of file. I have pipeline as "h264parse ! mpegtsmux ! tee ! queue !
multifilesink." To switch multifilesink, an upstream force-key-unit event
(set running_time to to GST_CLOCK_TIME_NONE) is pushed to tee's sink pad
[step 1]. Both mpegtsmux and h264parse receive the event. If mpegtsmux
pushes a downstream force-key-unit event before h264parse does (is this
always?), only keyframe comes along with the event. This is why the new file
is created with no SPS and PPS upon receiving the downstream event [step
3c].

If I send the upstream force-key-unit event to only h264parse, the h264parse
will send downstream force-key-unit event along with SPS, PPS, and keyframe.
However, the mpegtsmux does not push the downstream force-key-unit event
because it has queued that a new key unit should be produced at a specific
time. This is mpegtsmux_sink_event() reports "skipping downstream force key
unit event as an upstream force key unit is already queued"

Shall I send the upstream force-key-unit event to only h264parse or both
h264parse and mpegtsmux? If only h264parse, can we let an element
(mpegtsmux) push a downstream event even if it has queued an upstream force
key unit?

Hope my question is described clearly and someone would give me a hand.
Thanks.




--
Sent from: http://gstreamer-devel.966125.n4.nabble.com/


More information about the gstreamer-devel mailing list