--sub-delay shows weird behaviour

[bylee20]

When setting subtitle delay with --sub-delay option(or mpv_set_property function in libmpv), it delays only the time to display subtitle not rendering subtitle or end of subtitle. For instance, suppose that a subtitle caption must be displayed from 10sec to 20sec, and the color is changed at 15sec from blue to red. With --sub-delay=5 option, the subtitle will be displayed from 15sec to 20sec(not 25sec) and from start the caption is rendered red.(I'm not sure this timings are accurate, but it shows definitely wrong behviour.) Same problem occurs when mpv_set property is used. When setting the sub-delay property with 'set sub-delay ...' command, it works as expected. I have tested this issue with this sample: http://www.auby.no/files/video_tests/h264_720p_hp_5.1_3mbps_vorbis_styled_and_unstyled_subs_suzumiya.mkv

[ghost]

With --sub-delay=5 option, the subtitle will be displayed from 15sec to 20sec(not 25sec)

Probably because the player doesn't try to buffer ahead by the specified amount. Not sure how hard this would be to fix (on a scale from easy to hard, maybe medium), but it can be worked around by passing the mkv file as external subtitle to --sub. Then the player reads all subtitles when loading the file.

and from start the caption is rendered red.

How to reproduce?

When setting the sub-delay property with 'set sub-delay ...' command, it works as expected.

This shouldn't be different. Maybe the subtitle was already loaded. For text subtitles, the player caches subtitle events it has already seen.

[bylee20]

How to reproduce?

Try the linked file with --sub-delay=4, for instance. The styled subtitle is like a karaoke subtitle, and the color of text keeps changing. With --sub-delay=4, a half of displayed characters in first caption already have changed color when it displayed.

This shouldn't be different. Maybe the subtitle was already loaded. For text subtitles, the player caches subtitle events it has already seen.

I coudn' t find the cause, but actually they behave differently. When I set sub-delay with mpv_set_property, mp_property_sub_delay is called 3 times and when I try it with mpv_command("set sub-delay ..."), mp_property_sub_delay is called 5 times. Also, the arguments have different values by order.

[ghost]

With --sub-delay=4, a half of displayed characters in first caption already have changed color when it displayed.

I can't reproduce this.

When I set sub-delay with mpv_set_property, mp_property_sub_delay is called 3 times and when I try it with mpv_command("set sub-delay ..."), mp_property_sub_delay is called 5 times. Also, the arguments have different values by order.

Are you sure this isn't just because the set command calls show_property_osd? Anyway, I'm pretty sure it doesn't do anything magic here. It basically just sets the sub_delay option, and calls osd_changed_all(mpctx->osd); to redraw the OSD.

[bylee20]

I can't reproduce this.

Okay, my description was totally inaccurate, and I messed up start/end. I've tried more shots and here's new description: with --sub-delay option, the end of display seems right but the start of display is wrong. For instance, a subtitle from 5 to 10 with zero delay is displayed 5 to 6 with --sub-delay=4 and the subtitle is rendered so as to end at 6(not for starting at 5). So, if the color is changed 2sec before end of caption, when the delayed caption is displayed, it already shows changed color. Maybe this is what you've confirmed. Sorry for messing up.

Are you sure this isn't just because the set command calls show_property_osd?

I've checked the call stack, and yes, 3times of latter calls when using command was because of show_property_osd. Anyway, if the difference is only OSD related things, maybe there are some magic and this can be OSD-related problem.

[ghost]

Maybe this is what you've confirmed.

Yes.

Anyway, if the difference is only OSD related things, maybe there are some magic and this can be OSD-related problem.

Well, in theory it could happen that libass or something else messes up when rendering, but I find it unlikely. The behavior you described is most likely because the subtitle was already read, and then you seeked back and retried.

Not sure if I explained it properly why this happens. Every text subtitle you see is stored internally, and will be used when rendering something. So, even if the subtitle packet came too late (meaning the subtitle is rendered too late), when you seek back it will appear to be fine.

The main problem is that subtitles are read passively. You can see that in player/sub.c, where it calls demux_has_packet() to check whether there is a packet. If there's no packet, it doesn't try to read the subtitle. Subtitles are only read as a "by product" of reading audio and video. (Exception: the file contains only subtitles.) This is done because subtitles are relatively sparse compared to video and audio. If you would read subtitles actively, you'd quickly buffer up a lot of audio and video packets, just because demux.c will read and queue them when looking for a subtitle packet. A possible solution: read subtitle packets only until a maximum timestamp, and give up on trying to read more packets if audio or video packets go over the maximum timestamp.

[bylee20]

Doesn't the active reading of subtitle cause a delay of start of playback when sub-delay is large? In my experience, only extracting subtitle from mkv takes quite long time. If it can be related any problem of playback, I think giving up support of accurate sub-delay is better than making any other trouble.

[ghost]

Doesn't the active reading of subtitle cause a delay of start of playback when sub-delay is large?

Yes, you'd have to demux some data ahead, which may or may not be noticable. mpv in its current time, would read up to some hundreds of megabyte ahead (or some thousand packets, whichever comes first) if subtitle demuxing would be made active, so it would be rather crappy.

But maybe it wouldn't be so hard to implement it properly with a time limit, but I'm not sure. Also there's the question: is it worth the trouble? This issue comes up rather often, actually.

[bylee20]

If a subtitle has wrong sync timing, it's the problem of the subtitle file. Same thing can be stated for internal subtitle. The wrong timing problem should be fixed in the file. Player's subtitle delay function is just an option to provide some convinience and nothing should interfere or interrupt the normal playback. Therefore, I don't think it is worth the trouble, so I close this issue. Thank you!

[ghost]

I still might try to implement a solution for this, but yes, files with muxed subtitles that require manual subtitle adjustment are just broken, and there will always be caveats.