[Bug 796525] when gst-rtsp-server is used in conjunction with v4l2h264enc on an imx6, nobody allocates downstream buffers

[GStreamer (GNOME Bugzilla)]

https://bugzilla.gnome.org/show_bug.cgi?id=796525

Nicolas Dufresne (ndufresne) <nicolas at ndufresne.ca> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |NEEDINFO
                 CC|                            |nicolas at ndufresne.ca

--- Comment #3 from Nicolas Dufresne (ndufresne) <nicolas at ndufresne.ca> ---
(In reply to Keith Thornton from comment #0)
> using gst-rtsp-server with v4l2h264enc, the allocation query finds no
> element with a decide_allocation function so no downstream buffers are
> allocated.

The encoder does not run an allocation query. Encoded data is always pushed
using the v4l2 driver allocated buffers, dmabuf by default. Why does it matter
? Do you actually have an error or something or is this just conceptually not
what you expected ?

> example 
> ./test-launch "( v4l2src min-buffers=10

There is no min-buffers property in upstream v4l2src code. Can you explain
which modifications you are running with ?

> device=/dev/v4l/by-path/platform-captu
> re-subsystem-video-index4
> video/x-raw,format=NV12,width=1920,height=1080,framera

This pipeline is unlinked, you need a ! between v4l2src and the caps filter.

> te=60000/1001 ! v4l2h264enc ! video/x-h264,profile=baseline ! rtph264pay
> name=pay0 pt=96 )"

(In reply to Keith Thornton from comment #2)
> Similar pipelines with v4lsink or filesink work. I assume they provide the
> downstream buffer pool. I have only seen the problem up until now when using
> gst-rtsp-server. If I replace the v4l2h264enc by openh264enc without using
> dma buffers upstream I can stream, all be it with a lot of dropped frams. In
> this case I assume (but haven't checked) that openh264enc implements the
> decide_allocation and instantiates its own buffer pool.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.