Embedded CC Support

[brabebhin]

@lukasf Let's discuss about embedded CC support here.

1) At first glance it looks that indeed TimedMetadataStreamDescriptor looks a little bleak. Maybe there is still a SDK update to come.

2) The pull model can still work, probably we need to provide mock frame when there are no subtitles available.

3) As for a push model, maybe we can extract timed text from the file and feed it into existing, working API, such as TimedMetadataTrack.

[brabebhin]

I mean addCue gets called several times before the event handler.

[brabebhin]

Or add the pending cues from the AddCue method if there are too many pilling up.

[lukasf]

I am still not sure if we really understand the problem. Maybe adding some more debug output would allow us to find out what is going on. Do you think you can share the file?

One other way to approach this would perhaps be to read a more frames ahead. I guess we run into this problem when cues only appear very close to playback position. If we would read more packets ahead (filling up a/v buffers a bit more), we would have more time to add cues. It should at least reduce chances of this problem appearing.

[brabebhin]

The file is pretty big. Do you know of a tool which would probably preserve the metadata tracks and not convert them to image overlays?

[lukasf]

You can use ffmpeg.exe to extract only the subtitle stream, like this: ffmpeg -i Movie.mkv -map 0:s:0 subs.srt This would extract the first subtitle stream, second would be 0:s:1 and so on.

You only need to upload the subtitle file, I can mux it into a movie and test it.

[brabebhin]

subs.txt

Rename to .srt

[lukasf]

Ok I will try it. Do you have a position where the problem can be reproduced? Without the real audio, it is hard to know if a sub is missing ;)

[brabebhin]

I apologize. It seems to have been a windows insider preview thingy. After today's update, I no longer have the issue. And it also seems the flickering is gone too. The cues now all show up.

Regarding the flickering, I modified the duration of one of the text cues from that file to last 10 minutes and observed its behavior while others appeared and disappeared and could not notice any flicker.

Perhaps we should move on to either the snapshot bug or the image based subs.

[lukasf]

Oh ok, that's good news. I watched a few movies with subs and did not notice a single drop. Good to hear that in vNext the flicker is gone. Then we can disable that workaround when running on the latest Windows version.

[brabebhin]

At least 1 more person should confirm that it is gone, just to be sure.

[lukasf]

Yes. Maybe we should even wait until the official release and verify with that version, before disabling the workaround.

[lukasf]

At least I will wait for official relase before upgrading, so I cannot verify now. I don't like installing insider builds on my machine, had too many problems with that in the past...

[brabebhin]

The RTM should come soon enough, so it won't take too long. They seem to have fixed some DPI scaling and other visual bugs, probably indirectly took care of the flicker as well (as far as I know, we are the only project doing this demux of embedded subtitles, so it is unlikely they targeted our problem specifically)

[touseefbsb]

ironically I am also on insider build :P

[brabebhin]

Can you confirm the flickering is gone?

[lukasf]

You'd need to comment out the anti-flicker code to verify this (comment lines 184-204 in SubtitlesProvider.h).

[lukasf]

On the bitmap-subtitles branch, I added a config option "UseAntiFlickerForSubtitles". It defaults to "true", but you can disable this to test if flicker still occurs on Windows 1803. If flicker is really gone on 1803, we can dynamically initialize the default value, based on current Windows version.

[brabebhin]

I am closing this, we no longer need this thread and it has gotten too big already.

See #33