Jobs (batch processing) gives "Muxer cannot open"

[Shaker1978]

Hi.

I've updated from 2.6.12 (x64) to 2.6.19 (x64) and now every job of my job queue fails with the message:
"Muxer cannot open"
or the German version:
"Keine Daten zum Muxen oder keine Ausgabedatei".

I assume, it has something to do with the new feature that gives a warning when saving H.264 into an AVI file, which I've been doing for years now.
Because the same jobs that write to an MKV file work!
When I save the AVI without a job, directly from the editing UI, it works, too.
Same with version 2.6.21.

I would declare this as a bug, because you can override the warning and save the AVI in general, but not using jobs. It would be great, if for the job control, this warning could be disabled, since it seems to block the muxer.

[Jan Gruuthuse]

Most likely your batch has problems with this:

"Using H264/H265 in AVI is a bad idea, MKV is better for that."

Probably this will come up when converting one h.264 in the Avidemux GUI
see this thread: Batch Convert files

[Shaker1978]

That's the point - it doesn't show up and shouldn't show up in order to enable unattended batch processing. But here a "yes" must be assumed. Instead something else happens, that leads to the muxer error.
MKV might be better (although I don't know why) but AVI is possible, so there's no need to abort the batch.

[Jan Gruuthuse]

Delete the .idx2 files present in the procesed folder.
Place echo in front of the line with avidemux.
This should show what is passed to that line. Perhaps giving a clue why.
If this was not helpfully,  exchange avidemux-cli .exe by avidemux GUI .exe and run the batch again.

[Shaker1978]

Are you talking about the .py files that are automatically generated in the Avidemux user folder, when creating jobs?
Otherwise I don't know where to put "echo", and would "echo" in that line not simply echo, what's in that very line? It's just a script, isn't it? Is your intention to find the parameter, that skips the AVI / MKV warning? Becaus if not, I do not understand, how this deals with my problem. It's the warning that needs to be suppressed, cause in batch mode it lets the Muxer fail.

And deleting the .idx2 files would slow down the whole process, which is not desireable. Meanwhile I stick to version 2.6.12, which works, although a few new features of 2.6.21 are really nice.

[Jan Gruuthuse]

I think I was put on the wrong foot by your title

Jobs (batch processing) gives "Muxer cannot open"

Are you talking about putting videos in to avidemux Queue and processing afterwards with avidemux_jobs?

Think toggling the warning  "Using H264/H265 in AVI is a bad idea, MKV is better for that." would need Developer intervention?

[Shaker1978]

Yes, exactly. When doing 1 task only via "Save as", I get the new "MKV instead of AVI" warning, am able to ignore it and the AVI is saved.

When executing the queue, the warning somehow leads to this Muxer error.

[Shaker1978]

Has this been fixed in version .20 or .21? The changelog doesn't tell me so.

[eumagga0x2a]

I'm pretty sure this wasn't touched. I agree that the AVI muxer should either outright refuse to accept H.264 or allow to disable the warning (no priority for me though).

[Shaker1978]

Please don't make it refuse it, I make H.264-AVIs every day . I don't even understand this warning anyway. Isn't AVI kind of an "open" container? Not bound or restricted to any codec?

[eumagga0x2a]

I make H.264-AVIs every day

But why not using a modern container, specifically Matroska (MKV)?

I don't even understand this warning anyway. Isn't AVI kind of an "open" container? Not bound or restricted to any codec?

I can hardly give you an informed answer, but http://www.alexander-noe.com/video/amg/en_myths.html provides some clues. The main issue is AVI not supporting codecs which may need to retrieve future frames to decode current (in short: codecs with B-frames) natively. Hacks exist.

Unless your target player device can't handle MKV, use MKV.

[Jan Gruuthuse]

Audio Video Interleave Limitations:

Since its introduction in the early 90s, new computer video techniques have been introduced which the original AVI specification did not anticipate.

• AVI does not provide a standardized way to encode aspect ratio information, with the result that players cannot select the right aspect ratio automatically (though it may be possible to do so manually).
• There are several competing approaches to including a time code in AVI files, which affects usability of the format in film and television post-production, although it is widely used. For WAV audio files, Broadcast Wave extensions were designed to standardize post-production metadata, but an equivalent for AVI files has not emerged.
• AVI was not intended to contain video using any compression technique that requires access to future video frame data beyond the current frame. Approaches exist to support modern video compression techniques (such as MPEG-4) that rely on this function, although this is beyond the intent of the original specification and may cause problems with playback software which does not anticipate this use.
• AVI cannot contain some specific types of variable bitrate (VBR) data reliably (such as MP3 audio at sample rates below 32 kHz).
• Overhead for AVI files at the resolutions and frame rates normally used to encode standard definition feature films is about 5 MB per hour of video, the significance of which varies with the application.

More recent container formats (such as Matroska, Ogg and MP4) solve all these problems, although software is freely available to both create and correctly replay AVI files which use the techniques described here.

source: Wikipedia, Audio Video Interleave