Shield can't play some 4k HDR movies

[Guest asrequested]

Ooh, really bad. But not for me [emoji3]

You are also on Oreo?

 

Nougat. But as I get the same thing with my GTX 1050, it would appear this is Nvidia, not Android.

[pünktchen 1259]

Nougat. But as I get the same thing with my GTX 1050, it would appear this is Nvidia, not Android.

If it's working for me, then it's not Nvidia nor Android! What's your display setting on the shield?

[PenkethBoy 2063]

Initially i could not get the sample to play at all - and even getting emby to transcode - made ffmpeg choke

 

So

 

I put the sample through MKVToolNix and removed the vobsub stream and emby can play it fine via Web App and the Shield Nougat

 

No picture breakup - plays all the way through fine.

[Guest asrequested]

If it's working for me, then it's not Nvidia nor Android! What's your display setting on the shield?

 

So why does it no play with cuda on with my GTX 1050, and does with everything else. Even on the shield with other apps, it plays. Just not with ExoPlayer

 

Initially i could not get the sample to play at all - and even getting emby to transcode - made ffmpeg choke

 

So

 

I put the sample through MKVToolNix and removed the vobsub stream and emby can play it fine via Web App and the Shield Nougat

 

No picture breakup - plays all the way through fine.

 

 AH! Nice! I hadn't thought about the subs. Groovy! I'll try it right now.

[Guest asrequested]

Alas no, false hope. I sliced off another piece, this time keeping it mkv and removing all the subs and leaving one audio track. No bueno. But I did remux the mp4 file, back to mkv and removed the sub. That seemed to work. 

 

CUDA still choked on everything, in the HTPC. So my report to Nvidia still stands.

 

For those who want to test further. Here's the file that was sliced off and has only the video and audio.

Edited June 24, 2018 by Doofus

[Guest asrequested]

Ok, this is weird. The pieces I've sliced off, now have the same issue with nvdec-copy. And PDVD also has the same problem with it. In fact, nothing I have will play it. I did a straight copy, and removal. So it may be a mux issue, after all?????

[Waldonnis 148]

I found several references of ExoPlayer having problems with files that used (zlib) header compression for one or more of its tracks (especially subtitles, apparently).  Without seeing the original file, it's hard to tell if that's in play here, though.

 

Nothing in the encoding settings looked odd to me at first glance.  Out of curiosity, are all of the problematic files cropped like this one to remove the letterboxing?  It's probably a driver/blob bug, though.  Some of the artifacts look like prior/unallocated memory content.  I'm wondering if it's trying to decode an entire buffer that was allocated but not totally filled from the content (which would be a facedesk-worthy bug).

[Guest asrequested]

I found several references of ExoPlayer having problems with files that used (zlib) header compression for one or more of its tracks (especially subtitles, apparently).  Without seeing the original file, it's hard to tell if that's in play here, though.

 

Nothing in the encoding settings looked odd to me at first glance.  Out of curiosity, are all of the problematic files cropped like this one to remove the letterboxing?  It's probably a driver/blob bug, though.  Some of the artifacts look like prior/unallocated memory content.  I'm wondering if it's trying to decode an entire buffer that was allocated but not totally filled from the content (which would be a facedesk-worthy bug).

 

None of them have the letterboxing, but some of them are full 16:9. I just tried playing the mp4 again, and it played fine. So I'm remuxing the entire movie to mp4 without subs, to see what the result is.

[Waldonnis 148]

None of them have the letterboxing, but some of them are full 16:9. I just tried playing the mp4 again, and it played fine. So I'm remuxing the entire movie to mp4 without subs, to see what the result is.

 

That should oust any header compression, since I don't think mp4 supports the same types of compression that Matroska does.

 

If some of the misbehaving files are full-frame 2160p, then my partial theory doesn't really apply I guess    Not sure why it seems to be dragging in other frames' (or unrelated) data, though...probably a CUDA driver issue or an implementation bug.

[Guest asrequested]

That should oust any header compression, since I don't think mp4 supports the same types of compression that Matroska does.

 

If some of the misbehaving files are full-frame 2160p, then my partial theory doesn't really apply I guess    Not sure why it seems to be dragging in other frames' (or unrelated) data, though...probably a CUDA driver issue or an implementation bug.

 

It's a headscratcher. DVDfab doesn't seem to be able to complete the remux. It chokes at 99% (22.6 GB). I'm at a loss to pinpoint what's happening.

[Waldonnis 148]

It's a headscratcher. DVDfab doesn't seem to be able to complete the remux. It chokes at 99% (22.6 GB). I'm at a loss to pinpoint what's happening.

 

Try it with ffmpeg directly, since it'll be more descriptive.  If you just want the video and audio with no subs, it should be as easy as:

ffmpeg -i input.mp4 -map v -map a -c copy output.mkv

[Guest asrequested]

I have never used ffmpeg from the command line. And just change mkv to mp4?

Edited June 25, 2018 by Doofus

[Waldonnis 148]

I have never used ffmpeg from the command line. And just change mkv to mp4?

 

Yup, should be no problem:

ffmpeg -i input.mp4 -map v -map a -c copy output.mp4

Just to explain what it's doing....

The -map option tells it which streams in the file to include for processing.  -map v tells it to include all video streams, -map a includes all audio streams, and since we don't want subs, we purposely don't map them (if we wanted them too, we'd add -map s).  The -c copy tells it to copy everything, or in this case, everything we specified with the -map options.  This is pretty much the easiest command line to construct since we just want every stream of specific types (all audio/video) and are just copying everything (yay remux).  It gets more complicated when you want to map only specific streams or transcode/manipulate certain streams while not touching others, but you get used to it.

 

Oh, and if you wanted a total remux that includes all streams, you can just use one mapping: -map 0 , which includes every stream present in the (first) input file.

Edited June 25, 2018 by Waldonnis

[Guest asrequested]

So just put the ffmpeg.exe in the same folder as the movie and run the command line in that location? I just grabbed the latest zeranoe build. Total noob at this

[Waldonnis 148]

So just put the ffmpeg.exe in the same folder as the movie and run the command line in that location? I just grabbed the latest zeranoe build. Total noob at this

 

Yup, or put it somewhere in the path...or call it directly with the path.  You could even use Emby's with the APPDATA user environment variable if you haven't relocated your Emby install, like so:

%appdata%\Emby-Server\system\ffmpeg -i input.mp4 -map v -map a -c copy output.mp4

I use ffmpeg and other such commands so much that I just added my media utility directory (where I put all of those binaries) to the system path a while ago.  If I want to test a different build instead, I just shove it in the same directory as where I'm working or call it like above if I want to use Emby's.

[Guest asrequested]

I'm not in the right headspace for this, at the moment. I'll maybe try it, later. Thanks, though.

[Waldonnis 148]

It's the weekend...you're entitled to it 

[Guest asrequested]

mp4 wouldn't work, so I shoved it in a .ts container. It didn't change the playback. Nvidia have asked for a sample, so I sent it to them.

[Waldonnis 148]

Wacky.  Hopefully, they can figure out what's going on.

[Guest asrequested]

Yeah, and I just got another movie with the same issue

 

And to clarify what I mean by mp4 wouldn't work. ffmpeg couldn't do it

Edited June 27, 2018 by Doofus

[Waldonnis 148]

Yeah, and I just got another movie with the same issue

 

And to clarify what I mean by mp4 wouldn't work. ffmpeg couldn't do it

 

Okay, now that's downright strange.  Wondering if these files are malformed or damaged somehow.  Any error coughed up by ffmpeg?  Worst case, you can add -v debug to the ffmpeg command and it'll spit out all kinds of detail as to what it's doing (or use -report, which will create a text file with the output instead of logging it to stdout).

[Guest asrequested]

Okay, now that's downright strange.  Wondering if these files are malformed or damaged somehow.  Any error coughed up by ffmpeg?  Worst case, you can add -v debug to the ffmpeg command and it'll spit out all kinds of detail as to what it's doing (or use -report, which will create a text file with the output instead of logging it to stdout).

 

This is what it says at the end

[mp4 @ 0000029bc7ffcc00] Could not find tag for codec truehd in stream #1, codec not currently supported in container
Could not write header for output file #0 (incorrect codec parameters ?): Invalid argument
Stream mapping:
  Stream #0:0 -> #0:0 (copy)
  Stream #0:1 -> #0:1 (copy)
    Last message repeated 1 times

Edited June 27, 2018 by Doofus

[Waldonnis 148]

Oh, okay.  mp4 can't hold TrueHD streams, so that's what's happening there.

 

Looking at the mediainfo you posted before, you can map the lossy (AC-3) track instead just as a test (just change -map a to -map 0:2 and use the original file as the input; 0:2 means the third stream in the input file, which should be the AC-3 track).

 

Also, if you just want to nab a segment of the file rather than the whole thing, you can add a -t <secs> to the command (or -to <time>) to only nab X seconds (or up until the time given in -to).  For example, if you just wanted the first minute, you can either add -t 60 or -to 01:00 and it'll stop after it hits that mark (I prefer using -t, but that's mostly habit and I often know the number of seconds from frame timestamps anyway).

[Guest asrequested]

I'm remuxing the new one .ts, right now. Just to see what happens 

 

meh! No change. It's in Nvidia's hands

Edited June 27, 2018 by Doofus

[Waldonnis 148]

I'm remuxing the new one .ts, right now. Just to see what happens 

 

meh! No change. It's in Nvidia's hands

 

Yeah, probably for the best, especially since it seems so inconsistent, and there's nothing that jumped out and slapped me about the encoding settings (not far from my own generic settings, actually).  On the plus side, you dipped a toe into the ffmpeg pool now, so at least something was gained out of it.