Posts by Joe24

    Regarding dedicated graphics card for encoding, low-end Nvidia Turing (except GTX 1630 and GTX 1650) cards are best at the moment. Any Nvidia card from 1650 Super and up.

    Turing cards (16/20-series) encode notably better h.264/h.265 picture quality for the same bitrate vs. Pascal cards (10-series). Difference to me looks about the same as decreasing the Constant Quantizer setting by 1, but with the same filesize.

    Ampere cards (30-series) use the same NVENC module as Turing. The NVDEC decoder has a slight improvement, but not the encoder.

    Lovelace cards (40-series) have better NVENC modules, but are outside your $200 range at the moment.

    Worth noting too that a higher-end card won't gain you much encoding performance. Turing and Ampere cards all have the same NVENC encode module, which has nothing to do with how big the GPU is, how many CUDA cores etc. Separate module. (If you're doing effects or filters etc. where you also use CUDA, that's different...) The only encoder difference between a 1650 Super and a 3090 Ti is memory bus width/speed; they both have the same NVENC module.

    The RTX 2060 Super has a 256-bit memory bus with 14 Gbps GDDR6. Might be close to the sweet spot for you.

    Nvidia NVENC - Wikipedia

    List of Nvidia graphics processing units - Wikipedia

    It's something to do with your resolution. I tried a known working project on my rig (VP15, 3060Ti, Voukoder 13.0.2, Nvidia driver v531.29DCH patched with keylase), and I can make it choke by changing either of the resolution values (width or height) to your values. Tried 2400x3600, 1920x3600, 2400x1080. In all 3 cases, I get the following error in the log when ffmpeg is being initialized:

    FFmpeg: InitializeEncoder failed: invalid param (8): Invalid Level.

    When setting resolution back to 1920x1080, everything works again.

    According to the documentation, NVENC resolution limit for everything from Pascal to Lovelace is 8192x8192, so it shouldn't be an NVENC problem. Either FFmpeg doesn't like your resolution, or it's not receiving the correct syntax from Voukoder.

    You could test for an FFmpeg limitation by CPU-rendering a small test file in Vegas and then trying to re-encode the file using FFmpeg and the NVENC encoder directly from command line.

    So it's not viable for VP to use the x264/x265 libraries ONLY if they are present in the FFmpeg build? (Which would only happen if the user has chosen to download and compile their own version of FFmpeg, manually enabling these encoders.)

    Is there a way to have the user download/install ffmpeg separately for free? This might remove the requirement for you to buy commercial licenses.

    IIRC, Handbrake has an "update ffmpeg" function in it somewhere.

    The CCFS CuminCode FrameServer schmuck is happy to charge for his crap programming skills and lousy work ethic. Voukoder works several times faster, and is so much easier to use. Voukoder has no equal that I'm aware of. And believe me, I've looked! Especially if multiple streams and filters will soon be supported . . . Your program is vastly better and worth AT LEAST what he's charging ($15). Possibly 2-3+ times as much.

    Keeping in mind that most of us paid for the NLE suites that we use Voukoder on.

    One thing I would add is that a trial period of 1 week is NOT long enough. That's what CCFS is currently doing, and it did not make me happy. I've got other things in my life that need attention too, and I can't take a week off just to learn a new program. In my experience as a consumer, 1 month is a comfortable time period to figure out if a program will actually do what you need. I needed a couple solid weeks of working with TMPGEnc before deciding to buy it.

    P.S., I decided not to buy CCFS. Total garbage.

    Here's how to check in TAW6 whether your source file is compatible or not :

    Note that TAW6 uses fields, not frames, to indicate it's max GOP size. Voukoder "48 frames" = TAW6 "96 fields".

    I couldn't find a setting for CABAC

    Then I'm guessing your particular GPU only does CABAC encoding.

    Just did a test because I was curious, and it seems that TAW will also accept CAVLC encoding.

    What was probably messing you up last time is the Group-of-Pictures max size (GOP). Most encoders have a really large value by default, mine is 300. For Blu-ray though, this number has to be manually limited to 48 or less (for 24p video).

    Just to clarify, feel free to experiment with the other settings, as you can tweak your picture quality and encode speed quite a bit. @avwtp's settings will probably give you a much better picture than mine. But the settings that are absolutely critical to Blu-ray compatibility are listed in my last post.

    Tried everything I could think of, finally gave up on Architect Pro 6.0 compatibility, switched to TAW (TMPGEnc Authoring Works 6). If TAW isn't happy about something, it'll at least tell you why. Plus if you want to create a DVD from the same project, TAW has hardware MPEG-2 transcoding built in, so it's very easy to make a DVD from an existing Blu-ray project. Have had good success with hardware-encoded files (Voukoder + NVENC) being accepted by TAW without needing re-encoding.

    You don't need all of @avwtp's bells and whistles above to get Blu-ray compatibility. The main things are: h.264 format, Blu-ray Compatibility enabled, GOP max 48 (for 23.976/24p video) or max 60 (for 29.97/30p video), CABAC encoding, Level 4.0 (technically 4.1 is allowed by the Blu-ray spec, but I find TAW won't accept Level 4.1 video), resolution/framerate within Blu-ray specs, and YUV420P color format.

    Other than the settings listed above, the rest is just playing with encoder settings to get your desired picture quality or render speed. You should be able to leave everything else at default and still get TAW-compatible renders. If you screw anything up, TAW will tell you what you did wrong.

    The attached photo is a very barebones configuration that should be TMPGEnc / Blu-ray compatible. The bitrate is really low, so you'll probably want to raise that (this project involved putting 19 hrs of video onto a single disc).

    Yep, that's why I suggest you to export first, and then encode into different formats

    You suggest that I export 19 hrs of uncompressed 1080p video . . . okay, let's run some numbers, shall we?

    Ignoring the PCM audio stream, at 100MiB/s uncompressed video-only data rate, that's around 6.2 TiB of data. A SUSTAINED write speed of 1.4 GiB/s would be needed to store the data fast enough (more on that in a minute). That's a respectable hard drive!

    As is, let's take a 7-hr block of video for example (a pair of 3.5 hr videos). I currently run 4 instances of Vegas in parallel (dual-CPU system). Each instance of Vegas is running Voukoder and hardware-encoding the output. The first 2 Vegas instances are encoding the first 3.5 hr video to 2 different formats, and the second 2 Vegas instances are encoding the second 3.5 hr video to 2 different formats. This all completes in 1h55m.

    A tandem-encode function in Voukoder would drop the render/encode time to about 1 hr. GPU hardware is not an issue; I would throw a second card at it, which would more than keep up. Vegas would have literally half the work to do: 2 renders instead of 4.

    So this 'ideal' 1 hr render/encode time is what we're trying to match by using your 'suggestion of exporting first, then encoding'.

    To do this 1 hr render/encode in the way you've suggested, let's say we spend 30 min rendering our master file (2.4 TiB written at 1.4 GiB/s on our amazing hard drive), and then we spend another 30 min encoding. Total time 1 hr. Except that Vegas would take 1 hr just to render the master file. And Vegas is not currently using any compression (it's just firing the raw frames to Voukoder), so Vegas render times are as fast as possible already.

    But maybe you could reduce the impact of the data size by adding some lightweight fast compression, right? Explain to me how you would manage to double Vegas' render speed . . . while adding file compression. Even if you used a compression format that Voukoder offers, you still would need to DOUBLE Vegas' render speed to make your idea work. As mentioned, Vegas is rendering as fast as possible already.

    All that . . . just to match what a tandem encode function in Voukoder could do.