Testing Adaptive Bitrate Live TV Streaming (for improved viewing of remote TV)

Beta Community DVR Beta
#1

DVR Beta v2019.12.24.0128 has a new experimental feature for improving the experience of viewing Live TV while out of the house. This is bringing the Live TV experience to match the recorded streaming experience that we rolled out in September.

Why should I be interested in this?

If you watch Live TV when you are out of the house, the available bandwidth is often less than the bitrate of the content, and will sometimes increase and decrease depending on reception. Today the user is required to properly set the quality in Settings to be less than the available bitrate and adjust it if the situation changes.

What will be different if I use this?

Like the current behavior of streaming of recordings, this will result in a Live TV experience that has:

  • Less time spent changing quality settings
  • Less pausing and buffering
  • The highest quality available based on the available bandwidth

Who are we looking for to test this?

Anyone who uses iOS, tvOS or Android to watch Live TV remotely.

How do I try it out?

Make sure you are on the latest DVR beta and have installed the latest iOS, tvOS or Android app beta from getchannels.com/beta.

We do not have a beta process for the Fire TV so are unable to test it on it.

Once you have done that, enable Adaptive Streaming for Live TV in the Experimental settings section.

71145920-10661700-21d8-11ea-8cdf-2a90efd3f422
71145920-10661700-21d8-11ea-8cdf-2a90efd3f422.png1762×654 124 KB

Please let us know in this thread if you find any issues or strange behavior.

Known Issues

Like Adaptive Bitrate for recordings, the browser player is not supported for Live TV ABR.

1 Like
Adaptive transcoder is too aggressive in trying for higher bitrates
What are these Errors?
Testing the new Experimental Transcoder (for improved remote viewing of recorded content)
#2

Any idea when this feature will come to Fire devices? Very cool looking forward to using it if it's rolled out to fire devices next time I travel!

#3

Once we have more testing of the other clients we’ll do a Fire TV client release.

#4

I like this but if more than one user connects it can cause problems as the first user can take all the bandwidth ... I would like to see a setting at the server that would limit the amount of bandwidth a user can use. Say you have 6 mb up a limit to allow users to only use say 2 mb.

#5

I imagine you could use your router's QoS or traffic shaping settings to establish quotas based upon ports, connections, etc.

If you are relying on your home network to serve multiple remote streams, configuring your router with rules to adequately distribute and safeguard your bandwidth really should be on your agenda.

#6

Emby makes it simple you can allocate bandwidth per connection ... easy peasy.

#7

You can still specify the max bandwidth in the app under Streaming Quality

#8

Yes I know that but not everybody does this .....

Annotation%202019-12-24%20104734
Annotation 2019-12-24 104734.jpg1108×362 63.8 KB

#9

What you're describing is definitely outside the scope of this change, but it's interesting feedback on how to handle situations where the upload bandwidth of the server is the limiting factor.

1 Like
#10

I've noticed that television (via HDHomerun over the air) typically comes in somewhere between 10 and 18 megabits per second. In testing remotely on one the 2019-12-21 releases, I found that if the available bandwidth upload from the server is about 12 to 13 megabits per second, nearly matching the program bandwidth (in this case, live TV), that ffmpeg is only processing at about 8% and the media will skip and buffer quite a bit.

Using a more extreme condition, an imported media file at about 34 Mbps (an existing media file, not a live recording), that ffmpeg will compress it, using nearly 90% of the overall multicore CPU - it plays smoothly from the remote. This is with a Shield as the remote client, set for internet streaming. I haven't tested the 12/24 releases yet.

What is it exactly that determines if and when Channels DVR will encode the outgoing stream for the remote client?

#11

I see now, that addresses live vs. recorded.

I'll try the latest beta.

#12

Do the client side Beta versions work okay on MiBox? I see from older posts that Aman has one for testing purposes.

Is there a way to get access to the client beta downloads by using the common Channels DVR login info, or does it have to be some kind of gmail account?

#13

If you download the app via the Google Play store you can join the Android beta from getchannels.com/beta . Sign up with your Google Play login. It doesn’t need to match your Channels account email address.

#14

I see how that's tied together now. Thanks, Eric.

If I download the Beta server software by holding down the update button in the server settings, do the clients automatically know that they need to be using the latest Beta also?

#15

No, the client and server betas are separate.

There is a bug in the released client that only impacts Live TV Adaptive Bitrate that is fixed in the client betas.

#16

Because my clients (FireTV, Shield, MiBox) are set to update apps automatically, as soon as my Google account is flagged as a Channels DVR beta subscriber, it will know to autoupdate to the latest Beta?

Maybe a better question; how do I check on the clients mentioned above to verify that they are running a beta client version and not the original client?

#17

Check the About tab of the app to see what version is running

#18

The Shield claims that it's using Version 2.1.19.beta-v12232301. That unit is set to autoupdate it's apps. Is there something that needs to be done to force it up to the latest beta?

#19

That is the latest beta from 12/23 (ends in .beta-v1223)

#20

So if I update my Channels DVR Server to the latest beta, then I also need to make sure my AppleTV is also running the latest beta version of its app?