This is a quote from AndrewFG from another topic:
"(...)When MC has to transcode video to another format that the TV can play, it is not providing an HTTP Content-Length header. This means that the TV has no reference point enabling it to calculate the byte range offset for a byte-range seek command. The MC developers say that this is because they cannot calculate the Content-length in advance until the full transcoding has been completed. This statement is indeed logically true. I have personally been trying to encourage JRiver that even if they cannot calculate an exact Content-length in advance, they should deliver an estimated value. This would allow the TV to do a Seek and even if the byte destination is a bit off, it would still move onwards in the track, and would certainly be better than the current situation where the track starts replaying at zero. (Also MC would need to be able to satisfy such a byte range seek by converting that into an estimate time seek offset. If JRiver were clever about it, the estimated content-length and the estimated byte seek offset could refer to each other and the resulting time seek offset would actually be pretty accurate..)"
I fully support AndrewFG's suggestion and hope the developers implement this as soon as possible as it is a show stopper for longer transcoded videos.
Assume you are looking "LOTR - The Return of the King - Extended Edition" and have just watched half of the film but must stop now. You will have to rewatch the first half of the film again the other day when the video is transcoded because your TV can not play it otherwise. Not good.
That's a really urgent one to be solved!
Author
Topic: FR: Provide a Content-Length header for transcoded video (PLEASE!) (Read 1170 times)