Anyway to do direct stream?

[rykr 11]

Sorry if I'm not using the right term?

 

I'm trying to speed up channel tuning and ff/rw.  It shows that my Roku tv is not compatible with what I presume to be the .ts container and it has to repackage it.  Is this the same for all Roku?  Will a Roku ultra be different?    I'm looking for devices that can direct stream with no transcoding/repackaging going on.  Or at least no transcoding.

[speechles 1917]

Sorry if I'm not using the right term?

 

I'm trying to speed up channel tuning and ff/rw.  It shows that my Roku tv is not compatible with what I presume to be the .ts container and it has to repackage it.  Is this the same for all Roku?  Will a Roku ultra be different?    I'm looking for devices that can direct stream with no transcoding/repackaging going on.  Or at least no transcoding.

 

The issue we have when playing these is the .TS container tells the Roku this is a live-stream. It disables seeking. You cannot fast-fwd or rewind. You are stuck in real-time.

 

We like you to be able to seek. We want you to be able to seek. We tell ffmpeg to repackage the streams into a new container and copy both the video and audio(if audio is supported). This means we simply repackage the TS into HLS using an m3u8 playlist and TS slices. This allows you to seek within the stream.

 

You can use the stats for nerds in the app (video player OSD cog). When stats for nerds is enabled it will show exactly what is going on. With a directstream or remux the FPS will be ridiculously high. This is so close to direct play that the time to start will be almost identical and for all practical reasons it is. It is within a second with direct playing versus direct streaming. 

 

Why do you feel this is an issue? The Roku ultra will be faster to tune due to the faster processor but it will not be instant. To get instant the TS container needs to be direct playable and seekable on the device. There are very few devices where this is true. The Roku has an internal buffer that must fill before it starts to play. The app developer has no control over this initial retrieving/buffering/loading delay. The bits need to get to the Roku faster. Once Roku has gigabit ethernet connections instead of megabit it might be possible to shovel data at it faster.

Edited April 24, 2019 by speechles

[rykr 11]

The issue we have when playing these is the .TS container tells the Roku this is a live-stream. It disables seeking. You cannot fast-fwd or rewind. You are stuck in real-time.

 

We like you to be able to seek. We want you to be able to seek. We tell ffmpeg to repackage the streams into a new container and copy both the video and audio(if audio is supported). This means we simply repackage the TS into HLS using an m3u8 playlist and TS slices. This allows you to seek within the stream.

 

You can use the stats for nerds in the app (video player OSD cog). When stats for nerds is enabled it will show exactly what is going on. With a directstream or remux the FPS will be ridiculously high. This is so close to direct play that the time to start will be almost identical and for all practical reasons it is. It is within a second with direct playing versus direct streaming. 

 

Why do you feel this is an issue? The Roku ultra will be faster to tune due to the faster processor but it will not be instant. To get instant the TS container needs to be direct playable and seekable on the device. There are very few devices where this is true. The Roku has an internal buffer that must fill before it starts to play. The app developer has no control over this initial retrieving/buffering/loading delay. The bits need to get to the Roku faster. Once Roku has gigabit ethernet connections instead of megabit it might be possible to shovel data at it faster.

 

 

 

My issue is channel tune speed.  I'm comparing this to Kodi + Tvheadend which tunes my hd homer prime channels in 4-5 seconds from a cold stop.   On  my Roku tv I get 14-17 seconds from a cold stop.  It takes 5-6 seconds before I start seeing the filling buffer screen.  I've tested this on two different Roku TV devices (one wireless and one wired) going to two different servers (one running in docker on a core i7 860) and one running on Mac OS running on a Skylake core i7.  Not really any different speed.

 

I haven't measured it but I can tell that my shield tunes faster but I don't know how much.

[speechles 1917]

My issue is channel tune speed.  I'm comparing this to Kodi + Tvheadend which tunes my hd homer prime channels in 4-5 seconds from a cold stop.   On  my Roku tv I get 14-17 seconds from a cold stop.  It takes 5-6 seconds before I start seeing the filling buffer screen.  I've tested this on two different Roku TV devices (one wireless and one wired) going to two different servers (one running in docker on a core i7 860) and one running on Mac OS running on a Skylake core i7.  Not really any different speed.

 

I haven't measured it but I can tell that my shield tunes faster but I don't know how much.

 

We can speed this up but it would cause you to lose the ability to seek on the Roku. We can direct play these just like Kodi(http paths). The Roku though will see these TS in direct play and treat them like OTA liveTV. There will be no way to seek.

 

What we presently do is directstream/remux when we see a TS. Not because the container is not compatible with Roku. But because if we direct play this it won't let you seek. So that extra delay is due to us having to spawn ffmpeg, feed it parameters, start hardware/software encoders/decoders, etc.. Once that process begins it takes time. Then the Roku itself has to buffer before it will play. It wants a certain size buffer completed before it allows playback. We see this as the purple retrieving/loading bar. That part is out of our control. How fast you can push bits at the Roku determines how quickly the retrieving/loading disappears and what you want starts to play.

 

Would you be willing to lose the ability to seek within the LiveTV stream if it were to launch in half the time? Keep in mind you can pause. You can seek through the pause buffer. It is just you cannot break through real-time which in this case will be how far the Roku has played that channel. If this is a recorded TS(as in time shifted) we cannot direct play as you can never fast-forward. You have to play in real time if we direct play recordings because it will think this is a livestream. If you are okay with losing the ability to seek and having to pause to gain a rewind buffer for faster launch of real-time LiveTV there may be something we can do with a setting. 

Edited April 24, 2019 by speechles

[rykr 11]

We can speed this up but it would cause you to lose the ability to seek on the Roku. We can direct play these just like Kodi(http paths). The Roku though will see these TS in direct play and treat them like OTA liveTV. There will be no way to seek.

 

What we presently do is directstream/remux when we see a TS. Not because the container is not compatible with Roku. But because if we direct play this it won't let you seek. So that extra delay is due to us having to spawn ffmpeg, feed it parameters, start hardware/software encoders/decoders, etc.. Once that process begins it takes time. Then the Roku itself has to buffer before it will play. It wants a certain size buffer completed before it allows playback. We see this as the purple retrieving/loading bar. That part is out of our control. How fast you can push bits at the Roku determines how quickly the retrieving/loading disappears and what you want starts to play.

 

Would you be willing to lose the ability to seek within the LiveTV stream if it were to launch in half the time? Keep in mind you can pause. You can seek through the pause buffer. It is just you cannot break through real-time which in this case will be how far the Roku has played that channel. If this is a recorded TS(as in time shifted) we cannot direct play as you can never fast-forward. You have to play in real time if we direct play recordings because it will think this is a livestream. If you are okay with losing the ability to seek and having to pause to gain a rewind buffer for faster launch of real-time LiveTV there may be something we can do with a setting. 

 

Def don't want to give up timeshifting.  Just comparing it to kodi + tvheadend which tunes channels in 4-5 seconds and I can still ff/rw, etc.  That's going to a raspberry pi so not an overly powerful system.   I'm not that familiar with the Roku system so not saying you guys are doing anything wrong.  Just wanting it to be better since I'd love to use my Roku tv without an external box.   As it is I really can't right now as the experience is just not good.   

 

1.  Slow tuning

2.  Slow ff/rw.  With other platforms once it buffers hitting the ff/rwd button nearly instantly moves you there.  With Roku that's not the case

3.  No subtitles for live tv

4.  Grid is slow to navigate.  You get 4-5 lines in a page and then there is a light pause when the next page loads

 

Just off the top of my head.

[speechles 1917]

1.  Slow tuning

2.  Slow ff/rw.  With other platforms once it buffers hitting the ff/rwd button nearly instantly moves you there.  With Roku that's not the case

3.  No subtitles for live tv

4.  Grid is slow to navigate.  You get 4-5 lines in a page and then there is a light pause when the next page loads

 

Just off the top of my head.

 

#1 and #2 are directly related to the expense of directstream/remux and involving ffmpeg. For timeshifting we have to do this.

 

#3 is something we need to improve. I have this on our issue tracker as an issue/concern and we will address it as soon as we can. We will be able to generate subtitles on LiveTV streams we just have to investigate.

 

#4 is potentially something we can eventually address. That one takes more special care because the lower the power of a Roku the lower its RAM and CPU budget is to spend. So right now on the LiveTV you are correct. We are cripple the experience of the higher end models to make the lower end not suffer. This provides a consistent experience no matter the Roku model. We aren't spending all amount of power we could be when utilizing the LiveTV grid presentation. You can bet with a little bit of time to dig into this we could solve the problem and keep the ability differentiate between devices and give the more higher end models more loading at once instead of just one page. These are areas we know we need to improve. This is also one of those areas where it is a priority because LiveTV is a premiere feature. Premiere features take priority over lower.

 

 

If there were any way to immediately improve any of these areas with just a few hours work I would spend that time right now and set whatever else I was doing aside. But this will require more than just a few hours. It will require more time to figure out how to diffentiate devices (although I already do have most of the game plan there done from earlier work) so this will come too with time. We want you to have your media your way. Believe me that will never change. We will just keep pushing forward toward that goal and never stop. It can always be faster. It can always be better. We just have to find ways to get there.