Why most encoders in ffdshow have been removed?

[wolfgangbeyer]

Hi,

obviously in Nov. or Dec. 2010 nearly all encoders in ffdshow have been removed. Is there any reason for that?

[Midzuki]

http://forum.doom9.org/showthread.php?p=1467129#post1467129

[wolfgangbeyer]

Hi Midzuki,

I'm not very happy about that and I think most ordinary users too. Where can I find recommedations for the said better solutions for encoding? I don’t think that any ordinary user who casually used ffdshow so far for encoding also has the time to search the monster thread "ffdshow tryouts project: Discussion & Development" to find and understand the relevant discussion in Dec. 2010. How should we encode in the future XviD, DivX, H.264 and others? I installed ffdshow because I heard that installing several codec packages could lead to conflicts between them, and having all of them integrated in ffdshow would solve this problem. Now I have to care about this problem again? If there is no answer about this question which I am able to understand in less than 10 minutes I don’t see any reason to install any ffdsow version above ffdshow_rev3572_20100913_clsid.exe, which seems to be the last available version with all encorders (which I found out after a search of I forgot how much time). Problems with video on PC seem to be a never ending story for me. I never wanted to become a video expert ...

[nurbs]

How should we encode in the future XviD, DivX, H.264 and others?
With XviD (http://www.free-codecs.com/download/xvid_codec.htm), Divx (http://www.divx.com/), x264 (http://x264.nl/) (or x264vfw (http://sourceforge.net/projects/x264vfw/)).

I installed ffdshow because I heard that installing several codec packages could lead to conflicts between them, and having all of them integrated in ffdshow would solve this problem.
Codec packs can cause conflicts, but by not using packs and only installing the encoders you need you are unlikely to run into trouble.

[Ghitulescu]

Ideally there should be one codec for one format. Problems occur mainly when a codec conflicts with another one, either there are more than one codec for one format, or a codec that can do multiple formats interferes with another [legitimate] one.

Using less formats on a particular PC and installing only the needed codecs is the key to a trouble-free work.

[wolfgangbeyer]

With XviD (http://www.free-codecs.com/download/xvid_codec.htm), Divx (http://www.divx.com/), x264 (http://x264.nl/) (or x264vfw (http://sourceforge.net/projects/x264vfw/)).

For x264 the encoder seems to be offered separately but in case of XviD and DivX the decoders obviously are installed too. What about conflicts with the corresponding ffdshow decoders according to:

Problems occur mainly when a codec conflicts with another one, either there are more than one codec for one format, ...

Besides, if you really need/miss the options for Xvid, WMV9, H264 and Theora :rolleyes:, you still can copy the xvidcore, ff_wmv9, ff_x264 and ff_theora DLLs to the ffdshow folder.

That is good to know. :thanks:

[andrixnet]

I'm not very happy about that and I think most ordinary users too.

I don’t see any reason to install any ffdsow version above ffdshow_rev3572_20100913_clsid.exe, which seems to be the last available version with all encorders

The one great thing about ffdshow is the fact that offered a great variaty of decoders and encoders all in one package, while not being a codec-pack, but a single entity.

[andrixnet]

Are there any ffdshow builds other then clsid newer then ffdshow_rev3572_20100913 that do contain the full encoding capabilities of rev3572 and earlier?

[Sharc]

http://www.xvidvideo.ru/ffdshow-tryouts-project-x86-x64/

[clsid]

ffdshow's decoder has a very high merit and will get used instead of any other decoders that may be installed (basically just Xvid, as DivX is redundant anyway).

[pandy]

@Sharc - i believe that this version also strip off all other codec's

[andrixnet]

Indeed they are removed from those builds as well.

I still fail to understand the reason behind this.
I don't see ffmpeg dropping encoders because separate packages exist.
Yes, ffmpeg compiles support for various formats using separate libraries. But in the end it's one encoding and decoding package that does it all.

[nevcairiel]

The codecs that were removed were outdated, broken or incomplete. Much better alternatives exist all around. No-one was willing to update or fix the existing ones, so they were removed.

I don't get the problem here. You want a h264 encoder? Well install the x264 VfW codec, and don't use the half-broken and outdated ffdshow version. Same goes for the other codecs, of course. The only reason i can come up with that this is so bad for you is lazyness - and thats no reason in itself.

In the end, its the decision of the developers anyway. You don't pay them, most of you don't even thank them, but if they do something you don't like, you get noisy and annoying. A great world that is open source. :)

[andrixnet]

The codecs that were removed were outdated, broken or incomplete. Much better alternatives exist all around. No-one was willing to update or fix the existing ones, so they were removed.

ffmpeg -codecs
List is neither tiny, nor the encoders outdated. And yes, some of them are based on external libraries that are the base for their respective own standalone implementation as well. (like xvid, x264, etc).
Seeing this situation I am only sorry that I lack most of the skills required to bring those encoders up to date in ffdshow myself.

I don't get the problem here. You want a h264 encoder? Well install the x264 VfW codec, and don't use the half-broken and outdated ffdshow version. Same goes for the other codecs, of course. The only reason i can come up with that this is so bad for you is lazyness - and thats no reason in itself.

Actually, I DO have xvid and x264 installed as separate encoders.
Sometimes I use them, though most often ffdshow gets picked. Even though it may not be the fastest, the newest or the very best of output quality at the pixel level.

Consider the end user perspective. A unified codec package for both decoding and encoding, as it has been until recently.
Also, a unified interface for encoder parameters, which many actually share. Ffdshow is thus easier to use (as encoder).
Different encoder packages have their own ideas about what settings to make available to the user and also how to name them. Which in turn gets to be confusing.

Anyway, this is just another user's experience.

But please do not call me "lazy" while quoting "unwillingness to update or fix encoders".


In the end, its the decision of the developers anyway. You don't pay them, most of you don't even thank them, but if they do something you don't like, you get noisy and annoying. A great world that is open source. :)
Well, yes, it is true that open-source is not about direct payments from end users to developers.
There are many ways to contribute or show appreciation to an open-source project. Including bug reports, feature requests, patches, translations, and finally, actually using it.
I have contributed to many open-source projects with bugreports, testing, a couple of patches doable at my skill level.

There have been some projects shutting out some of their user base with some decisions. Some of them have even forked because of such.
There are other projects that linger features or components for years for similar reasons : developer unavailability or low priority. Some get better, others remained roughly the same.

This is the first major project that I see dropping features/modules/componets in bulk on such grounds.
"Err, it's kinda old, err, i've seen that other program do the same, let's just delete the whole thing..."

It makes me sad.

My few bits...

[clsid]

All I read is a lot of bla bla but no actual valid points.

We don't want people to use inferior buggy outdated software when proper alternatives are available. Alternatives is not really the correct word for it, since it are actually the original encoders for which ffdshow merely provided a buggy/outdated/incomplete wrapper. But since a lot of people are stubborn lazy fucks, the only way to accomplish that goal is by doing what we did.

Those who are so keen on an all-in-one solution, get a fucking codec pack or something like that.

And if you don't care about using quality software, then just keep using some old version. Maybe install Windows 3.11 also.

[wolfgangbeyer]

There remains one open question for me: If I install encoders with better quality separately, the corresponding decoders often are installed too, like in case of XviD and DivX. These encoders seem not to be available without decoder. But than XviD and DivX decoders are installed twice, because ffdshow contains them too. This way the danger of codec conflicts reappears, and the main advantage of ffdshow gets lost, which I was told is to solve exactly such codec conflict problem.

[-TiLT-]

clsid answered this in post 11

In jawors xvid builds you can disable the directshow decoder component. As for DivX, you do not need to install it anyway if you have xvid for mpeg4 part2 and x264 for mpeg4 part10. Just learn how to configure these to meet HW specifications.

[clsid]

There remains one open question for me: If I install encoders with better quality separately, the corresponding decoders often are installed too, like in case of XviD and DivX. These encoders seem not to be available without decoder. But than XviD and DivX decoders are installed twice, because ffdshow contains them too. This way the danger of codec conflicts reappears, and the main advantage of ffdshow gets lost, which I was told is to solve exactly such codec conflict problem.Codecs can NOT conflict with each other! Myth busted.

A codec (read: DirectShow filter) either gets used or it doesn't. You can install 10 decoders for MPEG-4 video and each and every one of them will continue work fine when manually creating a DirectShow graph that includes that decoder. The different decoders do not influence each others behavior in any way. When a DirectShow graph is created automatically by a player, the filter with the highest merit will get used when you got decoders installed for a particular format.

If you install both ffdshow and the Xvid decoder, then ffdshow will get used by default because of its higher merit. If you prefer using the Xvid decoder, then you could simply disable Xvid decoding in the options of ffdshow. It has options for all formats it supports. In general, you also adjust the merits of the filters to give your preferred one the highest merit.

When people are having playback problems, it is thus not because of codec 'conflicts'. It is simply because one of the DirectShow filters in the graph is not performing its task properly, usually due to a bug.

In short, you can safely install the Xvid decoder, even if you don't really need it. It will simply be redundant and won't get used. There are also Xvid installers and codec packs available that allow installing just the Xvid encoder.

DivX and Xvid are both MPEG-4 ASP codecs. You don't need both. So just get Xvid and be happy. DivX is not needed.

[nevcairiel]

What people commonly conceive as "codec conflicts" are usually codec packs that think they are smart, and modify the registry either in places that should not be modified manually, or just do it plainly wrong. On top of that add buggy codecs, like clsid said, and voila, everyone is having issues!

[clsid]

What do you mean? Modding the mediatype entries for source filters? That can actually be quite handy when using multiple splitters. Btw, support for LAVSplitter is being added to Codec Tweak Tool to aid people in setting preferred splitters.

[rec]

Removing all those encoders was a mistake. For example, I use MS MPEG4 V2 to encode 1920x1080 60P material. This is one of the few codecs that can handle this massive amount of data and playback smoothly on most machines. And now it's gone.

So, unless someone can point out a codec that does what MS MPEG4 V2 does, for me, ffdshow has reached a dead end. I don't think this is what the authors intended, but it's the reality.

[nm]

So, unless someone can point out a codec that does what MS MPEG4 V2 does

MPEG-4 ASP should be just as easy to decode. If it doesn't work for you, have you tried MPEG-2?

[rec]

MPEG-4 ASP should be just as easy to decode. If it doesn't work for you, have you tried MPEG-2?

From what I understand, MPEG-4 ASP only works for frame sizes up to 720x576. And yes, I tried MPEG-2, but it's frame rate maxes out at 60i or 30P. It refuses to do 1080 60P.

[Didée]

From what I understand, MPEG-4 ASP only works for frame sizes up to 720x576.
What? Please? There is no problem encoding 1080p with ASP. Such has been done a billion times already...

[Midzuki]

And yes, I tried MPEG-2, but it's frame rate maxes out at 60i or 30P. It refuses to do 1080 60P.

*Which* MPEG-2 encoder have you used? :confused:
60fps is 100% spec-compliant.

[rec]

*Which* MPEG-2 encoder have you used? :confused:
60fps is 100% spec-compliant.

The one that's in ffdshow. Error message - "MPEG1/2 does not support 65535/1093 fps"

I'm trying to encode 1080, not 720. Of course, the real frame rate is 59.94P, but I said 60P for shorthand.

[nm]

The one that's in ffdshow. Error message - "MPEG1/2 does not support 65535/1093 fps"

65535/1093 != 60000/1001. Also, ffdshow really isn't the best ffmpeg frontend for encoding. Use ffmpeg CLI or some other GUI frontend. Or HC.

ffmpeg encodes 1080p60 MPEG-2 just fine.

Edit: And check out MPEG-4 ASP first. It gives better compression and decodes almost as fast. Xvid should do as an encoder.

[is3000]

Apologies for digging up an old thread, but I'm curious about this line from Midzuki in post #6:
"Besides, if you really need/miss the options for Xvid, WMV9, H264 and Theora, you still can copy the xvidcore, ff_wmv9, ff_x264 and ff_theora DLLs to the ffdshow folder."

Copying those files to the ffdshow folder after a new ffdshow install did not seem to do anything. Is there something else that needs to be done in order to have those encoders available again?

[Midzuki]

Apologies for digging up an old thread, but I'm curious about this line from Midzuki in post #6:

Originally Posted by Midzuki

"Besides, if you really need/miss the options for Xvid, WMV9, H264 and Theora, you still can copy the xvidcore, ff_wmv9, ff_x264 and ff_theora DLLs to the ffdshow folder."

Copying those files to the ffdshow folder after a new ffdshow install did not seem to do anything. Is there something else that needs to be done in order to have those encoders available again?

Unfortunately, I was wrong. :o Since that "feature" was part of the older revisions of ffdshow, I stooopidly assumed :o that the new revisions were simply going to be "compiled without those DLLs", instead of rejecting them completely -.-

[is3000]

Thanks for the response, Midzuki. Bummer... For whatever reason, ffdshow's built-in encoders were the only ones I was able to get working well for real-time captures in VirtualDub. The latest XviD standalone pack encoder just crashes VirtualDub as soon as the record button is pressed, and my computer is not fast enough to do x264 real-time encoding with a decent frame rate. I guess I may have to stick with a combination of CCCP and an older version of ffdshow installed over the top of it.

[Midzuki]

^ Regarding Xvid: if the "latest and greatest" :rolleyes: version crashes VirtualDub,
just use an older revision, case solved :) I prefer the builds by Jawor to the "official" ones, and even the outdated mod by Nic should still be good-enough in most cases ;)

But unless disk space is a concern, I think you really should use a lossless codec, such as UT Video, or Camstudio (1.0).

[is3000]

Coming from a lossless audio background, that makes sense. Thank you for the suggestion. After trying out a number of different lossless codecs, I've settled on UT in RGB for lossless capture.

Unfortunately, Jawor's XviD 1.3.2 and Nic's XviD 2009.08.23 both caused VirtualDub to crash instantly in real-time capture just like the official distribution did. They were tested on two different computers running XP 32-bit. I'm not sure what makes the XviD encoder in the older ffdshow different. Capturing lossless and then re-encoding is undoubtedly the best method for maintaining quality, but my typical source is a cheap webcam, which is what makes encoding directly to XviD appealing.