FFvfw & FFdshow relationship

[mustardman]

This is not really a 'New A/V format' but my question dosen't really fit any any forum, although possibly XviD (as that seems to be where FF discussion happens)...

I read in the XviD forum that FFvfw is for encoding, and FFdshow is for decoding. ("ffvfw" thread, first post - by athos, XviD forum)

If FFvfw is for encoding, why does it have a 'decode' section within it?

Is FFdshow only visible to Direct Show capable software, or is it also capable of VFW output? (Like Virtual Dub uses).

I also read in the forum that it was possible to install both. (same forum & thread - moonman 10th May 03). That I can understand if in fact one does encoding and the other one decoding, but do they, and which does which?

Brimming with questions, skimpy on answers :(

[Doom9]

If FFvfw is for encoding, why does it have a 'decode' section within it?
To keep the decoder more lightweight? Actually, there is a vfw decoder (I think) that you need to open an ffvfw encoded video in a video editing application. IF you look at other codecs, you'll see that they have two components as well. Xvid for instance: xvid.dll is the vfw part, xvid.ax is the dshow part. If I recall correctly, you can play videos just having xvid.dll, however, you have no postprocessing and controls over playback (that's what you gain by using the DirectShow filter xvid.ax). Same goes for all DivX versions. So it's perfectly natural two have vfw and dshow separated.
Is FFdshow only visible to Direct Show capable software, or is it also capable of VFW output?No, as the name says, it's a directshow filter and that's that.

That I can understand if in fact one does encoding and the other one decoding, but do they, and which does which?
the above should tell you that. vfw codecs are used for encoding, directshow filters for decoding.

[Neo Neko]

Yep doom9 is correct. Basically they are complementary. One as he said handles the VFW end of things and the other handles the directshow decoding portion. They are however derived from one larger project namely ffmpeg. But between the two of them they are pretty much the best MPEG4 encoder decoder setup out there. Using the latest ffvfw compile I could find I would almost dare say it is superior to Divx 3-5, Xvid, and Apple MPEG4. If only we had software like this when we were starting out eh?

[rakaz]

vfw codecs are used for encoding, directshow filters for decoding
Well, not entirely. VFW is for both encoding and decoding. Directshow is also both for encoding and decoding. VFW is basically the predecessor of Directshow and both allow encoding and decoding.
To make things more complex, Directshow can use VFW codecs, using a compatibility layer. The reverse is not possible.

Most players use directshow. Most encoding and editing applications still use VFW.

So why was ffdshow created? Why not just use ffvfw for both decoding and encoding... Since most players use directshow to view movies they can also use VFW codecs using the compatibility layer. However this won't allow you to use some of the more advanced features. So using a native directshow filter for decoding has advantages.

So why was decoding support added to ffvfw? Why not just use ffdshow for decoding... Most applications that allow you to encode video still use the VFW API, so ffdshow won't work in those applications. For example, VirtualDub uses VFW for both encoding and decoding. If decoding support was dropped from ffvfw you wouldn't be able to (pre)view the content of a video file inside VirtualDub...

[Atamido]

This post is a little off topic.

Yes, both VFW and DS allow you to both encode and decode. In fact, DS is really better for encoding than VFW because of the newer design. The problem is that DS is not good for editing, so most people don't mention it for encoding. IF you are doing a simple transcode of a file from one format to another, DS is actually best designed for that. Here's why:

VFW places the application in the center of the encoding process. All data passes through it. Because of this the application has a lot a freedom on how it does things.

DS is more of a black box design. You attach things to it and let it do its work. This makes it difficult, or impossible to get the same level of control from the application. (This is why there is no VirtualDub 2.0, it was supposed to be DS based.)

VFW requires a playback application to handle all of the data that is used.

DS does most of the work for the playback application, outputting pre-rendered audio and video for it.


So, you will typically use DS for playing videos, and you will typically use VFW for editing.

[mustardman]

Thankyou all for your replies.

The situation is somewhat clearer now, actually, quite a bit clearer.

From these posts, and examining the FFvfw interface, I gather that when FFvfw is selected for encoding it uses its' *internal* encoders, that is, it does not simply pass the data on to a 'third party' encoder.

But with decoding, a note on the decode section of FFvfw says that it may not be actually decoding the fourCC stream that you ticked as saying 'handled by FFvfw', except in the case of FVFW (and one other which I can't think of). So, that being the case, is it possible to check a box saying 'handled by FFvfw', and then not being able to decode the stream because you *don't* have a 'third party' codec?

[rakaz]

From these posts, and examining the FFvfw interface, I gather that when FFvfw is selected for encoding it uses its' *internal* encoders, that is, it does not simply pass the data on to a 'third party' encoder.

But with decoding, a note on the decode section of FFvfw says that it may not be actually decoding the fourCC stream that you ticked as saying 'handled by FFvfw', except in the case of FVFW (and one other which I can't think of). So, that being the case, is it possible to check a box saying 'handled by FFvfw', and then not being able to decode the stream because you *don't* have a 'third party' codec?

This is correct. Well, if you want to get really technical it is not, but for globally it is. I'll try to explain it.

ffvfw and ffdshow are based on the ffmpeg libavcodec library. Libavcodec handles the actual encoding. What ffvfw does is, it passes the data it gets from the application to libavcodec and gives the encoded data back to the application.

For decoding, both ffvfw and ffdshow can use a number of different libraries. Based on the type of encoded video and your preferences it uses either libavcodec, libmpeg or xvid for decoding. Again, ffvfw and ffdshow passes the encoded data to any of these libraries and gives the decoded data back.

For the application that uses ffdshow or ffvfw this is all completely transparent and it will look like ffdshow or ffvfw is doing the decoding. All the application cares about that it can give the encoded information to ffdshow or ffvfw and that it gets the decoded information back. What ffdshow or ffvfw does internally with the information and which library it uses to decode the information is not important to the application.

And now things get even more complicated. Apart from decoding information, ffdshow and ffvfw can also do some additional filtering on the movie. For example, you can use post-processing and change the contrast and brightness of the movie. The amount of configuration for this is actually what makes ffdshow and ffvfw so powerfull.

What ffdshow and ffvfw usually do is use one of the libraries for decoding. The library passes the information back to ffdshow or ffvfw. The decoded information will then processed by the internal filters ffdshow or ffvfw. So after the information is decoded, ffdshow and ffvfw are not done yet.

If configured to do so, ffdshow can also accept already decoded information. The information it gets this way is not passed to one of the external libraries, but filtered by ffdshow directly and passed back to the application. So the information is already decoded before it reaches the ffdshow filter. In that case the decoding is done by another codec and ffdshow handles just the filtering.

Getting back to your last question... Ffdshow and ffvfw rely on external libraries for the encoding and decoding... So if these libraries are missing you're in trouble. The libraries that ffdshow and ffvfw use are also installed during the installation of ffdshow and ffvfw, so they are always available.

So if ffdshow or ffvfw is installed correctly you won't run into this problem. Ffdshow and ffvfw can decode all the different types of encoded video listed in the configuration screen with a default install, without the need for any external VFW or Directshow codecs. The only thing that they need are the libraries which are also installed by default.

There is one exception... Xvid... Ffdshow and ffvfw can also use Xvid for decoding. Xvid must be installed seperately. If Xvid is not installed ffdshow and ffvfw simply won't let you select it as the library to use for decoding. In that case ffdshow and ffvfw will simply use libavcodec for decoding the video.

[echooff]

Wow! :eek: What a great eplanation. Even a dummy like me can understand it. Thanks.:)

[mustardman]

Thankyou for your very concise answer.

That (and the posts above) have cleared up very nicely what I wanted to know about the two.

And I indeed hope that there are others out there who benefit from this also.

[SammyRoss]

Wow, this is like the most useful post I've read in a while!

A question on topic please: Is there any DS encoding application available at all, or did anyone not go through the hassle?

And why was VirtualDub 2.0 not created?

Thanks.

[Doom9]

especially in the audio arena there are quite a few filters (lame, AAC, ogg vorbis). NeroDigital uses DS only, so Recode - at least in the MPEG-4 area, is a DS encoder. Muxing is often done in Graphedit (thus in the DS realm), OggDS and 3ivX's MP4 filters are just two examples (you can do it as well with Matroska if I'm not mistaken). But there's no generic encoding / cutting tool available. I think one of the main reasons is that editing isn't quite so easy to achieve (where's the MP4 cutting we were promised for NeroDigital?), and most codecs are VFW. Of course it's a hen and egg problem.. codec coders need a working app, and the people who could write the app need codecs.

[SammyRoss]

Doom9: Personal opinion: Did you ever author DVDs before? What app do you prefer to use to author and what app do you prefer to use to actually encode the files to MPEG2 beforehand?

I'm stuck into the problem of putting multiple files (quicktime, mov) on a DVD video disc so that I would be able to play them at variable speeds (1.5x, etc.) since this is not achievable using QuickTime Player. What would you do?

Another question please: Bitrates confuse me. When I have an already encoded file with a certain bitrate, and I want to reencode it using another codec (Fast Recompression with VDub for instance). How can I decide what the target bitrate should be, in order to not lose quality? I do know, however, that I could never achieve better quality than the actual source, so that's not what I want.

Can I read about this somewhere? I tried looking into bitrate calculators, but I didn't understand anything :( Maybe I'm just dumb. I just wish I could see files encoded with all the bitrates, and compare them to know which is like moderate/high/low, etc.?

I hope I wasn't boring!

[SeeMoreDigital]

Originally posted by SammyRoss
Doom9: Personal opinion: Did you ever author DVDs before? What app do you prefer to use to author and what app do you prefer to use to actually encode the files to MPEG2 beforehand? Doom9 has tried many software applications over the years. For more info you should have a look in the guides section (http://www.doom9.org/index.html?/guides.htm) of Doom9's main site.

Cheers

[bond]

Originally posted by Doom9
But there's no generic encoding / cutting tool available. I think one of the main reasons is that editing isn't quite so easy to achieve (where's the MP4 cutting we were promised for NeroDigital?)editing in dshow is possible
basically i already tested such a tool (based on dshow) and things like cutting aso seem to work nicely already :) (nope its not from ahead)
especially the cutting also at non-keyframes is a great feature imo
also it allows encoding with a dshow encoder (great stuff especially when thinking about all these problems with b-frames in vfw), which allows variable framerate output too already

but dont hold your breath till it comes, its still very basic :(

edit:
Originally posted by mustardman
[This is not really a 'New A/V format' but my question dosen't really fit any any forum, although possibly XviD (as that seems to be where FF discussion happens)...well basically you chose the right forum, as ffvfw/ffdshow are totally different mpeg-4 implementations than xvid and therefore arent directly related to it
other (non xvid/divx5) stuff like 3ivx, nerodigital aso is also discussed in this forum

[shitowax]

basic ... basic ... it can already fortify some files anyway ;)

Originally posted by bond
editing in dshow is possible
basically i already tested such a tool (based on dshow) and things like cutting aso seem to work nicely already :) (nope its not from ahead)
especially the cutting also at non-keyframes is a great feature imo
also it allows encoding with a dshow encoder (great stuff especially when thinking about all these problems with b-frames in vfw), which allows variable framerate output too already

but dont hold your breath till it comes, its still very basic :(

[athos]

To make things more complicated, or actually easier, ffdshow and ffvfw has now merged. if you download any of the latest builds of ffdshow, you will be able to use it in vfw applications as well. one new feature is that it can use skal's mpeg4 codec to encode.

[Atamido]

Originally posted by Pamel
(This is why there is no VirtualDub 2.0, it was supposed to be DS based.) Avery recently clarified to me that he killed VirtualDub 2.0 because he didn't have time to maintain two completely seperate code bases, but DirectShow is still is not good for an editing app. He does an impressive rant about this that I won't bother anyone with. It doesn't look like he will move to it any time soon. Although, if GStreamer gets ported fully to Windows, then I think that he may take a look at it.