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 591664 - [playbin2] after seeking, srt subtitles don't resync correctly
[playbin2] after seeking, srt subtitles don't resync correctly
Status: RESOLVED FIXED
Product: GStreamer
Classification: Platform
Component: gst-plugins-base
0.10.24
Other All
: Normal normal
: 0.10.25
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2009-08-13 10:26 UTC by Andreas Frisch
Modified: 2009-08-18 09:18 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
test case (6.13 KB, text/x-csrc)
2009-08-13 10:28 UTC, Andreas Frisch
  Details
test case doing a seek +10s after 10s playback (6.13 KB, text/x-csrc)
2009-08-13 10:30 UTC, Andreas Frisch
  Details
log of testcase without seeking (152.12 KB, application/octet-stream)
2009-08-13 10:31 UTC, Andreas Frisch
  Details
log of test case with a seek of 10s after 10s (164.81 KB, application/octet-stream)
2009-08-13 10:33 UTC, Andreas Frisch
  Details
playsink-textsink.diff (1014 bytes, patch)
2009-08-17 15:04 UTC, Sebastian Dröge (slomo)
committed Details | Review

Description Andreas Frisch 2009-08-13 10:26:45 UTC
Please describe the problem:
after a seek, subtitles coming from an external srt file don't sync correctly

Steps to reproduce:
1. root@dm8000:/testProgs# GST_DEBUG=*:3,*sub*:5 ./srtnoseek file:///hdd/movie/avi/test.avi file:///hdd/movie/avi/test.srt >logfile_noseek.log 2>&1

2. GST_DEBUG=*:3,*sub*:5 ./srtseek file:///hdd/movie/avi/test.avi file:///hdd/movie/avi/test.srt >logfile_seek10s.log 2>&1

Actual results:
1. subtitles display at expected times
2. subtitles display correctly until a seek, afterwards they still appear (almost) at the sime time as if no seek had been invoked 

Expected results:
in case 2. the subtitles should be displayed with a respective time offset (in this testcase 10 seconds earlier)

Does this happen every time?
yes, but only with external subtitle files, subtitle streams internally muxed into mkv are not affected

Other information:
testcase and logfiles to be uploaded - should work with any avi + srt file
Comment 1 Andreas Frisch 2009-08-13 10:28:44 UTC
Created attachment 140638 [details]
test case
Comment 2 Andreas Frisch 2009-08-13 10:30:12 UTC
Created attachment 140639 [details]
test case doing a seek +10s after 10s playback

run with movie uri as first and suburi as second paramter
Comment 3 Andreas Frisch 2009-08-13 10:31:34 UTC
Created attachment 140640 [details]
log of testcase without seeking

this shows the subtitle lines appearing at the correct times
Comment 4 Andreas Frisch 2009-08-13 10:33:05 UTC
Created attachment 140641 [details]
log of test case with a seek of 10s after 10s

this shows that subtitle lines aren't being displayed at the correct times after the seek
Comment 5 Sebastian Dröge (slomo) 2009-08-17 14:24:13 UTC
Yes, the problem here seems to be that playbin2 only forwards the SEEK event to the audio/video part of the pipeline and not to the subtitle part, i.e. it only sends it to avidemux. And then the audio/video starts again at the correct position and subtitles continue from the old position.
Comment 6 Sebastian Dröge (slomo) 2009-08-17 15:04:40 UTC
Created attachment 140968 [details] [review]
playsink-textsink.diff

Maybe this patch fixes it, can you test it?

For normal subtitle playback (via textoverlay) playbin2 should work, the problem is that if there's a text sink it will never get the seek because playbin2 only sends it to the video sink (or if that fails) to the audio sink, never to the text sink. For the overlay case this works because the video part of the pipeline will send the event to subparse too.

Unfortunately I can't test this patch because I don't have a useful and working video+subtitle file.
Comment 7 Andreas Frisch 2009-08-17 18:10:31 UTC
Great, it works for me! Thanks a lot for the fix!
Comment 8 Sebastian Dröge (slomo) 2009-08-18 06:41:16 UTC
commit b5f84c0637accead6ad2ccda84b7aae7ddeb87b7
Author: Sebastian Dröge <sebastian.droege@collabora.co.uk>
Date:   Tue Aug 18 08:39:02 2009 +0200

    playsink: If a custom text sink is used, send events to it too
    
    Before, SEEK events would be sent to the video sink, which wouldn't
    be linked in any way to the subtitle part of the pipeline and
    subparse would never see the SEEK event. This would then seek
    the audio/video but the subtitles would continue from the old
    position instead.
    
    Fixes bug #591664.
Comment 9 Tim-Philipp Müller 2009-08-18 07:41:33 UTC
I guess this would be needed for any subpic sink as well if set?
Comment 10 Sebastian Dröge (slomo) 2009-08-18 08:38:49 UTC
(In reply to comment #9)
> I guess this would be needed for any subpic sink as well if set?

Not sure, the subpic sink would get it's data from the demuxer somehow so it would also be reached from the video sink. Or is it possible for subpicture stuff to come from a separate file too?


Also I'm not entirely convinced anymore that the patch was correct. For embedded subtitles (i.e. not a separate file) the SEEK event would now be sent twice to subparse (once from the text sink, once from the video sink). Am I missing something here?
Comment 11 Tim-Philipp Müller 2009-08-18 09:06:19 UTC
> Not sure, the subpic sink would get it's data from the demuxer somehow so it
> would also be reached from the video sink. Or is it possible for subpicture
> stuff to come from a separate file too?

Theoretically subpicture subtitles could come from a separate file (we don't support that yet, but there are .sub files in mpeg format with embedded dvd-style subpics and a separate .idx file).


> Also I'm not entirely convinced anymore that the patch was correct. For
> embedded subtitles (i.e. not a separate file) the SEEK event would now be sent
> twice to subparse (once from the text sink, once from the video sink). Am I
> missing something here?

Well, I guess that's just tough luck. Not sure if there's a better way. subparse and/or demuxers could be made to ignore duplicate seek events (I think we should be able to tell duplicates from the event serial number).
Comment 12 Sebastian Dröge (slomo) 2009-08-18 09:17:26 UTC
Ok, I've added the same change for the subpicture sink now.

commit b7fa34a279b5633e64093ca12c43f150c21f57a0
Author: Sebastian Dröge <sebastian.droege@collabora.co.uk>
Date:   Tue Aug 18 11:15:41 2009 +0200

    playsink: Also send SEEK events directly to a subpicture sink
Comment 13 Sebastian Dröge (slomo) 2009-08-18 09:18:19 UTC
(In reply to comment #11)
> > Also I'm not entirely convinced anymore that the patch was correct. For
> > embedded subtitles (i.e. not a separate file) the SEEK event would now be sent
> > twice to subparse (once from the text sink, once from the video sink). Am I
> > missing something here?
> 
> Well, I guess that's just tough luck. Not sure if there's a better way.
> subparse and/or demuxers could be made to ignore duplicate seek events (I think
> we should be able to tell duplicates from the event serial number).

In some demuxer I saw checks, if the incoming SEEK events matches the currently playing segment and position. I guess that's already good enough most of the time