Perenista
2nd June 2025, 00:48
https://www.youtube.com/watch?v=OSCOQ6vnLwU
There is a video explaining that "Closed captions on DVDs are getting left behind".
During that, the author mentions VLC, saying it display those from DVD (CC) wrong. Is that still the case?
Also, that comment explains something missing from it:
+++++++++++++++++
I'm a former chip architect for Set top box, DVD player, BluRay and DTV chips. Nobody forgot. The CC render is not implemented because the IP licensor for EIA captions demanded royalties which were far higher than the market would bear, and the requirement to use the official EIA font meant a 2nd license from the font licensor was also required. So it was decided not to include this tax on every unit sold since the captions were expected to be rendered on the subtitle channel.
+++++++++++++++++
Another user also pointed out:
+++++++++++++++++
FFmpeg maintainer here, and the details behind the caption decoding issues you're seeing in VLC are complex and horrific. They largely stem from how the EIA-608 caption format expects text to be laid out in a monospace grid onscreen, which isn't really how the text rendering stacks used for modern subtitling work (this is probably why changing the font caused problems on those Sony players); beyond that, the behavior can just end up pretty complex, and there's no convenient public-domain corpus of sample files for open-source software developers to test against.
These kinds of issues also affect the Japanese (ARIB) and European (Teletext) formats to varying extents. These days, a lot of the focus ends up being on converting the text into modern Unicode text formats, styled using modern techniques, so direct rendering of the legacy formats hasn't had as much attention lately. If anybody reading this has some badly-behaved samples and wants to contribute, patches to improve the decoding and rendering behavior are definitely welcome, though!
One small correction: at 1:49 and 14:53, you say the players are "decoding" the captions, which isn't quite right. The captioning data embedded in the MPEG-2 bitstream headers (or H.264 in some more recent contexts) is the exact same format found on line 21 of the NTSC TV signal, so the player doesn't actually have to decode anything!
It just takes the 16 bits of caption data for the current field of video, and modulates them into low (0, black) and high (1, white) signals on its analog output, without having to know anything about what those bits actually mean. (EDIT: reworded for clarity, since some people seemed to think I meant that the caption data was literally stored as a row of pixels in the video frames on the disk, which is not the case.)
+++++++++++++++++
There is a video explaining that "Closed captions on DVDs are getting left behind".
During that, the author mentions VLC, saying it display those from DVD (CC) wrong. Is that still the case?
Also, that comment explains something missing from it:
+++++++++++++++++
I'm a former chip architect for Set top box, DVD player, BluRay and DTV chips. Nobody forgot. The CC render is not implemented because the IP licensor for EIA captions demanded royalties which were far higher than the market would bear, and the requirement to use the official EIA font meant a 2nd license from the font licensor was also required. So it was decided not to include this tax on every unit sold since the captions were expected to be rendered on the subtitle channel.
+++++++++++++++++
Another user also pointed out:
+++++++++++++++++
FFmpeg maintainer here, and the details behind the caption decoding issues you're seeing in VLC are complex and horrific. They largely stem from how the EIA-608 caption format expects text to be laid out in a monospace grid onscreen, which isn't really how the text rendering stacks used for modern subtitling work (this is probably why changing the font caused problems on those Sony players); beyond that, the behavior can just end up pretty complex, and there's no convenient public-domain corpus of sample files for open-source software developers to test against.
These kinds of issues also affect the Japanese (ARIB) and European (Teletext) formats to varying extents. These days, a lot of the focus ends up being on converting the text into modern Unicode text formats, styled using modern techniques, so direct rendering of the legacy formats hasn't had as much attention lately. If anybody reading this has some badly-behaved samples and wants to contribute, patches to improve the decoding and rendering behavior are definitely welcome, though!
One small correction: at 1:49 and 14:53, you say the players are "decoding" the captions, which isn't quite right. The captioning data embedded in the MPEG-2 bitstream headers (or H.264 in some more recent contexts) is the exact same format found on line 21 of the NTSC TV signal, so the player doesn't actually have to decode anything!
It just takes the 16 bits of caption data for the current field of video, and modulates them into low (0, black) and high (1, white) signals on its analog output, without having to know anything about what those bits actually mean. (EDIT: reworded for clarity, since some people seemed to think I meant that the caption data was literally stored as a row of pixels in the video frames on the disk, which is not the case.)
+++++++++++++++++