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

[Tomas Härdin]

tor 2019-08-22 klockan 09:17 -0700 skrev Baptiste Coudurier:
> Hi Tomas
> 
> 
> > On Aug 22, 2019, at 3:47 AM, Tomas Härdin <tjoppen at acc.umu.se> wrote:
> > 
> > ons 2019-08-21 klockan 12:47 -0700 skrev Baptiste Coudurier:
> > > Hey guys,
> > > 
> > > 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"
> > 
> > mpeg12enc.c does this, if I read it correctly. 49999840 / 400 =
> > 124999.6 which gets rounded up to 125000.
> 
> Oh, that’s good actually.
> 
> > > 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.
> > 
> > Would writing 50000000 in mxfenc for values in the range
> > [49999840,50000000] make it pass?
> 
> If the d-10 mpeg-2 essence has the right bit_rate value, the analyzer works.
> Thinking about this, and assuming the seq header bit_rate_value is correctly set,
> Could we infer the D-10 UL after the first frame according to the mpeg-2 essence ? 
> That would guarantee correctness and eliminate the hackish bitrate check.

We could write a tentative D-10 UL and change it if any packet is off,
or maybe error out with a suggestion to pester the relevant people for
a proper CBR encoding option :]

If the output file isn't seekable (quite probable when dealing with
tape formats) then writing the header will have to be delayed until the
first packet has been inspected

We're definitely going to need something in the manual for this, since
D-10 is used in lots of places

/Tomas