Thanks ivan-f. The developer is to be commended for this render option which I might add is the same "under the hood" as HOS. They both make use of FFmpeg.
It works OK here for all Magix versions plus the Sony V13 version. It does not work in Sony V12.
To make it work in other installations, you must copy the folder "C:\Program Files\VEGAS\VEGAS Pro 17.0\FileIO Plug-Ins\voukoderplug" and paste it into other versions FileIO plug-ins folder. You must also copy the file "C:\Program Files\VEGAS\VEGAS Pro 17.0\Voukoder-x64.fio2007-config" and paste it into the main version folder such as "C:\Program Files\VEGAS\VEGAS Pro 16.0".
Former user
wrote on 10/10/2019, 2:53 PM
This IS exciting, and great added flexibility in setting your quality output, once you don’t mind the time trade off in render.
Previously to do the Render Quality tables and include an x264/ffmpeg value I needed to use the command line.
I just did a very quick equivalent test and everything aok, seemed a little lower value than what I got previously.
I'll do proper testing and add a table with a Voukoder x264 entry, hopefully tomorrow.
vRender: Time Vegas needs to render a frame vProcess: Time the plugin needs to convert it for the Voukoder/encoder vEncoder: Time voukoder / FFmpeg needs to encode it (incl. filters and everything) aRenderEncoder: Time for audio rendering and encoding Latency: Total latency for a single frame (incl. audio)
A word of caution and a suggestion for Vouk. At the moment, there is a 44msec audio sync problem as shown here. The same sync problem is also found in other rendering apps such as Handbrake in which FFmpeg is "under the hood".
Using a command line approach in HOS, it was very easy to correct by adding "-itsoffset 0.0444" before importing the audio (wav) file. Hopefully, the developer can add such an audio delay option.
I've yet to get a working encode out of it. My first attempt came out a garbled mess, the second froze half way through.
Former user
wrote on 10/10/2019, 5:03 PM
@Vouk Frankly, the testing I do is very simple, one glance at that screen shot and my eyes just glazed over, above my non existent pay grade, thanks for such a great tool though.
When I did the ffmpeg command line encode, way back, mediainfo displayed 4 frames, I still have the file. I assume thats 4 B frames. No matter what B frames I enter in your app I just get a mediainfo result of always 5? I really don’t know enough about this so may hold off in my table update.
Tried it again using HEVC... got the encode out, but it has no sound, and you can't skip around in it using the windows 10 media player, it will freeze if you do.
@wwaag Can you elaborate on this? Is it always 44ms? Does changing the sampling rate affect this value? Does this happen only with one specific or all audio encoders? I guess I could fix it by modifying the presentation timestamp offset but it would be helpful to have some details.
@fr0sty Is it possible your project is any other than YUV420 / 8 bit depth?
Tried it again using HEVC... got the encode out, but it has no sound, and you can't skip around in it using the windows 10 media player, it will freeze if you do.
I have this same problems with files encoded in HEVC out or vegas and Vouk, so probably is not related with this software but with the HEVC codec. Mine were encoded using Handbrake and AMD GPU.
"Can you elaborate on this? Is it always 44ms? Does changing the sampling rate affect this value? Does this happen only with one specific or all audio encoders?"
"I have this same problems with files encoded in HEVC out or vegas and Vouk, so probably is not related with this software but with the HEVC codec. Mine were encoded using Handbrake and AMD GPU."
My Vegas HEVC files have been working perfectly.
@Vouk It is a standard 4k 8 bit project. The first time, I tried a H264 render. It rendered and came out all messed up, the video smears and blurs all over the place. The second attempt, with some changes made (both were set to high profile, but I changed the encode mode from VBR to CRF), it encoded but just stopped rendering about half way through, hung on a frame. Canceling the render closed it out, but Vegas sat there saying "render canceled by user" (a bug that has been in Vegas since the beginning, that I REALLY wish they'd fix... not being able to cancel renders that hang for any reason even if it doesn't crash Vegas itself), I left it there until the next morning, it was still stuck saying that.
The third attempt, I messed with the settings a bit more and used HEVC this time. I got beautiful video out of it, but it was silent and if I tried skipping around to different parts of the video, it would lock up.
44 milliseconds? That is more than one frame (ahead, based on Wayne's screenshot.. and ahead is more annoying than behind to Homosapians). May be acceptable in some instances, and/or could be corrected before or after the render, but that's more work than it's probably worth, but I'll try it never the less.
As John Dennis points out, the audio delay issue is not "constant". It can be affected by a number of things. E.g. it is affected by the decoder that is being used inside of Vegas. As such, a "hard coded" solution doesn't seem reasonable. If possible, you should give the user the option of adjusting audio delay according to his own needs. Here is the UI in HOS wherein audio delay can be easily changed.
It'd be easy to give you an option to enter a delay value (in number of frames) to correct this issue. But it'd be better for me to fully understand why this happens so i could provide a nicer way to handle this.
Is this related to the delay AAC encoders add at the beginning and note that value in the header for decoders to correct it? (FFmpeg AAC adds 1024 samples, FDK AAC adds 1024 samples per channel AFAIR).
Interesting fact: 2048 samples are around 43ms (48 KHz, Stereo)
A word of caution and a suggestion for Vouk. At the moment, there is a 44msec audio sync problem as shown here. The same sync problem is also found in other rendering apps such as Handbrake in which FFmpeg is "under the hood".
Using a command line approach in HOS, it was very easy to correct by adding "-itsoffset 0.0444" before importing the audio (wav) file. Hopefully, the developer can add such an audio delay option.
This appears to be the legacy PCM desync issue in ffmpeg / libav going back to the dark ages, and abundantly discussed in 2018. First documented by me in 2012.
Since users have reported 42, 43, and 44 ms offsets, I believe it's the same general issue
Latest beta 5 does not work for me. I deinstalled former builds of core and connector, installed latest builds, restarted Windows. But now Voucoder no more appears in the list of renderers of VP17.