16.0.b7 bypass re-encode

i test this in b5, and it worked as expected
today i have a film to drop QCfixes into

- master is DCi2kFlat, DNxHR444/10b / 10Ch / constant
- project is YRGB / DCi2kFlat / no color managment
- fixes are rendered the same: DCi2kFlat, DNxHR444/10b / 10Ch / constant
- new 10ch audio tracks
- target is DCi2kFlat, DNxHR444/10b / 10Ch / constant

i was expecting to see bypass re-encode run the timeline through without re-encodeing, but it's not...

is this becuase of the changed audio perhaps? or any other reason?

i am doing the same steps as the test i ran a few weeks ago with sucess, but with the real deal it's not a happening thing

i went back to the master project in ACEScct and used the timeline there, rendered that instead as i do not want another needless de/re encode cycle, definatly takes a bit longer (understatment)

any thoughts?

It's my understanding that any changes will force a new encoding.

but there's no changes to the raster and codec that the export would know about, audio is the same number of tracks, picture has 7 shots changed in a film with 1,126 shots in it that did not change

scratch my head on this one, esp as it worked amazingly well when i tested it a few weeks ago under what i think are identical conditions

You changed the audio, yes?

According to the 16 manual (p. 2795), changing only audio should allow for bypass re-encode, for the video. Are you certain there wasn't some other change?

really tried not to change anything

workflow:
grade in ACEScct, export a CTM as DNxHR444/10b with 10 ch audio @DCi2kFlat
send to QC
render 7 shots to DNxHR444 @DCi2kFlat
open a new project DCi2kFlat / YRGB
link to the CTM
link to the fixes
link to the revised audio
place the show on v1, fixes on v2
replace the 10ch audio
export to DNxHR444 @DCi2kFlat

and it forces a decode/encode cycle i was wanting to avoid

my answer was to drop the same revisions into the master ACEScct project and export from there, avoiding the unwanted decode/encode cycle

but in theory the workflow should be golden, and i tested it a few weeks ago in b5, and it worked amazingly well, running at the speed of my disks - at 500+ Fps until a revsion poped up, and then it slowed down to a more normal (for this machine) 60-90 fps, and went back to 500+ fps once past the insert

not sure what i could be doing in a sub-optimal manner here. there's not alot of moveing parts

continue scratching my head....

i have another film, this one needs a revised credit roll, i dropped the broadcast deliverable DNxHD175x into a new project, and added the 15 seconds of revision at the end of a 97min movie, matched the settings in the render page and hit the go button

it's working for this project... revised broadcast master should be completed in a few min

no idea why this one works and the other one does not

was planning on haveing them render overnight, and it seems i'll have the master done before i'm finished cleaning up the left over coffee cups

It should bypass re-encoding. I done some quick test in one of the 16 betas with ProRes and was behaving fine.
I'm not sure about Resolve implementation, but not only it should bypass in cases like yours, but also even if you had some part of the master replaced (re-graded etc). It should basically follow cuts and check if content is the same or not and re-encode only required bits.
This is the whole point of it and it should work well specially with I frame based codecs (Edius does it nicely).

Faster solution is CineXtools which simply write only new/changed parts in at hex level (also new/replaced audio tracks). If you have eg. 2h master and replacing 10 seconds it takes few seconds to finish. Quite expensive thought and works only with some codecs (they have to be strict CBR ones). DNxHD/HR is one of them. This is next step- they already have plugin for Premiere and worked with BM to have CBR ProRes export from Resolve.

Which Timeline Color Space do you use? For me everything is fine with "Rec.709 Gamma 2.4", but when I change the Color Space, bypass won't work on ProRes4444.

Looks like there is a bug.

for packageing i use YRGB, no color managment

bypass re-encode works well with DNxHD175x

does not appear to work with:
- DNxHR444@DCi2k_Flat
- DNxHR444@DCi4k_Flat
- DNxHR444@DCi2k_Scope
- DNxHR444@DCi4k_Scope

for packageing i use YRGB, no color managment

Nevertheless you have to choose a "Timeline Color Space"?

timeline color space is set to default (709/2.4) for packageing

Thanks. The bottom line is, bypass re-encode is limited to certain codecs (of cource, but which one), certain resolutions and it works in Rec709 Gamma 2.4 only, which means wrong metadata in renderes files if you want to work in other color spaces.

Color spaces tagging is problematic with bypass option.
Maybe this is why it's failing. Maybe all has to match.
For some codecs (without private headers, so eg. all uncompressed options) it should always work as container flagging is always newly written in exported file. For eg. ProRes, DNxHR, Jpeg2000 it's not so easy as private headers will keep original flagging and at the end you may have mismatched flagging.

Thats right. But even an exported file with a new header written (when nothing is bypassed) will show the same behaviour when you try to export it again with the same settings.
Did someone try 16.1 yet?

Don't understand.
When you export new file without bypass then private codec headers and container are newly written and should be aligned and follow project setting.

Did someone try 16.1 yet?

Yes, and it still is a problem with 16.1b1

I have a "Rec.2100 ST2084" master in ProRes 444 that I want to patch and re-export using the "Bypass re-encode when possible" feature. I've imported the master to a new project configured with "DaVinci YRGB" color science, and the Timeline Color Space is set to "Rec.2100 ST2084". I've then added a entry to the render queue matching the original codec. When I render out with the Timeline Color Space set to "Rec.2100 ST2084", Resolve will re-encode all the frames. However, if I set the Timeline Color Space set to "Rec.709 Gamma 2.4", it will bybass the re-encode, but of course my new file will have the wrong metadata. This is obviosuly not how you'd expect this feature to work.

Clearly a bug. Maybe next version will fix it.
I assume your original file is properly flagged for ST2084.

Clearly a bug. Maybe next version will fix it.
I assume your original file is properly flagged for ST2084.

Yes, it's properly flagged. That's why it don't make sense that Resolve will re-wrap it in a new Rec.709 flagged file, but not in a new ST2084 flagged file like the original.

Sounds like a bug. Well, I would like to see a proper implementation, including patching private codec headers if there is a mismatch. It's not that difficult (and Resolve re-writes whole file anyway). Could be done at lest for ProRes and DNxHR (maybe Jpeg2000).
For ProRes you can always change it later with BBC tool, but why not have it patched during main export. It's just few bits at every frame. If DNxHR is strictly CBR then it will be constant offset, so very easy.

Sounds like a bug. Well, I would like to see a proper implementation, including patching private codec headers if there is a mismatch. It's not that difficult (and Resolve re-writes whole file anyway). Could be done at lest for ProRes and DNxHR (maybe Jpeg2000).
For ProRes you can always change it later with BBC tool, but why not have it patched during main export. It's just few bits at every frame. If DNxHR is strictly CBR then it will be constant offset, so very easy.

+1

Nothing new on that, right? I still have to reencode, nothing is bypassed on the latest version.

Old topic but.. does this work in v17 now? Bypass re-reencoding with any other color space then Rec709?

I was able to do some tests: ProRes will still be re-encoded on export, but IMF (P3D65/PQ) for example won't.