Archive for December, 2015

Need More Storage Than What DNxHD 36 Offers?

Monday, December 28th, 2015

avid-storage-calculator.gif

When DNxHD 36 was introduced in version 2.6.4 in March of 2007, it offered a balance of quality image and high storage rates that was a perfect fit HD offline workflows. As seen in the above graphic, 15GB for 1 hour of footage.  It is still a popular codec today, but with more test screenings coming straight out of Media Composer to DCP, and cost of storage going down, many of the studio productions are shifting to DNxHD 115 as the offline codec.

But in other markets, I have come across productions needing a a more compressed HD data rate than DNxHD 36. Perhaps it was to move dailies to a smaller drive to edit on set, or the drive wasn’t fast enough to play back the higher data rate, budget, or a combination of all of them.  When Avid introduced grater than HD project support in version 8.3 in December of 2014, it came with a new resolution independent codec called DNxHR. This codec was needed to support the new project resolutions and aspect ratios now available. The older DHxHD is a 720p and 1080 16:9 only codec at the handful of data rates offered.

For productions still shooting 1080 formats, it is possible using DNxHR to create media that is smaller than DNxHD 36. But with compression, it is a trade-off between storage, performance and image quality and understanding what these are will let you decide what is best for your workflow.

When in a 1080 project using 1080 sources, the Consolidate/Transcode box offers the option of Proxy Encoding at 1/14 and 1/16. When selecting this, your only option is DNxHR LB, the lowest data rate of DNxHR codecs. A good rule of thumb is when working at 4H UHD, which is 4x bigger than 1080 HD, DHxHR LB is the equivalent of DNxHD 36. If you were in a 4K UHD project and transcoded to DNxHR LB 1/4 proxy, it is the same as 1080 DNxHD 36.

You can create these DNxHR proxies from AMA linked clips directly, or from 1080 sources already at DNxHD 36. Note that these 1/4 and 1/16 proxy formats can only be created in Media Composer. Unfortunately they are not available in third party dailies applications - perhaps that will be made available in future versions.

transcode-1.jpg

transcode-2.png

For comparison purposes, I have also included Avid’s H.264 800 Kbps for comparison as it offers the most storage but is mainly designed for Avid’s remote editing solution, but can be considered as well depending on your needs.

For this explanation, I have used a 1 minute 1080 source clip (exactly 00:01:00:00) so that comparison between codecs can be easier to see. Here are the clips in the bin after each of the transcodes:

proxy-clips-bin.png

When compared for storage and how much more storage per codec type we get:

proxy-storage-compare.gif

So as we saw in the first graphic, 1 hour of DNxHD 36 was 15GB. Using any of these other proxy formats would give you ~4x to ~41 times more storage and more performance for slower drives, or more layers of real time playback for VFX or multicamera editing when in Media Composer.  The last factor to consider is what do these look like? Again, depending on your needs and how you are monitoring, any one of them may work - but the biggest difference is if you need to monitor at 1920 x 1080 with a client monitor or using full screen on a 1920 x 1080 GUI monitor - The smaller data rates may or may not work based on complexity of image and detail required for editorial decisions. But a 1080 at DNxHR LB 1/16th may work fine if all you use are the smaller source/record GUI monitors and don’t go full screen or have a client over your shoulder. Also keep in mind as per a previous blog, operations such as stabilize at proxy resolutions do not give you the same results when going back to full rez or camera masters.

Here is what the four “smaller than DNxHD 36″ options look like when transcoded and viewed at 1920 x 1080. Click to see full resolution.

proxy-quality-compare.jpg

I find that if in this situation, the DNxHR LB 1/4 Proxy offers a nice balance of image quality to storage savings. H.264 800 Kbps Proxy offers the absolute best storage rates, and looks slightly better than DNxHR LB 1/16 when editing in the GUI monitors alone (no 1920 x 1080 full screen). This is due to LongGOP’s ability to provide higher image quality at higher compression rates compared to I Frame only encoding as found with DNxHD or DNxHR.

Here is DNxHR LB 1/16 Proxy (left) and H.264 800 Kbps Proxy (right) when viewed in Source/Record Monitor on a 1920 x 1080 monitor. Click to see full resolution.

16-vs-h264-gui.jpg

Converting MS Word to Text With Layout

Thursday, December 10th, 2015

 

scriptsync_image.jpg

A question came up recently on the Avid Editors of Facebook on how to take a screenplay that was written in Microsoft Word and export it to be used with Avid Script Based editing while preserving the script layout. In older version of Microsoft Word, there used to be a “save as text with layout” option, but that is no longer available.

One solution is to use Fade In, an excellent, low cost, professional screenwriting software, that even in demo mode, allows for importing and exporting of different file types. In this scenario, the script is exported from Microsoft Word as .RTF and opened in Fade In. Once opened, go to the file menu and select export as “Formatted Text”. That will preserve the screenplay format and be ready to use in Avid’s Script Based editing interface. A demo of the process can be see here.

If on OS X, my go-to tool for further text manipulation is TextWrangler. One example brought up in the Facebook thread was adding more left side margin in the file. This can easily be done by opening the text file, selecting all the text and using  the “Shift Right function” from the Text Menu which is ” command-] ” and it inserts a Tab for each time used.

Before:

before-shift.gif

After Shift:

after-shift.gif

 The script used here for the demo is for the 2015 film “Straight Out of Compton” - available for download with other 2015 screenplays from IndieWire

Complete Your BWF Export

Wednesday, December 9th, 2015

bwf-blog-1.png

When exporting audio as BWF and you want to ensure metadata integrity, you need to finalize the process with a BWF editor such as Sound Device’s free Wave Agent, available for both Windows and OS X and should be part of everyone’s toolset. You can find more info and download here.

The example shown is a quick multitrack sequence simulating a 5.1 sequence as mono tracks to be exported as a poly file for archive or other purposes. Substitute your own naming convention and timecode per your own needs. Note that is also applies to exporting BWF source clips directly from the bin as well as poly or mono.

As you can see from the above image, I have a basic 6 track audio in a 1080p/23.976 project/timeline starting at 01:00:00:00 and I have renamed my tracks. I export using direct out as seen in these settings:

bwf-blog-2.png

Opening the exported file in Wave Agent shows the following (click to enlarge)

bwf-blog-3.png

As indicated, the timecode now shows 01:00:03:18 which is not correct. The Project and and Track info are blank and this is long time request to have that metadata taken from the project and track names automatically.

In order to correct and embed the proper timecode metadata back into the file, uncheck “Preserve Start TC:

bwf-blog-4.png

Then from the Frame Rate menu, select the frame rate that matches the project from which it was exported:

bwf-blog-5.png

This will update the timecode by properly embedding the frame rate/sample from midnight into the file.

bwf-blog-6.png

At this point, I also add the track info back onto the tracks and optionally add a project name that is most likely the same as the file name, but is now embedded in case that gets changed. Be sure to click the “Save” button before leaving the application.

bwf-blog-7.png

Now this information is part of the BWF file to be re-purposed as needed - even when re-importing back into Media Composer. It seems that the frame rate value is not being defined in the bEXT chunk of the BWF when exported. This is from the Sound Devices webpage on timecode:

TC frame rate:  This is the frames per second rate. It is also used to convert the HH:MM:SS:FF time code value to a ‘Samples Since Midnight’ value and visa versa. It is stored in the bEXT chunk as the ‘SPEED’ parameter and in iXML as the ‘TIMECODE_RATE’ parameter.

As seen here in this Sound Devices Tech Note.