4K HEVC shows as 1080p, think I can't find any setup to fix?

[Teddyknuddel 139]

Seriously? Do I really have to explain to YOU how that’s connected?

[Luke 42979]

30 minutes ago, PeteGul said:

Ok, here is my follow-up.

Stats for nerds says it now plays in 4K, when Shield is set to 4K. But it says 1080p in the settings "quality", add pictures of both.

@visproductionMy gear i relatively new, and generally new cables and everything is HDCP 2.2 compatible, I don't see this as a problem. I do think my stuff dances good together.

@TeddyknuddelThat's right, nothing is changed on my side. 

This is a question to find what's going wrong, when everything says it is an 4K movie. Why does that not that movie show in 4K. Should not need to "trick" the system to do so.

Hi. That’s just your quality setting. I would set that back to auto.  That’s strange though. I’m surprised it’s not causing a transcode.

[Luke 42979]

Anyway back to the original example. This is an edge case due to the cropped resolution so we will have to account for that. Thanks.

[PeteGul 45]

2 hours ago, Teddyknuddel said:

@PeteGul

Why not install Kodi as a trial, use the EmbyCon or EmbyNextGen add-on for Kodi, and don’t forget to install the Emby Kodi Companion plugin; set everything to DirectPlay, and see for yourself the difference between the app and proper, smooth playback.

Used Kodi for many years, and for me it just got to cluttered. I use it much outside my house, so me and the wife like thinks to look the same regardless of where we watch things, and Emby is good at this.

But yes, Kodi is good for video and audio. VLC also, but I want the sync if played not played, where we cut of the play. Then VLC is not the king. 

This is my first "big" problem with Emby app, and it seems it is possible to work out fast for the Emby team. Even if we know "simple" fixes can take to much time.

Hope it work out quickly

[PeteGul 45]

3 hours ago, Luke said:

Hi. That’s just your quality setting. I would set that back to auto.  That’s strange though. I’m surprised it’s not causing a transcode.

Back to auto it goes, was just an test also. Normal is auto
No transcode is happening. Never on local play anyhow. 

[Teddyknuddel 139]

@PeteGul
I’ve breathed new life into the old Embuary skin and spruced it up a bit. It’s a bit closer to the app now. My wife and I both like it when everything looks the same everywhere. But what we don’t like is when it doesn’t work properly. The app itself may well be good, but as soon as HD sound and 4K are used together, the app fails completely. And I don’t see why I should have to watch in lower quality just because the programming lot can’t be bothered to sort it out. Too lazy to test their own work, which is why a new release is now being rolled out every single day.

[Neminem 1863]

@TeddyknuddelI guess you have issues with Emby.

Here is how to report a problem

 

[Teddyknuddel 139]

1 minute ago, Neminem said:

I guess you have issues with Emby.

No – I’ve just got a better player. The Ugoos AM6b Plus. It plays Dolby Vision 7 FEL perfectly with CoreELEC. No Android app can hold a candle to it.

[Teddyknuddel 139]

Anyone who mocks without being able to refute what has been said ultimately only exposes their own narrow-mindedness – and thus becomes exactly what they are mocking.

[Lessaj 549]

I have no issues with Dolby Vision profile 7.6 content on Emby for Android. Have you reported a media playback issue with an example? Otherwise you're just polluting someone else's topic.

[Teddyknuddel 139]

You're confusing “it plays” with “it plays correctly and to the full capability of the source.”

The fact that Emby for Android plays Dolby Vision Profile 7 content on your device proves exactly one thing: your device accepts the stream and produces a Dolby Vision picture. It does not prove that the complete Profile 7 FEL data is being processed and reproduced with the same fidelity as on a playback chain that fully supports FEL.

And that's actually the point of my criticism.

A proper Direct Play path should simply hand the original media to a capable playback engine instead of unnecessarily putting the Android app/player layer between the source and the hardware. That would eliminate an entire class of compatibility, format-detection and playback problems.

It is also directly relevant to the problem discussed in this thread. If a genuine 4K HEVC source can end up being treated as 1080p, the obvious question is why the app isn't simply handing the original 4K stream to the playback hardware/player and letting it do its job.

The same applies to Dolby Vision. “My TV switches to Dolby Vision and I have no problems” is not evidence of full-fidelity Profile 7 FEL reproduction. It only tells us that your particular playback chain produces an acceptable result to you.

Those are two completely different claims.

So no, I don't need to report your personal playback experience as a separate bug in order to make the technical point. I'm criticizing the limitation of the playback architecture itself.

If all you require is “the movie plays and Dolby Vision appears on my screen”, then apparently you're satisfied.

If the requirement is original 4K media being passed through without unnecessary intervention, with the complete capabilities of the source and playback hardware preserved, then that's a different standard entirely.

And that is precisely why proper Direct Play would solve or prevent many of the problems being discussed here — including the 4K/1080p issue raised by the thread starter.

Your statement “I have no problems” therefore doesn't refute my argument. It merely tells me that you don't perceive the limitations as a problem.

[yocker 1846]

4 hours ago, Teddyknuddel said:

It is also directly relevant to the problem discussed in this thread. If a genuine 4K HEVC source can end up being treated as 1080p, the obvious question is why the app isn't simply handing the original 4K stream to the playback hardware/player and letting it do its job.

It's most likely a problems with TV's and AVR's. Setting Kodi to match resolution also sets the TV to 1080p for me.
My old Sony with Android could correctly match resolutions to the source, my new LG doesn't do that.

I havn't tested connecting a computer to the TV and see what it does when setting different resolutions though but that could prove/disprove if it's the TV or the match resolution feature.

If you are not satisfied with the player that Emby uses (Exoplayer made by Google i believe for Android) then you can set it to use another one, like for example VLC.

I would also argue that not having FEL doesn't change much, as i doubt many TVs (if any) use a 12bit panel anyway.

Edited 11 hours ago by yocker

[Teddyknuddel 139]

The reference to the AVR or TV signal processing does not go far enough here. If the app misinterprets or downscales the native resolution even when the input chain is correctly connected, the problem lies with the software’s stream handling and not with the underlying hardware.

As for external players such as VLC: this does not fully resolve the underlying problem either. External players disrupt seamless integration with the Emby interface (e.g. lack of server synchronisation, erratic playback resumption or lost audio tracks). This is precisely why a clean Direct Play architecture, which works exactly like specialised hardware players with CoreELEC, is irreplaceable.

On the subject of FEL and 12-bit panels: Dolby Vision Profile 7 FEL is not simply about the panel’s colour depth, but rather that the Enhancement Layers (FEL) contain additional image information, metadata and bitrate corrections which are completely lost when falling back solely to HDR10 or inferior processing layers. Even if the panel operates internally at 10-bit, the system discards essential data from the master without a genuine FEL.

[yocker 1846]

23 minutes ago, Teddyknuddel said:

The reference to the AVR or TV signal processing does not go far enough here. If the app misinterprets or downscales the native resolution even when the input chain is correctly connected, the problem lies with the software’s stream handling and not with the underlying hardware.

As for external players such as VLC: this does not fully resolve the underlying problem either. External players disrupt seamless integration with the Emby interface (e.g. lack of server synchronisation, erratic playback resumption or lost audio tracks). This is precisely why a clean Direct Play architecture, which works exactly like specialised hardware players with CoreELEC, is irreplaceable.

On the subject of FEL and 12-bit panels: Dolby Vision Profile 7 FEL is not simply about the panel’s colour depth, but rather that the Enhancement Layers (FEL) contain additional image information, metadata and bitrate corrections which are completely lost when falling back solely to HDR10 or inferior processing layers. Even if the panel operates internally at 10-bit, the system discards essential data from the master without a genuine FEL.

Emby wants to use a resolution of lets say 3840x1600, the TV can't do that resolution so Emby falls back to 1080p which is the safest thing to do. Pretty sure the scaling will be done on the TV and not Emby.
I guess a "closer to" rule based on display device EDID could be made in Emby to avoid that but falling back is always the safest thing to do.

Not sure i understand you here.
Direct play is bit to bit perfect copy sendt to the player. The player used might strip things like the FEL layer but that is the player/device's problem IMO.
I agree that watchtime tracking is a problem with external players, i would love better integration with for example VLC, it is how ever a solution (a bit flawed i agree) to people wanting to use other players.

Not talking about falling back to normal HD.
What i meant was that the difference between Dolby Vision with and without FEL on normal TVs is so minute that a blind test would be most about luck other than actual visual differences unless you have a studio display.

[Teddyknuddel 139]

Thanks for the constructive feedback and the insights regarding the TV and AVR behavior. You raise a valid point about how modern displays handle resolution switching—especially since manufacturers sometimes implement EDID or HDMI handshake logic differently compared to older generations.

Regarding the ExoPlayer and external players like VLC: While switching to an external player is technically possible, it unfortunately breaks the seamless Emby integration (such as server sync, direct resuming, and proper audio track handling), which is why many users prefer to avoid it.

As for the point about FEL and 12-bit panels: It's true that very few consumer TVs feature a true native 12-bit panel (most high-end sets operate on 10-bit or use FRC). However, the primary benefit of the Full Enhancement Layer isn't just about outputting a 12-bit signal. The FEL stream contains critical residual data, targeted luma/chroma corrections, and specific mastering metadata that directly improves the 10-bit output image compared to a standard fallback layer.

It really comes down to whether someone wants a solution that "just plays the file" or one that preserves the complete data integrity of the original master.

FEL (Full Enhancement Layer) is the most technically sophisticated variant of Dolby Vision (Profile 7), as used primarily on UHD Blu-rays. Unlike standard Dolby Vision profiles, the FEL layer contains not only dynamic brightness metadata, but also genuine additional image information and image corrections (residual data) to bring the video even closer to the master.

Why playback is so difficult: Most standard streaming boxes and apps (such as Android TV, Fire TV or Apple TV) do not natively support FEL files. They ignore the Enhancement Layer completely and often play back only the basic HDR10 image – a so-called ‘core fallback’ occurs.

Players that offer genuine FEL support:
Ugoos AM6B Plus (with CoreELEC): Considered within the community to be the only consumer-grade hardware currently capable of outputting Dolby Vision Profile 7 FEL losslessly and natively.
Certain Amlogic-based media players (running Linux/CoreELEC): Similar SoC platforms can process FEL, provided the software architecture (such as CoreELEC) accesses the hardware interfaces directly.
Oppo UDP-203 / UDP-205 (and identical clones such as the M92 / Reavon): Dedicated high-end UHD disc players capable of correctly processing the signal from physical media or ISOs, including FEL.

But actually, FEL is a topic in its own right. That said, a good programmer could implement it on an Android platform too. Once people properly understand what it actually is and what it can do, the growth would be enormous. Ultimately, however, one thing would be absolutely essential here too: direct playback.

[yocker 1846]

21 minutes ago, Teddyknuddel said:

Regarding the ExoPlayer and external players like VLC: While switching to an external player is technically possible, it unfortunately breaks the seamless Emby integration (such as server sync, direct resuming, and proper audio track handling), which is why many users prefer to avoid it.

Audio track handling? With direct play a bit to bit perfect copy is sendt to the player so i don't see how audio could be any worse unless it needs transcoding.

Again, not talking about HDR10 fallback.
I'm saying that the difference between Dolby Vision layer 7 (FEL) and Layer 8 (Not FEL) is so small that most people would fail a blind test between the two.

Also, i'm no expert at this but i don't think it's so much an Emby problem as it is with the players and devices being used.
Android doesn't support FEL and neither does AppleTV (because of licensing i bet) . There's simply nothing Emby can do about adding FEL to those devices when they don't support it to start with. If they found a work around to support FEL they would break a lot of licenses and be in serious legal trouble.
The reason other media servers, devices and players might be able to playback something like FEL is because they are open source and maintained by a lot of different people so it's impossible for companies to stop them.
Good luck suing a company in China.  

Direct play in Emby is precisely that, a bit to bit perfect transfer of a file to the player. If the player/device doesn't support the format sendt then Emby will transcode it on the fly to a supported format. So direct play is already available for use in Emby.  

[Teddyknuddel 139]

Audio playback has absolutely nothing to do with Dolby Vision.

The Amlogic S922X-J chip is required for FEL. Very few manufacturers have this, though. And at the moment, it ONLY works with CoreELEC. With the right programming, however, it would also be possible on Android. It’s just that at the moment, most devices are Android boxes, not Android TV boxes like the Shield.

The FEL layer provides additional information. For example, with older films like *Braveheart*, which have been remastered, you’ll see a very slight pinkish tinge to the sky without the FEL layer. Not with FEL.

You simply have to see it for yourself. So you can’t just say, ‘The difference is so slight, it certainly won’t be noticeable.’

As I said, DV 7 FEL is a topic in its own right. 

But fundamental problems could generally be solved with DirectPlay. It’s just that an ebr doesn’t see it that way.

[yocker 1846]

34 minutes ago, Teddyknuddel said:

Audio playback has absolutely nothing to do with Dolby Vision.

The Amlogic S922X-J chip is required for FEL. Very few manufacturers have this, though. And at the moment, it ONLY works with CoreELEC. With the right programming, however, it would also be possible on Android. It’s just that at the moment, most devices are Android boxes, not Android TV boxes like the Shield.

The FEL layer provides additional information. For example, with older films like *Braveheart*, which have been remastered, you’ll see a very slight pinkish tinge to the sky without the FEL layer. Not with FEL.

You simply have to see it for yourself. So you can’t just say, ‘The difference is so slight, it certainly won’t be noticeable.’

As I said, DV 7 FEL is a topic in its own right. 

But fundamental problems could generally be solved with DirectPlay. It’s just that an ebr doesn’t see it that way.

You were the one mentioning audio so i responded to that.

I sometimes watch movies on blue ray, i've seen movies with it on.  
I don't really notice a difference if any at all. One would have to really look for it.

Emby does direct play, as said it sends a bit to bit perfect copy to what ever player is enabled.
Ebr or Luke would have to chime in on this but to my knowledge nothing in the video is changed by Emby when direct play is used. So if you played a movie with the FEL layer then it would be preserved all the way to the player.
If the player or device can't play back the FEL layer then that is not a problem of Emby.

One of the reasons that the Ugoos can play Dolby Vision with FEL is because it ignores any license otherwise required that others don't want to pay for.
It's made in China so can't be sued. CoreElec is open source so basically impossible to stop.
Yes a chip would be required as well but without the license any western company wouldn't be able to play back the fel if they don't want to get sued.
Other companies making android devices are simply to cheap to include the chip.

All in all..
How good FEL is can be discussed but Emby is not at fault for FEL not being played, at least to my knowledge.

[Teddyknuddel 139]

HTTP streaming isn’t DirectPlay. Genuine file access is. Take a massive 4K film, whether it’s DV or not, at perhaps 90 Mb/s, plus a massive HD audio track! That’s where Emby falls short! It stutters and jerks! And with Kodi, I’ve got DirectPlay via SMB and file access. Why isn’t that possible with the app? After all, ebr had implemented it for Experience 8.x.

[yocker 1846]

2 hours ago, Teddyknuddel said:

HTTP streaming isn’t DirectPlay. Genuine file access is. Take a massive 4K film, whether it’s DV or not, at perhaps 90 Mb/s, plus a massive HD audio track! That’s where Emby falls short! It stutters and jerks! And with Kodi, I’ve got DirectPlay via SMB and file access. Why isn’t that possible with the app? After all, ebr had implemented it for Experience 8.x.

Nothing is lost by transferring over http. It's still bit to bit perfect copy.

[Teddyknuddel 139]

Wrong!

Because the HTTP protocol and a conventional file transfer process (such as copying via a network share) work in fundamentally different ways:

• Missing file system metadata: HTTP transmits only the raw data stream (the payload of the media file). Operating system file attributes – such as timestamps (creation and modification dates), access permissions, inode information or extended attributes – are simply not included in an HTTP response header and are lost in transit.

• HTTP Range Requests (partial requests): When copying a file (e.g. via SMB), the file is transferred sequentially from start to finish. An HTTP media stream works differently: the player uses so-called range requests (206 Partial Content) to request only specific ranges of bytes – for example, when fast-forwarding or for the current buffer. At no point is a complete, contiguous copy of the file as a whole transferred.

• Server abstraction: The Emby server reads the source file and sends only the requested byte sequences to the client. Even though the audio and video streams remain bit-for-bit identical, the server processes the container structure at the application level, rather than serving the physical file on a block-by-block basis (as a file system would).

Technically speaking, this is an on-demand live data stream rather than a synchronous, complete copy of a file.

[Luke 42979]

Quote

Missing file system metadata:

Actually some of that data goes in http headers. The rest doesn’t matter to a video player.

[Luke 42979]

Quote

HTTP Range Requests (partial requests): When copying a file (e.g. via SMB), the file is transferred sequentially from start to finish. An HTTP media stream works differently: the player uses so-called range requests (206 Partial Content) to request only specific ranges of bytes – for example, when fast-forwarding or for the current buffer. At no point is a complete, contiguous copy of the file as a whole transferred.

Actually it works the same way. Players abstract this sort of thing the same way the server does.

[Teddyknuddel 139]

From the perspective of a video player, this line of reasoning is entirely correct from a functional point of view; however, it does not alter the technical definition of a bit-for-bit file copy.

• Relevance for the player: A video player requires neither file system permissions nor inode information nor creation dates to decode a video stream. For playback alone, this part of the metadata is in fact irrelevant.

• Representation in HTTP headers: Certain basic metadata, such as the file size (Content-Length) or the modification date (Last-Modified), are, of course, transmitted in HTTP headers. However, they are represented there as protocol parameters and are not part of the original file bytes on the storage medium.

• The difference compared to a file copy: A true bit-for-bit copy (such as that produced when copying via SMB or rsync, for example) creates a physically or logically identical duplicate of the file at the bit level, including all container structures and file sectors. An HTTP stream, on the other hand, delivers data dynamically and often in fragments (via range requests).

If the original statement claims that this is a ‘bit-to-bit perfect copy’, this is technically inaccurate. It involves a bit-for-bit transfer of the payload (audio and video tracks) on demand, whilst the file as a whole remains on the server and is not transferred as a bit-for-bit copy.

The term ‘DirectPlay’ is just a misnomer here. And practice proves it too. Large MKV files with HD audio, no smooth playback

[Luke 42979]

Look at the source code for an smh file access client. The network requests to get a file are not that different from http requests.