Welcome to Doom9's Forum, THE in-place to be for everyone interested in DVD conversion.

Before you start posting please read the forum rules. By posting to this forum you agree to abide by the rules.

 

Go Back   Doom9's Forum > Video Encoding > High Efficiency Video Coding (HEVC)

Reply
 
Thread Tools Search this Thread Display Modes
Old 4th September 2019, 08:45   #1  |  Link
rafacharkman
Registered User
 
Join Date: Jul 2019
Posts: 15
doubt about x265 no-lossless compress

in x265 has anyway to compress the videos just only removing the bits not being used in image?

I would also like to know if it is possible to do this kind of check(real bitrate of the image) and then compress the image by setting a minimum bitrate adjustable and the maximum bitrange being the real value of the bitrate image or less (no more than that)

My goal is to compress the video based only on the absolute value of the image(lossless) together with x265 quality-based rate control

Last edited by rafacharkman; 4th September 2019 at 09:05.
rafacharkman is offline   Reply With Quote
Old 4th September 2019, 23:35   #2  |  Link
Asmodian
Registered User
 
Join Date: Feb 2002
Location: San Jose, California
Posts: 4,331
x265 will never compress to a higher bitrate than "the real value of the bitrate image." It does not add extra filler bytes.

Simply use "--lossless", or what do you mean?
__________________
madVR options explained
Asmodian is offline   Reply With Quote
Old 5th September 2019, 01:56   #3  |  Link
rafacharkman
Registered User
 
Join Date: Jul 2019
Posts: 15
Quote:
Originally Posted by Asmodian View Post
x265 will never compress to a higher bitrate than "the real value of the bitrate image." It does not add extra filler bytes.

Simply use "--lossless", or what do you mean?
for example, I have a video to compress and the current bitrate is 42.000.000 bits but it's not the real bitrate of the image(i guess) which should be around 10.000.000 bits. '--lossless' leaves huge file size unnecessarily(more than 42.000.000) and '--cu-lossless' is very heavy in general.

I want(if it's possible) to use only the real bit value of each frame that exists in the image and discard the rest. if possible too, delimit that each frame have at least X bits.

Last edited by rafacharkman; 5th September 2019 at 02:14.
rafacharkman is offline   Reply With Quote
Old 5th September 2019, 02:23   #4  |  Link
Cary Knoop
Cary Knoop
 
Cary Knoop's Avatar
 
Join Date: Feb 2017
Location: Newark CA, USA
Posts: 396
You are confused, a decoded RGB frame consists of width*height*bit-depth*3 pixels.
Cary Knoop is offline   Reply With Quote
Old 5th September 2019, 18:49   #5  |  Link
rafacharkman
Registered User
 
Join Date: Jul 2019
Posts: 15
Quote:
Originally Posted by Cary Knoop View Post
You are confused, a decoded RGB frame consists of width*height*bit-depth*3 pixels.
I guess kkk

Each image uses a certain amount of pixels which as you mentioned(width * height), but each image has a pixel table that you use to define which color will be used in each pixel. This table defines the actual bits of the image. When you reduce the table, it simplifies the image pixels, but when you add in table, doesn't change the image because the machine only uses pixels that it knows where to put it (unless an algorithm judges and puts it but not ideal)

Is it possible to find this value proportional to color table image and use it in compress without put more bits than the color table supports? this value in this case would be considered 'lossless compression'.

I say this because it is easy to detect in very large files, where you have a gradient in a scene but it is not clean, so I know the image contains more bits than the color table registers.(in this case, the table has been simplified and it's not a original and it's just allocating 'empty bits' in the file)

Last edited by rafacharkman; 5th September 2019 at 19:14.
rafacharkman is offline   Reply With Quote
Old 5th September 2019, 19:07   #6  |  Link
Cary Knoop
Cary Knoop
 
Cary Knoop's Avatar
 
Join Date: Feb 2017
Location: Newark CA, USA
Posts: 396
Quote:
Originally Posted by rafacharkman View Post
Each image uses a certain amount of pixels which as you mentioned(width * height), but each image has a pixel table that you use to define which color will be used in each pixel. This table defines the actual bits of the image. When you reduce the table, it simplifies the image pixels, but when you add in table, doesn't change the image because the machine only uses pixels that it knows where to put it (unless an algorithm judges and puts it but not ideal)

Is it possible to find this value proportional to color table image and use it to compress, without put more bits than the color table supports? this value in this case would be considered 'lossless compression'.

I say this because it is easy to detect in very large files, where you have a gradient in a scene but it is not clean, so I know the image contains more bits than the color table registers.(in this case, the table has been simplified and need less than proportional to the image)
I think you don't know what you are talking about.
Cary Knoop is offline   Reply With Quote
Old 5th September 2019, 19:18   #7  |  Link
rafacharkman
Registered User
 
Join Date: Jul 2019
Posts: 15
Quote:
Originally Posted by Cary Knoop View Post
I think you don't know what you are talking about.
How does color distribution work in the image? if I understand that maybe I can understand where I'm missing

Last edited by rafacharkman; 5th September 2019 at 19:40.
rafacharkman is offline   Reply With Quote
Old 6th September 2019, 17:51   #8  |  Link
MeteorRain
結城有紀
 
Join Date: Dec 2003
Location: NJ; OR; Shanghai
Posts: 893
You were looking for color palette compression. Yes you *can* do that to reduce the size, but why using such low-efficiency technology when we have much better entropy encoding?

Let's say your image is 40MiB. After color palette compression you make it 30MiB. While x265 along with motion estimation and entropy encoding can make it 15MiB. Why bother using the worse one?

Color palette is no more than a low-efficiency entropy encoding.
__________________
Projects
x265 - Yuuki-Asuna-mod Download / GitHub
TS - ADTS AAC Splitter | LATM AAC Splitter | BS4K-ASS
Neo AviSynth+ filters - F3KDB | FFT3D | DFTTest | MiniDeen | Temporal Median

Last edited by MeteorRain; 6th September 2019 at 17:54.
MeteorRain is offline   Reply With Quote
Old 10th September 2019, 17:13   #9  |  Link
benwaggoner
Moderator
 
Join Date: Jan 2006
Location: Portland, OR
Posts: 4,056
Quote:
Originally Posted by MeteorRain View Post
You were looking for color palette compression. Yes you *can* do that to reduce the size, but why using such low-efficiency technology when we have much better entropy encoding?

Let's say your image is 40MiB. After color palette compression you make it 30MiB. While x265 along with motion estimation and entropy encoding can make it 15MiB. Why bother using the worse one?

Color palette is no more than a low-efficiency entropy encoding.
Ah, I remember the good old days of optimizing GIF, Smacker, and Apple Graphics codec content. I was able to get several hours of reversible LEGO assembly instructions videos on the very first Mindstorms CD-ROM through clever 3-bit palletization techniques automated through DeBabelizer.

Palletization can be a valuable technique for some very specific kinds of content, like screen recordings or Flash-style animation. But applying it in preprocessing before using HEVC or other modern codec will generally worsen results by adding shaper edges. Some of the Screen Content Coding Extensions to HEVC can make encoding palletized content more efficient, but I'm not sure how common those features are supported in real-world encoders and decoders.
__________________
Ben Waggoner
Principal Video Specialist, Amazon Prime Video

My Compression Book
benwaggoner is offline   Reply With Quote
Old 10th September 2019, 20:23   #10  |  Link
Asmodian
Registered User
 
Join Date: Feb 2002
Location: San Jose, California
Posts: 4,331
Quote:
Originally Posted by rafacharkman View Post
How does color distribution work in the image? if I understand that maybe I can understand where I'm missing
It assigns every pixel a 24 or 30 bit color value, 8 or 10 bits per R, G, or B component. Actually it is usually 12 or 15 bits per pixel due to subsampled chroma. 8 or 10 bits per component for Y, Cb, and Cr but with Cb and Cr only having one value for every four pixels (half the resolution in both dimensions).

If you are still interested look into CABAC which is the better arithmetic coding method used in both H.264 and H.265. Then start looking into quantization and residual coding. There is no 'color table' in modern high bit depth image/video formats and image and video compression has come a long way. The amount of compression already done by HEVC while in its 42Mbps form will shock you.
__________________
madVR options explained

Last edited by Asmodian; 10th September 2019 at 21:17. Reason: added info
Asmodian is offline   Reply With Quote
Reply

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +1. The time now is 01:11.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2022, vBulletin Solutions Inc.