Porting the hlsdemux work in issue 698155 to 1.x

[Duncan Palmer]

Hi all,

I'd like to make use of the hlsdemux work described in
https://bugzilla.gnome.org/show_bug.cgi?id=698155 , and I'm running
gstreamer 1.x. So, I've spent some time nosing around the changes
introduced by 698155 with a view to figuring out what would be
required to get this stuff rebased onto the 1.x HEAD. I'm hoping
Andoni (the author), and maybe a few other people who may be familiar
with this can comment on what I think needs to be done, as I'd say
there's a good chance I may have missed a few things.

>From what I can see, the hlsdemux work was branched from the
sdk-0.10.23-hls branch in Andoni's github repository about a year ago.
After work on the hlsdemux branch finished, it was rebased onto some
other branch. Since this time, much (but not all) of the hlsdemux work
has been merged into the sdk-0.10.23-hls branch, and there have been
additional bug fixes applied to this branch.

Andoni, could you tell me what the story with the sdk-0.10.23-hls
branch is, and whether it would be sensible to pull any bug fixes from
this branch?

I think as a starting point, Andoni's hlsdemux branch would need to be ported
to 1.x, and all 1.x changes then merged in (if they still make sense), perhaps
along with bug fixes from Andoni's sdk-0.10.23-hls branch. This would be quite
a manual process. There are some complications;
- Andoni's hlsdemux branch and the 1.x hlsdemux implementation both support
  decryption, but the implementations are conflicting. Also, the 1.x
  implementation relies on gnutls whilst the hlsdemux branch relies on openssl.
  I'd probably be inclined to stick with gnutls, to avoid the openssl license
  complications.
- I think there are conflicting changes in m3u8.c
- Refactoring of uridownloader into it's own library on 1.x. Should be
  straightforward to deal with.

The hlsdemux branch creates hlsdemux as a bin, encapsulating a
typefind element and a tsdemux, plus some elements for subtitle
handling (haven't looked into it). I gather from the bug report that
there is some disagreement over whether this is the right way to go.
Could anyone enlighten me on the details?

>From what I can see, these are the reasons for the hlsdemux being a bin. Have I
missed any?
- 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 the implementation of gst_hls_demux_drain_streams(); on a
  discontinuity, hlsdemux waits for the tsdemux to drain (and filters out the
  EOS event it sends), before sending a SEGMENT event.

Any comments much appreciated.

Regards,
Dunk.