andoni: talking about hlssink, is anyone going to review https://bugzilla.gnome.org/show_bug.cgi?id=688310
   twi: I gave it a quick look, it doesn't seem like anything has changed since last time we spoke though?
   twi: like, what is the reason to not use multifilesink?
andoni: many things changed since last time: multi-bitrate support and byte-ranges support
   twi: ok, but that's trivial to add to the existing (in git) hlssink element, why can't we just do that?
andoni: the reason for not using multifilesink is that you can't provide an application interface
   twi: why do you need one?
andoni: if you have an application like flumotion that does the streaming directly
   twi: i do have one
   twi: i think we have discussed this already, but how is creating an ad-hoc interface that only flumotion would likely use better than mounting a piece of RAM in tmpfs, and letting hlssink write there
   twi: and then serve the segments using nginx or apache, or even your custom flumotion code? (like i do with twisted)
andoni: agreed in the that part. How would you implement segments encription  with multifilesink than?
   twi: hlssink wraps multifilesink, you can encrypt there
   twi: or you want to encrypt on the fly with a different key for each viewer/moment of time ?
   twi: you can do that too, you just read the segments from tmpfs disk like regular files instead of using the ad-hoc interface
   twi: i think there's even a nginx module somewhere that does that
andoni: sure, but you nead to read the fragments back  or you rely on something else like nginx. 
   twi: you read them back from memory just like you would with the ad-hoc interface
   twi: it's the same thing, just done with a different interface
andoni: if you use tmpfs, but if you want to write things to disk you will need to read from the disk and not the RAM
   twi: how is this different with the ad-hoc interface?
andoni: I don't think I understand what you mean by the ad-hoc interface
   twi: the interface you need that makes using multifilesink impossible
andoni: also, on some protocols like live Smooth Streaming, you need to modify the fragment before writting it and append the timestamps of the next 2 fragments in an atom
andoni: so you can't use multifilesink either 
   twi: well i haven't looked at smooth streaming in detail but i know of people using multifilesink and the same approach
   twi: no sorry that's wrong
   twi: what i've seen is dash not smooth streaming
   twi: hm
   twi: i should look at smooth streaming maybe
andoni: and how are you supposed to support byte ranges without tracking sizes of fragments in the GstForceKeyUnit event boundaries?
   twi: again, hlssink wraps multifilesink, hlssink gets all the GstForceKeyUnit events
andoni: also fragments can have different sizes and multifilesink only allows to limit the DVR window for number of files
   twi: and?
andoni: you usually set the DVR in time 
   twi: but you can easily go from time => files if you track the durations of the segments, no?
   twi: mind i'm not saying the current hlssink is perfect, it's far from it
andoni: and if you need to add more code to handle the events too in hlssink than multifilesink is only used to write buffers
   twi: but i think we can fix it relatively easily, like byte ranges would take 15 minutes to implement
andoni: and since you also need code to save the playlists you can reuse it save write fagments to disks
   twi: i'm not sure I understand your last sentence
   twi: but anyway, i should group all my thoughts on bugzilla i don't have time to go on now
   twi: but
   twi: in short, i'm not against improving the current hlssink, or even introducing a base class
   twi: i just think your current approach is overcomplex and your NIH'ing multifilesink
andoni: ok, at least I wanted someone to review it :)
   twi: (at some point it was even clearly copy/pasted and sed'ed around)
andoni: I can also change the base class to use multifilesink
   twi: also i think the interface is bad
andoni: ok, so let's discuss that
   twi: it's a bad interface and only flumotion would likely ever use it, IMO
andoni: i don't do any flumotion work anymore, so I don't really care
andoni: like I said I am open to any kind of change/modification
   twi: i don't think we need to keep stuff in memory and have the pull-like interface at all
   twi: you can do the same using tmpfs and that has the advantage of working with existing servers
andoni: I don't like it either, but I just though that some people could benefict from it. Anyway it's not the right think to do so we shouldn't even support it 
andoni: anyway I still think we could benefit from not using multifilesink and it doesn't add much more more complexity
andoni: as you still need to keep track of fragment boundaries 
   twi: yeah but you only need to look at events
   twi: i mean i agree that what multifilesink does is not science and we could redo it
   twi: but unless we have a good reason to do it I don't see why we would?
andoni: to me there are 3 reasons: variable-length fragments and DVR window, encryption and Smooth Streaming live. But I can keep the base class, without  the application interface and using multifilesink
   twi: as i said i don't know much about SS details, but i don't understand what you mean about variable lenght fragments, why are those harder to support with multifilesink?
   twi: we are not cutting segments looking at byte sizes, but at their duration, so...
andoni: anyway, I think we should use this base class (without or without multifilesink and without the application interface). There is a lot of code that should be shared among all adaptive streaming sink. hlssink  and dashsink are 200 lines of boilerplate with the base class.
   twi: agreed, i just want to keep it simple, because it's a simple problem
   twi: i mean
   twi: even the current hlssink is what 500 lines of code?
   twi: of which 200 of boilerplate
   twi: so...
andoni: and hls is by far the simplest of them
   twi: well i don't know about SS, but i've done some bugfixing on a (closed) dash sink, and it's essentially the same thing as the current hlssink but the playlist code is more complex (because XML etc)
andoni: sure and you need to extract width, height, media type for each representation, and support byteranges and encryption and multibitrate  so it' s not only 500 lines of code and it's almost the same for all the sinks, so wo why not using a base class here?
   twi: i didn't say anywhere i'm against having a base class :)
andoni: twi_, ok then :) I'll try to modify the base class to use multifilesink. By the for byte ranges it's a single file, dropping the downstream GstForceKeyUnit events before multifilesink should be enough, right?
andoni: *By the way
   twi: andoni yes
