DI comparison

Comments

Musicvid wrote on 3/9/2017, 11:17 PM

@Musicvid That's because you keep implying it replaced CUDA, and it doesn't. NVDEC & NVENC are specialized components within the GPU now it seems, but the CUDA cores are still there as well, even if they are not used for video decoding and encoding routines.

jabberwocky

Software codec comparisons must be done without acceleration. You want to compare hardware SIPs among themselves? Eagerly awaiting your quantifiable test results, and really try to stay on topic on this forum...

GJeffrey wrote on 3/9/2017, 11:34 PM

Software codec comparisons must be done without acceleration

This is what I did. It seems that you missed one of the post hidden in between the OT one...

I only turn timeline preview GPU on to check fps. The encoding and the snapshot were created with GPU OFF.

CogDiv wrote on 3/9/2017, 11:34 PM

Try to learn a few things and you get thrown moving targets (and random snipes at that). Now who complained about moving targets before? (and so much for that thanks . . .)

Sorry about the OT derailment OP. It seems unbelievable the MagicYUV could be so pristine in comparison to the others. I may have to try a similar comparison, offline, to see what I get.

GJeffrey wrote on 3/9/2017, 11:49 PM

 It seems unbelievable the MagicYUV could be so pristine in comparison to the others

MagicYUV is a mathematically lossless codec, this result is expected.

It's lossless only for 8bits footage with Vegas. As discuss in another topic, 10bits encoding must be hard coded in Vegas. It all depends on the Vegas development team.

Musicvid wrote on 3/10/2017, 12:04 AM

G. Jeffrey,

I have no questions about your tests except those I raised in my first post, and I would really like to focus on those. The "cuda" (actually "red herring") was thrown in to the discussion by a third party.

Did you test Magic in RGB or YUV/YV12 mode? It's not a trivial difference, since you tested it only against other Y'CbCr codecs.

Have you had a chance to test Sony 8 and 10 bit YUV among the other Y'CbCr codecs? They're still kind of the gold standard around here....

Do you know what a Belle-Nuit chart is and what it shows that a scenic photograph does not?

Do you know about available tools for measuring PSNR and SSIM?

Truth be known, I'd kind of like to see someone pick up where I left off ...

https://www.vegascreativesoftware.info/us/forum/intermediates-part-i-seven-lossless-codecs--84932/

;?)

GJeffrey wrote on 3/10/2017, 12:50 AM

Did you test Magic in RGB or YUV/YV12 mode?

In RGB mode. I will do YUV 422 later today.

It's not a trivial difference, since you tested it only against other Y'CbCr codecs.

HDCAM SR 444, Cineform 444 and maybe (not clear in the information i get) ProRes 444 are RGB right?

Have you had a chance to test Sony 8 and 10 bit YUV among the other Y'CbCr codecs? 

Will try later today.

Correct me if I'm wrong, but Vegas works with RGB internally.

So to get a true lossless result (at least seen on Vegas timeline) the encoded file should be RGB right?

I agree with you that RGB and Y'CbCr codecs must be compared separately. I will update my 1st post after testing.

Do you know what a Belle-Nuit chart

I know that. Meaningless word (for such a picture) for a french speaker like me BTW.

I did not use it as i want to test on real life footage. I don't intend to make a 100% scientific test but a real life one.

Do you know about available tools for measuring PSNR and SSIM?

I heard about those tools but i have absolute no clue on how to use them. If you can explain me i will eagerly do that.

 

Musicvid wrote on 3/10/2017, 1:20 AM

Putting yuv on an RGB timeline only maps the colors that are there -- can't replace missing bits any more than you could unbake a cake. 4:4:4 RGB door-to-door is lossless.

If you want a real-world scene for testing codecs, you need some reds with sharp delineations.

If you test Magic in RGB mode, do it against the ones in my link. That was 2011, and we didn't know about MagicYUV yet.

I also intend to test Magic in yuv mode against Sony head-to-head.

Pdf for the MSU VQMT is here (also avisynth and ffmpeg plugs). Free version works with 720p.

http://compression.ru/video/quality_measure/video_measurement_tool.html

 

Musicvid wrote on 3/10/2017, 1:36 AM

Oh, and REC 2020 codecs should be tested only among themselves, I believe.

NickHope wrote on 3/10/2017, 1:37 AM

Thanks for the tests. Been meaning to do something like this myself, so I'm glad someone else has! This was my last dabble with this stuff (I don't think Cineform was freely available at the time).

I'd like to see a column of preview speeds with CPU-only. Also maybe you could consider the Grass Valley codecs.

astar wrote on 3/10/2017, 2:19 AM

Did you try Sony YUV 10bit to a compressed windows folder? That would be mathematically lossless uncompressed codec with less magic.

CPUs are so fast today at compressing and decompressing of file system media.

GJeffrey wrote on 3/10/2017, 3:50 AM

I'd like to see a column of preview speeds with CPU-only

Did you try Sony YUV 10bit

Done. 1st post updated

Musicvid wrote on 3/10/2017, 7:02 AM

Your Sony yuv 10 bit possibly got dithered to 8 bit in Vegas or PS; no such differences registered between the two in my round of tests. Yuv 10 bit should show less banding than yuv 8 bit, even from 8 bit RGB source.

As you can see, the extreme machinations in Potoshop are not necessary; Belle-Nuit shows the relevant differences plain as day right on the timeline... vectorscopes too!

And the winner and still champion is...Sony YUV!

GJeffrey wrote on 3/10/2017, 2:00 PM

And the winner and still champion is...Sony YUV!

You definitely misunderstand what I'm trying to find here.

Yes sonyYUV gives the best quality but at the cost of huge filesize and not realtime preview (at least on my computer).

So it's far to be a champion...

What I'm looking for is the best balance between quality/filesize/timeline preview performance. DI are meant to be edited, if you can't preview realtime, it's basically useless...

CogDiv wrote on 3/10/2017, 2:16 PM

@GJeffrey Sounds like you need a good M.2 SSD to support the higher bit rate codecs. Do you have storage I/O contention when trying to preview the SonyYUV 10-bit file? From the information you have provided so far that looks like a good probability.

GJeffrey wrote on 3/10/2017, 2:43 PM

@GJeffrey Sounds like you need a good M.2 SSD to support the higher bit rate codecs. Do you have storage I/O contention when trying to preview the SonyYUV 10-bit file? From the information you have provided so far that looks like a good probability.

This is what I wrote in the 1st updated post.

CogDiv wrote on 3/10/2017, 2:50 PM

My bad on the SSD requirement. Looks like Cineform 4:4:4 Filmscan 2 could actually benefit from a more powerful GPU OpenCL acceleration of the timeline.

So, is one motivation here to persuade Magix to look into MagicYUV RGB (that can get confusing) 10-bit support for Vegas Pro?

Musicvid wrote on 3/10/2017, 3:39 PM

GJeffrey,

All you have to do is look at my first set of test results (2011) to see that we are interested in precisely the same thing!

It was your initial post that led me to believe you are primarily interested in accuracy. I do see some file sizes, but no render times. If quality were the only thing, irrespective of file size, I would be trying to steer you to those mathematically lossless RGB codecs (which btw handle great on the timeline!), Instead of the best lossy yuv codecs. Make sense?

The best compromise for my purposes then and now remains DNxHD, which has the added benefit of true cross-platform portability. Anxiously awaiting to see what you come up with; please take care to maintain a level playing field across colorspaces and bit depths, including REC 2020..

Size, quality, speed. pick two. Now, about those income taxes...

NickHope wrote on 3/10/2017, 10:26 PM

Thanks for the non-GPU-accelerated preview speeds.

If you wanted to take this further, you could increase the stress on the codecs by adding more FX or compositing. So many of them are still giving full fps preview, so it's difficult to get a comparison.

GJeffrey wrote on 3/10/2017, 11:01 PM

Thanks for the non-GPU-accelerated preview speeds.

If you wanted to take this further, you could increase the stress on the codecs by adding more FX or compositing. So many of them are still giving full fps preview, so it's difficult to get a comparison.


Tested with GPU off only (not relevant with GPU on)

  • MagicYUV YUV444 & RGB preview speed decreases with 4FX (color corrector Vegas) down to 25/26fps
  • MagicYUV YUV422 preview speed decreases with 4FX (color corrector Vegas) down to 28fps
  • HDCAM SR 422 preview speed decreases with 3FX (color corrector Vegas) down to 24/25fps
  • XAVC-I preview speed decreases with 3FX (color corrector Vegas) down to 24/25fps
  • DNxHR 8bits and 12 bits speed decreases with 3FX (color corrector Vegas) down to 25fps
  • Cineform 422 preview speed decreases with 4FX (color corrector Vegas) down to 24/25fps
  • Original h264 file speed decreases with 4FX (color corrector Vegas) down to 27/28fps

 

Musicvid wrote on 3/10/2017, 11:29 PM

Might I suggest, in light of the more recent revelation that timeline performance is really the OP's major concern and issue, that he might actually be far happier with a low tech proxy encoder, rather than a robust digital intermediate solution?

Of course the preview can be optimized, and Cineform previews just dandy on my dual core laptop, but these bad boy encoders were designed with multigenerational application in mind, apparently not at all what the OP is really after.

That said, the bestest, fastest, overall cutest proxy ever is 720p mpeg-2.

Best.

GJeffrey wrote on 3/10/2017, 11:41 PM

apparently not at all what the OP is really after

Jump to your own conclusion which are not mine...

Anyway thanks for your tests, your other posts reflect only your own judgment or are OT...

Musicvid wrote on 3/11/2017, 8:28 AM

I was hoping you were interested in running some controlled tests on first-tier compressed codecs. Sorry that my challenge has met with some defensiveness.

After tabling the project for five years, I may take it up again after feeling piqued by this thread, and the input you've already provided makes for a great start. I also suspect that our motivations, desired outcomes notwithstanding, are indeed quite similar. :-)

Wrt to compression vs. Vegas preview fps, it is often true that highly compressed files are harder on the system than less-compressed files, bitrates being reasonable. Vegas isn't able to use the kind of decoding that say, a media player does, so there's still a case out there for those big avi inters.

I'm particularly interested in seeing some visuals for the 4k codecs; REC 2020. wasn't known back then.

GJeffrey wrote on 3/11/2017, 5:09 PM

So, is one motivation here to persuade Magix to look into MagicYUV RGB (that can get confusing) 10-bit support for Vegas Pro?

No but it would be great if Vegas allowed 3rd party developers to implement custom codec directly like Premiere does (Nvenc or x264) for example.