[Jorn Bergmans]

It’s been a while since I worked with an AMIRA – that is, since the Alexa Mini came out a lot of my shoots have been with the newer ARRI body – but from what I know, the AMIRA records in ProRes (HQ or 4444 with appropriate license) which is super easy for the post workflow. Really, a basic drag and drop could be all that is needed.

As far as looks and luts go, AMIRA will record the ARRI LogC gamma curve, or has it’s own LUT to convert logC to r.709.
On-set the DP or cam assist can import a custom LUT that will be used for either monitoring, or monitoring + recording. (But please, don’t record the LUT, keep the logC image as your output if you plan on color correcting in post). They can provide this 3D cube LUT to post for the purpose of creating proxies and giving the colorist a starting point to build a look.

So that’s sort of it. ProRes files directly from the camera, which Premiere works great with.
If you want / need proxies for editing, they are easily made in Media Encoder or Resolve if you prefer a bit more control, where you can import the custom LUT (into ProgramData\Blackmagic Design\DaVinci Resolve\Support\LUT for your Windows env) and then output the timeline as separate files to your desired intermediate (I’m thinking, DNxHD 36/85 for offline editing, on windows?)
But if your machine is fast enough, it should even just pick up the rushes and have no problem with them.

– – –

So, what the Alexa Mini does, is burn the LUT into the metadata. This translates to Premiere showing the rushes _with_ LUT -under an option called ‘masterclip effects’ in premiere- but the footage will be _shot_ in logC and will view in Resolve as the nice boring grey-ish look that you want as a colorist.
This is the part where I’m not sure if AMIRA does the same. If it doesn’t, you are better off creating proxies with the LUT burned in. The other option being editing under an adjustment layer with the LUT on a lumetri effect, but this takes Premiere a lot of effort and cpu, and will eat up your real-time playback capabilities.

– – –

Hope this helps!

Kind regards,

Jorn

[Jorn Bergmans]

as an aside, ffmpeg will display the supported pixel formats when you input:
ffmpeg -pix_fmts

You can pipe the output and grep to ‘filter’ strict rgb formats. Note that pixel ordening will mean they’re not all labeled rgb, some will be bgr, grb, etc.
ffmpeg -pix_fmts | grep rgb

[Jorn Bergmans]

Hi there Seth,

So, the ProRes4444 format is a little weird, and a little weirder still in FFmpeg. Since it’s nothing but a ‘profile’ to the prores_ks encoder, it works like any other Prores encode would, and that (plus some reverse engineering done on the Apple decoder) suggests that ProRes even at 4444 is an YUV / Y’CbCr codec. That’s also what you told ffmpeg to export, and even when you input an rgb(a) it should default to yuva444p10le as the output:
(single frame output for example)
ffmpeg -i ~/0001077.dpx -codec:v prores_ks -profile:v 4444 -pix_fmt gbrp12le -r 23.976 ~/grb12_test_apr4444.mov
ffmpeg version 3.3.3 Copyright (c) 2000-2017 the FFmpeg developers
--snip header--
Input #0, dpx_pipe, from ‘~/0001077.dpx':
Duration: N/A, bitrate: N/A
Stream #0:0: Video: dpx, gbrp12le, 1920x1080 [SAR 1:1 DAR 16:9], 23.98 tbr, 25 tbn, 23.98 tbc
Stream mapping:
Stream #0:0 -> #0:0 (dpx (native) -> prores (prores_ks))
Press [q] to stop, [?] for help
Incompatible pixel format 'gbrp12le' for codec 'prores_ks', auto-selecting format 'yuv444p10le'
Output #0, mov, to '~/grb12_test_apr4444.mov':
Metadata:
encoder : Lavf57.71.100
Stream #0:0: Video: prores (prores_ks) (ap4h / 0x68347061), yuv444p10le, 1920x1080 [SAR 1:1 DAR 16:9], q=2-31, 200 kb/s, 23.98 fps, 11988 tbn, 23.98 tbc
Metadata:
encoder : Lavc57.89.100 prores_ks
frame= 1 fps=0.0 q=-0.0 Lsize= 1321kB time=00:00:00.00 bitrate=130373686.7kbits/s speed=0.000376x
video:1320kB audio:0kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead: 0.054886%


Secondly, as far as I know, currently FFmpeg does not support encoding deeper than 10bit pixel formats. (as suggested by the ‘p10le’ tail on the pix_fmt you supplied in your arguments). Reading a deeper-than-10-bit ProRes file will also give you the estimated yuva444p10le pixel format.

So that is where the colorshift might originate from. And that’s as much explanation as I can give you, considering I don’t know the system you’re working in or what color shift exactly happens.
If you need to encode to a mastering _video_ format in RGB, consider Apple Animation as it’s a RLE (linear) encoder that supports RGB pixel information.
For windows, I think you’d be stuck exporting a 10bit uncompressed video? (Which will be giant in filesize)

[Jorn Bergmans]

Exporting your timeline to a codec that is truly uncompressed is very inefficient in most cases. (They produce giant files)
Depending on your source footage, and the way you handled these files during postproduction, your highest quality is whatever your highest workflow setting is. So, for mastering, ‘all you need’ is a high enough quality codec to keep your data and ‘look’ intact, so that file can be used to create your deliverables.

As mentioned, the best options for this currently are codecs like ProRes422/ProRes4444 (Apple) or DNxHR (made by Avid, good mastering codec for Windows based sets) – these codecs are technically lossy (but visually barely noticable), but will give you an optimal mix between high quality and decent file size.

As Ann Bens mentioned, YouTube will always re-encode your file. To save yourself a lot of upload time, there’s a few tips in the upload specs.
https://support.google.com/youtube/answer/4603579?hl=en
I’d recommend reading the much clearer Vimeo specs, too. They are good to keep as a bookmark!
https://vimeo.com/help/compression

My suggestion would be something similar to this for HD video:
h.264 – main/high profile, level 4.1, 12-15 mbit/s VBR 1-pass
aac audio, 160-192kbps, 48kHz (assuming this is what was mixed), stereo
This would be an .mp4 file – under the h.264 format option in the export settings for Pr / AME

I’d suggest exporting a master file (ProRes or DNxHR), then encoding that file to these suggested settings before uploading the .mp4

[Jorn Bergmans]

Hello Anton,

As I said, I haven’t loaded for Avid in a long time. I believed, with AMA files, the EDL manager could embed the source path into the EDL.
An AAF should do the trick – the difference there being that an XML is literally just an edl, a text file referring to the files used, the in- and out-points and the in-point on the NLE’s timeline, where AAF has the option to embed all sorts of multi media.
It will still retain the link to the original file if specified, but it can also be a self-contained package like a zip + an edl.

For a full post workflow in FCP7 / Adobe + Resolve / Baselight, we tend to use XML as it’s a lot lighter (in KB’s) and all our files are on a central NAS/SAN RAID5 storage, so the XML will relink to absolute paths without having to embed anything into an AAF.
Exporting an XML from BaseLight will probably give you the fastest and least data intensive workflow, but AAF should work fine, too.

Digital Technician / Media Manager

[Jorn Bergmans]

Depending on how you set it up, a typical EDL will always refer to a relative file path / just a file name, while Premiere sees all files as a symlink to the actual file / content and it will require absolute paths to each file.
This means Premiere won’t typically relink files from an EDL properly, and you will always have to relink media and point Premiere to the first file in your EDL.

The workaround in Avid would be to add the full path to the file’s metadata in the project Bin. On the bin’s hamburger menu, select ‘choose columns’ and add ‘source path’ and ‘source file’.
That should allow Avid to export an EDL with an absolute filepath. Now I’m guessing this only works with files that you AMA link in Avid – but seeing as you’re working with EXR sequences, I’m assuming you have those AMA linked on a separate drive anyway, right?
(I’m a FCP / Adobe online editor/media manager, and I’ve not loaded for Avid in a while, but afaik the AvidMediaFiles database only accepts DNxHD and DNxHR video, which is why I’m assuming the AMA link)

That being said, an XML will typically point to an absolute path for each file. I would presume this works better in the case of relinking for Premiere. (also, it carries over more options for scaling, basic motion effects, multiple video and audio layers, etc – worth a try)

[Jorn Bergmans]

Hah, allright, thanks for the feedback. Im tempted to click the ‘like’ button on this, since that was exactly my assumption. I will file a bug report.

Any ideas on checks within Resolve are still welcome.

[Jorn Bergmans]

Hello Lucy,

Not all the settings all video can have are covered in the Easy Setup for fcp 7. You can, however, adjust your timeline to match the settings of your video. The Easy Setup is only a preset that will grab a default setting for any sequence you create within that project.
The Easy Setup preset you selected was based off HDV material, which is Anamorphic, and thus comes out as 1440*1080, which stretches to be 1920 when the Anamorphic flag is ticked. (turning 4:3 footage into 16:9 footage, essentially)

The easy way to adjust the timeline settings is by dragging a clip from your rushes into your timeline. FCP will ask if you want to adjust your settings to whatever your footage is exported as. This usually works fine, but it never hurts to know which setting is what, and where to adjust them.

So to set things up manually, we can create a new sequence, and set it up by going into the “Sequence – Settings…” menu (default cmd-0), which will pop up a menu allowing you to adjust your timeline.

In your case, where your rushes were made ProRes 422 1080i50 the settings from top to bottom would be

Frame Size: HDTV 1080i (16:9)
Pixel Aspect Ratio: in the case of 1920*1080 video almost always Square Pixels
Field Dominance: You’d have to check, usually Upper Field First (the ‘i’ in 50i means interlaced, which means the frames a split up into two fields with interlacing image lines. One of these fields is drawn first – either the odd or the even numbers, followed by the second field in the other 1/50th of a second. You can check this by right clicking a clip in your bins and reading it’s Item Properties)
Editing Timebase: 25fps – your footage is 50i meaning 50 fields per second, which makes for 25 full frames per second.

After setting this up, your footage and timeline settings should match, which will help with rendertimes and exports. If set up properly, your timeline should show no colored bars at the top (meaning the footage does not need to be rendered as the timeline is already in the right setting to play the footage dragged onto it)
Hope this helps!

[Jorn Bergmans]

Hi Scott,

Under the Window – Workspace tab there is an option called ‘Reset Current Workspace’.
This will reset the window layout you currently have selected to it’s original position and setup as when you first created it.

I know that doesn’t fully cover your problem, but maybe it will help on certain screens. I’m not aware of an option to make a windows layout ‘fit to screen’ or ‘stick to edges’, as the green bump in the upper left fills that function and I doubt it’s been put into Premiere itself.

As a work-around you could make a ‘failsafe’ layout, which you can drag into the middle of your screens so it will always have the green button accessible. Perhaps that would solve some of the headache on rebellious screens 😉

[Jorn Bergmans]

As the link Tero posted reads, holding the Command key while dragging a clip onto your timeline will insert that clip and move all clips over to the end of your newly inserted clip.

You will see a visual representation in the form of markers along a bar stretching along all of your video and audio tracks