A Few Words about my ProRes Encoder

Some people wanted to have ProRes encoder in Libav so I wrote one. And from what I gather it even has one user (not me).

In case someone is interested here is the list of possible options:

  • profile — selects ProRes profile to encode (proxy, lt, standard or hq)
  • quant_mat — selects quantisation matrix from one of profiles (proxy, lt, standard or hq). If you don’t specify it, the matrix will be picked from default profile (or use auto to be really sure). There’s also default matrix which should give the highest quality (it’s default in the sense that when quantisation matrix is not provided in frame decoder defaults to this one).
  • bits_per_mb — how many bits to give for coding one macroblock, different profiles use from 200 bits per macroblock to 2400, one can set it up to 8000.
  • mbs_per_slice — how many macroblocks are there in slice, 1-8. Default value of eight should be good for almost all situations though.
  • vendor — one can put custom vendor ID into frame like apl0 to claim it was produced by Apple encoder.
  • qscale — set fixed quantiser

How to make it encode faster?

In default mode of operation encoder has to honour frame constraints (i.e. not producing frames with size bigger than defined) while still making output picture as good as possible.
If the frame contains lots of small details it’s harder to compress it and encoder spends more time in search for appropriate quantisers for each slice. Thus setting higher bits_per_mb limit will improve the speed.

Or if you don’t care about frame size constraints just set qscale parameter to something (I’d recommend 4) and see it encode MUCH faster.

Feel free to leave wishes for features in comments, hopefully I can implement it when I have time.

P.S. For proper 4444 profile support we need 10-bit YUV with alpha. When it’s in I can add that profile too.

23 Responses to “A Few Words about my ProRes Encoder”

  1. jlucas says:

    “For proper 4444 profile support we need 10-bit YUV with alpha.”

    Is this a large or small undertaking? Has this been on the wishlist for a long time? Is it likely to happen in the near future (i.e. within a couple months?). For someone not familiar with the libav codebase, what source files would need to be touched to enable this?

    Thank you for your work!

  2. rick says:

    I use the prores feature in libav now! So, I am a second user, and thank you very much. I record content in Huffyuv and convert it to Prores for our video editor to utilize in Final Cut Pro. An error is given upon import, but the video is functional in Final Cut. I have come to understand that the encoding is also limited to a single thread. Hopefully multi-threading will come sometime.

  3. compn says:

    after the prores encoder is in, somehow a lot of windows video converting programs also got support for prores. must be coincidence.

  4. xr4y says:

    Thank you so much for your hard work Kostya, really appreciated, this is a game changer, a milestone, THANK YOU!

  5. longbowrocks says:

    This is wonderful, but I can’t seem to find the repository you committed these changes to. Am I missing something?

  6. longbowrocks says:

    Oops, I was actually interested in your SMPTE 302 patch for libav at http://patches.libav.org/patch/20184/ . Sorry about that!

  7. roger says:

    So do the ffmpeg/libav guys know about the lack of 10 bit YUV with alpha? Just trying to figure out how to use it with 444 … ffmpeg does have yuv444p10 now… or does this work with 444 now?

    ffmpeg -i input -vcodec prores_kostya -pix_fmt yuv444p10
    seems to take…
    Thanks!

  8. bob m says:

    I’ve been playing with ffmpeg and all 3 ProRes encoders (prores, prores_anatoliy, and your prores_kostya) and am having trouble with the movies they generate. They don’t play back smoothly on Quicktime Player for Windows, often freezing (in the case of the ‘prores’ encoder it can cause QT Player to freeze completely) and have trouble playing back in other apps as well.

    However I can scrub through the movies fine, or even frame-step through the entire thing with no problems. But there’s just something “off” about them that cause apps not to be able to play them correctly. If I re-save the movie from QT Player Pro self-contained (so, no recompression) the resulting movie DOES seem to play through smoothly in Quicktime Player but still not in other apps.

    Any ideas what could be “off” about them?

  9. bob m says:

    Upon a bunch more investigation, it seems like it’s actually the audio tracks ffmpeg is making that is the cause of my angst. Doing video only seems to work flawlessly! So you can pretty much ignore my previous comment 🙂

  10. Jeremy says:

    Hello..

    Thanks so much for this. I just downloaded this as it’s part of the newest ffmpeg download. I’m running Windows so it’s great to have this.

    Just a few quick questions I’m hoping that you could help me with. I need the ability to create ProRes 444 Quicktimes (don’t nessesary need an alpha.. but wouldn’t hurt either). I work with footage that was shot on Red so I want to keep the bit depth as high as possible.

    I was looking at Apple Pro Res has a bit depth of 12 and I need to maintain this.

    http://en.wikipedia.org/wiki/ProRes_422#ProRes_4444

    I also work in full HD @ 25FPS so I assume that I would need a data rate of 275 Mbps according to this

    http://documentation.apple.com/en/finalcutpro/professionalformatsandworkflows/index.html#chapter=10%26section=4%26tasks=true

    I’ve tried to encode a few clips and I get the error

    Error: No supported pixel format found for codec prores_kostya

    If someone could please help me with this it would really be apprciated. If I can get this working on Windows reliably it will be massive help.

    Thanks for all your work.. this is really very cool.

  11. v0n says:

    Few questions, I hope you don’t mind.

    First, question regarding -vendor flag. I have a problem playing back prores files made with ffmpeg through some capture/master-to-tape soft, like Media Express 3.2 for Blackmagic cards. The only two differences between prores files made with QuickTime and files made with ffmpeg as far as I can see are the “encoder” (or “writing library”) entries in mov headers (all files made with ffmpeg have a header of Lavf(version)) and QT Format/codec atoms, which in ffmpeg files are limited to encoder name (prores,prores_kostya) rather than full “Apple ProRes 422 (HQ)” entires as created by QT. I was hoping -vendor apl0 would be the answer, but unfortunately, specifying -vendor apl0 doesn’t seem to make any difference in neither latest git, nor ffmpeg 1.0 – encoder in ffprobe and “writing library” in mediainfo is still indicated as Lavf(version). Have I misunderstood what -vendor flag does or….?

    Second question I have – interlaced ProRes. I think I saw somewhere that this was being worked on some time ago, but I can’t find a way to force correct interlaced header in mov in current git or stable releases, adding -flags +ildct+ilme doesn’t seem to be doing anything, picture is interlaced, but mov header still says file is Progressive. What am I missing?

    Additionally, neither of the current prores encoders in ffmpeg git seem to be setting correct SD/HD values to colr and nclc atoms in mov, which in turn is often causing gamma shift in programs using quicktime pro 7 libraries to read the files. Is there any way to address this?

  12. Kostya says:

    @v0n

    For all your questions – encoders control only what’s written inside the frames and don’t (and probably cannot) affect MOV properties in the way you want. Sorry.

    Maybe somebody will write a patch to address all this.

  13. kris says:

    Hi there, I just found your blog because i desperately try to convert a apple pro res file into something else like DNxHD. I m on a linux machine and usually use winff as a gui for ffmpeg, but here it doesnt really work, I get the answer:

    “[prores @ 0x97567e0] alpha channel not implemented. Update your Libav version to the newest one from Git. If the problem still occurs, it means that your file has a feature which has not been implemented”

    Someone more into Video might know what this means 😉 thanks!!!

  14. Kostya says:

    @kris
    That means it uses some old version of avconv and you should either try the newest version of winff in hope that it has newer version bundled or find somewhere a newer Libav build and replace the binary it uses. Or simply use avconv directly.

  15. kris says:

    thanks so much! I try to update my ffmpeg right now…

  16. kris says:

    It works, beautiful, somehow my ffmpeg wasnt up to date and adding this ppa to my repos
    https://launchpad.net/~jon-severinsson/+archive/ffmpeg

    did the trick! Thanks for your help! 🙂

  17. Andeh| says:

    Hey Kostya,

    I’m using a windows version of FFMpeg compiled by zeranoe and I’m just wondering if there is anything stupid I’m doing that’s causing the Alpha channel to be lost on a ProRes 4444 MOV.

    I’m trying to make a 4444 MOV from PNG files. The PNG’s definitely have an alpha mask and everything generates fine if we use FCP etc. to do the conversion.

    Command I’m running is:
    ffmpeg -i “c:\Cube%04d.png” -vcodec prores_ks -pix_fmt yuva444p16le -quant_mat hq -alpha_bits 16 -vprofile 4444 “c:\cube_output_test.mov”

    Any help would be AMAZING! Thanks in advance!

    ac

  18. Kostya says:

    @Andeh|

    -pix_fmt looks wrong – it should be -pix_fmt yuva444p10le
    I’ve tried encoding with avconv and it all worked fine:

    avconv -i http://upload.wikimedia.org/wikipedia/commons/4/41/Wilber-huge-alpha.png -c:v prores -pix_fmt yuva444p10le -quant_mat hq -alpha_bits 16 -vprofile 4444 1.mov

  19. Andeh| says:

    @Kostya

    If I run this :
    avconv.exe -i “c:\Cube\results\Cube%04d.png” -c:v prores -pix_fmt yuva444p10le -quant_mat hq -vprofile 4444 -alpha_bits 8 “c:\Cube\Cube_output_test.mov”

    I get:
    avconv version 9.7, Copyright (c) 2000-2013 the Libav developers
    built on Jun 16 2013 19:51:26 with gcc 4.7.2 (Gentoo 4.7.2-r1 p1.5, pie-0.5.5)
    Unrecognized option ‘alpha_bits’.
    Error splitting the argument list: Option not found

    If I remove the -alpha_bits argument I get:
    avconv version 9.7, Copyright (c) 2000-2013 the Libav developers
    built on Jun 16 2013 19:51:26 with gcc 4.7.2 (Gentoo 4.7.2-r1 p1.5, pie-0.5.5)
    Input #0, image2, from ‘c:\Users\gbcopelan\Desktop\Cube Vibrate\results\Cube%04d.png’:
    Duration: 00:00:03.64, start: 0.000000, bitrate: N/A
    Stream #0.0: Video: png, 800×600, 25 fps, 25 tbr, 25 tbn
    File ‘c:\Users\gbcopelan\Desktop\Cube Vibrate\Cube_output_test.mov’ already exists. Overwrite ? [y/N] y
    [buffer @ 0000000004B72F60] Invalid pixel format string ‘-1’
    Error opening filters!

    I have a feeling it should be easier than this and I’m just being a fool! lol!

  20. Kostya says:

    Too old version obviously – alpha support in ProRes is supported only by current git HEAD and upcoming version 10. Maybe the same command line will work fine with your FFmpeg (I don’t use it so I cannot say anything).

  21. PickleJones says:

    Thank you so much! I just started using ffmpeg because it seemed the only option for encoding prores files on a PC. Thank you thank you! Could you give some tips in your original post as to what values do what in the qscale and cqp? Better encoding/ smaller files? Thanks again, first time user and I’m just so happy to find something that works.

  22. Kostya says:

    My encoder doesn’t have cqp parameter but I suspect it does on some other encoder what qscale does on mine (e.g. sets quantiser). And it works quite intuitively: the smaller quantiser the better quality and the larger files, the larger quantiser the worse quality and the smaller files.