>> as well as ATSC subtitles > > There are like 2 or 3 characters in each frame. Sometimes > they are shown as they are coming in, sometimes only > when a line is completed, sometimes needs to wait > for subsequent frames before emitting new characters. > This is really not a high-precision thing.
Can confirm. I did implemented this using video filters, precisely because we don't have subtitle filters and I was forced to do OCR. It works OK, but it's unrealiable when speaking about timings. You have 2 bytes/chars per frame, non-ascii chars use 2 bytes, and there are also commands that also use one or two bytes. This leaves you with a max speed of 60 chars per second for a 30 FPS video stream: a condition no other subtitle/caption format that I know of share. When there's fast dialogue, it desyncs. It later re-syncs: it doesn't drift away. But dialogue faster than 60 chars (including non-ascii and command) per second does affect the captions timings. But there's more. Implementations in players are chaotic, and some commands are ignored or works erratically. Also, there are line width issues: 30 chars max by the standard, even when some players change that. But you have to deal with word wrapping by doing text treatment and applying commands. Then there's 4 modes of rendering, as you say, which you are supposed to control but then players do what they want, and given that this are bytes added to the video frames you gotta encode two different video streams if you want to have two different caption configurations. It may be the most available format in the world. But it's also a PITA because a lot of details, and that's why I'm so interested in finally having subtitles in filters first, and dealing with the internal details later. _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".