Avidemux Forum

Okay, thanks for clearing.
I hope it can be added.

After last help all encoding run without any problems. But now I encountered strange problem. Have 2 recordings (.ts), made from the same stream and 24 hours apart, each recording has 2 audio tracks. Encoding settings identical on both recordings and on both tracks. 3 tracks are perfectly in sync, but 4th track is out of sync.

Video 1 audio track 0 is out of sync
Video 1 audio track 1 is in sync
Video 2 audio track 0 is in sync
Video 2 audio track 1 is in sync

The sync is almost precise at beginning of output file, and 1.5s at the end. The bad thing is that I can not replicate on small block of the file.

Media info from the original .ts

MPEG Audio Version 1 Layer 2 Constant 160 kb/s 160 kb/s

Media info from the resulting .mkv

AAC LC SBR PS HE-AACv2 NBC A_AAC-29 2 channels

Attached is .py script for both encodings and Media Info from all 4 files (2x original, 2x result).

Other than Copy mode, everything is YUV 4:2:0 in Avidemux.

Hi,
is there an option, that Avidemux can work and output with RGB colorspace?
After editing and saving the video it's limited to chroma subsampling at YUV 4:2:0 .
Already in the preview without anything done it even looks as if there is compression with YUV 4:2:0.

Quote from: Jay123210599 on August 18, 2025, 07:23:26 PMWhat if I use the 2.8.8 version?

You have arrived from the future then.

Quote from: eumagga0x2a on August 17, 2025, 07:44:18 AMFLAC raw or ogg-encapsulated streams are not supported for external audio tracks in Avidemux. You need to convert them into uncompressed 16 or 24 bit signed integer WAV files first (which is lossless) using flac executable or a tool which provides the functionality like approximately built ffmpeg.

What if I use the 2.8.8 version?

I started out with a 6gb volume for testing, and found that 3gb is enough for the time being.
I know the source directory doesn't have to be case sensitive, it's just a script for me to build the latest, everyone should adjust to their own need, including replacing the ARM specific build as appropriate.

Thank you, a nice idea to reduce SSD wear. BTW, I am surprised that 3 GiB suffice.

Just one detail: the source tree doesn't have to reside on a case-sensitive filesystem. Only the build root must be case-sensitive. Additionally, the build root doesn't need to be inside the top source directory, this is neither required nor recommended. Therefore repeated cloning on each build can be avoided.

The build environment requires a case sensitive volume.
I don't have one on my computer.
The next best thing would be to have a temp volume for that.
What better option than to use a RAM drive, formatted as a case sensitive volume?
Here's the script.
It installs the required homebrew packages, mounts the volume, runs the package build script, copies the DMG file and then ejects the RAM drive.
Works for me one macOS Sequoia 15.6, Apple Silicon.
Hope you find it useful.

https://gist.github.com/moshegottlieb/b21fa414c2f3d5c992c1a1bc9ed5d1e6

Have you done the SRT thing? SRTs will provide you the subs you need (for MP4s in VLC, anyway), and when editing the video, cutting parts out or whatever, well, you literally have your work cut out for you ; SRTs can be edited, but it's a lot of painstaking manual effort to change all the timestamps after the points of edit, and depending on how much dialogue there is, you could be looking at thousands of individual captions that need their timestamp adjusted to the new timestamp, post-edit.

I dunno if this helps you at all, or if I am even in the ballpark of your issue, but there it is, anyway.