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 723603 - mpeg2dec: Seek problem with video Mpegts/mpeg2
mpeg2dec: Seek problem with video Mpegts/mpeg2
Status: RESOLVED INCOMPLETE
Product: GStreamer
Classification: Platform
Component: gst-plugins-bad
1.2.2
Other Windows
: Normal normal
: NONE
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2014-02-04 10:49 UTC by Eric
Modified: 2018-01-23 17:24 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Eric 2014-02-04 10:49:41 UTC
Hi
when seeking a mpegts/mpeg2 video file in time (the time seek is handled by the source element) it seems the decoder have trouble presenting the right frames.
 If the seek is less that 30s from the beginning of the file, then after a few second, the decoder is able to present video, but if the seek is greater than 35s then the decoder stop presenting frames, and only audio is audible. 

Any idea on how to fix this?

Eric T.
Comment 1 Sebastian Dröge (slomo) 2014-02-04 12:57:19 UTC
Do you have a testcase to reproduce this?
Comment 2 Eric 2014-02-04 15:50:46 UTC
I'll try to find a way for you to be able to test the case.
Is there any source element that is able to work in 'time' ref?
Comment 3 Sebastian Dröge (slomo) 2014-02-04 16:07:17 UTC
I currently can't think of any that allows seeking
Comment 4 Tim-Philipp Müller 2014-02-12 00:02:57 UTC
rtspsrc might.

Question is: why do you think this is a bug in the decoder element and not your source, when it seemingly works fine with demuxers otherwise?
Comment 5 Eric 2014-02-13 08:37:40 UTC
(In reply to comment #4)
> rtspsrc might.
> 
> Question is: why do you think this is a bug in the decoder element and not your
> source, when it seemingly works fine with demuxers otherwise?

Hi, 
it looks to me it comes from the decoder because seeking on lots of other format work well. And also, the sound of the video is decoded well from the right position.

The demuxer seeks well with h264 video, so looks like the problem must come from the decoder when it receive an input segment in format GST_FORMAT_TIME.

Maybe I can try to send some logs, but I don't really know what to log. Also the decoder ouputs a good amount of things, I wasn't able to find any clue about my problem ^^. 

Cheers,Eric
Comment 6 Tim-Philipp Müller 2018-01-23 00:40:32 UTC
Closing this bug report as no further information has been provided. Please feel free to reopen this bug report if you can provide the information that was asked for in a previous comment.
Thanks!
Comment 7 Andrew Eikum 2018-01-23 17:12:47 UTC
Bug 723603 may be related.
Comment 8 Andrew Eikum 2018-01-23 17:13:06 UTC
Sorry, I meant Bug 759976.
Comment 9 Tim-Philipp Müller 2018-01-23 17:24:42 UTC
Thanks Andrew.