support remote hls streams

[flavioribeiro]

since this is just mixing and mapping stuff on manifests, I wonder if we could build a watcher that instead of getting events from the filesystem, would monitor the level manifest updates and map them accordingly on the woven manifest. This would enable the deployment of loom instances outside the same disk/server as the origin stream.

[rosscooperman]

Hey @flavioribeiro I'm not 100% sure I follow. So where would the updates be coming from in your example? In principal you could build a watcher for any source of updates.

[flavioribeiro]

@rosscooperman I imagine that we could create some kind of poller to detect new segments being advertised on the level manifests and use it to trigger updates. What do you think?

[rosscooperman]

Ooooh, I see what you're saying. Could that not still be triggered by filesystem events (since the write to each level manifest will still cause an update on the filesystem)?

[flavioribeiro]

correct -- we may be able to just extend the existent watcher to be able to periodically download manifests when resource is an URL and update the config parser to be able to accept URL's...

[rosscooperman]

That sounds doable to me. The configuration is meant to be pretty flexible for the future. One use case we've been talking about internally is adding filtering rules so the resulting output manifest only contains renditions that meet certain criteria (below a certain bitrate, audio-only, etc).

[flavioribeiro]

yeah that would help on multidevice scenario. I wonder how this could integrate with an "on the fly" manifest generation service where the filtering would happen based on user agent or query parameters for example. Just throwing up ideas..

[rosscooperman]

Love it. So, do you have the need for a network polling watcher currently? We're open to PRs obviously 😉 but also willing to work on it with you a bit as well.