Cropped 1080p media reports as 720p

[Hoosiers317 16]

Then i would try again with the next release because I can see we're already checking for >= 1200 on 720p. Thanks.

 

Okay, thank you.

[Guest asrequested]

I have a bunch, too. It's the same in 3.2.70.16 I tried refreshing and manually deleted the nfo file. Re-scanned, no change. But yes, it does play, correctly.

 

Edited February 20, 2018 by Doofus

[Happy2Play 9780]

I have a bunch, too. It's the same in 3.2.70.16 I tried refreshing and manually deleted the nfo file. Re-scanned, no change. But yes, it does play, correctly.

 

 

But your example is 960, and Luke state >=1200.

[Guest asrequested]

But your example is 960, and Luke state >=1200.

 

Yeah, but I also said that I have many, and with different sizes. 

 

[Happy2Play 9780]

@@Luke would have to comment on the1080p threshold as he only mentioned 720p.

oops he already did

 

 

 

It's only at the point of display so it's not really harming anything. We are considering 1900+ width as 1080p, but I will lower it though in order to handle those 1892 examples. The 1440 one though is unlikely to change. thanks.

  Edited February 20, 2018 by Happy2Play

[Guest asrequested]

@@Luke would have to comment on the1080p threshold as he only mentioned 720p.

 

The original posts are 1080 being reported as 720. I was just showing that it happens with multiple sizes. Using the width just doesn't work. And the cover art is wrong, too

[mbnwa 49]

@@Luke can you post the range for each quality indicator?

 

How about adding an advanced section in settings allowing the server admin to set the range to his/her preference?

 

 

Sent from my iPhone using Tapatalk

Edited February 20, 2018 by mbnwa

[ebr 16169]

Then i would try again with the next release because I can see we're already checking for >= 1200 on 720p. Thanks.

 

Seems like, for this to work properly, we have to add an " || height >= 720" on there.

[mbnwa 49]

Any updates to this issue? I still have quite movies that are showing as 720p when they should be 1080p for example movies with 

Resolution1800x1080 is being reported as 720p

Resolution1876x1076 is being reported as 720p 

Resolution1448x1076 is being reported as 720p

 

Emby Server Version 3.3.1.0

[Luke 42077]

Please try again with the next release, thanks.

[mbnwa 49]

Thanks for the update

[Carlo 4560]

https://github.com/MediaBrowser/Emby/blob/master/MediaBrowser.Controller/Entities/Video.cs#L783-L808

            if (videoStream != null)
            {
                if (videoStream.Width.HasValue)
                {
                    if (videoStream.Width.Value >= 3800)
                    {
                        terms.Add("4K");
                    }
                    else if (videoStream.Width.Value >= 1900)
                    {
                        terms.Add("1080P");
                    }
                    else if (videoStream.Width.Value >= 1270)
                    {
                        terms.Add("720P");
                    }
                    else if (videoStream.Width.Value >= 700)
                    {
                        terms.Add("480P");
                    }
                    else
                    {
                        terms.Add("SD");
                    }
                }
            }

Understand now? Perhaps this part of the code should be refactored to make use of videoStream.Height.Value in these evaluations too?

If that's the code being used that would explain it since it's wrong from the standpoint of how we think about resolutions and "box/frame" sizes.

 

It should be more like this:

 

            if (videoStream != null)

            {

                    if (videoStream.Width.Value > 4096 || videoStream.Height.Value > 2160)

                    {

                        terms.Add("8K");

                    }

                    else if (videoStream.Width.Value > 3840 || videoStream.Height.Value > 2160)

                    {

                        terms.Add("4K");

                    }

                    else if (videoStream.Width.Value > 2048 || videoStream.Height.Value > 1080)

                    {

                        terms.Add("UHD");

                    }

                    else if (videoStream.Width.Value > 1920 || videoStream.Height.Value > 1080)

                    {

                        terms.Add("2K");

                    }

                    else if (videoStream.Width.Value > 1280 || videoStream.Height.Value > 720)

                    {

                        terms.Add("1080");

                    }

                    else if (videoStream.Width.Value > 720 || videoStream.Height.Value > 576)

                    {

                        terms.Add("720");

                    }

                    else

                    {

                        terms.Add("SD");

                    }

            }

 

 

Basically that code would use a "box" or "frame" for the following sizes:

 

SD 720x480 or 720x576 (PAL)

720 1,280 x 720

1080 1,920 x 1,080

2K 2,048 x 1,080

UHD 3,840 x 2,160

4K 4,096 x 2,160 

8K 7,680 x 4,320

 

It checks both the Height and the Width to make sure the resolution fits inside the "box".

 

I removed the "p" from 720p and 1080p since this has nothing to do with resolution and with "p"rogressive vs "i"nterlaced. Technically you can't tell if it's p or i by the resolution although you can guess and be correct for many resolutions.  But for certain resolutions such as 1080 it can go either way.

1080p if it came from a BluRay or 1080i if you recorded it from a US broadcast.

 

I added a couple of other resolutions in there as well.

 

Carlo

[Luke 42077]

Great info, thanks !

[Guest asrequested]

I misread

Edited April 14, 2018 by Doofus

[quorn23 13]

Found this topic searching for it.

It even says 1080p HEVC, but the Thumbnails keeps being generated as 720P

Is there a way to overwrite this? Or is it a technical issue of Emby?

 

Edit: Became aware that's probably an issue with the CoverArt Plugin, as the resolution sticker is not vanilla emby. Will search for the thread for that plugin.

Edited January 5, 2021 by quorn23

[Carlo 4560]

These can both be correct depending on the actual resolution.

If only displaying the Width and this wasn't cropped then it will show 1080.  If however you're looking at the height and width and the height is cropped and not big enough to be considered 1080 then you'll get 720.

So in your file you have 1480x1080 which is quite a bit smaller than 1920 x 1080 which is the box size for a 1080 full HD video.  So it's 720 or better but not 1080 box size.

[speechles 2055]

@cayars In your equations above from 2018 those should be && AND and not || OR

Anything >720 height is 1080 unless it also >1080 then it is 2k unless it also >2k then it is etc etc

Edited January 6, 2021 by speechles

[Carlo 4560]

Depends on the outcome you want. Do you want to use EITHER height or width OR do you want BOTH height AND width to match? I agree if you want BOTH.

Can do it either way.  But what's shown above with coverart not matching the detail screen is likely using different methods to calculate the resolution (not good). The same calculation should be used everywhere for consistency IMHO.

 

[speechles 2055]

It must be AND && using OR || is wrong
 

                    else if (videoStream.Width.Value > 2048 || videoStream.Height.Value > 1080)

                    {

                        terms.Add("UHD");

                    }

                    else if (videoStream.Width.Value > 1920 || videoStream.Height.Value > 1080)

                    {

                        terms.Add("2K");

                    }

 

This will always trigger for 2K and never trigger UHD (because it triggers both actually and the last gets the value). Width will always have a value if Height has a value. Height will always have a value if Width has a value. They are mutually inclusive. Because the equation above uses || instead of && causes the problem of it not being able to select certain values (Such as "UHD" above). Do you see this too?  I am positive this is done correctly because we (luke, me, ebr and others) had this talk when the Roku app added the 4K token. The same exact way the web app does it in javascript was ported into brightscript so the Roku mimics it.

 

The reason the thumbnails are off is because of how ffmpeg is interpret things. It has to be told how to interpret this the same way the display is showing.

Edited January 6, 2021 by speechles

[Carlo 4560]

It's not a matter of if the height and width have a value but of how you want to calculate the size.  Do you want to use one dimension or both.

It wasn't meant to be drop in code but more of a C# pseudo code for Luke.

Personally I do agree with you that AND is a better choice and both dimensions should be used. If I were re-writing that today, that's exactly what I'd suggest.
So I think you are correct.

[speechles 2055]

I would use height first. If the height is standard (240,360,400,404,480,576,704,720,1080,2160,4320) just use height. If it is not-standard and not in that list I would then use height and width.

Edited January 6, 2021 by speechles

[Carlo 4560]

That I think is why the example above shows both 1080 and 720 as they are using different calculations.  

I'm guessing the coverart plugin is using both values with the AND and the detail screen is just using the height and code similar to above with OR.

To me the greater question is what do you want to call a video that's 1480x1080?
Is it 720+ or cropped 1080?  I'd prefer 720 but think most people would say 1080 and I understand both ways of looking at it.

 

[pwhodges 2012]

2 hours ago, cayars said:

To me the greater question is what do you want to call a video that's 1480x1080?
Is it 720+ or cropped 1080?  I'd prefer 720 but think most people would say 1080 and I understand both ways of looking at it.

Since the number actually states the height, calling 1480x1080 anything other than 1080 is plain wrong.  In this case the vertical dimension is not cropped.  And even if you are pretending that all videos are 16:9 (really?), then 1480 horizontal is bigger than the width of a 720 video, so 720 is still inappropriate.

For videos that are vertically cropped (e.g. 1920x960), I have seen both the actual height (960) and the container height (still 1080) used, with the second being the more common.

Paul

[Carlo 4560]

That is definitely one opinion. Other purist will say if it doesn't meet the 1920x1080 it isn't 1080 or Full HD
That is the issue.  Half the people want one thing, half another.  (don't know exact numbers but people feel differently about this).

I personally have no personal bias and don't care how we display it as long as I understand why.
Personally resolution is 1/2 the info I care about.  Bitrate IMHO is more important.

To me a high quality 720 or 1080 rip can look better than a low bitrate 1080 or 4K rip so what I personally care about is overall quality which isn't easy to quantify.
Therefore I have no personal bias in this.

[pwhodges 2012]

24 minutes ago, cayars said:

Other purist will say if it doesn't meet the 1920x1080 it isn't 1080 or Full HD

If it's purist to say that something whose dimensions literally include 1080 is not 1080, I guess those "purists" are the kind who like to alter the aspect ratio of what they're watching to fill the screen regardless of the distortion!

Paul