decklinksrc pipeline optimization

[Sebastian Dröge]

On Mon, 2019-04-01 at 14:28 -0600, John P Poet wrote:
> When using decklinksrc to capture to a transport stream file, it
> typically drops a couple of frames per second:
> 
> [...]
>
> I have played around with queue to try to eliminate those drops, but
> all I have achieved is to delay them.  Once they start up, they never
> stop.  My most recent attempt is:
> 
> gst-launch-1.0 -v decklinkvideosrc device-number=${DEVICE} mode=12
> do-timestamp=true output-cc=true video-format=2 duplex-mode=0 ! queue
> max-size-buffers=4096 max-size-bytes=0 max-size-time=0 !
> autovideoconvert ! queue max-size-buffers=4096 max-size-bytes=0 max-
> size-time=0 ! nvh264enc ! h264parse ! queue max-size-buffers=4096
> max-size-bytes=0 max-size-time=0 ! mpegtsmux name=mux ! queue max-
> size-buffers=4096 max-size-bytes=0 max-size-time=0 ! filesink
> location=/storage1/SDI/video-nv.ts      decklinkaudiosrc device-
> number=${DEVICE} ! queue max-size-buffers=4096 max-size-bytes=0 max-
> size-time=0 ! audioconvert ! queue max-size-buffers=4096 max-size-
> bytes=0 max-size-time=0 ! avenc_ac3 bitrate=480000 ! ac3parse ! queue
> max-size-buffers=4096 max-size-bytes=0 max-size-time=0 ! mux.
> 
> I feel like I must be handing this wrong.  Can someone give me some
> advise on how to optimize this pipeline?  Note: my eventual goal, is
> to include captions.

Considering your pipeline, your problem is most likely that downstream
of the Decklink sources can't handle the data in real-time. For example
the conversion from v210 to NV12 for nvh264enc might be too expensive
to run on a single core on your machine.

-- 
Sebastian Dröge, Centricular Ltd · https://www.centricular.com

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 963 bytes
Desc: This is a digitally signed message part
URL: <https://lists.freedesktop.org/archives/gstreamer-devel/attachments/20190408/0b354f77/attachment.sig>