来自应用程序的OpenCv + Gstreamer,初始延迟30秒

来自应用程序的OpenCv + Gstreamer,初始延迟30秒

问题描述:

所以我的应用程序正在使用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.