Opened 7 years ago

Last modified 6 years ago

#1853 new defect

duplicate entries when extracting DVD subtitles to VOBsub file with mencoder

Reported by: olivier.laurantin@… Owned by: reimar
Priority: normal Component: core
Version: unspecified Severity: normal
Keywords: Cc: Walter.MMM@…, olivier.laurantin@…, thedamocles@…
Blocked By: Blocking:
Reproduced by developer: Analyzed by developer:

Description

When I try to extract DVD subtitles to VOBsub files with the following command (for instance), it happens that some entries are duplicated in the resulting subtitles.idx file :

mencoder dvd://3 -vobsubout subtitles -vobsuboutindex 0 -sid 0 -o /dev/null -nosound -ovc frameno

It's not exactly duplicate entries, but two entries only separated in time by a few milliseconds, which obviously are unlikely to represent two real subtitle entries. The consequence of that bug is that corresponding subtitle won't be displayed by any video player.

For instance, the bug appears in the following sequence :
timestamp: 00:00:02:279, filepos: 000017800
timestamp: 00:00:04:759, filepos: 000018800
timestamp: 00:00:04:760, filepos: 000019000
timestamp: 00:00:07:639, filepos: 000019800

The second and third lines are what I call duplicate entries. While playing the video, we won't see any of those subtitles (which are one actually).
The complete subtitles.idx and subtitles.sub files are attached to this report.

I encounter that problem under Gentoo but also found it in latest Ubuntu (10.10), with different DVD.

Attachments (3)

subtitles.zip (20.9 KB) - added by olivier.laurantin@… 7 years ago.
subtitles files
avoid_duplicate_vobsubs.patch (666 bytes) - added by olivier.laurantin@… 7 years ago.
proposed patch
mplayer-1.1-vobsub-ts.patch (1.6 KB) - added by daniel.pielmeier@… 6 years ago.
Patch: Do not write idx entries for pts differences smaller than a millisecond

Download all attachments as: .zip

Change History (10)

Changed 7 years ago by olivier.laurantin@…

subtitles files

comment:1 Changed 7 years ago by olivier.laurantin@…

  • Cc olivier.laurantin@… added

comment:2 Changed 7 years ago by olivier.laurantin@…

To be more precise, the duplicate entries seem to be always separated by only 1 millisecond.

I also forgot to tell that there is no problem with subtitles when playing the DVD.

Anyway, an easy solution is to avoid dumping subtitles separated by only 1 millisecond. It's unlikely that two subtitles are so close in real life, so it doesn't seem too dirty and it doesn't have any side effect elsewhere in mplayer.

I attach a patch modifying the file sub/vobsub.c

Changed 7 years ago by olivier.laurantin@…

proposed patch

comment:3 Changed 7 years ago by olivier.laurantin@…

comment:4 Changed 7 years ago by thedamocles@…

  • Cc Walter.MMM@… added

comment:5 Changed 7 years ago by thedamocles@…

  • Cc thedamocles@… added

comment:6 Changed 7 years ago by thedamocles@…

I've applied the patch attached by charlot against my medibuntu source package : everything seems to work fine.

Changed 6 years ago by daniel.pielmeier@…

Patch: Do not write idx entries for pts differences smaller than a millisecond

comment:7 Changed 6 years ago by daniel.pielmeier@…

The problem with timestamps differing only a millisecond happens almost in all subtitle files I have seen so far. However the previous patch does not fix all occurrences. Consider the following sequence:

00:00:00.999
00:00:01.000

The difference is only a millisecond but there is a difference in the seconds and thus the entry is written to the idx file.

There are also a lot of entries where the time stamp is a millisecond lower than the previous which also cause media players to not display the corresponding subtitle.

00:00:00.120
00:00:00.119

This is not caught by the previous patch as well. There will be cases where the current timestamp is much much lower than the previous one but I did not recongize problems with these entries. mkvmerge however prints a warning when this occurs.

I will attach a patch which uses the pts time. the idx entry is only written if the absolute value of the difference between pts and last_pts is higher than a millisecond. I have tested the patch on a couple of movies and it seems to work okay.

I did not dig deeper in the code but it would probably interesting where this almost identical pts are coming from.

Note: See TracTickets for help on using tickets.