Trying to figure out the right FFMPEG ingestion workflow

Arts & Media Visual Arts & Design
1

Hi all,

I’ve started working on a new project, streamlining video ingestion/editing workflow of a small team (3 editors, 7 people involved in production total)

We’re shooting on an A6300 and a A7s II and editing on DaVinci Resolve on Linux (except one Windows laptop, but that’s only a mobile setup)

I’ve got my workstation set up to ingest and transcode the videos to ProRes at the moment, script pasted below, but I’m looking for advice from people who are experienced.

Additionally, I’m noticing something extremely interesting here. The A6300 is producing MP4 (XAVC, according to the camera) files that are, for example, 950MB, but once I convert them to FFMPEG, the 950MB file is 13.2GB. I know that, ProRes is not compressed, and that it’s a much higher quality format, but I’m not sure if the file size is worth it. We’ve only got ~160TB of space on the NAS at the moment, so obviously those ProRes files will fill it up quickly.

I’m looking for some advice to strike a medium between the XAVC and the ProRes format, mostly trying to not lose any quality.

I’m sure you’re typing “why not just use the MP4” right now, but DaVinci Resolve on Linux doesn’t support the files. In case anyone wants to see exactly what formats the camera spits out, Here’s a sample video file: linkity

I’m sure the next question is: Why not pay for Windows? Part of our organization’s mission is to prove that production is doable on Linux. We originally set out to prove it was capable on full FOSS, but we found quickly that kdenlive and others weren’t doing it for us. We’re pretty happy with DaVinci Resolve, but I’m concerned we’re going to run out of space too quickly. :confused: We seem to be creating ~150GB of good-take XAVC videos per week.

Lastly, I’m not married to any codec in particular, but I need a solution that works with Resolve 15 on Linux.

For reference: Resolve 15 Supported Codecs List

Script that’s called for ingestion and conversion:

for file in *.MP4 ; do
        echo converting: $file
        ffmpeg -i "$file" -c:v prores -profile:v 2 -c:a pcm_s16le -ar 48000 -ac 2 "$OUTPUT_DIR/$file.mov"
done

I’m very green here, so I’m humbly seeking advice. I don’t even know if I’m going about this correctly.

Tagging @FurryJackman since I seem to recall you either being familiar or this being your industry.

2

DNxHD is better for processing using FFmpeg. There are special parameters for enabling DNxHR for 4K, and you have to choose very specific bitrates, but it spits out MOV files compatible with Premiere and Resolve.

-c:a should be pcm_s24be for better compatibility with NLEs since MOV wrappers like Big Endian audio when they’re typically recorded from something like a Atomos Shogun or Ninja.

Here’s a printout of the options for the DNxHD encoder:

Encoder dnxhd [VC3/DNxHD]:
General capabilities: threads 
Threading capabilities: frame and slice
Supported pixel formats: yuv422p yuv422p10le yuv444p10le gbrp10le
  dnxhd AVOptions:
    -nitris_compat     <boolean>    E..V..... encode with Avid Nitris compatibility (default false)
    -ibias             <int>        E..V..... intra quant bias (from INT_MIN to INT_MAX) (default 0)
    -profile           <int>        E..V..... (from 0 to 5) (default dnxhd)
        dnxhd                        E..V.....
        dnxhr_444                    E..V.....
        dnxhr_hqx                    E..V.....
        dnxhr_hq                     E..V.....
        dnxhr_sq                     E..V.....
        dnxhr_lb                     E..V.....

The reason I say DNxHD is because the FFmpeg ProRes implementation was reverse engineered and is nowhere near QC passing quality for broadcast media.

The HQ presets are the only ones to support 10bit, everything else is 8bit, so that’s a disadvantage over ProRes, but DNxHD is properly built off of SMPTE papers for the standard, vs ProRes being Apple Proprietary.

1 Like
3

Oh, I forgot to mention that I can’t use DNxHD because we’re on AMD and there’s something with AMD CPUs and DNxHD that causes resolve to crash as soon as it tries to process it.

That’s interesting and disappointing. :frowning:

So, all that to say, I don’t think DNxHD/DNxHR is an option. (it was my first pick)

Is there another option?

Awesome! This is the exact type of advice thing I’m looking for!

EDIT: Nevermind, I missed a software update, it seems. (only by a few days, in fact!) As of Jan 24, they are claiming to have DNxHD support on Linux systems!

I’m testing it now.

4

It should work… DNxHD is part of FFmpeg’s libavformat. Resolve uses some things from FFmpeg for the Linux version.

5

It was a known issue, and they fixed it in the release that came out on the 24th. I’ve just confirmed that the problem is no longer happening on my system.

Basically, what happens is as soon as Resolve tries to work with a DNxHD file, it segfaultd and crashes. I can’t tell you why, since I haven’t run gdb on it, but it just wasn’t happy. Worked fine on my Intel laptop, (with the same os ssd swapped over, so I am fairly certain it wasn’t a config problem) and other people on the Blackmagic forums have confirmed it was an known issue that was Ryzen specific.

I’ve adopted your recommendations into the ingestion pipeline and I’ll be ingesting a bunch of footage on Tuesday, probably. I’ll let you know how it turns out.

Thanks for the help and advice!

6

Just keep in mind it’s VERY particular about accepted resolutions and bitrates if you try to specify specific ones. It will take some trial and error to get a useful error to print and show you the restrictions.

1 Like
7

Thanks. I’ll have to play around with it and see. I’ll try to document what I find.

8

Random musing that will probably make me look silly :stuck_out_tongue:

If the mp4 a issue a container or ‘codec’ issue?

If it’s just a contained issue cant you just use ffmpeg to do a stream copy into a different one? mov etc

9

MP4 is a container issue. MP4 natively cannot contain PCM uncompressed audio and Sony modified the standard to accept it in terms of XDCAM EX and XAVC.

However, the Linux issue is because the Linux version currently doesn’t support the XAVC-S codec.

Since the maximum the A6300 supports is 4K at 24fps or 30fps, DNxHR SQ should work.

I recently crafted a FFmpeg recipe for the iPhone HEVC 4K60 format that can be adapted for this use too:

iPhone 4K60 HEVC:

ffmpeg -guess_layout_max 0 -i (input).MOV -r 60 -pix_fmt yuv422p -c:v dnxhd -profile:v dnxhr_sq -c:a pcm_s24be -ar 48000 (output).MOV

XAVC-S 24fps:

ffmpeg -guess_layout_max 0 -i (input).MP4 -r 23.976 -pix_fmt yuv422p -c:v dnxhd -profile:v dnxhr_sq -c:a pcm_s24be -ar 48000 (output).MOV

XAVC-S 30fps:

ffmpeg -guess_layout_max 0 -i (input).MP4 -r 29.97 -pix_fmt yuv422p -c:v dnxhd -profile:v dnxhr_sq -c:a pcm_s24be -ar 48000 (output).MOV
10

in my experience supporting network head-ends, preferring open source but co-existing with commercial software customers, ffv1 codec was my goto gateway codec to minimizing the impact of archival system disparities among the aging video inventories as a first hop.

preserving audio synchronization over the years through trial and error has been a changing landscape, there are no hard and fast rules I have been able to glean during the co-evolution of the primary tools GPAC and ffmpeg except for one: “when in doubt, test NUT format”, as a first hop to avoid derailing sync.

I am interested in learning more about other home-grown ingestion systems in the wild, and have been searching for project collaboration opportunities; i have created a demo, https://github.com/jnorthrup/ffblockly to capitalize on ffmpeg’s self-doc database access.

no intent to derail your thread. back on the topic, ffv1 ± nut may give you a lossless codec jumping off point to source the end format pipeline goals from.

11

I fully agree FFV1 is a good archive format, but in terms of intermediate codecs for editing, DNxHR is still better for what he’s trying to do.

12

Yeah, I’m still happy with dnxhr_sq.

It’s a cool project though, @James_Northrup.