Use DNxHR or Cineform which is direct ProRes alternative.
Both should work fine in Vegas (and in Resolve).
For lossless option you can use 10bit uncompressed (v210) or RGB 10bit, but files will be big.
Beiträge von Andy
-
-
ProRes by its spec should be always limited range. There is no flag in its private stream nor in MOV headers which specifies video range.
You can create full range ProRes, but then you have to ALWAYS manually interpret such a files as full range as not a single app will know it's full range. Some apps (like Premiere) assume by default that full range is used for ProRes444, but there is no rule to it. Resolve itself still loads all ProRes files as limited range which is how it should be.
-
Ok I will send log file tonight, anyway the DVR project is very simple because is only a test: a 4K clip, with a LUT applied, scaled at 1080p. As I wrote, export to a similar codec (dnxhd) is faster, around real time. Vokoder prores take 5 times.
A info: if I encode on the same PC a prores file using ffmpeg is a lot faster.Plugin uses prores_ks which is closer with bitrates etc. to official encoder and ffmpeg default ProRes encoder is prores, which is way faster than _ks version. Use prores_ks in ffmpeg then then compare times.
-
ProRes 444 is 12bit, but ffmpeg is still encoding at 10bit.
Decoding is fixed and preserves 12bit.
You can add Auto option which has some logic to pick best format depending on encoding format.
Other options will be for those who know what they are doing.
Name could be "Pixel format", "Intermediate format"...
-
In case of ffmpeg all what it needs is: -aspect 16:9/4:3 command, so this should translate to Libav as well.
-
No way to get some documentation from BM?
I don't believe API has no documentation, but I can understand BM won't share it with "small developers". Poor approach though.
Yes, you need correct YUV data to encode for sure. You need levels to be correct as well. Fixing it by setting full range in codec flags is not very good workaround (sometimes not possible) as some apps don't read range flags.
-
All those setting should be there as well, no? So it just needs mapping.
-
Within the time we should have few pixel formats supported:
- yuv420 10bit for h264/5 etc
- yuv422 10bit ProResHQ, DNxHR etc
- yuva444 12 bit (for things like ProRes 444, DNxHR 444)- does ffmpeg properly encode now 444 at 12bit or they just fixed decoder?
- rgba 16bit -for anything RGB based
I assume bit depth scaling is not the issue, so those higher values will cover smaller bits depths.
Key point is to have YUV data when codecs require YUV data. Let Resolve do proper RGB->YUV conversion based on project settings etc. You don't want to do RGB<-> YUV as this would require all the color space etc. math behind it. Resolve does it well, so better to use final data.
For ProRes you want to add extra bits to ffmpeg command ( I assume you're adding color space, etc. already), so it looks more like Apple encode:
-metadata:s "encoder=Apple ProRes 422" -c:v prorers_ks -vendor apl0 -bitexact -movflags write_colr
These should be correct encoder names:
Apple ProRes 422 Proxy
Apple ProRes 422 LT
Apple ProRes 422
Apple ProRes 422 HQ
Apple ProRes 4444
Apple ProRes 4444 XQfor interlaced encoding (this will properly set ProRes private frame header as well) also add:
-vf "setfield=1, fieldorder=tff/bff" " -flags "ildct+ilme"
prores_ks is much slower but keeps bitrate in better control (still not perfectly as Apple encoder and affects quality a bit).
prores encoder is much faster, but it doesn't really restrict bitrate in the same way as Apple encoder. It will be most likely around 10-20% higher than Apple reference (but also quality is closer to Apple).
When it comes to PAL/NTSC aspect ratio just pass -aspect 16:9/4:3 and ffmpeg does set it properly by default based on frame size.
When you get timecode working then:
-timecode 10:00:00:00 -metadata:s reel_name=ABCD123
no sure if you can get reel name as variable.
Later we can add audio tracks language and name setting, which is useful.
-
Actually 0-255 is very important . Formats like DCPs, prores 444, Image sequences, IMF master files are full range. Years ago, Resolve was more focused on only rendering master files.
Grading is done in full range. Resolve takes the limited range and expands it to full with YUV files. RAW files are RGB and is full range. Keeps everything consistent when grading. Also grading monitors are almost always in full range.
As you noticed, Resolve only goes to 16-235 for non-RGB deliverables like prores hq and h264.
Looking forward to trying out the new update.
Resolve internal processing etc is meaningless here. Explained here:
https://forum.blackmagicdesign.com/viewtopic.php?…l+range#p711929
We need full range data as well, but be careful with it.
ProRes private frame headers have no tag (neither MOV container) to specify range. By design ProRes should be always limited range. You can send full range YUV data to it (ProRes also always stores data as YUV, even if you send RGB to it) and it will preserve it, but reading app will have no clue what is the real range of the file. Only by manual intervention (like we have in Resolve) you can force app to read it as full range. In some apps (like Premiere) it's all hard coded and there is no way to overwrite it. If I'm correct Premiere expects full range for 444 ProRes files and Resolve by default exports limited range, so you always need to set it manually in order to have good mapping between these 2 apps.
