Beiträge von urik

That's pretty solid advice by visionicloud above. If you want to reach a specific target size, VBR with tight (close) target/max bitrate ratio (or just same value) or even CBR mode are the way to go.

You can even calculate, let's say you want 600mb for 1hr, then

total bitrate = 600mb * 8 = 4800Mbit

total seconds = 60 * 60 = 3600 seconds

target bitrate = 4800/3600~=1.33Mbit/s. Subtract audio whichever audio bitrate you use from that, and you got your video bitrate.

The Constant Quantizer strategy is quality-based. Meaning it will select bitrate to achieve desired quality.

So it depends on how much detail/movement there is in the video; so in regards to video games, if it's slow paced and with little movement, then result bitrate will be low; but try a fast-paced fps or racing and it'll go through the roof. Did the content of your footage change lately?

I'd say that for level 23 CQP your result seems about right. 6Gb per hour equates to about 13Mbit/s bitrate, which for 60fps I'd say is somewhat medium even for HEVC.

Were you using voukoder before too? It has changed a lot in past year, perhaps earlier versions might've used different settings.

Zitat von Vouk (Daniel)

Did you try 7rc2 already?

I did install it yesterday, but didn't specifically test yet in regards to fixes.
I did just now. Exported to UtVideo (420) .avi, and h264_nvenc to VBR

bitrate 150M / max 250M/ bufsize 500M , all is fine.

On a side note, one thing slightly bothered me, is when you switch audio to AAC from another codec, when it's "initialized", the dropdown menu defaults to first entry of 96kbit/s. I realize it happens because GUI dropdown defaults to first entry, but is it possible to make it default it to something like 320?

This might be not a bug but intentional limitation. So, I installed Voukoder 7rc1 (7.0.113) today and was in the process of selecting some VBR settings for nvenc export that were previously loaded from a preset. My buffsize was previously set to 500000 kbit (500Mbit), and it seems the newer version didn't load it so it seems to have reverted to default 15000. When trying to change it, I was getting an error window saying

..\..\src\propgrid\advprops.cpp(271): assert ""Assert failure"" failed in wxPGSpinCtrlEditor::CreateControls(): SpinCtrl editor can be assigned only to numeric property 

And soon later Premiere crashed. I didn't notice anything in particular in voukoder log. The version I was using before when I made the preset with 500000 kbit -buffsize preset was Voukoder 6 (6.0.85). So I went back to last stable v6.2 release, now I notice it won't allow me to input a value above 288000?

Now, I've only recently started using that value since I've read somewhere it should be 2x of max bitrate. I don't know if it's ok to set it that high but I haven't had problems with it in ffmpeg + nvenc.
My current driver is 257.30 and I've verified that I can export h264_nvenc with Voukoder 6.2 just to eliminate possible issue on my end.

It's possible I'm just misunderstanding something, or there's some ffmpeg/nvenc limitations or dependencies on other settings. But I didn't fun into this on 6.0.85

edit: I'm sorry, it probably was always this way. So when saving the preset in V6.0 it didn't get saved as -buffsize 500000 but got reset to 15000. I can't verify inside .epr file itself but probably so.

Tested, works fine, speed wise seems to be same as ffmpeg (well, obviously).

When I tried to encode a 3834x2120 ("bad" width) file it failed - which is to be expected since cfhd just fails to initialize with such files. It does actually produce a red error output within ffmpeg

[cfhd @ 000001b782e22dc0] Width must be multiple of 16.
[cfhd @ 000001b7829e6300] ff_frame_thread_encoder_init failed

Opening codec: cfhd with options: quality=high
Failed opening codec: cfhd
Unable to open video encoder: cfhd
Closing encoders ...
Opening encoder failed! Aborting ...
0000000066E56DD0

I don't know if passing some critical errors from ffmpeg is possible, but it might be useful sometimes.

On a side note, UtVideo works too and seems to be the same speed wise as the official installable VCM codec. It does normally utilize .avi container though, which I understand isn't currently supported in voukoder.

My bad, I didn't realize it's not in official release yet. The one I have installed at this point is ffmpeg-20200818-1c7e55d-win64-static , it's a git windows build by Zeranoe but they don't build anymore now. I just tried latest Gyan.dev git build (ffmpeg-git-full) and it has the encoder too.

Encoder cfhd [GoPro CineForm HD]:
General capabilities: threads
Threading capabilities: frame
Supported pixel formats: yuv422p10le gbrp12le gbrap12le
cfhd AVOptions:
-quality           <int>        E..V...... set quality (from 0 to 12) (default film3+)
film3+          0            E..V......
film3           1            E..V......
film2+          2            E..V......
film2           3            E..V......
film1.5         4            E..V......
film1+          5            E..V......
film1           6            E..V......
high+           7            E..V......
high            8            E..V......
medium+         9            E..V......
medium          10           E..V......
low+            11           E..V......
low             12           E..V......

Speed wise, on my pc it's definitely slower than Media Encoder when converting from h264 (and I made sure to disable hardware decoding in Adobe), about 60%.

There is a quirk with Cineform that it requires the frame width must be evenly divisible by 16 and the frame height by 8. Adobe converts the file anyway even if source doesn't adhere to this rule, but rounds the width to closest appropriate value by adding tiny black bars. For some reason, it doesn't mind the height being not /8. But I've had issues before when video players of youtube would add a black or colored bar to fill the height gap. Not sure if it's an issue still.

FFmpeg's cfhd just flat out rejects the input with "bad" width and stops with error. Just like Adobe, it seems to not mind the height not being /8.

Zitat von dr0

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.

I do like Cineform too. For me, it still performs fastest to live playback in Premiere. Even the proxies in lowest quality look so decent I've to look closely to notice difference from full-resolution original. I've tried DNX for a while but went back to cineform again. Prores is the hardest to playback, I find.

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

I also VirtualDub2 from time to time, including cineform. It seems it hasn't been updated for a while, so I've some doubt if it will continue on. My problem with it was its command line usage is quite cumbersome compared to something like ffmpeg. I got it to work before, but then since certain version it for some reason just refused to work anymore.

I mostly use Media Encoder to transcode to cineform. I experimented a bit with a custom "cfenc" binary some guy F1nkster/marksfink wrote, but since FFMPEG added cfhd I've been using that.

Zitat von Daniel

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.

They added cfhd encoder a while back, in August. I haven't noticed issues with it in my experience so far. Unless I'm misunderstanding something.

Zitat von Vouk

That might explain why the Adobe NVENC Exporter is faster than Voukoder.

It's not for me, it's been pretty much the same speed wise.

I actually had some irregularities with Premiere's native nvenc export when it first came out in 14.2 where it would sometime pick QuickSync over Nvidia, but it seems to have been resolved with later updates.

Did you run your tests before you released the 1.4.0 Premiere connector that resolved the speed issue? I've been using vouk 1.1.3 prior to that and then the new one since connector fix came out, for me they're both take same time as Premiere's export. I still use both, v5 normally and v1.1.3 if I need to quickly tweak parameters without digging into ui.

So for me Premiere nvenc export doesn't in any way make voukoder nvenc irrelevant, with all the additional encoder options it has, CQP, + mkv/mov format for non-mp4 spec audio, to name a few.

Zitat von Vouk

What about the NVENC hardware encoders in Voukoder?

Yes, as I've mentioned, Voukoder does add scene cut I frames and B frames (as these settings are on by default in voukoder, along with lookahead).

I was just ranting about Adobe exporter. Perhaps they use a faster preset or don't pass any parameters to nvenc other than target bitrate and GOP interval.

So yesterday for the first time I had a look at a h264 file exported natively with Hardware Encoding (GTX1080Ti).

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. With enough bitrate it probably wouldn't matter that much, but still, it's just not effective quality wise to me.

Adobe's software encoder and Voukoder (by default) do add those I-frames.

So essentially Premiere hardware encoding reminds me of Nvidia's Shadowplay screen capture, just with probably higher preset, adjustable bitrate and GOP interval.

Zitat von Vouk

The native encoder renders both video and audio streams separately and then muxes it at the end to an mp4 file.

Voukoder directly writes a muxed file.

Oh right, indeed I noticed it write streams like that, one then another. Makes sense. Voukoder also spends time moving the faststart atom, but I guess it was faster on my short test export, I dunno. I know it pretty much depends on disk read/write performance at that point.

Wonderful! Thanks Vouk for fixing the Premiere connector. It is indeed as fast as v1 now. Also it's grown leaps and bounds since then, with match setting checkmarks, separate configuration window, etc. Looking forward to using publish tab, since with v1.1.3 I had to resort to timers & macros to make chrome upload file when it's done exporting. I'm glad you've added the default good quality preset, since I always forget which encoder preset/profile to use for that.

Zitat von kobol

Yep. I confirm it is as fast as Version 1, but the new H.264 native support is faster than Voukoder now.

I can't quite get behind that, since for me they work at pretty much the same speed. The first thing when PP 14.2 came out I did was tested hardware encoding against vouk 1.1.3 , and now I've re-tested with vouk 5 with 1.4.0 connector. I only tested 1 minute as usual, both in media encoder and premiere, the encoding task finishes at roughly the same time.

Interestingly, for me, Premiere native export takes longer time to assemble (finalize) the mp4 file, even though both PP and my vouk settings use faststart.

At first I thought it can be due to bitrate difference that occurs due to the fact that I'm using CQP mode with vouk, but even with twice the bitrate, vouk finalizes test file faster. Maybe there's some extra time PP takes writing some metadata or processing something.

This may be isolated to my test export, I can't statistically confirm it yet.

May I ask, what's the logics behind choosing RC lookahead of 16?

Is it related to max GOP distance or framerate?

I'm using the same value that max GOP just because I've read somewhere that going higher than GOP distance is pointless. But I'm always forcing max GOP of 1/2 framerate, e.g 30 for 60p or 25 for 50p, as per Youtube guidelines (I am keeping the auto-keyframe on scene change on though).

Vouk's right about height divisible by 8 requirement (and width divisible by 16). It has to do with macroblocks & compression.

You might get away with resolution that doesn't adhere to these requirements, but it's a bit of a lottery.

Depending on the codec, format and how Youtube's ffmpeg-based encoder processes it, it might end up with a green line too.

I've bumped into this issue myself a couple years back with Cineform codec, which requires width/16 & height/8 rule otherwise it gets that bottom line when played back in anything but Adobe.

3840x1600 is a good choice, it's 2.40:1 which is pretty much the same as 2.39:1 cinemascope (which is just a legacy of analog film/projection era)

21:9 is just a marketing number used for monitors and phones. The existing ultra wide resolutions in things like consumer monitors aren't exactly 21:9 and they still adhere to the rule, like 2560x1080 (2.37:1), 3440x1440 (~2.39:1) and 3840x1600 (2.40:1)

In cinema mastering / intermediate , they don't have to care about conforming to standard resolutions because it's exported as separate frames.

But when delivering, they adjust it to meet requirements.

Zitat von Rushmed

Which file did you copy?

The Voukoder.dll?

VoukoderR2.prm is the export plugin (connector). It goes into C:\Program Files\Adobe\Common\Plug-ins\7.0\MediaCore

(I'm not sure about pre-CC versions though).

If your connector installation ran correctly, it should've installed the .prm in the correct folder.

try

% LOCALAPPDATA% \ temp \ voukoder.log

(edit: hm, annoyingly, forum engine keeps adding spaces even with code tag)

You're not the only ones noticing this. According to this thread, Vouk is aware of this.

There's not much else to say at this point.

I myself use 1.1.3 for now; interestingly, since Suzerain mentioned 1.2.1, I might try that version too.

edit: avoid 1.2.x versions, they have issue with AAC export

I think you'd have to specify "how" exactly it doesn't look good, and what is your criteria. Also it depends on the quality method - CQP (constant quality), CBR (constant bitrate) VBR (variable bitrate).

The default setting is CQP with value of something like (23?). You could try lowering it to like 16 (lower=better), see if that makes it better. I use variable bitrate with 100mbps target / 130mbps max and keyframe interval of 30 frames (fixed GOP / no scene change detection ); but my footage is gameplay at 60fps so it's different from your scenario. For camera footage at 24fps, even 60-80mbps for 4K is plenty (Youtube's own recommendation for 4K uploads is something like 50 or 60, if I remember correct).

I can confirm what jasonvp wrote.

I did tests with a 1-minute sequence (3840x2160 60p, cineform codec source; no fx or anything).

With 2.2.0 (and 2.2.3) it exported in around 2:30 (basically 2.5:1 time ratio)

Then I ran VRPT , and it completed with about 1.6:1 ratio:

Finally, I've tried 1.1.3 and it finished in 51 seconds (0.85:1).

I re-ran this several times, and even with different compression/profile settings, these numbers remained pretty much the same.

My specs are i7-7700k@stock, 32gb ram, 1080Ti, win10. Source/export on fast disk (no bottlenecks).

Thanks for your work and it's great projects like these exist; the speed of 1.1.3 export is a real incentive to use it over CPU encoding when time is a priority.