More control over subtitles #467
Conversation
- TTML is also supported. - Limits of support are better described. - Both online and local files are supported. - A web server is only started if a local file needs to be served.
Not tested with other platforms. Only disabling subtitles is compatible with the YouTube controller
If an URL is specified, the MIME type is read directly from the HTML response, not guessed from the file termination. With this, we can use URLs that do not end with .srt, .ttml or .vtt (e.g. URLs with subtitles in YouTube). To allow this, the file extension is only checked if the file is local.
catt/subs_info.py
Outdated
| self.local_subs will be True; CATT will detect this and start a web | ||
| server so that ChromeCast can fetch it. Only devices in the same network | ||
| can access this file. | ||
| local_ip and port params are used for this purpose. |
There was a problem hiding this comment.
Is this forgotten from the previous docstring?
There was a problem hiding this comment.
I'm sorry I'm late. The answer's yes and no.
self.local_subs is still used, but now it's not directly provided by self._read_subs(). instead, self._read_subs() provides a MIME type only if the subtitles file was originally remote, AND the script uses the existence of the MIME type to infer if the file was remote or not.
This behaviour isn't documented anywhere, though, so I'll update the docstring right away.
EDIT: Done! But I might have overexplained it. Is there anything you want to change?
Also adding an annotation to the url() method
|
This looks good to me, thank you! Have you tested it, and does it work well? |
yt-dlp cannot always retrieve a name and an extension for a subtitles files. In these cases, the keys 'ext' and 'name' do not exist, and CATT failed. Example page: https://iandevlin.github.io/mdn/video-player-with-captions/
|
Not enough, as it turns out! I had tested it several times in:
but your question reminded me that I hadn't tried it in a random website besides those. I looked for any webpage I didn't already know, and found a test page referenced in the Mozilla docs.
|
2 participants
Hello again! These commits add some conveniences to toggle subtitles:
Allow the use of TTML subtitles
Because why not? Even my 1st-gen ChromeCast supports them... partially.
Like VTT; only positioning, bold, italics and underline are honoured. Unlike VTT, some HTML codes cause the receiver to stop interpreting subtitles at all.
Automatically find subtitles on YouTube (default app only)
When using the
catt cast -f URL(catt cast --force-default URL) command, all available subtitles are automatically found, and the best options (VTT > TTML > SRT) sent to the ChromeCast through the pychromecast parametermedia_info.yt-dlpis compatible with.-sof--subtitles, only that subtitle file is loaded. This is the undocumented behaviour of the pychromecast module when both argumentssubtitlesandmedia_infoare used, and I didn't find it prudent to work around this for now.Add a new menu to toggle subtitles on and off
The menu is quite basic, and TRACK_ID is always a number:
These work for the default app. The YouTube app uses a different controller, and I couldn't find the relevant documentation, so only
catt subs --offis compatible with it.MIME type is only guessed for local files
Subtitle files in web servers are already served with MIME types, so we just read the MIME type from the HTTP response. This way, we don't need to check the URL, and we can use URLs that don't end with .srt, .vtt or .ttml (like YouTube's URLs)
What I couldn't do
yt-dlpdoes not attempt to retrieve them