Closed sindresorhus closed 2 years ago
@kornelski Do you have any idea about the cause of this? If it's really the multiple thing, we could maybe only set the maximum size when it's a multiple.
You get green when all components of YCbCr color are zero, so it's an uninitialized area or a read out of bounds.
Codecs typically internally can only have a size that is a multiple of 4/8/16 (with potentially buggy tricks used to hide this) and chroma subsampling also often adds a requirement that dimensions must be even.
So these types of bugs are easy to make in a video decoder. Entirely unsurprising that it happens when scaling.
So I suggest decoding at video's native resolution and resizing frames later in RGB(A).
If you tell the codec to resize, only require smaller sizes and prefer integer scaling factors (divide by 2 or 3)
Thanks for explaining :)
So I suggest decoding at video's native resolution and resizing frames later in RGB(A).
👍
To reproduce, take the this video and set the size to 112 in the existing Gifski version. It will produce a GIF that is has the dimensions 111x112 (incorrect dimensions) and it also has a green line on the right side:
I have confirmed that the green line happens before passing it to the gifski library.
However, if we disable
generator.maximumSize
as done in this PR, the GIF comes out with the correct dimensions and no artifacts:The GIF also comes out correct when the dimensions are 108 instead of 112, so it makes me think it has something to do with it not handling sizes well that are not multiples on the original size.