AW: Question about integrating proprietary h264 encoders in gstreamer

[Thornton, Keith]

The downstream element doesn't have to re-queue the frame. You can allocate you're buffer with gst_buffer_new_full or gst_buffer_new_wrapped_full. In the call to these functions you can pass the address of a function which will be called when the ref count reaches 0. In this function, you can re-queue the frame.

-----Ursprüngliche Nachricht-----
Von: gstreamer-devel [mailto:gstreamer-devel-bounces at lists.freedesktop.org] Im Auftrag von Ottavio Campana
Gesendet: Dienstag, 3. Februar 2015 15:04
An: Discussion of the development of and with GStreamer
Betreff: RE: Question about integrating proprietary h264 encoders in gstreamer

Well, I'd love not to have to deal with this "monster" wrapper. In fact, my first try was to wrap the source and the encoder in two different elements, using GstBaseSrc and GstVideoEncoder classes, because this solution gives much better flexibility.

The problem that I faced was that I am having horrible performance, because I need to copy the acquired frame into a GstBuffer per passing it to the GstVideoEncoder and this makes the whole thing terribly slow.

I checked v4l2src, as far as I understand it also copies the acquired frame before re-enqueuing it in the driver, which is something I want to avoid.


My perfect solution would be a source that passes the pointer of the acquired frame to the successive elements without copying them and that re enqueues the uncompressed frame in the driver once all the processing is done. But I haven't found yet an example to do that, therefore I think it is not possible.


Ottavio




_______________________________________________
gstreamer-devel mailing list
gstreamer-devel at lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel