GNOME Bugzilla – Bug 155350
Previous video remains on-screen when audio-only file is queued
Last modified: 2006-07-03 20:41:46 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.
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.
Reopening, the problem still occurs with GStreamer, gst-plugins and Totem from CVS from 04-12-2004.
I can reproduce this, sorry for my previous mistake. It should show the logo or hide the window.
*** Bug 165660 has been marked as a duplicate of this bug. ***
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?
Also see #134342.
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.
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 ?
*** Bug 328089 has been marked as a duplicate of this bug. ***
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.
So is that the final desired behaviour ?
I guess it would be nicer, but certainly not a blocker.
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)?
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.