[Bug 747270] avfvideosrc: BUFFER_QUEUE_SIZE too small

[GStreamer (GNOME Bugzilla)]

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

--- Comment #13 from Ilya Konstantinov <ilya.konstantinov at gmail.com> ---
(In reply to Nicolas Dufresne (stormer) from comment #11)
> I don't get the point, GBaseSrc does not force having queues btw, as we
> said, create can wait for an event.

The "point" I refer to was – if a queue facility is needed between the driver
and userspace, AVF is providing it. Our own queueing facility would be
redundant, as far as driver-userspace communication goes.

> The context switch has nothing to do with the performance cost I have sure.

I have a rudimentary avfvideosrc which pushes from the dispatch queue. It
(kinda, sorta) works, enough to get performance metrics.

If we can have e.g. GstAsyncQueue-based avfvideosrc having the same
performance, I'll gladly go off my proposal. I like my patches small.

(If I could lower CPU usage by 2% through a solution that doesn't exactly fit
with GstBaseSrc, I'd do it, even as a fork.)

> And to be be clear, I will not sponsor work that move this object away from
> a GstBaseSrc. It's already barely maintained, that would only make the
> situation worst.

I understand that, but do understand too that if performance would be worse
than a pure AVF solution, it'll continue to be underused and under-maintained.

> ... we force AVFoundation into doing conversion to BGRA all the time.

Are you sure? I see avfvideosrc supports NV12, UYVY, YUY and BGRA.

(In any case, my test is afvvideosrc !
video/x-raw,format=BGRA,width=1280,height=720,framerate=30/1 ! fakesink, and I
didn't notice any difference when I changed format to NV12.)

> Implement AVF specific GstMemory, make sure we don't request memory
> pointers unless map() is called

In an "avfvideosrc ! vtenc_h264" pipeline, the current code *already* passes
CVPixelBuffer directly.

About GstMemory and mapping, that's what I'm doing in bug 747216. Surprisingly,
it didn't bring much performance improvement.

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