mamoel 3 Posted July 1, 2018 Share Posted July 1, 2018 (edited) I have a video file that isn't recognized/played as HDR with my Nvidia Shield when played back by emby. Other files with HDR content do not have this problem. But the problematic file is playing fine with Kodi, Plex and MrMc. It seems to me that emby uses another algorithm to detect the HDR metadata. I attached two screenshots from MediaInfo. "hdr" - a file that is recognized as HDR by emby "no_hdr" - the file that emby can't play with HDR (but other players can) Any ideas how I can force emby to play this file as HDR? There's no transcoding, so I can't attach a transcoding log. I can provide a 10 sec sample via PM if it helps. Edited July 1, 2018 by mamoel Link to comment Share on other sites More sharing options...
ebr 14913 Posted July 1, 2018 Share Posted July 1, 2018 Are you saying that the media info in our web app does NOT indicate this item is HDR? Link to comment Share on other sites More sharing options...
mamoel 3 Posted July 2, 2018 Author Share Posted July 2, 2018 I didn't even know there's a media info section in the web app, but I finally found it ;-) And it clearly shows "Video range: HDR". Stats for nerds shows a Video Bitrate of 26.4 MBps and Audio at 500 KBps (Shield is set at 80MBps). So the question is why doesn't it want to output HDR to my TV? Link to comment Share on other sites More sharing options...
ebr 14913 Posted July 2, 2018 Share Posted July 2, 2018 You are positive ffmpeg is not involved at all? Link to comment Share on other sites More sharing options...
mamoel 3 Posted July 2, 2018 Author Share Posted July 2, 2018 Yes, I am. Link to comment Share on other sites More sharing options...
Handl3vogn 6 Posted July 15, 2018 Share Posted July 15, 2018 I think I have this problem as well. Some videos plays in hdr using emby app on my shield TV, but others won't aktivate hdr on my TV. If I play them in Kodi every video plays in hdr. Link to comment Share on other sites More sharing options...
Handl3vogn 6 Posted July 18, 2018 Share Posted July 18, 2018 Here is an example on working and non working hdr playback on nvidia shield TV using emby app. Link to comment Share on other sites More sharing options...
Luke 37067 Posted July 18, 2018 Share Posted July 18, 2018 Strange as they're almost identical. Link to comment Share on other sites More sharing options...
Handl3vogn 6 Posted July 18, 2018 Share Posted July 18, 2018 (edited) Yeah I see that but both files plays as HDR in Kodi on the shield. When using the emby app some of my HDR files plays as HDR and some plays in regular SDR Edited July 18, 2018 by Handl3vogn Link to comment Share on other sites More sharing options...
xenu 10 Posted July 31, 2018 Share Posted July 31, 2018 I noticed here as well as in the other topic on this issue that the problematic files have a resolution of 3840x1600 whereas the working files are 3840x2160. This could be coincidence but coud that mess with HDR detection/metadata of the internal decoder? 1 Link to comment Share on other sites More sharing options...
Handl3vogn 6 Posted July 31, 2018 Share Posted July 31, 2018 Thanks @@xenu I can check this further when I'm getting home. Have some other files that won't play in hdr using the emby app. Hope they all are 3840x1600 Link to comment Share on other sites More sharing options...
Guest asrequested Posted July 31, 2018 Share Posted July 31, 2018 That probably means the padding is removed and was re-encoded. It's the re-encoding is likely the issue, and the decoder is having an issue with it. Link to comment Share on other sites More sharing options...
ebr 14913 Posted July 31, 2018 Share Posted July 31, 2018 That probably means the padding is removed and was re-encoded. It's the re-encoding is likely the issue, and the decoder is having an issue with it. That would be my initial assumption as well... Link to comment Share on other sites More sharing options...
Guest asrequested Posted July 31, 2018 Share Posted July 31, 2018 (edited) That would be my initial assumption as well... I'm curious to see what Nvidia, find. Every decoder other than CUDA, will play them. It's my understanding that ExoPlayer is utilizing the native device decoders or at least their architecture, correct? Which, in the case of the shield, looks like it's CUDA. Edited July 31, 2018 by Doofus Link to comment Share on other sites More sharing options...
ebr 14913 Posted July 31, 2018 Share Posted July 31, 2018 It's my understanding that ExoPlayer is utilizing the native device decoders or at least their architecture, correct? Yes, Exo uses the native decoders available on the device. Link to comment Share on other sites More sharing options...
Guest asrequested Posted July 31, 2018 Share Posted July 31, 2018 Yes, Exo uses the native decoders available on the device. Thanks for confirming, that. Link to comment Share on other sites More sharing options...
Waldonnis 148 Posted August 1, 2018 Share Posted August 1, 2018 That probably means the padding is removed and was re-encoded. It's the re-encoding is likely the issue, and the decoder is having an issue with it. Wouldn't be the first time. I'd be suspect of any cropped HDR files, personally, unless they were re-encoded properly. I've seen a few "less than legit" samples that just set the transfer characteristics on the container level, but didn't encode it in the bitstream, for example, so HDR mode wasn't being toggled on during playback on some monitors. It's not hard to tell if the metadata and proper signalling is there early in the bitstream, but it requires an extra option or two for ffprobe than Emby currently does. Speaking of which, how does Emby determine what to label as "HDR"? Is it specific values like the smpte2084 transfer, colour primaries, or pixel format...or some combination of those? I can offer up a sample ffprobe that will show the metadata from the bitstream as well if it would be worthwhile (stuff like CLL or the mastering display metadata if present). Link to comment Share on other sites More sharing options...
Guest asrequested Posted August 1, 2018 Share Posted August 1, 2018 Wouldn't be the first time. I'd be suspect of any cropped HDR files, personally, unless they were re-encoded properly. I've seen a few "less than legit" samples that just set the transfer characteristics on the container level, but didn't encode it in the bitstream, for example, so HDR mode wasn't being toggled on during playback on some monitors. It's not hard to tell if the metadata and proper signalling is there early in the bitstream, but it requires an extra option or two for ffprobe than Emby currently does. Speaking of which, how does Emby determine what to label as "HDR"? Is it specific values like the smpte2084 transfer, colour primaries, or pixel format...or some combination of those? I can offer up a sample ffprobe that will show the metadata from the bitstream as well if it would be worthwhile (stuff like CLL or the mastering display metadata if present). But what's curious, is that other decoders seem to be able to play them, correctly. Link to comment Share on other sites More sharing options...
Waldonnis 148 Posted August 1, 2018 Share Posted August 1, 2018 But what's curious, is that other decoders seem to be able to play them, correctly. Yep, definitely. Not saying it's a likely cause, but nothing surprises me these days. It could be as simple as CUDA's decoder is just ignoring signalling in the bitstream entirely or not passing it along. It's puzzling, though, why it would do this for some files and not others. Really, if only the cropped files are showing the problem and only using CUDA decoding, then there may be more than just a decoding problem at play. Link to comment Share on other sites More sharing options...
Guest asrequested Posted August 1, 2018 Share Posted August 1, 2018 Yep, definitely. Not saying it's a likely cause, but nothing surprises me these days. It could be as simple as CUDA's decoder is just ignoring signalling in the bitstream entirely or not passing it along. It's puzzling, though, why it would do this for some files and not others. Really, if only the cropped files are showing the problem and only using CUDA decoding, then there may be more than just a decoding problem at play. Yeah. I'll be interested to see what Nvidia, say. There's definitely something up with CUDA, though. NVDEC, works well. Link to comment Share on other sites More sharing options...
Guest asrequested Posted August 1, 2018 Share Posted August 1, 2018 It's puzzling, though, why it would do this for some files and not others. Really, if only the cropped files are showing the problem and only using CUDA decoding, then there may be more than just a decoding problem at play. I have uncropped movies that also have the issue. But they have been re-encoded. It just feels like new encoding algorithms that aren't fully supported. Link to comment Share on other sites More sharing options...
Waldonnis 148 Posted August 1, 2018 Share Posted August 1, 2018 (edited) I have uncropped movies that also have the issue. But they have been re-encoded. It just feels like new encoding algorithms that aren't fully supported. Any chance you could split out the first 10secs of one of them and lob it to me? I'd like to see the bitstream and container info. The following should do it: ffmpeg -i input.mkv -map v -c copy -t 10 output.mkv Edited August 1, 2018 by Waldonnis Link to comment Share on other sites More sharing options...
Guest asrequested Posted August 1, 2018 Share Posted August 1, 2018 Any chance you could split out the first 10secs of one of them and lob it to me? I'd like to see the bitstream and container info. The following should do it: ffmpeg -i input.mkv -map v -c copy -t 10 output.mkv When I get a chance, sure. Link to comment Share on other sites More sharing options...
Guest asrequested Posted August 2, 2018 Share Posted August 2, 2018 (edited) OK, I haven't tested this one on the Shield, but this is one that has no padding and is full 16:9 that has been re-encoded, and cuda can't play it. I lopped off 20 seconds. Edited August 2, 2018 by Doofus Link to comment Share on other sites More sharing options...
Waldonnis 148 Posted August 2, 2018 Share Posted August 2, 2018 Hmm, I'm seeing the right parameters in the bitstream's SEI and SPS at first glance, so I'm not sure what could be going on quite yet. I only did a quick look so far, so I'll need to take a closer look in a bit. It also played just fine and triggered HDR mode on my television, so I'm a bit more confident that the file is fine and that the issue is somewhere on the CUDA/decoding side. Link to comment Share on other sites More sharing options...
Recommended Posts