Stream api - StartTimeTicks does not work with Static=true

[pünktchen 1345]

@@Luke when creating a request with

/videos/{id}/stream?Static=true&StartTimeTicks={xxxxx}

the playback always starts at the beginning of the stream. Shouldn't Emby make a streamreader byte seek here before sending it through the Http Server?

[Luke 39650]

No, that should happen client-side.

[pünktchen 1345]

What about the http header Range: bytes=

I can see in the logs Emby is responding with 206 for partial content but the stream is returned from the beginning.

[Luke 39650]

Exactly, you'd use the range header for that. Try direct playing something in Chrome and open the chrome debugger and watch the network tab.

 

Then once it starts playing, do a seek and then look at the request that Chrome sends for that.

[pünktchen 1345]

Unfortunately the Range request header doesn't work as expected for me. I've set Range as a "RequiresHeader" parameter of "MediaSourceInfo" in my special live tv plugin. But the range is only used one time at LiveTvManager "Open shared channel stream". After this, in all other Emby actions especially ffmpeg, the streaming url is used without the header!

 

Beside my special usecase, shouldn't the header be passed and set within Emby's ffmpeg sessions? Otherwise the header parameter is just nonfunctional.

[Luke 39650]

I don't really know the full picture of what you're trying to do so it's hard for me to say. 

[pünktchen 1345]

As explained in my other thread i want to use Emby's video library as a source for custom live tv channels.

The plugin is already working. I have a guide and playback is also working in general. But i'm still searching for the fastest and at the same time resource-efficient playback methods.

To make playback realistic i need to open the video/library item that sits behind the current guide program with an offset. Right now i'm doing this by returning an url to Emby's streaming api with StartTimeTicks=xxxxx, VideoCodec=copy and AudioCodec=copy.

This works but stresses unnecessary my HDD, especially since you've removed the ReadAtNativeFramerate parameter.

[Luke 39650]

Ok unfortunately what I said earlier is really the right approach. When direct playing the video player needs to be given an instruction to start at a particular time. Then it will do the range requests and figure out the correct byte offset based on the desired time.

[pünktchen 1345]

Yes, but the range header gets lost after opening the shared channel stream.

I guess every header, also referer, forward or something like that get lost with the ffmpeg call.

[pünktchen 1345]

@@Luke can you please please please bring back the "ReadAtNativeFramerate" parameter?!

That would help so much!!!

Why was is it even removed?

[Luke 39650]

We saw nothing was using it, and with so many transcoding changes happening it's often easier to cut things out that are obsolete rather than preserve them and have to rebuild them. What do you want to use it for?

[pünktchen 1345]

We saw nothing was using it, and with so many transcoding changes happening it's often easier to cut things out that are obsolete rather than preserve them and have to rebuild them. What do you want to use it for?

As explained some posts before to get a video with stream copying at a defined start position at lowest resources but sometimes also for transcoding.