tis 2020-03-03 klockan 08:03 -0800 skrev Baptiste Coudurier:
> Hey Marton,
>
> > On Mar 2, 2020, at 5:18 PM, Marton Balint <c...@passwd.hu> wrote:
> >
> >
> >
> > On Mon, 2 Mar 2020, Baptiste Coudurier wrote:
> >
> > > Hey guys,
> > >
> > >
> > > > On Mar 2, 2020, at 12:57 PM, Marton Balint <c...@passwd.hu> wrote:
> > > > On Mon, 2 Mar 2020, Tomas Härdin wrote:
> > > > > fre 2020-02-28 klockan 10:30 +0100 skrev Marton Balint:
> > > > > > On Fri, 28 Feb 2020, Carl Eugen Hoyos wrote:
> > > > > > > Am Fr., 28. Feb. 2020 um 01:38 Uhr schrieb Marton Balint
> > > > > > > <c...@passwd.hu>:
> > > > > > > > Fixes ticket #8523.
> > > > > > > > > > Signed-off-by: Marton Balint <c...@passwd.hu>
> > > > > > > > ---
> > > > > > > > libavformat/mxf.c | 13 +++++++++++++
> > > > > > > > 1 file changed, 13 insertions(+)
> > > > > > > > > > diff --git a/libavformat/mxf.c b/libavformat/mxf.c
> > > > > > > > index 14056647c5..987410258a 100644
> > > > > > > > --- a/libavformat/mxf.c
> > > > > > > > +++ b/libavformat/mxf.c
> > > > > > > > @@ -135,10 +135,23 @@ static const MXFContentPackageRate
> > > > > > > > mxf_content_package_rates[] = {
> > > > > > > > { 2, { 1, 24 } },
> > > > > > > > { 3, { 1001, 24000 } },
> > > > > > > > { 4, { 1, 25 } },
> > > > > > > > + { 6, { 1, 30 } },
> > > > > > > > { 7, { 1001, 30000 } },
> > > > > > > > + { 8, { 1 , 48 } },
> > > > > > > > + { 9, { 1001, 48000 } },
> > > > > > > > { 10, { 1, 50 } },
> > > > > > > > { 12, { 1, 60 } },
> > > > > > > > { 13, { 1001, 60000 } },
> > > > > > > > + { 14, { 1, 72 } },
> > > > > > > > + { 15, { 1001, 72000 } },
> > > > > > > > + { 16, { 1, 75 } },
> > > > > > > > + { 18, { 1, 90 } },
> > > > > > > > + { 19, { 1001, 90000 } },
> > > > > > > > + { 20, { 1, 96 } },
> > > > > > > > + { 21, { 1001, 96000 } },
> > > > > > > > + { 22, { 1, 100 } },
> > > > > > > > + { 24, { 1, 120 } },
> > > > > > > > + { 25, { 1001, 120000} },
> > > > > > > > Are these still the only supported frame rates?
> > > > > > These are the *package* rates that SMPTE 326M defines
> > > > > > (technically it defines the /1.001 version of 25, 50, 75
> > > > > > and 100 fps, but those are not used).
> > > > > For the record, this is section 7.2 Content package rate in SMPTE
> > > > > 326M-
> > > > > 2000. What is not initially obvious is that mxf_content_package_rates-
> > > > > > rate is bits b5..b0. A comment about this would be nice, I don't
> > > > > > like
> > > > > magical tables in the MXF codebase not being justified by references
> > > > > :)
> > > > > You could technically have 25/1.001, 50/1.001, 75/1.001 and 100/1.001
> > > > > too. But it's probably wise not to do that.
> > > > I am not sure, maybe we should add all possible values, even if
> > > > they are uncommon. After all I found out that for example
> > > > 50/1.001 is actually supported for mkvmerge:
> > >
> > > It seems like if we were to do that, we would open the door to
> > > allowing essences that don’t support the package rate and we
> > > should definitely NOT do that.
> >
> > I am not sure I understand, there are two different things to
> > consider:
> >
> > 1) support every frame rate which can be exactly represented by a
> > package rate as defined in SMPTE 326M, even uncommon ones like
> > 50/1.001.
> >
> > 2) support all frame rates and write 0 (undefined) as the package
> > rate for frame rates which cannot be exactly represented
> >
> > You are voting against 2), right? 1) should not cause any
> > "compatibility" issues as far as I see.
>
> I’m against 1 and 2 actually. We should only explicitly support rates
> and validate that we are creating files that are compatible with
> other equipment and software that support them officially.
I'm generally of this sentiment as well. Sadly we can't test a lot of
this stuff in FATE. Ideally we'd have the output of mxfenc passed
through some popular MXF analyzers, but those are not libre and often
cost €€€
/Tomas
_______________________________________________
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".
