Hello,
I am using Avidemux 2.8.0 on three platforms:
Linux Mint (Cinnamon), MX Linux (xfce) and Mac OS (Catalina).
With Avidemux, I mainly edit .TS-files recorded from the TV: stitching, cutting out commercials, and removing the channel logo.
Lately, however, I often have the same problem with the Linux versions: Avidemux breaks in the middle with the error "Video too short".
On Mac OS everything works fine (of course: same movie and same conversion settings).
I ask for help, because I want to say goodbye to Mac OS so little by little.
Thanks in advance!
Addendum:
In the meantime I have also tried the "nightly build" 2.8.1 (avidemuxUniversal_amd64_220617_166.app):
Same problem, no change.
Unrelated to the issue, appImages named "avidemuxUniversal" are for really ancient Linux distributions, anything starting with Debian oldstable should use nightlies from the appImage4Buster (https://avidemux.org/nightly/appImage4Buster/) directory.
The problem itself happens when the timing of the source video(s) doesn't match the calculated or declared time base as required by MP4 format. Your screenshot shows that you re-encode rather than using copy mode. In this case it is trivial to work around the underlying issue by adding "resample fps" video filter with a suitable standard (not custom!) fps to force the timing of output to conform to it.
Another, less promising approach would be to force clock in the MP4 muxer to e.g. 90 kHz which may help prevent timestamp collisions when timing happens to be irregular.
Quote from: Kohlhaas on June 19, 2022, 09:15:13 AMOn Mac OS everything works fine (of course: same movie and same conversion settings).
Given the same Avidemux version, this is highly unlikely to be possible in this universe.
During Avidemux development, the details of the way to extract and use timing from source, pass it through the editor and filter chain to encoders and to consume it in muxers evolved, so ultimately a sample video with exact steps to reproduce the timestamp collision would be necessary to diagnose the exact cause of the collision for the given muxer, but as the workaround is readily available and straightforward, you might want to try it right away.
Thanks first of all for the quick reply.
But unfortunately the suggested solutions did not help (or I did something wrong).
Neither the 90kHz did anything, nor my various attempts with fps filter settings (see pictures).
I suspect that the problem happens during the transition from the first to the second .TS file.
I have attached the corresponding mediainfo's.
As for the universe: it is huge and the most amazing things happen.
Also attached: two pictures of the "about Avidemux", one from MX Linux, the other from Mac OS.
Best regards
Sorry, I was not allowed upload more pictures ...
Wrong filter according to screenshot. You need "resample fps", not "change fps".
Whenever possible, please upgrade to the latest 2.8.1 nightly, 2.8.0 is very old and buggy.
By the way, running Avidemux (also as appImage) for Linux in a terminal prints the Avidemux log to stdout, which includes the version – no need to post this information as a screenshot. On macOS, Avidemux log is written to $tmp/admlog.txt unless Avidemux2.8 is run from the Terminal app.
Similarly, MediaInfo has also a textual output which you can copy and paste into your reply.
The wrong filter was my mistake, unfortunately I am only rudimentarily familiar with the many possibilities Avidemux offers.
But now it works!!! ;D ;D ;D
Best regards and many thanks for the professional help.