Created attachment 205446 [details] [review]
Add keyunits scheduler element

I see some errors in configure.ac... I'll fix them first :)

Review of attachment 205446 [details] [review]:

::: gst/kuscheduler/gstkeyunitsscheduler.c
@@ +29,3 @@
+ * <title>Example launch line</title>
+ * |[
+ * gst-launch videotestsrc ! keyunitsscheluer interval=10000000000 ! vp8enc ! webmmux ! hlssink

typo: keyunitscheduler

Isn't this a workaround for not having an encoder interface where we could specify the keyunit rate?

In a multi-bitrate scenario, all encoders should produce a keyframe at the same stream position, at least for HLS, Smooth Streaming and the basic profiles of DASH (DASH supports having streams with keyframes not aligned, but not for the basic profiles). Also you should be able to add a new quality/encoder at any time for a live stream.

This element is therefore used for 2 goals at the encoder level:
  * Generate keyframes at a fixed interval.
  * Synchronize encoders to generate keyframes at the same instant and create streams that are keyframe-aligned at the fragment boundaries.

Most encoders have an API for creating keyframes at a regular interval but this wouldn't allow us inserting new encoders in the pipeline and create keyframe-aligned streams. Also, forcing keyframe at a regular interval in the encoder is suboptimal, instead we let the encoder decide whatever is best in the X seconds interval and force a keyframe only when needed.

Note that this event will flow downstream down to the sinks and it's also used by muxers and sinks to determine when a new fragment should be created.

(In reply to comment #4)
> Isn't this a workaround for not having an encoder interface where we could
> specify the keyunit rate?

I miss-read your question, so forget my comments about forcing a keyframe at fixed interval in the encoders :)
Generating the keyunit event in the encoder wouldn't let us synchronize them and that's why it should be done in the raw source.

I see that your newer BaseAdaptive produces regular upstream events, is this still used/necessary/better ?

That's no longer needed since the sink supports multibitrate and the synchronization happens in a single sink element.