[FFmpeg-devel] [PATCH] libavformat/mxfenc: Allow more bitrates for NTSC IMX50

[James Almer]

On 8/16/2019 7:32 PM, Tomas Härdin wrote:
> fre 2019-08-16 klockan 19:26 -0300 skrev James Almer:
>> On 8/16/2019 6:31 PM, Tomas Härdin wrote:
>>> tor 2019-08-15 klockan 13:55 +0200 skrev Thomas Mundt:
>>>> Am Do., 15. Aug. 2019 um 11:01 Uhr schrieb Tomas Härdin <tjoppen at acc.umu.se
>>>>> :
>>>>> ons 2019-08-14 klockan 22:18 +0200 skrev Thomas Mundt:
>>>>>> Hi Tomas,
>>>>>>
>>>>>> Am Mi., 14. Aug. 2019 um 12:42 Uhr schrieb Tomas Härdin <
>>>>> tjoppen at acc.umu.se
>>>>>>> :
>>>>>>> tis 2019-08-13 klockan 22:03 +0200 skrev Thomas Mundt:
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> attached patch fixes ticket #8077.
>>>>>>>> Please comment.
>>>>>>>
>>>>>>> Probably OK, bitrates lower than 50000000 are fine in D-10 according to
>>>>>>> S356m.
>>>>>>>
>>>>>>>> } else if ((sc->video_bit_rate >= 49999840) && (sc->video_bit_rate <=
>>>>>>>> 50000000) && (mxf->time_base.den != 25)) {
>>>>>>>
>>>>>>> You could drop the extra parentheses, else it should be fine.
>>>>>>>
>>>>>>
>>>>>> New patch attached.
>>>>>
>>>>> Looks OK. I'll push in a few days if no one else has any comments
>>>>>
>>>>
>>>> Thanks. Would you mind porting it to branches 4.1 and 4.2?
>>>
>>> I'm not quite sure what the process is for that. I have confirmed that
>>> the problem exists in 4.1 and 4.2 and that your patch fixes it.
>>>
>>> I think we also might want to put a note somewhere in the documentation
>>> how to make NTSC IMX50 files.
>>>
>>> /Tomas
>>
>> Use git cherry-pick -x $hash while in the 4.1 and 4.2 branches.
>> If there are no conflicts, it will be applied and committed without
>> extra work. If there are conflicts, it will ask you to solve them and
>> then manually commit the changes.
>>
>> There shouldn't be any conflicts with 4.2 since that branch was cut a
>> few weeks ago, but i can't say with 4.1 since there were several changes
>> since 4.1 was cut.
> 
> It applies fine to both 4.1 and 4.2, and master of course. I'm more
> thinking in terms of what goes in the changelog, documentation and so
> on. Judging by "11.1 Criteria for Point Releases" fixing a regression
> like this is certainly OK, and documentation about it as well.
> 
> It's getting late, I'll think about this tomorrow.
> 
> /Tomas

Michael updates Changelog to list every backported patch at the time of
a point release, but nothing stops you from pushing a second commit to
the branches adding the line yourself if you want.