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 22nd September 2010, 13:10   #1  |  Link
Sharktooth
Mr. Sandman
 
Sharktooth's Avatar
 
Join Date: Sep 2003
Location: Haddonfield, IL
Posts: 11,768
FFDShow and 32bit Float.

I've noticed there were some commits in FFDShow-tryouts that enables 32bit float in some decoders.
I would like to stress the fact it is perfectly USELESS.
It's not better in quality and it's not faster unless you have a CPU that executes FP operations faster than INT...

Last edited by Sharktooth; 22nd September 2010 at 13:13.
Sharktooth is offline   Reply With Quote
Old 22nd September 2010, 13:56   #2  |  Link
nevcairiel
Registered Developer
 
Join Date: Mar 2010
Location: Hamburg/Germany
Posts: 9,657
It depends on the decoder, but if all it was providing before was 16bit int, it is in fact better quality. Going from 32-bit int to 32-bit float is pointless, however.
This only matters of course if you do post-processing on the audio (and/or outputting more then 16bit int to your sound card)
__________________
LAV Filters - open source ffmpeg based media splitter and decoders
nevcairiel is offline   Reply With Quote
Old 22nd September 2010, 14:15   #3  |  Link
Sharktooth
Mr. Sandman
 
Sharktooth's Avatar
 
Join Date: Sep 2003
Location: Haddonfield, IL
Posts: 11,768
24bit int is what most soundcards are capable of. still 32bit float is useless coz it's in the decoder.
post processing happens AFTER the decoding. so, again, it's useless.
Sharktooth is offline   Reply With Quote
Old 22nd September 2010, 14:39   #4  |  Link
pandy
Registered User
 
Join Date: Mar 2006
Posts: 1,041
With float You can have 24 bit INT accuracy and higher dynamic range than 24 bit INT without checking and scaling (at least in theory).
Modern CPU are quite similar in terms of speed FP and INT.
pandy is offline   Reply With Quote
Old 22nd September 2010, 14:48   #5  |  Link
Sharktooth
Mr. Sandman
 
Sharktooth's Avatar
 
Join Date: Sep 2003
Location: Haddonfield, IL
Posts: 11,768
the correct terms you should have used are "you COULD, in theory, maybe...", but it's not the case.
every sane encoder uses an INT transform (including video encoders). so, using FP is, again... USELESS.
its all FUD and no good...
oh, and however, Int ops are way faster than FP ops even on modern CPUs, otherwise x264 would use FP... dont you think?

Last edited by Sharktooth; 22nd September 2010 at 14:53.
Sharktooth is offline   Reply With Quote
Old 22nd September 2010, 15:29   #6  |  Link
Gser
Registered User
 
Join Date: Apr 2008
Posts: 397
Meh, my core i7 4,2Ghz doesn't complain, so why should I.
Gser is offline   Reply With Quote
Old 22nd September 2010, 16:07   #7  |  Link
tetsuo55
MPC-HC Project Manager
 
Join Date: Mar 2007
Posts: 2,317
The most important part right now is that the extra bits above 16, if/when available are no longer clipped off.
__________________
MPC-HC, an open source project everyone can improve. Want to help? Test Nightly Builds, submit patches or bugs and chat on IRC
tetsuo55 is offline   Reply With Quote
Old 22nd September 2010, 20:30   #8  |  Link
nevcairiel
Registered Developer
 
Join Date: Mar 2010
Location: Hamburg/Germany
Posts: 9,657
libavcodec can output the 32bit float directly to the application using it, not only internally, so it can be used for post-processing by ffdshow, and then dithered to 16 or 24bit int for output.
If its done this way, i don't know. I know that in the case of the mpeg audio decoder in libavcodec, the integer decoder is actually better, and can be set to produce 32bit ints (a new float decoder was up as a GSoC task, but didnt happen afaik).

Anyhow, for many other decoders in avcodec, they internally already use float processing, but then cut the output to 16bit int for reasons unknown to me (probably compatibility or something).
For lossy formats, you should always try to keep the highest bitdepth possible in your decoding chain. In my system i have ffdshow output 32bit int to reclock, which then does its resampling magic, and converts it to 24bit before its send to the hardware, so any improvements on bit-depth up from the 16bit int are appreciated.
__________________
LAV Filters - open source ffmpeg based media splitter and decoders

Last edited by nevcairiel; 22nd September 2010 at 20:33.
nevcairiel is offline   Reply With Quote
Old 22nd September 2010, 23:44   #9  |  Link
STaRGaZeR
4:2:0 hater
 
Join Date: Apr 2008
Posts: 1,307
The only problem I have with the float decoder is that it produces garbled sound in x64 builds. Is this a known problem when compiling for Win64 or it's just GCC doing its wonderful job like it did with the Vorbis decoder some time ago?
__________________
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 23rd September 2010, 12:18   #10  |  Link
pandy
Registered User
 
Join Date: Mar 2006
Posts: 1,041
Quote:
Originally Posted by Sharktooth View Post
the correct terms you should have used are "you COULD, in theory, maybe...", but it's not the case.
yes and no...

Quote:
Originally Posted by Sharktooth View Post
every sane encoder uses an INT transform (including video encoders). so, using FP is, again... USELESS.
its all FUD and no good...
yes and no...
how frequently in video domain IIR filters are used ?

Quote:
Originally Posted by Sharktooth View Post
oh, and however, Int ops are way faster than FP ops even on modern CPUs, otherwise x264 would use FP... dont you think?
yes and no...
x264 use (SIMD) features in modern CPU and focus on performance and 8 bit samples

how fast is INT MAC and FP MAC (or rather FMA instruction in FP) on x86 (FMA seems exist only in Itanium family - still waiting for SSE5)
pandy is offline   Reply With Quote
Old 27th September 2010, 16:42   #11  |  Link
Blue_MiSfit
Derek Prestegard IRL
 
Blue_MiSfit's Avatar
 
Join Date: Nov 2003
Location: Los Angeles
Posts: 5,471
Am I correct in thinking that when doing channel / volume adjustments (i.e. downmixing to 3.1 and applying DRC as I do every day), clipping can be reduced by keeping the entire processing chain in higher bit depth?

Not sure if I'm correct, but it seems logical enough...

Derek
Blue_MiSfit is offline   Reply With Quote
Old 27th September 2010, 18:29   #12  |  Link
nevcairiel
Registered Developer
 
Join Date: Mar 2010
Location: Hamburg/Germany
Posts: 9,657
Your thoughts are correct. When you do any processing on the audio, you should do it in the highest bitdepth you can.
__________________
LAV Filters - open source ffmpeg based media splitter and decoders
nevcairiel is offline   Reply With Quote
Old 28th September 2010, 02:41   #13  |  Link
Blue_MiSfit
Derek Prestegard IRL
 
Blue_MiSfit's Avatar
 
Join Date: Nov 2003
Location: Los Angeles
Posts: 5,471
Then it seems logical to assume that 32 bit float decode could definitely help me!

I often want to apply heavy DRC to a movie, and even though AC3 metadata should guide the decoder perfectly, it certainly doesn't all of the time.. especially on captured TV shows.

ffdshow-tryouts currently gives me fairly nasty clipping artifacts occasionally when I use the "volume" filter to perform DRC.

Derek
Blue_MiSfit is offline   Reply With Quote
Old 29th September 2010, 10:49   #14  |  Link
pandy
Registered User
 
Join Date: Mar 2006
Posts: 1,041
Float gives only 24 bit accuracy and higher dynamic range - developer is free from thinking about all that scaling problems, range overflow which is in INT domain - but careful 32bit INT is better than 32 bit float (anyway high end audio algorithms use at least 48 bit INT or 64 bit float)
pandy is offline   Reply With Quote
Old 1st October 2010, 02:13   #15  |  Link
Sharktooth
Mr. Sandman
 
Sharktooth's Avatar
 
Join Date: Sep 2003
Location: Haddonfield, IL
Posts: 11,768
24bit int is what is needed, at least on processing done by ffdshow. im still convinced 32bit float is an overkill and leads to rounding/scaling errors.
since 24bit numbers need to be stored in 32bit integers, then 32bit int is THE choice.

Last edited by Sharktooth; 1st October 2010 at 02:15.
Sharktooth is offline   Reply With Quote
Old 1st October 2010, 02:28   #16  |  Link
Dark Shikari
x264 developer
 
Dark Shikari's Avatar
 
Join Date: Sep 2005
Posts: 8,689
Quote:
Originally Posted by pandy View Post
x264 use (SIMD) features in modern CPU and focus on performance and 8 bit samples

how fast is INT MAC and FP MAC (or rather FMA instruction in FP) on x86 (FMA seems exist only in Itanium family - still waiting for SSE5)
On modern CPUs, float add is usually 3/1, float multiply is 4/1 (latency / inv throughput). Int is 1/0.33 and 3/1, respectively.
Dark Shikari is offline   Reply With Quote
Old 4th October 2010, 16:56   #17  |  Link
pandy
Registered User
 
Join Date: Mar 2006
Posts: 1,041
Quote:
Originally Posted by Dark Shikari View Post
On modern CPUs, float add is usually 3/1, float multiply is 4/1 (latency / inv throughput). Int is 1/0.33 and 3/1, respectively.
Assume that we talking about 32 bit INT vs 32 bit float (24.8)
pandy is offline   Reply With Quote
Old 6th October 2010, 21:49   #18  |  Link
cc979
Curious BetaTester
 
Join Date: Oct 2005
Posts: 430
if the option is there for 32 bit float output, probably please all

one reason i can think of is if an other dither algorithm is of 'higher' quality than its native one it would be useful
__________________
Asrock N68-S AMD Athlon(tm) II X4 620 Processor (2.6GHz) - Crucial 2GB PC6400 800MHz DDR2 - Nvidia 9600GT

Tools: ProcessExplorer & ProcessMonitor - BatchCompressor

Guide: MinGW Compiling GCC
cc979 is offline   Reply With Quote
Old 22nd October 2010, 16:03   #19  |  Link
leeperry
Kid for Today
 
Join Date: Aug 2004
Posts: 3,455
actually, who cares about 32fp when you can have 32int? 32fp can only transport 23int FWIR.

Pro-audio gear works in 48int...The best sounding audio players have a full 64fp pipeline, from the lossy audio decoders/VST plugins to the volume attenuation.

I do a lot of post-processing in ffdshow audio: custom 5.1>stereo downmix matrix, volume attenuation, VST plugins...and the sound is noticeably clearer when I enable 32int processing over 32fp

This link shows that 24int is more accurate than 16int for lossy audio decoding, I'd say that 32int decoding is the next stop...dither it back at the very last stage to 24int and be amazed by the sound clarity.

I'm currently having fun w/ a ffdshow audio patch that allows 32int VST processing...my oh, my oh! The next stop would be to make libavcodec decode AC3/DTS to 32int

Full 32int audio processing is quite something...like what mVR does for video, nothing less. Higher accuracy + dithering pay in cash in the digital world, madshi knows about that...just like Apogee and Sony w/ their stunning audio dithering algorithms.

Last edited by leeperry; 22nd October 2010 at 21:52.
leeperry is offline   Reply With Quote
Old 24th October 2010, 16:05   #20  |  Link
Sharktooth
Mr. Sandman
 
Sharktooth's Avatar
 
Join Date: Sep 2003
Location: Haddonfield, IL
Posts: 11,768
That's it. As i said 32bit Int is the way to go (and it's also faster than 32bit FP)
Sharktooth 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 12:23.


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