Lossless Workflows using Premiere Pro, VirtualDub, ffmpeg and others

[poisondeathray]

And the ffmpeg v410 conversion is mathematically lossless according to that amplified differences check, when converted back to 8bit RGB with the stacked 16bit dither disabled (mode=-1) workflow method shown earlier , or PSNR test (at least on the limited test)

But few programs like NLEs will accept v410 at this point in time

But kudos to ffmpeg, avisynth/ dither tools for coming through

ffmpeg -r 24 -i "SMPTE_Color_Bars_16x9.svg.png" -vf scale=w=-1:h=-1:out_color_matrix=bt709 -pix_fmt yuv444p10le -vcodec v410 -an v410.avi

The conversion back from the AVI should use LWLibavVideoSource, because LSmashSource is for MOV/MP4 only, but otherwise it's the same thing

LWLibavVideoSource("v410.avi", format="yuv444p16", stacked=true)
Dither_convert_yuv_to_rgb (matrix="709", output="rgb24", lsb_in=true, mode=-1)

[SameSelf]

Here is a way to do it with ffmpeg prores-ks . It's pretty clean too, if you look at amplified differences, similar pattern so I'm thinking lossy compression artifacts. At least the solid colors return RGB values correctly (when prores is decoded correctly as described above)

You need a ffmpeg build with prores-ks (zeranoe's doesn't have it by default) . I use the autobuild script

ffmpeg -r 24 -i "SMPTE_Color_Bars_16x9.svg.png" -vf scale=w=-1:h=-1:out_color_matrix=bt709 -profile:v 4444 -pix_fmt yuva444p10le -vcodec prores_ks -an -f mov -vendor apl0 ffmpeg_prores_ks_4444_q1.mov

Notice the vendor writing library in mediainfo hahaha

Writing library : Apple

The ffmpeg build that I use has prores_ks, so I gave your ffmpeg cmd above a try. I think it is a little noisier, or has more compression artifacts, than the ffmbc version. Here is the cmd I use:

ffmbc -i in.png -color_primaries bt470bg -vcodec prores -profile hq -b 220000k -pix_fmt yuv444p10 -an out.mov

The only problem is the some of the MediaInfo is wrong. I will go ahead and attach the ffmbc bars, so you can see what you think.

Also, I tried loading the PNG into Nuke and exporting as a ProRes 422 HQ file, but I am getting a strange luma shift. Would you mind telling me exactly what settings you used on the write node? Also, is there a way to tell Nuke how to chroma subsample? I feel like I am really close to falling completely in love with Nuke. Figuring some stuff out is admittedly not easy though.

[poisondeathray]

The ffmpeg build that I use has prores_ks, so I gave your ffmpeg cmd above a try. I think it is a little noisier, or has more compression artifacts, than the ffmbc version. Here is the cmd I use:

ffmbc -i in.png -color_primaries bt470bg -vcodec prores -profile hq -b 220000k -pix_fmt yuv444p10 -an out.mov

The only problem is the some of the MediaInfo is wrong. I will go ahead and attach the ffmbc bars, so you can see what you think.

At this level of quality, you're "splitting hairs" especially if you're going to be using "normal" footage.

You should be comparing more challenging content if you're testing compression quality - solid color bars aren't a good test

You can look at the amplified differences with AE since you're using Adobe (or you can do it in avisynth), or if you wanted objective metrics do some PSNR or SSIM tests on the decoded image

Naked eye can't tell big differences, but on amp diff, it's clearly nuke > prores-ks > ffmbc . And if you use the amp difference to guide you and go back and look at the decoded images you might be able to see the problem areas (many people still won't be able to)

PSNR agrees


nuke
PSNR r:100.884127 g:inf b:98.287753 average:101.155649 min:101.155649 max:101.155649

ffmbc
PSNR r:86.968361 g:92.003864 b:87.953516 average:88.495306 min:88.495306 max:88.495306

prores_ks
PSNR r:95.616036 g:100.158620 b:95.387407 average:96.575366 min:96.575366 max:96.575366


But those aren't very meaningful test results by themselves (it's 1 data point, and a weak one at that in terms of compression testing), because you're shouldn't be using bars to test compression efficiency, codec characteristics, or how a codec "breaks down"

Also, I tried loading the PNG into Nuke and exporting as a ProRes 422 HQ file, but I am getting a strange luma shift. Would you mind telling me exactly what settings you used on the write node? Also, is there a way to tell Nuke how to chroma subsample? I feel like I am really close to falling completely in love with Nuke. Figuring some stuff out is admittedly not easy though.

When exporting out of Nuke for windows, I leave everything default except colorspace in the write node is set to sRGB. Nuke works in linear automatically internally - all the math and operations are more accurate as it "undoes" the ~sRGB 2.2 gamma curve . It has to re-apply that curve to get the results that you would expect on a PC. (AE has a linear workflow you can enable too but it's not as nice)

No easy way to modify the chroma subsampling that I know of - you would have to convert, split out the channels, process them individually then merge before the write node

[SameSelf]

pdr, great! just great! absoutely great! Those ProRes 4444 bars out of Nuke are sweet! I was also able to render out nearly perfect ProRes 422 HQ bars as well. I need to learn how to do those PSNR tests and amplified differences you posted, but otherwise, I feel like this is a major breakthrough. You realize what this means, right? There is a fairly rock solid way to encode to ProRes on the PC! I also need to work through the v410 workflow you posted above. I have been obsessing over Nuke for the past few days, watching lots of tutorials, etc. I am convinced there is a way to break out the channels and specify the chroma subsampling. Anyway, BRAVO!

Yes, it would be very interesting to do a PSNR test on some sample footage for the three methods. I will try to find some time soon.

[poisondeathray]

pdr, great! just great! absoutely great! Those ProRes 4444 bars out of Nuke are sweet! I was also able to render out nearly perfect ProRes 422 HQ bars as well. I need to learn how to do those PSNR tests and amplified differences you posted, but otherwise, I feel like this is a major breakthrough. You realize what this means, right? There is a fairly rock solid way to encode to ProRes on the PC! I also need to work through the v410 workflow you posted above. I have been obsessing over Nuke for the past few days, watching lots of tutorials, etc. I am convinced there is a way to break out the channels and specify the chroma subsampling. Anyway, BRAVO!

Yes, it would be very interesting to do a PSNR test on some sample footage for the three methods. I will try to find some time soon.

Yes, Nuke is prores certified by Apple. I mentioned it could do prores a few pages back, but I wasn't sure if the free version could export prores. It also reads v410 by ffmpeg when wrapped in MOV, but it's a bit "off" (e.g. you should get 1.0 linearlized for 100% red, but it reads 0.99 something)



RE: PSNR - it's discussed extensively in other threads and other boards, websites. The most important thing I'll say about it - is has to be interpreted properly and in context . There are slightly different ways to calculate it, but at least it's a verifiable, objective measure of quality deviation from an original. At the very least, it's great for distinguishing lossless vs. lossy. I won't discuss it farther here pros/cons because it's a big discussion which falls under an even bigger discussion of video quality/compression testing

Anyways - Most common would probably be to use MSU VQMT because it has a GUI. I prefer using ffmpeg to do the calcuation, because it can handle just about anything, you can batch it, and you can get a per frame log which you can plot (MSU can do plots too). It also can handle higher bit depths, different colorspaces, different resolutions, all for free. (Some features for MSU require the paid version). It also has SSIM calculation filter now

It's easy to use, here is an example for the prores_ks. The input file is the test file, in this example the decoded prores_ks 8bit PNG. The movie= is the source file you're testing against. The log file will list the per frame statistics (if you were doing a video, not single image).

ffmpeg -i prore_ks_decoded.png -vcodec rawvideo -vf "movie=SMPTE_Color_Bars_16x9.svg.png,setpts=PTS-STARTPTS[main];[main][ref]psnr="stats_file=prores_ks.log" [out]" -f rawvideo -y /NUL

There are a lot of "gotchas" or things that can skew results. For example, you wouldn't test the prores422HQ 10bit YUV 422 directly against an 8bit RGB source. It should be "apples to apples". A bunch of other variables need to be controlled or at least accounted for when you publish results - such as decoder, method of conversion, chroma plane resizing algorithm, dithering etc... ie. all those other things discussed earlier. Typically compression tests would compare same bitrates too

[SameSelf]

Everything you said above makes perfect sense, thanks. When I think about how much knowledge and experience is embedded in this thread, it blows my mind!

[SameSelf]

FWIW, and from what I can tell, PP treats NTSC DV AVI losslessly when exported as AVI - NTSC DV which is pretty nice when I need to cut up some caps for post-processing outside of PP. Sadly Resolve doesn't read DV AVI, but it does read UYVY, ProRes, etc. So I need to think about a workflow that minimizes generational losses.

[poisondeathray]

FWIW, and from what I can tell, PP treats NTSC DV AVI losslessly when exported as AVI - NTSC DV which is pretty nice when I need to cut up some caps for post-processing outside of PP. Sadly Resolve doesn't read DV AVI, but it does read UYVY, ProRes, etc. So I need to think about a workflow that minimizes generational losses.

PP smart renders DV, so yes - cuts only editing will be lossless. But that's only useful if you're starting with NTSC DV, not some other format.

It also smart renders DVCPro for HD, but it's not full raster (1920x1080i29.97 would be stored as 1280x1080i29.97 ie. horizontally "squished")

Or shoot in dnxhd with your ninja upgrade to CC and it will smart render dnxhd. Or get a mac with cc or fcpx if you need prores smart rendering .

[SameSelf]

Hmmm, "smart render", thanks, good to know the terminology. PP smart renders DVCPro HD but it gets squished? That doesn't seem too smart, not that I have ever come across that codec.

I think I would rather put an ice pick through my eye than sign up for CC even if it smart renders dnxhd. But I need to investigate dnxhd workflows further. OK, have some work to do.

[smrpix]

Any DNxHD unmodified copy to the same DNxHD bitrate, raster and framerate will be a "smart render" regardless of the software used.

[SameSelf]

That is interesting. pdr seemed to imply that wasnt the case in CS6 but maybe cuz dnxhd isn't an option in CS6? I am not at my PC, but I will try to test soon.

[poisondeathray]

Hmmm, "smart render", thanks, good to know the terminology. PP smart renders DVCPro HD but it gets squished? That doesn't seem too smart, not that I have ever come across that codec.

Not Adobe's fault. It's Panasonic's fault. DVCProHD spec means it's "squished". That's the defined format. It's an early I-frame HD professional codec, when HD cameras first started coming out.

https://documentation.apple.com/en/finalcutpro/professionalformatsandworkflows/index.h...tion=6%26tasks

"Smart render" that means segments that don't have any manipulations (eg. no filters) get passed through untouched. So if you only do cuts editing, those specific sections are identical , truely lossless copies. Since those are I-frame codecs, the cuts can be frame accurate. But sections where you have filters, other manipulations (e.g. resizing , cropping etc...) get re-encoded. Re-encoding dnxhd isn't lossless (it's not a lossless codec) . So typically you have segments that are re-encoded, and other segments that get passed through. As you can imagine this speeds up real workflows immensely. Instead of having to re-encode the whole thing, only sections that require it are re-encoded

But beware - Dnxhd is the absolute worst codec in terms of consistency, levels handling between programs. It's perfect on Avid based workflows, but that's it.

That is interesting. pdr seemed to imply that wasnt the case in CS6 but maybe cuz dnxhd isn't an option in CS6? I am not at my PC, but I will try to test soon.

smart render for dnxhd was added in CC. Ice pick here I come

In Premiere Pro CC, additional codecs have been added for smart rendering (scroll down for details).

AVC-Intra in MXF (located in Format > MXF OP1a)
DNxHD in MXF (located in Format > DNxHD MXF OP1a)
DNxHD in QuickTime
ProRes in QuickTime
Animation in QuickTime

http://blogs.adobe.com/kevinmonahan/2012/10/11/smart-rendering-in-premiere-pro-cs6-6-0-1-and-later/

[smrpix]

But beware - Dnxhd is the absolute worst codec in terms of consistency, levels handling between programs. It's perfect on Avid based workflows, but that's it.

Not trying to come off as DNxHD fanboy here -- but the problems with DNxHD handling were quicktime related (gamma shift) and don't appear in non-Quicktime contexts. The last version of quicktime seems to handle it fine as well -- just painfully slow.

[SameSelf]

I guess it is somewhat encouraging that Adobe is improving CC and not just sitting back and collecting monthly rental fees. However, I am really hoping BMD pushes Resolve to the point where I can ditch PP forever which is probably why Adobe can't stand still.

But beware - Dnxhd is the absolute worst codec in terms of consistency, levels handling between programs. It's perfect on Avid based workflows, but that's it.

I keep hearing that although ProRes on Windows has its share of gotchas too, I guess. I just need to test things for myself to see where dnxhd's gotchas are, unless there are some deal killers. The first order of business is of course coming up with some dnxhd color bars. I got to get this sorted out soon though because filming season is about to start in a few weeks and I will have no time once it does.

[SameSelf]

But beware - Dnxhd is the absolute worst codec in terms of consistency, levels handling between programs. It's perfect on Avid based workflows, but that's it.

Not trying to come off as DNxHD fanboy here -- but the problems with DNxHD handling were quicktime related (gamma shift) and don't appear in non-Quicktime contexts. The last version of quicktime seems to handle it fine as well -- just painfully slow.

Good to know. I wonder if these same problems apply to a color managed workflow on a calibrated monitor?

[poisondeathray]

Yes dnxhd inconsistencies occurs on color managed workflows , calibrated monitors to professional colorists. The prores inconsistencies do as well

He's implying that mxf wrapped dnxhd is more consistent than the QT mov variant - that is true - I've mentioned that earlier either in this thread or one of your other threads. But it's far from problem free. It's not only gamma shift, there are hue issues as well in some programs. You can't necessarily blame avid, just like you can't necessarily blame apple for prores handling inconsistencies. Some people do have it working. On a single system. Only to send off in collaborative workflows to have levels, gamma, color all over the place . But it's definitely worth checking out since it's free.

[SameSelf]

So I did a quick test of a DNxHD workflow after installing version 2.7.1. I took my HD color bars TIFF and exported from PP as DNxHD with the following settings:

Color Levels: 709
Alpha: None
Resolutions: 1080p/29.97 DNxHD 220 10-bit

I am not 100% certain, but if there is a chroma shift, it is very small. The bars are certainly not as rock steady as the ProRes HQ bars on the scopes. As an additional test, I filmed a quick clip in DNxHDx on my Ninja and tried to round trip in PP. There seems to be a small luma shift occurring.

Here are my clips. I have to admit, it is a bit of a head scratcher. These are all in a QT wrapper as I couldn't find the Avid codecs listed under MXF. Maybe I didn't look hard enough?

[poisondeathray]

DNxHD/DNxHR MXF comes standard with CC - I don't remember if it came with CS6, probably not. The Avid installer is only for DNxHD MOV (accessed through quicktime API) codecs

[SameSelf]

Even after installing the Avid codecs, I can't find it under MXF. Can you share exactly where you find it in CC? I am looking under MXF OP1a. So I am guessing CS6 doesn't have it.

[poisondeathray]

Even after installing the Avid codecs, I can't find it under MXF. Can you share exactly where you find it in CC? I am looking under MXF OP1a. So I am guessing CS6 doesn't have it.

The installed version is for the original quicktime MOV wrapped DNxHD

It's under "DNxHR/NDxHD MXF OP1a" in AME CC. There is nothing to install, it comes preinstalled. It has it's own category under "format", with a bunch of presets . Probably didn't ship until CC