This thread has been locked.
If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.
Part Number: DRA746
I'm looking for support with the following issue:
We've a use case where we want to capture the output of one of the CRTCs and feed it to an IVA-HD encoder. We've tried the following pipeline: gst-launch-1.0 -e v4l2src device=/dev/video11 io-mode=dmabuf ! video/x-raw,format=NV12 ! ducatih264enc level=51 ! queue ! h264parse ! mp4mux ! filesink location=capture.mp4 Although this pipeline works, there's an unwanted memory copy which causes a significant frame drop (~23fps when it should be ~60fps). We believe that the reason of the memory copy is due the buffers dequed from the omapwb-cap driver, when the pixel format is NV12, are not continuous in memory. However, from our understanding, the ducatih264enc GStreamer element expects them to be continuous in memory (that is, a single dmabuf-fd for both the Y and UV planes). In addition, we think that the correct pixel format for NV12 exposed by the omapwb-cap driver should be V4L2_PIX_FMT_NV12M instead of V4L2_PIX_FMT_NV12. Have TI ever managed to encode using GStreamer at 60 fps from the writeback v4l2 device? Is there any work in progress to address this? For reference, our kernel version is 4.4.0-3 and we are using GStreamer 1.11.90.
We are glad that we were able to resolve this issue, and will now proceed to close this thread.
If you have further questions related to this thread, you may click "Ask a related question" below. The newly created question will be automatically linked to this question.
In reply to Margarita Gashova:
kernel version 4.4.55
In reply to Thomas Brown:
To answer the main question - No, we haven't achieved 1080p 30fps with WB capture. This is not a tested pipeline. There is no plan as of now to support writeback pipeline.
Yes, ducati encoder expects one single fd. What puzzles me is that camera capture works at 30fps but not wb capture. From gstreamer perspective buffer management shouldn't be different in these cases. Nikhil Devshatwar Is there a difference from driver perspective.
In reply to Pooja Prajod:
In reply to Nikhil Devshatwar:
In reply to Chris Lande:
All content and materials on this site are provided "as is". TI and its respective suppliers and providers of content make no representations about the suitability of these materials for any purpose and disclaim all warranties and conditions with regard to these materials, including but not limited to all implied warranties and conditions of merchantability, fitness for a particular purpose, title and non-infringement of any third party intellectual property right. TI and its respective suppliers and providers of content make no representations about the suitability of these materials for any purpose and disclaim all warranties and conditions with respect to these materials. No license, either express or implied, by estoppel or otherwise, is granted by TI. Use of the information on this site may require a license from a third party, or a license from TI.
TI is a global semiconductor design and manufacturing company. Innovate with 100,000+ analog ICs andembedded processors, along with software, tools and the industry’s largest sales/support staff.