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 > Capturing and Editing Video > Avisynth Development

Reply
 
Thread Tools Search this Thread Display Modes
Old 9th July 2017, 17:32   #3541  |  Link
tebasuna51
Moderator
 
tebasuna51's Avatar
 
Join Date: Feb 2005
Location: Spain
Posts: 5,563
Quote:
Originally Posted by qyot27 View Post
So suddenly start forcing modern software that access AviSynth directly to invoke a pointless downconversion with inherent rounding errors just to satisfy people that want it to behave like ACM is sitting between them when it isn't
Is not the same than I say before?

I don't want than SSRC, TimeStrech, etc. accept 16 bit, convert to float and after downconvert to 16 bit to be transparent to the user.

And, for what introduce a problem when is clear in AviSynth docs?

"Audio is always converted to Float"

Point.
__________________
BeHappy, AviSynth audio transcoder, in Doom9 forums. NicAudio, BassAudio, audio decoders.
tebasuna51 is offline   Reply With Quote
Old 9th July 2017, 20:56   #3542  |  Link
qyot27
...?
 
qyot27's Avatar
 
Join Date: Nov 2005
Location: Florida
Posts: 1,050
Quote:
Originally Posted by tebasuna51 View Post
Is not the same than I say before?

I don't want than SSRC, TimeStrech, etc. accept 16 bit, convert to float and after downconvert to 16 bit to be transparent to the user.
Then you're at a fundamental disagreement with AviSynth+. The idea that users should be ignorant of format changes being done without their explicit consent is flatly and absolutely rejected. It's been like that from the start.

The output behavior isn't something AviSynth+ did, all I did was point out that OPT_AllowFloatAudio and the downconvert were not absolute. If I had my druthers, we'd do away with OPT_AllowFloatAudio entirely so that ACM behavior matches direct library access. In 2017 most programs should not have issues taking Float audio, and in the rare case one does, that should be the user's responsibility to make the script comply with it, not make the correct behavior an opt-in because some vague notion of undisclosed program names 10 years ago maybe couldn't handle Float audio.

Direct library access is the proper and preferred method to use AviSynth (explicitly so for AviSynth+, but classic AviSynth had been moving in that direction for years). It's not a bug that direct library access has only ever output the final processed format rather than forcing a downconversion. The docs not being clear about that isn't AviSynth+'s fault.
qyot27 is offline   Reply With Quote
Old 10th July 2017, 07:35   #3543  |  Link
hello_hello
Registered User
 
Join Date: Mar 2011
Posts: 3,949
What's the logic behind the formats some audio filters accept, and why isn't 16 bit converted to float for processing?

http://avisynth.nl/index.php/Amplify
"8bit and 24bit audio is converted to float; the other audio formats are kept as they are."

Is that what actually happens, or is it misleading and every format is converted to float, but for 16 bit integer it's automatically converted back?

When it comes to audio bit depth, I'm not sure I'd care about converting to a higher bitdepth automatically. You don't lose quality, and a higher bit depth output generally wouldn't be a problem. If the output is being converted to a lossy format and float is acceptable, (why is LAME still limited to 24 bit?) the user gets to be ignorant of no harm having been done.
If AVS did convert to float when a filter needed it, there's a possibility user intervention would be being required at the output stage rather than prior to the filter, but if it doesn't, user intervention is required each time a similar filter is used.
.
Automatically converting video from one type to another is one thing, but I'm not sure converting "type" and converting "bit depth" necessarily have to follow the same rules. If I was ruler of the world, the law would require the same bit depth in and out when there's no processing involved, and float when there is, as all filters would be required to accept float.

How does an all high bit depth video environment work? I had imagined in a perfect world you'd open a video of any bitdepth and it'd be upsampled to the highest bitdepth possible for processing, and only converted to the original/user specified bit depth at the output stage. It's probably not that simple for AVS+ at the moment, but wouldn't the ideal be for AVS+ to upsample all video automatically to be processed with native 16 bit filters/plugins, and only require the user to permit/specify a change of bitdepth when loading a legacy 8 bit plugin, or at the final output stage?

Last edited by hello_hello; 10th July 2017 at 07:37.
hello_hello is offline   Reply With Quote
Old 10th July 2017, 15:22   #3544  |  Link
qyot27
...?
 
qyot27's Avatar
 
Join Date: Nov 2005
Location: Florida
Posts: 1,050
Quote:
Originally Posted by hello_hello View Post
What's the logic behind the formats some audio filters accept, and why isn't 16 bit converted to float for processing?
When a filter is written, the formats it supports are based on how the methodology of the algorithm it uses to do the processing was written. Fixed-point (integer) math is often fastest, especially because there's a lot more useful SIMD instructions designed for fixed-point than there are for floating point. This is true for audio or video filters.

Quote:
Is that what actually happens, or is it misleading and every format is converted to float, but for 16 bit integer it's automatically converted back?
No, the filter doesn't support processing in 8 or 24 bit, so it converts the file's depth in order to process in 16 bit. Some filters support both 16 bit or Float, in which case it probably prefers 16 bit if the file is already integer, but keeps it in Float if it was Float. Most of the audio filters in the core support all the formats, which implies there are codepaths for each format to be processed natively.

Quote:
How does an all high bit depth video environment work? I had imagined in a perfect world you'd open a video of any bitdepth and it'd be upsampled to the highest bitdepth possible for processing, and only converted to the original/user specified bit depth at the output stage. It's probably not that simple for AVS+ at the moment, but wouldn't the ideal be for AVS+ to upsample all video automatically to be processed with native 16 bit filters/plugins, and only require the user to permit/specify a change of bitdepth when loading a legacy 8 bit plugin, or at the final output stage?
Filtering should be done at the same bit depth as the input to actually be efficient speed-wise and quality-wise. There's some technicalities when dealing with bit depths between 8 and 16 bit and how that gets arranged in addressing; upsampling for processing and then downsampling on output is avoided to prevent rounding errors introduced later. It's just not necessary to do that filtering in the highest bitdepth first.
qyot27 is offline   Reply With Quote
Old 10th July 2017, 15:32   #3545  |  Link
Wilbert
Moderator
 
Join Date: Nov 2001
Location: Netherlands
Posts: 6,335
@qyot27, i changed the online documentation to reflect the actual behaviour.
Wilbert is offline   Reply With Quote
Old 10th July 2017, 16:36   #3546  |  Link
hello_hello
Registered User
 
Join Date: Mar 2011
Posts: 3,949
Quote:
Originally Posted by qyot27 View Post
Filtering should be done at the same bit depth as the input to actually be efficient speed-wise and quality-wise. There's some technicalities when dealing with bit depths between 8 and 16 bit and how that gets arranged in addressing; upsampling for processing and then downsampling on output is avoided to prevent rounding errors introduced later. It's just not necessary to do that filtering in the highest bitdepth first.
So for video plugins that currently use the LSB hack to support 16 bit processing with AVS, is that basically a waste of time if your input is 8 bit and the output will be the same? I thought the idea was to process with greater precision, even if the video is dithered down to 8 bit in the end.
Not the I use the 16 bit hack much, but I thought that was the main point of it.

On the audio thing.... if a filter supports both 16 bit int and float, are you still better off converting to float first, precision-wise?

Thanks.
hello_hello is offline   Reply With Quote
Old 11th July 2017, 02:38   #3547  |  Link
qyot27
...?
 
qyot27's Avatar
 
Join Date: Nov 2005
Location: Florida
Posts: 1,050
Quote:
Originally Posted by hello_hello View Post
So for video plugins that currently use the LSB hack to support 16 bit processing with AVS, is that basically a waste of time if your input is 8 bit and the output will be the same? I thought the idea was to process with greater precision, even if the video is dithered down to 8 bit in the end.
Not the I use the 16 bit hack much, but I thought that was the main point of it.
That...depends. Supersampling is generally understood more in the vein of 'resize up, filter at the higher resolution, then resize back down', but that's staying inside of the same bit depth. Running filters on high bit depth input might provide a smoother gradient scale, and you might be able to retain *some* of that when you dither back down to 8 bit and use a lossy encoder on it, but it may also be possible to get similar results without processing it in >8bit. That's why the LSB hack is typically intended to be input to programs that can stitch it back into a proper high bit depth stream, since at least then it can keep the same >8bit gradient scale.

There's also the question of how much CPU and memory all of that would eat and whether whatever benefit you do end up seeing is worth it, or whether keeping it all in the same bit depth is faster for the same general perceptual quality (and a lot of that is naturally subjective).

Quote:
On the audio thing.... if a filter supports both 16 bit int and float, are you still better off converting to float first, precision-wise?
The only thing I've ever really heard about the benefit of processing in float vs. integer is the claim that float processing prevents clipping. How true that is in practice, I don't know. Also whether you'd even need to worry about clipping, depending on what filter(s) you're using.

If there's no obvious difference in quality, whichever is faster.
If neither is distinctly faster, use what the encoder you're giving it to supports.

Regarding the encoder part, if you're dealing with something like ffmpeg, ffmpeg as a command line program is distinct from the libavcodec encoders you'd be feeding the stream to. For instance, with MP3: LAME supports multiple formats including 16-bit integer, 32-bit integer, and float, whereas libshine only supports 16-bit integer. So optimally, even though ffmpeg has no problems opening float audio (and will perform the conversion prior to handing it to the encoder), if you wanted to encode with libshine, it would be more streamlined to output 16-bit int from AviSynth, so ffmpeg wouldn't have to convert it first. But if you were going to use LAME, you could use any of the three formats it allows.

Quote:
Originally Posted by Wilbert View Post
@qyot27, i changed the online documentation to reflect the actual behaviour.
Thanks.

Last edited by qyot27; 11th July 2017 at 02:43.
qyot27 is offline   Reply With Quote
Old 11th July 2017, 08:05   #3548  |  Link
hello_hello
Registered User
 
Join Date: Mar 2011
Posts: 3,949
qyot27,
Thanks for the info.

Previously when I asked why LAME is still limited to 24 bit, I appear to have put myself in the completely wrong category.

When foobar2000 creates a LAME encoder preset itself, it sets 24 as the maximum input bit depth, and I would've bet copious amounts of money I'd tested that, but I tried setting the maximum input bitdepth to 32 (which I assume is always float for foobar2000) and had no problem encoding with LAME. I'll have to ask about it in the foobar2000 forum.
(Edit: I asked and apparently 32 bit float support was added to LAME with version 3.99)

Thanks for the info regarding high bitdepth processing of 8 bitdepth video. As processing in 16 bit is very slow using my old PC and I'd not seen much visible benefit compared to 8 bit, or realistically any benefit at all most of the time, I've not bothered filtering in 16 bit. I'd assumed "technically" it'd still be better, even if in practice it often appears not to be.

So I guess "preventing clipping" would be the only remaining argument for always converting audio to float for processing, especially when multiple filters are daisy-chained. I assume that's why foobar2000 always converts to float when a DSP is used, which seems reasonable (at least that's my understanding).
I'd be close to admitting I was wrong when it comes to the implicit vs explicit conversion of bit depth, except for the possibility of clipping avoidance. To my way of thinking if converting to float prevents it, it should be prevented, and if a filter is capable of inducing clipping, processing the audio in anything but float seems like a bad idea, and therefore accepting anything but float as the input would also be less good.
It doesn't eliminate the need for checking for clipping at the output stage, but at least you don't have to worry about it until then.

Cheers.

Last edited by hello_hello; 12th July 2017 at 07:20.
hello_hello is offline   Reply With Quote
Old 11th July 2017, 09:01   #3549  |  Link
tebasuna51
Moderator
 
tebasuna51's Avatar
 
Join Date: Feb 2005
Location: Spain
Posts: 5,563
Quote:
Originally Posted by qyot27 View Post
The only thing I've ever really heard about the benefit of processing in float vs. integer is the claim that float processing prevents clipping. How true that is in practice, I don't know.
Float values can't have clipping because support volume values over 0dB, the clip occurs when are converted to int samples and any value over 0dB are truncated.

Precission of float 32 values is equivalent (more or less) to 24 bit int because 32 float have 24 bits for mantissa (+ 8 for exponent).
Downsample to 16 bits int lose precission, and the average human ear can distinguish up to 20-bit differences.

Math operations must be do always in float format to preserve precission even with low values.
Int maths:
(3/2)x2 = 2
float maths:
(3.0/2.0)x2.0= 3.0
__________________
BeHappy, AviSynth audio transcoder, in Doom9 forums. NicAudio, BassAudio, audio decoders.

Last edited by tebasuna51; 11th July 2017 at 09:30. Reason: Add info
tebasuna51 is offline   Reply With Quote
Old 11th July 2017, 10:25   #3550  |  Link
pinterf
Registered User
 
Join Date: Jan 2014
Posts: 1,231
Quote:
Originally Posted by mkver View Post
Thanks for pointing to the source. And what's the logic that makes a 10bit LUT use the same memory as a 16bit LUT? Is it because of the "garbage" mentioned here? (Garbage means that the most significant bits aren't necessarily zero, although they should be, or?)
And because IsYUV is true for Y8-Y16, line 193 and line 203 imply that a chroma LUT is created for monochrome formats.
Yes, because of the possible garbage.
Anyway, Levels was among the first filters that was ported and the code is probably a bit messy and not finished (float support).
Nor did I benchmark that a safety check on over-10-bits garbage before applying LUT (and thus allowing smaller 10 bit LUT tables) has any significant effect on execution time. Sure, Levels is on my todo list.
pinterf is offline   Reply With Quote
Old 18th July 2017, 20:55   #3551  |  Link
wonkey_monkey
Formerly davidh*****
 
wonkey_monkey's Avatar
 
Join Date: Jan 2004
Posts: 1,787
Just out of curiousity, if this okay to ask here - as a quick straw poll, which would people prefer vis a vis Avisynth+: existing plugins updated to x64, or existing plugins updated to handle the new colourspaces?
__________________
My AviSynth filters / I'm the Doctor

Last edited by wonkey_monkey; 18th July 2017 at 21:14.
wonkey_monkey is offline   Reply With Quote
Old 18th July 2017, 23:26   #3552  |  Link
DJATOM
Registered User
 
DJATOM's Avatar
 
Join Date: Sep 2010
Location: Ukraine, Bohuslav
Posts: 164
x64 ports preferred. Although I'd like to have eedi3 with 16-bit and AVX2 support.
DJATOM is offline   Reply With Quote
Old 19th July 2017, 12:21   #3553  |  Link
burfadel
Registered User
 
Join Date: Aug 2006
Posts: 2,235
x64 ports would be a lot more useful. I guess in general, and especially looking forward, colourspace support is irrelevant if you can't use the 32-bit filter in your 64-bit script.
burfadel is offline   Reply With Quote
Old 19th July 2017, 13:54   #3554  |  Link
Reel.Deel
Registered User
 
Join Date: Mar 2012
Location: Texas
Posts: 1,108
Quote:
Originally Posted by DJATOM View Post
x64 ports preferred. Although I'd like to have eedi3 with 16-bit and AVX2 support.
Ditto, according to cretindesalpes eedi3 is 16-bit ready. This has been the case since late 2013.

Quote:
Originally Posted by cretindesalpes View Post
The SSE2 code is 16-bit ready, although the glue code to pass stack16 clips hasnít been implemented yet. It will probably come in a next update.
Reel.Deel is offline   Reply With Quote
Old 19th July 2017, 18:55   #3555  |  Link
qyot27
...?
 
qyot27's Avatar
 
Join Date: Nov 2005
Location: Florida
Posts: 1,050
At least judging by the changes made to AviSynth+ itself in order to work on 64-bit, doing so would generally make the code more portable and easier to maintain, which is always a good thing. All the new pixel formats are much more purpose-oriented, and adding them after doing the work to make the plugins 64-bit compatible would be more efficient.
qyot27 is offline   Reply With Quote
Old 22nd July 2017, 14:41   #3556  |  Link
Metal
Registered User
 
Join Date: Jun 2016
Posts: 9
Quote:
Originally Posted by pinterf View Post
New release with TemporalSoften fix.
Thanks to Sharc for the report.

Download Avisynth+ r2508-MT

Code:
20170629 r2508
  - Fix TemporalSoften: threshold < 255 (bug exists probably since r1576)
Hello

I have a problem, could you please help me solve it?
When ever I try to install any Avisynth + other than version r1576 i get this error message http://imgur.com/1xkIhGL
I tried to locate the folder, but it didn't work even when I installed r2294 I got the same error!
Metal is offline   Reply With Quote
Old 22nd July 2017, 14:48   #3557  |  Link
LigH
German doom9/Gleitz SuMo
 
LigH's Avatar
 
Join Date: Oct 2001
Location: Germany, rural Altmark
Posts: 5,882
Do you possibly mix up 64 bit DLL and 32 bit system folder? Which Windows version do you have? Which file manager do you use? (If it's anything else than Windows Explorer: A 32-bit version of a custom file manager won't have access to the 64-bit system area.) In general: More facts! More details! More quotes of error messages!

P.S.: I guess it's time to build a recent installer again. Moving DLL's manually into sensitive areas is not everyone's favourite challenge. The Avisynth Universal Installer (run "as Administrator") would be a helpful alternative; unfortunately you have to edit it correctly to maintain plugin paths, or possibly copy all your plugins around, so it's not really straightforward and easy-to-use either for people with less experience. Handling paths with spaces and even parentheses is tricky in Batch.
__________________

New German Gleitz board
MediaFire: x264 | x265 | VPx | AOM | Xvid

Last edited by LigH; 22nd July 2017 at 14:58.
LigH is offline   Reply With Quote
Old 22nd July 2017, 15:00   #3558  |  Link
Metal
Registered User
 
Join Date: Jun 2016
Posts: 9
Quote:
Originally Posted by LigH View Post
Do you possibly mix up 64 bit DLL and 32 bit system folder? Which Windows version do you have? Which file manager do you use? (If it's anything else than Windows Explorer: A 32-bit version of a custom file manager won't have access to the 64-bit system area.) In general: More facts! More details! More quotes of error messages!
No, I checked again and again I followed the instructions very well, but it didn't work!
Even with a normal installer by Groucho2004 which I got from here: http://avisynth.nl/index.php/Avisynthplus/Downloads
won't work only r1576 works.
I'm on windows server 2012 64-bit and I'm using windows explorer.
Metal is offline   Reply With Quote
Old 22nd July 2017, 15:10   #3559  |  Link
LigH
German doom9/Gleitz SuMo
 
LigH's Avatar
 
Join Date: Oct 2001
Location: Germany, rural Altmark
Posts: 5,882
Then, next steps: download and unpack AVSMeter, and check
  • AVSMeter.exe -avsinfo
  • AVSMeter64.exe -avsinfo
  • AVSMeter.exe yourscript.avs
  • AVSMeter64.exe yourscript.avs
for error messages. I guess "the specified module" which is missing may be the Microsoft Visual C++ Runtime in the required version.
__________________

New German Gleitz board
MediaFire: x264 | x265 | VPx | AOM | Xvid
LigH is offline   Reply With Quote
Old 22nd July 2017, 15:39   #3560  |  Link
Metal
Registered User
 
Join Date: Jun 2016
Posts: 9
Quote:
Originally Posted by LigH View Post
Then, next steps: download and unpack AVSMeter, and check
  • AVSMeter.exe -avsinfo
  • AVSMeter64.exe -avsinfo
  • AVSMeter.exe yourscript.avs
  • AVSMeter64.exe yourscript.avs
for error messages. I guess "the specified module" which is missing may be the Microsoft Visual C++ Runtime in the required version.
Yes!!! Finally!!!
Thank you so much LigH, I updated the Microsoft Visual C++ Runtime and it worked.
Metal 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 08:24.


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