The issue is probably that 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..)
Author
Topic: LG TV renderer: Seeking within a (transcoded) video not possible!? (Read 2035 times)