[FernetMenta]

Mediainfo is no reliable tool for this. It may show entries for CC which are actually not there. Did you have any other indication that there should be an additional track?

[emveepee]

Yes ccextractor a great cc tools shows the 708 debug instructions http://pastebin.com/NPBy9xvH

here is the 608 debug http://pastebin.com/uBytGirN

Martin

[FernetMenta]

Sorry, I made myself not clear enough. The samples I got so far have not an additional language on the 608 track. Means if 708 service 1 in e.g. English, the 608 track is English too.
In your case I see French as the only language.
Means as soon as there is 708, decoding of an additional 608 track is no benefit.

[emveepee]

I see know what you mean, yes if you can properly decode the french character stream from the 708 data, there does not appear to be a need for the 608 data.

Martin

[allan87]

Hi FernetMenta. One more sample in https://drive.google.com/folderview?id=0...sp=sharing - 1023_20141226120000

It supposedly has a CEA-708 and a CEA-608 stream, but no CCs are detected by Kodi.

The channel that this sample is from is the only English-language programming I get that continues to have issues,

I have checked non-English programming as well (where I don't see captions), but my TV also does not show captions in those cases.

[FernetMenta]

Why do you think this sample is supposed to have 708 cc? I tried with ccextracor and mediainfo shows no 708 either. All I get get out of this sample is 608.

[allan87]

I also checked with mediainfo, which did show 708. Odd. Maybe it has something to do with this: "ATSC broadcasts instead use the EIA-708 caption protocol to encapsulate both the EIA-608 caption pairs as well as a native EIA-708 stream." http://en.wikipedia.org/wiki/EIA-608

Anyway, this issue appears to be an aberration affecting only one station (AntennaTV) and I suspect that 708 will become universal in due course.

[ironic_monkey]

https://lists.ffmpeg.org/pipermail/ffmpe...67225.html

@FernetMenta in case you missed it.

[allan87]

This is working pretty great. Thanks for this important improvement.

Before you close the book on this, can you please think about this issue with scrolling captions? New lines are centre aligned and render from the centre of the screen in both directions. Accordingly, the words are always moving, which makes them harder to read. Also, scrolling captions don't render fast enough when there is lots of talking, and fall behind the audio.

The readability issue would be alleviated by either left alignment or rendering the text line by line. I wonder if rendering the text line by line would would help the captions keep up with the audio.

Also, are you interested in assessing whether the setting in videoubtitles is necessary. I can tell you that, in my view, it is not necessary on the Pi. Although some recordings will stutter a bit when using captions, the stuttering stops when captions are disabled in the OSD. The videoubtitles setting is on all the time. I don't know about other low-power platforms, but the Pi is not an issue.

[FernetMenta]

Aligning simple text subtitles is not that easy because what should be x position? At least for 708 we would have the window size for the subtitles but we can't transport this information into renderer without changing lot of code. As already mentioned, the best way to cope with this would be to transform those into ASS format. Then it would be also possible to keep up to 15 separate windows which are defined by the 708 standard.

Also, are you interested in assessing whether the setting in videoubtitles is necessary

Let's see. There is plenty of time until 15.0 will be released.

[FernetMenta]

https://lists.ffmpeg.org/pipermail/ffmpe...67225.html

@FernetMenta in case you missed it.

thanks, I did not know. Unfortunately this does not include 708 as far as I can see.

[allan87]

Aligning simple text subtitles is not that easy because what should be x position?

Sorry if this is a stupid question, but can't x be, for instance, 10% of the screen from the left margin?

The text box would not be centred, but that's pretty much what my TV does with roll-up captions anyway.

[FernetMenta]

In software there is hardly anything which is not possible but from a design perspective this makes no sense. You would need at least half the effort of doing it right. Why torturing the environment by building new roads for an outdated vehicle instead of updating the vehicle to use existing infrastructure?
We have a decoder for SSA subtitles. The job is to transform simple text like:
"this is some text"
into
Dialogue: Marked=0,0:00:01.18,0:00:06.85,DefaultVCD, NTP,0000,0000,0000,,{\pos(400,570)}this is some text

This way you also get some features of 708 back which got lost by just taking the text out of the various windows.

[emveepee]

In software there is hardly anything which is not possible but from a design perspective this makes no sense. You would need at least half the effort of doing it right.

Once you get the 608 subtitles working, I want to try to help do the coding to move to basic SSA which is better than reinventing the wheel. I didn't want to start anything with this big piece missing and I want to make sure what I do can be adapted to both methods.

Martin

[allan87]

Thanks again to FernetMenta for developing this important feature.

For the reference of anyone who has the time and inclination to work on generating SSA captions, I will leave my samples online at
https://drive.google.com/folderview?id=0...sp=sharing