Is there a way to fix PTS in multiple files at once?

[comienzo2093]

Hi,

I am working with avidemux to fix mp4 files with wrong pts.

When I load these files I get a message like the one below:

"This video contains B-frames, but the presentation time stamps (PTS) are either missing or monotonously increasing. Avidemux can try to reconstruct the correct PTS by decoding the entire video. This can take a long time. Continue?

And I click Yes so that I can fix the file correctly.


The problem is that I have about 1200 files to fix. Loading them one by one, waiting for them to decode and clicking Yes is quite painful and requires a lot of patience.

Is it possible to automate the above tasks using the CLI? I managed to install avidemux on ubuntu and load the files, but I don't know how to do the part where I click yes on the dialogue asking me to modify the pts.

There doesn't seem to be a way to do the same thing with ffmpeg (the gen pts command doesn't solve the problem).

I've been looking at alternatives like ffmpeg, mp4box, etc. for a few days now, but avidemux is the only one that solves the problem without re-encoding.

Thanks for making such a good program. Please help me a little.

[eumagga0x2a]

PTS reconstructed in Avidemux by decoding are kept only in memory until the video is exported (saved) in a container format which supports PTS (i.e. not AVI) – and there is a special case of VC1 codec where PTS are incorrect, but trying to reconstruct them from DTS makes things worse.

When all files you try to fix are just H.264 videos with an AAC audio track stored in AVI container, a bash one-liner

Code Select Expand

for i in *.avi; do /full/path/to/avidemux_cli --nogui --load $i --video-codec copy --audio-codec copy --output-format MP4 --save /path/to/output/directory/$(echo $i | sed 's/avi$/mp4/'); done
should load every file with ".avi" as filename extension in the current directory using the command-line version of Avidemux and save it as a MP4 file with mp4 as filename extension.

You must adjust paths to match your system. Everything is case-sensitive! "*.AVI" won't be matched and the extension won't be replaced by mp4.

[sark]

@eumagga0x2a

Just to clarify - I've had this issue before, and Avidemux does not repair in  Copy mode. The repair on loading is only saved if reencoded - correct?  That's my experience. Am I missing something?
-

[eumagga0x2a]

Avidemux does not repair in  Copy mode. The repair on loading is only saved if reencoded - correct?

No, of course it does. Except if you save in a format which doesn't retain PTS as AVI or if video is VC1.

[comienzo2093]

Yes, it finally works with the --nogui option!

I've been struggling with this for weeks and you've solved it. Thank you.
By the way, in my case, when I specify the output format as MP4, I get the error below.



```
Too short!

The saved video is incomplete. The error occurred at 00:xx:xx:xxx(xx%). This may happen as result of invalid timestamps in the video.

Error -22 writing audio packet
```


To fix this, I first output to MATROSKA format instead of MP4, and then reloaded that .mkv file and output to MP4 format. After that, I no longer got the error message and it output to MP4 properly. This solved the problem,  but it would be nice if there was a better solution.


With your help, here are the commands I used

Code Select Expand

/full/path/to/avidemux_2.8.1_cli.appImage --nogui --load /path/to/video.mp4 --video-codec copy --audio-codec copy --output-format MP4 --save /path/to/output/directory/video.mp4 --quit
The error log is shown below.

[adm_lavLogCallback] 09:51:58-122 [lavc] Application provided invalid, non monotonically increasing dts to muxer in stream 0: 116474000 >= 116474000
[muxerFFmpeg::saveLoop] Error -22 writing audio packet


I can provide a link to a sample video(.mp4 file) here for reproduction if needed.
I'm using avidemux 2.8.1.

[eumagga0x2a]

I'm using avidemux 2.8.1.

Actually, 2.8.1 is very old, quite a lot of issues have been fixed since then. You might want to build Avidemu from source (which is very easy on Linux) using the latest git master.

Too short!

The saved video is incomplete. The error occurred at 00:xx:xx:xxx(xx%). This may happen as result of invalid timestamps in the video.

Error -22 writing audio packet

Probably a very high timebase denominator in the source video which Avidemux substitutes by an approximation, starting a cascade of failures. This is not yet addressed by the current development, unfortunately, but very high on the todo list.

The difficulty is that back then some devices could not handle videos where numerator was very small like 1, denominator very high like 1,000,000 and therefore timestamps became huge. Therefore, every improvement in handling such videos will break compatibility with some ancient hardware.

Of course, it is a video packet which cannot be written due to timestamp collision, not an audio one. The bug in debug message is fixed meanwhile – at least this one.

I can provide a link to a sample video(.mp4 file) here for reproduction if needed.

Yes, please do, if the video is innocuous enough. I need the source video, of course, not the output. It would be a bonus when the sample were not too large, thanks.

PS: Don't overestimate my Korean

[sark]

Avidemux does not repair in  Copy mode. The repair on loading is only saved if reencoded - correct?

No, of course it does. Except if you save in a format which doesn't retain PTS as AVI or if video is VC1.

Strange... This has not worked for me in the past, but working now.

[comienzo2093]

Actually, 2.8.1 is very old, quite a lot of issues have been fixed since then. You might want to build Avidemu from source (which is very easy on Linux) using the latest git master.

Thanks for the detailed explanation. I kept failing to build on Ubuntu 23.04, and then after installing libass-dev, the build succeeded!

And even in the latest version, there seems to be an issue with VAAPI not working properly only in the CLI, but it's possible that I'm missing something or it's something else, so I'll look into it a bit more, thanks.

[eumagga0x2a]

VA-API and other hw accels are available in the graphical app only.

I'll look into adding the developer package for libass to convenience scripts both for Debian-derivatives and for Fedora, thanks.

[eumagga0x2a]

I'll look into adding the developer package for libass to convenience scripts both for Debian-derivatives and for Fedora

Done, albeit untested.

[sark]

Avidemux does not repair in  Copy mode. The repair on loading is only saved if reencoded - correct?

No, of course it does. Except if you save in a format which doesn't retain PTS as AVI or if video is VC1.

Strange... This has not worked for me in the past, but working now.

Just for reference, I've now discovered that like comienzo2093's experience, this only works when exporting as MKV (same errors if saving as MP4).

[eumagga0x2a]

Just for reference, I've now discovered that like comienzo2093's experience, this only works when exporting as MKV (same errors if saving as MP4).

Please provide a sample. Upon a quick test with a roundtrip from H.264 with B-frames in MP4 saved as AVI, loaded by Avidemux, PTS reconstructed and then saved in copy mode as MP4, no problems surfaced (maybe except of a slight A/V desync, easily corrected by delaying audio by 40 milliseconds).

[sark]

Just for reference, I've now discovered that like comienzo2093's experience, this only works when exporting as MKV (same errors if saving as MP4).

Please provide a sample.

https://filebin.net/frovuiy29n8kj48u

[eumagga0x2a]

Thank you for the sample. I consider the approach of creating a conflict between fps encoded in codec extradata and actual timing at the container level invalid and fundamentally incompatible with Avidemux.

Nevertheless, I was able to produce a somewhat working MP4 file by saving "Broken.mp4" as AVI, then loading the AVI in Avidemux, letting it reconstruct the PTS and saving the result as MP4. By the way, "Broken.mp4" seems to be really broken as mpv complains about it as well.

[sark]

Oddly, the following three files followed exactly the same routine and work fine.

https://easyupload.io/hodjhv

Saving as mkv also solves the problem. Just odd that there is an inconsistency with mp4.