|
|
| acidophilus |
| Posted: Apr 14 2011, 02:29 AM |
 |
|
Newbie
Group: Members
Posts: 3
Member No.: 30796
Joined: 14-April 11
|
I've read the topic about external encoders.
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?
|
|
| stephanV |
| Posted: Apr 14 2011, 06:33 AM |
|
|
Spam killer ;)
Group: Moderators
Posts: 4348
Member No.: 8917
Joined: 18-February 04
|
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.
--------------------
useful links:
VirtualDub, Input plugins and filters, AviSynth, AVI-Mux GUI, AC3ACM by fcchandler, VirtualDub FAQ |
|
| phaeron |
| Posted: Apr 16 2011, 08:19 PM |
|
|
Virtualdub Developer
Group: Administrator
Posts: 7773
Member No.: 61
Joined: 30-July 02
|
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.
|
|
| ale5000 |
| Posted: Apr 16 2011, 09:30 PM |
|
|
Advanced Member
Group: Members
Posts: 1114
Member No.: 22180
Joined: 30-September 07
|
But it would be nice something like this:
First VirtualDub produce the avi file and then it call MKVtoolnix to remux.
--------------------
New VirtualDub forum
VirtualDub AIO (All-in-One installer for VirtualDub and plugins)
Codec Toolbox RS (A tool to read/change merit of codecs and many other things)
Input plugins for VirtualDub / ACM codecs / VFW codecs |
|
| acidophilus |
| Posted: Apr 17 2011, 01:13 PM |
|
|
Newbie
Group: Members
Posts: 3
Member No.: 30796
Joined: 14-April 11
|
| 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 | | 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. |
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. |
|
| ale5000 |
| Posted: Apr 17 2011, 02:18 PM |
|
|
Advanced Member
Group: Members
Posts: 1114
Member No.: 22180
Joined: 30-September 07
|
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.
--------------------
New VirtualDub forum
VirtualDub AIO (All-in-One installer for VirtualDub and plugins)
Codec Toolbox RS (A tool to read/change merit of codecs and many other things)
Input plugins for VirtualDub / ACM codecs / VFW codecs |
|
| stephanV |
| Posted: Apr 17 2011, 04:23 PM |
|
|
Spam killer ;)
Group: Moderators
Posts: 4348
Member No.: 8917
Joined: 18-February 04
|
| 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.
--------------------
useful links:
VirtualDub, Input plugins and filters, AviSynth, AVI-Mux GUI, AC3ACM by fcchandler, VirtualDub FAQ |
|
| acidophilus |
| Posted: Apr 20 2011, 06:10 AM |
|
|
Newbie
Group: Members
Posts: 3
Member No.: 30796
Joined: 14-April 11
|
| 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 ... |
|
|
