Andy777 21 Posted October 12, 2016 Posted October 12, 2016 @AngelBlue These two things are kind of feature requests, but I think they are really more related to the Emby API versions and the playback rework that you mentioned earlier: Problem: EmbyForKodi doesn't benefit from Kodi video caching mechanism when the stream is transcoded. Transcoding currently produces lots of small .ts files and a .m3u8 playlist. Even if the Kodi video cache is increased (via advancedsettings.xml), the cache is not filling if paused. With flaky connections (e.g. in a moving car) it would be beneficial to the end user experience if Kodi cache would download as much as it can during the moments of "good connections" and during connection breaks the video would stream from the Kodi cache. With the current small-chunk-ts files this is not possible. Background to a solution : If transcoding is not needed (and the video is direct streamed as original), the Kodi cache works as expected. Similarly if using Chrome as client (instead of Kodi) the transcoding doesn't create small .ts pieces, but transcodes to a single file. Ideal situation: When transcoding is needed, it should work similar to when using Chrome as a client -> then Kodi would be able to cache the video as fast as the connection/settings/transcoder would allow. The user experience on flaky slow connections would be greatly enhanced. 4K downscaling and transcoding: If the original video is 4K, selecting any "HD" transcoding option in the maxBitRate setting of the EmbyForKodi addon does _not_ trigger downscaling of the 4K video. Transcoding 4K60fps H264 video of original bitrate of 100MBps to 3MBps, while still preserving the original resolution and fps doesn't make any sense. The PQ would be better with downscaling and lower compression with the same allowed bitrate. By previous conversations (and a thread in the server-area about the 4k transcoding), I am pretty sure that these are things that are related to the Emby API version used for playback. Please do not take these as complaints, but as possible avenues of improvements whenever you have time/interest on the work on the playback code. Thank You for your important work! BR, Andy777
Angelblue05 4132 Posted October 12, 2016 Posted October 12, 2016 Yeah, I hear you. it's because our current playback methods don't use update features from the server. We have a playback branch on github where we did update transcode the way it works to be on par with other clients, however, there's still a few things I want to look over before it's ready for beta. Sent from my iPhone using Tapatalk
Recommended Posts