IMF master file support (avisynth)

[FranceBB]

Originally Posted by Frank62

Or do something else like drinking or smoking a good cigar, what is exactly what I am going to do now.

Cheers, mate.

[kolak]

Originally Posted by FranceBB

...With the tiny minority of contents coming over as 29,970p, blending to 50p and SeparateFields() to 25i it is as that's accepted by content providers (i.e Sony etc) while linear interpolation / optical flow etc is not.

And they accept blending and are not happy with 29.97p to 50i conversion with eg. Tachyon. Interesting
Tachyon is quite good with low fps source and 29.97p is not anymore that low fps. They use masking and blended fallback for scenes which produce too many artefacts. It works quite well.

Do you have a small sample of such a blended file. I would like to see it on TV

[excellentswordfight]

Hey @FranceBB, I just downloaded the IMF package of the stem2 movie from https://theasc.com/asc/stem2 and im not sure what the best way to feed the encoder with that source, I'm not even sure how to validate that I do the conversion correctly. I thought that I could just use the ProRes version as a reference, but it looks to me that they messed up that conversion as well.

I'm starting now with the SDR version, mediainfo states YUV 4:4:4, but ffmpeg reports "rgb48le(10 bpc, bt709, progressive)" (and that does seem to be correct as it matched the info in CPL xml). And if just try FFVideoSource with avisnyth (LSMASHVideoSource cant open the file at all), info says 16 bits per component.

So first of all, what would be the best way just to get an correct conversion to yuv 4:2:0 8bit in avsinyth, just so that I can get a reference, and secondly, do you think its even worth trying to mimic the conversion in ffmpeg? Cause it would be nice just do everything there, I think that I would be able to do it in ffmpeg, but I need something that im confident is correct to compare the test results to.

[FranceBB]

Ok, it's actually pretty easy and I even automated it in FFAStrans at work.

So, first thing first, the first thing would be to get the file they want you to have using the CPL.
Given that MJPEG2000 is all intra (so each frame is encoded individually) it's possible to "remux" by reading the CPL to get the final file losslessly (and the same goes for the audio, since it's PCM, so it can be trimmed anywhere).

To do that with FFMpeg, it's gonna be as easy as:

ffmpeg.exe -f imf -i "CPL_something.xml" -map 0:0 -map 0:1 -map 0:2 -map 0:3 -map 0:4 -c:v copy -c:a copy -f mxf -y "IMF.mxf"

(I use map 'cause my stream has 1 video and 4 audio, but you can use any map you want in that regard, like if you only want the video and the first audio track you can skip the map).

From there, it's gonna be business as usual just like you would do with literally any other file as you're gonna have one normal mezzanine file derived from the CPL in .mxf.

Originally Posted by excellentswordfight

I'm starting now with the SDR version, mediainfo states YUV 4:4:4, but ffmpeg reports "rgb48le(10 bpc, bt709, progressive)" (and that does seem to be correct as it matched the info in CPL xml).

Ignore the 4:4:4 YUV info inside Mediainfo, IMF files in MJPEG2000 are almost always delivered as RGB48 in Full PC Range. Actually, someone should really tell Jerome and open an issue on the Mediainfo bugtracker.
I'll do it eventually tomorrow morning (if I forget, guys, remind me, 'cause the older and more stressed out / burned out I get, the more things I forget - and I'm still relatively young).

Originally Posted by excellentswordfight

And if just try FFVideoSource with avisnyth (LSMASHVideoSource cant open the file at all), info says 16 bits per component.

Yeah, so FFVideoSource converts anything that can't directly index inside Avisynth to 4:4:4 16bit internally. It does it for things like XYZ when it's not YUV and it does the same for RGB48.

Now, about LSMASH, it obviously cannot index it 'cause it's not an ISO standard, however if you use LWLibavVideoSource() and LWLibavAudioSource() you will be able to skip 1 step and index the CPL directly without going through an intermediate file in FFMpeg at all!
So everything stays inside Avisynth and that's my suggested "go to" method.

In other words, just do:

video=LWLibavVideoSource("CPL_something.xml")
audio=LWLibavAudioSource("CPL_something.xml")
AudioDub(video, audio)

and you'll end up with RGB48 indexed directly inside Avisynth

https://i.imgur.com/Ic3WacT.png


Now, in my case, the example is RGB48 HDR PQ BT2020 Full PC Range, however if you're starting with the RGB48 SDR BT709 Full PC Range version, going to YUV 4:2:0 8bit it's gonna be as easy as:

#Indexing
video=LWLibavVideoSource("CPL_something.xml")
audio=LWLibavAudioSource("CPL_something.xml")
AudioDub(video, audio)

#Screw frame properties
propclearall()

#Going to yv12
ConverttoYUV420(matrix="Rec.709")
ConvertBits(bits=8, dither=1)

if you have the BT2020 HDR PQ then it's slightly more complicated depending on what you wanna do:

1) Encode as BT2020 PQ 4:2:0 Type 2 10bit H.265
2) Bring it to BT2020 HLG 4:2:0 10bit and encode it
3) Bring it to BT709 SDR 4:2:0 8bit and encode it with H.264

### Encoding in PQ ###

The first option is probably the easiest one as it's gonna be as easy as:

#Indexing
video=LWLibavVideoSource("CPL_something.xml")
audio=LWLibavAudioSource("CPL_something.xml")
AudioDub(video, audio)

#Screw frame properties
propclearall()

#From RGB planar Full Range to YUV420 10bit planar Narrow Range with dithering
z_ConvertFormat(pixel_type="YUV420P10", colorspace_op="rgb:st2084:2020:full=>2020:st2084:2020:limited", resample_filter_uv="spline64", dither_type="error_diffusion")

now, the output of that will still be 4:2:0 with the MPEG-2 chroma placement, so you need to convert it to Type 2, so

ffmpeg.exe -i "AVS Script.avs" -vf scale=out_color_matrix=bt2020nc:out_h_chr_pos=0:out_v_chr_pos=0 -pix_fmt yuv420p10le -strict -1 -an -f yuv4mpegpipe - | x265.exe --y4m - --preset medium --level 5.0 --tune fastdecode --no-high-tier --ref 4 --profile main10 --bitrate 25000 --deblock -1:-1 --hdr-opt --hrd --aud --min-luma 64 --max-luma 940 --chromaloc 2 --range limited --videoformat component --colorprim bt2020 --transfer smpte2084 --colormatrix bt2020nc --master-display "G(13250,34500)B(7500,3000)R(34000,16000)WP(15635,16450)L(10000000,0.0050)" --max-cll 1000,400 --overscan show --no-open-gop --min-keyint 1 --keyint 24 --repeat-headers --rd 3 --vbv-maxrate 25000 --vbv-bufsize 25000  --wpp -o "raw_video.hevc"

mkvmerge.exe --output "raw_video.mkv" --language 0:und ^"^(^" raw_video.hevc ^"^)^"

ffmpeg.exe -i "AVS Script.avs" -map 0:1 -af loudnorm=I=-24:LRA=14:tp=-2 -c:0:1 ac3 -b:0:1 384k -ar 48000 "audio.ac3"

ffmpeg.exe -i "AVS Script.avs" -map 0:1 -af loudnorm=I=-24:LRA=14:tp=-2 -c:0:1 libtwolame -b:0:1 192k -ar 48000 "audio.mp2"


ffmpeg.exe  -i "raw_video.mkv" -i "audio.ac3" -i "audio.mp2" -map 0:0 -map 1:0 -map 2:0 -c:0:0 copy -c:1:0 copy -c:2:0 copy  -f mpegts -metadata provider_name="ABC" -metadata service_provider="ABC" -metadata service_name="ABC" -mpegts_original_network_id 0x1122 -mpegts_transport_stream_id 0x3344 -mpegts_service_id 0x5566 -mpegts_pmt_start_pid 0x1500 -mpegts_start_pid 0x150 -mpegts_service_type "digital_tv" -mpegts_flags "resend_headers" "\\VBOXSVR\Share_Windows_Linux\final.ts"

pause

where of course you can change the settings, namely --max-cll must be the same one as your content and --keyint must be equal to the framerate of your file. 23,976 = keyint 24, 25 = keyint 25, 29,970 = keyint 30, 50 = keyint 50, 59,940 and 60 = keyint 60.

This of course depends on what your target audience is and you can change anything.
In my case, my target was to create a .ts stream with AC3 audio and legacy MP2 compatibility stream.

Oh and of course, "ABC" should be replaced with the name of your company when you make the final file


### Encoding in HLG (from PQ) ###


The second option would be to convert to HLG. That can be tricky 'cause some studios DO NOT allow us to do anything we want and might wanna negotiate a specific conversion.
For instance, we have a signed agreement with some companies that want us to use a particular LUT they made according to the reference white in PQ etc.
Anyway, assuming that you're not hog-tied to a particular contract, you can either use HLG Tools by William to generate the PQ to HLG LUT for you (it can even use PQ Stats to detect the MaxCLL if they didn't provide it to you) OR you can use my LUT based on the official BBC White Paper, but beware that it will assume a reference white of 1000 nits.
There are also other ways like using avsresize.
I mean, you have plenty of ways to do it.
I'm gonna show one:

#Indexing
video=LWLibavVideoSource("CPL_something.xml")
audio=LWLibavAudioSource("CPL_something.xml")
AudioDub(video, audio)

#Screw frame properties
propclearall()

#From RGB48 Full Range to RGB Planar 16bit Full Range
z_ConvertFormat(pixel_type="RGBP16", colorspace_op="2020:st2084:2020:full=>rgb:st2084:2020:full", resample_filter_uv="spline64", dither_type="error_diffusion")

#From PQ to HLG with 16bit precision
Cube("PQ_to_HLG.cube", fullrange=true)

#From RGB 16bit planar Full Range to YUV420 10bit planar Narrow Range with dithering
z_ConvertFormat(pixel_type="YUV420P10", colorspace_op="rgb:std-b67:2020:full=>2020:std-b67:2020:limited", resample_filter_uv="spline64", dither_type="error_diffusion")

From here it's really easy 'cause we have a nice cool HLG BT2020 4:2:0 10bit planar Limited TV Range stream and we don't need to convert to Type 2 due to backwards compatibility reasons (one more advantage of the HLG transmission standard, which I love), so...

ffmpeg.exe -i "AVS Script.avs" -pix_fmt yuv420p10le -strict -1 -an -f yuv4mpegpipe - | x265.exe --y4m - --preset medium --level 5.0 --tune fastdecode --no-high-tier --ref 4 --profile main10 --bitrate 25000 --deblock -1:-1 --hdr-opt --hrd --min-luma 64 --max-luma 940 --range limited --videoformat component --colorprim bt2020 --transfer arib-std-b67 --colormatrix bt2020nc --atc-sei 18 --overscan show --no-open-gop --min-keyint 1 --keyint 24 --repeat-headers --rd 3 --vbv-maxrate 25000 --vbv-bufsize 25000  --wpp -o "raw_video.hevc"

mkvmerge.exe --output "raw_video.mkv" --language 0:und ^"^(^" raw_video.hevc ^"^)^"

ffmpeg.exe -i "AVS Script.avs" -map 0:1 -af loudnorm=I=-24:LRA=14:tp=-2 -c:0:1 ac3 -b:0:1 384k -ar 48000 "audio.ac3"

ffmpeg.exe -i "AVS Script.avs" -map 0:1 -af loudnorm=I=-24:LRA=14:tp=-2 -c:0:1 libtwolame -b:0:1 192k -ar 48000 "audio.mp2"

ffmpeg.exe  -i "raw_video.mkv" -i "audio.ac3" -i "audio.mp2" -map 0:0 -map 1:0 -map 2:0 -c:0:0 copy -c:1:0 copy -c:2:0 copy  -f mpegts -metadata provider_name="ABC" -metadata service_provider="ABC" -metadata service_name="ABC" -mpegts_original_network_id 0x1122 -mpegts_transport_stream_id 0x3344 -mpegts_service_id 0x5566 -mpegts_pmt_start_pid 0x1500 -mpegts_start_pid 0x150 -mpegts_service_type "digital_tv" -mpegts_flags "resend_headers" "\\VBOXSVR\Share_Windows_Linux\final.ts"

pause

same rule as before, keyint = framerate and "ABC" in the muxing should be changed to whatever the company you're working for is called


### Encoding in BT709 SDR (from PQ) ###

It's really unlikely that a company will ever allow you to do this without having them send samples back and forth as they wanna approve each and every thing you do 'cause there are many things that could go wrong.
(Well, I mean, not go wrong, but maybe the director doesn't agree with it as it doesn't respect his original intent/creation etc).
Anyway, assuming that they allow you to do this, you can use plenty of methods.
There's HDR Tools by JPSDR (Jean Philippe Scotto di Rinaldi) which I used in the past and I remember working with him on testing his latest implementations with 12bit DNX which was a lot of fun.
Anyway, you can also use avsresize as always or you can use one my LUTs.
Again, I'll show just one way, but feel free to use anything you like.

#Indexing
video=LWLibavVideoSource("CPL_something.xml")
audio=LWLibavAudioSource("CPL_something.xml")
AudioDub(video, audio)

#Screw frame properties
propclearall()

#From RGB48 Full Range to RGB Planar 16bit Full Range
z_ConvertFormat(pixel_type="RGBP16", colorspace_op="2020:st2084:2020:full=>rgb:st2084:2020:full", resample_filter_uv="spline64", dither_type="error_diffusion")

#From PQ to BT709 SDR with 16bit precision
Cube("PQ_to_BT709_v1.cube", fullrange=true)

#From RGB 16bit planar Full Range to YUV420 8bit planar 
z_ConvertFormat(pixel_type="YUV420", colorspace_op="rgb:709:709:full=>709:709:709:limited", resample_filter_uv="spline64", dither_type="error_diffusion", use_props=0)

#Downscale to FULL HD
SinPowResizeMT(1920, 1080)

and at this point it's all nice and dandy 'cause we have a FULL HD yv12 BT709 SDR stream, so:

x264.exe "AVS Script.avs" --x264-binary "x264.exe" --bitrate 25000  --preset medium --profile High --level 4.1 --ref 4 --keyint 24 --slices 4 --deblock -1:-1 --bluray-compat --overscan show --range tv --log-level info --thread-input --opencl --colormatrix bt709 --transfer bt709 --colorprim bt709 --videoformat component --nal-hrd vbr --vbv-maxrate 40000 --vbv-bufsize 30000 --aud --output "raw_video.h264"


ffmpeg.exe -i "AVS Script.avs" -vn -sn -af loudnorm=I=-24:LRA=14:tp=-2 -c:a dca -b:a 1536k -ar 48000 -strict -2  "audio.dts"

ffmpeg.exe -i "AVS Script.avs" -vn -sn -af loudnorm=I=-24:LRA=14:tp=-2 -c:a ac3 -b:a 384k -ac 2 -ar 48000 "audio.ac3"

"mkvmerge.exe" --output "raw_video.mkv" --language 0:und ^"^(^" raw_video.h264 ^"^)^"

ffmpeg.exe  -i "raw_video.mkv" -i audio.dts" -i "audio.ac3" -map 0:0 -map 1:0 -map 2:0 -c:v copy -c:a copy -c:a copy -metadata provider_name="ABC" -metadata service_provider="ABC" -metadata service_name="ABC" -mpegts_original_network_id 0x1122 -mpegts_transport_stream_id 0x3344 -mpegts_service_id 0x5566 -mpegts_pmt_start_pid 0x1500 -mpegts_start_pid 0x150 -mpegts_service_type "digital_tv" -mpegts_flags "resend_headers" "final.m2ts"

pause

where, as always, keyint = framerate and in the muxing step, "ABC" should be changed to whatever your company is.



I hope this clarifies your doubts and solves your issue



p.s it occurs to me that there's really a company called "ABC" in the U.S. Please note that I used "ABC" as an example of the first 3 letters of the alphabet and I DO NOT work for ABC nor have anything to do with them. I work for Sky.



Oh one last thing, we discussed about Indexing IMF with LWLibav here: https://forum.doom9.org/showthread.php?t=167435&page=71
and I was so happy to be able to do all those things in Avisynth that I brought it to the attention to the IMF User Group meeting I attended in Amsterdam: Link



To quote the relevant part of the article:

the recent addition of an IMF demuxer to the FFmpeg, Avisynth and VapourSynth open-source toolkits has significantly reduced the barrier to adopting IMF.

Long live to open source and long live to Avisynth.
I'm the second guy on the right hand side, after Andrew from the BBC.
The only "sad" thing is that Amazon didn't send our Ben Waggoner (which was somewhere else in Amsterdam) but another guy. :'(

[excellentswordfight]

Thank you FranceBB, very much appriciate the help.

Originally Posted by FranceBB

Yeah, so FFVideoSource converts anything that can't directly index inside Avisynth to 4:4:4 16bit internally. It does it for things like XYZ when it's not YUV and it does the same for RGB48.

Now, about LSMASH, it obviously cannot index it 'cause it's not an ISO standard, however if you use LWLibavVideoSource() and LWLibavAudioSource() you will be able to skip 1 step and index the CPL directly without going through an intermediate file in FFMpeg at all!

That was exatcly the info I was looking for, thank you.

#Going to yv12
ConverttoYUV420(matrix="Rec.709")
ConvertBits(bits=8, dither=1)

Yes thats pretty much what I was already trying, I guess that when you specify Rec709 its always limited range so I dont have to think about that in a separate step right?

This gives me the same results as when playing the mxf back in MPC with lavfilters (well apart from a loss in chroma res) .

if you have the BT2020 HDR PQ then it's slightly more complicated depending on what you wanna do:

1) Encode as BT2020 PQ 4:2:0 Type 2 10bit H.265

Yes, Im going for option 1, so that should be easier (i've dabbed in HDR conversions before, and I dont wanna go back in that rabbit hole again in my free time ).

#Indexing
video=LWLibavVideoSource("CPL_something.xml")
audio=LWLibavAudioSource("CPL_something.xml")
AudioDub(video, audio)

#Screw frame properties
propclearall()

#From RGB planar Full Range to YUV420 10bit planar Narrow Range with dithering
z_ConvertFormat(pixel_type="YUV420P10", colorspace_op="rgb:st2084:2020:full=>2020:st2084:2020:limited", resample_filter_uv="spline64", dither_type="error_diffusion")

Why z_ConvertFormat? Cant you just do:

ConverttoYUV420(matrix="Rec2020")
ConvertBits(bits=10, dither=1)

Its still a bit interesting that even now when when I convert it in rather controlled fassion, there is both a luminance shift and colorshift (mostly reds as usual) compared to the Prores & AVC version that they offer. But I also saw encoding errors on the prores version, so Im not sure how carefully they have treated those versions...

[FranceBB]

Originally Posted by excellentswordfight

Yes thats pretty much what I was already trying, I guess that when you specify Rec709 it's always limited range so I don't have to think about that in a separate step right?

Correct, when you go from RGB to YUV and you specify Rec709, Avisynth will convert from full range to limited tv range, so you're gonna be fine.

Originally Posted by excellentswordfight

Why z_ConvertFormat? Can't you just do:

ConverttoYUV420(matrix="Rec2020")
ConvertBits(bits=10, dither=1)

You absolutely can, it was just me being a bit pedantic in specifying manually which resizing kernel to use for chroma downscale when downscaling to 4:2:0.
Anyway, yes, you totally can use just ConverttoYUV420() with the right colormatrix and it will automatically convert from Full Range to Limited TV Range.

Originally Posted by excellentswordfight

Its still a bit interesting that even now when it seems like I can convert it correctly to yuv 420 8bit, there is both a luminance shift and colorshift (mostly reds as usual) compared to the Prores & AVC version that they offer.

Assuming that IMF is the real master from which they made the other mezzanine files, the answer is simple: they screwed up during *their* conversion to ProRes and H.264.
IMF decoding is absolutely accurate in Avisynth (so much so that we worked with Pierre Luis Lumiex from the IMF User Group on that) and I've compared it with other paid software like AVID Media Composer and Colorfront Transkoder and it was absolutely fine.

Originally Posted by excellentswordfight

But I also saw encoding errors on the prores version, so Im not sure how carefully they have treated those versions...

Sloppiness, the great disease affecting companies ever since the digital era began...

TL;DR don't worry about that, they did something wrong, probably 'cause the operator doing that didn't care (which sadly is almost always the case in most companies), we did it right

[excellentswordfight]

Originally Posted by FranceBB

Assuming that IMF is the real master from which they made the other mezzanine files, the answer is simple: they screwed up during *their* conversion to ProRes and H.264.
IMF decoding is absolutely accurate in Avisynth (so much so that we worked with Pierre Luis Lumiex from the IMF User Group on that) and I've compared it with other paid software like AVID Media Composer and Colorfront Transkoder and it was absolutely fine.

Sloppiness, the great disease affecting companies ever since the digital era began...

TL;DR don't worry about that, they did something wrong, probably 'cause the operator doing that didn't care (which sadly is almost always the case in most companies), we did it right

yeah, i suspect that you are right. Maybe ffmpeg actually handled it "automagically" with just using -pix_fmt, I discarded that directly cause I compared it to the Prores & AVC versions. Im actually gonna revisit that and compare it to the avisynth workflow. Eitherway, this at least gave me a reason to install avisynth+ for the first time, havnt been using avisynth for years.

While im at it, do you know if there is any benefit of feeding x264 with 10bit and use --input-depth 10 --output-depth 8, will it use those extra bits or just do a standard bit conversion then encode it as usual?

edit.
Yes, my original encode of just going through ffmpeg with pix_fmt does look alright (pngs exported from avspmod).

IMF source https://ibb.co/dkNhgqB

LWLibavVideoSource("StEM2_SDR_Rec709_444F_IMF_2160p24_178.mxf")
ConverttoYUV420(matrix="Rec709")
ConvertBits(bits=8, dither=1)
Spline36Resize(1920,1080)
converttorgb(matrix="Rec709")

Prores source https://ibb.co/MCFvGF7

LSMASHVideoSource("ASC_StEM2_178_UHD_24_100nits_Rec709_Stereo_ProRes422HQ.mov")
ConverttoYUV420(matrix="Rec.709")
ConvertBits(bits=8, dither=1)
Spline36Resize(1920,1080)
converttorgb(matrix="Rec709")

ffmpeg piped to x264 encode https://ibb.co/PrQky9V

ffmpeg.exe" -ss 00:00:08 -r 24000/1001 -i "StEM2_SDR_Rec709_444F_IMF_2160p24_178.mxf" -s 1920x1080 -sws_flags spline -pix_fmt yuv420p10le -an -f yuv4mpegpipe -strict -1 - | 
"x264.exe" --demuxer y4m --fps 24000/1001 --input-depth 10 --output-depth 8 --profile high --level 4.1 --preset veryslow --tune film --bluray-compat --bitrate 25000 --vbv-maxrate 40000 --vbv-bufsize 30000 
--keyint 24 --sar 1:1 --colorprim "bt709" --transfer "bt709" --colormatrix "bt709" --pass 2 --stats x264_2pass.log  --colorprim bt709 --transfer bt709 --colormatrix bt709 - -o stem2.1080p.x264.SDR.mp4"

LSMASHVideoSource("stem2.1080p.x264.mp4")
converttorgb(matrix="Rec709")

@benwaggoner you have used the dnxhd file right? Did you see the same issue there as with the prores?


And thank you for reminding me about chroma location, gonna start with the hdr10 version now:

"ffmpeg.exe" -ss 00:00:08 -r 24000/1001 -i "StEM2_HDR_Rec2020PQ_444F_IMF_2160p24_178.mxf" -vf scale=out_color_matrix=bt2020ncut_h_chr_pos=0ut_v_chr_pos=0 -pix_fmt yuv420p10le -an -f yuv4mpegpipe -strict -1 - | "x265.exe" --y4m --fps 24000/1001 --profile main10 --level-idc 51 --preset slower --uhd-bd --no-sao --deblock -1:-1 --bitrate 50000 --vbv-maxrate 98000 --vbv-bufsize 98000 --pass 2 --hdr10-opt --chromaloc 2 --range limited --colorprim bt2020 --transfer smpte2084 --colormatrix bt2020nc --master-display "G(8500,39850)B(6550,2300)R(35400,14600)WP(15635,16450)L(10000000,50)" - -o stem2.2160p.HDR10.x265.hevc

[FranceBB]

Originally Posted by excellentswordfight

While im at it, do you know if there is any benefit of feeding x264 with 10bit and use --input-depth 10 --output-depth 8, will it use those extra bits or just do a standard bit conversion then encode it as usual?

If you feed x264 with high bit depth, it will still perform dithering, however it will use Sierra-2-4A error diffusion instead of the Floyd Steinberg error diffusion that you have in Avisynth. Unless you have a good reason to use Floyd Steinberg inside Avisynth, it's better to feed x264 with the high bit depth and let it use Sierra-2-4A dithering 'cause the encoder will know where those dithered bits are and therefore will be able to encode it in a more efficient way compared to receiving an 8bit floyd-steinberg dithered down source (which isn't bitrate friendly). Now, here's the catch: unfortunately x264 only supports 16bit planar, 16bit interleaved and 8bit input, but nothing in between, therefore if you try to open an "AVS Script.avs" in 10bit planar with x264.exe it will say "unsupported bit depth". This is one of the things that annoys me most when I'm encoding professional XAVC Intra Class 300 10bit stuff with x264, 'cause if my source is 10bit and target is 10bit, I still have to go to 16bit planar and let x264 go down to 10bit.

Originally Posted by excellentswordfight

IMF source https://ibb.co/dkNhgqB
Prores source https://ibb.co/MCFvGF7
x264 encode https://ibb.co/PrQky9V

Woah.
Whoever made the ProRes didn't bother to properly convert from Full PC Range to Limited TV Range, hence the screw up.



Your x264 version looks fine.

[FranceBB]

Actually, someone should really tell Jerome and open an issue on the Mediainfo bugtracker.

Done: https://github.com/MediaArea/MediaInfo/issues/657

[FranceBB]

Well, turns out it was an FFMpeg mxf muxer fault all along, so Mediainfo was actually right in reading the info out of a faulty file...

I reported it to the FFMpeg bug tracker using the info provided by Jerome: https://trac.ffmpeg.org/ticket/10001


Summary of the bug:

When muxing a MJPEG2000 RGB Full Range stream, the mxf muxer is using the CDCI essence descriptor UL instead of the RGBA essence descriptor UL.
In other words, it's using

{ { 0x06,0x0e,0x2b,0x34,0x02,0x53,0x01,0x01,0x0d,0x01,0x01,0x01,0x01,0x01,0x28,0x00 }, mxf_read_generic_descriptor, sizeof(MXFDescriptor), Descriptor }, /* CDCI */

instead of

{ { 0x06,0x0e,0x2b,0x34,0x02,0x53,0x01,0x01,0x0d,0x01,0x01,0x01,0x01,0x01,0x29,0x00 }, mxf_read_generic_descriptor, sizeof(MXFDescriptor), Descriptor }, /* RGBA */

On top of this, the mxf muxer adds the color sampling descriptor as 4:4:4 which doesn't make sense as it's RGB, not YUV.

Last but not least, instead of writing 10bit for 10bit RGB sources and 12bit for 12bit RGB sources, it always writes 16bit, which of course is also wrong.
This results from the fact that FFMpeg is trying to the first compatible match when there is no colr atom.


I also included the steps to reproduce as the following:

1) Download the standard IMF evaluation package from here: Link

2) Create the final mxf file by reading the CPL with FFMpeg like ffmpeg.exe -f imf -i "CPL.xml" -c:v copy -c:a copy -f mxf -y "IMF.mxf"

3) Check the resulting file: it was supposed to be rgb48le 10bit BT709, however the muxed file has all the above mentioned things wrong; wrong bit depth inside the container and CDCI wrongly populated instead of RGBA, causing it to be interpreted as YUV 4:4:4 16bit by other softwares other than ffmpeg and ffprobe themselves.

[Emulgator]

Ah, good find, thanks FranceBB !

[excellentswordfight]

Originally Posted by FranceBB

I also included the steps to reproduce as the following:

1) Download the standard IMF evaluation package from here: Link

2) Create the final mxf file by reading the CPL with FFMpeg like ffmpeg.exe -f imf -i "CPL.xml" -c:v copy -c:a copy -f mxf -y "IMF.mxf"

3) Check the resulting file: it was supposed to be rgb48le 10bit BT709, however the muxed file has all the above mentioned things wrong; wrong bit depth inside the container and CDCI wrongly populated instead of RGBA, causing it to be interpreted as YUV 4:4:4 16bit by other softwares other than ffmpeg and ffprobe themselves.

Ah, you are correct, while I was working on the files I pulled out a 10s sample with ffmpeg, I was apparently checking mediainfo on that file and not the source file. The original mxf containing the video track does indeed look correct in mediainfo.