So... x265 can't match x264 for lossless encoding?

[Asilurr]

A couple of tests on video content generated from still images.

#1 Lenna (preview: wikipedia.org/wiki/File:Lenna_(test_image).png; download: lenna.org), 512x512 RBG24 converted to 8-bit 4:4:4.
x264vs || relative filesize 100.0%
x265vs || 104.7%

#2 M87* (preview: wikipedia.org/wiki/File:Black_hole_-_Messier_87.jpg; download: eso.org/public/archives/images/original/eso1907a.tif), 7416x4320 RGB48 converted to 3708x2160 10-bit 4:4:4. Do note that the original TIFF is a gargantuan 183 MB file.
x264vs || 100.0%
x264f || 100.8%
x265vs || 103.2%
x265f || 104.2%

[gdgsdg123]

Originally Posted by benwaggoner

HEVC in particular has intraframe prediction and other advanced tools that should squeeze even more bits out.

They aren’t all on even in —preset placebo, though! Using —cu-lossless and —tskip can help improve efficiency and quality of near-lossless encoding. Cu-lossless allows any given CTU to use lossless mode if it is more efficient; real lossless is just using that for the whole frame.

The docs give somewhat different opinion.





About --tskip:

Lossless — x265 documentation

Transform Skip
A somewhat related feature, --tskip tells the encoder to evaluate transform-skip (bypass DCT but with quantization still enabled) when coding small 4x4 transform blocks. This feature is intended to improve the coding efficiency of screen content (aka: text on a screen) and is not really intended for lossless coding. This feature should only be enabled if the content has a lot of very sharp edges in it, and is mostly unrelated to lossless coding.

About --cu-lossless:

Command Line Options — x265 documentation

--cu-lossless, --no-cu-lossless
For each CU, evaluate lossless (transform and quant bypass) encode of the best non-lossless mode option as a potential rate distortion optimization. If the global option --lossless has been specified, all CUs will be encoded as lossless unconditionally regardless of whether this option was enabled. Default disabled.

Only effective at RD levels 3 and above, which perform RDO mode decisions.

And 1 thing I must emphasize... near-lossless = lossy.

[foxyshadis]

Heavily filtered video might sometimes benefit from tskip, but natural video never will. And since x265 doesn't even implement the screen coding range extensions, the actual capabilities of tskip and other screen coding tunings are very nerfed.

[pookpooi]

The rumored Sony's new video codec XEVC which is based on HEVC version 2 claims 240Mbps peak bitrate lossless compressing 1920 x 1080, 12 bit depth, 24fps. I did a calculation and get 1:7.12 ratio.

source: https://www.eoshd.com/2018/12/sonys-...aw-at-240mbit/

[benwaggoner]

Originally Posted by pookpooi

The rumored Sony's new video codec XEVC which is based on HEVC version 2 claims 240Mbps peak bitrate lossless compressing 1920 x 1080, 12 bit depth, 24fps. I did a calculation and get 1:7.12 ratio.

source: https://www.eoshd.com/2018/12/sonys-...aw-at-240mbit/

Visually lossless at that rate is certainly feasible, but mathematically lossless is impossible unless they're doing some sort of prefiltering.

[gdgsdg123]

Originally Posted by poisondeathray

FFV1 (in interframe mode)...

Hmm?..

FFV1 Video Codec Specification

The FFV1 video codec is a simple and efficient lossless intra-frame only codec.

Originally Posted by poisondeathray

If source has identical content, duplicate frames, then lagarith can be better (null frame option)

I doubt it.

As Lagarith is sort of an old outdated codec... And more advanced codecs (like x264, x265) should have implemented similar capabilities in the algorithms.

[gdgsdg123]

Originally Posted by poisondeathray

If source has identical content, duplicate frames, then lagarith can be better (null frame option)

You might be correct... See this.

[poisondeathray]

Originally Posted by gdgsdg123

Hmm?..

Scroll down


4.8.17 intra

intra indicates the relationship between frames. Inferred to be 0 if not present.
value relationship
0 frames are independent or dependent (keyframes and non keyframes)
1 frames are independent (keyframes only)
Other reserved for future use



https://trac.ffmpeg.org/wiki/Encode/FFV1
GOP size -g integer >= 1 For archival use, GOP-size should be "1".

I doubt it.

As Lagarith is sort of an old outdated codec... And more advanced codecs (like x264, x265) should have implemented similar capabilities in the algorithms.

Yes, but null frames is a special case with pure duplicates . And it's an intra codec, usually compression is worse on typical content


eg.

blankclip(length=1000, width=1280,height=720, pixel_type="YV12")

ie. 1001 blank frames, 1280x720 , 24fps, YUV 4:2:0

x264 --qp 0 mp4 container => 49.2kb
x264 --qp 0 --keyint 1001 mp4 container => 48.6kb
lagarith with null frames, avi container => 31.4kb

Originally Posted by gdgsdg123

You might be correct... See this.

I have no idea what you're trying to say there

Maybe try google translate

[gdgsdg123]

Originally Posted by poisondeathray

Scroll down

https://trac.ffmpeg.org/wiki/Encode/FFV1
GOP size -g integer >= 1 For archival use, GOP-size should be "1".

I doubt such behavior matches the definition of intra-frame only...

Originally Posted by poisondeathray

I have no idea what you're trying to say there

Maybe try google translate

Another time then...

Hint: Those numbers are file sizes in Bytes.

[benwaggoner]

Originally Posted by gdgsdg123

You might be correct... See this.

Although skip frames in the elementary stream are also possible in H.265 and HEVC. I'm not sure if x265 will use those with IDR-only encoding. It could be a useful option to add.

[gdgsdg123]

Originally Posted by benwaggoner

Although skip frames in the elementary stream are also possible in H.265 and HEVC. I'm not sure if x265 will use those with IDR-only encoding. It could be a useful option to add.

Merging such duplicates would be almost the most obvious way in exploiting redundancy.

And for people who came up with: general compression, motion estimation, psycho-visual optimization... such state-of-the-art stuffs. There's no possibility that they ain't aware of this.



So?..

On x264's Handling regards Consecutive Duplicate Frames

Conclusion

Absurd, isn't it?
Bewildered too at first... But then soon sort of understood its design language behind this seeming absurdity.
(To be continued...)

[benwaggoner]

Originally Posted by gdgsdg123

Merging such duplicates would be almost the most obvious way in exploiting redundancy.

And for people who came up with: general compression, motion estimation, psycho-visual optimization... such state-of-the-art stuffs. There's no possibility that they ain't aware of this.

Oh, I'm sure they do. But one advantage of a true skip frame is that it needed rest the maximum GOP duration encoder. So a 150 frame GOP could potentially encapsulate hundreds of playback frames in anime, for example.