Encoder tune: Film

[markfilipak]

I sincerely hope you and your's are well and safe.

H.264
Encoder tune: Film

Can you folks give me a technical description of what this encoder setting does? I suspect there's more to it than simply setting the output to p24, eh?

Perhaps there's a better reference than 'https://handbrake.fr/docs/en/1.3.0/tech ... tunes.html'? ...or maybe not.

HandBrake version: 1.3.1 (2020010400)

I must be getting old. Whenever I close the Help window, HandBrake is gone. I just can't remember to use the [< Back] button. I know, I know, that's how web browsers work. But I'm not used to an application doing that. Oh, well.

[rollin_eng]

https://superuser.com/questions/564402/ ... -x264-tune

[markfilipak]

https://superuser.com/questions/564402/ ... -x264-tune

Thanks... but...
"film – intended for high-bitrate/high-quality movie content. Lower deblocking is used here."
Assuming that HB is using ffmpeg -- I thought it was just using the libraries -- what does the quote above mean?
I know what deblocking is, but what does "Lower" mean?
Does it mean smaller macroblocks?
Does it mean more frequent I-frames?
Or does it mean something else?

Warm Regards,
Mark.

[rollin_eng]

- film (psy tuning):
--deblock -1:-1 --psy-rd <unset>:0.15

[markfilipak]

- film (psy tuning):
--deblock -1:-1 --psy-rd <unset>:0.15

Thank you. Yes, I saw that. It's too cryptic for me to understand.

I have a correction. I do not know what deblocking is. I know what macroblocks are and what goes into them. I'm sorry about that. Sometimes I write without thinking.

[rollin_eng]

http://www.chaneru.com/Roku/HLS/X264_Settings.htm

[mduell]

The linked to https://forum.doom9.org/showthread.php?t=109747 covers both the settings and what they do.

[Deleted User 11865]

https://en.wikipedia.org/wiki/Deblocking_filter

[markfilipak]

@rollin_eng, @mduell, @Rodeo

Thank you for the links. I see that "deblocking" simply means glossing over evident blocking, duh! May I wax technical?

It occurs to me that an encoder is applied in 2 quite differing circumstances: 1, raw encoding, and 2, transcoding. The difference is that in transcoding, the source already has some blocking that might need deblocking. Thus, a deblocking filter. My questions are: Just how much 'fuzzing' occurs? And where? Solely along the edges of existing macroblocks or across the entire macroblock? In other words, is the filter aware of the dimensions and base lines of the source's existing blocking, or does it low-pass everything? If you don't reply/comment, then I'll assume that deblocking is 'smart' and low-passes solely along the edges of macroblocks.

I do have one additional, possibly related question: Is this related to twitter? (Disclaimer: I've seen the word but not found an adequate explantion what it is, so I'll proceed with my notion of what twitter is.) By "twitter", I mean the effect I've seen where, for example, an actor's face momentarily sharpens and seems to pop when there's little/no motion, then slightly blurs when motion resumes.

Thanks again. You, and HandBrake are the best.

[mduell]

No, the encoder knows nothing about the upstream macroblocks; it's just fed the pixel data (possibly after other post-decode filtering, including potentially deblocking, resizing, denoising, etc).

[markfilipak]

No, the encoder knows nothing about the upstream macroblocks; it's just fed the pixel data (possibly after other post-decode filtering, including potentially deblocking, resizing, denoising, etc).

No, no, not the encoder, the filter. Does the deblocking filter know that the frames it is being fed have been decoded and were previously macroblocked & encoded? More importantly, does the deblocking filter know the physical features of the previous macroblocks: the size and base lines and colorspace. Or is the deblocking filter working 'in the dark'.

You may wonder why I'm asking such an obvious question -- "Of course the deblocking filter knows everything about the blocking, it's a deblocking filter" -- well, I'm learning that being illogical sometimes leads to truth.

Regards,
Mark.

[mduell]

Neither a standalone deblocking filter, nor the in-loop deblocking in the encoder, are aware of any prior macroblocking. They're fed pixels only.

[markfilipak]

Neither a standalone deblocking filter, nor the in-loop deblocking in the encoder, are aware of any prior macroblocking. They're fed pixels only.

Oh, my, that's too bad.