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. |
aler9
added a commit
that referenced
this issue
Nov 19, 2023
|
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 |
aler9
added a commit
that referenced
this issue
Nov 19, 2023
aler9
added a commit
that referenced
this issue
Nov 19, 2023
|
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 |
aler9
added a commit
that referenced
this issue
Nov 22, 2023
|
@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. |
aler9
added a commit
that referenced
this issue
Nov 23, 2023
|
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. |
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
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: