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. Cheers
signature.asc
Description: Digital signature
_______________________________________________ libav-devel mailing list [email protected] https://lists.libav.org/mailman/listinfo/libav-devel
