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.
Thanks!
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.
Updates
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/cachecalledtranscoder.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
