Non-transparencies are 100% opaque, meaning the GIF format does not support an “alpha” in the way that some formats, like PNG, do.
Optionally, one of those colors can be transparent. In a GIF, any pixel can take on any one of 256 colors defined in a palette. To understand the issue that FFMPEG had writing transparent GIFs, you need to understand exactly how transparencies work in the GIF format, and how FFMPEG was handling it.
Why FFMPEG Doesn’t Support Transparencies For this reason, we decided to tackle the issue ourselves. Although we have other tools at our disposal, such as Gifsicle, we want to use as many of the same tools as possible, especially ones that are powerful, popular and fast like FFMPEG. Until recently, however, FFMPEG did not properly support writing GIFs that are animated and have transparent pixels. At GIPHY, we use FFMPEG to process all uploaded content – including GIFs and Stickers.įFMPEG is fast, high quality, and open source. One of those tools is FFMPEG, an extremely popular package for working with video in a wide variety of formats. The distinction exists in our engineering toolchain as well – some tools struggle to correctly support Stickers (usually due to transparency). However, we still use the GIF format to store stickers – all they really are is GIFs with transparent pixels. Here at GIPHY, we differentiate between GIFs and Stickers in our business language, as the two products are served to different searches and customers. This example will just scale to 1630x1080: ffmpeg -framerate 30 -start_number 0529 -i DSC_%04d.JPG -r 30 -filter:v "scale=w=1630:h=1080:eval=init:interl=false:in_range=pc:out_range=tv,format=yuv420p,setsar=1631/1630" out.A sticker (left) is just a GIF (right) with transparent pixels. There are multiple ways to remedy this:Ĭropping by one pixel either left or right Nowadays, FFmpeg uses the non- j formats for both limited- and full-range, which works just fine, as long as the range-flag is set correctly.īut you are right, while 1631x1080 is a totally valid resolution for YUV 4:4:4-images, it should be avoided when using YUV 4:2:0, as every 2x2 grid of luma samples shares a single pair of chroma samples. FFmpeg used to differentiate between yuv444p (planar limited-range 8-bit YUV 4:4:4) and yuvj444p (planar full-range 8-bit YUV 4:4:4), same thing applies for other YUV formats. This warning (it's just a warning, not an error) is about the yuvj444p pixel format used by the mjpeg decoder.
0 kommentar(er)
