通过STDIN馈入gstreamer fdsrc仅产生预期结果的一部分

本文介绍了通过STDIN馈入gstreamer fdsrc仅产生预期结果的一部分的处理方法，对大家解决问题具有一定的参考价值，需要的朋友们下面随着小编来一起学习吧！

问题描述

我正在使用gstreamer Windows端口OSSBuild.我想使用fdsrc元素通过其STDIN为gst-launch提供视频数据.这样做似乎是管线仅消耗了输入的一小部分.例如

I am using gstreamer windows port OSSBuild. I want to feed gst-launch with video data via its STDIN using the fdsrc element. Doing so it seems as if the pipline is consuming just a small fraction of the input. For instance

type source.yuv | gst-launch fdsrc ! videoparse format=GST_VIDEO_FORMAT_I420 width=176 height=144 framerate=30000/1001 ! x264enc ! mpegtsmux ! filesink location=out.ts

在

gst-launch filesrc location=source.yuv ! videoparse format=GST_VIDEO_FORMAT_I420 width=176 height=144 framerate=30000/1001 ! x264enc ! mpegtsmux ! filesink location=out.ts

很好.因此，我认为问题与我对fdsrc的使用有关.

is all fine. So I assume the problem is related to my usage of fdsrc.

有什么想法吗?

推荐答案

在Linux下有效:


gst-launch videotestsrc num-buffers=100 ! \
  video/x-raw-yuv,format=(fourcc)"I420",width=320,height=240 ! filesink location=video.yuv

cat video.yuv | gst-launch-0.10 fdsrc ! \
  videoparse format="I420" width=320 height=240 ! xvimagesink

我想知道我们是否遇到了Windows下io的可移植性问题.您可以尝试将队列元素放在fdsrc之后.

I wonder if we'Re hitting a portability issue with regards to io under windows. You could try putting a queue element right after fdsrc.

这篇关于通过STDIN馈入gstreamer fdsrc仅产生预期结果的一部分的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！