Avidemux (crop & resize) to output format MP4 Muxer (HEVC x265) - glitch

[mayazir]

..

..

I feel like we talk a different English.
I never asked why a 1,26 GB video file becomes an 800 MB or 700 MB file after the conversion.
I understand that the video file size = its bitrate x running time.
I just want to understand what the bug or glitch or whatever is that makes the conversion illogical.
Read the title, I mentioned the HEVC x265 compression and this is what works wrong because with other compressions everything is ok.

Look at this screenshot and compare the results:


[Attachment 76637 - Click to enlarge]

How is possible you don't see it?
This list is ordered by the running time of each video file.
That's why all original size numbers go from the smallest to the biggest.
The same with UniConverter results.

But all files edited with Avidemux as HEVC x265 have no logical explanation for their sizes.

[poisondeathray]

I feel like we talk a different English.
I never asked why a 1,26 GB video file becomes an 800 MB or 700 MB file after the conversion.
I understand that the video file size = its bitrate x running time.
I just want to understand what the bug or glitch or whatever is that makes the conversion illogical.
Read the title, I mentioned the HEVC x265 compression and this is what works wrong because with other compressions everything is ok.

Everything looks ok

It's because you used the wrong settings

If you understand that filesize = bitrate x running time , then enter the bitrate. It's really that simple

How is possible you don't see it?

Of course I see it .

You will get the same trend with x265 if you used the a target bitrate. But you didn't use a target bitrate. You used the wrong rate control method

Please re-read the instructions in the earlier post about how to enter an average bitrate

If you would rather have quality based encoding with roughly similar level of quality - you will get fluctuating filesizes dependent on content complexity - then use CRF encoding instead of bitrate target

[mayazir]

I feel like we talk a different English.
I never asked why a 1,26 GB video file becomes an 800 MB or 700 MB file after the conversion.
I understand that the video file size = its bitrate x running time.
I just want to understand what the bug or glitch or whatever is that makes the conversion illogical.
Read the title, I mentioned the HEVC x265 compression and this is what works wrong because with other compressions everything is ok.

Everything looks ok

It's because you used the wrong settings

If you understand that filesize = bitrate x running time , then enter the bitrate. It's really that simple

How is possible you don't see it?

Of course I see it .

You will get the same trend with x265 if you used the a target bitrate. But you didn't use a target bitrate. You used the wrong rate control method

Please re-read the instructions in the earlier post about how to enter an average bitrate

If you would rather have quality based encoding with roughly similar level of quality - you will get fluctuating filesizes dependent on content complexity - then use CRF encoding instead of bitrate target

Do you mean I didn't configure it the correct way?
OK, here is the screenshot, what is wrong here?
And why does it need a configuration if all other compression works correctly without any specific configuration?


[Attachment 76639 - Click to enlarge]

[poisondeathray]

Do you mean I didn't configure it the correct way?

Yes - if what you wanted was increasing filesize proportional to the duration - you want to use a target bitrate

Why?

Because filesize = bitrate * running time

If you understand that equation, a given bitrate means the filesize will increase .

please re-read post # 24 for instructions

And why does it need a configuration if all other compression works correctly without any specific configuration?

I don't know what "all other compression" is - maybe the default settings are setup differently - ie different rate control method ,such as VBR , or maybe has VBV capping .

[mayazir]

Do you mean I didn't configure it the correct way?

Yes - if what you wanted was increasing filesize proportional to the duration - you want to use a target bitrate

Why?

Because filesize = bitrate * running time

If you understand that equation, a given bitrate means the filesize will increase .

please re-read post # 24 for instructions

And why does it need a configuration if all other compression works correctly without any specific configuration?

I don't know what "all other compression" is - maybe the default settings are setup differently - ie different rate control method ,such as VBR , or maybe has VBV capping .

Ok, that's what I asked, but no one told me "It's some kind of issue with Avidemux or HEVC x265".
Instead, you all started to explain to me that size = bitrate x time running.
Now, I see the problem is Avidemux or this compression in Avidemux because every converter I have used until now, used to convert files without any specific bitrate setup.

Yes, I saw #24, but I don't understand what bitrate should I use.
This is the original video file info, what should I use then?

format : Mpeg-4
overall bit rate mode : Variable
overall bit rate : 4 381 kb/s
frame rate : 29.970 fps
bit rate : 4 243 kb/s
frame rate mode : Variable
frame rate : 29.970 (30000/1001) fps

And if I should use a specific bitrate for each video?
Or choose the average one?

[poisondeathray]

Now, I see the problem is Avidemux or this compression in Avidemux because every converter I have used until now, used to convert files without any specific bitrate setup.

If you want some trend where increasing running time, results in relatively larger filesizes , then a set bitrate target must be set for ANY encoder, even if it does it in the background without your knowledge.

Why?

Because....

Filesize = bitrate x running time

Yes, I saw #24, but I don't understand what bitrate should I use.
This is the original video file info, what should I use then?

format : Mpeg-4
overall bit rate mode : Variable
overall bit rate : 4 381 kb/s
frame rate : 29.970 fps
bit rate : 4 243 kb/s
frame rate mode : Variable
frame rate : 29.970 (30000/1001) fps

Filesize = bitrate x running time

So if you wanted that episode, for the video stream to be 1/2 the size, you'd use 1/2 the bitrate . But remember there is audio and container overhead too. For example lets say 2100 kb/s. Then that video stream alone (not counting audio stream, or other streams) would be about 1/2 the size

And if I should use a specific bitrate for each video?
Or choose the average one?

If you wanted that trend where running time increases and filesize increase, you use the same bitrate (whatever you choose) for that set of episodes , otherwise the trend won't show...

Why?

Because filesize = bitrate x running time.

Notice the average bitrate of the episodes was around 4200kb/s . So very likely they used a target bitrate VBR, or even CBR encoding. CBR is very common for station broadcast

So if you wanted to reduce the filesize, and keep that trend where running time increases and filesize increase, but you want to reduce the filesizes, pick something lower than 4000kb/s . 2100kb/s would be roughly half for the video stream




CRF is the default rate control setting for x264, x265 - because most people care about a certain evenness to the level of quality. They don't want one scene or episode to look bad in comparison

When you use a set target bitrate for all episodes - some scenes or episodes are going to look worse in quality, some better because you are placing an extra restriction on the encoding. You're "forcing" it to fit that bitrate.

If you take the translation analogy - a target bitrate is like setting an artificial 100 word limit to the translation. But what if you need 200 words to express the translation properly? There will be problems, some misunderstandings - same in video compression - there will be more quality problems and fluctuations

When you set a target bitrate, some scenes might get too little bitrate = bad quality, some too much = wasted bitrate (inefficient) .

CRF encoding gives the bitrate required for that content complexity and CRF value - More bitrate for complex scenes, less bitrate for simple scenes - but overall you get a roughly similar level of quality. So the end filesize can vary, it's unpredictable. You claim that the episodes content are roughly the same, but you are wrong. Human eye cannot see everything that encoder "sees", things like fine noise, motion vectors, macroblock similarities... etc... Those are the things that make up compression

[Alwyn]

Now, I see the problem is Avidemux or this compression in Avidemux because every converter I have used until now, used to convert files without any specific bitrate setup.

There is (probably) no problem: you are currently encoding with CRF (your image in post #33). On the Configure screen, do a test: from the Rate Control>Encoding Mode droplist, choose "Average bitrate, 2 pass" and set say 4000kbps. That should be good for H265 compared to your H264 originals.

Encode a couple of your cropped/resized files and see how the sizes compare.

[_Al_]

@mayazir

To not use CRF using UniConverter is simply leading nowhere.

You did not tell what settings were used in UniConverter. It is guessed, by pdr that it is target bitrate or something because resulting size follows video length curve, same as your first video. Can you provide settings that were used?