recorded MP4 file issues

[Taps7734]

I am saving some streams using the following settings :

recordPath: D:/Stream/recordings/%path/%Y/%m-%d/%Y.%m.%d-%H.%M.%S
recordFormat: fmp4
recordPartDuration: 100ms
recordSegmentDuration: 30m
recordDeleteAfter: 24h

This is using MediaMTX 1.4.0 (also happened with 1.3.0 and 1.3.1) running on a Windows 2016 Server.

If I open the MP4 in Windows Media Player, then the video shows as 0:00 in length, and I am unable to scrub to a specific location in the video.

If I open in in the Windows 11 Photos App, then the length shows up as 26113:24. I am still unable to scrub.

If I open it in VLC, it takes a 40-60 seconds to open, but eventually shows the correct length, and I am able to scrub.

I also have these file available on an IIS website to view using video.js. They do seem to load, but it takes a minute or so to load no matter how small the files actually are.

This happens no matter how long the videos are. And It does it both when I use WHIP or RTMP to publish the video.

Is there a setting I am missing?

[Taps7734]

Just a quick reply to confirm I am still seeing the issue in 1.4.1 and 1.4.2.

My work around is to copy the MP4 with ffmpeg after MediaMTX is finished with it using:

ffmpeg -i inputfile.mp4 -c copy outputfile.mp4

The new files seem to be usable.

[aler9]

Hello, first of all, if you increase recordPartDuration to at least 1s, segments will load faster.

Second thing, recording segments are saved in the "fragmented MP4" format, that is robust against crashes but doesn't provide an explicit duration and has limited compatibility with some players. We cannot use the standard MP4 format since a single crash is enough to make the file completely unusable.

If you want to get your recordings in the Standard MP4 format, which provides the duration and is compatible with every player, you can enable the playback server as described in the README, and then specify the "mp4" output format:

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

Example:

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

[chance-emc]

Hi @aler9, I am experiencing the same issue as @Taps7734 and adding &format=mp4 still does not allow the video to be scrubbed. There are also inconsistencies with the duration parameter and the duration the video player actually displays.

For example, in Firefox, I can scrub these videos, but the duration is maxed out at 1 minute.

I used the same workaround @Taps7734 mentioned, converting the completed segments using ffmpeg when the segment completes, and those mp4s work perfectly fine.

Using the converted mp4s, I replaced the originals in the recordings/path folder, hoping those would be served at localhost:9996/list?path=<path>, but when one of the converted mp4s is in the folder, the page simply returns a blank page with the text moov box not found.

I would be really grateful if you could share some insight on how to get this working using &format=mp4. Otherwise, the only solution right now seems to be to serve the converted mp4 files ourselves and not use the built-in mediamtx playback server.

[tfelici]

same problem here. Playback using inbuilt mediamtx server (with and without &format=mp4) option, returns an unscrubbable file.
This seems to be because there is no defined moov atom in the mp4 file, which is resolved by executing the command
ffmpeg -i input.mp4 -movflags faststart -c copy output.mp4
however the mediamtx inbuilt server is unable to play this, so I need to serve this file via our own web server.
mediamtx playback should really serve scrubbable files as well as streamable, and not just something streamable

[aler9]

@tfelici the moov atom is present indeed.

The playback system is currently intended to be used inside an external UI that provides seeking - when you want to goto a certain time instant, the /get endpoint is called again with new parameters.

The impossibility to scrub (seek) into the raw MP4 depends on the fact that seeking requires the ability to access the recording file at a given position through the Range HTTP Header, but files are generated on-demand by using the start time and duration, therefore there's no file to seek, and the Range header has no effect.

This might be addressed in the future.

[tfelici]

Hello Harel, moving the moov atom to the beginning once recording is complete (i.e. when the streaming has ended) with ffmpeg -i input.mp4 -movflags faststart -c copy output.mp4 seems to resolve the issue, but the inbuilt mediamtx playback server is unable to read this file, but it can be read by the apache server ..

…

On 27/01/2025 07:45, Alessandro Ros wrote: @tfelici <https://github.com/tfelici> the moov atom is present indeed. The playback system is currently intended to be used inside an external UI that provides seeking - when you want to goto a certain time instant, the /get endpoint is called again with new parameters. The impossibility to scrub (seek) into the raw MP4 depends on the fact that seeking requires the ability to access the recording file at a given position through the Range HTTP Header, but files are generated on-demand by using the start time and duration, therefore there's no file to seek, and the Range header has no effect. This might be addressed in the future. — Reply to this email directly, view it on GitHub <#2831 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AB2PYTEPDQ6JRNRTQJW6CN32MXP3BAVCNFSM6AAAAABSDXYL2KVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTCOJWGU3TANQ>. You are receiving this because you were mentioned.Message ID: ***@***.***>