Beiträge von Joe24

    Joe24 Do you have that error message in the log file again?

    No, the error message is not present in the 13.2beta3 logs.

    Would a byte-compare of the files rendered by working/non-working versions of Voukoder be useful? The problem might be something at the very beginning of the file, because the clip posted above has zero video-motion throughout. Something breaks immediately at the start of playback, and stays broken.

    I've attached 2 files and their logs below. Absolutely nothing is different between the 2 files except the Voukoder version. The 13.0.2 file plays normally, the 13.2beta3 file gives a still picture and plays audio only.

    test files.zip

    I also tried the 32-bit version of VLC, and a beta version v4.0. No change.

    I'm sorry to say that the problem still exists, although that message is no longer present in the log.

    My settings are this (although as I mentioned, I've tried several other known working presets, both h.264 and h.265):

    Software: Vegas 20.0 build 411, Vegas 15.0 build 416, Voukoder 13.1 through 13.2beta3, Windows 10 version 22H2 build 19045.3086.

    Audio: AC3 96kbps, no boxes checked in Voukoder settings, 48 kHz 16-bit Vegas project output.

    Video: 1080p29.97, 8-bit (full range), Nvidia NVENC on RTX 3060 Ti, drivers v536.23 DCH patched with keylase.

    Voukoder parameters: b=2500000 bluray-compat=1 bufsize=2500000 coder=cabac cq=0 g=48 gpu=0 level=4 maxrate=5000000 multipass=disabled preset=p7 profile=high rc=vbr rc-lookahead=20 tune=hq

    Player: VLC 3.0.18 64-bit

    My (older server) processors do not have Intel QSV, although I doubt that's the problem.

    On a hunch, I rendered the same 10-second video project as above, using every available Voukoder audio format. The only thing that I changed was the audio format; video settings are identical to the clip posted above. All tests done with Vegas Pro 20.0 / Voukoder 13.2beta1.

    Results varied widely, and none worked properly except Uncompressed PCM. All PCM bit depths work, 16/24/32-bit.

    Rendering using AAC, AC3, MP3, EAC-3 (DD+), and Vorbis yields files where the video does not move on the screen, although the audio plays.

    ALAC format gives a video that plays, but no audio except the last 1 second.

    Dolby TrueHD crashes Vegas after 39 rendered frames. See screenshot.

    DTS yields a 1m50s file (remember the project is only 10s) that will never stop playing in VLC. Video plays, but picture stops moving at 10s. No audio except brief blips at ~6.5s and ~9.5s.

    FLAC yields a 1m50s file. Video plays but picture stops moving at 10s. Brief (~0.5s) audio at beginning of track, then no audio until last 10s of file (i.e., audio plays from about 1m40s to 1m50s).

    MP2 audio format gives a video that plays, but no audio except the last 2 seconds.

    WAVPACK format gives a video that plays, but no audio except the last 1 second.

    Log files: Voukoder logs 20230710.zip


    Update: All of the above formats tested and working properly in Voukoder 13.0.2 except Dolby TrueHD which still crashes Vegas, and DTS which produces a 10s (not 1m50s as above) infinitely-playing track where the video stops after 10s and with no audio except brief blips from time to time.

    Something obviously changed somewhere. Hardware, Vegas, and drivers have not changed, so the problem lies elsewhere.

    Is there a setting in the new FFmpeg version that uses a different syntax or has a different default? Or perhaps there's a new feature which has a default setting that breaks everything?

    The video clip (above) uses a custom preset that is Blu-ray compatible, but I have not tested BD-compatibility of renders using Voukoder 13.1+. I'm away from home at the moment, and unable to do so. Where I'm going with this is: Is there a way to test what h.264 profile/level is actually being used in the encoded file?

    The fact that this affects both h.264 and h.265 is interesting. Whatever is broken is evidently shared by both formats.


    I noticed in the unplayable file logs that there are numerous messages like this:

    FFmpeg: Delay between the first packet and last packet in the muxing queue is 10016000 > 10000000: forcing output

    These messages do not appear in the logs of the playable files. Did FFmpeg change bit resolution of any arguments?

    Confirmed the issue. All renders that I tried, using my known good presets, produced unplayable video files. My presets all use NVENC in h.264 and h.265 formats, various settings, various resolutions and framerates. Sound plays okay, but there is only a still image throughout. Sometimes you get a file which will produce a new still image every time you seek, but picture never moves.

    The problem seems limited to Voukoder 13.1, and affects both my Vegas Pro versions 15.0 and 20.0. I didn't try Vegas Pro 12.0, but presumably the same. Rolling back to Voukoder 13.0.2 fixed the problem. See logs below. If you want me to upload video files, I might be able to. Not sure what the site's download limit is . . .

    bicycling temp - non-functional Vegas 15.0 - connector 1.5.0 - Voukoder 13.1.log.txt

    bicycling temp - non-functional Vegas 20.0 - connector 1.6.0 - Voukoder 13.1.log.txt

    bicycling temp - working Vegas 15.0 - connector 1.5.0 - Voukoder 13.0.log.txt

    bicycling temp - working Vegas 20.0 - connector 1.6.0 - Voukoder 13.0.log.txt

    Is your problem system a pre-Haswell Intel processor, by any chance? And are you trying to use QSV encoding? Some library that FFmpeg uses appears to be incorrectly reporting QSV encoding capabilities of older Intel processors, and this is screwing up several programs including FFmpeg, Zoom, OBS, etc. when running on these systems.

    This may or may not be your issue; I'm just throwing ideas out there. Have had trouble on Sandy/Ivy Bridge systems when using QSV processing in FFmpeg-based programs. Pre-QSV chips (Nehalem and prior) don't seem to have this problem, nor do Haswell and forward.

    The reason that I recommended Quadro cards was because they were proven to be more stable than GeForce for rendering.

    I guess you're referring to ECC? Probably not a concern for anybody whose budget is $200, and to me a Pascal Quadro is not worth giving up the improved Turing NVENC.

    It's also pretty pointless to run ECC memory on your graphics card, but still run non-ECC memory on your computer mainboard. So add a bunch of server RAM into your budget if you want to get *that* carried away. Assuming your platform even supports server memory.

    RTX 3060 12GB falls into the OP's requirement by their computing power & larger VRAM size initially.

    Doesn't matter how much memory you have if your GPU is breathing through a straw. 3060 only has 192-bit memory bus, which is why it performs about the same as the cheaper 2060S. I wouldn't buy a 3060; I don't think they're worth the money. The lowest 30-series card I'd consider is a 3060 Ti.

    I own many cards from 10-, 20-, and 30-series, everything from a 1060 to a 3090, including a 3060 Ti which has a 256-bit memory bus and is around 30% more card than a 3060. And yet my 2070 Super finishes my jobs significantly quicker than the 3060 Ti (which is not to say everybody's workload will behave the same). I suspect this is due to the 2070S's higher clock speed. Don't buy a card just so you can tell your mommy you have a 30-series; they're not necessarily better, as I've said multiple times already.

    2080 Ti cards with their oddball 352-bit bus don't work well with my CUDA workload (Vegas/TMPGEnc). Maybe it's just my application. 2080 Ti is stable and I love the cards (I have 2 of them), but somehow they're way slower at this job than other cards with a 256-bit bus. I assume the odd bus-width doesn't mesh with the particular CUDA instructions my application uses. Which is another example of a hotter card not necessarily being better. Haven't tried a 10GB 3080 yet, though i suspect it would have the same issue.

    I did some research.

    Aka, you googled it. Yeah I spent a long time googling too, when i first started out. Then i realized that 99.5% of people on the Internet don't actually know anything, they just copy and pasted uninformed theories from OTHER people who don't actually know anything. Which realization is an important step in growing up. I bought several cards that the Internet swore were the best for Vegas. I was disappointed every time. So i just started buying various cards and running my own tests against my particular workload... and that's still what I'm doing as new tech comes along.