add playback server (#2452)

[aler9]

This adds a playback server that allows to download existing recordings.

Sub-features:

• Recordings are seekable by absolute timestamp
• playback starts from the first available frame after the timestamp and goes on until a given duration
• Recording segments are automatically concatenated and remuxed into a single file
• Multiple tracks are supported, all codecs already supported by the recording feature are supported by the playback server too
• The API is natively compatible with any browser and the endpoint can be inserted directly into an HTML video tag

Usage

Enable the playback server in the configuration file:

playback: yes
playbackAddress: :9996

Open the URL in the browser:

http://localhost:9996/get?path=[mypath]&start=[start_date]&duration=[duration]&format=[format]

Where:

• [mypath] is the path name
• [start_date] is the start date in RFC3336 format
• [duration] is the maximum duration of the recording in Golang format (i.e. 20s, 20h)
• [format] must be fmp4

All parameters must be url-encoded.

For instance:

http://localhost:9996/get?path=stream2&start=2024-01-14T16%3A33%3A17%2B00%3A00&duration=200s&format=fmp4

Nightly binaries

https://github.com/bluenviron/mediamtx/actions/runs/7521944954

(click on "artifacts", "binaries")

Todo

• add tests
• update README

[codecov]

Codecov Report

Attention: 234 lines in your changes are missing coverage. Please review.

Comparison is base (9b270ad) 51.28% compared to head (1c31f18) 51.40%.
Report is 1 commits behind head on main.

Files	Patch %	Lines
internal/playback/fmp4.go	66.55%	65 Missing and 33 partials ⚠️
internal/playback/server.go	55.61%	68 Missing and 15 partials ⚠️
internal/conf/path.go	18.51%	22 Missing ⚠️
internal/core/core.go	52.38%	17 Missing and 3 partials ⚠️
internal/api/api.go	0.00%	7 Missing ⚠️
internal/core/path_manager.go	95.83%	2 Missing ⚠️
internal/record/path.go	92.85%	1 Missing and 1 partial ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #2906      +/-   ##
==========================================
+ Coverage   51.28%   51.40%   +0.11%     
==========================================
  Files         128      130       +2     
  Lines       12103    12583     +480     
==========================================
+ Hits         6207     6468     +261     
- Misses       5445     5614     +169     
- Partials      451      501      +50     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[eravellaSC]

I can close #2901 right?

[aler9]

@eravellaSC your PR implements management of recording segments, while this PR implements downloading of recording segments - they're two distinct features, if you complete your PR it can be merged too.

[eravellaSC]

@aler9 Oh I am sorry I thought the features of #2901 were going to be added in this PR. I'll finish mine.

[pikachu937]

Hello. You are best, again.
Format only fmp4? You later plane add mpegts(may be playlist hls)?

[t3therdev]

Hi All, this looks very promising. Is it possible to add some layer of authentication security to this? Such as the read user/pass we do on HLS, etc?

Great works as always @aler9 , thank you.

[t3therdev]

@aler9 testing, seems time format needs to be in RFC3339 format?
https://it-tools.tech/date-converter
2024-01-16T23:18:11-05:00 (but url encoded) seems to work 2024-01-16T23%3A08%3A41-05%3A00

[aler9]

Hello everyone,

Format only fmp4? You later plane add mpegts(may be playlist hls)?

Regarding MPEG-TS, this can be added either my me or by another contributor.

Regarding serving recordings in HLS format, i developed that feature for a commercial project in the past, but i can't see any advantage with respect to returning files that can be natively inserted into <video> tags. Maybe the only advantage lies in the ability of providing both the recorded stream and the live one into the same page, this might be interesting, but i'm not sure on how to manage eventual gaps.

Is it possible to add some layer of authentication security to this? Such as the read user/pass we do on HLS, etc?

Yes, my idea is to add an authentication layer that is shared among all the services exposed by MediaMTX, including all protocols and the API, and to let the user decide the authentication mechanism to use, by chosing between credentials hardcoded in the configuration file, external endpoints and JWTs.

seems time format needs to be in RFC3339 format?

yes, it's the standard Golang way to parse dates from strings, it's documented in lots of places.

[t3therdev]

@aler9 thanks for the update. Do you know what release this will be planned to be in?

[github-actions]

This issue is mentioned in release v1.5.0 🚀
Check out the entire changelog by clicking here

[t3therdev]

@aler9 thanks! Will test and advise. I would imagine adding the authentication support would be next?

[t3therdev]

@aler9 how does the api request for playback start time work? is it looking for the file names? i didn't review the code yet, but just wanted to see how the request knows if there is video.