Re: [FFmpeg-devel] avformat/mxfenc: SMPTE RDD 48:2018 Amd 1:2022 (FFV1 in MXF) support
tis 2023-03-14 klockan 10:52 +0100 skrev Jerome Martinez: > On 31/01/2023 15:53, Tomas Härdin wrote: > > sön 2023-01-29 klockan 11:36 -0500 skrev Dave Rice: > > > > > > I'm just nudging on the consideration of merging this patch. I've > > > been testing it over the last week with ffv1/mxf content and have > > > found this demuxing support very helpful. > > Surely you mean muxing? > > > > Some FATE tests would be nice. > > > Apologizes for the huge delay. > Attached is an updated patch with a FATE test. Test passes. Maybe someone who knows more about FFV1 wants to chime in? /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".
Re: [FFmpeg-devel] avformat/mxfenc: SMPTE RDD 48:2018 Amd 1:2022 (FFV1 in MXF) support
On 31/01/2023 15:53, Tomas Härdin wrote: sön 2023-01-29 klockan 11:36 -0500 skrev Dave Rice: On Jan 20, 2023, at 10:17 AM, Tomas Härdin wrote: ons 2023-01-18 klockan 15:15 +0100 skrev Jerome Martinez: On 18/01/2023 14:40, Tomas Härdin wrote: Creating a new subthread because I just noticed something I am a bit lost there because the line of code below is not part of this FFV1 patch. Additionally, none on my patches (FFV1 of MXF stored/sampled/displayed fix) modifies the discussed behavior (FFmpeg behavior would be same before and after this patch for MPEG-2 and AVC), so should not block any of them, and a potential fix for that should have its own patch as it would be a separate issue. True, it doesn't need to hold up this patch. But some discussion is warranted I think. I might create a separate patchset for this. Anyway: + //Stored height mxf_write_local_tag(s, 4, 0x3202); avio_wb32(pb, stored_height>>sc->interlaced); Won't this be incorrect for files whose dimensions are multiples of 16 but not multiples of 32? Isn't each field stored separately with dimensions a multiple of 16? So while for 1080p we'll have StoredHeight = 1088 SampledHeight = 1080 and 1080i: StoredHeight = 544 SampledHeight = 540 Where 544 is a multiple of 16, for say 720p we have StoredHeight = 720 SampledHeight = 720 but for a hypothetical 720i we'd get StoredHeight = 360 SampledHeight = 360 whereas the correct values should be StoredHeight = 368 SampledHeight = 360 AFAIK, it would depend about if the stream has a picture_structure frame (16x16 applies to the frame?) of field (16x16 applies to the field?), but I really don't know enough there for having a relevant opinion. I can just say that I don't change the behavior of FFmpeg in your use case, I found the issues when I tried a random width and height of FFV1 stream then checked with MPEG-2 Video and the sampled width was wrong for sure e.g. sampled width of 1920 for a stream having a width of 1912, with current FFmpeg code, and for your use case I am sure about nothing so I don't change the behavior with my patch, IMO if there is an issue with 720i MPEG-2 Video it should be in a separate topic and patch as it would modify the "stored_height = (st->codecpar- height+15)/16*16" current code (in my patch I just move this code), unless we are sure of what should be changed on this side and apply a fix on the way. Better to fix 1 issue and let 1 open with no change than fixing no issue because we wouldn't be sure for 1 of the 2. I suspect we are lucky because 720i doesn't really exist in the real world, and 576i and 480i are both multiples of 32. IMO mxfenc shouldn't lie, but looking at S377m StoredWidth/Height are "best effort" and thus shall be encoded. Their values will depend on FrameLayout which in turn depends on what you say - how exactly the interlacing is done. TL;DR: this patchset doesn't need to be held up by this. I'm just nudging on the consideration of merging this patch. I've been testing it over the last week with ffv1/mxf content and have found this demuxing support very helpful. Surely you mean muxing? Some FATE tests would be nice. Apologizes for the huge delay. Attached is an updated patch with a FATE test. Jérôme From fec4b918dd6e6a067eaeb2cd27f5e42c08dcca2c Mon Sep 17 00:00:00 2001 From: Jerome Martinez Date: Tue, 14 Mar 2023 09:49:16 +0100 Subject: [PATCH] avformat/mxfenc: SMPTE RDD 48:2018 Amd 1:2022 support --- libavformat/Makefile | 3 +- libavformat/mxfenc.c | 163 +- libavformat/rangecoder_dec.c | 1 + tests/fate/lavf-container.mak | 2 + tests/ref/lavf/mxf_ffv1 | 3 + 5 files changed, 169 insertions(+), 3 deletions(-) create mode 100644 libavformat/rangecoder_dec.c create mode 100644 tests/ref/lavf/mxf_ffv1 diff --git a/libavformat/Makefile b/libavformat/Makefile index 47fb2a..048649689b 100644 --- a/libavformat/Makefile +++ b/libavformat/Makefile @@ -712,7 +712,8 @@ SHLIBOBJS-$(CONFIG_HLS_DEMUXER) += ac3_channel_layout_tab.o SHLIBOBJS-$(CONFIG_MATROSKA_DEMUXER) += mpeg4audio_sample_rates.o SHLIBOBJS-$(CONFIG_MOV_DEMUXER) += ac3_channel_layout_tab.o SHLIBOBJS-$(CONFIG_MP3_MUXER)+= mpegaudiotabs.o -SHLIBOBJS-$(CONFIG_MXF_MUXER)+= golomb_tab.o +SHLIBOBJS-$(CONFIG_MXF_MUXER)+= golomb_tab.o \ +rangecoder_dec.o SHLIBOBJS-$(CONFIG_NUT_MUXER)+= mpegaudiotabs.o SHLIBOBJS-$(CONFIG_RTPDEC) += jpegtables.o SHLIBOBJS-$(CONFIG_RTP_MUXER)+= golomb_tab.o jpegtables.o \ diff --git a/libavformat/mxfenc.c b/libavformat/mxfenc.c index a29d678098..0ff566fbb4 100644 --- a/libavformat/mxfenc.c +++ b/libavformat/mxfenc.c @@ -51,6 +51,7 @@ #include "libavcodec/golomb.h" #include "libavcodec/h264.h" #include "libavcodec/packet_internal.h" +#include "libavcod
Re: [FFmpeg-devel] avformat/mxfenc: SMPTE RDD 48:2018 Amd 1:2022 (FFV1 in MXF) support
sön 2023-01-29 klockan 11:36 -0500 skrev Dave Rice: > > > > On Jan 20, 2023, at 10:17 AM, Tomas Härdin wrote: > > > > ons 2023-01-18 klockan 15:15 +0100 skrev Jerome Martinez: > > > On 18/01/2023 14:40, Tomas Härdin wrote: > > > > Creating a new subthread because I just noticed something > > > > > > I am a bit lost there because the line of code below is not part > > > of > > > this > > > FFV1 patch. > > > Additionally, none on my patches (FFV1 of MXF > > > stored/sampled/displayed > > > fix) modifies the discussed behavior (FFmpeg behavior would be > > > same > > > before and after this patch for MPEG-2 and AVC), so should not > > > block > > > any > > > of them, and a potential fix for that should have its own patch > > > as it > > > would be a separate issue. > > > > True, it doesn't need to hold up this patch. But some discussion is > > warranted I think. I might create a separate patchset for this. > > > > > > > > Anyway: > > > > > > > > > > > > > > > + //Stored height > > > > > mxf_write_local_tag(s, 4, 0x3202); > > > > > avio_wb32(pb, stored_height>>sc->interlaced); > > > > > > > > > Won't this be incorrect for files whose dimensions are > > > > multiples of > > > > 16 > > > > but not multiples of 32? Isn't each field stored separately > > > > with > > > > dimensions a multiple of 16? So while for 1080p we'll have > > > > > > > > StoredHeight = 1088 > > > > SampledHeight = 1080 > > > > > > > > and 1080i: > > > > > > > > StoredHeight = 544 > > > > SampledHeight = 540 > > > > > > > > Where 544 is a multiple of 16, for say 720p we have > > > > > > > > StoredHeight = 720 > > > > SampledHeight = 720 > > > > > > > > but for a hypothetical 720i we'd get > > > > > > > > StoredHeight = 360 > > > > SampledHeight = 360 > > > > > > > > whereas the correct values should be > > > > > > > > StoredHeight = 368 > > > > SampledHeight = 360 > > > > > > AFAIK, it would depend about if the stream has a > > > picture_structure > > > frame > > > (16x16 applies to the frame?) of field (16x16 applies to the > > > field?), > > > but I really don't know enough there for having a relevant > > > opinion. > > > > > > I can just say that I don't change the behavior of FFmpeg in your > > > use > > > case, I found the issues when I tried a random width and height > > > of > > > FFV1 > > > stream then checked with MPEG-2 Video and the sampled width was > > > wrong > > > for sure e.g. sampled width of 1920 for a stream having a width > > > of > > > 1912, > > > with current FFmpeg code, and for your use case I am sure about > > > nothing > > > so I don't change the behavior with my patch, IMO if there is an > > > issue > > > with 720i MPEG-2 Video it should be in a separate topic and patch > > > as > > > it > > > would modify the "stored_height = (st->codecpar- > > > >height+15)/16*16" > > > current code (in my patch I just move this code), unless we are > > > sure > > > of > > > what should be changed on this side and apply a fix on the way. > > > Better > > > to fix 1 issue and let 1 open with no change than fixing no issue > > > because we wouldn't be sure for 1 of the 2. > > > > I suspect we are lucky because 720i doesn't really exist in the > > real > > world, and 576i and 480i are both multiples of 32. > > > > IMO mxfenc shouldn't lie, but looking at S377m StoredWidth/Height > > are > > "best effort" and thus shall be encoded. Their values will depend > > on > > FrameLayout which in turn depends on what you say - how exactly the > > interlacing is done. > > > > TL;DR: this patchset doesn't need to be held up by this. > > I'm just nudging on the consideration of merging this patch. I've > been testing it over the last week with ffv1/mxf content and have > found this demuxing support very helpful. Surely you mean muxing? Some FATE tests would be nice. /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".
Re: [FFmpeg-devel] avformat/mxfenc: SMPTE RDD 48:2018 Amd 1:2022 (FFV1 in MXF) support
> On Jan 20, 2023, at 10:17 AM, Tomas Härdin wrote: > > ons 2023-01-18 klockan 15:15 +0100 skrev Jerome Martinez: >> On 18/01/2023 14:40, Tomas Härdin wrote: >>> Creating a new subthread because I just noticed something >> >> I am a bit lost there because the line of code below is not part of >> this >> FFV1 patch. >> Additionally, none on my patches (FFV1 of MXF >> stored/sampled/displayed >> fix) modifies the discussed behavior (FFmpeg behavior would be same >> before and after this patch for MPEG-2 and AVC), so should not block >> any >> of them, and a potential fix for that should have its own patch as it >> would be a separate issue. > > True, it doesn't need to hold up this patch. But some discussion is > warranted I think. I might create a separate patchset for this. > >> >> Anyway: >> >> >>> +//Stored height mxf_write_local_tag(s, 4, 0x3202); avio_wb32(pb, stored_height>>sc->interlaced); >>> Won't this be incorrect for files whose dimensions are multiples of >>> 16 >>> but not multiples of 32? Isn't each field stored separately with >>> dimensions a multiple of 16? So while for 1080p we'll have >>> >>>StoredHeight = 1088 >>>SampledHeight = 1080 >>> >>> and 1080i: >>> >>>StoredHeight = 544 >>>SampledHeight = 540 >>> >>> Where 544 is a multiple of 16, for say 720p we have >>> >>>StoredHeight = 720 >>>SampledHeight = 720 >>> >>> but for a hypothetical 720i we'd get >>> >>>StoredHeight = 360 >>>SampledHeight = 360 >>> >>> whereas the correct values should be >>> >>>StoredHeight = 368 >>>SampledHeight = 360 >> >> AFAIK, it would depend about if the stream has a picture_structure >> frame >> (16x16 applies to the frame?) of field (16x16 applies to the field?), >> but I really don't know enough there for having a relevant opinion. >> >> I can just say that I don't change the behavior of FFmpeg in your use >> case, I found the issues when I tried a random width and height of >> FFV1 >> stream then checked with MPEG-2 Video and the sampled width was wrong >> for sure e.g. sampled width of 1920 for a stream having a width of >> 1912, >> with current FFmpeg code, and for your use case I am sure about >> nothing >> so I don't change the behavior with my patch, IMO if there is an >> issue >> with 720i MPEG-2 Video it should be in a separate topic and patch as >> it >> would modify the "stored_height = (st->codecpar->height+15)/16*16" >> current code (in my patch I just move this code), unless we are sure >> of >> what should be changed on this side and apply a fix on the way. >> Better >> to fix 1 issue and let 1 open with no change than fixing no issue >> because we wouldn't be sure for 1 of the 2. > > I suspect we are lucky because 720i doesn't really exist in the real > world, and 576i and 480i are both multiples of 32. > > IMO mxfenc shouldn't lie, but looking at S377m StoredWidth/Height are > "best effort" and thus shall be encoded. Their values will depend on > FrameLayout which in turn depends on what you say - how exactly the > interlacing is done. > > TL;DR: this patchset doesn't need to be held up by this. I'm just nudging on the consideration of merging this patch. I've been testing it over the last week with ffv1/mxf content and have found this demuxing support very helpful. Dave Rice ___ 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".
Re: [FFmpeg-devel] avformat/mxfenc: SMPTE RDD 48:2018 Amd 1:2022 (FFV1 in MXF) support
ons 2023-01-18 klockan 15:15 +0100 skrev Jerome Martinez: > On 18/01/2023 14:40, Tomas Härdin wrote: > > Creating a new subthread because I just noticed something > > I am a bit lost there because the line of code below is not part of > this > FFV1 patch. > Additionally, none on my patches (FFV1 of MXF > stored/sampled/displayed > fix) modifies the discussed behavior (FFmpeg behavior would be same > before and after this patch for MPEG-2 and AVC), so should not block > any > of them, and a potential fix for that should have its own patch as it > would be a separate issue. True, it doesn't need to hold up this patch. But some discussion is warranted I think. I might create a separate patchset for this. > > Anyway: > > > > > > > + //Stored height > > > mxf_write_local_tag(s, 4, 0x3202); > > > avio_wb32(pb, stored_height>>sc->interlaced); > > > > > Won't this be incorrect for files whose dimensions are multiples of > > 16 > > but not multiples of 32? Isn't each field stored separately with > > dimensions a multiple of 16? So while for 1080p we'll have > > > > StoredHeight = 1088 > > SampledHeight = 1080 > > > > and 1080i: > > > > StoredHeight = 544 > > SampledHeight = 540 > > > > Where 544 is a multiple of 16, for say 720p we have > > > > StoredHeight = 720 > > SampledHeight = 720 > > > > but for a hypothetical 720i we'd get > > > > StoredHeight = 360 > > SampledHeight = 360 > > > > whereas the correct values should be > > > > StoredHeight = 368 > > SampledHeight = 360 > > AFAIK, it would depend about if the stream has a picture_structure > frame > (16x16 applies to the frame?) of field (16x16 applies to the field?), > but I really don't know enough there for having a relevant opinion. > > I can just say that I don't change the behavior of FFmpeg in your use > case, I found the issues when I tried a random width and height of > FFV1 > stream then checked with MPEG-2 Video and the sampled width was wrong > for sure e.g. sampled width of 1920 for a stream having a width of > 1912, > with current FFmpeg code, and for your use case I am sure about > nothing > so I don't change the behavior with my patch, IMO if there is an > issue > with 720i MPEG-2 Video it should be in a separate topic and patch as > it > would modify the "stored_height = (st->codecpar->height+15)/16*16" > current code (in my patch I just move this code), unless we are sure > of > what should be changed on this side and apply a fix on the way. > Better > to fix 1 issue and let 1 open with no change than fixing no issue > because we wouldn't be sure for 1 of the 2. I suspect we are lucky because 720i doesn't really exist in the real world, and 576i and 480i are both multiples of 32. IMO mxfenc shouldn't lie, but looking at S377m StoredWidth/Height are "best effort" and thus shall be encoded. Their values will depend on FrameLayout which in turn depends on what you say - how exactly the interlacing is done. TL;DR: this patchset doesn't need to be held up by this. /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".
Re: [FFmpeg-devel] avformat/mxfenc: SMPTE RDD 48:2018 Amd 1:2022 (FFV1 in MXF) support
On 18/01/2023 11:12, Tomas Härdin wrote: mån 2023-01-16 klockan 15:17 +0100 skrev Jerome Martinez: [...] I think it may be relevant to keep the exact same code for the exact same purpose. Would be no more relevant if version and micro_version can be taken from FFV1Context. Perhaps we can have the ffv1 code in lavc expose a function for this? I don't really like that we have this kind of parsing inside the muxers. This goes for MPEG-2 and H.264 as well. I don't like that too but it is beyond my skills, and as this patch does not do worse that what is already implemented, with a very small overhead (less that the MPEG-2 and H.264 parts which were accepted to be merged as is), I suggest that this is not a blocker here and this part of the code could be trashed when lavc is able to expose the codec context (if it is not yet able to do so). ___ 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".
Re: [FFmpeg-devel] avformat/mxfenc: SMPTE RDD 48:2018 Amd 1:2022 (FFV1 in MXF) support
On 18/01/2023 14:40, Tomas Härdin wrote: Creating a new subthread because I just noticed something I am a bit lost there because the line of code below is not part of this FFV1 patch. Additionally, none on my patches (FFV1 of MXF stored/sampled/displayed fix) modifies the discussed behavior (FFmpeg behavior would be same before and after this patch for MPEG-2 and AVC), so should not block any of them, and a potential fix for that should have its own patch as it would be a separate issue. Anyway: +//Stored height mxf_write_local_tag(s, 4, 0x3202); avio_wb32(pb, stored_height>>sc->interlaced); Won't this be incorrect for files whose dimensions are multiples of 16 but not multiples of 32? Isn't each field stored separately with dimensions a multiple of 16? So while for 1080p we'll have StoredHeight = 1088 SampledHeight = 1080 and 1080i: StoredHeight = 544 SampledHeight = 540 Where 544 is a multiple of 16, for say 720p we have StoredHeight = 720 SampledHeight = 720 but for a hypothetical 720i we'd get StoredHeight = 360 SampledHeight = 360 whereas the correct values should be StoredHeight = 368 SampledHeight = 360 AFAIK, it would depend about if the stream has a picture_structure frame (16x16 applies to the frame?) of field (16x16 applies to the field?), but I really don't know enough there for having a relevant opinion. I can just say that I don't change the behavior of FFmpeg in your use case, I found the issues when I tried a random width and height of FFV1 stream then checked with MPEG-2 Video and the sampled width was wrong for sure e.g. sampled width of 1920 for a stream having a width of 1912, with current FFmpeg code, and for your use case I am sure about nothing so I don't change the behavior with my patch, IMO if there is an issue with 720i MPEG-2 Video it should be in a separate topic and patch as it would modify the "stored_height = (st->codecpar->height+15)/16*16" current code (in my patch I just move this code), unless we are sure of what should be changed on this side and apply a fix on the way. Better to fix 1 issue and let 1 open with no change than fixing no issue because we wouldn't be sure for 1 of the 2. Jérôme ___ 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".
Re: [FFmpeg-devel] avformat/mxfenc: SMPTE RDD 48:2018 Amd 1:2022 (FFV1 in MXF) support
Creating a new subthread because I just noticed something > +//Stored height > mxf_write_local_tag(s, 4, 0x3202); > avio_wb32(pb, stored_height>>sc->interlaced); > Won't this be incorrect for files whose dimensions are multiples of 16 but not multiples of 32? Isn't each field stored separately with dimensions a multiple of 16? So while for 1080p we'll have StoredHeight = 1088 SampledHeight = 1080 and 1080i: StoredHeight = 544 SampledHeight = 540 Where 544 is a multiple of 16, for say 720p we have StoredHeight = 720 SampledHeight = 720 but for a hypothetical 720i we'd get StoredHeight = 360 SampledHeight = 360 whereas the correct values should be StoredHeight = 368 SampledHeight = 360 ? /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".
Re: [FFmpeg-devel] avformat/mxfenc: SMPTE RDD 48:2018 Amd 1:2022 (FFV1 in MXF) support
mån 2023-01-16 klockan 15:17 +0100 skrev Jerome Martinez: > On 16/01/2023 15:00, Tomas Härdin wrote: > > > > > + ff_build_rac_states(&c, 0.05 * (1LL << 32), 256 - 8); > > (1LL << 32) / 20 ? > > Could be, I don't really care, but this line is copied from ffv1dec.c Yeah I figured as much after doing some more grepping > I > think it may be relevant to keep the exact same code for the exact > same > purpose. > Would be no more relevant if version and micro_version can be taken > from > FFV1Context. Perhaps we can have the ffv1 code in lavc expose a function for this? I don't really like that we have this kind of parsing inside the muxers. This goes for MPEG-2 and H.264 as well. /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".
Re: [FFmpeg-devel] avformat/mxfenc: SMPTE RDD 48:2018 Amd 1:2022 (FFV1 in MXF) support
On 16/01/2023 15:00, Tomas Härdin wrote: JPEG2000 will also need an RGBA descriptor filled out, might be good to prepare for that. this was the idea behind the way it is coded, so there is only a new mxf_write_jpeg2000_desc function to write, like the one for FFV1 i.e. static void mxf_write_jpeg2000_desc(AVFormatContext *s, AVStream *st) is_rgb = desc->flags & AV_PIX_FMT_FLAG_RGB; pos = mxf_write_cdci_common(s, st, is_rgb ? mxf_rgba_descriptor_key : mxf_cdci_descriptor_key); } to add. The ffv1 parsing code in this patch makes me nervous. Isn't the version available in metadata? I implemented a way similar to e.g. mxf_parse_mpeg2_frame by parsing a bit the frame. version and micro_version are available in FFV1Context so could be used but I don't know how to get FFV1Context from AVStream or other, need help there. +ff_build_rac_states(&c, 0.05 * (1LL << 32), 256 - 8); (1LL << 32) / 20 ? Could be, I don't really care, but this line is copied from ffv1dec.c, I think it may be relevant to keep the exact same code for the exact same purpose. Would be no more relevant if version and micro_version can be taken from FFV1Context. Jérôme ___ 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".
Re: [FFmpeg-devel] avformat/mxfenc: SMPTE RDD 48:2018 Amd 1:2022 (FFV1 in MXF) support
lör 2023-01-14 klockan 16:45 +0100 skrev Jerome Martinez: > The arbitrary short element codes are the ones used by another muxer > ( > files available at > https://www.digitizationguidelines.gov/guidelines/MXF_app_sampleFiles.html#2022 > > ) > > The support of RGBA descriptor is added, mainly by disabling in the > CDCI > descriptor related code the elements not in the Generic picture > descriptor, and could be in a separated dedicated patch (move of > Generic > picture descriptor code in a dedicated function?). > > Tested with: > ffmpeg -f lavfi -i testsrc=duration=10:size=ntsc:rate=ntsc - > field_order > bb -c:v ffv1 -level 0 test_ffv1_ntsc.mxf > ffmpeg -f lavfi -i testsrc=duration=10:size=pal:rate=pal -field_order > tt > -c:v ffv1 -level 3 test_ffv1_pal.mxf > ffmpeg -f lavfi -i testsrc=duration=10:size=1920x1080 -pix_fmt > yuv422p10 > -c:v ffv1 -level 3 test_ffv1_hd.mxf JPEG2000 will also need an RGBA descriptor filled out, might be good to prepare for that. The ffv1 parsing code in this patch makes me nervous. Isn't the version available in metadata? > +ff_build_rac_states(&c, 0.05 * (1LL << 32), 256 - 8); (1LL << 32) / 20 ? /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".
