GNOME Bugzilla – Bug 449435
gnlfilesource does only work with media-start=0 at all times
Last modified: 2009-03-21 14:14:14 UTC
Please describe the problem: following sometimes runs, sometimes fails and if using media-start times greater 5 it seems to fail ever - if using media-times of 1,2,3 or 4 seconds it works always. aren3.ogg is VIDEO: [theo] 600x400 24bpp 10fps with stereo ogg-vorbis sound, made with gstreamer if using video-only-ogg-files it seems to work always. gst-launch --gst-debug=gnlobject:5 gnlfilesource location=aren3.ogg name=bin start=0 media-start=5000000000 duration=10000000000 media-duration=10000000000 caps=video/x-raw-yuv ! queue ! xvimagesink fail after: 0:00:00.340397000 13699 0x804e070 DEBUG gnlobject gnlobject.c:468:translate_incoming_seek:<bin> SENDING SEEK rate:1,000000, format:TIME, flags:11, curtype:SET, stoptype:SET, 0:00:05.000000000 -- 0:00:15.000000000 0:00:00.341227000 13699 0x804e070 DEBUG gnlobject gnlobject.c:663:ghostpad_event_function:<bin:src0> Calling priv->eventfunc 0:00:00.342091000 13699 0x816d678 DEBUG gnlobject gnlobject.c:966:gnl_object_handle_message:<bin> message:tag 0:00:00.342909000 13699 0x804e070 DEBUG gnlobject gnlobject.c:966:gnl_object_handle_message:<bin> message:state-changed 0:00:00.343772000 13699 0x804e070 DEBUG gnlobject gnlobject.c:966:gnl_object_handle_message:<bin> message:state-changed 0:00:00.344439000 13699 0x804e070 DEBUG gnlobject gnlobject.c:966:gnl_object_handle_message:<bin> message:async-done 0:00:00.345151000 13699 0x804e070 DEBUG gnlobject gnlobject.c:966:gnl_object_handle_message:<bin> message:state-changed 0:00:00.345877000 13699 0x804e070 DEBUG gnlobject gnlobject.c:966:gnl_object_handle_message:<bin> message:state-changed 0:00:00.348107000 13699 0x804e070 DEBUG gnlobject gnlobject.c:666:ghostpad_event_function:<bin:src0> Returned from calling priv->eventfunc : 1 0:00:00.350456000 13699 0x8154c88 DEBUG gnlobject gnlobject.c:966:gnl_object_handle_message:<bin> message:error while the same sometimes work (seems dependent on the timing) 0:00:00.201866000 13652 0x804e070 DEBUG gnlobject gnlobject.c:468:translate_incoming_seek:<bin> SENDING SEEK rate:1,000000, format:TIME, flags:11, curtype:SET, stoptype:SET, 0:00:05.000000000 -- 0:00:15.000000000 0:00:00.202405000 13652 0x804e070 DEBUG gnlobject gnlobject.c:663:ghostpad_event_function:<bin:src0> Calling priv->eventfunc 0:00:00.202973000 13652 0x804e070 DEBUG gnlobject gnlobject.c:966:gnl_object_handle_message:<bin> message:state-changed 0:00:00.203473000 13652 0x804e070 DEBUG gnlobject gnlobject.c:966:gnl_object_handle_message:<bin> message:state-changed 0:00:00.203926000 13652 0x804e070 DEBUG gnlobject gnlobject.c:966:gnl_object_handle_message:<bin> message:async-done 0:00:00.204413000 13652 0x804e070 DEBUG gnlobject gnlobject.c:966:gnl_object_handle_message:<bin> message:state-changed 0:00:00.204894000 13652 0x804e070 DEBUG gnlobject gnlobject.c:966:gnl_object_handle_message:<bin> message:state-changed 0:00:00.205497000 13652 0x816d678 DEBUG gnlobject gnlobject.c:966:gnl_object_handle_message:<bin> message:tag 0:00:00.206871000 13652 0x804e070 DEBUG gnlobject gnlobject.c:666:ghostpad_event_function:<bin:src0> Returned from calling priv->eventfunc : 1 0:00:00.208640000 13652 0x816d678 DEBUG gnlobject gnlobject.c:544:internalpad_event_function:<src0:proxypad3> event:newsegment 0:00:00.209139000 13652 0x816d678 DEBUG gnlobject gnlobject.c:511:translate_outgoing_new_segment:<bin> Got NEWSEGMENT 0:00:05.000000000 -- 0:00:15.000000000 // 0:00:05.000000000 and then video-output runs Steps to reproduce: 1. see problem-describtion 2. 3. Actual results: Expected results: Does this happen every time? Other information:
a debug with --gst-debug=decodebin:5 shows the fail of decoding happens after multiple tries to make the queue buffer larger with last entry: 0:00:00.314410000 13776 0x8149870 DEBUG decodebin gstdecodebin.c:1152:queue_enlarge:<internal-decodebin> increasing queue queue2 max-size-bytes to 33908 and then given up. with decodebin2 (set via environment), there are no queue-enlarge messages and it looks like it starts at once with a bigger queue: 0:00:00.297923000 13791 0x8149870 DEBUG decodebin gstdecodebin.c:1189:queue_filled_cb:<internal-decodebin> One of the queues is full at 52546 bytes and the decoding works so workaround may be to use decodebin2 ?
I'm tempted to mark this as a duplicate of #355560 since it's VERY similar
*** This bug has been marked as a duplicate of 575972 ***