Jump to content

Emby Server on Nvidia Shield Pro: Unsafe at any bitrate


Netfool
 Share

Go to solution Solved by ebr,

Recommended Posts

'SubType' is an "invention" of Microsoft as part of their DirectShow API. 

Read the H.264 spec. The different bitstream formats exist, but they are neither called "SubType" nor "AVC1".

Link to comment
Share on other sites

So if using hardware codecs is a decision that needs to be made on a file-by-file basis, shouldn't that be a setting on the Conversions page when you set up a particular conversion, rather than on the global Transcode Settings page where you may or may not remember how you last set it?

I'll try a conversion of that file with the hardware codec disabled and see what happens.

Link to comment
Share on other sites

...and while were on the topic (subtopic) of the Emby Server UI:  It would be really nice to have a "Rotate Logs" button on the Logs page, rather than haveing to click down to Scheduled tasks and back.  That would make it easier to submit small focused logs here.

 

Link to comment
Share on other sites

3 minutes ago, Netfool said:

So if using hardware codecs is a decision that needs to be made on a file-by-file basis, shouldn't that be a setting on the Conversions page when you set up a particular conversion, rather than on the global Transcode Settings page where you may or may not remember how you last set it?

I'll try a conversion of that file with the hardware codec disabled and see what happens.

For playback transcoding, we're automatically falling back to sw transcoding in case hw transcoding fails. I think that is missing in case of conversions.

Just now, Netfool said:

...and while were on the topic (subtopic) of the Emby Server UI:  It would be really nice to have a "Rotate Logs" button on the Logs page, rather than haveing to click down to Scheduled tasks and back.  That would make it easier to submit small focused logs here.

 

Good idea!

@Luke

Link to comment
Share on other sites

So the conversion attempt with the Nvidia H.264 hardware codec turned off also failed instantly.   I'm starting an ffmpeg -copy to an mp4 container on the Linux media store box just to see what happens.  I'll have to read-up on ffprobe.

embyserver.txt

Link to comment
Share on other sites

33 minutes ago, softworkz said:

'SubType' is an "invention" of Microsoft as part of their DirectShow API. 

Read the H.264 spec. The different bitstream formats exist, but they are neither called "SubType" nor "AVC1".

Yes MS defines 5 different subtypes but they are also respected and adopted by other media producers and HW including Apple and Intel for example. They are described in Annex B of the ITU-Rec. H.264 specification I believe at least that what Intel says but I haven't verified it.

These files require a different decode sequence. Try doing a google search for "MP4/AVC Decode using the Intel® Media SDK" which covers the differences in using their SDK to decode them.

I don't have a link handy but do have the paper and could upload it.

It's worth at least looking at since the AVC1 files do seem to be the problem. There is definitely a difference in the presence or not of start codes between them. 

 

Link to comment
Share on other sites

20 minutes ago, Netfool said:

So the conversion attempt with the Nvidia H.264 hardware codec turned off also failed instantly.   I'm starting an ffmpeg -copy to an mp4 container on the Linux media store box just to see what happens.  I'll have to read-up on ffprobe.

embyserver.txt 268.98 kB · 1 download

Do you or can you setup a PC based Emby Server just to load a couple of these files into a library to see what happens on the PC version of Emby Server with them?

That could be a big help.

Link to comment
Share on other sites

3 minutes ago, cayars said:

Yes MS defines 5 different subtypes but they are also respected and adopted by other media producers and HW including Apple and Intel for example. They are described in Annex B of the ITU-Rec. H.264 specification I believe at least that what Intel says but I haven't verified it.

These files require a different decode sequence. Try doing a google search for "MP4/AVC Decode using the Intel® Media SDK" which covers the differences in using their SDK to decode them.

I don't have a link handy but do have the paper and could upload it.

It's worth at least looking at since the AVC1 files do seem to be the problem. There is definitely a difference in the presence or not of start codes between them. 

 

Right, it's called 'AnnexB'. ffmpeg handles the differences in stream formats via bitstream filters. This is probbly the "most famous" one: https://ffmpeg.org/ffmpeg-bitstream-filters.html#toc-h264_005fmp4toannexb

It should actually get inserted automatically when needed in newer ffmpeg versions.

Link to comment
Share on other sites

2 hours ago, cayars said:

Do you or can you setup a PC based Emby Server just to load a couple of these files into a library to see what happens on the PC version of Emby Server with them?

That could be a big help.

Well... not a Windows pc, but I did set up an emby server on the Linux media store box, and I'll give it a try there.  It's only an atom processor so it's likely way underpowered, and it's a headless box so there's no GPU to speak of at all.   Probably can't report back until tomorrow.   I did do an ffmpeg codec -copy  from the cli on that file and this is what it looks like in Emby Media Info.    I'll try in the Emby server tomorrow.  Haven't tried to play it.  Other folks are using the TV this evening.

 

2 hours ago, softworkz said:

Could you please add the ffmpeg log?

Thanks

Not sure which one it is.  I'll do it again in the morning and report back.

Screen Shot 2020-07-20 at 8.05.33 PM.png

Link to comment
Share on other sites

19 hours ago, cayars said:

Do you or can you setup a PC based Emby Server just to load a couple of these files into a library to see what happens on the PC version of Emby Server with them?

That could be a big help.

I did.  Emby Server is now running on the media store linux box.  That's a 4-core 1.86GHz Atom Processor with 8GB of RAM and no GPU, just the vga graphic controller in the Atom chip.

Using the same settings that failed instantly above (TV profile, Original Quality), the conversion ran to completion with no problem.  It did so rather slowly, taking about 2 hours.  1251694136_ScreenShot2020-07-21at12_48_36PM.thumb.png.5431eb0d3d22c027bebc4a94d2286f2a.png

834387367_ScreenShot2020-07-21at12_48_56PM.thumb.png.6db3828d17cb98b23f023e99da6ff86e.png

The dashboard showed the conversion sitting at 100% for another 25 minutes, apparently while subtitle extraction was underway.  As you can see about there are a lot of subtitles.

During the conversion CPU utilization never got above about 35%, and in fact rose when the subtitle extraction started about 12:10:35.

144443397_ScreenShot2020-07-21at11_45_39AM.thumb.png.2327e840f6c3c0f4f4a6a77d0f583a1d.png364421199_ScreenShot2020-07-21at12_13_53PM.thumb.png.294d671791bfdd937657ab1504e50dac.png

Wouldn't it be grand to have a version of NetData that ran on the Nvidia Shield?

It's interesting that on the same box, an ffmpeg codec -copy to change containers to .mp4 runs in about 5 minutes.  I don't know what else Emby Server is doing that makes the process take so long as the Media Info specs for the two files are quite similar:67112055_ScreenShot2020-07-21at1_50_16PM.thumb.png.1ec81ead7a2b858c5cf502dc0ed7cfe5.png

It's interesting that this file has BOTH Codec Tag: avc1 and AVC: Yes. That's not something I've seen on any of the other files.

I have not yet tried playing any of the conversions through the HDMI output on the NVIDIA Shield Pro.  Since the failures occur more than 30 minutes into the film, testing them all would involve rewatching many hours of the same film.  Any suggestions on an alternate way to test for a file that works?

embyserver.txt ffmpeg-remux-92844f42-18b4-445b-97b2-4fa44fde039c_1.txt

Link to comment
Share on other sites

Let us know if this files plays back properly on the Shield TV.

Link to comment
Share on other sites

That turns out to be easier said than done.  From the Shield UI (Not the web UI), how do I tell which file is which?  i.e. How to I get to Media Info on the Shield UI?   It doesn't show me either Media Info or the actual file name when looking at the output of the Shield HDMI connector.

Both the Shield Emby Server and the Linux Emby Server use the same network media store, but they present the 4 versions of the film in a different order in the library.
Can I be assured that the order is the same when viewed through the Shield HDMI connector and the webUI of the Shield Emby Server?

Edited by Netfool
To fix a typographical error.
Link to comment
Share on other sites

Rename them slightly different and use the version feature.

File  - original.mp4

File  - converted.mp4

Link to comment
Share on other sites

Resume them from the Shield HDMI UI?  ...and where exactly in the UI is the "version feature"?  It doesn't appear to be documented anywhere.

Edited by Netfool
to correct emphasis.
Link to comment
Share on other sites

So... playing what I believer it the version from the Linux Emby server convertsion using Profile: TV Quality: original quality (based solely on it's position in the library listing), it stalled at 16.04 on the timeline.  When I hit back I was given the choice to resume from 15.54 (minus 10 seconds, which I have a very vague recollection as having been a default I chose sometime, somewhere).  Clicking the resume option gave me the stalled video, and no information at all as to "version feature".   Now trying the version done with ffmpeg codec -copy to change the container to .mp4.   ...but clearly based on all of the discussion of H.264 specs above the word "container" has several different meanings I don't begin to comprehend.

I'll report back what happens.

Edited by Netfool
to correct a typographical error.
Link to comment
Share on other sites

Ahhh.... I was wrong!   I was clearly hasty in concluding that the video had "stalled".  Actually what appears to have happened is that it's just playing excruciatingly slowly:

1047809723_ScreenShot2020-07-22at12_19_42AM.png.5656a4647d978cc59f0c4d6af736f2cd.png

Note the 5.6 fps frame rate while it transcodes from H264(AVC) to H264(AVC) !!?!!     So if I play any of these through the WebUI, they work nicely, and the dashboard says they are "direct playing".  But I can't direct play the same content through the HDMI port.   

But I can play them through the WebUI and they "direct stream".    Playing the same files through the WebUI from the Atom box (with no GPU) also works.  All I loose in either case seems to be the ability to resume if I hit the back button.  (Hitting play/pause works).  

So this leads to the obvious conclusion that the NVIDIA Shield Pro is incapable of running both Emby Server and the Emby Client simultaneously (unless there is some way to force "direct play" through the HDMI port).  So to use the rather elegant Shield remote as a primary remote for the TV means that I must move to server to a less capable machine with no GPU capability at all.

Please, please, PLEASE tell me if I'm wrong about that!

The next problem I have to tackle is getting content from an HDHomeRun into the library.  So far, my experience with Emby Server on the Shield Pro is that it can't record a local TV stream without stalling for about 750ms every 60 to 90 seconds.   I'll do some testing on the Atom box to see if that's any worse, but it doesn't look like anything in the Shield hardware is helping the problem.  I'm currently using an HDHR Duo, but I have an (apparently now discontinued) HDHR Extend arriving next week which claims to have internal hardware transcoding capability which I hope will help.

....but that's another topic! (Coming soon to a forum near you!)

 

 

Edited by Netfool
Fixed spacing issue.
Link to comment
Share on other sites

Any chance we could do a remote TeamViewer session to get a look at your problems and try to help?

If so, send me a PM and we can arrange a session to go over a bunch of things and try to solve your issue.

Carlo

Edited by cayars
Link to comment
Share on other sites

Hi.  If you turn on the "Debug" setting in the app settings, you will see media info in the detail screen of the Android TV app.  Also, if you click that little "i" on the dashboard during transcoding playback, it will tell you why it is transcoding.  Stats for Nerds in the app will also tell you (under the cog menu during playback).

Link to comment
Share on other sites

3 hours ago, ebr said:

If you turn on the "Debug" setting in the app settings, you will see media info in the detail screen of the Android TV app

Aha!  So that's Emby Player App > Settings (gear icon) > General Display > [Scroll all the way down] > Enable Debug Options checkbox.  That's an immense help.  Now I can see which version I'm about to play.

3 hours ago, ebr said:

Stats for Nerds in the app will also tell you (under the cog menu during playback).

The TV with the Shield is otherwise occupied right now, but I'll look for that, althugh I don't remember being able to do anything but pause and adjust volume during playback on the Shield.

It would be really great if there were a sticky post at the top of this forum with all of the little hidden tricks like these (with some screen shots).  It would help us noobs ask better questions.

Keep in mind that what you all are doing is trying to educate "a bear with very little brain" as A.A.Milne put it.    Thanks for the help!

9 hours ago, cayars said:

Any chance we could do a remote TeamViewer session to get a look at your problems and try to help?

Certainly, but let me do a little more digging with the tricks @ebr just showed me.   What time zone are you in?

Link to comment
Share on other sites

EST but can generally help from about 6 am to 12 am (midnight).

Link to comment
Share on other sites

I fear that in our travels through the maze of twisty little passages that is the H.264 spec, I may have lead everyone down the wrong rabbit hole.

I think the problem is far simpler if we step back a bit.

I decided to test a different file.  An extreme case when it comes to bandwidth and bitrate.  893900948_ScreenShot2020-07-22at12_15_25PM.thumb.png.9f287abfe541cf3bd9d6478d6abe0c5d.png

Now please correct me if I'm wrong, but looking at the NVIDIA Shield Pro > Emby Player App > Settings (gear icon) > Playback, there is a setting for Maximum Streaming Bit Rate.

I had assumed that by "Streaming" it meant flinging video packets over the net.  But it appears that the limit also applies to the output of the HDMI connector on the Shield.  Keep in mind that both the Emby Server on the shield and the Emby Server on the Linux box both use the same media store.  Local in the case of Linux and network attached in the case of the Shield.

  1. Using the Shield remote I selected the video and hit play.   It played for a few minutes and then started stalling.
  2. I opened the Shield's webUI on my iMac and played the video.  It played smoothly to completion.
  3. I opened the webUI to the Linux Emby server instance and played the video.  It played smoothly to completion.

On the Shield's dashboard Active Devices looked like this:

136916488_ScreenShot2020-07-22at12_11_33PM.png.f732fc3b9e6dbb3cc111847d41fe4b08.png

Note that even though I started playing the Shield version first, at the point at which the screeshot was taken the direct stream to the webUI had overtaken the HDMI output.

The circle-i icon on the transcode showed this:

1985909432_ScreenShot2020-07-22at12_12_25PM.png.b741bd6bb76b2b9c95244e957edd2883.png

And the circle-i icon on the direct stream showed this:

1020304368_ScreenShot2020-07-22at12_12_02PM.png.51f44484e5226d5a719d3f2a9271ae87.png

The repackaging is presumably because MacOS won't natively play .mkv files.

I don't understand why it's harder to shove bits out of an HDMI port than it is to fling them over the network. Certainly there are a lot more moving parts involved in the latter.   But then,,,. there are a lot of things about video standards and GPUs I don't understand.

The inescapable conclusion is that despite all of it's advanced GPU technology and hardware codecs, the Shield can play this over the net far better than it can drive the HDMI input on a TV.

I have one more test to make this evening:  I currently have Handbrake chewing on the video to produce a 5Mb/sec .m4v.   We'll see if that can play through the HDMI output on the Shield.

That's going to necessitate reconversion of a good chunk of the 6TB media store, but it will also free up a bunch of space.  The challenge is how to do it.  I tried doing with ffmpeg on poor little Atom box, but it pinned the cpu usage to 100% and made the system quite unresponsive. 

The (quite ironic) interim solution is to check the media info before playing (having debug options on makes that possible on the Shield UI), and then switching the Shield Emby Player App to the Linux Emby server to watch the offending videos.  

This evening when the household is done with the TV, I'll try that and report back.  I'll also report back what happens when I try to play the 5Mb/sec file from Handbrake.

Link to comment
Share on other sites

17 hours ago, ebr said:

Hi.  If you turn on the "Debug" setting in the app settings, you will see media info in the detail screen of the Android TV app.  Also, if you click that little "i" on the dashboard during transcoding playback, it will tell you why it is transcoding.  Stats for Nerds in the app will also tell you (under the cog menu during playback).

 

14 hours ago, Netfool said:

I don't remember being able to do anything but pause and adjust volume during playback on the Shield.

I'm Sorry!  I misunderstood what you said there.  I didn't realize that "Debug" settings are in the Emby Player App on the Shield, and "Stats for nerds" is in the webUI.  

Got It now!

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
 Share

×
×
  • Create New...