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. In the meantime, I have submitted another patch to address the concerns that are specific to this fix. bjorn -- Bjorn Roche Sr. Video Pipeline Engineer bj...@giphy.com _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
