diff mbox series

[FFmpeg-devel,4/4] avformat/mxfenc: add some missing content package rates

Message ID 20200228003750.22536-4-cus@passwd.hu
State Superseded
Headers show
Series [FFmpeg-devel,1/4] avformat/audiointerleave: disallow using a samples_per_frame array
Related show

Checks

Context Check Description
andriy/ffmpeg-patchwork pending
andriy/ffmpeg-patchwork success Applied patch
andriy/ffmpeg-patchwork success Configure finished
andriy/ffmpeg-patchwork success Make finished
andriy/ffmpeg-patchwork success Make fate finished

Commit Message

Marton Balint Feb. 28, 2020, 12:37 a.m. UTC
Fixes ticket #8523.

Signed-off-by: Marton Balint <cus@passwd.hu>
---
 libavformat/mxf.c | 13 +++++++++++++
 1 file changed, 13 insertions(+)

Comments

Carl Eugen Hoyos Feb. 28, 2020, 8:09 a.m. UTC | #1
Am Fr., 28. Feb. 2020 um 01:38 Uhr schrieb Marton Balint <cus@passwd.hu>:
>
> Fixes ticket #8523.
>
> Signed-off-by: Marton Balint <cus@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?

How do archivists store low-fps film in mxf?

Carl Eugen
Marton Balint Feb. 28, 2020, 9:30 a.m. UTC | #2
On Fri, 28 Feb 2020, Carl Eugen Hoyos wrote:

> Am Fr., 28. Feb. 2020 um 01:38 Uhr schrieb Marton Balint <cus@passwd.hu>:
>>
>> Fixes ticket #8523.
>>
>> Signed-off-by: Marton Balint <cus@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).

>
> How do archivists store low-fps film in mxf?

I don't know. One can write an undefined package rate into the file, or 
the frame rate can may be different from package rate. You can put almost 
anything into MXF, the only problem is that it will not be widely 
supported or readable.

Regards,
Marton
Tomas Härdin March 2, 2020, 5:30 p.m. UTC | #3
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 <cus@passwd.hu>:
> > > Fixes ticket #8523.
> > > 
> > > Signed-off-by: Marton Balint <cus@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.

> > How do archivists store low-fps film in mxf?
> 
> I don't know. One can write an undefined package rate into the file, or 
> the frame rate can may be different from package rate. You can put almost 
> anything into MXF, the only problem is that it will not be widely 
> supported or readable.

Like Marton says, MXF allows anything. In practice everyone uses a
small set of profiles of MXF. No one attempts to support all of MXF,
that way lies madness.

/Tomas
Marton Balint March 2, 2020, 8:57 p.m. UTC | #4
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 <cus@passwd.hu>:
>> > > Fixes ticket #8523.
>> > > 
>> > > Signed-off-by: Marton Balint <cus@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:

https://gitlab.com/mbunkus/mkvtoolnix/-/commit/1a350a9573e4f895223e7ab10f7d491440abaf62

Regards,
Marton

>
>> > How do archivists store low-fps film in mxf?
>> 
>> I don't know. One can write an undefined package rate into the file, or 
>> the frame rate can may be different from package rate. You can put almost 
>> anything into MXF, the only problem is that it will not be widely 
>> supported or readable.
>
> Like Marton says, MXF allows anything. In practice everyone uses a
> small set of profiles of MXF. No one attempts to support all of MXF,
> that way lies madness.
>
> /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-request@ffmpeg.org with subject "unsubscribe".
Baptiste Coudurier March 2, 2020, 10:01 p.m. UTC | #5
Hey guys,


> On Mar 2, 2020, at 12:57 PM, Marton Balint <cus@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 <cus@passwd.hu>:
>>> > > Fixes ticket #8523.
>>> > > > > Signed-off-by: Marton Balint <cus@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.

— 
Baptiste
Marton Balint March 3, 2020, 1:18 a.m. UTC | #6
On Mon, 2 Mar 2020, Baptiste Coudurier wrote:

> Hey guys,
>
>
>> On Mar 2, 2020, at 12:57 PM, Marton Balint <cus@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 <cus@passwd.hu>:
>>>> > > Fixes ticket #8523.
>>>> > > > > Signed-off-by: Marton Balint <cus@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.

Thanks,
Marton
Baptiste Coudurier March 3, 2020, 4:03 p.m. UTC | #7
Hey Marton,

> On Mar 2, 2020, at 5:18 PM, Marton Balint <cus@passwd.hu> wrote:
> 
> 
> 
> On Mon, 2 Mar 2020, Baptiste Coudurier wrote:
> 
>> Hey guys,
>> 
>> 
>>> On Mar 2, 2020, at 12:57 PM, Marton Balint <cus@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 <cus@passwd.hu>:
>>>>> > > Fixes ticket #8523.
>>>>> > > > > Signed-off-by: Marton Balint <cus@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.

— 
Baptiste
Tomas Härdin March 3, 2020, 6:59 p.m. UTC | #8
tis 2020-03-03 klockan 08:03 -0800 skrev Baptiste Coudurier:
> Hey Marton,
> 
> > On Mar 2, 2020, at 5:18 PM, Marton Balint <cus@passwd.hu> wrote:
> > 
> > 
> > 
> > On Mon, 2 Mar 2020, Baptiste Coudurier wrote:
> > 
> > > Hey guys,
> > > 
> > > 
> > > > On Mar 2, 2020, at 12:57 PM, Marton Balint <cus@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 <cus@passwd.hu>:
> > > > > > > > Fixes ticket #8523.
> > > > > > > > > > Signed-off-by: Marton Balint <cus@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
Carl Eugen Hoyos March 4, 2020, 10:31 a.m. UTC | #9
Am Di., 3. März 2020 um 02:18 Uhr schrieb Marton Balint <cus@passwd.hu>:

> 2) support all frame rates and write 0 (undefined) as the package rate
> for frame rates which cannot be exactly represented

Why not?

Allow me to repeat: Professional archivists recommend using mxf. How
do they store digitized content from (old) low-fps film?

Carl Eugen
Tomas Härdin March 4, 2020, 4:29 p.m. UTC | #10
ons 2020-03-04 klockan 11:31 +0100 skrev Carl Eugen Hoyos:
> Am Di., 3. März 2020 um 02:18 Uhr schrieb Marton Balint <cus@passwd.hu>:
> 
> > 2) support all frame rates and write 0 (undefined) as the package rate
> > for frame rates which cannot be exactly represented
> 
> Why not?
> 
> Allow me to repeat: Professional archivists recommend using mxf. How
> do they store digitized content from (old) low-fps film?

We can worry about that when archivists open tickets on trac.

/Tomas
Carl Eugen Hoyos March 4, 2020, 4:48 p.m. UTC | #11
Am Mi., 4. März 2020 um 17:29 Uhr schrieb Tomas Härdin <tjoppen@acc.umu.se>:
>
> ons 2020-03-04 klockan 11:31 +0100 skrev Carl Eugen Hoyos:
> > Am Di., 3. März 2020 um 02:18 Uhr schrieb Marton Balint <cus@passwd.hu>:
> >
> > > 2) support all frame rates and write 0 (undefined) as the package rate
> > > for frame rates which cannot be exactly represented
> >
> > Why not?
> >
> > Allow me to repeat: Professional archivists recommend using mxf. How
> > do they store digitized content from (old) low-fps film?
>
> We can worry about that when archivists open tickets on trac.

A ticket was actually opened asking for more frame rates (just as
a ticket was opened earlier because of a limitation in aspect ratios),
I wonder why mxf is the only (?) libavformat muxer that tells the
user which frame rates (in the past: which aspect ratios) to use.
It is very hard to believe that the reason is that mxf does not allow
other frame rates (I have to listen once a year to a presentation
explaining how versatile mxf is compared to all other multimedia
containers).

Just print a warning when you feel that the chosen framerate will
not ensure maximum compatibility.

Carl Eugen
Tomas Härdin March 7, 2020, 11:35 a.m. UTC | #12
ons 2020-03-04 klockan 17:48 +0100 skrev Carl Eugen Hoyos:
> Am Mi., 4. März 2020 um 17:29 Uhr schrieb Tomas Härdin <
> tjoppen@acc.umu.se>:
> > ons 2020-03-04 klockan 11:31 +0100 skrev Carl Eugen Hoyos:
> > > Am Di., 3. März 2020 um 02:18 Uhr schrieb Marton Balint <
> > > cus@passwd.hu>:
> > > 
> > > > 2) support all frame rates and write 0 (undefined) as the
> > > > package rate
> > > > for frame rates which cannot be exactly represented
> > > 
> > > Why not?
> > > 
> > > Allow me to repeat: Professional archivists recommend using mxf.
> > > How
> > > do they store digitized content from (old) low-fps film?
> > 
> > We can worry about that when archivists open tickets on trac.
> 
> A ticket was actually opened asking for more frame rates (just as
> a ticket was opened earlier because of a limitation in aspect
> ratios),

Which one? #8523?

> I wonder why mxf is the only (?) libavformat muxer that tells the
> user which frame rates (in the past: which aspect ratios) to use.
> It is very hard to believe that the reason is that mxf does not allow
> other frame rates (I have to listen once a year to a presentation
> explaining how versatile mxf is compared to all other multimedia
> containers).
> 
> Just print a warning when you feel that the chosen framerate will
> not ensure maximum compatibility.

If the output can be guaranteed to be correct, sure. If not then no. We
should not output files which we can't verify to be correct, especially
when it comes to MXF. The ecosystem is enough of a mess as it is. It is
pointless to output files with mxfenc that can only be consumed by
mxfdec. To be useful the output must be possible to exchange with other
MXF decoders.

/Tomas
diff mbox series

Patch

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} },
     {0}
 };