Jump to content

Shield ATV HDR


mamoel

Recommended Posts

mamoel

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.

post-326531-0-81009200-1530425785_thumb.png

post-326531-0-03801500-1530425793_thumb.png

Edited by mamoel
Link to comment
Share on other sites

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

mamoel

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

  • 2 weeks later...
Handl3vogn

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

Handl3vogn

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 by Handl3vogn
Link to comment
Share on other sites

  • 2 weeks later...

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?

  • Like 1
Link to comment
Share on other sites

Handl3vogn

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

Guest asrequested

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

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

Guest asrequested

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 by Doofus
Link to comment
Share on other sites

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

Waldonnis

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

Guest asrequested

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

Waldonnis

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

Guest asrequested

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

Guest asrequested

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

Waldonnis

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 by Waldonnis
Link to comment
Share on other sites

Guest asrequested

 

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

Guest asrequested

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 by Doofus
Link to comment
Share on other sites

Waldonnis

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

Guest
This topic is now closed to further replies.
×
×
  • Create New...