Trying to find a proper workaround for seeking in a transcoded stream

[nambona890]

Hi, I recently got a server up and running with a large collection of shows, and downloaded UMS to stream them to other devices on the network. Problem is that for transcoded streams, I can't seek through them (skip, fast forward, rewind, etc).
I haven't had good luck finding a solution to the problem. Are there any good workarounds to the problem that will let me seek while transcoding? (Apart from "you can't" or "use HandBrake to pre-transcode them all", of course)

[Nadahar]

No.

There are many details that could be discusses, and have been discussed previously on this forum, on this topic. But, if you want a short answer, there is no "solution". It isn't possible to seek in a transcoded stream because the stream is generated on the fly. As such, "the future" and "the past" of the stream doesn't exist. To get seeking to work, this must be "emulated", and that is only possible under certain circumstances. You can find more information about this by searching.

The easiest thing you can do to mitigate this is to make sure that your renderer configuration files are as correct as possible, so that only the things that really MUST be transcoded are transcoded.

[nambona890]

No.

There are many details that could be discusses, and have been discussed previously on this forum, on this topic. But, if you want a short answer, there is no "solution". It isn't possible to seek in a transcoded stream because the stream is generated on the fly. As such, "the future" and "the past" of the stream doesn't exist. To get seeking to work, this must be "emulated", and that is only possible under certain circumstances. You can find more information about this by searching.

The easiest thing you can do to mitigate this is to make sure that your renderer configuration files are as correct as possible, so that only the things that really MUST be transcoded are transcoded.

Apart from "you can't"

That's what I meant. I want to know of any workarounds or simulations or anything that can achieve what I am looking for.
Not trying to be rude, but "no" is not an answer that I am going to take.

[Nadahar]

I wish you good luck with your endeavor.

[SubJunk]

Seeking during transcoding is possible on some renderers. I've never used one where it wasn't possible, but I'm aware there are some or many that have some problem with it.
My Panasonic TV, PS3, and VLC app on iPhone are all capable of it out of the box with no workarounds

Which device are you using?

[nambona890]

Seeking during transcoding is possible on some renderers. I've never used one where it wasn't possible, but I'm aware there are some or many that have some problem with it.
My Panasonic TV, PS3, and VLC app on iPhone are all capable of it out of the box with no workarounds

Which device are you using?

I was testing the seeking on VLC for Android, but now decided it would be best to try on the TV, which is a Samsung UHD 7100.
Bizarrely, despite some series playing fine, others that use the same encoder don't play.
Going into the transcode folder, the only ones that play for the series that play fine by default are the non-transcoded files.

[mik_s]

Samsung TVs are known for not seeking wile transcoding, and while I use a PS3 I have it on custom firmware which allows me to use the superior Movian instead. Unfortunately it's only downside is lack of seeking in transcoded files. Also the last time I tried it, the web player can't either.

There must be some way of working round this issue.
When a renderer uses seek by time there must be some communication between it and the server to request moving to a different time in that file.
If using seek by byte then the renderer can't work out how far to move as the file doesn't exist in its entirety so cannot make that request (or in the case of Movian it just restarts that file.)
If that communication cannot be made by the renderer there might be a way of emulating that signal on the computer in UMS to tell the transcoding engine to move to a different part of that file. As long as there is constant data being received by the renderer it shouldn't know any different and just keep playing.

Would one of those UPnP remote control apps work? If they connect to the server they might but as they most likely connect to the renderer using it's controls, probably not.

[Nadahar]

@mik_s There's no way to communicate with any of the transcoding engines in use during transcoding. The only thing UMS can do is start them and stop/kill them.

When seeking by time, what actually happens "under the hood" is that UMS constantly keep spawning new transcoding session from the new time position - while killing off the "old" process. There is no way that I know of to actually manipulate the output stream so that it "seeks" while the renderer is non-the-wiser. But, even if it was, it wouldn't work, as the time stamps would become all wrong and "confuse" the renderer. The renderer is the one controlling playback, and thus it must have the real information.

It is no problem to get renderers to make byte range requests though - the problem is that there's no way to serve those requests. In the old days where things were CBR only, you could guesstimate the time position from the byte position by calculating a guesstimated total size for the transcoded stream. With VBR this simply isn't viable, and any attempts at doing so will lead to very inconsistent behavior.

DLNA actually has a "mode" where the server controls playback, and the renderer just consumes the stream. For those renderers that supports this, it would be possible to feed it whatever one wanted, and the renderer would only serve as a "stupid slave" which didn't try to make sense of time codes etc. The problem is that UMS would then need to do the transcoding itself, to be able to manipulate the stream on-the-fly.

A UPnP remote control application won't make any difference, all it does is send commands to the renderer like "play this URL", "stop", "pause" etc. The renderer then communicates directly with UMS with everything concerning the playback itself, and the remote control application is nothing more than a "remote control".

[mik_s]

DLNA actually has a "mode" where the server controls playback, and the renderer just consumes the stream. For those renderers that supports this, it would be possible to feed it whatever one wanted, and the renderer would only serve as a "stupid slave" which didn't try to make sense of time codes etc.

I think that is how transcoded streams are being played on those devices. My Samsung TV shows the total time of a transcoded file to be 0:04, but the current play time goes up normally. It also disables the seek controls.
On Movian the length is shown as 0:01, but the progress bar extends past that off the screen when playing. Annoyingly it dosn't disable seek controles so if you forget it's transcoded and hit rewind to go back a few seconds, it goes back to the start.

DSC_0128-small.JPG (21.81 KiB) Viewed 9322 times

When I was scanning though some info on DNLA I saw that there was support for trick modes where the file would get played 2x speed on the server but the renderer plays as normal which gave me the idea that the stream can be manipulated.

When seeking by time, what actually happens "under the hood" is that UMS constantly keep spawning new transcoding session from the new time position - while killing off the "old" process. There is no way that I know of to actually manipulate the output stream so that it "seeks" while the renderer is non-the-wiser. But, even if it was, it wouldn't work, as the time stamps would become all wrong and "confuse" the renderer. The renderer is the one controlling playback, and thus it must have the real information.

Then could it be possible to make UMS kill and spawn those new sessions manually? If the renderer is acting like "stupid slave" it should work as it has no control anyway except play, pause and stop.

It would be like having a camera pointing at a TV with it's feed going to another TV in a different room. you can watch as normal on the first, fast forwarding and rewinding, but the second TV can't control what is playing on the first and just sees any seeking as part of the feed. If the guy watching the second TV wanted to rewind he would have to shout out for the other guy to do it on his TV.

[SubJunk]

I can see most of the Samsung renderers use SeekByTime=true, what happens if you do SeekByTime=exclusive?