You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
NTSC closed caption data overlaps the first line of the active region, so it's visible (and distracting) in the output:
If valid CC is detected in the video, ld-chroma-decoder should blank the first line, and ld-dropout-correct should ignore the first line, both for fixing dropouts and as a source of replacements.
I think the easiest way to do this would be to adjust the first line of the active region, checking that this doesn't change the output padding for ld-chroma-decoder. Currently the active range is hardcoded in all the tools that need to know it...
The text was updated successfully, but these errors were encountered:
Technically speaking; it's a deliberate feature of the closed caption system; it's placed in a visible line since it means any system/processing in between the viewer's closed caption decoder and the source should never remove it. I imagine a number of PC based players can generate subtitles based on it, although I've not checked. I guess the active region could be provided by ld-decode into the metadata; and the tools changed to use it instead of the hard-coded values.
My first thought is you can simply crop it out with ffmpeg or other tools if needed, but it's a fair point that it should be excluded from DOC stuff.
I'm not sure if any PC-based players can actually decode it at present. I think VLC includes libzvbi for decoding, but it only works when viewing from a capture card as it expects fields rather than frames, and only looks on line 21 of each field. Other players I've found that support CC require it attached in pre-decoded text form as metadata.
The other reason for excluding it early is that you don't want ld-chroma-decoder's 2D/3D filters seeing it (since it would affect the decoded colour on the surrounding lines).
NTSC closed caption data overlaps the first line of the active region, so it's visible (and distracting) in the output:
If valid CC is detected in the video, ld-chroma-decoder should blank the first line, and ld-dropout-correct should ignore the first line, both for fixing dropouts and as a source of replacements.
I think the easiest way to do this would be to adjust the first line of the active region, checking that this doesn't change the output padding for ld-chroma-decoder. Currently the active range is hardcoded in all the tools that need to know it...
The text was updated successfully, but these errors were encountered: