nginx-ts-module
nginx-ts-module copied to clipboard
Add pull feature
Add a pull feature in anology with nginx-rtmp-module.
Pull as a separate feature is not planned. However I'm planning to implement a number of flexible execs instead.
I've made the first approach to the exec pull feature. It works, but there's one question which I don't know how to address. Once a client requests an m3u8 or mpd file, nginx starts ffmpeg which publishes this stream. However at least the first request ends up with 404 anyway. If I keep restarting the page, it finally starts working. Still not sure if this should be addressed at client side by handling 404 properly or at server side by sending a fake manifest.
I would think the "correct" way to handle it is to return code 503 with the "retry-after" header indicating a delay time. But that would depend on the browser & player honouring the delay indicated in the "retry-after" header and re-submitting the request.
The best approach may be to de-couple the exec request from the player. So have a separate location that is designated with a ts_exec directive and has different commands for different path endpoints. So for example:
location /foo/ {
ts_exec;
exec_cmd ffmpeg -i bar <other arguments> path=bar;
exec_cmd ffmpeg -i hash <other arguments> path=hash;
exec_cmd ffmpeg -i $path <other arguments> path=$path;
}
So a GET request to /foo/bar would start the first command. A DELETE request to /foo/bar would result in SIGTERM being sent to that process. Likewise for the second command if the path used is /foo/hash. The third command would be a catch all allowing use of the path as a variable. So GET to /foo/bang would start the third command with the path variable expanding to "bang" when executed.
Then it's up to the developer using it to make sure a call is made to start the exec (and use HEAD to test for when the manifest is available) before ever trying to load the stream into the player.
@arut Can you show a example of exec_pull feature?
Can use exec_static like on rtmp module?