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

[Baptiste Coudurier]

Hey guys,


> On Aug 19, 2019, at 9:54 AM, Thomas Mundt <tmundt75 at gmail.com> wrote:
> 
> Am Fr., 16. Aug. 2019 um 23:31 Uhr schrieb Tomas Härdin <tjoppen at acc.umu.se
>> :
> 
>> 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.
>> 

Yeah, it’s been an issue for quite some time, s356m mentions:
"When used as a signal source for the type D-10 recording format, the bit stream is carried by SDTI-CP, as defined in SMPTE 326M, using recommended operating point bit rates as defined in this annex. Other bit rates may be used. However, users are cautioned that other system design parameters within the studio may not support all bit rates.

Table A.1 indicates recommended operating points to simplify studio operations and to provide users with a tool to be used in designing systems."

Then specifies the exact value of the sequence_header bit_rate_value, 50mit/s being “1E848h”, "To be used when compliant with EBU D84 and D85"

I don’t think it is a good idea to produce files with the wrong bit_rate value, and I know for a fact that many file analyzers in use today will simply reject the d-10 essence.
The current code is simply a hack, and IMHO the right solution is to put an option to force the ratecontrol to behave as people want for NTSC D-10. I’ve submitted a patch for that but Michael wanted it as an option.

— 
Baptiste