Jellyfish file tests - General questions (Side Note: ATMOS eARC passthrough in the comments)

This is strictly for my own education. I’m trying to get a better understanding of how Plex works with all my equipment. I saw some other posters talk about the jellyfish video bitrate test files (http://jell.yfish.us/) and I got curious about them and decided to see what my clients would play.

Hopefully I’m not asking a bunch of dumb questions. I’ve been reading through these forums a bit for the past few months and I find it interesting. Trying to chip away at my ignorance.

I’m only looking at direct play scenarios on my local network right now.

I realize that the iPad doesn’t support Dolby TrueHD audio and that is causing an audio transcode with a direct stream for video when playing the 140Mbps file that has an audio track.

The Shields and my PC are plugged into an LG 65C9 OLED via HDMI and the tv is connected to a Sony STR-DH790 receiver using eARC.

Here is a picture of my network setup:

I typically get around 110MB/s file transfers between my NAS and my PC on the other side of the network:

So I put the various Jellyfish files on my NAS and tried to play them on my clients and this is the result:

20-60Mbps

140Mbps and up:

So some of my questions are:

  1. Is the client hardware/software combination the limiting factor in playing back these particular files? My PC using Plex for Windows had the most success. Is that because it has the processing capacity to deal with 300Mbps files?

  2. Is it safe to assume that my NAS and network connections are fast enough to feed my clients as much data as they can handle? I realize a simple Windows file transfer and Plex handing data from the server to the client are not exactly the same thing, but the file transfer speed would suggest my network is good up to the 880Mbps range.

  3. How does Plex decide that these simple video only files need to be transcoded? It looks like the Nvidia Shields are trying to convert the 200Mbps files (based on the “Not enough CPU…” error). Does the client know how much it can handle and report that to the Server?

I realize that a lot of these tests are fairly impractical. I don’t expect to have any files that reach these bitrates. I’m interested in understanding more, and at the very least, possibly ruling out my network’s speed capabilities in any future troubleshooting.

Anyway, I would be interested in hearing what more knowledgeable people have say and if you can point me at relevant reading material, it would be greatly appreciated.

Edit: 25 May @15:42
Added 20-60Mbps results.

1 Like

For a true sense of fairness,

How about also testing 20-30-40-50-60 Mbps ?

Such rates would be much more practical and useful to others, yes?

Good point. I guess I assumed if the 140Mbps file played then the lower rate files would play. I’ll go ahead and add them (eventually :sweat_smile:).

I was hoping to understand why files that didn’t max out my network’s throughput capability would fail to play on various clients. I suppose you can deliver 10 cheeseburgers to a client but it can only eat 1 at a time… or 4, depending on the client…

140x 1 lb cheeseburgers is much more realistic than 1x 140 lb cheeseburger, don’t you agree? :rofl:

-or-

a whole lot of ribs

-or-

:slight_smile:

Why are the shields not plugged into the avr? Is it 4k capable?
Edit: I read 4k and HDR, plug the shields into the avr, saves you trouble with HD audio.

Hopefully. Arc in general often doesn’t work as smooth as expected in my experience.

highly depends on the vendor and their implementation (e.g. if / how much they still meddle with the data stream)

True, my experience with arc in general is mediocre. I avoid it whenever I can.

I keep telling that to my past self who didn’t bother about that when buying my TV

:smiley: It is never too late for changing the setup :wink:
You never know if it works until you have tested it in your living room with your very own components…

That is one of the things I’m trying to understand. There are a lot of factors for each piece of equipment in the chain and I’m trying to learn the limitations of each.

I still have occasional playback issues and I try to troubleshoot to make sure all the various parts in my setup are connected and configured properly. I think what these jellyfish file tests are getting me is whether or not my NAS and network are a weak link in the chain or not. For direct play, that is. I don’t expect my DS416play to transcode any of my files, nor do I want it to.

Frankly it is amazing to me that Plex and other media players like it can handle all the various equipment and file format combinations as well as it does.

The TV and AVR have eARC and so far it seems to be working very well. I have a couple files where TrueHD causes problems (Akira, Batman Begins) with the Shield, but they work with Plex for Windows (plugged into the same TV and AVR) so I’m guessing that is a Shield issue and not an eArc issue. I was really surprised that I could passthrough HD audio with my PC to the AVR because I haven’t figured out how to get 5.1 audio from my games through HDMI.

Please include lower bitrate files as well as if you have hw transcoding features enabled or not. I have been using these test files for a long time with plex and frankly found playback issues on much lower bitrates that you describe here, problems I have never been able to resolve. 40mbps HEVC was an issue even.

@ChuckPa I added the 20-60Mbps results to the first post so people won’t have to dig through the thread for them.

@mervincm All the 20-60Mbps jellyfish files direct played on all my clients (except the old player on the iPad, which I’m not all that interested in). I have pretty much disabled the transcoding on my NAS server because I primarily use it at home and would rather direct play my files. Also, my NAS isn’t very good at transcoding my files. I choose whatever options that the clients have to play maximum quality and to passthrough the audio to my receiver.

Here are my server transcoder settings if you are interested:

Sounds good. I agree completely with both your idea of testing with direct play and direct stream first, as well as concentrating on devices on the local network.

I also think it was worthwhile to show that at lower bitrates, everything is smooth as glass (for the players you care about anyway)

Obviously you have the bandwidth (100 MB/sec) to handle everything, and other than ipad, you are using wired networking, so unless you have that router in the middle doing VLAN or subnet to subnet routing, latency is not likely an issue. Also the PC shares the network path and it is more or less fine.

Thankfully the problems you are having (on these test files) are more of less theoretical. I doubt you are going to run accross any actual media over 180 mbps video.

I don’t doubt that the Ipad and the PC have the most powerful GPU based HEVC decoders, and the fact that they can handle higher bitrates isn’t shocking to me.

If you are wondering if a more powerful server would help, install PMS on you PC, configured similarly with transcoding disabled.

I think your 140 mbps w audio strutter on ipad was indeed caused by the nas CPU not up to the task of the single threaded task of converting TRUEHD audio to AAC. this test also could be repeated from your PC based test plex server.

Your LG TC can also play Plex and natively handle the majority of these codecs, I wonder if you tried that at all? I use the app built in my LG OLED C7 almost exclusively in that room.

I didnt notice you also have a sheild pro, you could plex server on that too and see what happens.

I tested the jellyfish files on my shield 2017 and 200 Mbps is also the limit there, meaning this files cannot be played back. So same results as for your clients.

Just to jump back in for a moment…

You’re all enjoying testing your networks and systems, aren’t you? :smiley:

Find any weaknesses which you didn’t expect?

Has this been a good learning experience?

Indeed. I have no clue why 200 mbit is the limit…

Probably either the drive just can’t write that fast, or it’s hitting the actual bandwidth limit on the HEVC/H.264 hardware decoder. I don’t know what the limit is on the Shield, but certainly many TVs from only a few years ago max out around 60 mbps with HEVC or H.264.

I see, thanks for explaining. 180 mbit is also enough for real streaming.

When I started ripping my blu-rays and dvds back in the day, I left in the embedded PGS/VOSUB subtitles. I now know that goes against the common recommendations but Android TV clients seem to play them fairly well. That is one of the things that led me to the Shield devices. Also, I don’t think my TV can direct play those subtitles and it doesn’t have gigabit ethernet, so I just stick with the Shield.

I am glad I ran the tests and it has been a good learning experience. As far as weaknesses which I didn’t expect: I didn’t exactly know what to expect. I’m not an expert at this and the possibility that I set something up wrong in the chain was a real possibility. If I’m having a problem playing something, I’d like to figure out if it is something I can fix myself or if it is something inherent to the equipment and software that is essentially out of my control.

I was having problems for months playing some 1080p files on the Shield Tube that I don’t think should be too hard for a client to handle. Based on these tests I can assume it wasn’t a bitrate problem with my setup. I switched to the Shield Pro and they play fine. I still don’t quite understand what it is about certain files that caused that issue on the tube. I’ve seen people say it has something to do with the memory on the Shield Tube but that is beyond my capabilities to do anything about (other than switching devices). Here is a link to the thread if you care to look at it:

So, as both @Coxeroni and @rwoffice have mentioned, the Shield seems to be good up to 180Mbps of raw bitrate, and my setup seems to be good for that throughput. Now if I have problems playing something I can run the 180Mbps jellyfish test again to see if my network and NAS are still up to snuff. Then I can move onto other troubleshooting steps.