Best workflow to delivery Prores from pc?

Hi guys and girls..

Do you have an effective workflow to encode Prores in a PC ?
I'm working on Resolve 12.5 .. and looking fpor a good encoder..

any ideas of a good workflow to break this Apple barrier

thanks


llano.

Telestream Switch was cheapest way to get official ProRes encoder, but you have only ProResHQ option.
And they just raised the price to 499$ which is not that cheap anymore at all.

You can also buy/rent Scratch and this will give you fully featured ProRes encoder on PC.
All other option with official ProRes are rather expensive.

Free solution- export v210 uncompressed MOV and then encode with ffmbc/ffmpeg (using good command).

Last solution- buy Mac or build hakintosh.

I think your best option here, that wouldn't cost you anything, would be ffmpeg. As Andrew said, you will need to export from your NLE in an uncompressed format, or you can even use a high res images sequence, something like EXRs for instance.

Then, you can use this guide to understand ffmpeg and find the command that you will need to use:

https://trac.ffmpeg.org/wiki/Encode/VFX

This is the command the article uses.. This converts an image sequence to ProRes 422

Code: Select all

ffmpeg -y -probesize 5000000 -f image2 -r 48 -force_fps -i ${DPX_HERO} -c:v prores_ks -profile:v 3 -qscale:v ${QSCALE} -vendor ap10 -pix_fmt yuv422p10le -s 2048x1152 -r 48 output.mov

If you want to use quicktime sources and convert them to ProRes 4444, then you can use something like this:

Code: Select all

ffmpeg -f mov -r [add the frame rate of the original footage] -i [file path\yourFile.mov] -c:v prores_ks -profile:v 4 -qscale:v [any number between 0 and 32] -pix_fmt yuv422p10le -s [resolution] [file path\convertedFile.mov]

The qscale, as explained in the link above, is very important as it determines the bit rate of the file. Lower numbers give higher bit rate and better quality, but takes longer to render. So, if you are converting a very long file, it will take a while if you use a low qscale number.

Last, if at anytime you need to know what are the options available in ffmpeg, or you don't understand what any of these "-(text)" means, you can just type "ffmpeg -h" in the command line, and it will give you all the options (or most of them at least) and their explanations.

Hope this helps.

Use profile:v to have standard ProRes modes- HQ, LT etc. By using qscale you are making non-standard bitrate ProRes. You rather use 1 or another.
1st command is for ProResHQ (profile:v 3), not ProRes. It's 0,1,2,3 which is Proxy, LT, Normal, HQ.

Also it's not -vendor ap10, but -vendor apl0 to simulate that file was encoded by Apple encoder.

v210 is best format to start with for any ProRes except 444 as it's exactly what is fed into encoder, so you will never have situation that ffmpeg has messed with incoming data as it simply passes it in this case.

Ideally there are other options needed for MOV muxer, like color tag, muxing chunk, etc

Hello,


Did you try to see if you can deliver in DNxHD ? (Avid multi platform codec)

Try to ask them, Prores is not the only solution for mastering

I don't remember how I did it, but I used to have ProRes as export options in Resolve 12.5 on Windows before I reinstalled Windows.

I may have installed various ffmpeg tools, like ClipToolz; but whatever I did, I somehow had the ProRes option on the render page as well as the optimized media settings page. Does anyone else have that?

Use profile:v to have standard ProRes modes- HQ, LT etc. By using qscale you are making non-standard bitrate ProRes. You rather use 1 or another.
1st command is for ProResHQ (profile:v 3), not ProRes. It's 0,1,2,3 which is Proxy, LT, Normal, HQ.

Also it's not -vendor ap10, but -vendor apl0 to simulate that file was encoded by Apple encoder.

v210 is best format to start with for any ProRes except 444 as it's exactly what is fed into encoder, so you will never have situation that ffmpeg has messed with incoming data as it simply passes it in this case.

Ideally there are other options needed for MOV muxer, like color tag, muxing chunk, etc

Thanks, Andrew. I am still exploring ffmpeg myself. I know the first command is for ProResHQ. I personally only used the second one for the 444 option, but I didn't know that I shouldn't use qscale.

Regarding the vendor part, I haven't used this parameter and I haven't looked into it myself. The first command is just copied from the article I mentioned, which I was just reading a couple of days before reading this post.

Thank you.

The quickest and user friendly way I found to do it, is to use Convert V4
http://hdcinematics.com/V4.html

You can use the free version, but with one encoded files at time.

Two things :
1) The last release I used has a 601/709 issue with Prores HQ encoding.
As the previous release were perfect, I guess it should be fixed today.

2) I dont like the licencing key.
It depends of your hardware, so if you change something important (like a MB),
you'll have to request a new code.

It's uses same ffmepg code + you have no control over additional and important parameters. Waste of money for pure conversion to ProRes.

Use profile:v to have standard ProRes modes- HQ, LT etc. By using qscale you are making non-standard bitrate ProRes. You rather use 1 or another.
1st command is for ProResHQ (profile:v 3), not ProRes. It's 0,1,2,3 which is Proxy, LT, Normal, HQ.

Also it's not -vendor ap10, but -vendor apl0 to simulate that file was encoded by Apple encoder.

v210 is best format to start with for any ProRes except 444 as it's exactly what is fed into encoder, so you will never have situation that ffmpeg has messed with incoming data as it simply passes it in this case.

Ideally there are other options needed for MOV muxer, like color tag, muxing chunk, etc

Thanks, Andrew. I am still exploring ffmpeg myself. I know the first command is for ProResHQ. I personally only used the second one for the 444 option, but I didn't know that I shouldn't use qscale.

Regarding the vendor part, I haven't used this parameter and I haven't looked into it myself. The first command is just copied from the article I mentioned, which I was just reading a couple of days before reading this post.

Thank you.

Vendor parameter is not that important at all- it's just metadata which identifies which encoder was used. apl0 is for Apple.
When you transcoding form DPX or EXR make sure you specify color matrix, so conversion from RGB to YUV is done properly over Rec.709 or Rec.2020 if needed. I advise to use zscale filter and also write_colr option which will add color tagging to MOV, e.g.

-vf "zscale=pin=709:tin=709:min=709:p=709:t=709:m=709" -movflags write_colr

this will do accurate conversion from EXR/DPX (through Rec.709) into YUV for ProRes etc encoding.

Use profile:v to have standard ProRes modes- HQ, LT etc. By using qscale you are making non-standard bitrate ProRes. You rather use 1 or another.
1st command is for ProResHQ (profile:v 3), not ProRes. It's 0,1,2,3 which is Proxy, LT, Normal, HQ.

Also it's not -vendor ap10, but -vendor apl0 to simulate that file was encoded by Apple encoder.

v210 is best format to start with for any ProRes except 444 as it's exactly what is fed into encoder, so you will never have situation that ffmpeg has messed with incoming data as it simply passes it in this case.

Ideally there are other options needed for MOV muxer, like color tag, muxing chunk, etc

Thanks, Andrew. I am still exploring ffmpeg myself. I know the first command is for ProResHQ. I personally only used the second one for the 444 option, but I didn't know that I shouldn't use qscale.

Regarding the vendor part, I haven't used this parameter and I haven't looked into it myself. The first command is just copied from the article I mentioned, which I was just reading a couple of days before reading this post.

Thank you.

Vendor parameter is not that important at all- it's just metadata which identifies which encoder was used. apl0 is for Apple.

I see. Thank you for the explanation, Andrew.

the delivery spec's i have to work to specify "Apple Certified ProRez"... the QC houses get a copy of the deliverables spec's and they have to issue q QC pass based on those spec's- there's no wiggle room there for anything but the real deal

Nucoda's Loki is a cost effective option, it monitors a folder and when there's something to render to ProRez it does it in the bg, there's no need for setting up renders etc once set up, just render your Resolve timeline to say DPX into a folder that Loki is set up to watch, and the ProRez is made automagicly for you

Dermot, how much is Loki?

It's not going to be 500$ for sure

official ProRes encoder

I question the existence of such for Windows. To the best of my knowledge, Apple has never released an SDK for ProRes on Windows, nor licensed it's use in Windows encoders.

This is part of the reason Premiere Pro only includes ProRes encoding with the Mac version.

Magix recently added ProRes decoding/encoding to Vegas Pro 14. Not sure how well it's implemented though, but it's usable even in the 30 day trial. It's not on the ProRes authorised products list yet.

official ProRes encoder

I question the existence of such for Windows. To the best of my knowledge, Apple has never released an SDK for ProRes on Windows, nor licensed it's use in Windows encoders.

This is part of the reason Premiere Pro only includes ProRes encoding with the Mac version.

They haven't released anything as "widely available"- you have to go to them and ask for an agreement. You may get it or not- all depends on your product type etc. and also your contacts at Apple.
There are many products with Apple licensed ProRes encoding on Windows, but about all of them are enterprise level (expensive) and many (but not all) require Windows Server OS. They seams to be more happy to give you license for hardware implementation, which don't affect them in "war of OSes".

If you interested this is an official list:

https://support.apple.com/en-gb/HT200321

which does keep growing.

Also please don't quote single words out of context, because they become meaningless.

Magix recently added ProRes decoding/encoding to Vegas Pro 14. Not sure how well it's implemented though, but it's usable even in the 30 day trial. It's not on the ProRes authorised products list yet.

I don't think it's Apple licensed. Does their website say Apple licensed? I'm sure they would say it if it would be.

Cool, from the release notes of the newly released Blackmagic Design Fusion Studio 9.0:

• Fusion is now certified for Apple ProRes on all three platforms. The unsupported 32bit QuickTime framework is no longer used on Windows.
  
  • Fusion Studio can load and save Apple ProRes on all platforms.
  • Fusion (free) can load and save Apple ProRes on macOS.
  • Fusion (free) can load but not save Apple ProRes on Windows and Linux.
  • Render Node can load but not save Apple ProRes on all platforms.

Let's hope they bring this to DR Studio as well.

But even now Fusion would be the cheapest solution to get a certified encoder on the PC, even if you don't need any of it's other features

[Peter Chamberlain]

For clarification, there should be no expectation that ProRes rendering will become available on DaVinci Resolve for Windows.

Thanks for the clarification, Peter, much appreciated.

So, my second argument stays valid: just get Fusion Studio to have the cheapest certified encoder for ProRes on Windows. It should be a non-brainer for any professional shop, even if not needing any of the other features of that excellent compositing software.

Fusion will cause RGB route which is not desired for straight conversion (with YUV based sources).

Something that has been mentioned is FFMpg so it may not be certified Prores after all?

Prores encoding works in Fusion Studio 9 on Windows without even configuring a path to ffmpeg.exe. FFmpeg is optional and I've only been able to use it for reading. With FFmpeg configured I was able to read an mkv file directly in Fusion, without FFmpeg it wouldn't work. To me that indicates that the Prores implementation does not come from FFmpeg, that and the fact that the BMD release notes states "certified for Apple Prores".

Fusion will cause RGB route which is not desired for straight conversion (with YUV based sources).

Andrew, what is the major downside of processing in RGB in the middle? I guess it makes lossless trimming of ProRes files impossible, but are there other issues as well?

It's not biggest problem, but for "broadcast" usage you don't want to go to RGB, but stay in YUV.
It's just unnecessary conversions: YUV->RGB->YUV. If you think of Fusion as transcoder then this is not the best route (but all grading/compositing software work in RGB).
YUV<->RGB is never 100% lossless (not like you going to see any difference, but in math sense). It also can cause issues with Rec.709 v Rec.601, gamma etc. When you stay with YUV nothing like this will happen as data always stays as YUV, it just gets encoded to new codec. This is why transcoders work rather in YUV or change path based on incoming/outgoing format.
For example Telestream Episode has many "routes" and based on source/target it triggers one. It will never for example convert eg. ProRes to AVC-I over RGB pixel format. It will decode ProRes to v210 (10bit uncompressed YUV 4:2:2) and because AVC-I encoder module accept this as source it will straight away pipe this into encoder. The same will happen in ffmpeg.

In ideal world once your master is done in some RGB based finishing software (Flame, Resolve etc) and converted to YUV based format (ProRes, DNxHR, etc) for further broadcast, web, Blu-ray etc usage it should stay in YUV world (and in most cases this is the case).

That's why there is specialized software for this and why it's costly. It's aimed at a smaller number of shops who use it daily and have picky clients who are ready to pay for it.

All the others will never even notice a difference. The gamma and/or color shifts you are mentioning don't come from the tiny errors in RGB/YUV/RGB conversions. They come from improper tagging of codecs or differences in their interpretation by playback software.

They do come me from bad RGB<->YUV conversion- it's the source of most problems with Rec.709 v Rec.601.
Tons of software out there were at some point affected by this including free ffmpeg, through ContentAgent up to Vantage
Tagging issue is only visible in players as again- YUV has to be converted to RGB for the display. If you stay in YUV then tagging is issues is "transparent" for conversions.

It's not about being specialised or costly- you can have free ones. It's (again) about using correct tool for the given task. If you just want to convert your source camera assets or some final master (from e.g. Resolve) through Fusion to ProRes then this is still absolutely fine.

Hi guys and girls..

Do you have an effective workflow to encode Prores in a PC ?
I'm working on Resolve 12.5 .. and looking fpor a good encoder..

any ideas of a good workflow to break this Apple barrier

thanks


llano.

No contest. I have Delivered it a thousand times: In Resolve, Export a DPX or Uncompressed .MOV then use http://hdcinematics.com/Dali.html to Prores but if you think you need to Deliver 'certified' ProRes from a PC, use Fusion 9 Studio or Assimilate 'Scratch' (buy outright or a short subscription 'as required')

PS: there is another low cost and 'Certified' alternative everybody else seems to miss. If you have a BMD Mini-Monitor configured, (you probably shouldn't be using Resolve without one or a Decklink card) simply play down your Timeline and record to any Atomos Recorder. I've used this method successfully with a Ninja 'Star' ProRes recorder and Atomos ProRes recorders are Apple Certified.

Fusion will cause RGB route which is not desired for straight conversion (with YUV based sources).

Regarding this, since DR forces all sources into RGB, if one stays in RGB for export, than using Fusion for a ProRes encode should be theoretically lossless, i.e. equivalent to putting a ProRes encoder for Windows into DR. Granted I have not tested any of this.

If you don't want your YUV source to go through an RGB conversion you should stay away from DR as well. But I am not aware of any color correction tool that operates in YUV anyway.

Again, this is all pure speculation on my part.

...Again, this is all pure speculation on my part.

That reads like pretty sound speculation.

Fusion will cause RGB route which is not desired for straight conversion (with YUV based sources).

Regarding this, since DR forces all sources into RGB, if one stays in RGB for export, than using Fusion for a ProRes encode should be theoretically lossless, i.e. equivalent to putting a ProRes encoder for Windows into DR.

Problem is that it won't. ProRes is always (although spec says in can be also RGB) YUV based (well, not 100% sure and would like to see RGB encoded ProRes file), so you always doing conversion. Any write to ProRes is RGB->YUV and then on reading again YUV->RGB.

This is why I would prefer to use Cineform for intermediates steps (going through Resolve, Fusion, AE etc) as its 4:4:4 mode is RGB based (4:2:2 mode is YUV based).
Again- in ideal scenario until you work between "grading/compositing/finishing" apps (Resolve, Scratch, Flame, AE, Fusion etc) you want to stay with RGB. Once you have final product you export to some YUV based codec (ProRes etc) and from this point any other lower end formats should be done over YUV chain (from now on we can forget about RGB). This is ideal scenario, which is broken quite often in real world and it's not end of the world

I think you misconstrued what I was saying, so let me try again. I know that ProRes encodes are typically YUV. What I was saying is that DR forces all YUV sources through an RGB conversion. Therefore, if one stays in RGB on export, reads this into Fusion, then theoretically, an RGB export from Fusion should be lossless. But like I said, I have not tested this which is why I speak speculatively. I don't have Fusion, so I leave it to Fusion users to test this themselves. Testing workflows is tedious, but I have done enough testing of round trips with other vfx/compositing software to know what to expect, theoretically, speculatively, or whatever word floats your boat. I am trying to be helpful here, not combative.

Therefore, encoding to ProRes in Fusion (which of course will impose an RGB>YUV conversion which I thought was implicitly understood in my previous post), should be no different than putting a ProRes encoder in DR. IOW,

ProRes (YUV) > DR (RGB) > Export (RGB) > Fusion (RGB) > ProRes (YUV)

would theoretically be identical to (if it existed):

ProRes (YUV) > DR (RGB) > ProRes (YUV)

If the above is not the case, then that is a serious ding against Fusion IMHO. But I am giving Fusion the benefit of the doubt. I was mainly pointing out that Fusion's RGB route is no different than DR.

ProRes (YUV) > DR (RGB) > Export (RGB) > Fusion (RGB) > ProRes (YUV)

would theoretically be identical to (if it existed):

ProRes (YUV) > DR (RGB) > ProRes (YUV)

If the above is not the case, then that is a serious ding against Fusion IMHO. But I am giving Fusion the benefit of the doubt. I was mainly pointing out that Fusion's RGB route is no different than DR.

This is correct.
It doesn't matter if ProRes encoder is in DR or Fusion or Flame etc. They all work in RGB so end effect is (should be the same) the same.
I've read that Autodesk support reply about ProRes storing data as YUV or RGB was:
we read and feed into it RGB, but we don't care how it's stored inside ProRes
I can't find a single app which clearly states that it can write ProRes444 as RGB.
Companies just simply feed/read whatever it's easier for them (and it can take quite a many pixel formats) and don't care what happens with this data once it gets encoded. Code is certified, so somehow they are fine in this approach. It's just would be nice to know if there is single solution out there which writes RGB based ProRes. Apple says it's possible, but this is just theory.