Use of x265's --crop-rect and --overscan

[yup]

Hi all!

Please explain how proper use option
--crop-rect --overscan
My source is DAR 4:3 and 50Hz, near compliant frame size 1280x720. I am change size to 960x720 and add borders.
Avisynth script.
XXXResize(960,720)
AddBorders(160,0,160,0)
During encoding add switch
--crop-rect 160,0,160,0 --overscan show
I do not want spent time for encoding borders, it is possible?

yup.

[microchip8]

Hi all!

Please explain how proper use option
--crop-rect --overscan
My source is DAR 4:3 and 50Hz, near compliant frame size 1280x720. I am change size to 960x720 and add borders.
Avisynth script.
XXXResize(960,720)
AddBorders(160,0,160,0)
During encoding add switch
--crop-rect 160,0,160,0 --overscan show
I do not want spent time for encoding borders, it is possible?

yup.

Please don't hijack threads. Open a new topic about your question

Mod note: This was split from the x265 dev thread.

[benwaggoner]

I do not want spent time for encoding borders, it is possible?
Do you believe you are spending time encoding borders? Do you see slower encoding time when you add the padding than when you don't?

Even if the encoder tries to encode image outside of the active image area (which is probably (?) the correct behavior), a big block of Y'=16, U'=0, V'=0 will encode very quickly?

That said, why not just encode at 960x720? I imagine any device that can decode HEVC should be able to handle arbitrary mod16 frame sizes. If you've found an exception, please share!

[yup]

Hi benwaggoner!

Do you believe you are spending time encoding borders? Do you see slower encoding time when you add the padding than when you don't?
Yes I see some speed decreasing. Do not forget that x265 not very fast encoder if comparing to x264 and small decreasing for clip length 1 hour can add hours for encoding time. 1280 bigger 960 by factor 1.3. Also hard border between black area and video will be spent time for motion estimation, when one part smooth moving other very close, static.

That said, why not just encode at 960x720?

It is not compliant size and if I want remux encoded video and write to BD, player can not show this source.
I read help file for x264 and understand that the same option related for decoding stage.
Will be spent time for encoding black borders.

yup.

[Asmodian]

It is not compliant size and if I want remux encoded video and write to BD, player can not show this source.
But HEVC itself is not compliant so even at 1280x720 if you remux the encoded video and write to BD the player can not show it.
That said, why not just encode at 960x720? I imagine any device that can decode HEVC should be able to handle arbitrary mod16 frame sizes. If you've found an exception, please share!

[yup]

Asmodian!
See
http://forum.doom9.org/showthread.php?p=1692610#post1692610
BD will be support HEVC and 1280[720 50 Hz compliant video.

yup.

[benwaggoner]

Asmodian!

See

http://forum.doom9.org/showthread.php?p=1692610#post1692610

BD will be support HEVC and 1280[720 50 Hz compliant video.



yup.


A spec available in the first half of next year would be quite premature to start encoding for now.. Particularly around features like this, which optical formats tend to be quite fussy about.


-Ben Waggoner (via TapaTalk)

[Asmodian]

Asmodian!
See
http://forum.doom9.org/showthread.php?p=1692610#post1692610
BD will be support HEVC and 1280[720 50 Hz compliant video.

yup.

That link only talks about 4K HEVC, where did you get anything about 1280x720 HEVC? 1280x720 would probably work but 960x720 would probably work too.