GNOME Bugzilla – Bug 759976
mpeg2dec: Flushing during seek breaks libmpeg2 decoding
Last modified: 2018-11-03 15:35:23 UTC
(Possibly a duplicate of https://bugzilla.gnome.org/show_bug.cgi?id=723603 ?) OS: Arch Linux (up to date as of yesterday) libmpeg2 package version 0.5.1-5 I have two mpg files that fail to seek in Totem. They are distributed with the Steam version of Grand Theft Auto: Vice City. [aeikum@aeikum movies]$ file * GTAtitles.mpg: MPEG sequence, v1, system multiplex Logo.mpg: MPEG sequence, v1, system multiplex [aeikum@aeikum movies]$ md5sum * d469239863d8dd5d27a758ec407d3e5a GTAtitles.mpg 5d5ff3db65ba37a0d5f0474a96ac51ea Logo.mpg Totem successfully plays the videos. However, if you try to seek any length, Totem will display a dialog saying, "No valid frames decoded before end of stream" and quit playing the video. Seeking is possible with VLC. A little extra debug printing in gst-plugins-ugly shows the problem occurs after executing gst_mpeg2dec_flush during the seek operation: mpeg2dec gstmpeg2dec.c:1103:gst_mpeg2dec_handle_frame:<mpeg2dec1> parse state 0 mpeg2dec gstmpeg2dec.c:1103:gst_mpeg2dec_handle_frame:<mpeg2dec1> parse state 7 mpeg2dec gstmpeg2dec.c:1103:gst_mpeg2dec_handle_frame:<mpeg2dec1> parse state 4 mpeg2dec gstmpeg2dec.c:974:handle_picture:<mpeg2dec1> stride mpeg2dec gstmpeg2dec.c:1103:gst_mpeg2dec_handle_frame:<mpeg2dec1> parse state 0 mpeg2dec gstmpeg2dec.c:246:gst_mpeg2dec_flush:<mpeg2dec1> flushing decoder mpeg2dec gstmpeg2dec.c:246:gst_mpeg2dec_flush:<mpeg2dec1> flushing decoder mpeg2dec gstmpeg2dec.c:246:gst_mpeg2dec_flush:<mpeg2dec1> flushing decoder mpeg2dec gstmpeg2dec.c:246:gst_mpeg2dec_flush:<mpeg2dec1> flushing decoder mpeg2dec gstmpeg2dec.c:1103:gst_mpeg2dec_handle_frame:<mpeg2dec1> parse state 0 mpeg2dec gstmpeg2dec.c:1103:gst_mpeg2dec_handle_frame:<mpeg2dec1> parse state 0 mpeg2dec gstmpeg2dec.c:1103:gst_mpeg2dec_handle_frame:<mpeg2dec1> parse state 0 mpeg2dec gstmpeg2dec.c:1103:gst_mpeg2dec_handle_frame:<mpeg2dec1> parse state 0 mpeg2dec gstmpeg2dec.c:1103:gst_mpeg2dec_handle_frame:<mpeg2dec1> parse state 0 States {0,7,4} are normal operation. After flushing, mpeg2_parse always returns STATE_BUFFER(== 0) no matter how much data is fed to mpeg2_buffer. gst_mpeg2dec_flush executes mpeg2_reset and mpeg2_skip. Attached is a GST_DEBUG=9 log of the Totem session, trimmed to the first 600000 lines (expands to 112 MB).
Created attachment 318013 [details] Trimmed GST_DEBUG log of Totem failing to seek The log was too big, so I've uploaded a log without refcounting and trimmed to 200000 lines. It expands to 40 MB.
I also see this problem with the two videos available here: http://fgouget.free.fr/tmp/wine-test-videos/daytona_crw.mpg http://fgouget.free.fr/tmp/wine-test-videos/Ikea_Tidy_up_2_11.mpg From: https://bugs.winehq.org/show_bug.cgi?id=17448#c14
Another user was able to confirm this with 1.6.2 on their machine, so it isn't an issue unique to Arch or my setup.
I tried reverting this commit on top of 1.6.2: commit 22b3a60dbd393b9f82d411efc027f20992904b69 Author: Sebastian Dröge <slomo@circular-chaos.org> Date: Thu Aug 15 15:30:31 2013 +0200 mpeg2dec: Fix mpeg2_reset() calls Totem no longer shows the error on seeking. However, the mpeg usually decoding seems to go poorly, as if it never finds another key frame, but not always. Sometimes (maybe 1 in 10 seeks) it works correctly after a seek.
-- 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-ugly/issues/14.