On 26/05/14 09:52, Alessandro Ghedini wrote: > On dom, mag 25, 2014 at 03:58:20 +0200, 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. > > Ah yes, that may be it. What would be an appropriate return error code for > this > (i.e. set_systematic_pal2() fails and pix_fmt != PAL8)? I put -1 for now. >
Forwarding the error from set_systematic_pal2 might be the right thing to do or AVERROR_INVALIDDATA. lu _______________________________________________ libav-devel mailing list [email protected] https://lists.libav.org/mailman/listinfo/libav-devel
