MagicYUV codec coming on strong for 4K

Comments

Nick Hope wrote on 12/14/2016, 8:22 PM

How about the Quicktime MagicYUV codecs, which are also installed? Can they render 10/12/14 bit in Vegas?

ignus wrote on 12/15/2016, 1:18 AM

Hi all,

I'm the developer of the MagicYUV codec, just thought I'd tune in to the discussion, in fact I was more or less following this thread since the Sony days.

In any case, it is unfortunate that Vegas cannot send 10bit+ data neither through VFW nor QuickTime.

I had a lengthy discussion with a Vegas developer 2 years ago, and he also confirmed that 10bit+ data paths are handled specially.

Actually, transfering 10bit+ data through VFW should be easily possible to do. The main reason I believe it is not done is probably a lack of agreed upon fourcc/pixel format for 10bit+ data and/or architectural difficulties inside Vegas. v210 (nicknamed in Vegas as the Sony YUV "codec") is one option for 10bit YUV 4:2:2 transfer, but there are 2 fourccs already in place in other programs (ffmpeg, VirtualDub Filtermod, AviSynthPlus) that could be used for 16bit RGB transfer: "BGR0" ie. BGR[48] and "BRA@" ie. BRA[64].

If Vegas development could be convinced to implement presenting these formats to VFW, deep color compression with MagicYUV (and possibly other VFW codecs) would work now right away.

It is a bit of a chicken-egg problem I believe: there is no incentive to add support until the need arises from the community (ie. MagicYUV 10bit+ files waiting to be imported), but the community cannot raise the need, as there is no way to create MagicYUV 10bit+ files from Vegas in the first place.

Balázs

ignus wrote on 12/17/2016, 1:18 PM

So, does anyone have an idea how to go about convincing Magix to implement deep color transfer support to generic VFW/QT codecs?

Kinvermark wrote on 12/17/2016, 9:11 PM

Write a letter to ******* in Madison Wisconsin.  He is the product manager.

Nick Hope wrote on 12/17/2016, 10:31 PM

Sorry, publishing or mentioning the names of MAGIX employees in your posts is not permitted (Community Rule #9). I will attempt to pass the message on to the product owner.

Kinvermark wrote on 12/17/2016, 11:35 PM

Oh, sorry, his forum name is ********.  Sorry I added a space. 

His identity and position are public knowledge and his forum name is hardly a pseudonym.

NickHope (is this how you prefer to be adressed?), have I offended you in some way?  Because what you just did was both unecessary and seems a little sharp.

Nick Hope wrote on 12/17/2016, 11:43 PM
NickHope (is this how you prefer to be adressed?), have I offended you in some way?

Not at all. Just following my instructions as a moderator.

Red Prince wrote on 12/18/2016, 12:05 AM

Because what you just did was both unecessary and seems a little sharp.

Really? To me, Nick is the ulltimate nice guy.

He who knows does not speak; he who speaks does not know.
                    — Lao Tze in Tao Te Ching

Can you imagine the silence if everyone only said what he knows?
                    — Karel Čapek (The guy who gave us the word “robot” in R.U.R.)

Wolfgang S. wrote on 12/18/2016, 2:10 AM

Back to topic. I do not see any need for the MagicYUV codec in Vegas at all. One can use Cineform but also XAVC I for 10bit, and especially Cineform works great in Vegas.

Nick Hope wrote on 12/18/2016, 2:16 AM

MagicYUV is lossless. Cineform and XAVC-I aren't.

ignus wrote on 12/18/2016, 9:41 AM

Thanks Nick, if you pass on the info that would be great! I await the results.

Kinvermark wrote on 12/18/2016, 11:30 AM

Because what you just did was both unecessary and seems a little sharp.

Really? To me, Nick is the ulltimate nice guy.


Yes, of course.   Just a little mis-understanding on my part about how MAGIX view the forum rules. I think rule #9 needs a little embellishment for practicality, but I will still respect the rule as it stands.

I use and like Cineform, but having choices is best.  You can't send cineform to handbrake, for example, and you never know how long GoPRo will keep it in develpoment.

ignus wrote on 12/18/2016, 11:59 AM

I use and like Cineform, but having choices is best.

Exactly. I'm advocating for supporting deep color transfer through generic codec interfaces, that would allow not just MagicYUV to encode at higher bit depths, but any other codec implementing the interface.

Red Prince wrote on 12/18/2016, 2:06 PM

I use and like Cineform, but having choices is best.

Exactly. I'm advocating for supporting deep color transfer through generic codec interfaces, that would allow not just MagicYUV to encode at higher bit depths, but any other codec implementing the interface.

As far as I’m concerned, such a generic interface would have to pass the data as 32-bit floats, and the codec would then convert them to whatever bit depth it needs.

He who knows does not speak; he who speaks does not know.
                    — Lao Tze in Tao Te Ching

Can you imagine the silence if everyone only said what he knows?
                    — Karel Čapek (The guy who gave us the word “robot” in R.U.R.)

Wolfgang S. wrote on 12/19/2016, 8:13 AM

MagicYUV is lossless. Cineform and XAVC-I aren't.

Fun answer: if you see the difference then you have great eyes! ;)

More serious: it is not true that the use of any intermediate codec is lossless really. At least there is the step to decode the camera footage and encode it in the intermediate codec (and this step is not loseless). The advantage of all the intermediate codecs is that - after you have transfered your footage in the intermediate codec, the loss when rendering generations of the footage becomes small. But you are not able to avoid the initial loss. So it can be better to avoid any loss due to the first conversion and to decode the original footage immediately - if that is possible from your workflow side.

Beside that: all the intermediates are of interest for an high-end workflow mainly, where we adress 10 bit or higher. Given the fact that we will not see a 10bit implementation for MagicYUV in Vegas very likely, for me it is quite clear what codec I will use. For 8bit I would not go into the effort of huge intermediates at all, as long as I am not forced due ot a lot of render generations I would try to stick to the original footage (and all what is called H.264 preserves the picture quality in a great way, as long as we render again to H.264).

Nick Hope wrote on 12/19/2016, 9:32 AM

Thanks Nick, if you pass on the info that would be great! I await the results.

I can tell you that the request has reached the place it needs to and is at least in discussion. Doesn't mean to say it will happen of course! Could you PM me your email address and I'll pass it on in case the devs wish to contact you?

More serious: it is not true that the use of any intermediate codec is lossless really. At least there is the step to decode the camera footage and encode it in the intermediate codec (and this step is not loseless).

If I compare a video rendered by MagicYUV (e.g. 8 bit RGB) on the timeline with the original MP4 or whatever, not a single pixel moves on any scope. So how is this not lossless?

david-tu wrote on 12/19/2016, 10:11 AM

A scope doesn't show you every pixel so that is not necessarily accurate, but if you don't see any visual changes and the scope matches the original, then it could be considered visually lossless. I don't know if it is mathematically lossless or not.

Wolfgang S. wrote on 12/19/2016, 10:52 AM

The comparison should be done with difference pictures, and the noise brougth in by any step can be quantified. If you do that you will find that the decoding and the encoding from one (not loseless codec) to ANY other codec will deliver some noise. I have done those tests years ago with both Cineform and the Canopus HQ codec. That is why a workflow with an intermediate may makes limited sense only in terms of quality, as long as you do not need more than one render generation. This is why Vegas never added an more explicit intermediate workflow.

wwjd wrote on 12/19/2016, 11:02 AM

Magix should add higher bits to Vegas because ALL of its pro competition has already done so. With the new cameras recording higher bits for lower prices, its become sort of manditory.

Marco. wrote on 12/19/2016, 11:52 AM

MagicYUV is mathematically lossless. It is not reconstruction of pixels/macroblocks, it is identical bit reconstruction. In a certain way similar to ZIP compression.

Nick Hope wrote on 12/19/2016, 9:11 PM

The comparison should be done with difference pictures, and the noise brougth in by any step can be quantified. If you do that you will find that the decoding and the encoding from one (not loseless codec) to ANY other codec will deliver some noise.

Method: Original UHD footage on upper track, compositing mode set to "Difference", rendered footage on lower track.

MagicYUV RGB 8-bit:

Cinform Filmscan2 (least lossy of the Cinform codecs):

GJeffrey wrote on 12/19/2016, 9:39 PM

I have been testing this codec recently and my results match Nick's pictures.

This is valid as long as no fx is added, as soon as 1 is added, some pixels change (may be due to rounding error).

If one wants true lossless encoding, no choice but using a lossless codec and encoding as RGB, which Cineform or Canopus (among others) are not.

john_dennis wrote on 3/26/2018, 2:15 PM

Today, I bought a license for MagicYUV 2.0 Standard.

1) The ground is too wet to mow the grass.

2) I've spent more time, of late, working with external encoders.

I'm happy.

JN_ wrote on 6/18/2018, 9:34 AM

Article on making Cineform available in Vegas plus the GoPro software download link.

I haven’t been able to use Cineform up to now because I couldn’t find the software download, this now solves it.

https://www.moviestudiozen.com/free-tutorials/sony-vegas-pro/592-render-cineform-video-from-vegas-pro-movie-studio

Also article on Zen site for frameserving to handbrake.

https://www.moviestudiozen.com/free-tutorials/sony-vegas-pro/590-render-video-from-vegas-pro-to-handbrake

Last changed by JN_ on 6/18/2018, 9:38 AM, changed a total of 1 times.

Desktop and Laptop basic specs ...

Both run Win 10 ...

Running latest ver. of Vegas Pro with latest updates

Vegaseur and Pluraleyes installed on both ...

PC ...

CPU .. Haswell Core i7-4790K. Intel® HD Graphics 4600

Changed i7 to i9 9900K Nov. '18. Intel Graphics 6300

Memory .. 16GB DDR3.

Changed to 32gb DDR4 Nov. '18.

Graphics card .. Nvidia MSI GTX 1080 Z.

Nvidia Graphics driver 4.1694

Intel Graphics driver 6373

 

Laptop ... (Acer Predator G9-793-77AC)

CPU .. i7-6700HQ Skylake-H

Memory ..16GB DDR4 

Graphics card .. Nvidia GTX 1070, driver is 4.1722