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. |
6th March 2011, 15:15 | #13142 | Link | |||
Registered Developer
Join Date: Sep 2006
Posts: 9,140
|
Quote:
Quote:
Audio decoders are standardized in a way, too. However, what you need to be aware of is that standards only tell us how to decode video and audio. They don't tell us how to do post processing. E.g. does the h264 standard tell you how to upsample chroma from 4:2:0 to 4:4:4? No, it doesn't, that's outside of the decoder, it's a post process. Does the h264 standard tell you how to downconvert 8bit per component video to 7bit per component video? Nope, it doesn't, because that's got nothing to do with encoding/decoding. The same thing applies to audio: How you post process the audio got nothing to do with decoding. So it's not specified in the codec specs. You can downconvert 24bit audio to 4bit, if you like. You shouldn't do that, but you can. So do you expect the decoder specs to contain information on how to downconvert 24bit audio to 4bit? Quote:
So the final question is: *After* the decoders have completed their task, what further processing is done to the decoded audio data? libavcodec and liba52/libdts do not differ so much in how they decode. They differ on how they post process. libavcodec violates processing laws by forcedly rounding down to 16bit integer. liba52 doesn't do that, it outputs the decoding result untouched. So the problem with libavcodec is not the decoding itself, it's the post processing, which can't be turned off. Not even via compiler switches or #defines. Last edited by madshi; 6th March 2011 at 15:18. |
|||
6th March 2011, 15:41 | #13143 | Link | |
もこたんインしたお!
Join Date: Jan 2008
Location: Finland / Japan
Posts: 512
|
Quote:
+1 reason for ffmpeg not to reject a patch that lets it handle more than one type of output. Or something that would just let the calling application get the decoded output and do whatever it wants to the output, so the next generation of audio hipsters can get their float64 or float128 instead without concerning the ffmpeg project itself (*grin*).
__________________
[I'm human, no debug]
|
|
6th March 2011, 15:49 | #13144 | Link | |
Registered User
Join Date: Oct 2008
Posts: 5
|
Quote:
Code:
/** * audio sample format * - encoding: Set by user. * - decoding: Set by libavcodec. */ enum AVSampleFormat sample_fmt; ///< sample format The audio decoding API will soon be changed anyway to return AVFrames instead of the user having to manage buffers. |
|
6th March 2011, 17:34 | #13146 | Link |
Registered User
Join Date: Oct 2008
Posts: 5
|
This time there are actual patches
EDIT: and this wouldn't affect or block any possible patches you make for sample format; it's just an user interface change not internal ffmpeg stuff Last edited by Kovensky; 6th March 2011 at 17:42. |
6th March 2011, 17:52 | #13148 | Link |
Registered User
Join Date: Feb 2008
Posts: 335
|
libdts at least should not be removed, until libavcodec can decode DTS core in DTS-HD MA track properly. My test MKVs files with DTS-HD MA tracks will not start playing, if I were to use libavcodec to play the core audio track, but with libdts playback works perfectly.
|
6th March 2011, 18:09 | #13149 | Link | ||||
4:2:0 hater
Join Date: Apr 2008
Posts: 1,302
|
Quote:
Since clsid is with the placebo guys, I'm outta this debate. At least I hope that the guy in charge of the patching does it right: by patching AAC, AC3, DTS, Vorbis, WMA and Nellymoser. That's another thing I've noticed, the guys complaining only complain because it affects themselves directly. ffdshow is a lot more than an AC3/DTS decoder for playing your DVDs. I don't remember anyone complaining when tremor (32-bit int output) was removed, leaving only libavcodec (16-bit int). A word exist for this: hipocrisy. Quote:
And as always, you don't answer the key questions, only what's best for your interests. I will do the same with you from now on. Quote:
Quote:
Last edited by STaRGaZeR; 6th March 2011 at 19:29. |
||||
6th March 2011, 18:25 | #13150 | Link | ||
Registered User
Join Date: Sep 2004
Posts: 1,295
|
Quote:
Quote:
I don't know every single feature of ffdshow. It contains a lot more decoders than I will ever need, so it's natural for me to complain only about the parts that I know. |
||
6th March 2011, 18:50 | #13151 | Link | |||
Registered Developer
Join Date: Sep 2006
Posts: 9,140
|
Quote:
Quote:
Quote:
Ok, didn't know that. But it doesn't change the fact that the libavcodec DTS decoder natively produces floating point samples. Rounding them to 16bit integer samples introduces quantization noise. |
|||
6th March 2011, 19:10 | #13152 | Link | ||
4:2:0 hater
Join Date: Apr 2008
Posts: 1,302
|
Maybe I'm missing something, but I don't remember you saying anywhere that liba52, libdts, libfaad or libmad sound better than unpatched libavcodec? Can you point me to it? All I read is "32 to 16 sucks, adds shit to the decoded PCM". While this is 100% true, you're comparing patched libavcodec with unpatched libavcodec. And the debate is not there.
Quote:
Quote:
Read the first quote: the debate is not here. |
||
6th March 2011, 19:40 | #13153 | Link | ||
Registered Developer
Join Date: Sep 2006
Posts: 9,140
|
Not really. If libavcodec *dithered* down to 16bit, I would agree with removing liba52 and libdts. The problem is not doing a conversion from 32bit float to 16bit integer. That's fine with me. The problem is that libav is doing the conversion in a bad way.
Quote:
Quote:
I think you're misunderstanding me a bit: I do not explicitly claim that liba52 sounds noticeably better than libavcodec. I don't know that for a fact. *However*, there's a known problem with libavcodec decoding quality, while there is no known problem with liba52 decoding quality. This alone is IMHO a key argument to not remove liba52 until the libavcodec problem is fixed. I don't see any sense in removing a decoder which has no known audio quality problems in favor of another decoder which does have known audio quality problems. And that's basically what I was trying to say from the start. |
||
6th March 2011, 19:53 | #13154 | Link | |
Registered User
Join Date: Nov 2006
Posts: 799
|
Quote:
|
|
6th March 2011, 20:48 | #13155 | Link |
*****
Join Date: Feb 2005
Posts: 5,642
|
Here is a test build with fp32 output for libavcodec AC3 and DTS:
http://www.sendspace.com/file/lrjn02
__________________
MPC-HC 2.1.7.2 |
6th March 2011, 20:50 | #13156 | Link | ||||
4:2:0 hater
Join Date: Apr 2008
Posts: 1,302
|
Quote:
Quote:
Quote:
Quote:
And just for the record: the libs removal was in no way inmediate. Time is needed to fix any possible bugs in ffdshow's implementation of libavcodec. You, in the meantime, should try to get the ffmpeg stuff done. That's where you excell, and with the new ffmpeg's direction I see it doable. Go for it. |
||||
6th March 2011, 21:00 | #13157 | Link | |
4:2:0 hater
Join Date: Apr 2008
Posts: 1,302
|
Quote:
|
|
6th March 2011, 21:03 | #13158 | Link | |
_
Join Date: May 2008
Location: France
Posts: 692
|
Quote:
In my case, I don't hear any difference between sources in 16 bits, 24 bits, 44100Hz, 96000Hz etc. But even if it's boring for you, it's a good thing that there is a discussion. Better now than later. |
|
6th March 2011, 21:26 | #13159 | Link |
Registered User
Join Date: Jul 2008
Posts: 184
|
AFAIK on Hydrogenaudio they actually prefer if you can provide ABX results for your comparisons. That's based on what you hear and not on numbers. But that's for more minute differences than 32 bit downconverted with and without dithering, for which they have an agreed upon stance (the same as madshi's) based on past ABX tests. That's also why they don't like certain people who post here on Doom9 that use company press releases as evidence for superior audio quality and don't provide ABX comparisons for their claims that (eg.) upsampling 44.1 kHz to 96 kHz makes audio sound better.
|
6th March 2011, 21:42 | #13160 | Link | |
Registered User
Join Date: Aug 2008
Posts: 231
|
E-AC3 as well.
I guess very few people need Vorbis in ffdshow. In fact only AAC, (E-)AC3 and DTS decoders need to be patched. Everything else either work as it should or simply not used. BTW I don't know who needs 12 (twelve) software deinterlacers (and +1 HW) in ffdshow. Quote:
Thanks, clsid Last edited by Gleb Egorych; 6th March 2011 at 22:04. |
|
Tags |
ffdshow, ffdshow tryouts, ffdshow-mt, ffplay, icl |
Thread Tools | Search this Thread |
Display Modes | |
|
|