You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
At the moment, HLS muxing can happen in two ways:
(1) For all defined paths that are not on-demand
(2) For paths with an active reader
It would be nice to have a more selective approach. My use case is monitoring cameras locally, post-processing the input by transcoding and then thme locally recording, hooking them into OBS as well as publishing them to a remote server. For that I have a pair of paths for each camera, the raw feed which is an RTSP source and a processed feed which is created from the raw feed via localhost publishing. For the HLS access, I want persistent mutexes for the processed feed to have the last few minutes accessible by seeking backwards. But when enabling the always mutxing, it will also mux the raw reeds and that adds additional space.
The text was updated successfully, but these errors were encountered:
Describe the feature
At the moment, HLS muxing can happen in two ways:
(1) For all defined paths that are not on-demand
(2) For paths with an active reader
It would be nice to have a more selective approach. My use case is monitoring cameras locally, post-processing the input by transcoding and then thme locally recording, hooking them into OBS as well as publishing them to a remote server. For that I have a pair of paths for each camera, the raw feed which is an RTSP source and a processed feed which is created from the raw feed via localhost publishing. For the HLS access, I want persistent mutexes for the processed feed to have the last few minutes accessible by seeking backwards. But when enabling the always mutxing, it will also mux the raw reeds and that adds additional space.
The text was updated successfully, but these errors were encountered: