来自应用程序的OpenCv + Gstreamer，初始延迟30秒 [英] OpenCv + Gstreamer from an app, getting initial 30s delay

问题描述

所以我的应用程序正在使用new VideoWriter(pipeline-definition);

So my application is exposing an RTP stream using new VideoWriter(pipeline-definition);

管道定义为:

appsrc is-live=1 do-timestamp=1 format=3 stream-type=0 min-latency=0 max-latency=500000000 ! queue leaky=2 max-size-time=500000000 ! videoconvert ! video/x-raw ! x264enc ! h264parse ! rtph264pay config-interval=10 pt=96 ! udpsink host=127.0.0.1 port=9000

我面临的问题是在VLC中查看流时流延迟30秒.不管我做什么，VLC总是落后29-30秒.似乎appsrc导致了这一点，因为与videotestsrc相同的管道根本没有延迟.

The problem I'm faced with is 30s delay in the stream when viewing it in VLC. No matter what I do, VLC is always 29-30s behind. It seems that appsrc is causing this as the same pipeline with videotestsrc has no delay at all.

有什么想法要使appsrc立即将帧释放到流中吗?

Any ideas what should I do to make the appsrc release the frames to the stream right away?

推荐答案

类似于VideoWriter的内部缓冲区似乎可以缓存30秒钟的素材.以我为例，我在内存中保留了一个单例，并依靠它足够快地刷新到管道中.实际上，我最终不得不迫使VideoWriter通过释放数据来刷新数据.

Seems like the VideoWriter has an internal buffer that caches 30s of footage. In my case I was keeping a singleton in memory and relied on it flushing to the pipeline fast enough. In reality I ended up having to force the VideoWriter to flush the data by releasing it.

我不建议您使用此方法作为问题的解决方案，但就我而言，它仅在定义DEBUG时才需要该管道，因此可以正常工作.

I don't recommend this as a solution to the problem but in my case it worked as I need this pipeline only when DEBUG is defined.

这篇关于来自应用程序的OpenCv + Gstreamer，初始延迟30秒的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！