18.0 is slower since popup windows prompting to update to 19.0

ColdWeather wrote on 9/7/2021, 1:53 AM

I have an impression, since 18 shows a popup window with the suggestion to buy 19, the rendering got twice slower (intensionally?) as if 18 tries to nudge to upgrade: the same sources, the same project in 4K, no changes to PC: 7fps instead of 12-14fps while rendering. Is that a policy?

Comments

RogerS wrote on 9/7/2021, 3:20 AM

No that's not the case. You can turn off the news feed in preferences.

VEGASDerek wrote on 9/7/2021, 8:49 AM

We do not sabotage our software to urge people to buy upgrades. Something else is likely wrong. Please post information about the media you are using and the format you are rendering to. I also knowing a little bit about your hardware would be handy.

ColdWeather wrote on 9/15/2021, 10:12 AM

Well, first, I updated to 19. My impression is, Vegas has still difficulties quickly to decode some H.265 sources. My Panasonic HC-X2000E camcorder for UHDp60 makes H.265 encoded files, those codec information (by VLC player) looks like:

Stream 0:

Codec: MPEG-H Part 2/HEVC (H.265) (hvc1), Resolution: 3840x2160, Frame Rate: 59.940060, Color Primaries: ITU-R BT.709, Color Transfer Function: ITU-R BT.709, Color Space: ITU-R BT.709 range.

Stream1:

MPEG AAC audio (mp4a), Stereo, 48000Hz, Bits/Sample: 32

According to properties of the files by Vegas I see:

Streams
  Video: 00:37:39,758, 59,940 fps progressiv, 3840x2160x32, HEVC
  Audio: 00:37:39,758, 48.000 Hz; Stereo, AAC

Even playing back those files from the time line I get only about 7fps in the preview window, almost independently upon, what quality setting the preview has. The "Frame" counter in the window always has trailing ''..." like "Frame: 123.456..."

By chance I converted the sources by "Any Video Converter" to equal H.265 saying him to use the "original" settings of the source. The resulting files have quite similar Codec information, but instead of (hvc1) I see (hev1): MPEG-H Part 2/HEVC (H.265) (hev1), Vegas shows the same:

Streams
  Video: 00:37:39,758, 59,940 fps progressiv, 3840x2160x32, HEVC
  Audio: 00:37:39,732, 48.000 Hz; Stereo, AAC

but "converted" files are smoothly played back from the time line. Maybe that is the reason, why rendering with the sources of the "first type" is so slow...

Howard-Vigorita wrote on 9/15/2021, 12:52 PM

That app embeds ffmpeg to do it's transcoding. Using ffmpeg directly with a script to repair gh5 footage created with the same Panasonic hevc codec was covered in this other thread. Any app embedding ffmpeg should work, such as vDub2 or Handbrake.

ColdWeather wrote on 9/15/2021, 4:04 PM

That app embeds ffmpeg to do it's transcoding. Using ffmpeg directly with a script to repair gh5 footage created with the same Panasonic hevc codec was covered in this other thread. Any app embedding ffmpeg should work, such as vDub2 or Handbrake.


Thanks! So it's true, hvc1 vs. hev1 seems to be a known "issue".

Question: what is -crf option for ffmpeg? I could not find it in docs to ffmpeg yet...

P.S. -crf found in WiKi: constant rate factor, the less the number, the better quality.

fr0sty wrote on 9/15/2021, 4:29 PM

Some types of HEVC clips can be hardware accelerated with GPU decoding, others cannot, that is likely the source of the issue.

ColdWeather wrote on 9/16/2021, 12:48 AM

By the way, the version is already 19 but still needs changes to settings like 0MB dynamic RAM and reduced number of rendering threads to avoid crashes during rendering...

RogerS wrote on 9/16/2021, 9:41 AM

With what media? Are GPU drivers up to date? What render template?

Reducing rendering threads is pretty outdated at this point.

Reducing dynamic ram preview shouldn't be necessary but if you can do controlled tests and show it still causing problems that would be helpful to diagnosing (if you can make a sample project and media available for others to confirm that would be even more valuable).

ColdWeather wrote on 9/16/2021, 10:45 AM

With what media? Are GPU drivers up to date? What render template?
Reducing rendering threads is pretty outdated at this point.

Reducing dynamic ram preview shouldn't be necessary but if you can do controlled tests and show it still causing problems that would be helpful to diagnosing (if you can make a sample project and media available for others to confirm that would be even more valuable).

1. Media are UHDp60 hvc1 files, ~96Mbps from Panasonic HC-X2000E.

2. Up-to-Date "Studio-", not "gaming-" Driver 471.68 from nVidia, GTX 1060 3GB card;

3. i9-9900KF CPU, 16GB RAM.

4. Template: "built-in" Magix AVC/AAC UHD NVENC.

After updating to Vegas Pro 19 from 18 I tried to render a project with the "default" settings regarding mentioned RAM/Thread settings, and have been facing crashes after 27%, 33% and 35% rendering progress: my project is to result in a 1h14m UHD video of 50GB size. Imagine the time I lost having about 7fps of rendering speed each time! At the end I just applied the settings from 18 (0 RAM, 1 thread), right now I'm at 40%, 6.5h yet to go, and I hope for success: my PC has been running since 60 hours non-stop.

I don't need to do control tests: google for "rendering problems Vegas Pro" up to 19, and you'll find tons of live hacks. For example, "Scrapyard Films" youtube channel - an expert in Vegas: Hardly 19 was out, "Run faster, Fix Crashing" Video was set online.

RogerS wrote on 9/16/2021, 9:19 PM

3GB is under the recommended minimum for GPUs. Can you watch task manager/performance while rendering and see if it runs out of memory? You might not be able to do NVENC with this GPU (and if it crashes may be faster to do Mainconcept and not crash. Put dynamic ram preview and threads back to defaults).

I don't really see Scrapyard Films as expert- it's just one approach to disable GPU and other recent functions of Vegas for stability. The video is also largely the same as in past years.

What is an HVC1 file? Try MediaInfo: https://www.vegascreativesoftware.info/us/forum/faq-how-to-post-mediainfo-and-vegas-pro-file-properties--104561/

Former user wrote on 9/16/2021, 11:07 PM
 

By chance I converted the sources by "Any Video Converter" to equal H.265 saying him to use the "original" settings of the source. The resulting files have quite similar Codec information, but instead of (hvc1) I see (hev1): MPEG-H Part 2/HEVC (H.265) (hev1), Vegas shows the same:

Streams
  Video: 00:37:39,758, 59,940 fps progressiv, 3840x2160x32, HEVC
  Audio: 00:37:39,732, 48.000 Hz; Stereo, AAC

but "converted" files are smoothly played back from the time line. Maybe that is the reason, why rendering with the sources of the "first type" is so slow...

Did video converter encode using NVENC (hardware encode) or did it do it much more slowly with software encode?

ColdWeather wrote on 9/17/2021, 1:33 AM

Did video converter encode using NVENC (hardware encode) or did it do it much more slowly with software encode?

I have no idea. According to Howard-Vigorita above, the converter must be using ffmpeg being a GUI wrapper for it. ffmpeg has a lot of options, among them also for utilization of hardware encoding (cuda). The conversion speed is definitely not in "real time" (frame rate), I estimate of about 10fps.

ColdWeather wrote on 9/17/2021, 2:02 AM

3GB is under the recommended minimum for GPUs. Can you watch task manager/performance while rendering and see if it runs out of memory?

It may be: time to buy some up-to-date graphic card :). By the way, my first project under 19 has been successfully rendered. I used Magix AVC/AAC preset while setting RAM to 0 and thread count to 1.

I have no tool to see, if the renderer runs out of GPU memory; a task manager for Windows (I use System Explorer, a third part tool) shows CPU load of about 25-28%%. It means, GPU must be in use (rendering without NVENC gives above 50%). Under an OS like windows/linux it's almost impossible to run out of memory because of its virtualisation and memory paging (as long as no limits set to the swap file and having a lot of gigabytes disk free space, what the case in my PC is); my system stays more or less operating while rendering, at least for browsing in internet or writing forum messages.

Look, if 3GB GRAM is not enough, a program that uses this ressource should implement some diagnostic and give a warning or apply another algorithms but not crash! By the way, my Vegas 19 crashes without any message but just disappears.

What is an HVC1 file? Try MediaInfo: https://www.vegascreativesoftware.info/us/forum/faq-how-to-post-mediainfo-and-vegas-pro-file-properties--104561/

General
Complete name                            : A015C003_210911_DJ0C.MP4
Format                                   : MPEG-4
Format profile                           : Base Media / Version 2
Codec ID                                 : mp42 (mp42/hvc1)
File size                                : 34.5 MiB
Duration                                 : 3 s 3 ms
Overall bit rate                         : 96.3 Mb/s
Encoded date                             : UTC 2021-09-11 08:29:58
Tagged date                              : UTC 2021-09-11 08:29:58
Video
ID                                       : 1
Format                                   : HEVC
Format/Info                              : High Efficiency Video Coding
Format profile                           : Main 10@L5.1@High
Codec ID                                 : hvc1
Codec ID/Info                            : High Efficiency Video Coding
Duration                                 : 3 s 3 ms
Bit rate                                 : 95.7 Mb/s
Width                                    : 3 840 pixels
Height                                   : 2 160 pixels
Display aspect ratio                     : 16:9
Frame rate mode                          : Constant
Frame rate                               : 59.940 (60000/1001) FPS
Color space                              : YUV
Chroma subsampling                       : 4:2:0
Bit depth                                : 10 bits
Bits/(Pixel*Frame)                       : 0.192
Stream size                              : 34.2 MiB (99%)
Language                                 : German
Encoded date                             : UTC 2021-09-11 08:29:58
Tagged date                              : UTC 2021-09-11 08:29:58
Color range                              : Limited
Color primaries                          : BT.709
Transfer characteristics                 : BT.709
Matrix coefficients                      : BT.709
Codec configuration box                  : hvcCAudio
ID                                       : 2
Format                                   : AAC LC
Format/Info                              : Advanced Audio Codec Low Complexity
Codec ID                                 : mp4a-40-2
Duration                                 : 3 s 3 ms
Source duration                          : 3 s 51 ms
Bit rate mode                            : Constant
Bit rate                                 : 256 kb/s
Channel(s)                               : 2 channels
Channel layout                           : L R
Sampling rate                            : 48.0 kHz
Frame rate                               : 46.875 FPS (1024 SPF)
Compression mode                         : Lossy
Stream size                              : 94.0 KiB (0%)
Source stream size                       : 95.5 KiB (0%)
Language                                 : German
Encoded date                             : UTC 2021-09-11 08:29:58
Tagged date                              : UTC 2021-09-11 08:29:58Other
ID                                       : 3
Type                                     : Time code
Format                                   : QuickTime TC
Duration                                 : 3 s 3 ms
Bit rate mode                            : Constant
Frame rate                               : 59.940 (60000/1001) FPS
Time code of first frame                 : 02:44:10:14
Time code, striped                       : Yes
Title                                    : A015
Language                                 : German
Encoded date                             : UTC 2021-09-11 08:29:58
Tagged date                              : UTC 2021-09-11 08:29:58

 

Former user wrote on 9/17/2021, 5:01 AM

If you uploaded a small sample file from camera to a file server that could be helpful . Currently nobody knows how your file is actually supposed to play in vegas as you can't tell us if GPU decode works, and we don't know if Vegas does do decode with your particular 10bit HEVC camera file with Nvidia GPU's. My samsung phone 10bit HEVC camera files decode in Vegas but many don't

RogerS wrote on 9/17/2021, 5:29 AM

Pressing control/alt/delete opens up task manager. There you can click on performance.

From there you can see what your GPU is doing (is NVENC encoding working? It will have activity in video encode. It will also show how much dedicated GPU memory is in use.). If you can get a card with 4GB or more of memory that's preferable. Your CPU usage does hint that GPU encoding is working.

I agree with you that a lack of memory shouldn't cause crashes, it should just slow things down, but GPUs don't always work in Vegas as we think they should. Vegas disappearing with no message is not normal (and not something I've experienced to date. I'm using a GTX 1050, by the way).

So the file is 4K60p 10-bit 4:2:2. If you're not using log or another flat profile consider trying an 8-bit mode and see if it works better with your system. Agree with Todd on a sample- happy to test it.

 

ColdWeather wrote on 9/17/2021, 7:07 AM

If you uploaded a small sample file from camera to a file server that could be helpful . Currently nobody knows how your file is actually supposed to play in vegas as you can't tell us if GPU decode works, and we don't know if Vegas does do decode with your particular 10bit HEVC camera file with Nvidia GPU's. My samsung phone 10bit HEVC camera files decode in Vegas but many don't

Thank you for your engagement. The link to a short file (in ZIP) from my cam is here:

https://drive.google.com/file/d/1QjXYNsi-vpyB2ZhmWscBwUzIJqQLv50_/view?usp=sharing

VEGASDerek wrote on 9/17/2021, 8:05 AM

I have forwarded this media to our file I/O engineer to examine. I agree the decoding performance of this is really poor.

Former user wrote on 9/17/2021, 10:01 AM

If you uploaded a small sample file from camera to a file server that could be helpful . Currently nobody knows how your file is actually supposed to play in vegas as you can't tell us if GPU decode works, and we don't know if Vegas does do decode with your particular 10bit HEVC camera file with Nvidia GPU's. My samsung phone 10bit HEVC camera files decode in Vegas but many don't

Thank you for your engagement. The link to a short file (in ZIP) from my cam is here:

https://drive.google.com/file/d/1QjXYNsi-vpyB2ZhmWscBwUzIJqQLv50_/view?usp=sharing


It does not use Nvidia GPU decode, It does not playback normally with GPU decode turned off or in Legacy Mode, about 3fps in VP18

ColdWeather wrote on 9/17/2021, 10:22 AM


It does not use Nvidia GPU decode, It does not playback normally with GPU decode turned off or in Legacy Mode, about 3fps in VP18

That is the point. The encoding (rendering) works also slowly, in this case maybe because of decoding lags of the sources.

ColdWeather wrote on 9/17/2021, 5:31 PM

I have forwarded this media to our file I/O engineer to examine. I agree the decoding performance of this is really poor.


I was playing with "Any Video Encoder" and ffmpeg. The main difference of my hvc1 sources is that they have 10-bit depth while H.265 hev1 after "Any Video Encoder" with the equal bit rate of ~96Mbps is 8-bit.

ffmpeg with the command line:

ffmpeg.exe -hwaccel auto -i %1 -c:v libx265 -c:a copy -pix_fmt:v yuv420p -crf 17 -y %1.ff.mp4

generates the result like "Any Video Encoder" but essentially slower (01:50 vs. 00:18 for a 109MB source file). Vegas works fine with both hev1 files providing almost full 59fps in the preview window from the time line.

I'm pretty sure now, the main reason, why Vegas works slowly with my sources, is their 10-bit depth. The poster RogerS was right suggesting to switch to 8-bits. So long I have to re-encode the sources before feeding them to Vegas, since I could not find any settings in my cam to reduce the bit depth: HC-X2000E offers a limited number of storage formats.

Former user wrote on 9/17/2021, 7:21 PM
 

I'm pretty sure now, the main reason, why Vegas works slowly with my sources, is their 10-bit depth. The poster RogerS was right suggesting to switch to 8-bits. So long I have to re-encode the sources before feeding them to Vegas, since I could not find any settings in my cam to reduce the bit depth: HC-X2000E offers a limited number of storage formats.

10 bit HEVC uses the Nvidia GPU decoder as generated by FFMPEG so you can convert using command line as you were talking about or use shutter encoder, a GUI for it. The Vegas GPU decoder doesn't like 60fps so will still have playback problems most likely but it will render faster.

Also logically speaking, is there any need to stay in HEVC format considering you're having to transcode, it's just as fast to convert to an editing codec, the only negative being the size of files

ColdWeather wrote on 9/18/2021, 6:31 AM

10 bit HEVC uses the Nvidia GPU decoder as generated by FFMPEG so you can convert using command line as you were talking about or use shutter encoder, a GUI for it. The Vegas GPU decoder doesn't like 60fps so will still have playback problems most likely but it will render faster.

Also logically speaking, is there any need to stay in HEVC format considering you're having to transcode, it's just as fast to convert to an editing codec, the only negative being the size of files

Thanks for Shutter Encoder!

Anyway, as long as Vegas struggles with 10-bit sources I have to re-encode to 8-bits. I agree with you: no sense to re-encode H.265x10 sources to H.265 again and then produce a video by Magix AVC/AAC encoder/renderer (H.264) in order to match the current recommendations of youtube, since I target it uploading there (but not for public 😀). Vegas works fine with H.264x8 sources.

ColdWeather wrote on 9/19/2021, 9:02 AM

Reducing rendering threads is pretty outdated at this point.

Reducing dynamic ram preview shouldn't be necessary but if you can do controlled tests and show it still causing problems that would be helpful to diagnosing

Started rendering of a new project. First with the re-encoded H.264 and then with my original cam hvc1 files as sources, but before I set RAM to 10%. Immedialely I got a pop-up with an error "0x8066000a (no message)". Reset RAM to 0 - rendering starts and goes normally. Tried with some other non zero values like 5% and 50%: the same error; only at 0 RAM the rendering goes on. The threads are at 32.

RogerS wrote on 9/19/2021, 9:17 AM

@ColdWeather Thanks for that confirmation that dynamic ram preview is hindering renders with non-zero values in VP 19 for you. @VEGASDerek

Is this the initial build (341) or update (361). Not that I think anything changed with ram preview but helpful to know for diagnostic purposes.

FWIW I was able to do a MagixAVC UHD 30p NVENC render of this with 10% dynamic ram preview and 32 threads with my 4GB GTX 1050.