Record Segment Duration increases but incorrect

[JoshuaHintze]

Which version are you using?

v1.11.1

Which operating system are you using?

Linux amd64 standard

Describe how to replicate the issue

I have been using the recording feature of mediamtx with a security camera that is generating H.265 video. I'm saving out 5 second recordings into a tmpfs folder. When mediamtx first starts the duration reported by ffprobe is almost exactly 5 seconds. However if I let it sit for a few minutes the REPORTED duration grows but the actual frame count and segment does not. If I let it run for 8 hours the 5 second duration now ways its like 22.43 seconds, and it just keeps growing the longer mediamtx is running. The actual video clip is not 22.43 seconds long, when trying to concat together these files with ffmpeg -concat it does weird things obviously.

Just as an FYI this video camera (RTSP) does not have an audio channel. I saw from this OLD ticket that this issue happened before and it seems it was related to audio channel. (#2477)
 
Here is an example files after it has ran all night.

2025-01-22_10-02-31-729310.mp4

Here is the ffprobe output of this bad duration file

[mov,mp4,m4a,3gp,3g2,mj2 @ 0x557de18d7a80] Could not find codec parameters for stream 1 (Audio: none (ipcm / 0x6D637069), 8000 Hz, 1 channels, 42 kb/s): unknown codec
Consider increasing the value for the 'analyzeduration' (0) and 'probesize' (5000000) options
Input #0, mov,mp4,m4a,3gp,3g2,mj2, from '2025-01-22_10-02-31-729310.mp4':
  Metadata:
    major_brand     : mp42
    minor_version   : 1
    compatible_brands: mp41mp42isomhlsf
  Duration: 00:00:25.54, start: 0.000000, bitrate: 322 kb/s
  Stream #0:0(und): Video: hevc (Main) (hev1 / 0x31766568), yuv420p(tv), 2560x1440, 1502 kb/s, 15 fps, 15 tbr, 90k tbn, 15 tbc (default)
    Metadata:
      handler_name    : VideoHandler
      vendor_id       : [0][0][0][0]
  Stream #0:1(und): Audio: none (ipcm / 0x6D637069), 8000 Hz, 1 channels, 42 kb/s (default)
    Metadata:
      handler_name    : SoundHandler
      vendor_id       : [0][0][0][0]
Unsupported codec with id 0 for input stream 1

If I restart mediamtx here is a nice clean expected file

2025-01-22_10-13-36-210014.mp4

Here is the ffprobe of the good clean one

[mov,mp4,m4a,3gp,3g2,mj2 @ 0x55df65da0a80] Could not find codec parameters for stream 1 (Audio: none (ipcm / 0x6D637069), 8000 Hz, 1 channels, 127 kb/s): unknown codec
Consider increasing the value for the 'analyzeduration' (0) and 'probesize' (5000000) options
Input #0, mov,mp4,m4a,3gp,3g2,mj2, from '2025-01-22_10-13-36-210014.mp4':
  Metadata:
    major_brand     : mp42
    minor_version   : 1
    compatible_brands: mp41mp42isomhlsf
  Duration: 00:00:05.04, start: 0.000000, bitrate: 1644 kb/s
  Stream #0:0(und): Video: hevc (Main) (hev1 / 0x31766568), yuv420p(tv), 2560x1440, 1513 kb/s, 15 fps, 15 tbr, 90k tbn, 15 tbc (default)
    Metadata:
      handler_name    : VideoHandler
      vendor_id       : [0][0][0][0]
  Stream #0:1(und): Audio: none (ipcm / 0x6D637069), 8000 Hz, 1 channels, 127 kb/s (default)
    Metadata:
      handler_name    : SoundHandler
      vendor_id       : [0][0][0][0]
Unsupported codec with id 0 for input stream 1

But like I mentioned if it sits for 5 minutes that 5 second duration changes to 5.5 seconds etc.

Here is my relevent mediamtx.yml config

writeQueueSize: 1024
recordFormat: fmp4
recordPartDuration: 100ms # I've tried 1s
recordSegmentDuration: 5s
recordDeleteAfter: 2m

I hope this helps.

Server logs

There is nothing in the server logs that says dropping frames or any particular issues I can see when this is happening.

Here is some of it

0|mediamtx  | 2025/01/22 10:21:31 DEB [path 312/ptz/low] [RTSP source] [c->s] SETUP rtsp://192.168.1.115:554/media2/video2/metadata RTSP/1.0
0|mediamtx  | Authorization: Digest username="admin", realm="c4790529f760", nonce="875b8fa9ec425ef86e0dad2186cc6536", uri="rtsp://192.168.1.115:554/media2/video2/metadata", response="cd369c658a0aac838dfaff2c126f07fd"
0|mediamtx  | CSeq: 6
0|mediamtx  | Session: 21bbdffc41bbdffc3dbbdffce9bbdff
0|mediamtx  | Transport: RTP/AVP/TCP;unicast;interleaved=4-5
0|mediamtx  | User-Agent: gortsplib
0|mediamtx  |
0|mediamtx  | 2025/01/22 10:21:31 DEB [path 314/ptz/high] [RTSP source] [s->c] RTSP/1.0 200 OK
0|mediamtx  | CSeq: 6
0|mediamtx  | Session: 646d60bb8b1d60bb456d60bb5e1d60b;timeout=60
0|mediamtx  | Transport: RTP/AVP/TCP;unicast;interleaved=4-5;ssrc=a4cc37e;mode="PLAY"
0|mediamtx  |
0|mediamtx  | 2025/01/22 10:21:31 WAR [path 314/ptz/high] [recorder] skipping track 3 (Generic)
0|mediamtx  | 2025/01/22 10:21:31 INF [path 314/ptz/high] [recorder] recording 2 tracks (H265, G711)
0|mediamtx  | 2025/01/22 10:21:31 INF [path 314/ptz/high] [RTSP source] ready: 3 tracks (H265, G711, Generic)
0|mediamtx  | 2025/01/22 10:21:31 DEB [path 314/ptz/high] [RTSP source] [c->s] PLAY rtsp://192.168.1.117:554/media2/video1 RTSP/1.0

0|mediamtx  | 2025/01/22 10:21:46 DEB [path 313/ptz/high] [recorder] closing segment /tmp/segments/313/ptz/high/2025-01-22_10-21-41-476796.mp4
0|mediamtx  | 2025/01/22 10:21:46 DEB [path 312/ptz/high] [recorder] closing segment /tmp/segments/312/ptz/high/2025-01-22_10-21-41-578259.mp4
0|mediamtx  | 2025/01/22 10:21:46 DEB [path 314/ptz/high] [recorder] closing segment /tmp/segments/314/ptz/high/2025-01-22_10-21-41-567920.mp4
0|mediamtx  | 2025/01/22 10:21:46 DEB [path 313/static/high] [recorder] closing segment /tmp/segments/313/static/high/2025-01-22_10-21-41-589364.mp4
0|mediamtx  | 2025/01/22 10:21:46 DEB [path 313/ptz/high] [recorder] creating segment /tmp/segments/313/ptz/high/2025-01-22_10-21-46-470081.mp4
0|mediamtx  | 2025/01/22 10:21:46 DEB [path 314/ptz/high] [recorder] creating segment /tmp/segments/314/ptz/high/2025-01-22_10-21-46-558833.mp4
0|mediamtx  | 2025/01/22 10:21:46 DEB [path 312/ptz/high] [recorder] creating segment /tmp/segments/312/ptz/high/2025-01-22_10-21-46-545579.mp4
0|mediamtx  | 2025/01/22 10:21:46 DEB [path 313/static/high] [recorder] creating segment /tmp/segments/313/static/high/2025-01-22_10-21-46-625138.mp4
0|mediamtx  | 2025/01/22 10:21:46 DEB [path 314/static/high] [recorder] closing segment /tmp/segments/314/static/high/2025-01-22_10-21-41-726760.mp4
0|mediamtx  | 2025/01/22 10:21:46 DEB [path 312/static/high] [recorder] closing segment /tmp/segments/312/static/high/2025-01-22_10-21-41-739132.mp4

Network dump

No response

[JoshuaHintze]

I was wrong, it is outputing an audio channel that is G.711u or (mlaw). Perhaps mediamtx has a hard time with this audio codec?

Here is VLC information

[JoshuaHintze]

Some more information for @aler9 - I just disabled the audio channel on the security camera and it fixed the invalid duration values. I can live with this for now. It would be great to figure out why mediamtx slowly increases durations when the audio channel is enabled. Obviously ffmpeg didn't recognize that audio channel G.711u (mlaw), but VLC does so maybe its an audio codec issue on the machine?

[kimud6003]

The same bug happens to me.

[aler9]

@JoshuaHintze you need to provide some additional data in order to allow to replicate the issue.

First of all, in server logs, we need the "[rtsp source] [c->s] DESCRIBE" line (and following lines), since they contain track details and in particular details of the audio track.

Second, thing, some seconds of network dump (of the server reading the stream from the camera, WITHOUT any additional reader) would be quite useful. It can be generated in this way:

1. Download wireshark (https://www.wireshark.org/)
2. Start capturing on the interface used for exchanging packets * If the server and the external hardware or software are both installed on your pc, the interface is probably "loopback", otherwise it's the one of your network card.
3. Start the server and replicate the issue
4. Stop capturing, save the result in .pcap format
5. Attach

[kimud6003]

I found out the cause in my promblem.
The reason was the video itself.
Even if I set it to cut the video at 1-second intervals, since the i-frames were placed at 8-second intervals, the video ended up having a length of 8 seconds.
After modifying the code to process it at 1-second intervals, I discovered that if there were no i-frames, the video would not play.
I concluded that my issue was not a problem with MediaMTX but rather with the video itsel

[JoshuaHintze]

@aler9 - I'll try to replicate next week and grab a network log from wireshark.