Difference in output files from CLI and GUI

[Son_Of_Diablo]

Hello,

I have noticed that outputs from HandBrake CLI and HandBrake GUI is different.
I use the same preset (H.265 MKV 1080p30) with both.


HandBrake GUI version: 1.2.2 (2019022300)

HandBrake CLI version: HandBrake 1.2.2

OS: Windows 10

HandBrake GUI Activity Log:
https://pastebin.com/2RxtTkkb

HandBrake GUI File Properties:


HandBrake GUI Codec Info (from VLC):



HandBrake CLI Activity Log:
https://pastebin.com/KEZMt6cA

HandBrake CLI File Properties:


HandBrake CLI Codec Info (from VLC):



If you need any other info to help me out please let me know!
I just really want to know why there is a difference in the output files when I use the same preset.

[Woodstock]

What command line did you use?

The log from the CLI is damaged, and much of it (especially the setup section) is not there.

[Son_Of_Diablo]

Command was:

Code: Select all

D:\Programs\HandBrake\HandBrakeCLI.exe -v0 -i ".\filename.mp4" -o ".\filename.mkv" --preset="H.265 MKV 1080p30" 2> my-activity-log.txt

[rollin_eng]

2 video encodes will not be the same.

I think its down to rounding and averaging things but perhaps someone with better knowledge can answer why.

[Son_Of_Diablo]

I'm not quite sure what you mean @rollin_eng it's the same origin video, same preset, same computer, only difference is Handbrake GUI vs Handbrake CLI

[Rodeo]

The difference is like 1 kilobits per second average over the whole video… though typically this is only expected if e.g. the CPUs aren't the same, but maybe x265 isn't fully deterministic?

[s55]

x265 has modes which can be non-deterministic. This introduces very small variances for each run but for all intensive purposes, can be ignored.

Your settings are the same for both encodes, and the output stats for the video tracks are close enough for it to be irrelevant.

[Son_Of_Diablo]

Okay, so for all intense and purposes the two output files are basically the same?

That is great to hear!

Thank you so much everyone!

[Woodstock]

If you do two encodes back-to-back, using the exact same settings, the files WILL be different, because there are fields in the container that include the time of the "mux".

[s55]

@Woodstock, the video will also be different (in some cases), even with identical settings. x265 won't always produces identical results for subsequent runs. While not identical, the differences is minuscule. Thus, safe to say, they are the same. (Although wouldn't produce the same checksum)

While small, container dates wouldn't impact filesize to the extent @son_of_diablo is seeing.

[Rodeo]

Dates would most likely be fixed-length fields and have no impact on the final output size, too.

[rollin_eng]

What exactly causes the difference then?

[Rodeo]

What exactly causes the difference then?

x265 won't always produces identical results for subsequent runs.

https://en.wikipedia.org/wiki/Deterministic_algorithm (or in this case, lack thereof)

[rollin_eng]

Ok, but what makes it non-deterministic

[Rodeo]

No idea, ask x265 devs.

[nhyone]

I believe it is due to multithreading.

When encoding a chunk, it may need to reference previous chunks. Earlier chunks may finish close enough that different ones are used on different runs.

x264 also has this issue, but to a lesser extent. If you use more threads, space efficiency goes down a little. My guess is that it can only reference much earlier chunks (the ones in-flight can't be used) that results in less compression.

This is why I only use 6 threads (and 1 lookahead) for x264.

[Rodeo]

x264 is fully deterministic unless you specifically tell it not to be though (even with VBV).

[nhyone]

x264 is fully deterministic unless you specifically tell it not to be though (even with VBV).

When lookahead threads > 1, the output size is larger. I forgot if it is deterministic.

And with 1 lookahead thread, there isn't much reason to use >6 threads.

[s55]

Increasing the thread count can change results. As long as those results are the same at a given thread count, t's deterministic.