[FFmpeg-cvslog] r25567 - trunk/libavcodec/libx264.c

[Jason Garrett-Glaser]

On Tue, Oct 26, 2010 at 7:53 AM, Reinhard Tartler <siretart at tauware.de> wrote:
> On Di, Okt 26, 2010 at 16:40:00 (CEST), Ronald S. Bultje wrote:
>
>> Hi,
>>
>> On Tue, Oct 26, 2010 at 10:36 AM, Reinhard Tartler <siretart at tauware.de> wrote:
>>> On Di, Okt 26, 2010 at 16:32:24 (CEST), Ronald S. Bultje wrote:
>>>> On Tue, Oct 26, 2010 at 10:30 AM, Reinhard Tartler <siretart at tauware.de> wrote:
>>>>> On Di, Okt 26, 2010 at 16:24:33 (CEST), Ramiro Polla wrote:
>>>>>> On Tue, Oct 26, 2010 at 12:16 PM, Reinhard Tartler <siretart at tauware.de> wrote:
>>>>>>> On Mo, Okt 25, 2010 at 16:40:01 (CEST), cehoyos wrote:
>>>>>>>> Author: cehoyos
>>>>>>>> Date: Mon Oct 25 16:40:00 2010
>>>>>>>> New Revision: 25567
>>>>>>>>
>>>>>>>> Log:
>>>>>>>> Make libx264 take the pict_type input parameter into account,
>>>>>>>> thus making forced key frames work.
>>>>>>>>
>>>>>>>> Patch by Nicolas George, nicolas d george a normalesup d org
>>>>>>>>
>>>>>>>> Modified:
>>>>>>>> ? ?trunk/libavcodec/libx264.c
>>>>>>>>
>>>>>>>> Modified: trunk/libavcodec/libx264.c
>>>>>>>> ==============================================================================
>>>>>>>> --- trunk/libavcodec/libx264.c ? ? ? ?Mon Oct 25 08:15:21 2010 ? ? ? ?(r25566)
>>>>>>>> +++ trunk/libavcodec/libx264.c ? ? ? ?Mon Oct 25 16:40:00 2010 ? ? ? ?(r25567)
>>>>>>>> @@ -100,7 +100,11 @@ static int X264_frame(AVCodecContext *ct
>>>>>>>> ? ? ? ? ?}
>>>>>>>>
>>>>>>>> ? ? ? ? ?x4->pic.i_pts ?= frame->pts;
>>>>>>>> - ? ? ? ?x4->pic.i_type = X264_TYPE_AUTO;
>>>>>>>> + ? ? ? ?x4->pic.i_type =
>>>>>>>> + ? ? ? ? ? ?frame->pict_type == FF_I_TYPE ? X264_TYPE_KEYFRAME :
>>>>>>>> + ? ? ? ? ? ?frame->pict_type == FF_P_TYPE ? X264_TYPE_P :
>>>>>>>> + ? ? ? ? ? ?frame->pict_type == FF_B_TYPE ? X264_TYPE_B :
>>>>>>>> + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?X264_TYPE_AUTO;
>>>>>>>> ? ? ?}
>>>>>>>>
>>>>>>>> ? ? ?do {
>>>>>>>
>>>>>>> This breaks compilation with older x264:
>>>>>>>
>>>>>>> libx264.c: In function 'encode_nals':
>>>>>>> libx264.c:54:63: warning: unused parameter 'size'
>>>>>>> libx264.c: In function 'X264_frame':
>>>>>>> libx264.c:104:45: error: 'X264_TYPE_KEYFRAME' undeclared (first use in this function)
>>>>>>> libx264.c:104:45: note: each undeclared identifier is reported only once for each function it appears in
>>>>>>> make[3]: *** [libx264.o] Error 1
>>>>>>>
>>>>>>> X264_TYPE_KEYFRAME was introduced in this x264 commit:
>>>>>>>
>>>>>>> commit 40c8c4926a78a705c263e042a780d63ca24687f4
>>>>>>> Author: Lamont Alston <wewk584 at gmail.com>
>>>>>>> Date: ? Wed Jun 16 10:05:17 2010 -0700
>>>>>>>
>>>>>>> ? ?Open-GOP support
>>>>>>> ? ?Allows B-frames immediately prior to keyframes (in display order).
>>>>>>> ? ?This helps reduce keyframe popping and improve compression with short keyframe intervals.
>>>>>>> ? ?Due to a staggering display of braindamage in the Blu-ray spec, two open-GOP modes are available.
>>>>>>> ? ?The two modes calculate keyframe interval differently: one based on coded distance and one based on display distance.
>>>>>>> ? ?The latter is superior compression-wise, but for no comprehensible reason, Blu-ray requires the former if open-GOP is used.
>>>>>>>
>>>>>>> (this commit has bumped X264_BUILD from 98 -> 99)
>>>>>>>
>>>>>>> Nicolas, can you add some #ifdefs so that libx264.c can also be compiled
>>>>>>> with an older x264?
>>>>>>
>>>>>> Why not bump the libx264 requirement in configure?
>>>>>
>>>>> because there might be folks that prefer to use their 'outdated' system
>>>>> ffmpeg that comes with their distribution.
>>>>
>>>> Wouldn't these people use an outdated FFmpeg also?
>>>
>>> In these packages, I'm compiling the included copy of ffmpeg
>>> statically. x264 is not included in the mplayer source.
>>
>> Why do these people need present-day SVN of FFmpeg/MPlayer while at
>> the same time being unable to update their "outdated" system libx264?
>> It seems contradictory.
>
> it's not impossible, but it would save me time and work if this wasn't
> necessary. Is it only me that finds *unnecessary* bumping of build
> requirements rude?

I will reject any patch that introduces any hack to support old x264 versions.

We have absolutely no reason to support x264 versions older than the
date of a given ffmpeg svn checkout.  We've never done this in the
past, either.

Dark Shikari