GNOME Bugzilla – Bug 747222
vtenc: eliminate gst_video_frame_copy on iOS in non-CVPixelBuffer case
Last modified: 2018-11-03 13:33:01 UTC
In gst_vtenc_encode_frame, we do: meta = gst_buffer_get_core_media_meta (frame->input_buffer); if (meta != NULL) { pbuf = gst_core_media_buffer_get_pixel_buffer (frame->input_buffer); } #ifdef HAVE_IOS if (pbuf == NULL) { ... /* FIXME: iOS has special stride requirements that we don't know yet. * Copy into a newly allocated pixelbuffer for now. Probably makes * sense to create a buffer pool around these at some point. */ ... if (!gst_video_frame_copy (&outframe, &inframe)) { ... The gst_video_frame_copy is a performance issue. --- Case in point, in OpenWebRTC we have avfvideosrc upstream, so the pixel layout should be Apple-compatible. The need for this gst_video_frame_copy should be reevaluated.
Well, you need this copy in any case as a fallback case. But we should have some more optimal cases we try first: a) we should provide buffers from a CVPixelBufferPool upstream, so that other elements can fill that directly. And then detect those buffers and instead of copying them, directly use them b) directly use the CVPixelBuffers we get from vtdec or avfvideosrc. Those should also be detected properly, and the code you quoted there should've found them already. Not sure what is broken there. One thing that might be a problem is that we currently have two almost identical metas there. A core media meta, and a core video meta. The two should be merged, but the problem here in vtenc might be that we get the meta we do not look for :) That is, the core video meta.
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/issues/229.