-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello Hannes,
I've received the following answer from aballier, explaining the libavutil50 and x264 patches by gentoo. In my opinion both changes are fully justified, and _now_ as well sufficiently explained. So what is currently still pending / not merged yet (that should be included in Cin2.1.5CV)? With best regards, Simeon - -------- Original Message -------- Subject: Re: gentoo's cinelerra patches Date: Thu, 28 Oct 2010 11:00:43 -0300 From: Alexis Ballier <aball...@...> Organization: Gentoo To: Simeon Völkel <simeon.voel...@...> Hi, > we are currently working on Cin2.1.5CV and now collecting patches from > distributions to be included in the next release. However, only very few > have any explanation with them, but for the git repos we would like to > have a at least somewhat expressive commit message. > > When asking today in #gentoo-media about gentoo's patches for cinelerra > ssuominen told me to ask you for the following two patches: Glad to hear cinelerra is moving again :) I was bored of sending patches that were lost in the abysses of the cincv ml so I stopped forwarding them at some point... Anyway, about these two patches, its been so long that I don't remember but let's try. in any case, you can see the cvs log here: http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/media- video/cinelerra/files/ > > cinelerra-libavutil50.patch > > This patch seems to be quite destructive, as it replaces RGBA with RGB > color models. Is that really a proper solution or just a workaround that > does not mind loosing the alpha channel? Could you please explain this > patch? cvs log says: Fix build with libavutil 50 by not using pixel formats that have been deprecated for years. libavutil/pixfmt.h says: * PIX_FMT_RGB32 is handled in an endian-specific manner. An RGBA * color is put together as: * (A << 24) | (R << 16) | (G << 8) | B * This is stored as BGRA on little-endian CPU architectures and ARGB on * big-endian CPUs. #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. > > cinelerra-x264.patch > > What does this patch solve? 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 Regards, Alexis. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkzNvxEACgkQph/voQkhF7yzqwCbBqAWlMPkHqo8mmJ63iljdA+r u1QAnRwKjuwYmAMWR/HYf1G3SirDbmTM =Leyp -----END PGP SIGNATURE----- _______________________________________________ Cinelerra mailing list [email protected] https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
