Issues with hlsdemux being a bin

[Duncan Palmer]

Hi Edward,

I'm keen to get the work which Andoni has been doing on the hlsdemux element
ported to gstreamer 1.x (see bug 698155). A sticking point with this
element being
accepted for mainline inclusion appears to be that it is a bin, which
uses internal
decodebin elements to either identify or demux audio/video/subs and present the
results on single audio/video/subs source pads.

I see your name was mentioned in the bug report. Would you be able to
provide your views on this?

After discussion with Andoni, and some head scratching on my part, I believe
these are the reasons for hlsdemux being a bin. They seem to boil down to
making it possible to manage the decode pipeline, without the managing
application having to be aware of HLS specifics.
- To allow alternative renditions to be handled internally by the hlsdemux
  element; e.g. an alternative audio elementary stream being passed to the
  audio source ghost pad rather than the audio from the transport stream.
- To fiddle with the timestamps on SEGMENT events after a 'catch-up' seek to
  the head of a live window.
- To ensure that no SEGMENT events produced by tsdemux make it downstream (does
  tsdemux actually produce it's own SEGMENT events - I haven't looked
  properly).
- To facilitate implementation of HLS discontinuity handling; the hsldemux
  waits for an EOS from it's internal decodebins before sending out a SEGMENT
  event.

Regards,
Dunk