Closed magiblot closed 5 years ago
Thanks, chroma problem was fixed on git. And ConvertToYUY2 now gives error message when input bit depth is not 8, it was not guarded from hight bit depth input.
Thank you very much!
Yeah, I had forgotten YUY2
is only intended for a bit depth of 8.
However, other Convert functions (YV12
, YV16
, YV24
) keep the input bit depth, which is a bit confusing, considering the tables in http://avisynth.nl/index.php/Convert, although this may be the intended behaviour.
At first I thought they would downsample to output to 8 bit, but they seem to be synonims for ConvertToYUV420
, YUV422
and YUV444
, respectively.
I don't mean this should be changed, but I would find it very useful if it was a bit better explained in the Wiki page I linked (maybe it's already described in the changelog, but I haven't looked there).
Yes, I have recognized that behaviour (ConvertToYV12..24 keeping the bitdepth), but forgot about it. It is not intended, perhaps it was introduced in an early internal reorganization. Maybe I'll look at it but it is not priority.
Alright. Thanks!
By the way, I have noticed when converting from RGB to YUV that RGB->YV24->YV12
is notably faster than RGB->YV12
. Do you know why? My processor supports AVX at most.
RGB is always converted to YV24 internally before doing YV12 conversion. So there is no reason to get noticable difference. You may start a different ticket on that and I'll check it.
Okay. I'll do that.
Many conversion functions give weird results with 32-bit Y sources, most probably due to not being adapted to the new range for the U and V channels. It looks like they want to fill the U and V planes with
half_range
but they fill them with0.5
instead of0.0
.Y8 source clip:![imatge](https://user-images.githubusercontent.com/20713561/43670009-e542746e-9787-11e8-80fc-fba055f831fb.png)
In addition, converting Y to YUY2 at any bitrate other than 8 will cause a severe crash:
I'm sorry.