Universal Media Server | Forum

Hi there,

I'm new to UMS and everything is working fine so far (so, thanks already for all the great work!) except: Streaming jpeg images to a Chromecast feels very slow:

- for images with 12 MegaPixel (MP) and around 4MB, switching from one image to the next takes around 5 seconds
- for images with 2 MP and several 100KB, it is almost immediate

I'm not even sure where to bottle neck is, but if it is the downsampling on the Chromecast (or the wifi bandwidth), is there a possibility to transcode (i.e. downsample) my jpegs? (I found all the options for audio and video transcoding and remuxing, but almost nothing on plain images).

Thanks much!
-Stephan

There is no such setting. The Chromecast itself isn't DLNA/UPnP AV compliant and as such isn't really a supported device (UMS is a DLNA/UPnP AV server). I supposed that you use BubbleUPnP or similar to control the Chromecast, and if so the "problem" is really with the remote control software.

UMS will transcode images to a different format if they're not supported by the renderer. It will offer them to the renderer in several sizes (the original size, plus some fixed downsized sizes as specified by the DLNA standard). UMS will resize them according to what the renderer requests.

I haven't seen a renderer (although, I haven't seen that many devices - you can't buy them all to test them) that has any settings for which size to use, I think the general idea is that the renderer will pick the "best" version that it can display. In any case, the idea is that the renderer controls this and that the server simply serves.

Since Chromecast doesn't support DLNA/UPnP AV, whatever software you use in between is making those choices on behalf of the Chromecast. Again, I suspect most software will simply pick a format and size that is supported by the Chromecast.

It would be possible to implement a "maximum image size" restriction in UMS that would downsize every image above a certain size, but this hasn't been implemented. I don't know what takes the most time, it could be the transfer or it could be resizing either by UMS or by the Chromecast. A trace log where you viewed some of these large images would shed some light on where this, it would at least tell us the time from the image is requested until it starts uploading - and if UMS spends considerable time on converting it. I don't know if it would help much though, as there isn't really anything we can do to speed it up that I'm aware of other than downsizing it. That might not be that quick either, as Java's image manipulation is in fact pretty slow, only testing would what could be gained by doing this.

Thanks for the very helpful reply! I wasn't even aware that the Chromecast is not a native DLNA device... .

For the sake of completeness I attached a tracelog, using viplayer for ipad to browse through some images (which causes a delay of several seconds, before the image appears on the Chromecast attached TV). However, I will probably not pursue this path... .

Cheers
Stephan

Here is an example of the request/response for one of the images from your log. As you see, resolution 3872x2592 is explicitly requested. The image doesn't need any conversion, so UMS replies (and thus starts the transfer of the image itself) after 865 milliseconds. The reason it takes that long is that a lot of checks of the properties of the image is checked first, because DLNA has a lot of requirements for what qualifies as a valid JPEG (like file format version, huffman tables, color depths etc.). The image is quite large (4.3 MB), so processing it will take some time although I must say I am a bit surprised that it takes this long. It should be said that UMS is doing several things in parallel here (there are other requests happening at the same time), but still it's a long time to only verify a JPEG. If your

There's no way to see in the log when the transfer is completed (it's handled by underlying Java components, not UMS' code) so we can't tell how much time the transfer itself takes. Assuming a "normal" Wifi transfer speed of 30-50 Mb/s which translates to ~4-6 MB/s, the transfer itself should take somewhere around 1 second. It all depends on what Wifi equipment you use and the signal strength though, it doesn't take much to make Wifi even much slower. Whatever wait time takes place in addition to 1.5 - 2 seconds should be the time the Chromecast use to convert the image.

If UMS were to downscale the image, it would still spend the time on analyzing it first, plus a probably significant conversion time. The transfer would be faster though.

There should be room for improvement in the time it takes to analyze it, but this is done by external libraries (not UMS code) so the improvements would have to take place there. I'd have to look at it further to see exactly which part spend how much time, but there's two different libraries used (metadata-extractor and ImageIO). ImageIO is known to be quite slow, especially since Java 8 as Oracle replaced a proprietary library they used in previous versions with an open source one that is much slower.

Your CPU is quite slow and you only "give" UMS 683 Mb of memory. It might help a bit to increase the amount of RAM UMS is able to use. This is set during the installation, but you can change it later by using regedit and changing "HeapMem" under "HKEY_CURRENT_USER\Software\Universal Media Server". The value is in MB. The speed of your E: harddrive probably has a lot to do with the time UMS spends on analyzing the image. Since your CPU is ~10 years old it might be that your harddrive is relatively slow as well?

Implementing a maximum size for images might be a worthwhile idea. Sending a higher resolution than what the renderer can display isn't that useful, unless you want to be able to zoom in on renderers that let you do that. The biggest potential for improvement here probably lies in the libraries we use to analyze the images though. Spending that much time indicates that the whole file is read at one point during the analysis. Reading the file header should be enough to analyze a JPEG as far as I can understand.