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

Started by snotty, November 03, 2019, 06:52:01 PM

Previous topic - Next topic

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?


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

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.

snotty


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.