July 07, 2022, 02:29:48 PM

News:

--


Video too short

Started by Kohlhaas, June 19, 2022, 09:15:13 AM

Previous topic - Next topic

Kohlhaas

June 19, 2022, 09:15:13 AM Last Edit: June 19, 2022, 09:40:51 AM by Kohlhaas
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.

eumagga0x2a

Unrelated to the issue, appImages named "avidemuxUniversal" are for really ancient Linux distributions, anything starting with Debian oldstable should use nightlies from the 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.

Kohlhaas

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

Kohlhaas

Sorry, I was not allowed upload more pictures ...

eumagga0x2a

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.

Kohlhaas

June 21, 2022, 02:51:23 PM #5 Last Edit: June 21, 2022, 02:53:06 PM by Kohlhaas
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.