Open JIEgOKOJI opened 6 years ago
I've had some limited success using a proxy method, but it is inconsistent.
Can you share your experience ?
What proxy you use?
server {
add_header 'Access-Control-Allow-Origin' '*';
listen 192.168.1.21:443 ssl;
server_name llhls.mysite.com;
ssl_certificate /opt/nginx/conf/certs/mycert.com.bundle.crt;
ssl_certificate_key /opt/nginx/conf/certs/mycert.com.key;
ssl_session_cache shared:SSL:1m;
ssl_session_timeout 5m;
ssl_ciphers HIGH:!aNULL:!MD5;
ssl_prefer_server_ciphers on;
chunked_transfer_encoding on;
location / {
proxy_http_version 1.1;
expires off;
proxy_buffering off;
proxy_request_buffering off;
chunked_transfer_encoding on;
proxy_pass https://192.168.1.20:443;
}
}
server {
add_header 'Access-Control-Allow-Origin' '*';
listen 192.168.20:443 ssl;
server_name llhls_origin.mysite.com;
ssl_certificate /opt/nginx/conf/certs/mysite.com.bundle.crt;
ssl_certificate_key /opt/nginx/conf/certs/mysite.com.key;
ssl_session_cache shared:SSL:1m;
ssl_session_timeout 5m;
ssl_ciphers HIGH:!aNULL:!MD5;
ssl_prefer_server_ciphers on;
}
If you view it in tcpdump or a browsers network inspect you will see the header is sometimes correct, but not consistent...
I suspect rearranging this if logic might be enough to forge it continually.
but where you generate for example the tag: #EXT-X-FRESH-IS-COMING for example implementarion: https://medium.com/freshdevelopers/implementing-lhls-on-hls-js-4fc4558edff2
Or what implementation you are doing?
They say they did it for this reason
We added custom HLS tag EXT-X-FRESH-IS-COMING for two reasons. One reason is to let hls.js know whether a playlist is HLS or LHLS. If the playlist includes the custom HLS tag, hls.js works as LHLS player.
I don't really understand how that actually helps anything.
In my experiment I simply produce HLS using nginx-rtmp, with 2, 3 second segments. Chunk encoding does one thing here, and that allows the last file to be read (delivered) while it is being written. Whereas with a standard content-length header nginx can't use the file as it doesn't know the length of the file. The proxy to regular http seems necessary to get nginx to serve the file, but I suspect it would be fairly easy to modify nginx to read a file that is open.
At least how I understand it, the only advantage to chunk encoding over content-length is that the LAST file being written to disk can be used, where as without it you would need 3, 3 second segments. The average latency changes to about 4 seconds verse something closer to 8 seconds in this case.
Unless you use fragmented segments that is about as good as it is going to get, I think.
I understand, but you need a patched hls client to do this i think. Because this module, only publish the segment when is complete.
https://github.com/openfresh/hls.js/commit/8e6746ba0393e424a92c7b5de340e037fdd5e177
You can try with another proxy, like: https://github.com/jordicenzano/webserver-chunked-growingfiles
The snipped of code I pasted where Nginx hosts and proxy's to itself tries to do the same as the "webserver-chunked-growingfiles" project. The advantage to the nginx solution is it will scale and is not some bonkers javascript node thing (;
I don't think the player modification is necessary, although it seems it might help in some cases to reduce the buffer size. If you try to do only 2 segment files you will find the player will stop pretty soon into the live stream because the 2nd file isn't available, whereas with Chunk-encoding you will be able to serve the 2nd file and keep the stream playing. Using safari's native player you can reproduce or see that pretty quickly.
Now the LHLS protocol is gaining popularity. How about it support? This is a tune over HLS. The essence is Leveraging HTTP/1.1 chunked transport for segments Announcing segments before they are available