Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[JimH]

Another key requirement from my point of view is the ability to specify local decoding - again something that Panel doesn't currently do, I believe.  A key feature of Android TV boxes are that they can decode most file types (h264, h265, etc), often at up to 4K.   Having to have everything decoded on an MC server, as Panel does it now, is very undesirable for this use case.

Thanks for the feedback.  I may split this to a new thread, but I want to understand this better.

Right now, in Panel, when you are playing "here", you can choose one of four different compression levels:  1080, 720, 480, and 240.

I know that we should probably have another choice for "no change".

The codec used must be something that the browser support.    This will change over time, but I'm not sure why you would need to select one.  We should chose the best available.

The point I really don't understand is why you would want conversion done on the client side.  Why use the bandwidth needed to transfer a big file, then convert it to something smaller?   And there are technical reasons that it should be done on the server.  We can begin conversion, then begin streaming, while the rest of the file is being converted.

I admit that I'm not expert in this area, so that's why I'm asking.

[jmone]

Ideally, you would want an option where the client is able to select the Video / Audio / Sub streams with MC server then delivering those streams without re-encoding.  The client then would do the Video and Audio rendering.

[jmone]

I had a play with Panel again on the weekend, and as an example, the "best" is a 1080p profile and it does not have an AutoFPS option (though there is already that option for DNLA and conversion in MC).  The end result when playing a UHD BD video from MC to a 4K TV it was  trans-coded down to 1080p but also then interpolated from 23 to 30fps. 

[Hendrik]

The point I really don't understand is why you would want conversion done on the client side.  Why use the bandwidth needed to transfer a big file, then convert it to something smaller?   And there are technical reasons that it should be done on the server.  We can begin conversion, then begin streaming, while the rest of the file is being converted.

Because on the client side you may not do any conversion, you may just do playback, which is far cheaper and usually done by dedicated hardware. Not converting is better for quality and saves a lot of processing resources on the server (ie. you may get away with a really low power server if all files can be served that way, while conversion requires quite some beefy system). And Bandwidth is usually not a concern on a local network.

The difficulty is that not necessarily all files can be played directly on the client, so for an optimal result you would have to have some smarts that can selectively serve you content that is known to work, and convert that which isn't. And also some additional conversion features that maybe can convert audio only (because HD audio formats may not be supported by a browser), or keep both audio and video as-is and just re-pack it into a new container that the TV/Browser understands (which is a common case, and would be significantly less resource intensive then a full conversion).

To achieve that goal there is some work to do on both sides, the clients (ie. Panel and others) would have to somehow communicate which formats they support, and MC might then have to decide how to deliver the video. And of course those new delivery mechanism would have to be build.

[jmone]

Hendrik said it better.

[Hilton]

The other reason not to transcode is if you're watching a 4K HDR movie the HDR meta-data will get lost in the transcode. So the picture won't look right unless you do a HDR to SDR conversion on the server in the transcode. Which kinda defeats the purpose of having a nice shiny new 4K HDR TV.

The main reason NOT to touch the original quality, is to maintain the original disc quality. That's the whole purpose of buying UHD blurays.  If you take away the ability to have the native UHD bluray quality because everything is going to be transcoded, you may as well skip the buying and ripping process and just play a lower quality stream from one of the streaming content providers. And if you do that, you dont end up using MC or panel anyway.

Streamed 4K content is typically under 16Mbit/s  whereas UHD Bluray is anything between 65Mbit/s and 128Mbit/s. 
That lost bitrate is visible in the comparisons I've done with compression artifacts, softness and particularly with darker scenes displaying more noise and artifacts. Colours are also not as bright.

So in my opinion, native client side decode is even more important to stay relevant with those of us that buy original discs, (and a large portion of your future user base) especially where HDR is concerned. 

[tjobbins]

Because on the client side you may not do any conversion, you may just do playback, which is far cheaper and usually done by dedicated hardware. Not converting is better for quality and saves a lot of processing resources on the server (ie. you may get away with a really low power server if all files can be served that way, while conversion requires quite some beefy system). And Bandwidth is usually not a concern on a local network.

Yeah this was my reasoning.  In my envisaged use of an Android client, I definitely want to do simple playback with no conversion.   Both my Android TV boxes and my Google Pixel phone are capable of playing all the video files in my library as-is, with no transcoding, and this would be the default use-case for me.

And as Hendrik mentions, I also want to save processing resources on the server.   Right now my MC server runs in a VirtualBox VM, on my home server/NAS.  I put it in there so it would be guaranteed to be available at all times that my media was online, and so that I could do library management without affecting anyone currently watching media on the HTPC. 

The first (and only) time I tried Panel on one of my Android boxes, I saw that the CPU on that MC Server VM went immediately to 100% as the MC server was transcoding everything before sending it to the Android client.    I knew from experience that my Android box has the necessary codecs and capabilities to play every video in my library directly - ie if I simply opened that file directly in Kodi, loaded from the SMB share, it would display fine.  So this forced transcoding seemed like a big waste of resources, and quite likely unsubstainable: if I had two such clients playing files simultaneously, I doubt the MC server could have kept up with both at once, given that just one took it to 100% CPU.

Jim asked "why transfer a big file and convert it to something smaller".  I guess this is because Jim is primarily thinking of the Android client as being used on handheld phones, accessing the library remotely, where bandwidth is an issue?  And yes, in that use case I would want to choose to transcode down to 720p or whatever, with a low bitrate, so as not to blow my monthly data allowance on one video.   

But I envisage the vast majority of my Android usage occurring locally, over Ethernet (for the Android TV boxes) or WiFi (phone/tablet).  Bandwidth here is no issue, so it's much more important to avoid the CPU cycles on the server and potential quality losses of transcoding than it is to minimise the bitrate.  The only conversion I'm likely to want is DSP stuff, like converting 5.1 soundtracks down to 2.0.  But again I'd like to be able to do that on the client, just like I do today in MC.

In summary, I can see there are use cases where transcoding will be valuable, but equally I believe an option of "no change" is also vital.

[fitbrit]

Hendrik said it better.

+1

I responded to the old thread before realising it was split. Hendrik summed it up perfectly.

[tzr916]

For me the main reason to NOT do VIDEO transcoding on the Server is because the cpu LOAD on the Server is tremendous. Any Android device that I have can decode video on the device.