On 25/05/14 15:58, Anton Khirnov wrote: > > On Sun, 25 May 2014 15:02:56 +0200, Alessandro Ghedini > <[email protected]> wrote: >> On dom, mag 25, 2014 at 02:53:59 +0200, Anton Khirnov wrote: >>> >>> On Sun, 25 May 2014 14:26:38 +0200, Alessandro Ghedini >>> <[email protected]> wrote: >>>> On Sun, May 25, 2014 at 02:10:15PM +0200, Anton Khirnov wrote: >>>>> >>>>> On Sun, 25 May 2014 13:48:59 +0200, Alessandro Ghedini >>>>> <[email protected]> wrote: >>>>>> On dom, mag 25, 2014 at 08:37:14 +0200, Anton Khirnov wrote: >>>>>>> >>>>>>> On Sat, 24 May 2014 20:40:57 +0200, Alessandro Ghedini >>>>>>> <[email protected]> wrote: >>>>>>>> On sab, mag 24, 2014 at 12:24:08 +0200, Anton Khirnov wrote: >>>>>>>>> >>>>>>>>> On Mon, 19 May 2014 11:32:58 +0200, Alessandro Ghedini >>>>>>>>> <[email protected]> wrote: >>>>>>>>>> Yup, that works!!! That only leaves the pix fmt problem now. >>>>>>>>>> >>>>>>>>> >>>>>>>>> Comparing the codes, seems like removing the >>>>>>>>> avpriv_set_systematic_pal2() is the >>>>>>>>> cause >>>>>>>> >>>>>>>> The ffmpeg code actually adds the avpriv_set_systematic_pal2() call. >>>>>>>> FWIW, >>>>>>>> removing that call doesn't seem to make much difference: instead of >>>>>>>> red-ish the >>>>>>>> image becomes black-ish, but the colors are still wrong. >>>>>>>> >>>>>>> >>>>>>> Ok, the patch i just sent to the ML should really fix that. >>>>>> >>>>>> Nope, no luck this time. The output image still looks wrong (in fact, I >>>>>> can't >>>>>> see any difference). I wonder if it's in fact a problem in lavc/gif.c >>>>>> (that is >>>>>> in the encoding of the actual frames), but TBQH I don't know much about >>>>>> libav >>>>>> internals so I'm not very useful I'm afraid. >>>>>> >>>>>> FWIW I just noticed that the gray image (-pix_fmt gray) has more or less >>>>>> the >>>>>> same problems [0]. The possibly interesting thing is that the first few >>>>>> frames >>>>>> look fine, then something happens and it becomes black (or red in the >>>>>> colored >>>>>> one), and then the "moving" pixels get back to the correct color. Dunno >>>>>> if this >>>>>> is of any use though. >>>>>> >>>>> >>>>> Did you add the avpriv_set_systematic_pal2() call back to the encoder too? >>>>> With those two changes, the output looks correct to me. >>>> >>>> Do you mean in libavformat/gif.c? If so, yes, I have: >>>> >>>> if (avpriv_set_systematic_pal2(palette, video_enc->pix_fmt) < 0) { >>>> av_assert0(video_enc->pix_fmt == AV_PIX_FMT_PAL8); >>>> gif_image_write_header(s, width, height, gif->loop, NULL); >>>> } else { >>>> gif_image_write_header(s, width, height, gif->loop, palette); >>>> } >>>> >>>> in gif_write_header(). Otherwise I don't see any other >>>> avpriv_set_systematic_pal2() calls in the diff between ffmpeg and libav. >>> >>> No, I mean in libavcodec/gif.c. ffmpeg has a call to >>> avpriv_set_systematic_pal2() there, in gif_encode_init(), which initialises >>> the >>> palette >> >> -.-" I'm a fucking idiot... why I removed that part is beyond me. > > Because you didn't like the assert perhaps? I don't like it either, so feel > free > to keep it out.
Yes, please do not add asserts to new code =) lu _______________________________________________ libav-devel mailing list [email protected] https://lists.libav.org/mailman/listinfo/libav-devel
