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

[mayazir]

I have a few downloaded series, which I try to fix and keep.
I use Avidemux to crop and resize video files to the output format HEVC x265.
I already edited one serie with 150+ episodes and everything was ok, each edited episode has more or less a similar weight.
But now I've started to edit a new serie and immediately saw a very weird thing - all episodes have a different weight.
It is not normal to see a such difference between edited files:

Episode 01: From 1,26 GB => 776 MB
Episode 14: From 1,31 GB => 769 MB
Episode 02: From 1,32 GB => 729 MB
Episode 15: From 1,33 GB => 548 MB
Episode 06: From 1,34 GB => 661 MB
Episode 07: From 1,34 GB => 669 MB
Episode 05: From 1,35 GB => 586 MB
Episode 11: From 1,36 GB => 716 MB
Episode 12: From 1,37 GB => 524 MB
Episode 04: From 1,37 GB => 515 MB
Episode 09: From 1,39 GB => 680 MB
Episode 10: From 1,39 GB => 659 MB
Episode 03: From 1,40 GB => 538 MB
Episode 08: From 1,40 GB => 582 MB
Episode 16: From 1,40 GB => 594 MB
Episode 17: From 1,40 GB => 552 MB
Episode 13: From 1,41 GB => 719 MB

How is possible this:

• The episode of 1,40 GB becomes 538 MB after the edition
• Another episode of also 1,40 GB becomes 594 MB after the edition
• And the episode of 1,26 GB becomes 776 MB

I tried to edit the same files again and again but always got the same result.
I also paid attention to the fact that

• all 1,40 GB files finally became 500+ MB
• all 1,39 GB files finally became 600+ MB
• all 1,34 GB files finally became 600+ MB
• all 1,37 GB files finally became 500+ MB

It makes no sense.

[davexnet]

It makes no sense.

file size = bitrate x running time

Once a file has been re-encoded, the size of the new file is determined purely from the settings in the x265 encoder
and the bitrate control (2-pass bit rate for a known size, CRF for unknown size)

With CRF bit rate control, the size is not known beforehand because it depends on the complxity of the source video.
soft/clean/low action/flat parts use less bitrate than action/sharp/noisy, etc,etc.

In general, the size of the source is irrelevant, since during the processing the source is fully decompressed and recompressed
in the encoder

[mayazir]

It makes no sense.

file size = bitrate x running time

Once a file has been re-encoded, the size of the new file is determined purely from the settings in the x265 encoder
and the bitrate control (2-pass bit rate for a known size, CRF for unknown size)

With CRF bit rate control, the size is not known beforehand because it depends on the complxity of the source video.
soft/clean/low action/flat parts use less bitrate than action/sharp/noisy, etc,etc.

In general, the size of the source is irrelevant, since during the processing the source is fully decompressed and recompressed
in the encoder

It still makes no sense.
How is 1,26 GB file can become 776 MB, and a 1,40 GB file become 552 MB?
All files are downloaded from the same source, with the same method, and have the same dimensions and using Avidemux I edit the same thing in all files - only the same crop and resize to the same size

I also keep the same configuration and the same order in editing.


[Attachment 76584 - Click to enlarge]

[davexnet]

Well the CRF value equates to a quality value, and the quality value equates to a mathematical calculation
about how the video is encoded. So two source videos that have the same file size can produce different size encodes for
the same CRF because, due to the complexity of the source, the compressibilty that results is different

See the section "How do quality and bitrate relate to each other?"
https://slhck.info/video/2017/02/24/crf-guide.html

[mayazir]

Well the CRF value equates to a quality value, and the quality value equates to a mathematical calculation
about how the video is encoded. So two source videos that have the same file size can produce different size encodes for
the same CRF because, due to the complexity of the source, the compressibilty that results is different

See the section "How do quality and bitrate relate to each other?"
https://slhck.info/video/2017/02/24/crf-guide.html

Check this screenshot, the order is by duration time.
It makes sense for the original size, but not for the edited file after Avidemux.


[Attachment 76586 - Click to enlarge]

[davexnet]

Perhaps you should post the mediainfo reports for at least two of the soource files so we can see
some details (use text view in mediainfo). Perhaps the source was encoded using ABR or 2-pass ,
where the size was determined before the encode

[poisondeathray]

What compression did the source files use ?

[mayazir]

perhaps you should post the mediainfo reports for at least two of the soource files so we can see
some details (use text view in mediainfo). Perhaps the source was encoded using abr or 2-pass ,
where the size was determined before the encode

What compression did the source files use ?

original files info

Episode 01: From 1,26 GB => 776 MB (duration: 41:20)

format : Mpeg-4
format profile : Base media
codec id : Isom (isom/iso2/avc1/mp41)
file size : 1.27 gib
duration : 41 min 20 s
overall bit rate mode : Variable
overall bit rate : 4 381 kb/s
frame rate : 29.970 fps
movie name : Ver el juego de la vida, capítulo 1 por vix
writing application : Lavf60.3.100

video
id : 1
format : Avc
format/info : Advanced video codec
format profile : High@l4
format settings : Cabac / 1 ref frames
format settings, cabac : Yes
format settings, reference frames : 1 frame
format settings, gop : M=1, n=60
codec id : Avc1
codec id/info : Advanced video coding
duration : 41 min 20 s
bit rate : 4 243 kb/s
width : 1 920 pixels
height : 1 080 pixels
display aspect ratio : 16:9
frame rate mode : Variable
frame rate : 29.970 (30000/1001) fps
minimum frame rate : 29.960 fps
maximum frame rate : 29.980 fps
color space : Yuv
chroma subsampling : 4:2:0
bit depth : 8 bits
scan type : Progressive
bits/(pixel*frame) : 0.068
stream size : 1.23 gib (97%)
codec configuration box : Avcc

audio
id : 2
format : Aac lc
format/info : Advanced audio codec low complexity
codec id : Mp4a-40-2
duration : 41 min 20 s
bit rate mode : Variable
bit rate : 128 kb/s
maximum bit rate : 130 kb/s
channel(s) : 2 channels
channel layout : L r
sampling rate : 44.1 khz
frame rate : 43.066 fps (1024 spf)
compression mode : Lossy
stream size : 37.9 mib (3%)
default : Yes
alternate group : 1

text #1
id : 1-cc1
format : Eia-608
muxing mode : Scte 128 / dtvcc transport
muxing mode, more info : Muxed in video #1
duration : 41 min 20 s
start time (commands) : 33 ms
start time : 1 s 869 ms
bit rate mode : Constant
stream size : 0.00 byte (0%)
count of frames before first event : 56
type of the first event : Popon

text #2
id : 1-cc4
format : Eia-608
muxing mode : Scte 128 / dtvcc transport
muxing mode, more info : Muxed in video #1
duration : 41 min 20 s
start time (commands) : 33 ms
bit rate mode : Constant
stream size : 0.00 byte (0%)

Episode 02: From 1,32 GB => 729 MB (duration: 43:24)

format : Mpeg-4
format profile : Base media
codec id : Isom (isom/iso2/avc1/mp41)
file size : 1.33 gib
duration : 43 min 24 s
overall bit rate mode : Variable
overall bit rate : 4 376 kb/s
frame rate : 29.970 fps
movie name : Ver el juego de la vida, capítulo 2 por vix
writing application : Lavf60.3.100

video
id : 1
format : Avc
format/info : Advanced video codec
format profile : High@l4
format settings : Cabac / 1 ref frames
format settings, cabac : Yes
format settings, reference frames : 1 frame
format settings, gop : M=1, n=60
codec id : Avc1
codec id/info : Advanced video coding
duration : 43 min 24 s
bit rate : 4 238 kb/s
width : 1 920 pixels
height : 1 080 pixels
display aspect ratio : 16:9
frame rate mode : Variable
frame rate : 29.970 (30000/1001) fps
minimum frame rate : 29.960 fps
maximum frame rate : 29.980 fps
color space : Yuv
chroma subsampling : 4:2:0
bit depth : 8 bits
scan type : Progressive
bits/(pixel*frame) : 0.068
stream size : 1.29 gib (97%)
codec configuration box : Avcc

audio
id : 2
format : Aac lc
format/info : Advanced audio codec low complexity
codec id : Mp4a-40-2
duration : 43 min 24 s
bit rate mode : Variable
bit rate : 128 kb/s
maximum bit rate : 130 kb/s
channel(s) : 2 channels
channel layout : L r
sampling rate : 44.1 khz
frame rate : 43.066 fps (1024 spf)
compression mode : Lossy
stream size : 39.7 mib (3%)
default : Yes
alternate group : 1

text #1
id : 1-cc1
format : Eia-608
muxing mode : Scte 128 / dtvcc transport
muxing mode, more info : Muxed in video #1
duration : 43 min 24 s
start time (commands) : 33 ms
start time : 2 s 903 ms
bit rate mode : Constant
stream size : 0.00 byte (0%)
count of frames before first event : 87
type of the first event : Popon

text #2
id : 1-cc4
format : Eia-608
muxing mode : Scte 128 / dtvcc transport
muxing mode, more info : Muxed in video #1
duration : 43 min 24 s
start time (commands) : 33 ms
bit rate mode : Constant
stream size : 0.00 byte (0%)

Episode 03: From 1,40 GB => 538 MB (duration: 45:48)

format : Mpeg-4
format profile : Base media
codec id : Isom (isom/iso2/avc1/mp41)
file size : 1.40 gib
duration : 45 min 48 s
overall bit rate mode : Variable
overall bit rate : 4 384 kb/s
frame rate : 29.970 fps
movie name : Ver el juego de la vida, capítulo 3 por vix
writing application : Lavf60.3.100

video
id : 1
format : Avc
format/info : Advanced video codec
format profile : High@l4
format settings : Cabac / 1 ref frames
format settings, cabac : Yes
format settings, reference frames : 1 frame
format settings, gop : M=1, n=60
codec id : Avc1
codec id/info : Advanced video coding
duration : 45 min 48 s
bit rate : 4 247 kb/s
width : 1 920 pixels
height : 1 080 pixels
display aspect ratio : 16:9
frame rate mode : Variable
frame rate : 29.970 (30000/1001) fps
minimum frame rate : 29.960 fps
maximum frame rate : 29.980 fps
color space : Yuv
chroma subsampling : 4:2:0
bit depth : 8 bits
scan type : Progressive
bits/(pixel*frame) : 0.068
stream size : 1.36 gib (97%)
codec configuration box : Avcc

audio
id : 2
format : Aac lc
format/info : Advanced audio codec low complexity
codec id : Mp4a-40-2
duration : 45 min 48 s
bit rate mode : Variable
bit rate : 128 kb/s
maximum bit rate : 130 kb/s
channel(s) : 2 channels
channel layout : L r
sampling rate : 44.1 khz
frame rate : 43.066 fps (1024 spf)
compression mode : Lossy
stream size : 41.9 mib (3%)
default : Yes
alternate group : 1

text #1
id : 1-cc1
format : Eia-608
muxing mode : Scte 128 / dtvcc transport
muxing mode, more info : Muxed in video #1
duration : 45 min 48 s
start time (commands) : 33 ms
start time : 2 s 436 ms
bit rate mode : Constant
stream size : 0.00 byte (0%)
count of frames before first event : 73
type of the first event : Popon

text #2
id : 1-cc4
format : Eia-608
muxing mode : Scte 128 / dtvcc transport
muxing mode, more info : Muxed in video #1
duration : 45 min 48 s
start time (commands) : 33 ms
bit rate mode : Constant
stream size : 0.00 byte (0%)

Episode 04: From 1,37 GB => 515 MB (duration: 44:52)

format : Mpeg-4
format profile : Base media
codec id : Isom (isom/iso2/avc1/mp41)
file size : 1.38 gib
duration : 44 min 52 s
overall bit rate mode : Variable
overall bit rate : 4 390 kb/s
frame rate : 29.970 fps
movie name : Ver el juego de la vida, capítulo 4 por vix
writing application : Lavf60.3.100

video
id : 1
format : Avc
format/info : Advanced video codec
format profile : High@l4
format settings : Cabac / 1 ref frames
format settings, cabac : Yes
format settings, reference frames : 1 frame
format settings, gop : M=1, n=60
codec id : Avc1
codec id/info : Advanced video coding
duration : 44 min 52 s
bit rate : 4 252 kb/s
width : 1 920 pixels
height : 1 080 pixels
display aspect ratio : 16:9
frame rate mode : Variable
frame rate : 29.970 (30000/1001) fps
minimum frame rate : 29.960 fps
maximum frame rate : 29.980 fps
color space : Yuv
chroma subsampling : 4:2:0
bit depth : 8 bits
scan type : Progressive
bits/(pixel*frame) : 0.068
stream size : 1.33 gib (97%)
codec configuration box : Avcc

audio
id : 2
format : Aac lc
format/info : Advanced audio codec low complexity
codec id : Mp4a-40-2
duration : 44 min 52 s
bit rate mode : Variable
bit rate : 128 kb/s
maximum bit rate : 130 kb/s
channel(s) : 2 channels
channel layout : L r
sampling rate : 44.1 khz
frame rate : 43.066 fps (1024 spf)
compression mode : Lossy
stream size : 41.1 mib (3%)
default : Yes
alternate group : 1

text #1
id : 1-cc1
format : Eia-608
muxing mode : Scte 128 / dtvcc transport
muxing mode, more info : Muxed in video #1
duration : 44 min 52 s
start time (commands) : 33 ms
start time : 2 s 903 ms
bit rate mode : Constant
stream size : 0.00 byte (0%)
count of frames before first event : 87
type of the first event : Popon

text #2
id : 1-cc4
format : Eia-608
muxing mode : Scte 128 / dtvcc transport
muxing mode, more info : Muxed in video #1
duration : 44 min 52 s
start time (commands) : 33 ms
bit rate mode : Constant
stream size : 0.00 byte (0%)

Episode 05: From 1,35 GB => 586 MB (duration: 44:22)

format : Mpeg-4
format profile : Base media
codec id : Isom (isom/iso2/avc1/mp41)
file size : 1.36 gib
duration : 44 min 22 s
overall bit rate mode : Variable
overall bit rate : 4 379 kb/s
frame rate : 29.970 fps
movie name : Ver el juego de la vida, capítulo 5 por vix
writing application : Lavf60.3.100

video
id : 1
format : Avc
format/info : Advanced video codec
format profile : High@l4
format settings : Cabac / 1 ref frames
format settings, cabac : Yes
format settings, reference frames : 1 frame
format settings, gop : M=1, n=60
codec id : Avc1
codec id/info : Advanced video coding
duration : 44 min 22 s
bit rate : 4 241 kb/s
width : 1 920 pixels
height : 1 080 pixels
display aspect ratio : 16:9
frame rate mode : Variable
frame rate : 29.970 (30000/1001) fps
minimum frame rate : 29.960 fps
maximum frame rate : 29.980 fps
color space : Yuv
chroma subsampling : 4:2:0
bit depth : 8 bits
scan type : Progressive
bits/(pixel*frame) : 0.068
stream size : 1.31 gib (97%)
codec configuration box : Avcc

audio
id : 2
format : Aac lc
format/info : Advanced audio codec low complexity
codec id : Mp4a-40-2
duration : 44 min 22 s
bit rate mode : Variable
bit rate : 128 kb/s
maximum bit rate : 130 kb/s
channel(s) : 2 channels
channel layout : L r
sampling rate : 44.1 khz
frame rate : 43.066 fps (1024 spf)
compression mode : Lossy
stream size : 40.6 mib (3%)
default : Yes
alternate group : 1

text #1
id : 1-cc1
format : Eia-608
muxing mode : Scte 128 / dtvcc transport
muxing mode, more info : Muxed in video #1
duration : 44 min 22 s
start time (commands) : 33 ms
start time : 1 s 869 ms
bit rate mode : Constant
stream size : 0.00 byte (0%)
count of frames before first event : 56
type of the first event : Popon

text #2
id : 1-cc4
format : Eia-608
muxing mode : Scte 128 / dtvcc transport
muxing mode, more info : Muxed in video #1
duration : 44 min 22 s
start time (commands) : 33 ms
bit rate mode : Constant
stream size : 0.00 byte (0%)

Episode 06: From 1,34 GB => 661 MB (duration: 43:56)

format : Mpeg-4
format profile : Base media
codec id : Isom (isom/iso2/avc1/mp41)
file size : 1.35 gib
duration : 43 min 56 s
overall bit rate mode : Variable
overall bit rate : 4 395 kb/s
frame rate : 29.970 fps
movie name : Ver el juego de la vida, capítulo 6 por vix
writing application : Lavf60.3.100

video
id : 1
format : Avc
format/info : Advanced video codec
format profile : High@l4
format settings : Cabac / 1 ref frames
format settings, cabac : Yes
format settings, reference frames : 1 frame
format settings, gop : M=1, n=60
codec id : Avc1
codec id/info : Advanced video coding
duration : 43 min 56 s
bit rate : 4 257 kb/s
width : 1 920 pixels
height : 1 080 pixels
display aspect ratio : 16:9
frame rate mode : Variable
frame rate : 29.970 (30000/1001) fps
minimum frame rate : 29.960 fps
maximum frame rate : 29.980 fps
color space : Yuv
chroma subsampling : 4:2:0
bit depth : 8 bits
scan type : Progressive
bits/(pixel*frame) : 0.068
stream size : 1.31 gib (97%)
codec configuration box : Avcc

audio
id : 2
format : Aac lc
format/info : Advanced audio codec low complexity
codec id : Mp4a-40-2
duration : 43 min 56 s
bit rate mode : Variable
bit rate : 128 kb/s
maximum bit rate : 130 kb/s
channel(s) : 2 channels
channel layout : L r
sampling rate : 44.1 khz
frame rate : 43.066 fps (1024 spf)
compression mode : Lossy
stream size : 40.2 mib (3%)
default : Yes
alternate group : 1

text #1
id : 1-cc1
format : Eia-608
muxing mode : Scte 128 / dtvcc transport
muxing mode, more info : Muxed in video #1
duration : 43 min 56 s
start time (commands) : 33 ms
start time : 2 s 903 ms
bit rate mode : Constant
stream size : 0.00 byte (0%)
count of frames before first event : 87
type of the first event : Popon

text #2
id : 1-cc4
format : Eia-608
muxing mode : Scte 128 / dtvcc transport
muxing mode, more info : Muxed in video #1
duration : 43 min 56 s
start time (commands) : 33 ms
bit rate mode : Constant
stream size : 0.00 byte (0%)

[poisondeathray]

It can be the expected behaviour - you are going from AVC to HEVC. You are assuming the encoder compression works exactly the same way - it does not. HEVC has different features and settings than AVC

e.g. if one episode has more scenes that can make use of more 64x64 CTU's the compression ratio can be higher, filesize smaller. AVC doesn't have 64x64 CTU's

If you want to rule out an avidemux bug, you can check with other tool sets using x265

If you used similar encoder, similar settings, similar rate control methods - then the relationship between filesizes pre and post between episodes should be similar.

[mayazir]

e.g. if one episode has more scenes that can make use of more 64x64 CTU's the compression ratio can be higher, filesize smaller. AVC doesn't have 64x64 CTU's

I don't understand this. AVC or something else, but why is in HEVC x265 the compression is not so constant?

[poisondeathray]

e.g. if one episode has more scenes that can make use of more 64x64 CTU's the compression ratio can be higher, filesize smaller. AVC doesn't have 64x64 CTU's

I don't understand this. AVC or something else, but why is in HEVC x265 the compression is not so constant?

The lossy compression is a function of the source content complexity . Higher complexity (more details, more motion, more noise) results in higher bitrates at a given CRF for any given encoder using any given setting . But you cannot compare directly between AVC and HEVC because they use slightly different compression methods when utilizing redundacies . I only mentioned one difference as an example, but there there are several differences

The AVC source video gets decompressed to uncompressed frames first before recompression to HEVC. Uncompressed video will have exactly the same filesize if the running time and pixel format are the same. Because it gets re-compressed using different compression method (different technology), the prior relationship pre/post and between files for AVC will not necessarily be the same for HEVC (or any other compression type)

It's still possible there is another bug, but what you describe is completely possible as well

[mayazir]

e.g. if one episode has more scenes that can make use of more 64x64 CTU's the compression ratio can be higher, filesize smaller. AVC doesn't have 64x64 CTU's

I don't understand this. AVC or something else, but why is in HEVC x265 the compression is not so constant?

The lossy compression is a function of the source content complexity . Higher complexity (more details, more motion, more noise) results in higher bitrates at a given CRF for any given encoder using any given setting . But you cannot compare directly between AVC and HEVC because they use slightly different compression methods when utilizing redundacies . I only mentioned one difference as an example, but there there are several differences

The AVC source video gets decompressed to uncompressed frames first before recompression to HEVC. Uncompressed video will have exactly the same filesize if the running time and pixel format are the same. Because it gets re-compressed using different compression method (different technology), the prior relationship pre/post and between files for AVC will not necessarily be the same for HEVC (or any other compression type)

It's still possible there is another bug, but what you describe is completely possible as well

Maybe I don't understand the technical nuances, but all this makes no sense because all original files are made with the same downloader, from the same platform, and on the same laptop. All these video files are the same series and have more or less the same actions. I could understand if some files were macrame weaving lessons and others were blockbusters.

Doesn't matter what the original format is, each format must have logic and sense in its size calculations.

[poisondeathray]

Doesn't matter what the original format is, each format must have logic and sense in its size calculations.

If you used CRF for x265 encoding, the "logic" and main determining factor is content complexity

But you don't know what rate control method the source used, you don't know what other settings were used except for a max GOP isze of 60

Perhaps the source was encoded using ABR or 2-pass , where the size was determined before the encode

Yes, and that's another possible difference . It's not clear what rate control method the source files used

If they used CRF, it's very possible the source filesizes would be very different between each source episode, instead of what he started with

[mayazir]

Doesn't matter what the original format is, each format must have logic and sense in its size calculations.

If you used CRF for x265 encoding, the "logic" and main determining factor is content complexity

But you don't know what rate control method the source used, you don't know what other settings were used except for a max GOP isze of 60

Perhaps the source was encoded using ABR or 2-pass , where the size was determined before the encode

Yes, and that's another possible difference . It's not clear what rate control method the source files used

If they used CRF, it's very possible the source filesizes would be very different between each source episode, instead of what he started with

Do you mean if the original format would be a few articles of 500 in English, its translation into French could be let's say 450-550 words per article, into Germany let's say 450-600 words, and it translates into HEVC could bounce from 100 to 800 words per article?
It's not normal... You can't translate a 500-word text in a 100-word article, then take another 500-word text and translate it in the same language in a 800 word text.

[poisondeathray]

Doesn't matter what the original format is, each format must have logic and sense in its size calculations.

If you used CRF for x265 encoding, the "logic" and main determining factor is content complexity

But you don't know what rate control method the source used, you don't know what other settings were used except for a max GOP isze of 60

Perhaps the source was encoded using ABR or 2-pass , where the size was determined before the encode

Yes, and that's another possible difference . It's not clear what rate control method the source files used

If they used CRF, it's very possible the source filesizes would be very different between each source episode, instead of what he started with

Do you mean if the original format would be a few articles of 500 in English, its translation into French could be let's say 450-550 words per article, into Germany let's say 450-600 words, and it translates into HEVC could bounce from 100 to 800 words per article?
It's not normal... You can't translate a 500-word text in a 100-word article, then take another 500-word text and translate it in the same language in a 800 word text.

There can be errors in translation. Word finding difficulty

And yes, because you don't know if there were restrictions in the translation. Maybe you had a 400 page limit for one translation, so you used abbreviations and shorthand to fit the limit . ie. Maybe the source files used 1 or 2pass encoding to hit the target limit instead of unrestricted CRF or quantizer encoding . The same series can easily vary +/-20 - 80% to begin with with similar running times had it used CRF encoding. The main difference is content complexity. Your source files didn't vary that much - so maybe it was restricted or used a target bitrate in the first place. When you re-encode with CRF encoding the "normal" content complexity relationship manifests

In some languages, there are contractions - e.g. "cannot" becomes "can't" . That's compression of 1 character. HEVC has compression methods that AVC doesn't have access to. Some words cannot use contractions - it's only feasible if that word has a contraction available - it's the same thing here. The content determines if certain compression techniques can be used (or cannot be used), as well as the compression type . If you had scenes with large similar textures, the the 64x64 CTUs could be used for HEVC resulting in higher compression ratios. But if another episode had only a few scenes like that, it wouldn't benefit as much. AVC couldn't use them at all

[_Al_]

Try to look at it backwards. Those original sizes make no sense. You cannot encode bunch of 20 files, even the same length, to the same (just a bit different) filesize and be always effective the same way.

That means, original was encoded with different quality (even per scenes). If original was encoded to size, it makes no scientific sense for further comparisons. It is disqualified for any further comparisons.

Or, as always, it is a bunch of problems, as usually what real life throws at us, it could be a reason mentioned above and even slight uneven x265 result, which throws system off even a bit more, whatever direction.

[mayazir]

Try to look at it backwards. Those original sizes make no sense. You cannot encode bunch of 20 files, even the same length, to the same (just a bit different) filesize and be always effective the same way.

That means, original was encoded with different quality (even per scenes). If original was encoded to size, it makes no scientific sense for further comparisons. It is disqualified for any further comparisons.

Or, as always, it is a bunch of problems, as usually what real life throws at us, it could be a reason mentioned above and even slight uneven x265 result, which throws system off even a bit more, whatever direction.

Original files do make sense, check here the video duration and the file size, it makes sense:


[Attachment 76624 - Click to enlarge]

[poisondeathray]

Original files do make sense, check here the video duration and the file size, it makes sense:

They make sense if the original files were encoded with restrictions such as bitrate targets . Similar to the analogy of using translation page limit like 400

Original files do not make sense if they were encoded with CRF

You can encode with restrictions too. Use a set bitrate target in x265 (or any encoder). Then you get your nice pattern instead of encoding according to content complexity.

[_Al_]

Original files do make sense, check here the video duration and the file size, it makes sense:

You cannot encode 5-7 episodes to exactly the same size and even with time tolerance 1 minute (that's a giveaway even more). That cannot happen using CRF. Better to say, statistically very, very improbable.
You might get hold of originals muxed in mkv or true source episodes, a couple or so. And try to encode them with x265 (possibly in different app). The rations will not be exactly the same as your x265 encodings to your 1.x GB size, but it should point at that direction of getting different ratios.

[_Al_]

Also try to compare sizes for episodes (x265 result) and actual action scenarios in them. Whatever defines more "action" for that kind of series.

Bitrate viewer of some sort would help as well. That would tell more why x265 was allocating more (or less) for what parts.

[mayazir]

Original files do make sense, check here the video duration and the file size, it makes sense:

They make sense if the original files were encoded with restrictions such as bitrate targets . Similar to the analogy of using translation page limit like 400

Original files do not make sense if they were encoded with CRF

You can encode with restrictions too. Use a set bitrate target in x265 (or any encoder). Then you get your nice pattern instead of encoding according to content complexity.

Where to set this value?

[mayazir]

Also try to compare sizes for episodes (x265 result) and actual action scenarios in them. Whatever defines more "action" for that kind of series.

Bitrate viewer of some sort would help as well. That would tell more why x265 was allocating more (or less) for what parts.

I already said all these video files are episodes of the same telenovela, downloaded from the same source with the same format, using the same downloader. All episodes have almost the same actions.

[mayazir]

Original files do make sense, check here the video duration and the file size, it makes sense:

You cannot encode 5-7 episodes to exactly the same size and even with time tolerance 1 minute (that's a giveaway even more). That cannot happen using CRF. Better to say, statistically very, very improbable.
You might get hold of originals muxed in mkv or true source episodes, a couple or so. And try to encode them with x265 (possibly in different app). The rations will not be exactly the same as your x265 encodings to your 1.x GB size, but it should point at that direction of getting different ratios.

1 min = 19 MB (Episode 01) and 1 min = 11 MB (Episode 04) is a big difference.

I also paid attention to the fact that:
all 1,40 GB files finally became 500+ MB
all 1,39 GB files finally became 600+ MB
all 1,34 GB files finally became 600+ MB
all 1,37 GB files finally became 500+ MB

Pay attention to the word "all", because this weird issue does have a pattern... weird illogic pattern...

[poisondeathray]

Original files do make sense, check here the video duration and the file size, it makes sense:

They make sense if the original files were encoded with restrictions such as bitrate targets . Similar to the analogy of using translation page limit like 400

Original files do not make sense if they were encoded with CRF

You can encode with restrictions too. Use a set bitrate target in x265 (or any encoder). Then you get your nice pattern instead of encoding according to content complexity.

Where to set this value?

Push the configure button

In the General Tab, there is Encoding Mode. Select Average Bitrate (Two Pass) and enter the bitrate. Or video size (two pass) and enter the size. 1pass VBR quality is not as good at CRF, it's significantly worse. But CRF final bitrates can vary as you 've seen - and they vary according to content complexity

Filesize = bitrate * running time . But there is video bitrate, audio bitrate, and container overhead for the total filesize

e.g. if you used 4243 kb/s, that would be like the first input video . It would be about the same size . Use lower bitrate if you want to reduce the size

There are pros/cons to each rate control method. If you restrict it using 1 or 2 pass, likely the ones that yielded larger sizes before using CRF rate control, will have lower quality . CRF is a rate control method that gives a very rough approximation of a certain level of "quality", lower values result in larger filesizes, higher quality - but the output filesize is unpredictable

[_Al_]

You should do something, otherwise this goes forever ....

-get x264 encoder and encode to crf (good quality) in different app posibly and check sizes

-get a bitrate viewer for your downloaded video,
for example there might be a steady shot, almost image like with no changes and when your original keeps allocating bitrates,
then that would mean their encoder used steady bitrate (not probable, but just to exclude it)

-bitrate viewer for you x265 result would tell you the same about allocating. If there is a rule. Then you know those sizes make sense (for x265 encoder)

-also thinking what makes and what does not make sense, like doing this for a while with other contents and there was no size problem (perhaps it matched so and so) and now it is off ...

[poisondeathray]

Also try to compare sizes for episodes (x265 result) and actual action scenarios in them. Whatever defines more "action" for that kind of series.

Bitrate viewer of some sort would help as well. That would tell more why x265 was allocating more (or less) for what parts.

I already said all these video files are episodes of the same telenovela, downloaded from the same source with the same format, using the same downloader. All episodes have almost the same actions.

What the encoder "sees" is different "actions" among the episodes, hence the different filesizes . ie. The content complexity overall of the larger files is higher.

I would bet money that you would see a simliar trend if you used x264 CRF, or XVID qp encoding. You will see that similar fluctuation in filesizes. eg episode 1 will be significantly larger than episode 4

[mayazir]

Also try to compare sizes for episodes (x265 result) and actual action scenarios in them. Whatever defines more "action" for that kind of series.

Bitrate viewer of some sort would help as well. That would tell more why x265 was allocating more (or less) for what parts.

I already said all these video files are episodes of the same telenovela, downloaded from the same source with the same format, using the same downloader. All episodes have almost the same actions.

What the encoder "sees" is different "actions" among the episodes, hence the different filesizes . ie. The content complexity overall of the larger files is higher.

I already started to convert all these files with UniConverter to show you the difference, and having only 3 converted files, I already see the logic.


[Attachment 76632 - Click to enlarge]

[poisondeathray]

I already started to convert all these files with UniConverter to show you the difference, and having only 3 converted files, I already see the logic.

And what encoder, settings, and rate control are you using? Why use the same encoder x265 with avidemux using a set bitrate as suggested ? Then you will see the logic.

It's just math

filesize = bitrate * running time.

If you use a set bitrate, the longer the running time, the larger the filesize

[mayazir]

I already started to convert all these files with UniConverter to show you the difference, and having only 3 converted files, I already see the logic.

And what encoder, settings, and rate control are you using? Why use the same encoder x265 with avidemux using a set bitrate as suggested ? Then you will see the logic.

It's just math

filesize = bitrate * running time.

If you use a set bitrate, the longer the running time, the larger the filesize

No, I don't use x265 for the UniConverter test, and there is no need.
Doesn't matter what I use because each converter must have a logic.
If video file #1 is 42 minutes long and video file #4 is 44 minutes long, then obviously file #4 should be larger in size.

[poisondeathray]

I already started to convert all these files with UniConverter to show you the difference, and having only 3 converted files, I already see the logic.

And what encoder, settings, and rate control are you using? Why use the same encoder x265 with avidemux using a set bitrate as suggested ? Then you will see the logic.

It's just math

filesize = bitrate * running time.

If you use a set bitrate, the longer the running time, the larger the filesize

No, I don't use x265 for the UniConverter test, and there is no need.
Doesn't matter what I use because each converter must have a logic.
If video file #1 is 42 minutes long and video file #4 is 44 minutes long, then obviously file #4 should be larger in size.

It depends on the bitrate. The logic is math

filesize = bitrate * running time

Had video #1 used a slightly higher bitrate than #4, then #1 would be larger.

If they used the same bitrates, then #4 would be larger


You can use set target bitrate encoding too, then you get your "logic". You probably won't understand until you prove it to yourself -so use avidemux with x265, use a target bitrate of say 2500

But if you use CRF encoding, or quantizer encoding, the bitrate varies based on content complexity