Daiz

Yes, I know the format supports it. The question is, will hardware decoders built primarily around video use cases? And if those kind of hardware decoders end up forming the majority of hardware decoders for AVIF, will we end up in a future where using the full range of the format is heavily discouraged because it won't be supported by hardware decoders?

For comparison, it was possible to do 10-bit video with H.264, but 10-bit video didn't see any mainstream adoption with it because hardware decoders generally didn't support 10-bit H.264 video. Only when newer formats came around and specced 10-bit support as a baseline necessity did we start to see wider adoption for it. And well, the baseline specs (main profile) for AV1, which AVIF is based on, are limited to 4:2:0...

A potentially major issue I have with AVIF is that because it is based on a video format, any hardware decoding support AVIF will get is likely to be restrained to common video scenarios. This can result in eg. only 4:2:0 YUV being supported by hardware decoders, as that's the upper limit of AV1 Main Profile (and thus the limit of AVIF Baseline Profile). And 4:2:0 is just a poor fit for certain categories of images (like various kinds of illustrations, screenshots, etc). I would not be very happy about a web where lossy 4:4:4 image compression would be heavily discouraged with modern formats.

Also, good lossless compression absolutely does matter for the web as well. Lossy images just cannot be used in all circumstances - like when comparing compression quality (especially of videos), for example!

EDIT: To give an additional example, pixel art is an entire field of art (which is very much still active today) where both lossless compression is a must and where 4:2:0 would be absolutely catastrophic for quality.

Having your own font is nice and all, but I wish Nebula would spend at least as much time on their subtitle rendering as they've spent on this marketing site... The subtitle rendering on Nebula is worse than what Youtube offers, and Youtube isn't exactly some pinnacle of subtitle rendering either. I'd really expect better from a premium service.

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.

Good catch, thanks - I literally built the site alongside the article, so there's still some rough edges here and there.

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.

Both services explicitly disallow this by default in their delivery specifications, unfortunately.

Netflix: https://partnerhelp.netflixstudios.com/hc/en-us/articles/215...

> 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.

Amazon: https://videocentral.amazon.com/support/delivery-experience/...

> 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.

See for yourself: https://partnerhelp.netflixstudios.com/hc/en-us/articles/215...

> 4. Line Treatment

> 2 lines maximum

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.

Lack of closed captions and dubtitles are definitely very real issues as well, though this article is solely focused on subtitles.

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 linked article here goes over all of that in great detail!

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.

[1] https://www.vapoursynth.com/

Lossless compression means the pixels of the output image are 100% identical to that of the output image.

This site is clearly not doing that, and should thus not be called "lossless compression". The industry term for lossy compression that appears to be basically the same as the source is "visually transparent" or just "transparent". Though this doesn't seem like that either, especially when you're compressing large PNGs into JPGs while naming the output as PNGs. That's just outright deceitful, and not a good look.

As someone who's done made use of most of the techniques listed in these posts, some comments...

First of all, it's nice to see them receive attention outside the fansubbing scene! Anime has long made use of on-screen text in ways that most other mediums don't, and with the limited animation the medium is famous for, it tends to be extremely amenable to localization that aims to replicate that on-screen text presentation as closely as possible. With fansubbing, this is largely due to the power of the ASS (Advanced SubStation Alpha) subtitle format, and the Aegisub editor's capabilities for making use of that power (none of which is a coincidence - ASS was effectively developed for subtitling anime, and the same goes for Aegisub). Of special note is Aegisub's Automation features, which allow users to write Lua scripts to extend its capabilities, even building various extra GUI bits and bobs to make them usable for any non-coders.

To comment on one of the techniques in particular: it's always kind of fun to see people be impressed by masking, because technically speaking it's one of the more simple tricks that people do with ASS. The format includes basic vector drawing capabilities, which can be used to also make clipping masks for subtitles. How masking works is that usually the typesetter will be simply drawing vector clipping masks to clip the subtitles properly, frame-by-frame. Due to the limited animation, this usually doesn't take all that long. If the covering object remains static in shape, you could also just draw the mask once and then use motion tracking and an automation script to move it for the duration of the masked line. So all in all, not very complex, just a bunch of manual effort :)

And speaking of which: one of the biggest innovations of anime fansubbing happened around 2011-2012, when fansub groups started making use of motion tracking en masse. The popular program for doing the actual motion tracking was Mocha[1], and then various tools were used to apply its After Effects -compatible motion tracking data to typesetting lines in Aegisub. This development eventually culminated in Aegisub-Motion[2], which has been the de-facto motion tracking script for Aegisub for quite a while.

Motion tracking is also the main thing still lacking when it comes to typesetting in official anime releases today. This mostly comes down to the fact that while fansubs can have fancy motion tracked typesetting completely softsubbed since they expect their releases to be watched on reasonably powerful PCs, the same doesn't really apply to the much more limited and less powerful subtitle render used by official services. But honestly speaking? That's mostly just an excuse for the official services to not even try. You could have the fanciest on-screen text presentation in the world if you just burned your on-screen text translations into the video (hardsubbing, as opposed to softsubbing). Yes, this approach would work just fine even for multiple languages - modern video streaming is already based on short segmented chunks, so all you'd need to do is develop a system that will make multiple hardsubbed variants of only the segments where on-screen text is actually present. With this, for the vast majority of video, you would only need one variant. I developed the bones of a system like this myself for some official anime streaming I worked on some years back (unfortunately no longer available), and it very much was extremely feasible. This kind of segmented hardsubbing is even possible on Blu-ray, so the technique is disc-feasible too.

In conclusion, I completely, 100%, concur that I'd love to see a lot of these techniques be used with official anime releases. Especially since it would be very much possible to apply just about all of them as long as a publisher was simply motivated enough to make it happen.

[1] https://borisfx.com/products/mocha-pro/

[2] https://github.com/TypesettingTools/Aegisub-Motion

As someone who has built custom EPUB authoring scripts in Node.js for work and also quite likes the EPUB spec: cool! I expect I'll still keep using said scripts for work, but I have some side project ideas which would involve actually reading EPUB files too - I'll probably give this a spin for those.

Extremely welcome legislation, especially since it has an exception for "permanent download that can be accessed offline", ie. DRM-free downloads. It's about time someone actually calls out Big Media on their deceptive practices. As I've been saying for years, it's not "buying" with DRM-encumbered media, merely "renting for an undefined time period".

In fact, it'd be even nicer if the legislation explicitly required rental terminology to be used for anything DRM-encumbered, but well, even as-is, this is an extremely welcome development and I hope legislators worldwide are taking note and plan to follow suit as soon as possible. This kind of victory for digital consumer rights has been long overdue!

I've yet to meet a single developer who likes what Apple did with 100vh. And it's why all my projects to date that want to use viewport height in CSS have ended up adding a JS snippet that sets a --vh CSS variable to window.innerHeight on resize, because I have no interest in dealing with Apple's special boy CSS behavior. And really, even Apple itself admits that their 100vh solution is troublesome - they wouldn't have introduced all these new units otherwise! Even if the saner solution would have been to just change their idiosyncratic 100vh behavior to what developers actually expect from it.

Gotta say, really disappointed with the fact that instead of Safari making 100vh actually mean 100% of viewport height like it's supposed to, they instead present us with all these new viewport units, all to fix a problem that was caused by their own deviation from the spec to begin with. And of course they're not going to do anything about 100vh even with all these new units, because how else are we going to force developers to use our special units to cater to our browser's quirks!

I did see the beta calendar. It's a start for sure, but most back catalog titles still have zero information in terms of when to expect new chapters for them, so there is definitely still work to be done in that regard. And on the calendar itself: entries should ideally be grouped by day. Multiple entries for the same title on the same day should get grouped to one entry (so eg. "Again!! c74-76" rather than "Again!! c74" "Again!! c75" "Again!! c76"). And this one's especially important: if a user is logged in, the calendar should highlight titles in My List by default, and you should also be able to filter the calendar to only show My List titles. For an external reference, I can recommend taking a look at J-Novel Club's release calendar, as it covers basically all of these points and then some: https://j-novel.club/calendar

On the subject of apps, I'm not saying you shouldn't have apps, I'm just saying that there are certain things you should share across the web and apps, like the reader. Basically, you could have the reader running in a web view inside the mobile apps, and this way you could have just one reader codebase that gets reused across all the platforms. You could take this even further and build your mobile apps with web tech inside web views as well. You probably wouldn't do that at this point, but I would still recommend looking into using the reader in a web view at least, as that's no doubt the most complex frontend component in the entire system.