Opened 8 months ago
Last modified 8 months ago
#10927 open defect
Converting EIA-608 to ASS can have multiple \pos tags
Reported by: | SuperrSonic | Owned by: | Marth64 |
---|---|---|---|
Priority: | normal | Component: | avcodec |
Version: | unspecified | Keywords: | |
Cc: | Blocked By: | ||
Blocking: | Reproduced by developer: | yes | |
Analyzed by developer: | yes |
Description
Summary of the bug:
As described here: https://github.com/libass/libass/issues/738
libass rendering doesn't allow more than 1 \pos per line/event.
At the end I include a command line tool that can split the \N on each line to a new dialogue event line, this allows the extra \pos tags to be used, producing an accurate look to the TV's CC decoder.
I could try modifying ffmpeg but I wanted to find out if there's a better way to fix this, or a reason why this shouldn't be done.
The code here seems to be what adds the \N it's always followed by a \pos,
so replacing this code to make it into a new dialogue event should be enough to fix it. How to do that, I am still not sure.
https://github.com/FFmpeg/FFmpeg/blob/master/libavcodec/ccaption_dec.c#L601
How to reproduce:
% ffmpeg -f lavfi -i movie=video.m2v[out0+subcc] -map 0:s -c:s ass video_cc.ass ffmpeg version N-113881-gf7545e90df-20240301
I've been ripping a lot of my collection to contain these captions, but the tools I've used, like makemkv remove the original caption data, so I don't have any samples right now.
Change History (2)
comment:2 by , 8 months ago
Analyzed by developer: | set |
---|---|
Owner: | set to |
Priority: | wish → normal |
Reproduced by developer: | set |
Status: | new → open |
There is a patch up for this already in the review phase. It will not fix all of your positioning problems but at least it will stop producing invalid ASS with this patch. Unfortunately though, if the patch is merged, it will only print the first position tag. This may break your workflow, I will think a little bit more about this.
It is not as simple as just splitting it into individual dialogue lines because of how the decoder works (this will break justification and cause other oddities). But I am slowly working on it.
Also, ffmpeg's new DVD demuxer retains the CC data