News:

--

Main Menu

Recent posts

#51
Windows / Re: MKV variable to constant a...
Last post by coolgit - April 08, 2024, 12:59:56 PM
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.
#52
Avidemux-French / Re: Problème de JobList avec L...
Last post by Zapata - April 08, 2024, 09:08:28 AM
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
#53
Windows / Re: MKV variable to constant a...
Last post by eumagga0x2a - April 07, 2024, 07:30:16 PM
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.
#54
Main version 2.6 / Re: Feature request: a toggle ...
Last post by szlldm - April 07, 2024, 07:21:45 PM
Request implemented, try a future nightly build.
#55
Main version 2.6 / Re: Feature request: a toggle ...
Last post by cachaito - April 06, 2024, 10:45:26 PM
Hi szlldm! I was referring to swapping the values.
#56
Windows / MKV variable to constant and t...
Last post by coolgit - April 06, 2024, 01:24:52 PM
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.
#57
Main version 2.6 / Re: New version Avidemux
Last post by HALUNKE - April 06, 2024, 09:50:06 AM
Quote from: eumagga0x2a on March 06, 2024, 05:36:41 PMNo time estimate possible. I wish it would have happend a few months ago, but I didn't have free time available.

Nightlies were, are and will be at least 90% of the time better (less buggy and more stable) than releases because very few users test nightlies and instead wait for releases, ensuring that glaring bugs make it into releases. The only benefit of release builds is the availability of published checksums.
https://avidemux.org/smif/index.php/topic,20460.0.html
#58
Main version 2.6 / Re: Feature request: a toggle ...
Last post by szlldm - April 06, 2024, 12:52:13 AM
Do you mean swapping the values, or swapping the position of the numeric inputs?
#59
Main version 2.6 / Feature request: a toggle butt...
Last post by cachaito - April 05, 2024, 07:31:16 PM
Hello! I don't know if this is a right place, but I'd to ask if adding a toggle swap  button for width and height of video size in Fit to Size filter would be possible? This small feature could be very handy. Something like that would be amazing:

#60
Main version 2.6 / New version Avidemux
Last post by wojtek.mm - April 05, 2024, 08:22:33 AM
Hello, when will be the new version of Avidemux ? Last version was in 2022.