2.7.5: borked by not using UNC paths to file in idx2

[snotty]

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

[eumagga0x2a]

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.

[snotty]

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.

[eumagga0x2a]

Do you work with local files or files accessible by SMB?

[snotty]

SMB

[eumagga0x2a]

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.

[snotty]

i wouldn't know, i only do .ts file editing, avidemux is set to Copy/Copy/Mpeg TS Muxer (ff)

[eumagga0x2a]

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?

[snotty]

correct, Mpeg4 ASP (xvid4)/Copy/AVI Muxer works even when saving to SMB path (mkv same error msg as above)

[eumagga0x2a]

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.

[snotty]

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?

[eumagga0x2a]

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.

[snotty]

HE-AAC V2 offers quality based encoding

[eumagga0x2a]

You would need a current / recent MinGW nightly to encode with fdk-aac to HE-AACv2. Still CBR for now.

[eumagga0x2a]

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.