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 155350 - Previous video remains on-screen when audio-only file is queued
Previous video remains on-screen when audio-only file is queued
Status: RESOLVED FIXED
Product: totem
Classification: Core
Component: GStreamer backend
unspecified
Other Linux
: Normal normal
: ---
Assigned To: Maintainer alias for GStreamer component of Totem
Maintainer alias for GStreamer component of Totem
: 165660 328089 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2004-10-14 03:07 UTC by Paul Drain
Modified: 2006-07-03 20:41 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Paul Drain 2004-10-14 03:07:42 UTC
Totem seems to leave the last frame of the previous video on-screen when an
audio-only file is played from a playlist.

If you pause the audio, drag the window around the screen, the window goes blue
(as expected) -- but as soon as you resume playing the audio-only track, the
last frame of the video is redisplayed.

It doesn't seem to matter if the auto resize function is off or on, or if any of
the visualization settings are touched.

Running totem with --gst-debug=2 and debugging turned on produces the following
when attempting to play the second (MP3, audio only) file:

WARN  (0x84c2848 - 304923:01:18.656420000)  GST_SCHEDULING(10112)
gstpad.c(3153):_invent_event: needed to invent a DISCONT 0x80c0458 (no time) for
source:src => typefind:sink
WARN  (0x84c2848 - 304923:01:18.688021000)       mpegdemux(10112)
gstmpegdemux.c(766):gst_mpeg_demux_parse_packet:<mpegdemux3> unknown stream id 0xbe
WARN  (0x84c2848 - 304923:01:18.689232000)  GST_SCHEDULING(10112)
gstpad.c(3147):_invent_event: needed to invent a DISCONT 0x80c03a0 (time
413344444) for mpegdemux3:video_00 => mpeg2dec3:sink
WARN  (0x84c2848 - 304923:01:18.701836000)       mpegdemux(10112)
gstmpegdemux.c(766):gst_mpeg_demux_parse_packet:<mpegdemux3> unknown stream id 0xbe
WARN  (0x84c2848 - 304923:01:18.703003000)       mpegdemux(10112)
gstmpegdemux.c(766):gst_mpeg_demux_parse_packet:<mpegdemux3> unknown stream id 0xbe
WARN  (0x84c2848 - 304923:01:18.728795000)  GST_SCHEDULING(10112)
gstpad.c(3147):_invent_event: needed to invent a DISCONT 0x80c02e8 (time
333344444) for mpegdemux3:audio_00 => mad6:sink
WARN  (0x84c2848 - 304923:01:18.738041000)  GST_SCHEDULING(10112)
gstpad.c(3147):_invent_event: needed to invent a DISCONT 0x80c02e8 (time
333333333) for mad6:src => preroll_src0:sink
WARN  (0x84c2848 - 304923:01:19.247170000)       mpegdemux(10112)
gstmpegdemux.c(766):gst_mpeg_demux_parse_packet:<mpegdemux3> unknown stream id 0xbe
WARN  (0x85bce78 - 304923:01:19.560733000)  queue_dataflow(10112)
gstqueue.c(856):gst_queue_handle_src_event:<preroll_src1> Preparing for loop for
event handlerWARN  (0x85bce78 - 304923:01:19.570833000)  queue_dataflow(10112)
gstqueue.c(884):gst_queue_handle_src_event:<preroll_src1> Event handled
WARN  (0x85bce78 - 304923:01:22.090653000)  queue_dataflow(10112)
gstqueue.c(856):gst_queue_handle_src_event:<preroll_src1> Preparing for loop for
event handlerWARN  (0x85bce78 - 304923:01:22.091423000)  queue_dataflow(10112)
gstqueue.c(884):gst_queue_handle_src_event:<preroll_src1> Event handled
WARN  (0x85bce78 - 304923:01:22.133490000)  queue_dataflow(10112)
gstqueue.c(856):gst_queue_handle_src_event:<preroll_src1> Preparing for loop for
event handlerWARN  (0x85bce78 - 304923:01:22.134409000)  queue_dataflow(10112)
gstqueue.c(884):gst_queue_handle_src_event:<preroll_src1> Event handled
WARN  (0x85bce78 - 304923:01:22.160354000)  queue_dataflow(10112)
gstqueue.c(856):gst_queue_handle_src_event:<preroll_src1> Preparing for loop for
event handlerWARN  (0x85bce78 - 304923:01:22.177292000)  queue_dataflow(10112)
gstqueue.c(884):gst_queue_handle_src_event:<preroll_src1> Event handled
WARN  (0x85bce78 - 304923:01:22.233337000)  queue_dataflow(10112)
gstqueue.c(856):gst_queue_handle_src_event:<preroll_src1> Preparing for loop for
event handlerWARN  (0x85bce78 - 304923:01:22.244924000)  queue_dataflow(10112)
gstqueue.c(884):gst_queue_handle_src_event:<preroll_src1> Event handled

(totem:10112): GStreamer-CRITICAL **: file gstbin.c: line 543
(gst_bin_remove_func): assertion `GST_ELEMENT_PARENT (element) == (GstObject *)
bin' failed

(totem:10112): GStreamer-CRITICAL **: file gstbin.c: line 543
(gst_bin_remove_func): assertion `GST_ELEMENT_PARENT (element) == (GstObject *)
bin' failed
WARN  (0x84c2848 - 304923:01:34.153794000)  GST_SCHEDULING(10112)
gstpad.c(3153):_invent_event: needed to invent a DISCONT 0x80c03a0 (no time) for
source:src => typefind:sink
WARN  (0x84c2848 - 304923:01:34.215674000)  GST_SCHEDULING(10112)
gstpad.c(3153):_invent_event: needed to invent a DISCONT 0x80c0230 (no time) for
id3demux2:src => mad7:sink
WARN  (0x84c2848 - 304923:01:34.215949000)             mad(10112)
gstmad.c(948):gst_mad_handle_event: Failed to retrieve sample position

This is using GStreamer, gst-plugins and gst-ffmpeg from CVS (14th October 2004)
on a Ubuntu system with Totem 0.99.19.

Of note, GStreamer 0.8.7 didn't have this issue, but it caused the video file I
was attempting to play to crash badly.
Comment 1 Ronald Bultje 2004-12-03 22:37:22 UTC
I believe this no longer to be the case with current CVS. It will now either
stay black or show visualizations. Please reopen if you still see this, I might
have done something wrong or accidently re-add this bug at some point.
Comment 2 Paul Drain 2004-12-06 00:44:32 UTC
Reopening, the problem still occurs with GStreamer, gst-plugins and Totem from
CVS from 04-12-2004.
Comment 3 Ronald Bultje 2005-02-04 09:12:51 UTC
I can reproduce this, sorry for my previous mistake. It should show the logo or
hide the window.
Comment 4 Ronald Bultje 2005-02-04 09:14:47 UTC
*** Bug 165660 has been marked as a duplicate of this bug. ***
Comment 5 Ronald Bultje 2005-02-25 11:27:11 UTC
We're getting better. I'm at the point where the video will not be on-screen.
However, the logo still isn't shown and the window is not hidden. Not sure which
of the two to choose... Bastien, any pref?
Comment 6 Ronald Bultje 2005-02-25 11:28:45 UTC
Also see #134342.
Comment 7 Bastien Nocera 2005-02-25 11:35:54 UTC
Black screen is fine for now, I wouldn't want to put big changes like that in
just before GNOME 2.10. In the long run, if there aren't any viz selected, and
you're playing an audio only file, it should probably hide the video canvas indeed.
Comment 8 Julien MOUTTE 2006-01-21 22:51:43 UTC
The xine backend keeps redrawing the latest frame of the previous video file.

GStreamer 0.10 shows a black window. Which IMHO make much more sense.

Can we close that bug ?
Comment 9 Bastien Nocera 2006-01-22 11:36:49 UTC
*** Bug 328089 has been marked as a duplicate of this bug. ***
Comment 10 Bastien Nocera 2006-01-22 11:38:01 UTC
From bug 328089:
"It has happend to me that while watching a movie in the night i fall sleep and
when i wake up the computer seems to be hunged up as everything is black."
It would be better if the last frame showed up on the screen, instead of plain black.
Comment 11 Julien MOUTTE 2006-01-22 12:20:54 UTC
So is that the final desired behaviour ?
Comment 12 Bastien Nocera 2006-01-22 13:34:48 UTC
I guess it would be nicer, but certainly not a blocker.
Comment 13 Tim-Philipp Müller 2006-07-03 16:32:09 UTC
Current behaviour with the GStreamer-0.10 backend is to show a black window when playing an audio file after a video file and visualisation is disabled.

I think showing a black frame or the logo makes much more sense than showing a video frame from a completely unrelated video that's not playing any longer.

Is the current behaviour ok (ie. can this bug be closeed)?

Comment 14 Bastien Nocera 2006-07-03 20:41:46 UTC
Fine by me. CVS HEAD shows the logo when the viz are off, and playing an audio file in the xine-lib backend as well. Let's be done with this.