which makes it unusable for me. i do idx2 files on one computer, then edit the video files on another, which worked until 2.7.5
Avidemux has never used UNC paths. Please explain.
BTW, you can adjust the path in .idx2 file with any text editor supporting unix line endings.
hmmmm. i did the exact same thing i used to do in 2.7.3 - index the files on the computer they are physically ON.
then i load it on a different computer (that still works without a new index being written), did some edits (ad removal), and save the file without recoding to the original location. i now get a popup: "Info: Muxer Cannot open."
i assumed the non-unc path in the idx2 file as the reason, my bad.
Do you work with local files or files accessible by SMB?
SMB
Regarding the muxer issue, is the issue libavformat-only (MP4, MKV, WebM, MpegTS, MpegPS but not AVI and not MP4v2)?
*) MP4v2 when you use a MinGW build like the win64 nightlies, the official release is VC++, it doesn't include the deprecated MP4v2 muxer.
i wouldn't know, i only do .ts file editing, avidemux is set to Copy/Copy/Mpeg TS Muxer (ff)
Just re-encode a small portion with Xvid and save it as
a) MKV
b) AVI
to a location available over SMB.
Does "a" fail while "b" succeed?
correct, Mpeg4 ASP (xvid4)/Copy/AVI Muxer works even when saving to SMB path (mkv same error msg as above)
Well, it is probably the ffmpeg patch which fixed moving the index of MP4 files (the moov box) to the start of the file for streaming compatibility. As a side effect, it seems to have broken handling of SMB paths (so probably ffmpeg is doing UNC internally) by libavformat. This went unnoticed because I don't use any shares in the local network.
I'll have to setup some (probably buy new hardware) to be able to work on it.
thank you VERY much for your quick & competent help. (makes a nice change from being verbally abused elsewhere upon REAL bug reports by a guy called stanley *g*)
i have another question, since you got me to try encoding ;)
any chance of using a quality-based setting for AAC or AC3 encoding instead of a fixed bitrate?
Quote from: snotty on November 03, 2019, 08:00:52 PM
any chance of using a quality-based setting for AAC or AC3 encoding instead of a fixed bitrate?
AAC is VBR by nature, but indeed, depending on encoder used, it might be worth it to explore more options. AC3 is practically always CBR.
HE-AAC V2 offers quality based encoding
You would need a current / recent MinGW nightly to encode with fdk-aac to HE-AACv2. Still CBR for now.
At a quick glance I could not find anything which might match the description of "quality based encoding" in the header (aacenc_lib.h). VBR should be easily possible, however.