23.09 version - gigantic export file size for h264_nvenc 100%

I really like using this software, just upgraded to newest version.
I always use these settings for 4k export.
I just did a few exports and file sizes are enormous for some odd reason .
A 6 second clip that is around 130MB originally turns into a 1,14Gb file after exporting (only using color grading, levels and sharpen).
What could be the reason for this ?
In the previous version I always used YADIF, this version has BWDIF, I tested both and got the same huge file after exporting.
What is causing the exported file to be nearly 8-10 times larger ?

1 Like

Le paramètre Qualité que vous avez réglé sur 100%

The Quality parameter you set to 100%

I am thinking it’s a version problem, I read up on this issue and I probably should not try to export or edit a project that was created in an older version .
I installed the older version I was using and everything works again normally.
I might upgrade again when I start a new project .

No, it is what Namna said, the quality parameter sets how good the video looks → better looking = better bigger size, at 100% you are asking the program to do the absolute best quality so the absolute biggest file size. A common recommandation is 65% for medium-high quality.

Never use 100%.

1 Like

It’s 4K 60fps video that is most likely being encoded in lossless format (the usual interpretation of 100% quality), and the encoding is being done with hardware rather than software. Hardware usually produces larger file sizes than software because it trades size for speed. There should be zero expectation whatsoever that the exported file will be small. Shotcut is behaving as expected given these export settings.

The size of the video is greatly influenced by the dynamics of the image. One minute of green fill will take very little time at any quality setting. If you add the film scratch effect to it, the size will be significantly larger, but the craziest file size will be a minute of black and white noise. In real use scenarios, a “talking head” against a static background will take up much less space than the dynamic let’s play of some shooting game. In any case, I almost never use quality above 70%, my eye does not see the difference and the video size increases greatly.

Agreed, to what dimadjdocent said. The complexity of the content and how fast it changes greatly effects the filesize. My files tend to be gigantic because I do hiking videos in 5.7K 360. I can easily fill a terabyte per month or more if I’m going out often. Complex, moving trees, bushes, clouds and rock textures change every frame when I’m walking around. The codec cannot “repeat” similar areas between frames to maximize compression if the whole screen is changing rapidly. Same reason modern FPS video games are harder videos to compress than old school 8-bit platformers. The old games repeat most of the screen as you move the character sideways, while the new ones change most pixels in 3D every single frame. If a captured subject is standing in one place with little movement, the file size will be much smaller during those segments, since much of the frame is repeated over time.

I like the look of adding a little video noise to my hiking videos… but I immediately stopped doing it after noticing it tripled the size of my exports! Looks great because it hides some of the compression artifacts, but not worth the extra file size. The smoother the color regions in an image, the better compression works. More noise = bigger files. It’s annoying not to be able to save files in their full glory, with no compression. However, unless you have money enough to buy new terabyte or petabyte drives every time one fills up, compressing video is what is necessary. Maybe someday terabytes will be the new kilobytes (super small to future generations), and all videos will be 256K instead of the current 8K, 4K or 1080P. When we reach that point, compression probably won’t matter so much. For now, it’s still a thing to consider.

It’s still a version difference, I haven’t updated it in a while, I was running an early 2022 version and simply 100% in the older version yields a smaller file than the current 2023 version. I reverted back to the 2022 version to finish my current project and I will experiment later with the newer one when I start my newer project.

It might be, but not incorrectly so. Historically, the hardware encoders do not support 100%. All that did was either go to some internal maximum or get rejected and revert to some internal default. Hardware encoding with 100% is generally a bad idea. It might be that now in a newer version it works as expected to produce a very large file. A hardware encoder is a bit of a black box. It consists of hardware, driver, library (SDK), FFmpeg API usage of the library, and Shotcut’s parameters to FFmpeg. Our parameters for this did not change in any version this year, but it is quite likely one of the others did change. FFmpeg, and the NVENC SDK were upgraded and probably your driver. I do not expect it to change back to the older behavior in any new version of Shotcut.

P.S. If you truly want lossless NVENC, it looks like you need to add an option in Shotcut’s Other tab: tune=lossless. I have not found any code in Shotcut or FFmpeg that converts 100% into the dedicated lossless mode for NVENC. However, I just did a comparison test in Shotcut v23.09 between 100% and the default 55% with tune=lossless, and they produced roughly the same size file. I also right-clicked each export job and chose Measure Video Quality. When the quality jobs completed, I chose View Report in each job’s menu. The “psnr[Y]” values for lossless were 148.13 (same as x264 lossless) while 100% gave ~66. Thus, 100% merely approaches lossless while tune=lossless delivers it. Finally, I repeated the test using 100% without tune=lossless on Shotcut version 22.12. It produced a much smaller file with “psnr[Y]” values of ~42.5. So, one could say that 100% in older versions is actually under-performing, and the new versions fixed it.

2 Likes

This topic was automatically closed after 90 days. New replies are no longer allowed.