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.78k stars 1.4k forks source link

Enable serving recordings with the playback server is broken #3183

Closed hlacikd closed 1 month ago

hlacikd commented 3 months ago

Which version are you using?

v1.6.0. (arm64v8)

Which operating system are you using?

Describe the issue

Description

Describe how to replicate the issue

Current implementation of serving recordings with the playback server is broken. Altough files are stored on disk according to the setup, Playback API is stuck. Let me begin with the configuration

mediamtx.yml for record and playback is configured as following :

  # Default path settings -> Record and playback

  # Record streams to disk.
  record: yes
  # Enable serving recordings with the playback server.
  playback: yes
  # Path of recording segments.
  # Extension is added automatically.
  # Available variables are %path (path name), %Y %m %d %H %M %S %f %s (time in strftime format)
  recordPath: /video/%Y%m%d/%path_%Y%m%d_%H%M%S_UTC
  # Format of recorded segments.
  # Available formats are "fmp4" (fragmented MP4) and "mpegts" (MPEG-TS).
  recordFormat: fmp4
  # fMP4 segments are concatenation of small MP4 files (parts), each with this duration.
  # MPEG-TS segments are concatenation of 188-bytes packets, flushed to disk with this period.
  # When a system failure occurs, the last part gets lost.
  # Therefore, the part duration is equal to the RPO (recovery point objective).
  recordPartDuration: 1000ms
  # Minimum duration of each segment.
  recordSegmentDuration: 10m
  # Delete segments after this timespan.
  # Set to 0s to disable automatic deletion.
  recordDeleteAfter: 240h

Video segments are split according to configuration (10m for segment).

This is my current content

Index of /20240401/
[../](http://a.vin.lan/video/)
[lp_20240401_164502_UTC.mp4](http://a.vin.lan/video/20240401/lp_20240401_164502_UTC.mp4)                         01-Apr-2024 16:55           189141848
[lp_20240401_165501_UTC.mp4](http://a.vin.lan/video/20240401/lp_20240401_165501_UTC.mp4)                         01-Apr-2024 17:05           189680567
[lp_20240401_170502_UTC.mp4](http://a.vin.lan/video/20240401/lp_20240401_170502_UTC.mp4)                         01-Apr-2024 17:15           189384215
[lp_20240401_171502_UTC.mp4](http://a.vin.lan/video/20240401/lp_20240401_171502_UTC.mp4)                         01-Apr-2024 17:25           189665206
[lp_20240401_172503_UTC.mp4](http://a.vin.lan/video/20240401/lp_20240401_172503_UTC.mp4)                         01-Apr-2024 17:35           189273243
[lp_20240401_173503_UTC.mp4](http://a.vin.lan/video/20240401/lp_20240401_173503_UTC.mp4)                         01-Apr-2024 17:45           189447958
[lp_20240401_174504_UTC.mp4](http://a.vin.lan/video/20240401/lp_20240401_174504_UTC.mp4)                         01-Apr-2024 17:55           189030304
[lp_20240401_175504_UTC.mp4](http://a.vin.lan/video/20240401/lp_20240401_175504_UTC.mp4)                         01-Apr-2024 18:05           189227580
[lp_20240401_180505_UTC.mp4](http://a.vin.lan/video/20240401/lp_20240401_180505_UTC.mp4)                         01-Apr-2024 18:15           188976113
[lp_20240401_181505_UTC.mp4](http://a.vin.lan/video/20240401/lp_20240401_181505_UTC.mp4)                         01-Apr-2024 18:17            48991578

However playback server servers following : (URL http://a.vin.lan/playback/list?path=lp)

[
    {
        "start": "2024-04-01T16:45:02Z",
        "duration": 600.662111111
    },
    {
        "start": "2024-04-01T16:55:01Z",
        "duration": 4985.530044444
    }
]

As you can see playback server got "stuck" at second video segmet and its counting its duration to infinite ...

Did you attach the server logs?

no

Did you attach a network dump?

no

aler9 commented 1 month ago

Hello, first of all you are losing precision since you are not saving the milliseconds (%f) in the file name of record segments:

  # Available variables are %path (path name), %Y %m %d %H %M %S %f %s (time in strftime format)
  recordPath: /video/%Y%m%d/%path_%Y%m%d_%H%M%S_UTC

The playback server extracts the start date of segments from their names, and if you're not storing the milliseconds, the start date gets truncated at the seconds.

Second thing, the playback server is designed in order to return timespans, which might not correspond to segments. If two segments correspond to two consecutive time instants, they are merged into a single entry. This entry here:

    {
        "start": "2024-04-01T16:55:01Z",
        "duration": 4985.530044444
    }

corresponds to about 9 segments, which is coherent to the segment list you provided.

If you want to obtain the segment list instead of the timespan list, there's the Control API and the endpoint:

http://localhost:9997/v3/recordings/get/pathname