Working with a DI on the T/L

MartinE wrote on 3/7/2017, 7:17 AM

OK I've got a project with a few scenes, some of which are long (30mins plus) and I'm using a separate veg file for each scene which I find easier than having the whole project on one t/l. I have issues with nested projects (weird things happen) so for each scene I intend to render a DI (UT Video YUV) and load these into a master veg, do a few transitions between scenes and render out a final DI for input to Handbrake (can't get frameserving to work for me, another story!).

Now say I need to make a small mod to a scene, I load the scene veg and also bring in the existing scene DI. Now the idea is to be able to smart render a new scene DI so that VP only has to re-compress the bit that changed, so here is the question:

Do I:

1. Put the DI on the top and just make a gap so VP "sees" the changed project tracks underneath ie just like a window or

2. Put the DI underneath and crop the main project tracks so only the changed section appears above the DI.

Does it make any difference which way I do this in terms of VP processing time?

Hope this makes sense.

Comments

NickHope wrote on 3/7/2017, 7:49 AM

I don't think it would matter either way as long as your preview window says "No Recompression Required" when you re-render. I think I would do #1.

MartinE wrote on 3/7/2017, 8:15 AM

Thanks Nick. That would be my choice also but since this is a new workflow for me I thought I'd just see what others thought.

astar wrote on 3/7/2017, 4:00 PM

There are very few codecs that smart-render in Vegas. Does your DI codec smart render? Because if you are not seeing "No Recompression Required" you rendering another generation either way.

Not sure that UT codec would be any different than using SonyYUV Uncompressed codec. If your source material is just HD 420, something like XDCAM-EX would make a good DI that smart renders. If your source material is already compressed, decompressing it does very little except take up space. I guess unless you are planning on several generations in your workflow. Cineform.AVI in FilmScan would be another DI choice that offer uncompressed quality with out the size. There is very little info on your source material to fully understand the workflow.

NickHope wrote on 3/7/2017, 9:30 PM

I did a quick test with MagicYUV RGB to check it would still smart render and it does. Can't check with UT Video Codec as I uninstalled it the other day. If you can't get it to smart render then MagicYUV RGB would be a good choice for a lossless DI.

MartinE wrote on 3/8/2017, 3:19 AM

Astar

My workflow is as follows:

Canon XF100 MXF files (mpeg2 35bm/s 4.2.0)

De-noised with Neat Video and batch rendered for editing

Edit 8-off scenes and render a DI for each

Put scenes together in master project (frameserving doesn’t
work for me) and render DI for input to HB

I’m interested in the use of XDCAM EX as a DI. How would it
stand up in the 3rd generation and does HB read it?.

Nick, Magic YUV doesn't work with HB

ushere wrote on 3/8/2017, 3:33 AM

I’m interested in the use of XDCAM EX as a DI. How would it
stand up in the 3rd generation and does HB read it?.

iirc xdcam no longer smart renders. well, at least raw footage from my ex1. it did once but was removed for some technical reason.

i now use xavc-i as an di with great success.

NickHope wrote on 3/8/2017, 9:41 AM

Nick, Magic YUV doesn't work with HB

I just asked @MagicYUV, the MagicYUV about the possibility of MagicYUV getting read by Handbrake. He replied:

Handbrake does read MagicYUV files, at least recent ones. Handbrake uses ffmpeg, and ffmpeg reverse engineered and implemented a MagicYUV decoder, so in general Handrake can decode MagicYUV files. However there is another issue, but that is related to AVI muxing, which makes handbrake refuse to read certain MagicYUV AVI files. See these topics for further info:

He added that it's an issue with Handbrake hopefully under investigation by the Handbrake team and that you need a very recent version of HB to have a chance of working at all.

OldSmoke wrote on 3/8/2017, 9:47 AM

I’m interested in the use of XDCAM EX as a DI. How would it
stand up in the 3rd generation and does HB read it?.

iirc xdcam no longer smart renders. well, at least raw footage from my ex1. it did once but was removed for some technical reason.

i now use xavc-i as an di with great success.

usher, did you manage to get HB to read the XAVC-I MXF files correctly? I have issues with that in HB 0.9.9.

john_dennis wrote on 3/8/2017, 10:26 AM

Old Smoke

I encoded XAVC-I files directly from a Canon camera and rendered from Vegas Pro 13-453 and Handbrake 0.9.9.5530 failed to handle the audio properly. I could possibly check a newer version of Handbrake on another machine later today.

OldSmoke wrote on 3/8/2017, 10:35 AM

John, that is exactly what I get. I don't have later versions of HB on my system and would really like to know if later ones can handle it.

john_dennis wrote on 3/8/2017, 12:04 PM

I updated Handbrake to 1.0.3(2017022500)-64 bit and ran the same test as before. This version of Handbrake now identifies XAVC-I files as having two mono audio tracks.

It was successful at encoding the audio from one track at the correct length.

The developers appear to be making progress but aren't there, yet.

1) Is there a way to combine two mono tracks into one stereo track in Handbrake?

2) It's time I threw some money at the Handbrake effort. I don't remember the last time I did.

ushere wrote on 3/8/2017, 4:50 PM

using the latest hb is ok - earlier versions didn't work... as jd observes, still some audio issues.

btw. i use xavc-i between vegas and resolve. usually use either vegas or ame for outputting assorted distribution formats