1

I have several hundred 1080p 59.94fps 10-bit-per-channel (bpc) AVC-Intra Class 100 MXF encoded video files. I would like to extract the frames of this video file and export them to disk in a 16-bit lossless image format. I recently encountered this question: Convert video to 10 bit images

So I tried this:

ffmpeg -i "testinput.mxf" -pix_fmt rgb48 _Frames/out%05d.tiff

But ran into a rather unfortunate issue that I am not sure how to resolve. Although it technically did work, and exported all of the video frames into a 16 bpc format, the color of these frames appears washed out. Here's what I mean:

The first frame of the original video file (MXF):

enter image description here

The first frame exported with ffmpeg: enter image description here

As you can see, the color appears to be faded and doesn't perfectly match the frame in the original video. I don't know why this is, but it's a serious problem that needs a resolution ASAP. Perhaps I'm not using ffmpeg correctly, or perhaps this is a bug in ffmpeg. What do I need to do to extract the frames from this particular codec correctly? Please, help.

I have included the original MXF file here, for your own testing purposes: https://drive.google.com/open?id=1HtCmPGkIZMMMEOAVKMlLksov7QyKzqRE Here is a link to the output of running the command I specified earlier. I'm on the latest version of ffmpeg for Windows, ffmpeg version N-94150-g231d0c819f Copyright (c) 2000-2019. https://pastebin.com/8UrxJJpY

  • What you use to display video and tiff? Asking because here mpv displays it almost exact. On other hand you could use zscale filter to do colorspace conversion instead of scale filter. Do you also downscale when converting to tiff? If yes that could explain washed out colors. – Paul B. Mahol Jul 12 at 9:55
  • @PaulB.Mahol Whether in Windows Photo Viewer, VLC media player, Adobe After Effects, or Adobe Premiere Pro, the frames are noticeably different. I did not downscale anything. – jippyjoe4 Jul 12 at 23:48
  • Then I kindly recommend you to try zscale filter for pixel conversion in FFmpeg. – Paul B. Mahol Jul 13 at 7:42
-1

Try using:

ffmpeg -i "testinput.mxf" -vf scale=in_range=limited:out_range=full -pix_fmt rgba64 path/to/output/out%05d.tiff

instead.

For a reason that is slightly beyond my comprehension of color science (or maybe just something odd with ffmpeg), the output of the initial command was creating .tiff files in the "limited" (15-235) rather than "full" (0-255) RGB color range. I used the scopes in Premiere Pro and DaVinci Resolve to A-B between the first frame of the created .tiff sequence and the original .mxf and the differences became clear.

If you aren't dead set on using ffmpeg, I was also able to achieve a comparable result by importing the .mxf into a Resolve (version 15 in my case) timeline and then using the "Deliver" workspace, selecting the 16 Bit, RGB and .tiff options as the output and using either the 'Auto' or 'Full' range setting. If you go the Resolve route, you can queue up each .mxf file and just let them export until everything is complete.

There are slight variations between the ffmpeg .tiff, the Resolve .tiff and the original .mxf but to my understanding the process of converting YUV (the original .mxf) to RGB (the .tiff sequence) generally isn't mathematically perfect. The files pass the "eyeball" test, however, and should work well unless the people you are working for have really strict delivery requirements.

If you really want to go deep into it, the nice (and smart!) folks over at Doom9 forums can get you into AVISynth (which is really cool and powerful but also quite complicated) for very advanced conversions.

Hope this helps!

  • The input is full color range YUV (yuv422p10le(pc, bt709, progressive)), while command you provided forces it to interpret it like limited/tv. – Paul B. Mahol Jul 9 at 8:38
  • @PaulB.Mahol I appreciate your feedback. In theory you are absolutely correct. In practice that wasn't the case. Maybe something is odd with the header information on the original .mxf? I also tried scale=in_range=full and scale with just the out_range=full parameter (omitting in_range) and the above combination was the only one that worked correctly. Additionally, I gave a second option for accomplishing the task. Thanks! – TehOtherLebowski Jul 9 at 9:22
  • Your ffmpeg code is not a solution; the result is no different than before. It is imperative that this is done with ffmpeg for speed purposes. I still do not understand how to decode this video file properly. – jippyjoe4 Jul 12 at 6:01
  • Ok. Best of luck to you – TehOtherLebowski Jul 13 at 15:21

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.