Will it work on after effects cs6? And also premier cs6? How about vegas pro 12?
Somebody hasn't read the thread...
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.
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?
-
Both VLC 3.0.18 64-bit and Windows 10 Media Player. Both programs will play video encoded by Voukoder 13.0.2, and both programs refuse to play video from Voukoder 13.1 and 13.2beta1.
-
-
-
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
-
Looking forward to the Vegas version...
-
I have to change it in the project settings right?
In Vegas' project settings, yes.
-
Confused little bit here. So I can't use 13 if my driver is lower version than that? Or just SDK 12 won't be used? I'm still running Windows 7
Why don't you go experiment on your own? You seem good at solo activities.
-
What are your output resolution and framerate?
-
-
Does rendering the same project without using Voukoder produce a playable file?
-
To remove the session limit on Nvidia GeForce cards, search for the driver patch by keylase on GitHub. NB: You will have to re-apply the patch every time you update drivers or change graphics cards.
-
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.
-
You really should point my fault out.
Do I have to? Okay, this is not productive or constructive for anybody, but here we go....
First of all, with a $200 budget and an 8000-series Intel processor, the OP is not a high-powered user. He's looking for hardware encoding and some light effects, by the sounds of it.
I explained the different generations of Nvidia cards, and why Ampere is a waste of money for encoding, and Lovelace (while somewhat better for encoding) is obviously way out of his price range. I suggested a card (2060S) at the price point he was looking for, and with what should be very good specs for his purposes.
You came in with a misinformed wall of text touting every high-powered card you'd ever heard of. Despite the facts that: this clearly wasn't what he was looking for, encoding wouldn't benefit from these cards (as I'd already explained), Vegas editing wouldn't benefit much from these cards, and they were also significantly out of his price range (a Quadro, when the guy asked about $200 cards? Really?).
I did not provide a bad answer compared to yours.
I answered his question, based on my own experience trying to improve Vegas' performance. You shouted me down by copy and pasting half the Internet, which didn't really apply to his situation or to Vegas.
... gluing humilation with context.
I don't speak whatever language this is.
You are actually recommending 40-series cards, which are NOT older than mine recommendation.
If you actually read what i wrote above, you'll see i was not recommending Lovelace cards to this gentleman. Quite the opposite. They do have better onboard NVENC encoders supposedly, but are significantly out of his price range and are not a good fit for him.
Nor is it simply a matter of card age. Which i explained (Pascal vs Turing vs Ampere). For instance, a 2060 Super has the same NVENC module and 24% more memory bandwidth than a 3060.
I will say that you were right on one thing: Faster processors make everything better, including Vegas. But the OP's rig isn't that bad for what it seems like he's doing, and on a $200 budget he's certainly not going to buy an entirely new platform and a 13900K or 7950X.
