crf with decimal value

[linuxuser]

I really hate it to be limited with 4 GiB but with FAT32 it is less surprise, if it works with some hardware. Crazy, that Android-phones (linux) do not support NTFS or exFAT, because there are linux -drivers available. Maybe it can be solved with 3rd party apps, but with some TVs you are limited again.

Most times my files, are below 4GiB, so there is no problem, but my reference video has 4.1GiB with crf=25, so crf=25.2 would solve my problem probably. but with handbrake-gtk 1:1.3.3.1-zhb-1ppa1~focal1 I do not see an option to use decimal values. On the other other hand mediainfo outputs crf=25,0

Any ideas? A constant bitrate is no solution for me.

[Deleted User 13735]

"Constant Quality Fractional Granularity" is a setting in my Windows HB 1.3.3, down to 0.25
And of course, NTFS is de rigueur in all my editing and delivery work.
Are you religiously opposed to running on another OS?

[linuxuser]

Are you talking of Windows, because you know, this option does not exist with Linux?

Searching for "Constant Quality Fractional Granularity" I found a problem with X264. Does this option exist with HEVC 10bit too?

A screenshot with this option would be very nice.

It is useless to talk about using handbrake with Windows. My Win-License belongs to a pc which is older than 10 years.

[Woodstock]

The NTFS limitation must be an issue just with Android, because I regularly use NTFS between Linux, Windows, and OSX, the limitation that OSX has NTFS writing disabled by default, even though Apple left the code in the driver. A quick Google search comes up with a free app that will mount NTFS drives on Android.

Another search for ExFAT support on android says that if the device supports SD cards larger than 32GB, it should have full ExFAT support.

Linux has had ExFAT support through FUSE for at least 4 years. You have to explicitly install it, though. I really should do that one of these days.

[Deleted User 13735]

granularity.jpg (88.41 KiB) Viewed 1245 times

[linuxuser]

Thanks a lot for the screenshot! There are big differences re preferences:

ii handbrake-gtk 1:1.3.3.1-zhb-1ppa1~focal1

handbrake-preferences1.png (90.37 KiB) Viewed 1241 times

handbrake-preferences2.png (111.9 KiB) Viewed 1241 times

Sorry for the German preferences, but I can't see anything which has to do with my problem.

[linuxuser]

The NTFS limitation must be an issue just with Android, because I regularly use NTFS between Linux, Windows, and OS X

Yes it is an Android problem, and to be more exact, it depends on the Software (Stock-ROM, Custom-ROM) of the mobile phone. Some work, some don't and with some, like LinageOS it depends on the file manager (the LinageOS filemanager works with NTFS)

While there is a chance to solve the problem using Android, maybe an app is needed, you have no chance with TVs. There are TVs (eg my Samsung) which use XFS as filesystem for encrypted recordings, but it cannot mount usbdrives using XFS.

It can be a nightmare, what works and what not. With FAT32 you are on the safe side.

[Deleted User 11865]

handbrake-preferences2.png (139.49 KiB) Viewed 1232 times

[linuxuser]

Thanks a lot, OMG I have no idea, why I didn't notice this.

[linuxuser]

Can it be, that crf=25.25 takes a lot longer than crf=25?

Speed = slow

From my understanding slow means, that the calculation is more exact and therefore the filesize is smaller.

But what means crf. Movement is better with smaller values, but does it influence the image too, eg blue sky with clouds and nearly no movement. Should there be a difference with a still picture with crf 22 or 27 as extreme example.

[rollin_eng]

Speed = slow

From my understanding slow means, that the calculation is more exact and therefore the filesize is smaller.

https://handbrake.fr/docs/en/1.3.0/tech ... tunes.html

[Deleted User 13735]

Can it be, that crf=25.25 takes a lot longer than crf=25?

Speed = slow

From my understanding slow means, that the calculation is more exact and therefore the filesize is smaller.

But what means crf. Movement is better with smaller values, but does it influence the image too, eg blue sky with clouds and nearly no movement. Should there be a difference with a still picture with crf 22 or 27 as extreme example.

It sounds like you are asking two questions.
25 and 25.00 are the same; e.g., index precision in itself will not affect the relative times. Over many samples, 25.25 could be a bit faster than 25, but individual mileage will absolutely vary.

Blue sky with clouds has lots of movement, often slow, and it will affect file size significantly.
A still photo hits the i-frames only, the rest of the GOP is now just roadsigns, so changing the RF will have little or no significant effect. Yes, you could expect a slideshow with no fades or transitions to be in the neighborhood of 100-200 times smaller than a corresponding motion video, and we mortals have far less control over that, even if we switch to ABR.

Experiment: Make a video from a few stills with no fades or transitions, straight cuts only, and encode at 50 Mb/s. See what you actually come up with.

[linuxuser]

Actually it are more than 2 questions. All around the crf optimization.

Estimated time calculation seems to be very unexact. With crf=25 it was 8h, don't know how long it took really. With crf=25.25, it started with 10h, changed to 30 and after 6h now I have 50%. I thought there could be a difference between an integer value and a decimal value.

I have 2 extrem differemt UHD videos, one with a lot movement and the other with nearly no movement.-

So I think, if crf=25 is fine for fast movement it should be ok for videos too with less movement, except a lower crf value creates better still images (pause) too.

Imagine a child is running on a place, everything very static, except the child. If the child is big, most of the child fills the screen, there will be a lot changes, but if the child is very small and moves a lot, most areas of the screen are static. Imagine there are a lot details on the static building, will this become better with lower crf?

[rollin_eng]

Changing your crf so little should not change your encode speed. Can you post logs from both encodes?

If you are also changing content then yes, encode speed will change.

[linuxuser]

I am sorry, but I don't have logs to compare. It was a question only, if decimal crf-values change the encoding speed dramatically. It takes as long as it takes and I do not have a lot UHD videos.

[rollin_eng]

Why no logs?

[Deleted User 11865]

There is nothing special about fractional rate factors (they're not QPs).

Higher bitrates do mean more time spent in binary arithmetic coding of the bitstream. So, everything else being equal, an RF of 20.75 would encode very slightly slower (on average) than the same encode at RF 21.00, and an RF of 21.25 would encode very slightly faster (on average) than the same encode at RF 21.00.

[Deleted User 13735]

If you are testing two different CRF values with the same video, you will need exactly the same settings. Only no one seems able to do that, so encode logs are required, as you were informed just above.

If you are testing two different videos with the same CRF value, forget it; all size bets are off, because you will be comparing apples and oranges.

You would do well to read this article thoroughly, and then ask questions, so that you won't get lost in speculation.
https://handbrake.fr/docs/en/1.3.0/tech ... s-abr.html