ffdshow-tryouts bloat

[kieranrk]

Why does ffdshow-tryout need the following libraries:

Audio:
MP1/2/3 - mp3lib/libmad - What's wrong with lavc?
AC-3 - liba52 - ditto
DTS - libdts - ditto
Vorbis - Tremor - ditto
AAC - libfaad2 - ditto

Video:
Xvid - ditto
libmpeg2 - ditto

Arguments such as "X is better quality" or the claim of bugs without a bugreport will not be considered a decent answer.

[Atak_Snajpera]

Xvid - ditto
From experience I can tell you that Xvid works better with DirectShowSource(). With libavcodec I had sometimes a/v sync problems.

[clsid]

Lets turn the question around. Why do you think the lavc decoders are better? Having everything in one library is NOT a good argument, so you can skip that.

AC3/DTS -> floating point decoding
libmpeg2 -> simply better compatibility is my experience
aac -> lavc decoder is still a work in progress
vorbis -> lavc is already default, except for x64 where it is buggy due to compiler mess-ups

[kieranrk]

Lets turn the question around. Why do you think the lavc decoders are better? Having everything in one library is NOT a good argument, so you can skip that.

AC3/DTS -> floating point decoding
libmpeg2 -> simply better compatibility is my experience
aac -> lavc decoder is still a work in progress
vorbis -> lavc is already default, except for x64 where it is buggy due to compiler mess-ups

All decoders are now significantly faster than other counterparts. Having things in one library means you can speed up the mdct for example and all decoders are sped up.

ac3/dts - Enjoy your floating point placebo. It's also a one line patch to use floating point if you're so desparate to use it.
libmpeg2 - Conjecture
AAC - Decoder has been finished.

And the others?

From experience I can tell you that Xvid works better with DirectShowSource(). With libavcodec I had sometimes a/v sync problems.

Why do you use DirectshowSource anyway?

[Dark Shikari]

AC3/DTS -> floating point decodingAnd twice as slow.libmpeg2 -> simply better compatibility is my experienceWell, except for the rather large iDCT inaccuracy that hurts quality.aac -> lavc decoder is still a work in progressThis isn't 2009 anymore.

[Atak_Snajpera]

Why do you use DirectshowSource anyway?
Because I'm not big fan of FmpegSource().

[clsid]

AAC - Decoder has been finished.Submit a patch if you want it in ffdshow. The required files are already in SVN for your convenience.

And twice as slow.But isn't floating point supposed to give better quality? Otherwise why were float variants added to FFmpeg for mp1/2/3? I know float is slower, but most people care more about quality.

This isn't 2009 anymore. I check FFmpeg SVN log on a daily basis and there were several AAC related changes the past weeks. Is it up-to-par with for example libfaad2 now, feature-wise?

[Dark Shikari]

But isn't floating point supposed to give better quality? Otherwise why were float variants added to FFmpeg for mp1/2/3? I know float is slower, but most people care more about quality.Floating point is faster on CPUs with fast floating point units. Fixed point is faster on CPUs without. That's why such variants were added to ffmpeg.
I check FFmpeg SVN log on a daily basis and there were several AAC related changes the past weeks. Is it up-to-par with for example libfaad2 now, feature-wise?I'm pretty sure it has a few more features than libfaad has at this point -- and is at the minimum a superset of libfaad.

[Blue_MiSfit]

AFAIK, floating point decoding is most useful when you're doing transcoding. I don't think it's THAT important for playback :)

Derek

[leeperry]

liba52 and libdts decode in 32fp, libavcodec is 16int only.
ac3/dts - Enjoy your floating point placebo. It's also a one line patch to use floating point if you're so desparate to use it.
Anything but placebo when you do heavy post-processing(volume/mixing matrix/VST plugins/Reclock resampling/etc)...all the audio apps apply post-processing in 32fp/64fp for a very good reason.

Maybe it's a one line patch to libavcodec, but noone seems to care enough to submit it.

[Reimar]

Anything but placebo when you do heavy post-processing(volume/mixing matrix/VST plugins/Reclock resampling/etc)

And since when does a AAC decoder do heavy postprocessing? I don't know what Dshow can do, but wouldn't it make more sense to just convert to floating point when necessary instead of having to find a floating point decoder for every single format you want to do that kind of heavy post-processing for?
I'm sure there are a lot of audio codecs out there where no floating-point decoder exist, a float AAC/whatever decoder is just hiding the problem, not fixing it.

[leeperry]

And since when does a AAC decoder do heavy postprocessing? I don't know what Dshow can do, but wouldn't it make more sense to just convert to floating point when necessary instead of having to find a floating point decoder for every single format you want to do that kind of heavy post-processing for?
I'm sure there are a lot of audio codecs out there where no floating-point decoder exist, a float AAC/whatever decoder is just hiding the problem, not fixing it.
I post-process all my audio..volume/mixing matrix to downmix 5.1 to stereo/VST plugins(to improve the headstage on headphones) and finally, Reclock resampling. I favor decoders that output 32fp.

Most audio players decode lossy audio in 32fp(like foobar), but uLilith decodes them in 64fp..and also processes VST plugins in 64fp, together w/ the volume attenuation. Decoding lossy audio in 16int doesn't make any sense: http://mp3decoders.mp3-tech.org/24bit.html

[roozhou]

And why is libmad included? Doesn't mp3lib run faster and output 32fp?