ProRes support? Need your voice!

Hi, anyone interested in Blender supporting ProRes Video Codec via ffmpeg?

I have commited a patch to enable it - but sergej sharbin isn’t convinced to allow it:

“Further, we really prefer to stick to support of only commonly used interchange video formats to prevent settings from being too much cluttered. So the question here would also be how much commonly used this format for interchange data?”

So i want to hear some opinions…
Or you can drop a line in Patch commit directly.

I really think ProRes would be great to have support for!

If I understand correctly from this wiki page

This codec is basicly designed to speedup the workflow (realtime preview) during video editing. I’m no expert on Blender coding but wont that require a lot more work then including the codec via ffmpeg. Does blender even generate a proxy/temp file of the videos in the VSE?

Does allow Apple Inc. for enabling ProRes codec in blender or another program? I think ProRes codec is closed format? Or it is not need license for it? In windows you can`t write in ProRes codec, quick time not allowing it.

My intention is to have it as an output format, so Blender can render to ProRes.

ProRes in VSE is already supported. Proxy is MJPEG anyway and yes is generated from ProRes too.

I don’t think so. But yes, apple does not have it in Quicktime non Pro. ffmpeg can ProRes - ffmpeg is already in Blender - so it just a matter of enabling it - by 1 Code Line…

pro res can only be read in windows, not written, i think it is a licence matter

did’t know that… Any links on this? But that does not stop me from wanting it - at least for osx. :wink:

EDIT: I think ffmpeg on windows can write ProRes too? Can anyone confirm?

All I know is it was a nightmare trying to figure out how to output to video before that part of blender got cleaned up.

Now it’s just a dropdown list that has all the ‘common’ ones and no need to go googling to determine what codec goes in what container type at what settings in order to put a simple demo up on vimeo.

  1. In countries where the patent applies.
    from link 1

  2. If you want ProRes exports on Windows, you need to talk to Apple. Until then, you will either need to find someone who has a Mac, or export something else.

Personally, I’m in favor of “something else”. The UT codec is very usable on both platforms, and free. (only 8bit support :()
from link 2

  1. The appropriate contact information is here:
    from link 3

  2. Licensing QuickTime for Distribution Selecting the right QuickTime 7 licensing agreement is the first step. Download the appropriate agreement (PDF) at the end of the descriptions below.
    from link 4

i don’t get it. FFmpeg supports ProRes de- and encoding on mac/linux/windows.
Do we get in troubles if we use that?

As it seems ffmpeg prores encoder is only “legal” on mac? Is this true?

If so, we still could enable it for osx, right?

And if ffmpeg is not “legal” on win/linux - if blender enables this - is the party to be sued ffmpeg or Blender???

@ maksat_m, those Licensing thing seems to be about quicktime - i’m not talking about quicktime at all. I’m talking ffmpeg.

I will be happy if ffmpeg with blender will support prores codec, in particular - ProRes 422 HQ and ProRes 444. I will give my voice for it if it is not illegal :slight_smile:

Yeah, the last thing i want is Blender being sued :wink:

But i really want ProRes too :wink:

So what i think doing next is two things:

-Get enough people that wants ProRes.
So please write here if you like to have ProRes support in Blender.

-Figure out the “legal issues” on Windows/Linux.
If anyone knows more about this topic, please please write here.

One way or another i will get ProRes in Blender - even if it’s only on Mac or only in my build.
(Well, i already got it - it’s really just one line change in Blender source Code :wink:

ProRes 422 is essentially JPEG2000 (i.e. 10 bit color) except JPEG2000 uses wavelet technology. Overall ProRes is not that important to me even though I use it everyday on OSX. It makes big files and distorts the RED colors in your image. I have never got ProRes to work on Windows, I’m not sure about Linux. For logo and motion work I always had to ditch ProRes because it changes the brand colors on output.

@Atom, what are you using then?

And is the Red Shift caused by it being Rec709?

I did in a terminal in Linux:

ffmpeg -formats

and there don’t appear the ProRes codec.
In that list to the left of each codec you have “D” and “E” characters. D means it is decoder and E that is is encoder. If you look to some codec and it is only D that means there are legal issues. Decoding is open always, but encoding is what must be resolved legally.

But in Linux (ffmpeg version 0.8.6) I don’t see such a codec “ProRes”.

I am curious what advantage has this format versus other formats? Is because it permits 4K size or because it is quicker reading?

But seems Blender would have to pay money to Apple to enable the codec (all the people would be using blender then to convert their movies to ProRes and I don’t think Apple wants to be so altruistic…

Some info about ffmpeg ProRes for VFX.

@atom, use ffmpeg -codecs
actual ffmpeg version is 1.2
all the people use ffmpeg to convert to ProRes, apple doesn’t care there…

ProRes is proprietary and was originally developed specifically for use in their Finat Cut Pro software.

It is only possible to encode to ProRes on mac systems, others are able to decode only. In my experience since it’s a lossy codec anyway you’re better off using a high bit rate .mp4 instead. This way you’re able to use it cross platform without issues, otherwise it’s just a pain. Of course if you want prestine images or an alpha channel it’s better to use animation codec or image sequences.

As for the possible legal issues, I hear Apple has been known to file a law suit or two:)

MP4 is MUCH more CPU-intesive to encode/decode. In fact, that is pretty much the entire reason for ProRes existing in the first place.

For those not familiar with the format, ProRes is an intermediate editing codec. The idea is you take the various kinds of footage you got when shooting (DPX sequences, H.264, RED, whatever) and convert them all into ProRes, which Final Cut will happily eat (even the old and grouchy FCP 7). You can then edit and do your thing, then encode from this into whatever delivery formats you want. (it also makes a nice format for a “printmaster file” if you need one of those). While it’s lossy, it is designed to be “visually transparent”, meaning the loss from 1-2 runs through the encoder should not be visible. In my experience, it lives up to this. It comes in a few different flavors. The basic 422 version, a “HQ” version which is 422 with extra bit rate, a “proxy” version meant for offline editing, and a 4444 version for alpha channels and color correction.

FFMPEG supports ProRes encode/decode on all platforms nowadays, it is not using Apple’s actual codec, but rather a home-grown implementation. This would be what Blender uses. The legality of this is of course somewhat dubious and varies a lot by country. I don’t think it’s actually any worse than bundling x264 though, which I believe Blender already does. This might have to do with BF being located in the Netherlands, which is towards the lax side on software patents and the like.

ProRes 4444 is meant as a sort of successor to the animation codec and is better in pretty much every way except encode/decode support.

Would being able to export ProRes out of the VSE/compositor be useful? IMO, yes. Sure, you can always render to a PNG or EXR sequence and encode it with something else (Compressor, etc), but being able to do it in one shot is nice and saves a lot of disk space.

Oh, and as a closing note, the purpose and legal issues around ProRes are pretty much identical to DNxHD, which Blender already supports. (ProRes is basically the Final Cut version of DNxHD). Considering Blender supports DNxHD and QT Animation, it seems rather silly to not support ProRes when it can be done just as easily.

Whenever there is a discussion of the benefits of ProRes vs. MPEG-4, the ProRes advocates usually claim that MPEG-4 is optimized for aquisition and distribution but not suitable for frame-accurate editing. They are wrong.

Frame-accurate editing works best with video encoded as intra-frames only, and that’s what ProRes does by default. MPEG-4 video on the other hand frequently uses predictive (P and B) frames to increase compression efficiency. The problem with predictive frames is that they all require an intra-frame for reference. An I-frame and all the predictive frames that depend on it are called a GOP (group of pictures). In order to skip to a particular frame of the video, the computer has to first find the start of the GOP and then decode the intermediate predictive frames leading up to the frame to be displayed. Also, non-destructive cutting is only possible at GOP boundaries, otherwise new I-frames have to be encoded and inserted. These are the things that can make MPEG-4 video editing painfully slow – if you work with material encoded for distribution.

However, the use of predictive frames in MPEG-4 video is entirely optional. If you encode with a maximum GOP length of 1, your video will consist of I-frames only, and you won’t have any trouble editing it. The problem is, whenever something is optional, people need to know what they are doing.

There may be valid reasons to support ProRes, but speed is not one of them.

Ffmbc(ffmpeg fork) has ProRes/DNxHD/Mpeg2 I Frame HD/MJPEG.

If you want to try with those formats EyeFrame Converter is a GUI for batch converting with ffmbc.