Wed Jul 31, 2013 3:30 pm
Transcoding Cache
I get the impression that Serviio currently uses a temporary directory for transcoded files, and doesn't hang-on to them for very long, hence I was wondering whether a cache might make more sense for performance reasons?
So, I'm thinking that Serviio could essentially be tweaked to serve the original media file if that's playable, but if not check whether it has a transcoded version of it in its cache that's playable, and if so serve that, and if not transcode the original media file, add it to the cache, and serve that. Just in case pseudo code is any clearer:
Obviously, the media cache would need some limits in order to prevent it from getting too big, but that just means deciding what to delete from the cache and when, and could be something primitive like when adding a media file to the media cache check whether there's enough space for it, and if not delete the media file(s) accessed the longest ago until there is. Just in case pseudo code is any clearer:
No doubt there'd be several other things to consider that would make the feature more complicated to implement, such as whether to have separate caches for the different media types (video, audio and image), what to do if the cache isn't big enough, and what to do if the media file you want to delete from the cache is currently being played, but they are hopefully all nothing too tricky that would make the feature more effort than it's worth!
Note: I guess there's also the potential to make use of the caching feature in order to provide another feature, i.e. to automatically transcode media files when they're added to the database, so that they're ready to play when requested, thereby avoiding issues with insufficient CPU power for transcoding on the fly. Obviously, there'd be quite a few issues to consider/resolve with that though, such as managing the initial database population and what media devices need supporting!
So, I'm thinking that Serviio could essentially be tweaked to serve the original media file if that's playable, but if not check whether it has a transcoded version of it in its cache that's playable, and if so serve that, and if not transcode the original media file, add it to the cache, and serve that. Just in case pseudo code is any clearer:
Obviously, the media cache would need some limits in order to prevent it from getting too big, but that just means deciding what to delete from the cache and when, and could be something primitive like when adding a media file to the media cache check whether there's enough space for it, and if not delete the media file(s) accessed the longest ago until there is. Just in case pseudo code is any clearer:
No doubt there'd be several other things to consider that would make the feature more complicated to implement, such as whether to have separate caches for the different media types (video, audio and image), what to do if the cache isn't big enough, and what to do if the media file you want to delete from the cache is currently being played, but they are hopefully all nothing too tricky that would make the feature more effort than it's worth!
Note: I guess there's also the potential to make use of the caching feature in order to provide another feature, i.e. to automatically transcode media files when they're added to the database, so that they're ready to play when requested, thereby avoiding issues with insufficient CPU power for transcoding on the fly. Obviously, there'd be quite a few issues to consider/resolve with that though, such as managing the initial database population and what media devices need supporting!