On Sonntag, 31. Oktober 2010, Simeon Völkel wrote: > #define PIX_FMT_RGB32 PIX_FMT_NE(ARGB, BGRA) > #define PIX_FMT_RGB32_1 PIX_FMT_NE(RGBA, ABGR) > #define PIX_FMT_BGR32 PIX_FMT_NE(ABGR, RGBA) > #define PIX_FMT_BGR32_1 PIX_FMT_NE(BGRA, ARGB) > > > so at least the remark of it being destructive is wrong > > iirc the only thing this patch changed is the name: the two pixel formats > were #defined one onto the other but with libavutil 50, the one cinelerra > was using was gone. You'll have to check libavutil/pixfmt.h svn history in > ffmpeg svn if you want a 100% accurate answer there I'm afraid.
I am worried that this regresses on big-endian machines because the new name expands to a different PIX_FMT code depending on the endianness whereas the old name indicated a particular byte order. But it might just be that this actually *fixes* a problem on big-endian. Since I can't tell which it is, I'll just take the patch and see what happens. > 9 +#if X264_BUILD >= 76 > 10 + int size = nals[i].i_payload; > 11 + memcpy(codec->work_buffer + codec->buffer_size, nals[i].p_payload, > nals[i].i_payload); > 12 +#else > > > I guess you can infer the obvious answer :) Again, don't ask me to explain > more: it's been so long that I forgot. This API change in x264 was well > documented though: > http://mailman.videolan.org/pipermail/x264-devel/2009-September/006337.html > http://mailman.videolan.org/pipermail/x264-devel/2009-September/006353.html Ok, I'm clueless what this is all about. I'll trust your expertise and take the patch. Thanks. -- Hannes _______________________________________________ Cinelerra mailing list [email protected] https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
