Hi Tomas
> On Aug 22, 2019, at 3:47 AM, Tomas Härdin <tjop...@acc.umu.se> wrote: > > ons 2019-08-21 klockan 12:47 -0700 skrev Baptiste Coudurier: >> Hey guys, >> >> >>> On Aug 19, 2019, at 9:54 AM, Thomas Mundt <tmund...@gmail.com> wrote: >>> >>> Am Fr., 16. Aug. 2019 um 23:31 Uhr schrieb Tomas Härdin <tjop...@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 < >>>> tjop...@acc.umu.se >>>>>> : >>>>>> ons 2019-08-14 klockan 22:18 +0200 skrev Thomas Mundt: >>>>>>> >>>>>>> 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" > > 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. Thanks! — Baptiste _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
