Re: Gstreamer pipeline problem

[Chris Tapp <opensource@keylevel.com>]

Hi Thomas,

Some more info below:

On 11 Jul 2013, at 09:39, Thomas Senyk wrote:

> On Wednesday, 10 July, 2013 20:53:58 Chris Tapp wrote:
>> On 10 Jul 2013, at 20:19, Chris Tapp wrote:
>>> I've got an application which uses playbin2 to capture video. The pipeline
>>> is of the form:
>>> 
>>> playbin2 uri=... video-sink="queue2 ! videoscale ! video/x-raw-rgb,
>>> pixel-aspect-ratio=1/1, width=<capture-width>, height=<capture-height> !
>>> fakesink"
>>> 
>>> I then get the "frame" property from the pipeline and use this to grab the
>>> latest frame.
>>> 
>>> This works on my development system (Ubuntu 11.10) and a Cedar Trail /
>>> Yocto system, but the pipeline fails on the Wandboard Quad. I think this
>>> is related to:
>>> 
>>> 0:00:13.028151336  1349 0x4442d520 WARN           basetransform
>>> /media/SSD-RAID/build-danny-wandboard/tmp/work/armv7a-vfp-neon-poky-linux
>>> -gnueabi/gstreamer/0.10.36-r2/gstreamer-0.10.36/libs/gst/base/gstbasetrans
>>> form.c:1304:gst_base_transform_setcaps:<videoscale0x2ab820> transform
>>> could not transform video/x-raw-yuv, width=(int)854, height=(int)480,
>>> framerate=(fraction)24/1, format=(fourcc)I420, interlaced=(boolean)false
>>> in anything we support
>>> 
>>> I added an ffmpegcolorspace element betwween the queue2 and the videoscale
>>> to get round this and the pipeline now builds, but only a few frames are
>>> captured. There are different diagnostics showing:
>>> 
>>> 0:00:02.881403000  1361   0x28da60 WARN                  vpudec
>>> vpudec.c:914:gst_vpudec_core_create_and_register_frames: Allocate
>>> Internal framebuffers!!!! Message Callback : Element playbin0x250b68
>>> changed state from READY to PAUSED. 0:00:03.237675000  1361   0x28da60
>>> WARN                  vpudec vpudec.c:1578:gst_vpudec_chain: Got no frame
>>> buffer message, return 0x89, 8 frames in displaying queue!!
>>> 0:00:03.242324334  1361   0x28da60 WARN                  vpudec
>>> vpudec.c:1578:gst_vpudec_chain: Got no frame buffer message, return 0x89,
>>> 8 frames in displaying queue!!
>>> 
>>> <lots of repeats>
>>> 
>>> 0:00:08.499914334  1382   0x28d860 WARN                  vpudec
>>> vpudec.c:1655:gst_vpudec_chain: Retry too many times, maybe BUG!!
>>> 0:00:08.500784667  1382   0x28d860 WARN                  vpudec
>>> vpudec.c:1578:gst_vpudec_chain: Got no frame buffer message, return 0x88,
>>> 8 frames in displaying queue!!
>>> 
>>> <lots of repeats>
>>> 
>>> Message Callback : Element playbin0x250aa0 changed state from PAUSED to
>>> PLAYING. 0:00:09.253202667  1382   0x28d860 WARN                  vpudec
>>> vpudec.c:1578:gst_vpudec_chain: Got no frame buffer message, return 0x88,
>>> 8 frames in displaying queue!!
>>> 
>>> 0:00:13.364523335  1460   0x142ec0 WARN             mfw_v4lsink
>>> mfw_gst_v4l_buffer.c:435:mfw_gst_v4l2_new_buffer: Try new buffer failed,
>>> ret 2 No such file or directory queued 0
>>> 
>>> 
>>> The "Message Callback" events are my own logging to try and see what's
>>> happening in my app.
>>> 
>>> Is this something I'm doing wrong, or are these messages a real issue
>>> somewhere?
>> This is when playing a .webm. The results for an .flv are as expected.
> 
> is it the same when you use v4l2 sink instead of fakesink?
> Is playbin (without defining the pipeline) behaving the same?

I've run some tests using pipelines of the form:

   gst-launch playbin2=file://trailer.webm video-sink="<a-sink-to-test>"

GST_DEBUG was set to "*:2"

1) When the sink is set to "mfw_4vlsink" I get full screen video playback;
2) When the sink is set to "fakesink" I get nothing on the screen (as expected), and no debug of interest;
3) When the sink is set to "queue2 ! mfw_4vlsink" I get very choppy full screen video playback (which eventually stalls) and debug output as originally reported;
4) When the sink is set to "queue2 ! fakesink" I get nothing on the screen (as expected), and no debug of interest;
5) When the sink is set to "queue2 ! fakesink sync=1" I get nothing on the screen and debug output as originally reported.

These were all run from the command line, no 'X' running.

It looks like queue2 + sync=1 (default for v4lsink) combination causes the problem... Setting sync=0 for v4lsink makes no difference and looks to be ignored.

Things also 'get confused' at times and 1) doesn't work anymore without a restart.

Does any of that help? ;-)

Chris Tapp

opensource@keylevel.com
www.keylevel.com