Avidemux Forum

Recently I needed to edit a HEVC video that was generated
by standard HEVC output of OpenCV (ffmpeg 5.0.1).

Opening gives no error message but only a black screen.
(Opening it with VirtualDub2 (2020), ffmpeg CLI or MPC-HC: no problem).

Can you tell what is going wrong here?
Is it a bug of ADM? (Or maybe of HEVC-type generated?)

https://c.gmx.net/@1155842887640945833/bJH2qPQ-Tm279HnSREF4SA

EDIT:
It is lossless HEVC.

Quote from: szlldm on April 08, 2024, 04:44:26 PMThat is the right URL. When the next nightly build will be built, you will find it there.

Great! Can't wait. Best regards!

That is the right URL. When the next nightly build will be built, you will find it there.

I will check it out, thank you! Only one thing: I know about https://www.avidemux.org/nightly/win64/ - where I can find a feature builds?

What MP4 got to do with my post? The file is MKV. It is Star Trek series where it was filmed in 23.976 and the cgi part in 29.970. The timestamp correctly uses both so the audio is in sync. As my first post avidemux created a weird timestamp that was not compatible with the mkv file.

Seriously why can't avidemux just use the original mkv timestamp and not change it.

Bonjour, j'ai bien lu vos consignes. Je n'ai pas l'ordinateur en question sous la main.
Donc j'essaierai dès que je pourrai, peut-être le week-end prochain, de relancer un encodage avec une version plus récente d'Avidemux, et je vous enverrai les fichiers de log.

Merci à vous

Avidemux tries to restore original timestamps in specific cases when variable frame rate in MKV is an artifact of timestamps being not precisely representable with 1 millisecond resolution in MKV: remuxing a MP4 with a CFR video track at 30000/1001 fps (time base 1001/30000) to a MKV and back to MP4 using Avidemux results in a CFR video like the original. Performing this roundtrip with ffmpeg creates a VFR MP4, the CFR property is lost.

In some rare circumstances, guessing the original timing may go wrong. Please provide a sample MKV then, thank you.

Official releases which are older than a couple of weeks are only useful to verify that an issue found in a nightly build is not a recent regression.

Request implemented, try a future nightly build.

Hi szlldm! I was referring to swapping the values.

OK i have lots of mkv files and and each need trimming once. Trimming is start to 44ish minutes.

Each MKV file are vfr and each has vfr timestamps. I then proceeded to cut each file and copy both audio and video to new mkv file. No encoding whatsoever. Some files worked and has vfr but some were converted to cfr without my say so. I want all files to be vfr as this is important.

Secondly, when converting the original timestamps is:

# timecode format v2
0.00
42.00
83.00
125.00
167.00
209.00
250.00
292.00
334.00
375.00 and so on.

After new mkv file was created the timestamps changed to:

# timecode format v2
111.00
153.00
194.00
236.00
278.00
320.00
361.00
403.00
445.00
486.00 and so on.

The above timestamp is wrong. It should be the same as the original.

For example if i were to trim a video from 0 to 60,000 frames out of 65,000 frames then the new timestamps would be 60,000 frames not 65,000 from the original. If i did this myself i would open timestamp into notepad++ and delete lines 60,002 to 65,001. I do not need to change anything else.

When i cut a video from 0 to 45:00.364, frames 0 of 65069, the original timestamp shown, using spreadsheet, arrived correctly at 45:00.323. The avidemux timestamp arrived incorrectly at 45:00.434. I do not know what methods you are using but would it be easier just export original timestamp, delete lines no longer needed, then import new timestamp, the same way as i did it by hand above.

So why does avidemux starts with 111.00, it causes audio/video sync to be off around 100 to 120 ms.

Edit:additional info.

I originally used the last official release and got 0 of 65064, 65064 frames, 5 frames short, video length 45:00.114. Not a big deal as they were black frames. I updated using the latest nightly built and got 0 of 65069, 65069 frames, video length 45:00.323, which is correct and perfectly cut. Obviously there has been some fixes so any chance of an official build so users can cut at the correct frame/time and get the right amount of frames.