[Bug 747414] basesrc: Enable pushing frames from OS thread

[GStreamer (GNOME Bugzilla)]

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

--- Comment #2 from Ilya Konstantinov <ilya.konstantinov at gmail.com> ---
(In reply to Sebastian Dröge (slomo) from comment #1)
> So in your case, which thread would be responsible for all the other things
> that the basesrc task does?

I'm not fully aware of all other GstBaseSrc responsibilities.

Judging from existing implementations which afford blocking in 'create' for:
 a) data
 b) unlock
I'd judge that there's not much ongoing in GstBaseSrc that's not a reaction to
incoming data.

If there is something (e.g. independent timer), there's still the good old
GstTask.  If what I say is true - that GstBaseSrc loses its "independence"
until 'unlock' — the GstTask could be, in fact, restarted by 'unlock'.

> (In reply to Ilya Konstantinov from comment #0)
> > The rationale -- "solving" this with a GAsyncQueue has two problems:
> >  - with a small queue, latency, perf will suffer due to blocking on kernel
> > lock
> 
> How is that different from blocking the thread directly that gave us data?
> I.e. what you propose

It's not different, but it's in addition. Obviously the OS framework is
implemented using similar primitives, e.g. it'll submit N memory blocks to the
kernel for reading, and wait for completion. (There can be other methods, but
all of them involve potential yielding to the scheduler.)

In typical Linux elements (e.g. v4l), the GStreamer component performs the role
of the OS framework — beneath it, only the kernel handling ISRs, marking the
I/O requests as completed and scheduling a thread. In a typical OS X element,
the OS framework thread is already paying the cost of being at the scheduler's
mercy. There's no reason to pay the cost twice. (For the record, I think the
cost is in scheduling, not in context switching per-se.)

As a silly thought exercise, ask yourself whether you'd fling the buffer
between 10 more threads for no reason whatsoever, and how that will affect
performance and latency.

For fear of stating the obvious, this is true for RTC where late buffers are of
no value. For pipelines where late buffers can be of value, one can easily add
a GstQueue.

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