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
The conversion back from the AVI should use LWLibavVideoSource, because LSmashSource is for MOV/MP4 only, but otherwise it's the same thingCode: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
Code:LWLibavVideoSource("v410.avi", format="yuv444p16", stacked=true) Dither_convert_yuv_to_rgb (matrix="709", output="rgb24", lsb_in=true, mode=-1)
Try StreamFab Downloader and download from Netflix, Amazon, Youtube! Or Try DVDFab and copy Blu-rays! or rip iTunes movies!
+ Reply to Thread
Results 181 to 200 of 200
Thread
-
-
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:
Code:ffmbc -i in.png -color_primaries bt470bg -vcodec prores -profile hq -b 220000k -pix_fmt yuv444p10 -an out.mov
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. -
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.
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 -
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).
Code: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
-
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!
-
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 . -
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. -
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.
-
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.
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 -
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.
-
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.
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. -
-
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. -
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? -
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.
-
Similar Threads
-
MXF export
By Gabes in forum Video ConversionReplies: 4Last Post: 18th Jul 2015, 08:35 -
Export my work in vidcoder
By Cazz in forum Video ConversionReplies: 2Last Post: 13th Jul 2013, 08:10 -
Best Export Method for FCP?
By Jeff_NJ in forum MacReplies: 1Last Post: 4th Nov 2011, 13:12 -
Export DV type 1 with Virtualdub?
By Asterra in forum Video ConversionReplies: 1Last Post: 16th May 2011, 04:10 -
Capture and Export
By Ron's Creations in forum Newbie / General discussionsReplies: 16Last Post: 18th Mar 2011, 18:14