I would also be interested in this. Subtitle presentation is something where browsers are still generally very bad at out of the box, so having good subtitle rendering support built directly into the library would make a lot of sense to me. As someone with a lot of knowledge on this subject, I would be very much willing to help at least draft design documents for something like this, if not more.
Been using (and occasionally contributing to) Sharp for quite a while, both professionally and personally. Great library to have at hand when you need to deal with images.
I made some revisions to the start of the article in order to make things more clear to the layman unfamiliar with anime and subtitling. Hopefully that clears things up!
The key to good endnotes is to make them a nice bonus for those interested rather than required reading for everyone. Basically, make the main text work on its own, then get into the weeds of translation details separately. It's the best of both worlds, though admittedly requires quite a bit of extra work to pull off.
Well... the very first paragraph of the article does say with highlighting how "the presentation quality for translations of on-screen text has taken a total nosedive". And then it shows visual examples of the new bad quality and gives comparison screenshots demonstrating good quality shortly after.
Unfortunately, as the link describes, Netflix only makes this available for a very limited set of languages, while everyone else is stuck with the extremely limited text-based standards.
Frankly, those text-based subtitle standards are quite maddening on their own. Netflix's text-based subtitle rendering seems to support a much wider set of TTML features than what it actually allows subtitle providers to use - so if these restrictions were to be slightly relaxed, providers could start offering better subtitles for anime immediately with no additional effort from Netflix.
To be more specific, basically all online streaming today is based around the concept of segmented video (where the video is already split into regular X-second chunks). If you only hardsubbed the typesetting while keeping the dialogue softsubbed (which could then be offered in a simpler subtitle format where necessary), you would only need to have multiple copies of the segments that actually feature typesetting. Then you would just construct multiple playlists that use the correct segment variants, and you could make this work basically everywhere.
You can also use the same kind of segment-based playlist approach on Blu-ray if you wanted to, though theoretically you should be able to use the Blu-ray Picture-in-Picture feature to store the typesetting in a separate partially transparent video stream entirely that is then overlaid on top of the clean video during playback.
> CR could have used the ASS subs on their website and given the less-dynamic sub files to their vendors.
This is exactly what CR was doing for the past couple years, though you can't just automatically convert a fancy ASS file with typesetting into the limited kind of TTML subtitles that general streaming services expect, which is why Crunchyroll has been paying its subtitling staff extra to make those conversions semi-manually.
Though Crunchyroll could definitely improve its standard ASS workflows in ways that would make that conversion process significantly more automated with minimal extra effort on the subtitling staff's part. It wouldn't even be that hard, I've done something like that myself when I had to mangle ASS into limited WebVTT for some streaming work I did at one point.
This kind of softsubbing is what Crunchyroll primarily does, but it has hardsubbed encodes for devices that cannot do softsubbed rendering of the ASS subtitles that Crunchyroll uses. I go over some ways in how they could do away with these hardsubbed variants in the article without any notable loss in primary experience quality.
> Netflix requires a non-subtitled version of the content. Netflix defines “non-subtitled” as the presence of main titles, end credits, location call-outs, and other supportive/creative text, but no burned-in subtitled dialogue, regardless of the language in the primary video.
> Global packaging requires component asset packages to be delivered with a semi-textless video file that can be localized with discrete subtitles and audio dubbing.
> Also known as “Texted with no subtitles,” “Textless with main, ends, and graphic text,” and “Non-subtitled”, Prime Video defines semi-textless as a video master without burned-in subtitles, regardless of the language.
Quality typesetting is just as important for dubs as it is for subs, actually! All that on-screen text will be there regardless of which audio track you are using.
Crunchyroll is currently using a subtitle rendering stack that is highly unique in the media industry, being based on the Advanced SubStation Alpha (ASS) subtitle format. It seems that the current executives would like to replace this unique stack with something more "industry standard" (and far less capable), but they can't do that as long as their back catalog is full of ASS subtitles - if they just switched stacks without doing anything else, all of these back catalog subtitles would just stop working completely. Which is why in order to perform such a stack switch, all old subtitles would need to be replaced with worse ones to make them compatible with the less capable new stack.
I did find instances of them actively deleting old subtitles and replacing them with lower quality ones in the back catalog, yes. Which seems indicative of Crunchyroll wanting to eventually get rid of good subtitles altogether.
The cyan is basically just bold, but also a highlighter. I was using just plain bold initially but started experimenting with it and landed on this. Pairs quite nicely with the pink links, IMO.
This is the result of a ton of research into Crunchyroll's recent subtitle changes that have tanked the service's first-party presentation quality to an all-time low. The article ended up being quite long, so I highly appreciate anyone taking the time to read it in full!
If you're going to do script-based video processing in Python, I would highly recommend just going straight for Vapoursynth[1] instead. It's built for the purpose from the ground up, is actively maintained with a decent commmunity and tooling, and isn't tied to ffmpeg's CLI.