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, 23:38   #12561  |  Link
STaRGaZeR
4:2:0 hater
 
Join Date: Apr 2008
Posts: 1,302
Quote:
Originally Posted by leeperry View Post
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).


Every option in sound processing was checked. Every option in the output section was checked. It seems you don't get that I've modified ffdshow to process winamp plugins in 24-bit (output is zeroed to 32-bit) instead of 16-bit here in my system, by changing "tons of "int16_t"/"SF_PCM16" in those sections" into something else following your own words. Too bad I couln't get 32-bit to work, everything was fine but the audio returned from the plugin was untouched. Just a FYI:

Code:
int (*ModifySamples)(struct winampDSPModule *this_mod, int16_t *samples, int numsamples, int bps, int nch, int srate)
Notice that little int bps? 16, 24, etc. etc.

Quote:
Originally Posted by leeperry View Post
Sorry for that, I know that posting in the ffdshow thread is a waste of time. Won't happen again
Someone wanna bet on this?
__________________
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, 23:59   #12562  |  Link
Midzuki
Unavailable
 
Midzuki's Avatar
 
Join Date: Mar 2009
Location: offline
Posts: 1,480
Quote:
Originally Posted by STaRGaZeR View Post
Cool, I can own our two resident trolls in one shot
As Palpatine surely would say,

"Troll is a point of view".

Also, you cannot deny that many devilopers can be scientifically defined as "the trolls who got there first".
Midzuki is offline   Reply With Quote
Old 29th September 2010, 00:04   #12563  |  Link
tetsuo55
MPC-HC Project Manager
 
Join Date: Mar 2007
Posts: 2,317
Quote:
Originally Posted by diizzy View Post
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?
indeed, i want to see some scientific research done on this.

We can output the wav files and compare them right? so whats the difference?

When madshi had to prove his renderer does better chroma scaling he made a screenshot comparison, and i've seen tools that can highlight the pixels that the better scaling affects.
the same should be possible for audio, no need to involve ears or speakers. just the pure wave, is it different or not, and if so where.
__________________
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 29th September 2010, 00:54   #12564  |  Link
kieranrk
Registered User
 
Join Date: Jun 2009
Location: London, United Kingdom
Posts: 707
Quote:
Originally Posted by tetsuo55 View Post
just the pure wave, is it different or not, and if so where.
If you want to show better chroma upsampling then you show a picture; if you want to show better audio quality you have to do it with an audio track.

Last edited by kieranrk; 29th September 2010 at 01:01.
kieranrk is offline   Reply With Quote
Old 29th September 2010, 02:53   #12565  |  Link
STaRGaZeR
4:2:0 hater
 
Join Date: Apr 2008
Posts: 1,302
Some new tests with O2 and O3:

Sample 1: Blu-ray, 1080p24, ~35Mbps

O2 --> 178,12fps
O3 --> 182,43fps

Sample 2: Blu-ray, 1080i30, ~35Mbps

O2 --> 166,9fps
O3 --> 169,9fps

Sample 3: Big Buck Bunny, 720p24, ~2,5Mbps

O2 --> 672.06fps
O3 --> 677.42fps

1-2% difference. What do you think about changing it? Binaries are ~25% smaller with GCC 4.5.1
__________________
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 29th September 2010, 08:05   #12566  |  Link
madshi
Registered Developer
 
Join Date: Sep 2006
Posts: 9,140
Quote:
Originally Posted by diizzy View Post
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?
First of all we're not talking about interpolation here. All we're (some of us are) asking about is to do the math as precise as possible, which in the worst case should sound equal to doing the math unprecise, and in the best case should sound noticeably better.

Next, you're saying that most non-HD formats are 16bit, which is simply not true. AC3 and DTS are non-HD formats and perfectly support 24bit encodings. There's even a DTS header field which tells you which bitdepth was fed to the encoder. And from my experience there are plenty of 24bit DTS encodings out there, and I'm not talking about DTS-HD here. For AC3 we will never know which bitdepth was fed to the encoder, but the encoder also happily encodes 24bit sources. So it's a fair guess that many studio created AC3 tracks were also created from 24bit sources.

I've done tests myself with rounding vs. dithering. Ok, I've done them at a lower bitdepth than 16bit to make the difference very easily audible and the difference was big. Of course with 16bit the difference is much smaller. But still, rounding is scientifically and mathematically worse than dithering. And libav rounds down every DTS and AC3 audio track to 16bit, no questions asked.

Quote:
Originally Posted by tetsuo55 View Post
indeed, i want to see some scientific research done on this.
Easy, the web is full of proof that dithering is needed. E.g. this is a nice starting point:

http://www.users.qwest.net/~volt42/c...rExplained.pdf
madshi is offline   Reply With Quote
Old 29th September 2010, 08:18   #12567  |  Link
tetsuo55
MPC-HC Project Manager
 
Join Date: Mar 2007
Posts: 2,317
That document clearly shows that a 24bit (lossless?) source benefits from 24bit output or dithering over truncation.
However what kierank seems to suggest is that lossless codecs seem to expect the truncation, the encoder/decoder psy optimises the stream to not become ugly like the examples in the document.

For the argument to be settled, the same test as explained in that document should be repeated (by either side of the argument) but this time using a typical lossy sample.
__________________
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 29th September 2010, 08:30   #12568  |  Link
madshi
Registered Developer
 
Join Date: Sep 2006
Posts: 9,140
Quote:
Originally Posted by tetsuo55 View Post
However what kierank seems to suggest is that lossless codecs seem to expect the truncation, the encoder/decoder psy optimises the stream to not become ugly like the examples in the document.
No, I don't think that's what he meant. It would be wrong, anyway. I think what he believes is that when 16bit int sources are fed into a lossy encoder, the decoder already has noise in the lower 8bit of a 24bit signal, so the signal can be truncated/rounded without side effects. I don't agree with that at all, and the paper I linked to has a clear opinion on this, as well:

> If the signal has had any processing happen to it
> at higher bit depths then choose to add dither

This is exactly what we're talking about here: "16bit int source -> lossy encoding -> lossy decoding -> 16bit int output". This processing chain has processing steps in a higher bit depth (floating point in the case of DTS and AC3), so dithering needs to be added when converting the floating point decoding results back to int16.

Furthermore, what kieranrk conveniently ignores is that AC3 and DTS tracks were often encoded directly from true 24bit studio masters.
madshi is offline   Reply With Quote
Old 29th September 2010, 08:39   #12569  |  Link
fastplayer
Registered User
 
Join Date: Nov 2006
Posts: 799
Quote:
Originally Posted by STaRGaZeR View Post
1-2% difference. What do you think about changing it? Binaries are ~25% smaller with GCC 4.5.1
Could these 1-2% - for example, for people with low CPU specs - mean the difference between playable and stutter? Why not switch to O2, wait a few weeks, see what reaction we get and decide then finally? As long as the people don't shout "Hang the bastards!", we're good
By the way, what effect has O2 vs. O3 on compile/build time?
fastplayer is offline   Reply With Quote
Old 29th September 2010, 09:51   #12570  |  Link
Reimar
Registered User
 
Join Date: Jun 2005
Posts: 278
Quote:
Originally Posted by STaRGaZeR View Post
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?
While I think it's worth a try (with some convincing it might get accepted in FFmpeg), this definitely is not the best option.
What I expect the developers to want you to do is to only support float output for decoders that use float internally, but also add scale/bias options so that decoders that are capable of it will apply these to the output "for free", and then use that to implement a very fast float -> 16 bit int conversion outside the codec like the one that is currently done inside it (also means you get volume control for free).
As you can see this will be a bit of effort, just deciding on the precise design will take some time.
Reimar is offline   Reply With Quote
Old 29th September 2010, 10:16   #12571  |  Link
madshi
Registered Developer
 
Join Date: Sep 2006
Posts: 9,140
Adding scale/bias options sounds like a useful idea if you really need to squeeze out the last bit of performance on very slow hardware. But scale/bias options would also be useful if the decoders keep on outputting int16. So I don't think that changing the output data format and adding scale/bias options are (or have to be) connected in any way.
madshi is offline   Reply With Quote
Old 29th September 2010, 11:16   #12572  |  Link
Reimar
Registered User
 
Join Date: Jun 2005
Posts: 278
Quote:
Originally Posted by madshi View Post
Adding scale/bias options sounds like a useful idea if you really need to squeeze out the last bit of performance on very slow hardware. But scale/bias options would also be useful if the decoders keep on outputting int16. So I don't think that changing the output data format and adding scale/bias options are (or have to be) connected in any way.
Let me try to make this more clear: scale/bias is _required_ to avoid a (on some hardware massive, IIRC > 50%) performance regression for the float->int16 conversion if the decoders output native float.
That is very unlikely to be accepted by FFmpeg developers.
Selectable codec output format (either at run- or compiletime) might be accepted, but it is not an ideal solution (more a quick hack) and is likely to be treated as such during review.
Reimar is offline   Reply With Quote
Old 29th September 2010, 12:18   #12573  |  Link
STaRGaZeR
4:2:0 hater
 
Join Date: Apr 2008
Posts: 1,302
Quote:
Originally Posted by fastplayer View Post
Could these 1-2% - for example, for people with low CPU specs - mean the difference between playable and stutter? Why not switch to O2, wait a few weeks, see what reaction we get and decide then finally? As long as the people don't shout "Hang the bastards!", we're good
By the way, what effect has O2 vs. O3 on compile/build time?
I can't answer that with a system like mine, but considering that 2% difference I got in all cases: if your CPU is slow and can only reach 25fps during the most CPU intensive parts you'd get 24,5fps with O2 instead. Will that be enough for stutter free playback? Not sure. However if people have that kind of perfomance there's no point in using ffdshow, they should be using a faster decoder or DXVA. I like that trial period, will do that. x64 builds use O2 BTW.

And I can't really measure compile time, I'm bottlenecked by the hard drive
__________________
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; 29th September 2010 at 12:20.
STaRGaZeR is offline   Reply With Quote
Old 29th September 2010, 13:45   #12574  |  Link
fastplayer
Registered User
 
Join Date: Nov 2006
Posts: 799
ffdshow_installer.iss
Line 326 is obsolete:
Code:
Name: "audio\mp3\mp3lib"; Description: "mp3lib"; Components: ffdshow; Flags: unchecked exclusive
fastplayer is offline   Reply With Quote
Old 29th September 2010, 18:50   #12575  |  Link
dansrfe
Registered User
 
Join Date: Jan 2009
Posts: 1,210
This is kind of off-topic for the discussion at hand however i just want to point out that ass karoke support seems broken in ffdshow because while rendering I see tags all over the place.
dansrfe is offline   Reply With Quote
Old 29th September 2010, 19:11   #12576  |  Link
STaRGaZeR
4:2:0 hater
 
Join Date: Apr 2008
Posts: 1,302
Quote:
Originally Posted by dansrfe View Post
This is kind of off-topic for the discussion at hand however i just want to point out that ass karoke support seems broken in ffdshow because while rendering I see tags all over the place.
It's a known problem. Plus you just said it here. Don't post the same bugs over and over again, it'll only slow down the process. It'll eventually be fixed by someone.
__________________
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 30th September 2010, 07:12   #12577  |  Link
Midzuki
Unavailable
 
Midzuki's Avatar
 
Join Date: Mar 2009
Location: offline
Posts: 1,480
Quote:
Originally Posted by leeperry View Post
...

can't fix it due to an unmanageably messy code...

... so it's a lost cause. WYSIWYG.
I was bored , and so I hex-edited ffdshow.ax r3562, so that it couldn't connect anymore to Windows DVD Navigator (qdvd.dll) . YES!, the trick did work , BUT...

well, ...

Code:
now, the "multi-purpose" pin of the raw video filter connects to the output pin of the audio processor!




P.S.: This post is dedicated to Keiyakusha

Last edited by Midzuki; 1st October 2010 at 02:25.
Midzuki is offline   Reply With Quote
Old 30th September 2010, 10:35   #12578  |  Link
rpm7200
Registered User
 
Join Date: Apr 2009
Posts: 23
lfe crossover doesn't work with surround audio files. please fix it. i need lfe crossover.
rpm7200 is offline   Reply With Quote
Old 30th September 2010, 12:16   #12579  |  Link
nevcairiel
Registered Developer
 
Join Date: Mar 2010
Location: Hamburg/Germany
Posts: 10,344
Hey,

i noticed the other day that the audio delay doesn't work with bitstreaming, at least not with all bitstreaming formats.
I set a delay to fix A/V sync with my TV, and it was all peachy with PCM. But when bitstreaming AC3 for example, i get no sound at all anymore.
It seemed to work when streaming DTS-HD, but not with DTS.. I can run more tests on other formats if that helps.
__________________
LAV Filters - open source ffmpeg based media splitter and decoders
nevcairiel is offline   Reply With Quote
Old 30th September 2010, 12:25   #12580  |  Link
Sebastiii
Registered User
 
Join Date: Oct 2009
Location: France
Posts: 615
Quote:
Originally Posted by nevcairiel View Post
Hey,

i noticed the other day that the audio delay doesn't work with bitstreaming, at least not with all bitstreaming formats.
I set a delay to fix A/V sync with my TV, and it was all peachy with PCM. But when bitstreaming AC3 for example, i get no sound at all anymore.
It seemed to work when streaming DTS-HD, but not with DTS.. I can run more tests on other formats if that helps.
I also remark this when i use reclock, but without it, it's ok
Doesnt know what happen lol.
__________________
HTPC : i7 920 6Go Win10(x64) / Nvidia 1050Ti / P6T Deluxe / Harman-Kardon AVR-355.
Sebastiii 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 09:58.


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