How to force Emby to not cropped bands

[lolotux 4]

That's formidable to see somes never said how they did something or others....
That's never help any one!
Tks

[lolotux 4]

Hi 

When Emby read file it seems cropping black bands.....
Then the height size is increased and "moche".....

Is there any option to force to not crop !

Tks

[20251207-20:06:14] lolo@debian12:~$ lsb_release -a
No LSB modules are available.
Distributor ID: Debian
Description:    Debian GNU/Linux 12 (bookworm)
Release:        12
Codename:       bookworm

Emby Version 4.9.1.90

 

[visproduction 315]

I think it is likely that your original media has black bands and when it is directly played back on a monitor or other player, the black bands are not cropped, but the media is played back with the largest dimension of the media filling either the width or the height of the screen.  This can result in additional black bars appearing in the opposing direction which can make the video seem to float with black bars on all 4 sides.  It's a side effect of the player's monitor aspect ratio.  I do not think anything is being cropped.

 

[TMCsw 247]

4 hours ago, lolotux said:

"moche"

Please don't make me look up words!

"moche"... ...French? = ugly?

[Luke 42077]

HI there, can you please provide a specific example?

How to Report a Problem

Thanks !

 

[lolotux 4]

9 hours ago, Luke said:

HI there, can you please provide a specific example?

How to Report a Problem

Thanks !

 

Hi all

This came frome HandBrakeCLI....
For some reason it encodes in 16:9 and sometimes in 2.35:1.....
To force to not crop you have to used --crop-mode 0
https://handbrake.fr/docs/en/latest/cli/command-line-reference.html

We apologize for any inconvenience caused...

NB : TMCsw : sorry the entirely world exists and without you.....

[visproduction 315]

Lol,

Does the video show black bars because you are watching it on a 16:9 widescreen TV or monitor?  The actual video may have no black bars at all.

If the original media does have black bars, then you will usually see black bars all around.  This is because two extra black bars area appear from your player that wants to play back the whole video to fit whatever screen size you are using.  You have to look at the video on it's own to see if there are black bars.  You cannot tell by playing it back inside a player.

https://www.maestro.io/blog/video-aspect-ratios/

[Luke 42077]

have your questions been answered?

[lolotux 4]

2 hours ago, Luke said:

have your questions been answered?

Not really....
I think is not just Emby issue....

Look at this strange....
First is under KDE Wayland

The second is under KDE X11

That's all the story.

If someone have an idea!

Tks

[Luke 42077]

Yea it's probably an issue in the browser video player on that platform...

[lolotux 4]

2 hours ago, Luke said:

Yea it's probably an issue in the browser video player on that platform...

Do you know how to get this player?

[Luke 42077]

What do you mean by "this" player?

[lolotux 4]

5 hours ago, Luke said:

Yea it's probably an issue in the browser video player on that platform...

Do you know how to get this player?

The "Yea it's probably an issue in the browser video player on that platform..."

 

[visproduction 315]

Suspect the media .mkv has embedded display aspect playback should be 2.39 for this media. But in the above example, but the original media is saved as 16:9.  This can happen when Handbreak is used to copy the media from a blu-ray.  Handbreak has a tendency to do this automatically in it's settings.  There are an optimization reason to do this.  Compression using the 16:9 format is more efficient than keeping the media in 2.39 aspect ratio. Handbreak ads a play the media back in 2.39 inside the MKV container.  If the user's player can read the internal playback aspect ratio setting inside the .mkv container, then it will convert the media from 16:9 (1.78) and playback correctly in 2.39, which is the top screenshot labeled KDE Wayland above.  This is the actual correct aspect ratio showing the Vin Diesel's head in a correct shape.  With this player at this window size, black bars top and bottom are added to allow the full correct width of the media showing the 2.39 aspect ratio.  If you resized the player to match exactly 2.39, the top and bottom black bars would disappear.  These bars are just a side effect of the player window being a little too tall.

Can Emby read the internal preferred playback ratio and incorporate that into the transcoding conversion?  Maybe not.  A transcoding probably occurs based on the actual media aspect ratio in the recorded media that Handbreak made with the false 16.9 aspect and ignores the extra embedded metadata that mkv video players check to resize the media to the assigned aspect ratio which is just an extra data entry inside the file.  In other words the encoding by Handbreak forced a 16:9 ratio to allow better quality transcoding and now that it has to be transcoded again, this is not read and used, so the squeezed version at 16:9 shows up with black bars inserted left and right because the player window itself is too wide for 16:9 playback.

Of interest: ffmpeg and MKVtools can change this aspect ratio tag inside the embeded metadat of the .mkv media.  But at this point, that doesn't help anything.  The problem happens because the media is saved with a forced 16:9 aspect ratio and just a metatdata tag to play it at 2.39.  This is a bad media copy.  When you don't notice the problem when playing back on some players, doesn't change the fact that the media copy has been distorted by Handbreak.  In commercial online media server sites, this would be listed as bad media content and need to be reencoded to the real aspect ratio and never use the .mkv player aspect tag.  It should be encoded to the correct 2.39 and override Handbreak from trying to optimize the quality for squeezing it to a different 16:9 size.

Should Emby be able to read inside the mkv player to adjust automatically the aspect ratio to the assigned resize?  Well, maybe not.  How do we know that it's the assigned aspect ratio is correct.  It a media mastering error to make the media squeezed to 16:9.  If Emby changed the aspect to match the playback, what if that is the error made by the bad transcoding and the media itself is correct.  Each case is one error.  Which is correct.  It does make sense for Emby to not pay attention to any internal resizing tags and just count on the original content to be correct.

The answer is to stop making media content with incorrect aspect ratios.  If you don't notice the difference when playing back on a .mkv 3rd party player, that's becuase you are looking at the playback and not looking a the media file aspect ratio and making sure it is correct without black bars.  In short, this is most likely incorrectly copied media causing this issue.  Encode your master media correctly in the true aspect ratio and the squeezing and stretching will be fixed.  As far as having black bars on a 16:9 TV, the only method around that would be either crop or stretch the media to match 16:9, which is considered a error in playback for professional uses.  Sometimes people prefer this, but most people prefer to watch in a correct aspect ratio.  Even TV's have dropped this feature about 10 years ago because of so many complaints.

 

[Luke 42077]

8 hours ago, lolotux said:

Do you know how to get this player?

The "Yea it's probably an issue in the browser video player on that platform..."

 

What do you mean by "get it" ? I don't quite understand what you're asking, sorry.

[lolotux 4]

4 hours ago, visproduction said:

Suspect the media .mkv has embedded display aspect playback should be 2.39 for this media. But in the above example, but the original media is saved as 16:9.  This can happen when Handbreak is used to copy the media from a blu-ray.  Handbreak has a tendency to do this automatically in it's settings.  There are an optimization reason to do this.  Compression using the 16:9 format is more efficient than keeping the media in 2.39 aspect ratio. Handbreak ads a play the media back in 2.39 inside the MKV container.  If the user's player can read the internal playback aspect ratio setting inside the .mkv container, then it will convert the media from 16:9 (1.78) and playback correctly in 2.39, which is the top screenshot labeled KDE Wayland above.  This is the actual correct aspect ratio showing the Vin Diesel's head in a correct shape.  With this player at this window size, black bars top and bottom are added to allow the full correct width of the media showing the 2.39 aspect ratio.  If you resized the player to match exactly 2.39, the top and bottom black bars would disappear.  These bars are just a side effect of the player window being a little too tall.

Can Emby read the internal preferred playback ratio and incorporate that into the transcoding conversion?  Maybe not.  A transcoding probably occurs based on the actual media aspect ratio in the recorded media that Handbreak made with the false 16.9 aspect and ignores the extra embedded metadata that mkv video players check to resize the media to the assigned aspect ratio which is just an extra data entry inside the file.  In other words the encoding by Handbreak forced a 16:9 ratio to allow better quality transcoding and now that it has to be transcoded again, this is not read and used, so the squeezed version at 16:9 shows up with black bars inserted left and right because the player window itself is too wide for 16:9 playback.

Of interest: ffmpeg and MKVtools can change this aspect ratio tag inside the embeded metadat of the .mkv media.  But at this point, that doesn't help anything.  The problem happens because the media is saved with a forced 16:9 aspect ratio and just a metatdata tag to play it at 2.39.  This is a bad media copy.  When you don't notice the problem when playing back on some players, doesn't change the fact that the media copy has been distorted by Handbreak.  In commercial online media server sites, this would be listed as bad media content and need to be reencoded to the real aspect ratio and never use the .mkv player aspect tag.  It should be encoded to the correct 2.39 and override Handbreak from trying to optimize the quality for squeezing it to a different 16:9 size.

Should Emby be able to read inside the mkv player to adjust automatically the aspect ratio to the assigned resize?  Well, maybe not.  How do we know that it's the assigned aspect ratio is correct.  It a media mastering error to make the media squeezed to 16:9.  If Emby changed the aspect to match the playback, what if that is the error made by the bad transcoding and the media itself is correct.  Each case is one error.  Which is correct.  It does make sense for Emby to not pay attention to any internal resizing tags and just count on the original content to be correct.

The answer is to stop making media content with incorrect aspect ratios.  If you don't notice the difference when playing back on a .mkv 3rd party player, that's becuase you are looking at the playback and not looking a the media file aspect ratio and making sure it is correct without black bars.  In short, this is most likely incorrectly copied media causing this issue.  Encode your master media correctly in the true aspect ratio and the squeezing and stretching will be fixed.  As far as having black bars on a 16:9 TV, the only method around that would be either crop or stretch the media to match 16:9, which is considered a error in playback for professional uses.  Sometimes people prefer this, but most people prefer to watch in a correct aspect ratio.  Even TV's have dropped this feature about 10 years ago because of so many complaints.

 

Hi 

In this way I had --mode-crop 0 to emby but problem stay....

I think that Luke have a good idea....

Emby movie player depends of environement as KDE Plasma Gnome........

[Luke 42077]

9 hours ago, lolotux said:

Hi 

In this way I had --mode-crop 0 to emby but problem stay....

I think that Luke have a good idea....

Emby movie player depends of environement as KDE Plasma Gnome........

Well in this case it is the web app, so Emby depends on the browser video player, which in turn depends on the environment.

[lolotux 4]

10 hours ago, Luke said:

Well in this case it is the web app, so Emby depends on the browser video player, which in turn depends on the environment.

Mine is mpv , others are after.....

I think I begin to see the issue.

HandBrakeCLI cropped..... using --crop-mode none : it's ok

bands still there.

And to be sure of that, I created a new emby user without particulary conf and it's ok.....

 

[lolotux 4]

And my last msg !

[20251210-22:16:56] lolo@debian12:$ sudo grep -i "handbrake-cli" /var/log/dpkg.log
2025-12-06 11:34:31 upgrade handbrake-cli:amd64 1:1.6.1-dmo2+deb12u5 1:1.6.1-dmo2+deb12u5
2025-12-06 11:34:31 status half-configured handbrake-cli:amd64 1:1.6.1-dmo2+deb12u5
2025-12-06 11:34:31 status unpacked handbrake-cli:amd64 1:1.6.1-dmo2+deb12u5
2025-12-06 11:34:31 status half-installed handbrake-cli:amd64 1:1.6.1-dmo2+deb12u5
2025-12-06 11:34:31 status unpacked handbrake-cli:amd64 1:1.6.1-dmo2+deb12u5
2025-12-06 11:36:16 configure handbrake-cli:amd64 1:1.6.1-dmo2+deb12u5 <none>
2025-12-06 11:36:16 status unpacked handbrake-cli:amd64 1:1.6.1-dmo2+deb12u5
2025-12-06 11:36:16 status half-configured handbrake-cli:amd64 1:1.6.1-dmo2+deb12u5
2025-12-06 11:36:16 status installed handbrake-cli:amd64 1:1.6.1-dmo2+deb12u5

Tks
 

[Luke 42077]

Thanks. Please keep us posted if you find anything.