Testing the new Experimental Transcoder (for improved remote viewing of recorded content)

Beta release v2019.08.20.2353 has a new experimental transcoder that is ready for testing by people who watch content while out of the house. It is used when watching recorded content (not live TV).

Why would I care about transcoding?

When watching shows from outside of the house, many times the bandwidth available is less than the bitrate of the content that is being watched. To accommodate that, Channels can re-encode the content at a lower bitrate to send it to the client. Also, when watching OTA encodes from the browser, Channels must re-encode MPEG2 encodings to be playable in the browser.

What was wrong with the old way?

Over time we've seen some situations where seeking while viewing could cause:

  • Long delays to start playing again (sometimes so long that it felt like it had hung forever)
  • Pixelation or repeating video and audio while rewinding many times

What's great about the new way?

The biggest changes you should see when watching content from outside the house is:

  • No more pixelation or repeating video and audio when rewinding a bunch
  • Playback resuming faster after rewinding or fast-forwarding
  • Playback resuming much faster when coming back to watch a show or movie that had been partially watched previously

To aid in faster playback, we are now keeping the encoded segments around in a size-limited cache instead of deleting the transcoded content as soon as the player has stopped.

Who are we looking for to test this?

Anyone who watches recordings at a streaming quality lower than the original recordings bitrate (which is the case most often when streaming away from home).

How do I turn this on?

Make sure you are running the latest beta. You can update by long-pressing on the "Check for Updates" button.

Then scroll to the bottom of the dashboard and enable New Transcoder.

How much is being cached?

The new transcoder now caches up to 16GB of content. If there is anything cached, you will see a new Cache line in the Transcoder settings that will tell you how much is used. You will also be able to use the menu to remove the cache if you run into issues.

Please let us know how this works for you!

I have been testing this for the past few days and have had very positive results from it, but I would love to hear from people who regularly stream content from out of the house and hear if it makes any noticeable impact or if you run into any issues with it.



Appendix: Give me some technical details!

The new transcoder uses the same underlying ffmpeg encoder that we have always used but changes the way that we interact with ffmpeg. Previously, there were situations where an encoded HLS segment would have different audio and video frames from one encoding session to another. Because of this, we would delete the encoded segments at the end of each encoding session.

We have made changes to how we encode these HLS segments and now, with the aid of the Video Index we started generating a few weeks ago, make sure the segments have the same audio and video each time we encode them. Now that we have the segments being generated consistently, we are caching them across encoding sessions, so we aren't wasting CPU cycles to encode content again when you resume watching something again later.


iOS and tvOS beta build Version 2019 (9.8.100) has been posted:

  • IMPROVED: Adaptive streaming switches to a lower bitrate more quickly when connection has high packet loss

DVR beta build v2019.09.07.0705 has been posted:

  • NEW: Audio bitrate is adjusted based on video bitrate
  • IMPROVED: Audio bitrate is now taken into account in the bitrates advertised in the master.m3u8
  • FIXED: Streaming indexer could sometimes generate index with wrong (very large durations)

iOS and tvOS beta build Version 2019 (9.3.522) has been posted:

  • NEW: Adaptive streaming when experimental transcoder is enabled in DVR

DVR beta build v2019.09.03.0745 has been posted:

  • NEW: Provide new HTTP header to help client identify if clients are waiting on the server to encode segments
  • IMPROVED: Encoder restarting more than necessary when client is seeking

DVR beta build v2019.08.24.1834 has been posted:

  • FIXED: The DVR could sometimes fail to start any new transcodes after the new transcoder had stopped until the DVR was restarted
  • IMPROVED: Transcoder detailed logging has been moved out of the DVR log and into a recording-specific log in Streaming/cache called transcoder.log

DVR beta build v2019.08.21.1923 has been posted:

  • FIXED: Playing in-progress recordings with the New Transcoder would previously fail in the browser and could produce corrupted playback
  • IMPROVED: Spurious errors are no longer logged in DVR log when TVE streams are closed

Thanks, I understand transcode vs remux, but...

Does this apply to any in-home streaming for clients including web browsers with settings that would cause transcoding?

If only for out-of-home streaming, does it apply to all clients, including web browsers and what settings would trigger it to be used?

AND, how can we tell when it is being used vs. when it isn't.

1 Like

Is the cache only for hardware decoding? I don’t see it.

Yes, it will also apply for in-home streaming that uses transcoding. I'm updating the announcement to better reflect this.

It will be used for any out-of-home streaming that would cause transcoding to occur:

  • Any bitrate that is lower than the recorded content
  • Any OTA recording playing in the browser

With this setting active, if the Activity view in the dashboard says Streaming directly it is remuxing and if it otherwise is saying Transcoder Running it is using the new transcoder.

1 Like

You will only see the Cache setting once there is data in the cache.

Sorry to sound dense, but by Activity view in the dashboard, do you mean in the DVR web UI?

Or can you also see it in the playing client, including a browser.

I don't currently stream out-of-home, so not sure if I need to test anything here?
I use Firefox in-home streaming and iOS in-home occasionally.
Would be willing to help test, but sounds like this is aimed at issues with out-of-home streaming.

Also a bit confused by what this means
Previously, there were situations where an encoded HLS segment would have different audio and video frames from one encoding session to another. Because of this, we would delete the encoded segments at the end of each encoding session.

different audio and video frames = ?
encoding session = ?

It doesn't sound like you're going to see a lot of improvement for those cases, so I don't think you're our target audience for this feature. I appreciate your interest in helping out!

It's a technical description of the section above it for anyone on the site that was familiar with video encoding.

Yes, that Activity.

Yes, it will also show up in the browser player.

OK, sounds like you don't need in-home streaming testing, Thanks and will pass on it.

my server doesn't see hardware transcoding, its something that @tmm1 has looked at extensively even though it works on plex, videoredo and handbreak. my question was does this cache only appears if hardware transcoding is enabled? it doesnt appear for me since it only shows software transcoding. how does one get data in the cache? i streamed remotely for a while and nothing appeared. thanks.

Yes, this will cache software transcoding. Any time the new transcoder is used to watch recorded content it will be cached. If it’s not caching, my guess is the option isn’t enabled or it isn’t transcoding the content.

Definitely transcoding and definitely enabled but no cache.

trans1 trans2 trans3

Ah! I will clarify in the post that this is only relevant for watching recorded content and not live TV. Thanks for pointing out that oversight.

I am noticing VERY high CPU rates. When I had one remote streaming running I was at 40% system utilization. And with two streams it jumped to 60%. I have hardware acceleration selected and didn't expect this high of a load. Even with the 40% utilization my fan starts to kick in.

Hardware, 2019 Mac-Mini
6 cores / Intel(R) Core(TM) i5-8500B CPU @ 3.00GHz
load averages: 3.93 3.13 2.20

Apple Macmini8,1
10.14.6 (kernel: 18.7.0)

2019/08/21 14:12:07 [HLS] Starting transcoder for file5557-b0368327feee---3000-720-0--linear-false-false-1 at 0s from (encoder=h264_videotoolbox, resolution=720, deinterlacer=linear, bitrate=3000)

2019/08/21 14:10:43 [HLS] Starting transcoder for file5620-b0368327feee---3000-720-0--linear-false-false-1 at 29s from (encoder=h264_videotoolbox, resolution=720, deinterlacer=linear, bitrate=3000)

Can you compare the CPU utilization you see with the New Transcoder disabled? There shouldn't be anything with the new transcoder that would change the CPU utilization profile of encoding — it's using the same underlying ffmpeg for encoding.

I tried the same test with the New Transcoder Disabled. I am getting similar results.

However, with or without New Transcoder, when I watch Live TV Remotely the CPU utilization is way down. But Live TV is still transcoding.

Recorded TV - ffmpeg about 140%
Live TV - ffmpeg about 30%

Any reason for that?

The reason for the difference is that when you are watching Live TV you can only encode at 1x speed (because it only has as much video as is being broadcast). When you are watching recorded content the entire file is already saved, so the transcoder can encode faster than realtime (which will be why you could see 2x or 4x being shown in the Activity status for your DVR).

I do quite a bit of streaming to my iOS device over cellular and from my limited testing so far it seems to handle quick skips and manual changes to show position much more smoothly. If it's a placebo I'll still keep it :sunglasses:


@eric is there any priority to the cache, or is it simply first in first out (when hitting the 16GB limit)?