Opened 13 years ago

Last modified 13 years ago

#1870 new defect

Negative subdelay parameter useless on mkv files

Reported by: lorefice2@… Owned by: reimar
Priority: normal Component: demuxer
Version: unspecified Severity: normal
Keywords: Cc:
Blocked By: Blocking:
Reproduced by developer: no Analyzed by developer: no

Description

mplayer version: MPlayer SVN-r32792
Os: Linux 2.6 32bit

Bug:
when using a negative parameter for subdelay option on an mkv file which embed the subtitle, some subtitles are not displayed

To reproduce:

--

  • Try the same with avifile.avi
  • see that subtitles are displayed

So an external subtitle works, while if muxed in an mkv file, it doesnt.

  • Note that if you load an external sub for an mkv file, it works too.
  • Note that even z and x hotkeys (realtime subdelay changes) give the same issue.

Side note:
It seems to me that only the start time is shifted.
As a result, subtitle lines with duration lower than the absolute value of the subdelay parameter aren't displayed.

Attachments (1)

subtest.tar.gz (704.4 KB ) - added by lorefice2@… 13 years ago.
Mkv with embedded sub + avi file with external sub

Download all attachments as: .zip

Change History (4)

by lorefice2@…, 13 years ago

Attachment: subtest.tar.gz added

Mkv with embedded sub + avi file with external sub

comment:1 by reimar, 13 years ago

The problem is that this is not nicely fixable without introducing other issues.
The underlying problem is that MPlayer reads the data in the file in the order it is stored on disk for efficiency.
That means that it will get the data for the subtitle to be displayed only shortly before the corresponding video frame.
MPlayer can't display the subtitle before it has its data, thus it will end up displaying nothing.
As a workaround, two things should work:
1) instead of "mplayer file.mkv" use "mplayer file.mkv -subfile file.mkv"
2) try below patch
Index: mpcommon.c
===================================================================
--- mpcommon.c (revision 32865)
+++ mpcommon.c (working copy)
@@ -191,6 +191,7 @@

if (teletext_control(NULL, TV_VBI_CONTROL_START, &ptr) == VBI_CONTROL_TRUE)

d_dvdsub->demuxer->teletext = ptr;

}

+ d_dvdsub->non_interleaved = 1;

if (d_dvdsub->non_interleaved)

ds_get_next_pts(d_dvdsub);

while (1) {

comment:2 by lorefice2@…, 13 years ago

Both methods worked fine, thanks for your suggestion.

Back to the issue, i made a mistake when i wrote:

It seems to me that only the start time is shifted.

Instead, the start time remains the same, while the end time is shifted (back).

MPlayer can't display the subtitle before it has its data,
thus it will end up displaying nothing.

I dont think this is 100% correct,
As you said, mplayer can't "predict" when the next subtitle will have to be shown, still it will display it ignoring the negative delay for the start time, but will shift the end, leading to a negative duration and so displaying none.

In fact, the attached file shows a countdown from 60 to 0 and subtitles are in sync with the video, every subtitle line has a duration of 0.5 seconds.
If you try:
mplayer subtest.mkv -subdelay 0.4
...you will see every subtitle for 0.1 seconds.
mplayer subtest.mkv -subdelay 0.3 shows them for 0.2 seconds and so on.

Anyway, i understood your point about the efficiency; avoiding disk seeks (not to mention network streams) is good, but consider that the kernel buffer cache will probably make the data available to mplayer avoiding any seek for higher 'cache','cache-min' and 'cache-min-seek' values, and still will smooth it if mplayer cache is not used at all.

So in the end i'd prefer more seeks to unsynced subtitles, will it be possible to integrate the patch you wrote for mkv (and similar) files?

comment:3 by lorefice2@…, 13 years ago

(In reply to comment #2)

Both methods worked fine, thanks for your suggestion.

Mmh, both methods doesn't work with -ass switch anyway, any toughts?

Note: See TracTickets for help on using tickets.