Would it make sense to implement a transcoding "cache" mechanism if it were even possible? As in, once a video source has been transcoded, a copy is left on the media server's hard drive. Thus if a DNLA client requests the resource yet again, the cached file can be simply passed through, instead of transcoding again.
The way it could work is a user-defined cache size might be designated in the master config which sets aside a determined amount of hard drive space. Item containers would have an additional flag to indicate cache state status. All transcoded / remuxed streams are written to this cache. Subsequent requests for said resource can utilize the cache, thus reducing overall CPU loads.
Not sure if all the Pro's and Con's warrant this idea. The "cache" would need to be quite large if you consider how much space a MPEG2 stream may blow out to. But would help in situations where video files are relatively short and numerous, and CPU horse power is limited.
Is all honesty, it would make better sense for DNLA clients to implement a type of "cache" on their end instead. But convincing manufactures to adopt this might pose a challenge, plus the uPNP protocol standards might need to be enhanced to support.
Just a thought.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
This "feature" request just goes to show how poorly the DLNA/uPnP as a Standard really is… Let's face it, if the protocol allowed for a greater support of codecs and container formats we really wouldn't have to do much transcoding in the 1st place !!
On a side-note; has anyone noticed the echo (echo….echo….echo) in this forum?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Would it make sense to implement a transcoding "cache" mechanism if it were even possible? As in, once a video source has been transcoded, a copy is left on the media server's hard drive. Thus if a DNLA client requests the resource yet again, the cached file can be simply passed through, instead of transcoding again.
The way it could work is a user-defined cache size might be designated in the master config which sets aside a determined amount of hard drive space. Item containers would have an additional flag to indicate cache state status. All transcoded / remuxed streams are written to this cache. Subsequent requests for said resource can utilize the cache, thus reducing overall CPU loads.
Not sure if all the Pro's and Con's warrant this idea. The "cache" would need to be quite large if you consider how much space a MPEG2 stream may blow out to. But would help in situations where video files are relatively short and numerous, and CPU horse power is limited.
Is all honesty, it would make better sense for DNLA clients to implement a type of "cache" on their end instead. But convincing manufactures to adopt this might pose a challenge, plus the uPNP protocol standards might need to be enhanced to support.
Just a thought.
This "feature" request just goes to show how poorly the DLNA/uPnP as a Standard really is… Let's face it, if the protocol allowed for a greater support of codecs and container formats we really wouldn't have to do much transcoding in the 1st place !!
On a side-note; has anyone noticed the echo (echo….echo….echo) in this forum?