Small output file size

[Clarity3]

I recently bought a new graphics card which now enables me to take advantage of CUDA hardware acceleration for encoding/decoding.

My first trial was with ‘Hostiles’ which processed the backup in around 30 minutes as opposed to 38 minutes with software encoding/decoding.

As a ‘Partial’ copy the file size to be compressed to 25GB was 34GB and from the slider setting suggested an approximate final size of 23.90GB. After completion and the ‘save the log file’ window shown I noticed the data written was 34.47GB and the data written was 14.8GB, somewhat smaller than expected.

Wondering if the CUDA process might have an effect, I saw the software encoding/decoding version came out the same size as well.

I have now tried two more blu ray titles and each came out at 14GB when set for 25GB. If a backup is done without compression the file is the same size as the original (not surprising).

Has anyone else seen this behaviour?

Attached are two logs, one with CUDA, the other without.

Edit:

Just reinstalled 1.1.9.4 and backed up the same blu ray titles as Partial for 25GB. The output file sizes are now 23.03GB and 23.40GB.

Going to install 1.2.2.0 again and see if the small output file size is repeatable.

 

[Reto]

Just reinstalled 1.1.9.4 and backed up the same blu ray titles as Partial for 25GB.

It would help a lot, if you could also post log files for those attempts, that will help compare.

 

[Clarity3]

Hi Reto
Log files attached

 

[Clarity3]

Further the points above, is it expected that the file size for a CUDA accelerated transcription will be circa 14GB as opposed to the software decoding/encoding which is typically ~23GB, when both are set for a 25GB output?

 

[Reto]

Further the points above, is it expected that the file size for a CUDA accelerated transcription will be circa 14GB as opposed to the software decoding/encoding which is typically ~23GB, when both are set for a 25GB output?

Did I misunderstand something there? Didn't you say, that the conversion using 1.1.9.4 resulted in 23GB? According to the log file, it's 14 GB as well.

There is something you need to understand about the sizes - I'm not entirely certain, that it applies here, but it is quite likely: some discs have rather low quality to begin with but also have a lot of filler data (random padding).
This filler data is a regular feature on different levels of the video encoding. One practical use is to prevent buffer underflows in scenes with low detail.
But that doesn't really apply as a use case with Blu-ray discs - it's application there is mainly to fill the disc and make it look like there's really a lot of great picture quality on it. (A BD with only 8GB on it wouldn't look all that impressive).

nVidia and AMD don't support filler data on output. Intel and software encoding (ffmpeg) do.
So when encoding without hw acceleration, ffmpeg will attempt to add filler data to come closer to the requested bit rate, if the actual video doesn't have enough detail to really use the space.
nVidia will not.
nVidia will encode the video stream with as high a bit rate as you allow it to (through the settings), but it will not artificially add size beyond what is there without reduction of quality.

So the real question is: do you see a major difference between your CUDA and your non-CUDA output quality-wise?
If not, you can assume, that the non-CUDA output is the same 14GB, just with 9GB of additional random junk added.

Additional note: what I described there, is a very common thing, especially with Blu-rays, that were upscaled from DVD sources or TV shows.
Hostiles, on the other hand, is a recent, over 2h movie, so I'd be a bit surprised.

In any event, we don't have much influence on this, because we can't do more than tell the nVidia encoder the requested bit rate and let it do its work.
(We could switch to constant bitrate mode - then nVidia would add filler data to ensure the requested size, but the quality would be worse than VBR).

 

[Reto]

software decoding/encoding which is typically ~23GB, when both are set for a 25GB output?

A 25GB disc doesn't really have 25GB free, so 23.something is correct.

 

[Clarity3]

Thanks Reto.

I am aware the useable space on 25GB disc is less, I just quoted this as the reference for the setting used to qualify the output size.

Sorry for the misleading information. Having named the output files with the version and process type on numerous tries, I must have mixed the log file window information.

I have now looked at both the software encoded/decoded and hardware aceleration versions on a 65" screen. Incidentally, both were set to Encoder 'highest speed'.

There seems little difference but if I am really picky, the CUDA version appears to have lower quality during some scenes. Is this what you would expect and is this a potential trade off for a shorter process time?

 

[coopervid]

My CUDA results using a Geforce 760 were always small. Also in the 14 Gb range. In order to compress UHD disks I moved to a Geforce 1050. Now the BD files are very close to the limit of a 25 Gb BD-R.

 

[Pete]

My CUDA results using a Geforce 760 were always small. Also in the 14 Gb range. In order to compress UHD disks I moved to a Geforce 1050. Now the BD files are very close to the limit of a 25 Gb BD-R.

THAT is really interesting.
Seems that the 7xx has some bitrate limit.
I'd recommend at least a 9xx anyway for video transcoding.

 

[David Johnson]

I have noticed the same phenomenon since installing a new GTX 650 Ti about a year ago. I have tried everything I can think of, but the resulting ISO file is 13 GB more or less, and when burned the disk can be seen to be about half used. I will admit that the visual results on screen look OK. However, on my new 4K Sony Blu-Ray player, which will show Mbps as it plays, the disk I produced with Redbox & Elby produces about half the Mbps, typ 9, compared to the original at the exact same scene point, ie about 20 Mbps. I am not positive, but I think this did begin when I upgraded the video card. Also, now if I disable CUDA transcoding etc., the software processing speed is close to zero, and I am told the process will take days.

So, what do we think? Is this an Nvidia issue, or crafty marketing as indicated above? The variation indicated Mbps during playback says to me that perhaps this is not just a matter of producer padding, or would that also show up in Mbps during playback?

Just curious.

 

[TM2-Megatron]

I've got a 670, and the same thing happening. My ISOs when set to a 25GB disc in CloneBD are about 14GB. I'll hopefully be building a new system soon, so I don't need to worry about it much longer and won't bother upgrading the GPU in this one. Until then, I'll just turn CUDA off, which seems like it'll result in the process taking about 1.5-2x as long (but still manageable).

 

[tectpro]

That is very strange indeed.
I did not encunter this issue with the 750 TI. Will it help if I run some tests? @Reto

 

[Reto]

Will it help if I run some tests?

I just can repeat: this is nothing we can influence in any way.
It's as simple as this: dearest nVidia card, here I have a sequence of pictures, please compress them, I'd like an average bit rate of xxxxx and a maximum bitrate of yyyyy.

There are no additional knobs to turn (there are sliding window sizes and virtual buffer sizes with some limited impact, but these are all preset by the BD specifications anyway).
GTX 6xx cards have a stronger tendency to deliver smaller bitrates - we don't know why. Bugs in the chipsets, marketing, who knows.

But considering that an old GTX 6xx hardly really processes a full-hd stream much faster than a moderately up-to-date CPU, I don't think this is worth pursuing anyway.