Unofficial VirtualDub Support Forums [Powered by IB Forums]

Printable Version of Topic
Click here to view this topic in its original format

Unofficial VirtualDub Support Forums > Codec Discussion > Multiplexer-only Encoderset

Posted by: acidophilus Apr 14 2011, 02:29 AM

I've read http://forums.virtualdub.org/index.php?act=ST&f=3&t=18840&st=0.

Quite honestly, I believe, the design is very stiff. I find it logical to have all external video-encoders in video-compression list, all external audio encoders in audio-compression list. Then "Save as" has to list all containers, supported by external multiplexers. The current way stuffs up all VirtualDub idea with independent settings for video and audio.

I have an x64 vfw, so I don't need x64.exe, as an external encoder. I've built an Encoder Set, which specifies only multiplexer, such as mkvmerge, in expectation that I can save in MKV container, enjoying all Vdub features (like I can do with good old VirtualDubMod), but it doesn't work!

Anyone tried this successfully?

Posted by: stephanV Apr 14 2011, 06:33 AM

Stuff doesn't work that simple. There is no guarantee that a particular encoder is going to work with a particular muxer and heaping all VFW encoders (which at least all work with, well, VFW) with CLI tools is going to create so much combinations that won't work that it would bring too much confusion. A design that is guaranteeing errors while they can be easily avoided (in this case by separating external encoders from VFW) is generally considered very weak.

What you want is not possible. You will have to setup x264 as an external encoder.

Posted by: phaeron Apr 16 2011, 08:19 PM

More specifically, the codecs in the compression list have a better programming interface than the external encoders, in that they receive specific information about the video and audio streams and send frames or samples back and forth rather than raw bytes. The advantage of the external encoder path is that it handles free-form data; the downside is that because the codec structure isn't in place, the isolation between codec and container isn't possible. Often, the external encoders are themselves producing a container format, so the encoders and the multiplexer have to be chosen and configured in tandem.

Posted by: ale5000 Apr 16 2011, 09:30 PM

But it would be nice something like this:
First VirtualDub produce the avi file and then it call MKVtoolnix to remux.

Posted by: acidophilus Apr 17 2011, 01:13 PM

QUOTE

There is no guarantee that a particular encoder is going to work with a particular muxer and heaping all VFW encoders (which at least all work with, well, VFW) with CLI tools is going to create so much combinations that won't work that it would bring too much confusion.

So, you mean, it's a protection from a dumb user. Well, I wouldn't mind if a dumb user gets confused, what I am more interested in is flexibility. BTW a dumb user can configure an encoder set in a dumb way and get even more confused

QUOTE

I completely agree, but still I don't see, why this prevents having external encoders listed among others. Well, an external encoder can be specially marked, to warn me, that the only way to talk to this encoder is through a pipe, so there is no sufficient feedback, but still it would be much more useful, than the way it is currently done.

QUOTE

Often, the external encoders are themselves producing a container format

Such an encoder may be considered as a multiplexer taking uncompressed video data (no video encoder). Actually it might also be a good idea to have "No container" option which allows to save video track only (e.g. *.h264)

QUOTE

But it would be nice something like this:
First VirtualDub produce the avi file and then it call MKVtoolnix to remux.

BTW, you could do that with older versions of VirtualDub, but I belive a good program wouldn't need tricks like that.

What I mean is, that when you have an external encoder, logically it should be treated if not exactly like others, then at least similarly to other encoders. When you add a new envelope, it should be treated similarly to other envelopes. It comes into your mind as an obvious thing, and not a surprise, I've come across quite a few posts like: "Help, I've added an external encoder, and it isn't there!".

Very soon, AVI format might become obsolete, and I wouldn't like such a great program as VDUB to stick to this particular container and treat another container as a foreign object.

Posted by: ale5000 Apr 17 2011, 02:18 PM

The problem is that every audio/video formats is stored with the same method in avi files (this makes VirtualDub able to read/write avi files with format that it doesn't even known) but for other containers every formats is stored in a different way, so it is difficult.

A better way would be to use a method similar to the one used for input plugins.
It could be something like this: VFW/ACM codecs compress the data, when the data are ready to be written in the avi, instead of doing it VirtualDub could pass them to output plugins along with video fourcc/audio tag then the output plugin with these data can choose if allow or deny the audio/video formats and if possible write the file.
Obviously it would take at least an year before the VirtualDub support for this is stable and at least one ouput plugin is stable enough for normal use but it is worth waiting for something like this.

Posted by: stephanV Apr 17 2011, 04:23 PM

QUOTE

So, you mean, it's a protection from a dumb user.

No it has nothing to with the user being dumb or smart. It's about the interface giving options that don't exist. The dumbness is in the design, not in the user.

QUOTE

Such an encoder may be considered as a multiplexer taking uncompressed video data (no video encoder).

Doesn't work, where would audio go?

QUOTE

Actually it might also be a good idea to have "No container" option which allows to save video track only (e.g. *.h264)

VirtualDub cannot control the output formats available in external encoders.

QUOTE

What I mean is, that when you have an external encoder, logically it should be treated if not exactly like others, then at least similarly to other encoders.

There isn't much similarity between an external encoder and a VFW codec, other than that they both have something to do with digital video.

QUOTE

When you add a new envelope, it should be treated similarly to other envelopes. It comes into your mind as an obvious thing, and not a surprise, I've come across quite a few posts like: "Help, I've added an external encoder, and it isn't there!".

I haven't seen those posts, and that is something that could be attributed to user ignorance.

QUOTE

Very soon, AVI format might become obsolete, and I wouldn't like such a great program as VDUB to stick to this particular container and treat another container as a foreign object.

People have been saying that for 10 years now and there are now more devices that support AVI than ever before.

Also, one of the reasons the external encoder feature was put into place is that supporting output of every (important) format natively in a proper manner is rather time consuming and it's much easier to provide a general front-end to CLI tools that do support those formats properly.

Posted by: acidophilus Apr 20 2011, 06:10 AM

QUOTE

A better way would be to use a method similar to the one used for input plugins.
It could be something like this: VFW/ACM codecs compress the data, when the data are ready to be written in the avi, instead of doing it VirtualDub could pass them to output plugins along with video fourcc/audio tag then the output plugin with these data can choose if allow or deny the audio/video formats and if possible write the file.

This is what I was also thinking about. I wonder if VirtualDub supports output plugins the same way as it allows the input ones. As far as I remember, an input plugin adds a line to the list of input formats (e.g. VOB for MPEG2 type). The same way an output plugin could add a line to the list of output formats, so that we could have MP4 and MKV.

And if there were a way to have an encoder plugin, that would fix the problem completely

Though it isn't as crucial as a muxer plugin, since we have vfw.

QUOTE

People have been saying that for 10 years now and there are now more devices that support AVI than ever before.

I also like vdub (should I say liked?). One of its appreciated features is Direct Stream Copy, so that you can modify video, while audio stays at exactly same quality, and vice versa. I wonder how compatible this feature is with the encoder sets. Will it be just ignored, or it might lead to an enormous confusion? And this might be not the only inconsistency with the encoder sets. I wonder if somebody has really used this feature on a regular basis to see how robust it is. Of course you can copy the settings from the above mentioned topic, and use it all the time in the same way. But encoder is always a trade-off between size and quality, so I always play with the parameters ...