Welcome to Doom9's Forum, THE in-place to be for everyone interested in DVD conversion.

Before you start posting please read the forum rules. By posting to this forum you agree to abide by the rules.

 

Go Back   Doom9's Forum > Video Encoding > New and alternative video codecs

Reply
 
Thread Tools Search this Thread Display Modes
Old 6th July 2010, 21:10   #1  |  Link
kieranrk
Registered User
 
Join Date: Jun 2009
Location: London, United Kingdom
Posts: 707
ffdshow-tryouts bloat

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.
kieranrk is offline   Reply With Quote
Old 6th July 2010, 21:57   #2  |  Link
Atak_Snajpera
RipBot264 author
 
Atak_Snajpera's Avatar
 
Join Date: May 2006
Location: Poland
Posts: 7,806
Quote:
Xvid - ditto
From experience I can tell you that Xvid works better with DirectShowSource(). With libavcodec I had sometimes a/v sync problems.
Atak_Snajpera is offline   Reply With Quote
Old 6th July 2010, 22:01   #3  |  Link
clsid
*****
 
Join Date: Feb 2005
Posts: 5,642
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
__________________
MPC-HC 2.1.7.2
clsid is offline   Reply With Quote
Old 6th July 2010, 22:20   #4  |  Link
kieranrk
Registered User
 
Join Date: Jun 2009
Location: London, United Kingdom
Posts: 707
Quote:
Originally Posted by clsid View Post
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?

Quote:
Originally Posted by Atak_Snajpera View Post
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?
kieranrk is offline   Reply With Quote
Old 6th July 2010, 22:31   #5  |  Link
Dark Shikari
x264 developer
 
Dark Shikari's Avatar
 
Join Date: Sep 2005
Posts: 8,666
Quote:
Originally Posted by clsid View Post
AC3/DTS -> floating point decoding
And twice as slow.
Quote:
Originally Posted by clsid View Post
libmpeg2 -> simply better compatibility is my experience
Well, except for the rather large iDCT inaccuracy that hurts quality.
Quote:
Originally Posted by clsid View Post
aac -> lavc decoder is still a work in progress
This isn't 2009 anymore.
Dark Shikari is offline   Reply With Quote
Old 6th July 2010, 23:01   #6  |  Link
Atak_Snajpera
RipBot264 author
 
Atak_Snajpera's Avatar
 
Join Date: May 2006
Location: Poland
Posts: 7,806
Quote:
Why do you use DirectshowSource anyway?
Because I'm not big fan of FmpegSource().
Atak_Snajpera is offline   Reply With Quote
Old 6th July 2010, 23:13   #7  |  Link
clsid
*****
 
Join Date: Feb 2005
Posts: 5,642
Quote:
AAC - Decoder has been finished.
Submit a patch if you want it in ffdshow. The required files are already in SVN for your convenience.

Quote:
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.

Quote:
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?
__________________
MPC-HC 2.1.7.2
clsid is offline   Reply With Quote
Old 6th July 2010, 23:44   #8  |  Link
Dark Shikari
x264 developer
 
Dark Shikari's Avatar
 
Join Date: Sep 2005
Posts: 8,666
Quote:
Originally Posted by clsid View Post
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.
Quote:
Originally Posted by clsid View Post
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.
Dark Shikari is offline   Reply With Quote
Old 7th July 2010, 01:47   #9  |  Link
Blue_MiSfit
Derek Prestegard IRL
 
Blue_MiSfit's Avatar
 
Join Date: Nov 2003
Location: Los Angeles
Posts: 5,988
AFAIK, floating point decoding is most useful when you're doing transcoding. I don't think it's THAT important for playback

Derek
__________________
These are all my personal statements, not those of my employer :)
Blue_MiSfit is offline   Reply With Quote
Old 11th July 2010, 20:03   #10  |  Link
leeperry
Kid for Today
 
Join Date: Aug 2004
Posts: 3,477
liba52 and libdts decode in 32fp, libavcodec is 16int only.
Quote:
Originally Posted by kieranrk View Post
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.

Last edited by leeperry; 11th July 2010 at 20:14.
leeperry is offline   Reply With Quote
Old 11th July 2010, 22:56   #11  |  Link
Reimar
Registered User
 
Join Date: Jun 2005
Posts: 278
Quote:
Originally Posted by leeperry View Post
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.
Reimar is offline   Reply With Quote
Old 11th July 2010, 23:06   #12  |  Link
leeperry
Kid for Today
 
Join Date: Aug 2004
Posts: 3,477
Quote:
Originally Posted by Reimar View Post
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
leeperry is offline   Reply With Quote
Old 15th July 2010, 02:50   #13  |  Link
roozhou
Registered User
 
Join Date: Apr 2008
Posts: 1,181
And why is libmad included? Doesn't mp3lib run faster and output 32fp?
roozhou is offline   Reply With Quote
Reply

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +1. The time now is 10:06.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2024, vBulletin Solutions Inc.