Issue with output file size

[jho82]

Discrepancy with output file size
I have encoded 2 videos for my housemate that she recorded on her video camera (1080p 25fps).
One file is 43mins (Barre - 389mb), the other is 46mins (Dance - 1.25GB).
What i'm trying to understand is how an additional 3 mins of footage has resulted in a video that has TRIPLED in size?? I went back through other encodes that I've done for her, and noticed the same thing - both sets of videos will have between 3-5mins difference, but one will be 2-3x larger.
I thought that it was perhaps because they were consecutive encodes and it's perhaps a bug in Handbrake, but even when trying it as a single encode, then closing and restarting HB, still produces the same result.

Original footage is 1080p, 25fps (AVCHD container)
Output is 1080p, 25fps, mp4 container, very fast encode preset, no subs

Can not work out why this keeps happening, but it's driving both of us crazy because it doesn't make any sense.

Steps to reproduce the problem (If Applicable):




HandBrake version (e.g., 1.0.0):
1.3.3



Operating system and version (e.g., Ubuntu 16.04 LTS, macOS 10.13 High Sierra, Windows 10 Creators Update):
Mac OS Catalina 10.15.7




HandBrake Activity Log ***required*** (see How-to get an activity log)

Code: Select all

Barre - https://pastebin.com/mie7TirL (exp 6mths)
Dance - https://pastebin.com/JjWVs5qi (exp 6mth)

[Woodstock]

Are you SURE the video source was "1080p"? Handbrake detected a lot of "combed" frames, and attempted to remove interlacing, which can make files bigger.

Additionally, video with a lot of movement (like dancing) vs. "talking head" lecturing requires a lot more bits to encode properly.

[mduell]

It's not the 3 minutes, it's the content. This is completely expected with constant quality encoding.

The dance video had a lot more motion than the barre video, which takes more bits to encode. Static elements in the frame don't take much.
Without having seen the content, it's possible the dance video may have also had a lot more detail, vs the barre video having a more uniform subject or background.

We see this all the time. Two good film examples are Saving Private Ryan and The Social Network. The former is about 50% longer, but the output is easily 10-20x the size with the same settings.

[jho82]

Are you SURE the video source was "1080p"? Handbrake detected a lot of "combed" frames, and attempted to remove interlacing, which can make files bigger.

Additionally, video with a lot of movement (like dancing) vs. "talking head" lecturing requires a lot more bits to encode properly.

Thanks Woodstock!

All I can tell on the camera is that it's 1080x1920 @25fps and there's another option for 1080x1920 @ 50fps.

[jho82]

It's not the 3 minutes, it's the content. This is completely expected with constant quality encoding.

The dance video had a lot more motion than the barre video, which takes more bits to encode. Static elements in the frame don't take much.
Without having seen the content, it's possible the dance video may have also had a lot more detail, vs the barre video having a more uniform subject or background.

We see this all the time. Two good film examples are Saving Private Ryan and The Social Network. The former is about 50% longer, but the output is easily 10-20x the size with the same settings.

Thanks mduell!

Interesting - thanks for that insight. The reason why I originally thought it was the 3 mins, was because a 35min video of barre and a 35min video of dance - same recording and output settings resulted in video sizes around the same size 390-400mb. Going back and looking at a number of other videos that are the same length have shown similar output sizes, hence why the immediate observation was the discrepancy in time or perhaps a bug.

however, your explanation makes a lot more sense.