Jump to content

Transcoded resolution doesn't match selection


Juzzle11

Recommended Posts

Juzzle11

I'm not sure if this has been covered elsewhere, but there seems to be an issue with the way Emby calculates the resolution when transcoding.
In this example I'm using the web player to playback a video  (1920x806 source resolution) I get the following.

Selected resolution Transcoded Resolution
Auto (1080p 60Mbps) 1920x806
1080p 10Mbps 1920x806
1080p 8Mbps 1920x806
1080p 6Mbps 1920x806
1080p 5Mbps 720x302
1080p 4Mbps 720x302
720p 4Mbps 720x302
720p 3Mbps 720x302
720p 2Mbps 640x269
720p 1.5Mbps 640x269
720p 1Mbps 426x179
480p 1Mbps 426x179
480p 720Kbps 426x179
480p 420Kbps 426x179
360p 426x179
240p 426x179
144p 426x179

.

In the logs I can see that scaling at 1080p 6Mbps is

scale@f5=width=1920:height=-2

1080p 5Mbps then goes to 

scale@f5=width=720:height=-2

This means there's a huge quality drop below 6Mbps on the web player. 

This isn't limited to this particular video, and I can provide logs from many other source videos which have the same problem if needed.

Thanks!

 

ffmpeg-transcode-e467adc5-6455-4e2f-af06-45256d129976_1.txt ffmpeg-transcode-622520dc-8f71-4f12-9022-2ecb6bcd37b1_1.txt embyserver.txt

Edited by Juzzle11
Link to comment
Share on other sites

Hello Juzzle11,

** This is an auto reply **

Please wait for someone from staff support or our members to reply to you.

It's recommended to provide more info, as it explain in this thread:

Thank you.

Emby Team

Link to comment
Share on other sites

It would be better to remove the resolution and only keep the bitrate but that might be confusing to people.  The resolution is only a guide as the original file + codecs plus chosen bitrate dictates the resolution.

You do not lose quality by using a smaller resolution.

As an example a 1080/4Mb file might show banding or not look fluid compared to a 720/4Mb version.

Link to comment
Share on other sites

pünktchen
2 hours ago, cayars said:

You do not lose quality by using a smaller resolution.

You do not believe this yourself, do you?

Link to comment
Share on other sites

pünktchen

We are not talking about decision making at the point the video is created the first time! The video already exists after some initial encoding.
Every further transcoding of the same video means loss in quality, especially when transcoding to lower resolutions and/or lower bitrates.
Of course if you watch that 1080p video on a 5 inch, 720p smartphone display you won't notice the quality decrease. But it still happens. That's a fact!

  • Like 3
Link to comment
Share on other sites

Juzzle11

This isn't a cosmetic issue about whether or not to show the resolution (although I agree that only bitrate is really needed as a choice)
From what I can tell there seems to be something up with the calculations used to determine how to scale the transcoded video for certain sources.

For the source video used in my example, the resolution drops straight from 1920x806 to 720x302. This is an equivalent drop straight from 1080p to 360p with nothing in between. (remember 720x302 is is not 720p, this is 302p.)

I would expect a more gradual decrease in resolution as the bitrate is reduced - e.g. 1280x538 as the next step. (720p cropped to match source aspect)
When transcoding a video with a more standard source resolution (e.g. 1920x1080), this works fine and there is a progression of resolutions that makes sense:

1920x1080, 1280x720,  720x405, 640x360 etc etc

 

  • Like 1
Link to comment
Share on other sites

Juzzle11

This may explain the problem better:

For a source video with 1920x1080 resolution, the transcode options used by Emby are as follows:

 

scale@f5=width=1920:height=-2
scale@f5=width=1280:height=-2
scale@f5=width=720:height=-2
scale@f5=width=640:height=-2
scale@f5=width=426:height=-2

 

For my source video with 1920x806 resolution, the transcode options seem to be:

scale@f5=width=1920:height=-2
scale@f5=width=720:height=-2
scale@f5=width=640:height=-2
scale@f5=width=426:height=-2

In this second example, the width=1280 option is never used and transcoding jumps straight from 1920 width to 720.

 

Link to comment
Share on other sites

45 minutes ago, pünktchen said:

We are not talking about decision making at the point the video is created the first time! The video already exists after some initial encoding.
Every further transcoding of the same video means loss in quality, especially when transcoding to lower resolutions and/or lower bitrates.
Of course if you watch that 1080p video on a 5 inch, 720p smartphone display you won't notice the quality decrease. But it still happens. That's a fact!

Understood but there is a corresponding bitrate per resolution that can be calculated based on the source file and the codecs used. Framerate, interlaced, number of audio tracks and subs all come into play as well.

31 minutes ago, Juzzle11 said:

This may explain the problem better:

For a source video with 1920x1080 resolution, the transcode options used by Emby are as follows:

 


scale@f5=width=1920:height=-2
scale@f5=width=1280:height=-2
scale@f5=width=720:height=-2
scale@f5=width=640:height=-2
scale@f5=width=426:height=-2

 

For my source video with 1920x806 resolution, the transcode options seem to be:


scale@f5=width=1920:height=-2
scale@f5=width=720:height=-2
scale@f5=width=640:height=-2
scale@f5=width=426:height=-2

In this second example, the width=1280 option is never used and transcoding jumps straight from 1920 width to 720.

 

What does the Media Info (detail screen at bottom) show for the file you used when testing this?

Link to comment
Share on other sites

Juzzle11

 

3 minutes ago, cayars said:

What does the Media Info (detail screen at bottom) show for the file you used when testing this?

image.png.5419ca5509b770ef5d54a3abda18ac16.png

Link to comment
Share on other sites

So this is what I was getting at.  This is a 10bit file using HEVC/h.265 compression.  It's bitrate is 4.7Mb.  In order for this to be an AVC/H.264 file at 8 bit's it would take 2 to 3 times the bitrate just because of the differences in compression available between HEVC and AVC.  So Emby will consider this something like a 12 or 13Mb file when it does it's calculations.

Link to comment
Share on other sites

pünktchen
1 hour ago, cayars said:

So Emby will consider this something like a 12 or 13Mb file when it does it's calculations.

That makes what happens even more wrong. If the source is treaten like 12 Mbit/s, why it drops down to 4.6 Mbit/s at 720x302?

Link to comment
Share on other sites

It's not wrong.  You have to stop and think about what happens when you convert media.

People convert media from AVC to HEVC because they want to save space on disc and to lower the bitrate needed to stream.  These HEVC files typically will be 1/3 to 1/2 the AVC size.  On my system it's right around 1/3 the size.

So if I have a 1080 video that was converted and needed 5Mb (average) to hold the quality and I'm streaming it to a client that can't direct play what does Emby have to do?
It does the following in chunks of course but let's ignore chunks.  So It has to decode the HEVC stream and reprocess it as AVC.  It's no longer a 5Mb stream but closer to 15Mb stream if it kept 100% quality and just changed the codec.

So what happens if there is a 10Mb cap on the user?  15Mb doesn't fit in 10Mb so it can either hold the resolution and cap the bitrate at 10Mb which isn't going to be ideal most of the time because we give up 1/3 the bits before even starting the process and know this will degrade the video OR we can "shrink" the video so we can hold the bitrate per pixel to keep the video fluid and avoid things like banding and washed out video.

It's proportion just like the size of Rips from DVD to Blueray to 4K.  As the resolution increases the bitrate climbs. The inverse is also true which is why Emby and other similar programs have to adjust the size of the image based on what bandwidth is available.

 

Link to comment
Share on other sites

Juzzle11
57 minutes ago, cayars said:

So what happens if there is a 10Mb cap on the user?  15Mb doesn't fit in 10Mb so it can either hold the resolution and cap the bitrate at 10Mb which isn't going to be ideal most of the time because we give up 1/3 the bits before even starting the process and know this will degrade the video OR we can "shrink" the video so we can hold the bitrate per pixel to keep the video fluid and avoid things like banding and washed out video.

 

Can we presume for the time being that most of us here fully understand the relationship between bitrate, resolution and visual quality.
It's also understood that to prevent unwanted visual artefacts from lower bitrates, Emby must reduce the resolution of the transcoded video if the user selects a low bitrate.

In my example, we are always transcoding - not because of bandwidth limitations - but because the player doesn't support HEVC. 

To rephrase my original question again:

When reducing the selected bitrate from 6Mbps (transcoded) to 5Mbps (transcoded) why does Emby drop the resolution by a factor of 4 (1920x806@6Mbps vs 720x302@5Mbps) instead of a factor of 2 (e.g. 1280x538@5Mbps).

The bitrate of the source video is not relevant to my question.

Link to comment
Share on other sites

Without being able to read the code I can't give specifics.  Maybe @softworkz can answer the more specific question as he works on this in the code.

Link to comment
Share on other sites

Well, I think the criticism is justified - partially at least. It's not just about resolution but even about bandwidth itself which doesn't adhere to the selection. In case of hw accelerated transcoding, the hw encoders are sticking rather closely to the requested bandwidth, while software encoding via libx264 is controlled in a way that bandwidth is often way below that bandwidth selection. I'm thinking about changing that ever since, and there's no doubt that the internal calculations for bandwidth and resolution could be improved.

Maybe the "problem" is that this topic is brought up just very rarely - even less than once a year, so it probably never became a higher priority.
('maybe' and 'probably' because I don't set priorities)

Regarding the removal of resolutions in the quality selection - I'm not a fan of the idea. At least not in a way that there would just remain a collection of bandwidth values to choose from. That's not really intuitive and user-friendly. Even those that have an understanding of these things: it would often require some extra-thinking without the orientation that those resolution values are providing.

But granted - I agree that the presentation is not ideal, because it suggests that you would get a video with the selected bandwidth and the selected resolution. 

Instead, it must be seen and understood in a different way: The resolution value is meant to match the size and resolution of the display you are using to watch.
Of course, nowadays this doesn't tell a lot, as there are smart phones having a higher resolution than big-screen TVs.

I wonder whether it might make sense to replace the resolutions in the quality list with something else - maybe some icons representing a phone, a tablet, a TV and a 4k TV...?

  • Thanks 1
Link to comment
Share on other sites

  • 2 weeks later...
Juzzle11

@softworkz I think the actual reason I started this thread is being misunderstood, and it specifically relates to the way Emby categorises certain resolutions, which seem to have a knock on effect on the resolutions used for transcoding at reduced bitrates..

In my example at the beginning of this thread, the source resolution is 1920x806. I have no doubt that this was encoded from a 1920 x 1080 source and was cropped to remove the black bars top and bottom. Somewhere internally this video seems to be treated as a 720p source and the first drop in resolution caused by a transcode skips past 720p and goes straight to 1/4 resolution (720x302) (see table in my first post)

I have another example here which confuses Emby somewhat - this video is also from a 1920x1080 source with usual black bars removed from top and bottom, but also in this case a 22 pixel crop from the left / right edges.

Emby categorises this as a 720p video.

image.png.2cab89fc733efaaf3f6635c44d170936.png

While it may seem counterintuitive, perhaps the issue is that Emby should be more focused on looking at the horizontal resolution to determine the 'p' rating of a file, especially if the pixel aspect is 1:1 and the display aspect is 'wider' than 16:9

e.g.1920x800 = 1080p 
1280 x 544 = 720p

I'm probably not making much sense, but I think there must be a better way of doing this.....!

Edited by Juzzle11
Link to comment
Share on other sites

You are right, what Emby does here, doesn't make much sense actually.

Formats like 1080p, 1080i, 720p are precisely defined.

1080p/i is always and only 1920x1080 and 
720p is always and only 1280x720.

I will propose a change for this in Emby, but you need to be aware that this simply about building that "Title" display text. It is not a "classification" and not used for anything else than that little text in your screenshot.

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...