Proxy Workflow - Building the best ingest preset for 4-channel sources

[Premiopolis]

Our situation: We've got a mix of UDH 4k file formats

  - mp4 files with 2 channels of audio

  - mxf files with 4 channels of audio

The existing PPro/AME ingest presets generate files that seem needlessly large.

Using the smallest existing ProRes (Proxy) @ 1270x720 created files that were 14x larger than an equivalent h.264 file.

Custom-created Ingest Presets doing ProRes at 640x360 and even 160x90 were still many times larger.

ProRes being what it is, there's no changing the bit rate / resolution

For our 2-channel originals, we can generate h.264 proxies and assign those as our proxies.  The results are fantastic: very small files, very good picture quality.

But for our 4-channel originals we haven't yet figured out an optimal solution.

What I would like to do is generate h.264 picture, with matching audio track assigns, wrapped in either MXF or QuickTime.

So far I can't figure out how to do that with PPro/AME

[johansebamuel]

So far the answer seems to be to use Handbrake, Edit Ready, or Resolve as none of these have this limitation on MP4s that Premiere has.

[R Neil Haugen]

So for proxies your main goal is the smallest file size rather than smoothest playback.... is that correct?

Neil

[Premiopolis · Accepted solution]

johansebamuel 

So far the answer seems to be to use Handbrake, Edit Ready, or Resolve as none of these have this limitation on MP4s that Premiere has.

https://forums.adobe.com/people/R+Neil+Haugen  wrote

So for proxies your main goal is the smallest file size rather than smoothest playback.... is that correct?

Neil

I ended going with ffmpeg and ExtendScript workflow.

1 - ffmpeg:

The key using ffmpeg was finding the here was the right option, in this case "-map 0" which tells the conversion to track source tracks to matching destinations.  Example CLI:

ffmpeg -i /path/to/source -map 0 -g 48 -c:v libx264 -profile:v baseline -crf 16 -c:a aac -b:a 256k -vf scale=1280:720 -pix_fmt yuv420p /path/to/dest.mp4

2 - ExtendScript:

Connects the project item master clips to the generated proxies.  In this way you can

- Batch generate all the proxies using a codec, naming convention, and folder hierarchy of your choice (currently PPro/AME limit the codec, naming convention, and target destinations to a couple of choices)

- Batch connect the generated proxies to their respective master clip (projectItems) (currently PPro's batch connect for Proxies is limited)

- Re-do or make multiple versions all the proxies at a different resolutions using codecs, and auto switch.

     (thanks to bruce bullis​ and team as always for transforming the possibilities in post)

R Neil Haugen

Not necessarily looking for the smallest the file size, but the savings with h.264/mp4 have been on the order of 75x that of the default PPro proxy options -- huge savings -- and the quality and performance do not seem to have suffered, in spite of the the (I would expect) valid argument that h264 burdens the CPU with decompression overhead.  So far that hasn't the case.

Question: Is there a preferred codec / compression you would suggest?

[Trevor_Asq]

Premiopolis  wrote

1 - ffmpeg:

The key using ffmpeg was finding the here was the right option, in this case "-map 0" which tells the conversion to track source tracks to matching destinations.

Are your FFMPEG AAC resultant files in correct track order when used in PP? - see https://adobe-video.uservoice.com/forums/911233-premiere-pro/suggestions/35569411-bug-aac-multitrack...

BUG: AAC multitrack audio incorrect track order – Adobe video & audio apps

I'm getting the following mapping in PPro for a 6 channel H264/AAC 'pass through' via EditReady (it is correct in Resolve & Avid)

A1 A3

A2 A1

A3 A2

A4 A5

A5 A6

A6 A4

[Premiopolis]

So that's an interesting question.

I'm good up to 4 tracks between ffmpeg and PPro. The mapping is fine.

But above 4 tracks I don't have an answer yet. Things get dodgy. It looks like PPro stubbornly interprets 5+ tracks as a surround sound.

[R Neil Haugen]

I do prefer the Cineform as that format only uses the bits it needs for any one frame, and as an intraframe playe smoothly.

But if you're getting good playback with a small H.264, that's great.

Neil

[excited_Genie16B8]

The existing PPro/AME ingest presets generate files that seem needlessly large.

Actually, that size is needed to make the files easy to play.  It's the very high compression (small size) of the originals that requires the proxies to begin with.

[Premiopolis]

Jim_Simon  wrote

The existing PPro/AME ingest presets generate files that seem needlessly large.

Actually, that size is needed to make the files easy to play.  It's the very high compression (small size) of the originals that requires the proxies to begin with.

Apparently not.  The smaller h264 look great, play fine.  If it were a modest file size savings, sure, but we're getting 75x savings over Cineform.  The show we were on was highly mobile, meaning we're in multiple locations editing on a laptops and thousands of UHD sources.  If we'd worked in Cineform, we would have needed extra drives, making the process that much more cumbersome.  By going h264 we were able to keep two shows at full res plus proxies on one 4TB, which, in this context, made a difference.   The surprise was that neither the quality nor the performance took a significant hit by going with h264/mp4.

[Trevor_Asq]

The reason I use ultra small H264 files (which are v poor quality) is to use google drive to get proxies back from location quickly with variable internet connections. Can then get ahead with edit ahead of full res arrival.

Very interested in trying out ffmpeg recipe and also your extendscript recipes if you are willing to share.

[Premiopolis]

The ffmpeg strategy is relatively straightforward. The code I posted I actually use, and it looked great from Sony A7Sii UHD files. You can tweak the settings for higher quality. There's plenty of room to scale up the quality / file size. And w/ ffmpeg your'e hardly limited to h264. It seems to be able to generate any code and file type you can imagine. ffmpeg code / options logic is anything but obvious. If you need any help interpreting it, just ask. Or head to their site (ffmpeg.org <http://ffmpeg.org/>) and forums (https://lists.ffmpeg.org/mailman/listinfo/ffmpeg-user/ <https://lists.ffmpeg.org/mailman/listinfo/ffmpeg-user/>) Not as fancy as Adobe's but the folks who run it are really knowledgeable and answer complex questions with obtuse code that works like magic.

The ExtendScript side is more involved. The basic command you're looking for is projectItem.attachProxy(FilePath, 0); (0 = low res / 1 = high res)

Reference for that method are here: https://premiere-scripting-guide.readthedocs.io/4%20-%20Project%20Item%20object/projectItem.html#attachproxy <https://premiere-scripting-guide.readthedocs.io/4%20-%20Project%20Item%20object/projectItem.html#attachproxy>

and here: https://premiere-scripting-guide.readthedocs.io/4%20-%20Project%20Item%20object/projectItem.html#attachproxy <https://premiere-scripting-guide.readthedocs.io/4%20-%20Project%20Item%20object/projectItem.html#attachproxy>

The process of batch attaching takes you into actual JS coding, developing project architecture, naming conventions, etc. You sound like you know your stuff, but of course coding is its own world apart from editing. If you're familiar with it, then the above links are helpful resources. If not, there's a learning curve, but the benefits are worth it. Happy to help w/ specific questions.

[Trevor_Asq]

Thanks Premiopolis

I‘ve got ffmpeg up & running but having issues with 8 channel transcodes (QT ProRes & MXF AVCI ) using your recipe.

Before posting to ffmpeg-user I thought I’d check in & see if you had managed an 8 channel transcode?

[Premiopolis]

Trevor_Asq

I‘ve got ffmpeg up & running but having issues with 8 channel transcodes (QT ProRes & MXF AVCI ) using your recipe.

Before posting to ffmpeg-user I thought I’d check in & see if you had managed an 8 channel transcode?

I have indeed had problems working files 5 audio tracks and up, both on the ffmpeg side and with PPro interpreting them as surround sound.  But I just tested again using 8-track source, along with a 5- and 6-track and everything worked perfectly from ffmpeg to PPro.  Haven't been able to replicate the errors, but at least there's a promising solution here.

Tech details:

Sources in all cases were DNxHD video essence / PCM Audio 16 bits 48 Hz mono per track / MXF wrapper.

ffmpeg recipe was the one posted above.

Results were perfect mapping of sound, from DNx/mxf to h264/mp4.

Maybe post your tech specs / workflow

[Trevor_Asq]

Premiopolis  wrote

Trevor_Asq

I‘ve got ffmpeg up & running but having issues with 8 channel transcodes (QT ProRes & MXF AVCI ) using your recipe.

I have indeed had problems working files 5 audio tracks and up, both on the ffmpeg side and with PPro interpreting them as surround sound.  But I just tested again using 8-track source, along with a 5- and 6-track and everything worked perfectly from ffmpeg to PPro.  Haven't been able to replicate the errors, but at least there's a promising solution here.

Tech details:

Sources in all cases were DNxHD video essence / PCM Audio 16 bits 48 Hz mono per track / MXF wrapper.

ffmpeg recipe was the one posted above.

Results were perfect mapping of sound, from DNx/mxf to h264/mp4.

Maybe post your tech specs / workflow

I was playing around with various essence but mainly ProRes 422 in a QT container - with PCM 48k/16bit.

The recipe seems to fall down when I change the output file extension to .mp4 IF

-map 0

is still in the recipe

So

ffmpeg -i "$i" -y -g 48 -c:v libx264 -profile:v baseline -crf 32 -c:a aac -b:a 256k -vf scale=1280:720 -pix_fmt yuv420p "$o"

works fine when $o contains .mp4 but

ffmpeg -i "$i" -y -map 0 -g 48 -c:v libx264 -profile:v baseline -crf 32 -c:a aac -b:a 256k -vf scale=1280:720 -pix_fmt yuv420p "$o"

shows errors:

[mp4 @ 0x7fbd45006600] Could not find tag for codec none in stream #5, codec not currently supported in container

Could not write header for output file #0 (incorrect codec parameters ?): Invalid argument

Error initializing output stream 0:0 --

I was also getting errors with spaces in the filepath or name - hence putting the inputs & outputs into quoted variables. Made it easier to adjust anyway. Also meant I looked through what the various switches were doing (although I'm not sure what the -map 0 switch is actually doing.

(Also went down a rabbit hole of trying to add burn-in timecode, but need to somehow get my ffmpeg configured for drawtext. )

Thanks for the inspiration...

[excited_Genie16B8]

The smaller h264 look great, play fine.

I think "fine" is a relative term.  You won't get the same performance out of H.264 that you can get from Cineform, especially once effects come int play.

[Premiopolis]

You won't get the same performance out of H.264 that you can get from Cineform, especially once effects come int play.

You may well be right.  Though we did have a lot of layered effects in the timeline and still no obvious.  The back-and-forth between Proxies and Originals a real stroke of genius on Adobe's part and a huge relief from Avid.

In fact the reason for building an automated Proxy transcode-and-connect system was to be able to test multiple codecs and get a feel for the tradeoffs.  (In your honor we have preset named "Jim Simon" -- non h264).  The h264/mp4 was the right one for that recent project, but more projects coming up.  It'll take the time to develop a sense of what works best where.

[Premiopolis]

Minor update: I'm currently working on a different project, again using h264 proxies, editing in proxy mode while simultaneously exporting another sequence at full res (non-proxy) to a DNxHR on AME.  The Proxies are generally playing smoothly (there is sometimes some stutter play immediately after hitting play, but it smooths out within a few seconds.  Color is slightly amber compared to camera originals but only slightly)  Again, I'm hardly loyal to an h264 Proxy workflow, but this is AME exporting and editing simultaneously working on a MacBook Pro laptop using an external USB3 drive.  As the guy who fell off the Empire State building said on his way past the 35th floor: so far so good.