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. |
5th July 2017, 09:53 | #3521 | Link |
HeartlessS Usurer
Join Date: Dec 2009
Location: Over the rainbow
Posts: 10,980
|
OK, I accede to your wisdom [no need to look so smug about it Douglas]
You look so so smug in every single pic of you:- https://www.google.co.uk/search?q=&t...&bih=821&dpr=1
__________________
I sometimes post sober. StainlessS@MediaFire ::: AND/OR ::: StainlessS@SendSpace "Some infinities are bigger than other infinities", but how many of them are infinitely bigger ??? |
5th July 2017, 12:56 | #3522 | Link | |
Moderator
Join Date: Feb 2005
Location: Spain
Posts: 6,915
|
Quote:
SSRC, TimeStretch and SuperEQ need work internally with float samples, to accept other format need convert the input to float. Like AviSynth support 8, 16, 24 and 32 bit int need the 4 conversions in each plugin. For what don't use the already exist conversions inside AviSynth? And what do at end? 1) Reconvert the float to input precission? Lossy conversion to 8 or 16 bits? Upsample to 32 bits int? Normalize if some peaks go over 0dB? Thats need a lot of duplicated rutines in all plugins. 2) Or output the float samples? That is also a problem, the user supply a format and recover other without notice. It is not a good purist software. The user must know the change like is informed when read: "Audio is always converted to Float" The "AVS+ no conversion is performed. Accepts 16-bit or Float audio (although Float is recommended)" behavior is usseless. If audio is 8, 24 (frequently) or 32 bits int we need explicit conversion. And, what is the output format?
__________________
BeHappy, AviSynth audio transcoder. Last edited by tebasuna51; 5th July 2017 at 13:27. |
|
5th July 2017, 22:45 | #3523 | Link | ||
Registered User
Join Date: Mar 2011
Posts: 4,829
|
Quote:
Quote:
As a user I'd expect the lack of implicit conversion to mean the output will be the same as the input. Will that be the case if I use multiple plugins that accept 16 bit audio? For a 16 bit input will the audio be converted to float and back by each plug-in? Is there an argument to prevent that? ie SuperEQ(OutputConversion=false) or how does it work? I'm confused if not surprised. Personally I think a better idea would be to keep the old method and have AVS+ automatically convert the output to the same format as the input as long as ConvertAudioTo() wasn't used in a script, although even then many lossy encoders accept 32 bit float, so it'd probably still require user input to prevent an unnecessary conversion at times. Another method might be to always output the same format as the input when the audio isn't being processed, and to always output a particular format when it is..... oh..... wait a minute.... What's the worst that can result from an automatic conversion to float, which I don't think happens anyway unless the audio is being processed in some way. Sometimes having to add ConvertAudioTo() to a script? Last edited by hello_hello; 5th July 2017 at 23:24. |
||
6th July 2017, 00:22 | #3524 | Link | ||||
Excessively jovial fellow
Join Date: Jun 2004
Location: rude
Posts: 1,100
|
Quote:
Is this really that hard to understand? At the very least it should be easy to see that it's inconsistent with everything else in Avisynth. Quote:
If you pass 16-bit to SuperEQ in Avs+ I believe you will get 16-bit back. Quote:
Quote:
The problem here though isn't actually the conversion to float itself since nobody ever actually inputs anything but 16-bit int audio anyway, and upconverting that to float is relatively harmless. The problem is that it's directly opposite to what the video filters do (where nothing does implicit format conversion, for reasons that are apparently less hard to understand when it's video). There are even video filters that do temporary conversions to some special internal format for processing (see: Overlay) but even those do not come with an output conversion as a side effect. Consistency is nice, y'all. Last edited by TheFluff; 6th July 2017 at 00:27. |
||||
6th July 2017, 00:51 | #3525 | Link |
...?
Join Date: Nov 2005
Location: Florida
Posts: 1,420
|
Just to put this in perspective, as well: the change in question occurred nearly four years ago. It was one of the earliest things that got committed to the nascent fork; I can't remember if the project had even accepted the 'AviSynth+' name yet, that's how old this is. And in all that time and now-89 pages of this thread, the 'no implicit conversion' behavior has been brought up only three or four times, and this latest time is the only one that's involved a heated back-and-forth.
Why do I think there's been an obvious silence on the issue? A) After hearing the explanation for the change, users agreed that the new behavior is correct and adapted their scripts accordingly. B) They weren't doing anything that would bring them into contact with the new behavior, because they were already working with float audio. WAVSource is the most likely place to hit this issue, because FFMS2 and LSMASHSource both output whatever libavcodec's decoder for the audio format decodes to. Which in the case of AAC (and who knows what other common formats*), is single precision float, not int. So users just didn't see it, because there was nothing for SSRC to complain about. *MP3 still decoded to 16-bit integer the last time I checked, but that was a few months ago. I've not checked most of the other ones I come across more often, because I usually don't use those inside video files. |
6th July 2017, 06:07 | #3526 | Link | |||||||
Registered User
Join Date: Mar 2011
Posts: 4,829
|
Quote:
If I add ConvertAudioToFloat() to a script am I introducing a bug or changing the default behaviour?. Quote:
Quote:
It might be like resizing a standard 8 bit YV12 clip and having the resizer output 16 bit YV12 (or P016 or whatever it's called). Quote:
Quote:
Quote:
I'm a GUI kind of guy and I actually don't use Avisynth for processing audio much, but Avisynth says this is 16 bit: LoadPlugin("C:\MeGUI\tools\avisynth_plugin\NicAudio.dll") RaWavSource("D:\audio.wav") And this is 32 bit: LoadPlugin("C:\MeGUI\tools\avisynth_plugin\NicAudio.dll") NicMPG123Source("D:\audio.mp3") Quote:
It just seems logical to me. Once you move up in bitdepth, you stay there till the bitter end or as long as possible, whichever comes first. If a plugin is going to move you up in bitdepth, it doesn't seem an issue to me if it's expected behaviour, and I assume all audio filters/plugins do for AVS? Having to manually convert to float at the beginning and back to integer at the end of a script to prevent a succession of filters up-converting and down-converting doesn't seem like a better idea. I have no idea how high bitdpeth video processing works for AVS+. I've only had experience with the AVS hack, and there manually specifying bitdepth changes is unavoidable, but in a high bitdepth environment if it's upconverted once wouldn't you want to keep it that way until the final output? Last edited by hello_hello; 6th July 2017 at 06:46. |
|||||||
6th July 2017, 10:43 | #3527 | Link |
Formerly davidh*****
Join Date: Jan 2004
Posts: 2,496
|
Okay, so... is SSRC like an internalised plugin that comes with AviSynth, right? And was it Avisynth itself which was making a special case out of it by looking out for calls to SSRC and converting audio to float beforehand? Or was it in the internal version of SSRC itself which was converting audio?
|
6th July 2017, 11:51 | #3528 | Link | |
Retried Guesser
Join Date: Jun 2012
Posts: 1,373
|
Quote:
As tebasuna51 points out, SuperEQ works with float samples only, but unlike SSRC and TimeStretch, does not check the input sample type -- and crashes with non-Float input. Tested w/ r2489, r2506. So SuperEQ does not actually accept 16-bit. Not sure how my 16-bit test didn't fail before (I have a clue though) EDITYes (ssrc-convert.cpp line 56) Last edited by raffriff42; 6th July 2017 at 13:40. |
|
6th July 2017, 12:31 | #3529 | Link | ||
Moderator
Join Date: Feb 2005
Location: Spain
Posts: 6,915
|
Quote:
Quote:
The problem is with lossless decoders (FLAC, DTS-MA, TrueHD, ... or WAV input) most the times with 24 bit int samples. Even is not normal need a SSRC over these sources. I detected the behavior change (I was thinking a bug) when a user try a SSRC(48000) over a already 48000 source and MeGUI crash. At least I hope than first verify if the resample is needed before than send the format error.
__________________
BeHappy, AviSynth audio transcoder. |
||
6th July 2017, 13:01 | #3530 | Link | |
Retried Guesser
Join Date: Jun 2012
Posts: 1,373
|
Quote:
https://github.com/pinterf/AviSynthP...nvert.cpp#L175 |
|
6th July 2017, 19:58 | #3531 | Link |
Registered User
Join Date: Nov 2009
Posts: 2,405
|
I am using r2508 (32bit) with an 10-bit input file and FFMS2 2.23.1 and getting an error:
ConvertToRGB: conversion is allowed only from 8 bit colorspace Code:
source = "C:\TEMP\bug_890\clip10s.avi" LoadPlugin("D:\MEGUI\tools\ffms\ffms2.dll") V = FFVideoSource(source, fpsnum=30, fpsden=1, threads=1).Lanczos4Resize(1280, 720) A1 = FFAudioSource(source, track=1).AmplifyDB(10) #.Normalize(volume=1.0, show=false) A2 = FFAudioSource(source, track=2).Normalize(volume=1.0, show=false) commentary = MonoToStereo(A1, A1) #.AmplifyDB(1.5) audio = MixAudio(commentary, A2, 0.9, 0.1) AudioDub(V, audio) return last Another user reported a similar thing: https://sourceforge.net/p/megui/bugs/888/ Any thoughts what may causing this? |
6th July 2017, 20:06 | #3532 | Link |
Registered User
Join Date: Dec 2002
Posts: 5,565
|
Vanilla AviSynth does not support >8 bit natively so ffms2 dithers down to 8 bit automatically. Then there's no error, of course. High bitdepth was only added in ffms2 2.23.1. So if you have older version or different source filter it will probably not happen either. (VirtualDub won't add ConvertToRGB() which I think is a MeGUI "feature". But VfW support for high bitdepth YUV ... ).
Last edited by sneaker_ger; 6th July 2017 at 20:10. |
6th July 2017, 22:16 | #3533 | Link |
Retried Guesser
Join Date: Jun 2012
Posts: 1,373
|
RGB24 & RGB32 are 8bit only in AviSynthPlus. For >8bit (high bit depth) RGB processing, you normally use:
Code:
## source=YUV ConvertBits(16) ## bits=10,12,14,16,32 (always upconvert bits *before* RGB<>YUV conversion) ConvertToPlanarRGBA(matrix="Rec709") If you need >8bit interleaved, you have 16bit RGB48 and RGB64: Code:
## source=YUV ConvertBits(16) ConvertToRGB64(matrix="Rec709") Code:
ConvertBits(8, dither=0) ## (dither is optional) ConvertToRGB32 Last edited by raffriff42; 8th July 2017 at 03:38. Reason: RGB48, RGB64; add links |
7th July 2017, 23:15 | #3534 | Link |
Registered User
Join Date: Aug 2006
Location: Stockholm/Helsinki
Posts: 805
|
If we make SSRC convert to float automatically, we also need some way to show "warnings" to the user, which would say that SSRC has converted the audio. In this case with SSRC it would be safe, because either you convert or you get an error. But the user should be aware of this, because the output format might not be what you expect.
|
8th July 2017, 11:35 | #3535 | Link | |
Moderator
Join Date: Feb 2005
Location: Spain
Posts: 6,915
|
Quote:
AviSynth always downconvert float audio to 16 int at output. Unless you use (v2.57): global OPT_AllowFloatAudio=True The users than add this global variable know very well than SSRC always convert audio to float. Using MeGUI or BeHappy is not needed that global OPT_AllowFloatAudio=True because a special interface with AviSynth: AvisynthWrapper.dll But MeGUI/BeHappy always convert the output samples to the best precission suported by the encoder than go after. The users don't need care about it. ----------------------------- I can accept a diferent behaviour betwen AViSynth and Avs+ but the first improvement than audio management need is: Replace the audio property nchannels by maskchannels. In AviSynth.h instead: Code:
int audio_samples_per_second; // 0 means no audio int sample_type; // as of 2.5 __int64 num_audio_samples; // changed as of 2.5 int nchannels; // as of 2.5 Code:
int audio_samples_per_second; // 0 means no audio int sample_type; // as of 2.5 __int64 num_audio_samples; // changed as of 2.5 int maskchannels; // New Now decoders, than know maskchannels, can pass that value to AviSynth.
__________________
BeHappy, AviSynth audio transcoder. |
|
9th July 2017, 05:21 | #3536 | Link | ||
...?
Join Date: Nov 2005
Location: Florida
Posts: 1,420
|
Quote:
Code:
>cat test.avs ColorBars() >ffmpeg -i test.avs ffmpeg version r86337 git-39c8e0dd8e Copyright (c) 2000-2017 the FFmpeg developers built on May 31 2017 19:37:35 with gcc 7.1.0 (GCC) libavutil 55. 63.100 / 55. 63.100 libavcodec 57. 96.101 / 57. 96.101 libavformat 57. 72.101 / 57. 72.101 libavdevice 57. 7.100 / 57. 7.100 libavfilter 6. 90.100 / 6. 90.100 libavresample 3. 6. 0 / 3. 6. 0 libswscale 4. 7.101 / 4. 7.101 libswresample 2. 8.100 / 2. 8.100 libpostproc 54. 6.100 / 54. 6.100 Guessed Channel Layout for Input Stream #0.1 : stereo Input #0, avisynth, from 'test.avs': Duration: 01:00:00.00, start: 0.000000, bitrate: N/A Stream #0:0: Video: rawvideo (BGRA / 0x41524742), bgra, 640x480, 29.97 fps, 29.97 tbr, 29.97 tbn, 29.97 tbc Stream #0:1: Audio: pcm_f32le, 48000 Hz, stereo, flt, 3072 kb/s At least one output file must be specified Quote:
http://avisynth.nl/index.php/AviSynt...gging_Facility But it still depends on the filter/plugin emitting those warnings and other informational messages, which almost nothing does because it wasn't historically possible to do this. Last edited by qyot27; 9th July 2017 at 05:23. |
||
9th July 2017, 09:26 | #3537 | Link | |
Moderator
Join Date: Feb 2005
Location: Spain
Posts: 6,915
|
Quote:
The question here is: A automatic conversion to float is not a problem, if serving through ACM there are a downconvert to 16 int, other modern soft like MeGUI, BeHappy, ffmpeg, avs2pipemod, ... can manage float samples without lose precission downconverting the samples to initial format.
__________________
BeHappy, AviSynth audio transcoder. |
|
9th July 2017, 14:13 | #3538 | Link |
Registered User
Join Date: Nov 2009
Posts: 2,405
|
Thank you very much. MeGUI - or to be more specific the AvISynthWrapper.dll - does a
Code:
res = pstr->env->Invoke("ConvertToRGB24", AVSValue(&res, 1)); Code:
PVideoFrame f = pstr->clp->GetFrame(frm, pstr->env); if (buf && stride) { pstr->env->BitBlt((BYTE*)buf, stride, f->GetReadPtr(), f->GetPitch(), f->GetRowSize(), f->GetHeight()); } |
9th July 2017, 14:13 | #3539 | Link |
German doom9/Gleitz SuMo
Join Date: Oct 2001
Location: Germany, rural Altmark
Posts: 6,781
|
As just an AviSynth user, not a developer, I care little about whether audio gets converted to float samples implicitly for filters which need that; I just need this feature to be both reliable and well documented, and optimally with verbose and specific enough error messages if my script doesn't fulfill the requirements. As already said: I am used to be forced to adapt existing scripts upon updates in a much worse way by PHP. How bad can it get with AviSynth, knowing that you developers out there care so much about us users?
|
9th July 2017, 16:44 | #3540 | Link | ||
...?
Join Date: Nov 2005
Location: Florida
Posts: 1,420
|
Quote:
It has nothing to do at all with how AviSynth as a library behaves (or any media library behaves), and I'm certain that's why anything using direct access to AviSynth as a regular library is not subject to this and never has been. Quote:
FFmpeg is likely going to be that standard bearer now, considering the number of media software projects that utilize libavformat for their file format support, and so anything that uses libavformat potentially has access to AviSynth. FFmpeg will automatically reject any patch that introduces a downconversion like that, guaranteed. Last edited by qyot27; 9th July 2017 at 16:48. |
||
Thread Tools | Search this Thread |
Display Modes | |
|
|