Closed dericed closed 1 month ago
However in the dvrescue srt output the screen/buffer are not cleared, so it appears as if text is being overwritten rather than cleared and redrawn.
Right, there is an issue in the roll-up, I am fixing it, but I notice that FFmpeg doesn't do the roll-up, it erases the entire buffer and show the next line in full (with home made in and out timestamps?), is it expected? On my side I mimic a 608 decoder with a paint on style (no back buffer storage before poping the full line + 2 roll-up lines) in order to have a "lossless" conversion as seen by a old fashion TV, that leads to something like:
>> "ARKANSAS WEEK" IS MADE
POSSIBLE IN PART BY THE
POSSIBLE IN PART BY THE
POSSIBLE IN PART BY THE
AR
In practice I am afraid about the SRT player behavior due to the missing 2nd line after a 608 carriage return command, maybe it will center the 2nd caption, to be checked. Maybe it would be good to always keep the roll-up lines, so a line with a fake character.
Also, is this behavior of my decoder good or not?
This image depicts an srt from dvrescue and an srt made by ffmpeg doing a scc->srt conversion (then I removed the formatting). This video side by side shows dvrescue on the left and uses the time range of 00:54 to 2:54 of the srts.
https://github.com/mipops/dvrescue/assets/762604/f0b38376-9e89-4191-8dd9-402e70baaabf
scc from dvrescue https://gist.github.com/dericed/a93ed9ccd3d094d86266e231e230c6e4 srt from dvrescue https://gist.github.com/dericed/c1def2cba8448f1fd5d32b75e865cab2 srt from ffmpeg using scc->srt https://gist.github.com/dericed/7114ee7455368a76a1628fc3143232c4
The scc makes frequent use of code
9425
which per http://www.theneitherworld.com/mcpoodle/SCC_TOOLS/DOCS/CC_CODES.HTMLHowever in the dvrescue srt output the screen/buffer are not cleared, so it appears as if text is being overwritten rather than cleared and redrawn.