I think that is beyond my technical abilities. Since there are a lot of Pluto users here, I'm hoping the Devs know (or be able to quickly find out) the answer.
I browsed over to the Pluto site and looked at what they're using for closed captions. On the website they are being separately served as WebVTT files, and their web player then syncs them and displays them over the video. It looks like since they are coming from a separate source/location, and not part of the container holding the video and audio data, closed captions served that way are not making their way to Channels.
In short it looks like Channels can read the closed captions in WebVTT format; but it doesn't look like they are being sent. Or rather, the pluto-for-channels container does not present the subtitles in the playlist it generates.
1 Like
Thank you for your efforts in explaining this.
The playlist for the subtitles is actually in the m3u8 that pluto-for-channels generates:
#EXTM3U
#EXT-X-MEDIA:TYPE=SUBTITLES,GROUP-ID="subs",NAME="English",DEFAULT=NO,FORCED=NO,URI="subtitle/en/playlist.m3u8?terminate=false&embedPartner=&serverSideAds=true&paln=&includeExtendedEvents=false&architecture=&deviceId=8580488c-bb80-11ec-bcc3-f14d56112a64&deviceVersion=unknown&appVersion=unknown&deviceType=web&deviceMake=Chrome&sid=7ea3203e-b643-4741-b1e9-6b9e44563e14&advertisingId=&deviceLat=0&deviceLon=0&deviceDNT=0&deviceModel=web&userId=&appName=web",LANGUAGE="en"
#EXT-X-STREAM-INF:PROGRAM-ID=1,BANDWIDTH=997452,SUBTITLES="subs"
997452/playlist.m3u8?terminate=false&embedPartner=&serverSideAds=true&paln=&includeExtendedEvents=false&architecture=&deviceId=8580488c-bb80-11ec-bcc3-f14d56112a64&deviceVersion=unknown&appVersion=unknown&deviceType=web&deviceMake=Chrome&sid=7ea3203e-b643-4741-b1e9-6b9e44563e14&advertisingId=&deviceLat=0&deviceLon=0&deviceDNT=0&deviceModel=web&userId=&appName=web
#EXT-X-STREAM-INF:PROGRAM-ID=1,BANDWIDTH=1539795,SUBTITLES="subs"
1539795/playlist.m3u8?terminate=false&embedPartner=&serverSideAds=true&paln=&includeExtendedEvents=false&architecture=&deviceId=8580488c-bb80-11ec-bcc3-f14d56112a64&deviceVersion=unknown&appVersion=unknown&deviceType=web&deviceMake=Chrome&sid=7ea3203e-b643-4741-b1e9-6b9e44563e14&advertisingId=&deviceLat=0&deviceLon=0&deviceDNT=0&deviceModel=web&userId=&appName=web
#EXT-X-STREAM-INF:PROGRAM-ID=1,BANDWIDTH=2142297,SUBTITLES="subs"
2142297/playlist.m3u8?terminate=false&embedPartner=&serverSideAds=true&paln=&includeExtendedEvents=false&architecture=&deviceId=8580488c-bb80-11ec-bcc3-f14d56112a64&deviceVersion=unknown&appVersion=unknown&deviceType=web&deviceMake=Chrome&sid=7ea3203e-b643-4741-b1e9-6b9e44563e14&advertisingId=&deviceLat=0&deviceLon=0&deviceDNT=0&deviceModel=web&userId=&appName=web
#EXT-X-STREAM-INF:PROGRAM-ID=1,BANDWIDTH=3063648,SUBTITLES="subs"
3063648/playlist.m3u8?terminate=false&embedPartner=&serverSideAds=true&paln=&includeExtendedEvents=false&architecture=&deviceId=8580488c-bb80-11ec-bcc3-f14d56112a64&deviceVersion=unknown&appVersion=unknown&deviceType=web&deviceMake=Chrome&sid=7ea3203e-b643-4741-b1e9-6b9e44563e14&advertisingId=&deviceLat=0&deviceLon=0&deviceDNT=0&deviceModel=web&userId=&appName=web
#EXT-X-STREAM-INF:PROGRAM-ID=1,BANDWIDTH=572723,SUBTITLES="subs"
572723/playlist.m3u8?terminate=false&embedPartner=&serverSideAds=true&paln=&includeExtendedEvents=false&architecture=&deviceId=8580488c-bb80-11ec-bcc3-f14d56112a64&deviceVersion=unknown&appVersion=unknown&deviceType=web&deviceMake=Chrome&sid=7ea3203e-b643-4741-b1e9-6b9e44563e14&advertisingId=&deviceLat=0&deviceLon=0&deviceDNT=0&deviceModel=web&userId=&appName=web
This probably is an issue with how Channels parses the m3u8 playlists. Maybe it can't parse vtt files that are referenced in another playlist? @tmm1, do you think that is the correct assessment?
I can confirm that the issue is on the Channels side.
Here is the output of the Pluto TV "Showtime Selects" channel from the m3u8 generated by pluto-for-channels in the latest VLC nightly, which recognizes and outputs the VTT track:
Here is the same channel from the m3u8 output by Channels, which does not include the VTT track (http://X.X.X.X:8089/devices/ANY/channels/127/hls/master.m3u8?)
1 Like
Just bumping this because someone mentioned this issue today: Docker Hub not working, trying to add Pluto TV - #3 by TheFaizyJamalz
I know addressing this is probably a low priority, but could the devs acknowledge the issue? This isn't only a Pluto problem if the software cannot parse VTT playlists.
VTT captions are not currently supported.
I'm thinking of developing some middleware to transform the VTT captions into a format that Channels can parse. I don't know if it's possible, but I'd like to try. What live caption formats are supported by Channels?
Live streams only support embedded a53/cc
2 Likes
@fashioncents have you looked more closely in to your idea?
@tmm1 you used the word "currently". Does that mean there can be hope someday live streams may support VTT?
Would love to use Pluto but without subtitles I guess the other 500 channels I get will have to do. 
I did, but I haven’t had any luck finding a way to do it. Conceptually, I think it would take a stream, read the vtt playlist, and encode the text from that playlist into a new video stream. But I have not found any software that can embed captions in the standard format. I’m assuming that software like that is expensive industry software, but if anyone knows of a FOSS solution, please let me know.
Edit: So I did a little more Googling and found https://github.com/szatmary/libcaption. Going to take a look tomorrow and see what I can do with it.
Edit: I made some assumptions here that were wrong, as tmm1 points out below. Channels doesn’t use FFmpeg for HLS playback, nor do a lot of other projects.
————
I spent many hours in the last week trying to find solutions and every path I went down was a dead end.
From what information I have gathered, captions from Pluto do not work because FFmpeg, the library that Channels (and a lot of other video software) uses to handle multimedia does not support webvtt captions in HLS streams.
This issue has been known since at least 2013 and patches have been proposed but none have been accepted into the codebase.
The feature is supposedly behind an experimental flag, however, as lines 513-518 of this file show, the code to actually handle the webvtt stream does not exist.
To get on my soapbox a bit, I honestly find it unacceptable that the maintainers of FFmpeg have not made resolving this bug a priority. This is a library that is used by billions of people. HLS streams with WebVTT subtitles has become a de facto standard. I understand the resource limitations inherit to open source software projects, but projects like this have a social responsibility to make sure that their software works for the 430+ million deaf and hard-of-hearing people across the world, not to mention the countless neurodivergent people who depend on captions. I wish I understood how to fix the issue, but my technical acumen in this area is extremely limited.
@tmm1, I know this is an unlikely ask, but is it possible that patching the version of FFmpeg used in Channels with the code linked to in this GitHub comment would resolve the issue? I assume that you're already patching it for other things and that the effort might not make much financial sense. But I know a lot of people that use Channels would be greatly appreciative to get captions working from sources like Pluto and other live video streaming services.
First let me say that I use CC most all the time, and I am unable to watch certain programs because of lack of CC. I have been writing code since before you ever knew what code was.
People who write code and give it away for free, owe the world nothing! If giving away code came with rules and responsibilities, people would stop giving away code. They write code that suits their personal needs, and sometimes add in some extras for other people.
Given enough effort (a lot), you could learn how to do this, but you would rather tell others to do the work for you. You call this a "bug". It is not. A "bug" is an unintended result. There was no intention to ever make this work.
There is a simple way to fix this. Pay a qualified person to write the code. You could pay for it yourself, or get some of those 430 million people to kick in a few bucks appease.
There is no such thing as a free lunch.
2 Likes
Edit to add: I didn’t realize you were the OP of this thread. I spent hours trying to find a way to fix this issue for you and when I came back with my findings and advocated for you and others who are experiencing this issue, you decided to attack and insult me. Wow.
—
I'm not intending to start a flame war in the Channels community, so this will be my only reply to any criticism of my comment.
Starting off on a great foot here...
FFmpeg isn't just a small random hobby project. It is one of the most used FOSS projects in the world. Just look at their contributors list. They have engineers from Huawei, HBO, Kaltura, Twitch, Epic, Google, Vimeo, and other large companies contributing to the project.
When a project is used by that many companies for profit, then those companies have a social responsibility to ensure that that project is secure, well maintained, and accessible to people with disabilities.
I tried to find a way to solve it, but as I said above, my technical skills in this area are not adequate. So, I did what I am skilled in: research a technical issue, document what I've found, and publicly advocate that it be fixed for the sake of the disabled.
Don't get me wrong. I am very grateful and appreciative to people who write code for FOSS projects. It's a thankless job and my post was not intended to be a criticism at the work that they do. There are other ways to be a contributor, however, and one of those ways is to highlight areas where the project is failing. This is what security researchers do. How is what I did any different?
Except for the numerous tickets and proposed patches going back nearly a decade?
As far as I can tell, the code to fix it has been written. It just hasn't been accepted into the main codebase. I'd be more than happy to contribute money toward getting the issue resolved, but I don't see the point when there are already patches that the maintainers have not accepted.
Almost no one uses ffmpeg for hls playback. Even OSS projects like VLC and Kodi don't use ffmpeg's hls code.
We are also no longer using ffmpeg for hls playback, because it simply does not work well.
Most companies are using ffmpeg on the server, to generate hls for consumption by players built into the OS or browser. Generating vs consuming hls in ffmpeg takes completely different code paths.
Anyway, this is on our radar and something I would like to implement, but its not very easy.
1 Like
Thanks for providing more context. My knowledge in this area is pretty limited and I made some assumptions that I shouldn’t have. I’m sorry if I was out of line.
Is there anything that I and/or others can do to support getting this feature implemented?
I have a very basic implementation available for testing. It may be buggy.
You will need the DVR server prerelease and the latest beta of the Channels app. With this combination, you should see subtitles on Pluto channels where they are available. New recordings from these Pluto channels will also include the subtitle data.
I dunno if this is related to subtitle/cc update, but ever since I loaded 2022.08.02.0430 this morning, many of my Pluto channels are showing video that is slowing/pausing and then rapid catching up all the while the audio remains consistent. This is happening on AppleTV 4k beta (8.2.438) and stable (5.4.1). The CC looks mostly fine, but sometimes choppy. The main issue is the video disruption. Diagnostics have been sent from the AppleTV client and the server.
Edit/Update: Also happening on FireTV 4.3.0. Also happening on some Plex custom channels.
@Absenm Thanks, yes it was due to my changes. I reverted them in the next build, but I think have made some improvements now. With upcoming v2022.08.03.0007 subtitle support has been re-added and hopefully doesn't have the same video stuttering problems.
Please try it out and let me know how it works out for you.
I'm still seeing the stuttering issue on Android mobile on the latest server pre-release and beta app while watching Pluto TV. I submitted player diagnostics twice a few minutes ago: once on hardware video decoder, once on software (same issue both times).