GNOME Bugzilla – Bug 338995
Videorate does not handle EOS
Last modified: 2006-04-21 15:21:51 UTC
When transcoding a DVD image to Ogg I noticed that if I include 'videorate' in the pipeline then EOS is never reached. Instead the last image of the original file gets repeated indefinetly making the resulting file (or on screen display) go on forever. I was able to reproduce this issue with the following pipeline. gst-launch-0.10 dvdreadsrc title="5" ! decodebin name="dvd" dvd. ! ffmpegcolorspace ! video/x-raw-yuv,format=\(fourcc\)YUY2 ! videoscale method=1 ! video/x-raw-yuv,format=\(fourcc\)YUY2,width=360,height=288,pixel-aspect-ratio=\(fraction\)16/15 ! videorate ! video/x-raw-yuv,framerate=25/2 ! ffmpegcolorspace ! xvimagesink dvd. ! audioconvert ! alsasink
gst-launch-0.10 filesrc location=/home/zaheer/desktop-recording.ogg ! oggdemux ! theoradec ! videorate ! video/x-raw-yuv,framerate=1/1 ! ffmpegcolorspace ! ximagesink does not cause this...
Given that videorate is chain-based, I can see this frame-duplication-at-the-end-until-the-end-of-time only be caused by one of two things: (a) somewhere around the end videorate gets a buffer with an enormous timestamp and goes to fill the gap by pushing lots of copies of the previous buffer (b) somewhere around the end videorate gets a buffer with GST_CLOCK_TIME_NONE and interprets that as very high timestamp, and then goes on to do (a). Or something like that where CLOCK_TIME_NONE isn't handled right. Christian, could you run: $ gst-launch-0.10 dvdreadsrc title="5" ! dvdemux name=d d. ! mpeg2dec ! fakesink -v 2>dbg.log and attach the gzipped output?
Created attachment 63856 [details] Output of requested gst-launch line
The timestamps at the end look perfectly fine, so that can't be it. However, it looks like two EOS events are sent: /pipeline0/fakesink0: timestamp: 0:15:22.351422222, duration: 0:00:00.040000000 /pipeline0/fakesink0: timestamp: 0:15:22.391422222, duration: 0:00:00.040000000 /pipeline0/fakesink0: last-message = "event ******* E (type: 86, ) 0x981d568" /pipeline0/fakesink0: last-message = "event ******* E (type: 86, ) 0x981d590" Got EOS from element "pipeline0".
Seems the behaviour is not deterministic. I just tried ripping the file again and this time it stopped writing to the file at EOS. It still doesn't give me the command prompt again though, so I will mark 339004 as a duplicate of this one as I am sure it is the same issue/issues causing this.
*** Bug 339004 has been marked as a duplicate of this bug. ***
can't see an obvious problem in videorate. dvddemux has some issues with state changed that are now fixed in CVS that could cause deadlocks and other weird errors during shutdown.
fixed the two EOS events in CVS now too.
the problem is not at the end but around time 0:15:09 /pipeline0/fakesink1: last-message = "chain ******* < (207360 bytes, timestamp: 0:15:09.351433333, duration: 0:00:00.040000000 /pipeline0/fakesink1: last-message = "chain ******* < (207360 bytes, timestamp: 0:15:09.391433333, duration: 0:00:00.040000000 /pipeline0/fakesink1: last-message = "chain ******* < (207360 bytes, timestamp: 0:15:09.271433333, duration: 0:00:00.040000000 /pipeline0/fakesink1: last-message = "chain ******* < (207360 bytes, timestamp: 0:15:09.311433333, duration: 0:00:00.0400 Timestamps go backwards which makes videorate go into an endless loop. marking as duplicate of #339013 *** This bug has been marked as a duplicate of 339013 ***