Quote:
Originally Posted by benwaggoner
For Compatibility, deploying compatible encoders, servers, and clients end-to-end is a big lift, and would only be justified if it provided some compelling value. Web Assembly is making web-based decoders a lot more feasible, but don't have DRM support. AVC & HEVC Video codec encode and decode is already built into the hardware of of PCs, Macs, mobile devices, and living room players. AVC and HEVC also have scalable profiles with wavelet-like enhancement layers. Those are supported by a fair amount of hardware and software already, but I've not seen them used outside of videoconferencing applications.
As it is making a AVC or HEVC proxy from a ProRes offers better quality at a given bitrate with broad compatibility. And allows for HW DRM if desired for higher resolutions.
|
There is simply no need for any proxy creation. With good codec this should come "for free". When we create actual master we can create "all other needed bits" as well during 1 process at the very beginning, not keep transcoding countless times later.
Any proxy creation costs time and money. If you have big UHD library (which some companies already do) and a lot of proxy preview needs it actually can be a serious money. We should be able to do it way better.
Smaller resolution preview without reduced data read solves nothing when it comes to cloud storage.
Eg. 10% better efficiency (due to "better" codec) is really irrelevant in such a case. I don't think intermediate codec should be designed mainly with efficiency in mind. This is why JPEG2000 is cool, but not really. For its crazy computational needs it offers not that much more. Finally someone realised it and now we have JPEG2000 HT.
Atm. no one (except Apple) even implemented ProRes decode at smaller resolution (Resolve may be doing it now) even if it's in Apple official decoder as far as I understand it.