[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 #5 from Olivier Crete (Tester) <olivier.crete at ocrete.ca> 2013-04-17 23:42:20 UTC ---
I had a look at your code, I think it's a good start and has some important
features over the current hlssink, such as supporting multiple bitrates.

Some comments:

1. I'm not sure why you have a base class and separate dashsink and hlssink, I
think it would make more sense to have a single "fragmentsink" that can produce
both, since it is very possible to make a stream that is both dash and hls at
the same time (and then to write both manifests). If you do that, then you no
longer need an external base class.

2. As discussed on bug #688310, you should use multifilesink, it might make
sense to allow the user to replace this multifilesink which his own element.

3. I'm not sure listening on the ForceKeyUnit is the best way to split the
fragments, it might make sense to instead listen to FLAG_HEADER and
FLAG_DELTA_UNIT. This way, one can use it from a pre-encoded file.

4. I'm also not incredibly happy about seeing decodebin in there, I think if we
just muxed the stream, we shouldn't need to re-demux it. This may mean that we
need to enrich the caps of muxed streams to know what they contain. Or forward
something along the lines of an encoding profile down the pipeline.

5. DASH allows for more complex cases than just N streams representing the same
content, it allows for separate files for separates languages, etc. It might
make sense to think of a more complex API to create these kind of 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.