New update and new video codecs?

KaraUSA wrote on 9/3/2019, 6:04 AM

Hello everyone, I would like to know when will come the first update of VP 17? When will we be entitled to new video codecs for export? Like the real ProRes in 4444XQ? And many other codecs ... Unlike Adobe, VP is really slow to make new codecs videos, or several codecs for export. I find on VP, codecs are really limited unlike Adobe who puts a big package on it. Why do not you try to do the same thing? Export to DCP, MKV, ProRes (the real one) and not Intermediate Magix (the fake ProRes), and many more ...

Comments

KaraUSA wrote on 9/3/2019, 10:00 AM

?????

Grazie wrote on 9/3/2019, 10:26 AM

@KaraUSA - Yeah, you’d need to hear those answers from a MAGIX Staffer. Us Users no nothing.

KaraUSA wrote on 9/3/2019, 12:21 PM

Thanks @Grazie

Please @VEGAS_CommunityManager 

Musicvid wrote on 9/3/2019, 1:14 PM

How much would you be willing to pay for licensing Apple's proprietary codecs in Vegas?

Adobe subscription prices maybe?

KaraUSA wrote on 9/3/2019, 4:22 PM

For the new version of VP, frankly I thought they could have made an effort on it, but it's a bit disappointing should I say, always the same codecs. In XAVC's we can not even export in 8K while on adobe yes for example.

Kinvermark wrote on 9/3/2019, 5:29 PM

Regarding ProRes: AFAIK, Adobe is the only NLE to offer true ProRes on Windows. And remember, Ppro has an MAC OS version. Clearly Apple is not keen to license this.

But why do you need Prores? Magix intermediate (fake Prores) is apparently tecnhically indistinguishable, so unless you have some sort of legal restriction because you sell to Netflix, then who cares?

This in no way means I disagree with you in general - yes, Magix needs to do more with intermediate codecs. But for now all the "exciting action" is around hardware acceleration of h264/265 - which is, frankly, probably more important to the typical Magix customer.

Former user wrote on 9/8/2019, 5:32 AM

Regarding ProRes: AFAIK, Adobe is the only NLE to offer true ProRes on Windows. And remember, Ppro has an MAC OS version. Clearly Apple is not keen to license this.

Edius Pro supports ProRes Decode and Encode, as well as ProRes RAW Decode.

Assimilate Scratch supports ProRes Decode and Encode.

Fusion Studio supports ProRes Decode and Encode.

All on Windows.

All of those are Apple-Licenced ProRes Implementations..

How much would you be willing to pay for licensing Apple's proprietary codecs in Vegas?

Adobe subscription prices maybe?

One doesn't need a subscription to access this functionality. They just need to evaluate their options.

But why do you need Prores? Magix intermediate (fake Prores) is apparently tecnhically indistinguishable, so unless you have some sort of legal restriction because you sell to Netflix, then who cares?

Because of QA. It may be technically indistinguishable (jury's out on that - hardly anyone uses VEGAS Pro where this is required, so it hasn't really been battle tested in the real world), but it cannot be trusted, because it's not a reliably safe implementation.

This in no way means I disagree with you in general - yes, Magix needs to do more with intermediate codecs. But for now all the "exciting action" is around hardware acceleration of h264/265 - which is, frankly, probably more important to the typical Magix customer.

The exciting Action around Hardware Acceleration of H.264/HEVC happened years ago. All we do these days, is add to it as the hardware generations progress. Hardware Decoding and Encoding is almost a decade old, at this point.

ProRes is needed because it isn't about the Typical MAGIX Customer. It's about the what the customers of professional editors using their software require... and their QA requirements/protocols.

Reverse engineered CODECs are a huge no-no.

MAGIX sells professional software to professionals who sell services/products to their customers, so they have to think beyond one link. Perhaps this type of short-range thinking is why the NLE has such porous CODEC support? A professional NLE not supporting DNxHD/R in the absence of a licensed ProRes implementation is practically unforgiveable.