bluenviron / mediamtx

Ready-to-use SRT / WebRTC / RTSP / RTMP / LL-HLS media server and media proxy that allows to read, publish, proxy, record and playback video and audio streams.
MIT License
10.79k stars 1.4k forks source link

HLS Stream Timestamp Option #3201

Closed Craytor closed 1 month ago

Craytor commented 3 months ago

Describe the feature

The idea behind this feature is to allow mediamtx to be easily stored behind a nginx reverse proxy to be able to distribute to multiple users easily and quickly. The current .ts files use incremental file names which can pose an issue if the stream is constantly restarted as it would create new .ts files. In this case, the edge proxy cache servers may still have older files cached and not retrieve the new file if was within the cache time.

The nginx-rtmp module does handle a scenario like this by allowing the use of a directive hls_fragment_naming to timestamp. I believe that it would be a good idea to add a way that we could allow the use of a timestamp fragment name over an incremental integer, to aid in cacheing and allowing more flexibility in hosting solutions. Further, the timestamp would need to be in unix time as stream relative time would incur the same issues that are currently happening with incremental integers.

aler9 commented 1 month ago

Hello,

The current .ts files use incremental file names which can pose an issue if the stream is constantly restarted as it would create new .ts files. In this case, the edge proxy cache servers may still have older files cached and not retrieve the new file if was within the cache time.

You're right about this potential issue, but we have already solved it. Take a look at playlists returned by the server:

#EXTM3U
#EXT-X-VERSION:10
#EXT-X-TARGETDURATION:2
#EXT-X-SERVER-CONTROL:CAN-BLOCK-RELOAD=YES,PART-HOLD-BACK=0.50000,CAN-SKIP-UNTIL=12.00000
#EXT-X-PART-INF:PART-TARGET=0.20000
#EXT-X-MEDIA-SEQUENCE:29
#EXT-X-MAP:URI="ce0c22ee188c_init.mp4"
#EXTINF:2.00000,
ce0c22ee188c_seg29.mp4
#EXTINF:2.00000,
ce0c22ee188c_seg30.mp4
#EXTINF:2.00000,
ce0c22ee188c_seg31.mp4
#EXTINF:2.00000,
ce0c22ee188c_seg32.mp4
#EXTINF:2.00000,
ce0c22ee188c_seg33.mp4

There's already a random prefix (ce0c22ee188c) which prevents the problem you described from happening.

Craytor commented 3 weeks ago

@aler9 thanks for pointing this out. I was unsure if the the random prefix was generated for each client, was statically assigned for all future streams, or if it is just a one time prefix that is added once the source goes live. Can you advise further?

Thanks!