After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 531166 - textoverlay: subtitles shown with delay after keyframe seek
textoverlay: subtitles shown with delay after keyframe seek
Status: RESOLVED OBSOLETE
Product: GStreamer
Classification: Platform
Component: gst-plugins-base
git master
Other Linux
: Normal normal
: git master
Assigned To: GStreamer Maintainers
GStreamer Maintainers
playback
: 632390 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2008-05-03 02:52 UTC by Tomasz Sałaciński
Modified: 2018-11-03 11:14 UTC
See Also:
GNOME target: ---
GNOME version: 2.21/2.22



Description Tomasz Sałaciński 2008-05-03 02:52:53 UTC
Hello,

As you may know, seeking the movie with MicroDVD subtitles will make the subs disappear for few seconds. This patch will make the subtitles work great - like in MPlayer, Xine or FFDShow (the subs are shown instantly and GST is not slowed down). Actually, it will make GSTreamer the best media framerowk for these subs, because it supports italic/bold text, right now the only issue is seeking. Here it is:

434,435c434,439
< 
<   if (!in_seg) { return NULL; }
---
>   if (in_seg) {
>     state->start_time = clip_start;
>     state->duration = clip_stop - clip_start;
>   } else {
>     return NULL;
>   }

Tested with few subtitle files, and it works ok. I would like to ask someone to test it:) If you want to download the patch file, go here:

http://dp0154.debowypark.waw.pl/gst-sub-patch.diff

I am working on TMPlayer subtitle parser patch too, but AFAIK you prefer to open a new bug, so I'm doing it.

Cheers,
and thanks for GStreamer,
Tomasz Sałaciński
Comment 1 Tomasz Sałaciński 2008-05-03 02:55:41 UTC
Aww, and sorry - the patch is made against gstreamer-plugins-base-0.10.19.
Comment 2 Tomasz Sałaciński 2008-05-03 15:42:33 UTC
Ok, one additional error: Totem is still missing subs, but only when seeking backward with arrow keys. Seeking with progress bar or seeking forward with right arrow key is working perfectly.

Is seeking backward working differently in Totem? I remember the issue with missing audio on previous versions of GStreamer when seeking backward with arrow key.
Comment 3 Sebastian Dröge (slomo) 2008-05-05 06:42:43 UTC
Seeking backwards works the same way as seeking forwards, there's no real difference.

Could you make a test file available that worked bad without your patch but works good with it? :) Also please create unified diffs (-u) in the future, they're much easier to read :)

And against which version of gst-plugins-base did you create this patch? It seems this is already changed like in your patch since 2006
Comment 4 Tomasz Sałaciński 2008-05-05 07:38:21 UTC
It happens with almost every file I have. The issue is, when seeking forward subtitles are shown instantly when they are supposed to be shown, after seeking backward you need to wait 5-10 seconds before the subtitles will appear. I made this against gstreamer-plugins-base-0.10.19.

It happens on other subtitle formats, too. It doesn't happen if I will comment out the segment checking (but the performance is worse). Actually, disabling the segment checking makes subtitles work _perfectly_, but at the expense of performance. Enabling segment checking makes subtitles disappear for few seconds after seeking.

It is very inconvenient, because microdvd parser is not checking for movie's FPS (and it should, according to specification: http://trac.annodex.net/wiki/MicroDVD, check this: "    * Frame rates need to be converted into timings, thus it is necessary to obtain the frame rate of the video to ensure the syncronisation of subtitling. "). So if user wants to check if the subs are ok (if the framerate is ok), he needs to seek to few parts of the movie, and it takes time, because subs are appearing after few seconds.
Comment 5 Tim-Philipp Müller 2008-05-05 09:43:27 UTC
The problem has to do with keyunit seeking. What happens is basically that avidemux will adjust the requested seek position to the position of the next key frame in the index. This will usually be before the requested seek position.

The textoverlay element, however, will not know about this adjustment being made and won't know about the actual new start position of the stream, it will send data from the requested position (which is a few seconds after the actual start). That's where the initial gap/delay of the subtitle display comes from.

Comment 6 Tomasz Sałaciński 2008-05-05 12:15:53 UTC
So is it possible to fix or should just be closed as WONTFIX? This is the only issue that bothers me (and many people AFAIK). It would be great to see this fixed.
Comment 7 Tomasz Sałaciński 2008-07-08 13:50:50 UTC
Anything new on this bug?
Comment 8 Tomasz Sałaciński 2009-03-20 23:29:57 UTC
Hi there,

Is there anything new on this bug? It sits here for a quite long time.
Comment 9 Sebastian Dröge (slomo) 2009-11-12 12:35:12 UTC
The patch is not available anymore unfortunately. But this might have become much better with latest GIT of gst-plugins-base. Can you confirm?
Comment 10 Tobias Mueller 2010-03-04 12:47:21 UTC
Tomasz, can you please reopen this bugreport if this is still an issue for you? Thanks in advance!
Comment 11 Tomasz Sałaciński 2010-09-26 16:46:22 UTC
Hello,

Sorry for long delay. Yes, this is still an issue, but not with all video files, for example it happens with file marked as XVID MPEG-4. If there is any information I can provide you with?
Comment 12 trondsg 2010-11-26 21:03:13 UTC
I have this problem, too, but the subs disappear for longer than "just a few seconds". It can take up to a minute before they reappear.
Comment 13 Tim-Philipp Müller 2011-01-09 22:20:56 UTC
*** Bug 632390 has been marked as a duplicate of this bug. ***
Comment 14 Sebastian Dröge (slomo) 2013-08-16 12:04:27 UTC
Related to bug #600648 and #686713
Comment 15 GStreamer system administrator 2018-11-03 11:14:00 UTC
-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/issues/12.