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 28th September 2010, 16:25   #12541  |  Link
madshi
Registered Developer
 
Join Date: Sep 2006
Posts: 9,140
Quote:
Originally Posted by Reimar View Post
If you take a 16 bit input, add random bits to expand it to 24 bit
What are you talking about? I don't think anybody is doing that.

Quote:
Originally Posted by Reimar View Post
If the encoder never had more than 16 bit to start with, anything more than 16 bit in the decoded output can't be much more than noise
I'm not really sure if you understand how lossy encoding/decoding works. Look, the encoder gets samples in the time domain, but encoding is done in the frequency domain (for lossy formats). After conversion to frequency domain, you end up with floating point data with full precision. The precision is not limited to 16bit here, because the conversion to frequency domain is a complex mathematical process. In the next step the encoder compresses the frequency domain audio data. Later, when you decode that, you again get floating point frequency data back. This will not be identical to the input data, of course, since the encoder is lossy. The decoder converts the frequency data back to time domain, which means that you end up with *full precision* floating point time domain data. Because of that you cannot say that only 16bit contain data and the rest is noise. That doesn't make any sense. The native output of a lossy decoder is usually *full precision* floating point. This data will only be an approximation of the original input data, but still it is full precision. You can't say that the data is only 16bit and the rest is noise. That's not true. After decoding, the data is floating point, not 16bit. The decoder doesn't even *try* to reproduce the original 16bit PCM data. Instead the decoder tries to reproduce an approximation of the original frequencies. And it does so in full floating point precision. Of course the decoding result will never sound better than the 16bit original, though, because it's only an approximation.
madshi is offline   Reply With Quote
Old 28th September 2010, 17:22   #12542  |  Link
clsid
*****
 
Join Date: Feb 2005
Posts: 5,642
I am OK with removing Theora and mp3lib.
__________________
MPC-HC 2.1.7.2
clsid is offline   Reply With Quote
Old 28th September 2010, 18:00   #12543  |  Link
kieranrk
Registered User
 
Join Date: Jun 2009
Location: London, United Kingdom
Posts: 707
Quote:
Originally Posted by Reimar View Post
But if someone sends a patch to fix this issue, there'd probably no objections to changing the output format.
I would suggest including float output in ENABLE_AUDIOPHILE_KIDDY_MODE (which already exists).
kieranrk is offline   Reply With Quote
Old 28th September 2010, 18:14   #12544  |  Link
nevcairiel
Registered Developer
 
Join Date: Mar 2010
Location: Hamburg/Germany
Posts: 10,342
Quote:
Originally Posted by kieranrk View Post
I would suggest including float output in ENABLE_AUDIOPHILE_KIDDY_MODE (which already exists).
You realize that it already decodes in full floating point? All we basically ask for is to move the conversion to int16 from the decoder to ffdshow. If you're happy with int16, it wouldn't change much for you at all, but if you're not, you can select another bitdepth for output, and you get higher quality.

No downsides, just added value. Why are you arguing?
__________________
LAV Filters - open source ffmpeg based media splitter and decoders
nevcairiel is online now   Reply With Quote
Old 28th September 2010, 18:26   #12545  |  Link
leeperry
Kid for Today
 
Join Date: Aug 2004
Posts: 3,477
Quote:
Originally Posted by kieranrk View Post
I would suggest including float output in ENABLE_AUDIOPHILE_KIDDY_MODE (which already exists).
A troll is a troll, but troll feeding can be fun sometimes.

madVR brings world class PQ, and ffdshow sub-par consumer SQ...you're watching your videos in YV12 OVERLAY point resize on an ATi I presume

All it needs is a few fixes, it will not worsen the SQ...at worst, it'll sound the same to your ears. Point of the matter is that either the few active coders don't care(libavcodec) or can't fix it due to an unmanageably messy code(ffdshow audio) so it's a lost cause. WYSIWYG.

Last edited by leeperry; 28th September 2010 at 19:40.
leeperry is offline   Reply With Quote
Old 28th September 2010, 18:28   #12546  |  Link
madshi
Registered Developer
 
Join Date: Sep 2006
Posts: 9,140
Quote:
Originally Posted by nevcairiel View Post
Why are you arguing?
Because he evidently does not understand the basic laws of digital audio processing.
madshi is offline   Reply With Quote
Old 28th September 2010, 18:41   #12547  |  Link
kieranrk
Registered User
 
Join Date: Jun 2009
Location: London, United Kingdom
Posts: 707
Quote:
Originally Posted by madshi View Post
Because he evidently does not understand the basic laws of digital audio processing.
Having written a decoder for a perceptual audio format (with floating point transforms) I can tell you that's not the case.

All I'm saying is that the people arguing for float output because of "higher quality" are wrong. It is also laughable to see leeperry's talk of 64bit float - I can guarantee the decoder from the audio codec is 16-bit int or possibly 32-bit float at most. As reimar said the encoder had most likely 16-bit input in the first place so insisting on float producing a higher quality is an invalid argument. The LSBs of audio are generally noise anyway.

Feel free to also add the slowest but "highest quality" DCTs for mpeg-2 video and other codecs while you're at it. Also rewrite ffmpeg's MDCT to use 64-bit float since it "only" uses 32-bit float.

Last edited by kieranrk; 28th September 2010 at 18:54.
kieranrk is offline   Reply With Quote
Old 28th September 2010, 19:00   #12548  |  Link
madshi
Registered Developer
 
Join Date: Sep 2006
Posts: 9,140
Quote:
Originally Posted by kieranrk View Post
Having written a decoder for a perceptual audio format (with floating point transforms) I can tell you that's not the case.
Then you do know that every time you reduce audio bitdepth, you have to apply dithering, if you don't want to introduce quantization noise. Do you know that, or do you not? Are you aware that libav violates this basic processing law, or are you not aware of that?

Quote:
Originally Posted by kieranrk View Post
All I'm saying is that the people arguing for float output because of "higher quality" are wrong.
No, they are right. Because of the simple reason that libav currently does not *dither* down to 16bit, but they *round* down the internal float32 decoding data to 16bit int. Which is a violation of audio processing laws and adds quantization noise. If libav correctly dithered down to 16bit, there would be little point to ask for floating point output. Not for ffdshow, at least.
madshi is offline   Reply With Quote
Old 28th September 2010, 19:24   #12549  |  Link
kieranrk
Registered User
 
Join Date: Jun 2009
Location: London, United Kingdom
Posts: 707
Quote:
Originally Posted by madshi View Post
...
Read what Reimar said.
kieranrk is offline   Reply With Quote
Old 28th September 2010, 19:50   #12550  |  Link
leeperry
Kid for Today
 
Join Date: Aug 2004
Posts: 3,477
Quote:
Originally Posted by kieranrk View Post
It is also laughable to see leeperry's talk of 64bit float - I can guarantee the decoder from the audio codec is 16-bit int or possibly 32-bit float at most.
http://www.sonicspot.com/lame/history.html
Quote:
found bugs in some sections when using 32 bit floating point. Default is now back to 64bit floating point.
Lilith decodes MP3 in 64fp and processes attenuation/VST plugins in 64fp as well...just like any serious pro-audio app. The higher the resolution, the less distorted the tiny details and phase coherence will be.

Reclock provides 53bit volume attenuation and bit-perfect float/integer conversions(they all pass the HDCD flag and were looked over by WingFeather -a pro VST plugin coder from diyaudio.com-, James and yesgrey).

I use a low jitter 24/96 transport w/ Reclock via a bit-perfect audio renderer, and my two bottlenecks are libavcodec for DTS and the VST plugins processed in 16int...Some call it parroting, I call it uncalled for and a damn shame as the chain is only as strong as its weakest link. But nothing ever works the way it should thanks to Murphy's Law, so that's no big deal.
leeperry is offline   Reply With Quote
Old 28th September 2010, 19:51   #12551  |  Link
STaRGaZeR
4:2:0 hater
 
Join Date: Apr 2008
Posts: 1,302
Quote:
Originally Posted by _xxl View Post
If you can update it ok. If not remove it.

x264 should be updated to latest, I can t update it anymore....
Quote:
Originally Posted by fastplayer View Post
clsid disabled it some time ago in the hope that someone would update it. IIRC the current version in the trunk is hopelessly outdated.
I don't care about Theora really, the best thing is to remove it IMO. libavcodec handles it just fine. I'll do it. clsid, I can't update ICL10 project files, sorry about that.

Quote:
Originally Posted by Reimar View Post
I think some were changed. The biggest issue is that the format conversion inside the codec uses some tricks to be a lot faster, particularly on systems with slow FPU like ARM. Just removing them would mean that FFmpeg would get a lot slower on these systems.
And for FFmpeg speed (even on non-mainstream platforms) is most important than output resolution.
But if someone sends a patch to fix this issue, there'd probably no objections to changing the output format.
I agree with madshi, the best solution would be a compile time option. Very few lines of code to make everyone happy. Can you make those patches and send them, madshi?
__________________
Specs, GTX970 - PLS 1440p@96Hz
Quote:
Originally Posted by Manao View Post
That way, you have xxxx[p|i]yyy, where xxxx is the vertical resolution, yyy is the temporal resolution, and 'i' says the image has been irremediably destroyed.
STaRGaZeR is offline   Reply With Quote
Old 28th September 2010, 20:00   #12552  |  Link
STaRGaZeR
4:2:0 hater
 
Join Date: Apr 2008
Posts: 1,302
Quote:
Originally Posted by leeperry View Post
If you had a bugtracker anyone cared about, this wouldn't be happening...bumping bugfixes requests is the only chance to see anything happening(just like MPC).

I've asked three very skilled audio plugins coders for help and they've all told me that the ffdshow audio code was a bug feast(full of syntax errors and beginners mistakes) and a huge mess...so I guess this is not going to change anytime soon. They were even wondering how it could be working at all

ffdshow is a lost cause for studio grade audio, atm it's just a toy to watch movies in WMP...sorry for rubbing it in
Stop the presses, a freak wants studio grade stuff for free ASAP!!!

lol, you talk like if it were my responsability or something. I was going to fix it, but now I don't feel like it. Enjoy the wonderful 16-bit integer output, troll
__________________
Specs, GTX970 - PLS 1440p@96Hz
Quote:
Originally Posted by Manao View Post
That way, you have xxxx[p|i]yyy, where xxxx is the vertical resolution, yyy is the temporal resolution, and 'i' says the image has been irremediably destroyed.

Last edited by STaRGaZeR; 28th September 2010 at 20:03.
STaRGaZeR is offline   Reply With Quote
Old 28th September 2010, 20:02   #12553  |  Link
fastplayer
Registered User
 
Join Date: Nov 2006
Posts: 799
Quote:
Originally Posted by STaRGaZeR View Post
libavcodec handles it just fine.
Yep, libavcodec seems to be the solution for every "problem" lately
fastplayer is offline   Reply With Quote
Old 28th September 2010, 20:12   #12554  |  Link
leeperry
Kid for Today
 
Join Date: Aug 2004
Posts: 3,477
Quote:
Originally Posted by STaRGaZeR View Post
Stop the presses, a freak wants studio grade stuff for free ASAP!!!

lol, you talk like if it were my responsability or something. I was going to fix it, but now I don't feel like it. Enjoy the wonderful 16-bit integer output, troll
hehe, yeah exactly...can you please make libavcodec and the winamp2 plugins output 8int? that'd be the shiznit, and that'd make kieranrk happy too

I don't think I'm the troll here, but the french and british have never managed to get along nicely...that's what hundred years of history are teaching us.

3 highly skilled coders(Vincent Burel, Wingfeather and Christian Budde) said that ffdshow shouldn't even work as is...but surely you could fix it, I believe you. I really do.

Last edited by leeperry; 28th September 2010 at 20:30.
leeperry is offline   Reply With Quote
Old 28th September 2010, 20:38   #12555  |  Link
Midzuki
Unavailable
 
Midzuki's Avatar
 
Join Date: Mar 2009
Location: offline
Posts: 1,480
Quote:
Originally Posted by STaRGaZeR View Post
I was going to fix it,
I seriously doubt that.
Midzuki is offline   Reply With Quote
Old 28th September 2010, 20:43   #12556  |  Link
STaRGaZeR
4:2:0 hater
 
Join Date: Apr 2008
Posts: 1,302
Cool, I can own our two resident trolls in one shot



Winamp works with 32-bit integer max, and there you have it working with a simple equalizer. If you want a video of it working, just let me know
__________________
Specs, GTX970 - PLS 1440p@96Hz
Quote:
Originally Posted by Manao View Post
That way, you have xxxx[p|i]yyy, where xxxx is the vertical resolution, yyy is the temporal resolution, and 'i' says the image has been irremediably destroyed.
STaRGaZeR is offline   Reply With Quote
Old 28th September 2010, 20:46   #12557  |  Link
avih
Capture, Deinterlace
 
avih's Avatar
 
Join Date: Feb 2002
Location: Right there
Posts: 1,971
Quote:
Originally Posted by leeperry View Post
hehe, yeah exactly...can you please make libavcodec and the winamp2 plugins output 8int? that'd be the shiznit, and that'd make kieranrk happy too

I don't think I'm the troll here, but the french and british have never managed to get along nicely...that's what hundred years of history are teaching us.

3 highly skilled coders(Vincent Burel, Wingfeather and Christian Budde) said that ffdshow shouldn't even work as is...but surely you could fix it, I believe you. I really do.
Dude, take it easy, you've made your point. Please try to lower the volume of your posts and stay closer to the topic.

Thanks.
avih is offline   Reply With Quote
Old 28th September 2010, 21:32   #12558  |  Link
leeperry
Kid for Today
 
Join Date: Aug 2004
Posts: 3,477
Quote:
Originally Posted by STaRGaZeR View Post
Cool, I can own our two resident trolls in one shot [..]
Winamp works with 32-bit integer max, and there you have it working with a simple equalizer. If you want a video of it working, just let me know
What are you trying to prove exactly? You obviously set the ffdshow sound processing bitdepth higher than 16int, and the 16int off the decoder and winamp2 DSP plugin are being resampled to 32int/32fp(depending on what you chose).

I've inserted the Ozone4 bitmeter in MPC Classic between ffdshow and Reclock, and set ffdshow to 32fp:
DTS in ffdshow/libavcodec:
DTS in ffdshow/libdts:
DTS in ffdshow/libdts + a winamp2 DSP wrapper>VST plugin in ffdshow:

both libavcodec and the winamp2 DSP plugins are processed in 16int and trim the 8 least significant bits...but nice try.
Quote:
Originally Posted by avih View Post
Dude, take it easy, you've made your point. Please try to lower the volume of your posts and stay closer to the topic.

Thanks.
Sorry for that, I know that posting in the ffdshow thread is a waste of time. Won't happen again

Last edited by leeperry; 28th September 2010 at 21:40.
leeperry is offline   Reply With Quote
Old 28th September 2010, 22:26   #12559  |  Link
Astrophizz
Registered User
 
Join Date: Jul 2008
Posts: 184
So, if I understand correctly, there is no intent to have libav dither to 16 bit?
Astrophizz is offline   Reply With Quote
Old 28th September 2010, 23:18   #12560  |  Link
diizzy
Registered User
 
Join Date: Feb 2007
Posts: 49
While this 16-bit int vs * float seems to get people a bit defensive I would like to ask how "inaccurate" is it really? Given that many formats except HD formats are 16-bit or even lower the degradation should be minimal or none at all nor do you really know if the encoder used a higher precision during encoding right? As far as I know most people use analogue cabling at least to the speakers you would also introduce further degradation since there's no digital correction of any kind. Also having in mind that speakers or headphones usually don't have a flat frequency curve this would sound degrade even further. While I do agree that precision is a good thing in general and that it may / may not make a huge performance impact I also understand if some say that rounding doesn't matter since the sound will get dirty on the way to your ears. Fine, audio processing should be lossless but interpolating which might happen since you have more precision (and then at some point round it) than during encode time might not be a great solution either.
Am I missing something here?
diizzy is offline   Reply With Quote
Reply

Tags
ffdshow, ffdshow tryouts, ffdshow-mt, ffplay, icl

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 11:59.


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