This is best demonstrated using an example:
export GST_DEBUG="*:2"
1) gst-launch playbin2 uri=http://media.w3.org/2010/05/sintel/trailer.webm
2) gst-launch playbin2 uri=http://media.w3.org/2010/05/sintel/trailer.webm video-sink="multiqueue ! mfw_v4lsink"
3) gst-launch playbin2 uri=http://media.w3.org/2010/05/sintel/trailer.webm video-sink="queue ! mfw_v4lsink"
4) gst-launch playbin2 uri=http://media.w3.org/2010/05/sintel/trailer.webm video-sink="queue2 ! mfw_v4lsink"
Playback for 1) and 2) is good, where as playback for 3) and 4) starts of choppy, stalls and gets lots of messages of the form:
0:00:00.472157023 7566 0x40d60150 WARN vpudec vpudec.c:1578:gst_vpudec_chain: Got no frame buffer message, return 0x89, 10 frames in displaying queue!!
GST_DEBUG=GST_ELEMENT_FACTORY:3 shows that playbin2 without the video-sink property uses 'multiqueue'.
So, it looks as if something is going on with 'vpudec' when the pipeline includes a 'queue' or 'queue2' element.
This was running on a Wandboard Quad using an image built using Yocto.
Can anyone explain what's going on here?
解決済! 解決策の投稿を見る。
hi,
So if add one queue between VPU dec and V4lsink will cause not enough frame buffer to run. So you command should be video-sink="queue max-size-buffers=1 max-size-bytes=0 max-size-time=0 ! mfw_v4lsink"
hi,
So if add one queue between VPU dec and V4lsink will cause not enough frame buffer to run. So you command should be video-sink="queue max-size-buffers=1 max-size-bytes=0 max-size-time=0 ! mfw_v4lsink"
Hi,
Thanks, that's sorted it :smileyhappy:
Could you please explain why there is a hard limit on the number of buffers in the pipeline? I thought that the limits were set by the elements and that it was this which set the limit in the pipeline.
the vpu buffers number can be set ,it should be in the VPU plugin, the default is 6, you could adjust it .
frame-plus : set number of addtional frames for smoothly playback
flags: readable, writable
Integer. Range: 2 - 2147483647 Default: 6
Another thread similar to this issue is https://community.freescale.com/message/339660
Leo
Yes, it could well be related. The steps I've given above are repeatable without the 'random' behavior mentioned on the other issue, but it does also seem to be related to buffers.