[Bug 688310] New HLS sink element using the GstBaseAdaptiveSink base class

[GStreamer (bugzilla.gnome.org)]

https://bugzilla.gnome.org/show_bug.cgi?id=688310
  GStreamer | gst-plugins-bad | 1.x

--- Comment #6 from Andoni Morales <ylatuya at gmail.com> 2013-04-18 08:45:58 UTC ---
1) I think we should keep 2 different elements even though you can in some
special cases produce DASH and HLS content from the same stream. HLS is a
subset of DASH, which means you could only have an HLS playlists for certain
kind of streams (mpeg-ts). Instead DASH is codec agnostic and for now there are
defined profiles for MP4 and mpeg-ts with several levels of complexity but more
can be added in the future (such as for webm).
We could have at some point a bin that can do both HLS and DASH but with a
restricted set of input caps. The base class has a write-to-disk property that
can be disabled for one of them, meaning it will only write the playlist and
fragments will be written by the other sink.
Also note that HLS's fragments recommended duration is 10 seconds while in DASH
you have fragments of around 2 seconds. So producing both contents from the
same stream is a special case and not the default operation mode.

2) I am not in favour of replacing the code to write fragments to disk with
multifilesink because it will make things harder in the future, such as
encryption or Smooth Streaming live, but that's what was agreed so let's do it.

3) ForceKeyUnit is the only way to split fragments correctly. In a HLS stream
segments are 10 seconds long, so you let the encoder generate keyframes when
needed except each 10 seconds where you force one. The only way to know when
this keyframe is forced is listening to this event. We will also need to listen
to FLAG_DELTA_UNIT to create I-Frames playlists in HLS, which is not
implemented.
We could also change this behaviour and let the sink fragment each X seconds
using as reference the closest FLAG_DELTA_UNIT for encoded streams, but that
needs to be an option.

4) I am not happy too, but that's the only way I found to get stream info
needed for the DASH media representation such as width, heigth, codec type,
etc.. It should possible to add this in the caps, but it won't work for encoded
streams.

5) We need to improve the API for alternative renditions. When adding a new
stream to the sink there is no way to let him know whether it's a new bitrate
or a variant stream of an existing one. The sink relies in ondemand pads to
make it work with gst-launch but we should additionally provide an api to add
pads with some metada such as the stream bitrate and the stream information
(name of the alternative rendition or language for audio streams).

-- 
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.