| 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 | expand |
| Context | Check | Description |
|---|---|---|
| andriy/ffmpeg-patchwork | success | Make fate finished |
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
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
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
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".
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
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
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
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
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
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
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
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 --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} };
Fixes ticket #8523. Signed-off-by: Marton Balint <cus@passwd.hu> --- libavformat/mxf.c | 13 +++++++++++++ 1 file changed, 13 insertions(+)