Posts by dr0

    I just tried to do a multi-resolution export in AME, as was shown in this video tutorial:

    It worked with built into AME H.264 CPU encoder just fine. But, when I tried Voukoder (both H.264 NVENC and a regular H.264), AME was crashing every time I started my render queue. Am I doing something wrong, or is there some kind of limitation in Voukoder / FFmpeg that prevents multiple videos from being encoded at the same time?

    I wanted to see how different source formats compare in 4K. So, for that, I encoded a 1m40s 4K drone video into several different video formats and compared the decode speed of each video with VRPT in PrPro CS6.

    The results almost linearly scale if you compare the difference in fps between formats used in my previous comparison and the number of pixels per frame. The only discrepancy is that unlike with 1856x776, HandBrake Production Max turned out to be slower than ProRes in 3840x2160.

    thanks for answer, for 12Mbit vbr bitrate i must set buffer size=48Mbit ?


    when i set GOP=60 at exported video info not seen GOP size, but i set GOP=30 at exported video info see " format settings, GOP M=5 N=30 " !! maybe not accept more then 30 GOP size?

    i attached image of export video info that i set GOP=30

    Not necessarily. Sometimes MediaInfo just doesn't display certain file properties. To be sure, you have to manually check the distance between neighbouring I-frames in your encodes.

    You can do this with Avidemux, for example. Just press the UP arrow to go forward to the nearest I-frame. You can then count the number of frames between each I-frame (GOP size).

    javad490 you can try to decrease the Max GOP Size, say, to match your FPS value, in order to improve your seek performance. Keep in mind though that this will increase your file size.

    It's probably better to use VBR instead of CBR. I usually use CQP18 as I prefer to target quality rather than file size.

    AFAIK, GTX 1050 does not support b-frames for HEVC encoding, so you might want to stick to AVC with 3 b-frames instead.

    Your RC Lookahead is too high.

    Personally, I wouldn't use b-frames as references, especially for CQP encodes.

    This is the result I got with Premiere Pro CS6 (v. 6.0.5) on my main rig - 244 fps @ 1920x1080:


    I also tested a few different encodes of the same files to better examine Premiere's decode speed with VRPT. For that, I created 5 identical timelines each containing 5 identical video clips without audio, effects, or transitions, with identical resolutions and framerates. The only difference between these timelines was video codecs used to encode said clips.

    Original ProRes 444 LOG source footage (avg. 215 Mb/s-) - 48 fps:

    The same footage encoded with HandBrake's Production Max preset (avg. 127 Mb/s) - 78 fps:

    The same footage encoded with HandBrake's Production Standard preset (avg. 55 Mb/s) - 140 fps:

    The same footage encoded with HandBrake's Production Proxy 1080p preset (avg. 19 Mb/s) - 248 fps:

    The same footage encoded with a custom NVENC CQP18 HQ preset in HandBrake (avg. 5 Mb/s) - 356 fps:

    Interestingly enough, despite the fact that ProRes and Production Proxy timelines were the fastest in terms of forward and backward live playback and playhead scrubbing, due to their I-frame-only nature, it was actually much faster to render an NVENC timeline, which was the only one among these timelines to actually contain all 3 frame types (I, P, B). You might think that this was due to disk throughput (the smaller the videos the faster the render), but all these videos were stored on a fast modern SSD with DRAM cache, and the disk load during rendering was fairly low.


    All the above tests were run with Mercury Playback Engine GPU Accelerated (CUDA).

    I did try to disable CUDA, but, I didn't notice any significant speed change when rendering these effectless/transitionless timelines with CUDA disabled.

    Thanks i dont want VBR.

    Any particular reason you prefer to use CBR/ABR?

    The common wisdom of video encoding is that 1-pass VBR or CRF/CQP are much better solutions in terms of bitrate distribution with sufficient enough encoding speed. If you want a more or less predictable file size, - use 1-pass VBR. If you want to target quality (qantizer), - use CRF/CQP. For best results, you can use multipass encoding, but it's usually not worth the added time.

    It's great that they have finally added (a non-QuickSync) hardware encoding in 14.3. They have also added hardware decoding in a later release, which is also nice.

    But still, Voukoder has quite a few advantages over Adobe's solution, that I can name off the top of my head:

    1) As was already mentioned, Voukoder is more than just an HWA QuickSync/NVENC/AMF encoder for AVC/HEVC, as it supports many other codecs.

    2) As was also already mentioned, it allows for very comprehensive fine-tuning of encoding parameters.

    3) It supports older Premiere Pro versions, going all the way back to Creative Suite.

    4) It can be used in After Effects directly.

    5) It supports various non-Adobe host applications.

    I think it was the first time I actually examined it, I had it opened in Avidemux to tweak something. I was surprised to see there's only P-frames (no B-frames), which in itself isn't a big deal, but even worse, there's no additional I-frames insertion on scene changes.

    Thanks for bringing this up!

    I've been using Avidemux on and off for ages, but only now have I realized that it actually has a current frame type indicator, oh well. Now I won't have to create custom AviSynth scripts for AvsP, or set up a separate installation of MPC-HC/BE with ffdshow output module in order to examine a frame-type-structure of a video.

    The resulting YouTube video looks fine to me. QP27 seems a bit high tho. AFIAK, it is recommended to stay in the range of QP17-QP23 for optimal quality/size ratio. Since your GPU has 7th Gen NVENC, it's justifiable for you to use H.265 instead of H.264. My current GPU has a 6th Gen NVENC, so there's no point for me to use H.265 (without B-frames), since H.264, even with only 2 consecutive B-frames outputs a bit smaller files with nearly the same quality.

    These are my main H.264 NVENC settings for Voukoder and HandBrake: bf=2 preset=slow profile=high qp=18 rc=constqp

    And these are the settings that YouTube recommends to be used for uploads: Recommended upload encoding settings

    Vouk, thanks for such a quick feature update! You're the best!

    I am slightly confused though, why you ask if cineform is already supported in Adobe, has been for several years by now?

    As I mentioned in my original post, I'm still using quite dated Adobe Creative Suite 6 Master Collection, which doesn't have some of the latest features of Creative Cloud. I hadn't updated for so long mainly because CS6 does 99% of what I need, almost never crashes (unlike CC), doesn't require a subscription, and has somewhat lower hardware requirements (compared to the latest CC counterparts).

    The current Voukoder only supports encoders that can be integrated with FFmpeg. Unfortunately the FFmpeg guys decided to not implement it as it doesn't work on any other platform than x86.

    Oh, I didn't know about that. Thanks for pointing it out.

    I am currently working on the Voukoder successor that will support encoders like this one. But there are a couple of months work ahead.

    Nice! I'll be looking forward to it. Any chance that it would still be compatible with CS6?

    Hello everyone! Recently, I discovered Voukoder and was blown away by how good it works with Media Encoder CS6, After Effects CS6, and Premiere Pro CS6. So, first of all, I wanted to say thank you to Vouk for his work!

    It's great that Voukoder has ProRes support but having CineForm in addition to it would be even better in my opinion.

    I tried to encode a few videos into CineForm with VirtualDub2 and noticed that it encodes noticeably faster than ProRes and it gives even better scrubbing preformance in Pro Pro and AE. In term of file size they're close enough.