-
Notifications
You must be signed in to change notification settings - Fork 1.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Some recordings have wrong duration #2477
Comments
Hello, in order to identify the issue we need
My guess is that some video frames get assigned a negative timestamp, due to the video / audio synchronization algorithm of the server. FFmpeg decodes timestamps into unsigned variables, the sign is lost and is interpreted as the most significant bit, and here you have your distant point in the future. |
I have recorded some segments and replicated the bug, again. I'll forward them to you privately via mail. The log did not reveal anything noteworthy. No lost packets or the like. |
Thanks for providing the recording file that allowed to replicate the issue. There's a small delay between video timestamp and audio timestamp, and the first audio samples get a negative timestamp, which, as i have already mentioned, is not supported by fMP4. I created a patch that discards samples with a negative timestamp. Please test the nightly release in this page ("Artifacts", "binaries") and let me know if it fixes the issue: https://github.com/bluenviron/mediamtx/actions/runs/6920341925 |
While testing the nightly release you provided, I again noticed incorrect segments. I have sent you another test sample. |
The sample you sent has the same exact problem as before, it has a negative base timestamp in the first part, in the audio track. I don't understand why it's happening, so i've updated the patch in order to print the base timestamp on the console, please test it and attach a server log: https://github.com/bluenviron/mediamtx/actions/runs/6923278140 |
Here's the server log:
Durations are still inconsistent, i.e. some are okay, some are not:
#!/bin/bash
cd /dev/shm/recordings/64/high/
for file in *.mp4; do
duration=$(ffprobe -v quiet -print_format json -show_format -show_streams "$file" 2>&1 | jq -r '.format.duration')
echo "Duration of $file: $duration seconds"
done |
@0ip thanks again for providing feedback that allowed to replicate the residual bug (if you take a look at BASE TIME, there are some lines that ends with large numbers, that in reality are negative signed integers casted to unsigned integers). I should have fixed this scenario too. Here's another nightly release: https://github.com/bluenviron/mediamtx/actions/runs/6962789837 |
Thank you. That last iteration did the trick! Now all recordings have consistent, plausible durations. |
This issue is mentioned in release v1.3.1 🚀 |
This issue is being locked automatically because it has been closed for more than 6 months. |
Which version are you using?
v1.1.1
Which operating system are you using?
Describe the issue
Some recordings of my security camera have a wrong or absurdly high length duration instead of the actually set 10 seconds. While this problem doesn't show up in VLC (duration is said to be 10 s) and the videos play fine there, ffmpeg and chrome report the wrong durations:
ffprobe of a video that is affected by this bug:
ffprobe of a normal video:
relevant config parts:
I can forward you the files via email if desired.
Describe how to replicate the issue
Did you attach the server logs?
no
Did you attach a network dump?
no
The text was updated successfully, but these errors were encountered: