On Mon, Oct 23, 2017 at 7:17 PM, Bjorn Roche <bj...@giphy.com> wrote:
> On Sat, Oct 21, 2017 at 4:00 PM, Clément Bœsch <u...@pkh.me> wrote: > >> On Sat, Oct 21, 2017 at 09:47:47PM +0200, Carl Eugen Hoyos wrote: >> > 2017-10-21 21:43 GMT+02:00 Clément Bœsch <u...@pkh.me>: >> > > On Sat, Oct 21, 2017 at 09:37:06PM +0200, Carl Eugen Hoyos wrote: >> > >> 2017-10-21 18:40 GMT+02:00 Clément Bœsch <u...@pkh.me>: >> > >> >> > >> > Aside from these nitpicks, I'm still concerned about how it's going >> > >> > to conflict with GIF encoding where the transparent color is >> actually >> > >> > used as a mean of not updating pixels from previous frames. >> > >> >> > >> But is this really related to this patch? >> > > >> > > Maybe not, but we need to keep that in mind and not make a >> > > hasty decision wrt how we handle the transparency, because >> > > it might makes future related development much harder. >> > >> > Given that this is a libavfilter-only patch and we can reproduce >> > the issue without using libavfilter, I am not completely >> > convinced, but this is of course your decision. >> > >> >> Yes it should be fine, I just want to be sure that using >> palettegen/paletteuse will not create input streams that the limited GIF >> encoder does not handle well because it doesn't make a difference between >> "transparency flavours". If paletteuse starts inserting transparent colors >> that are not meant to be used for the frame-diff system it could become a >> problem. >> > > There is a bug in the GIF encoder. I have a fix for that issue as well. > Okay, I've submitted that as well. Still need some feedback, but I believe it's close. _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel