Collect buffers to send out in buffer lists instead of
pushing out single buffers one at a time. For HD video
each frame might easily add up to a couple of thousand
packets, multiply that by the frame rate and that's a
lot of push() and sendmsg() calls per second.
A good reason to push out buffers as early as possible is
latency, so we don't accumulate the whole frame in a single
buffer list, but instead push it out in a few chunks, which
is hopefully a reasonable compromise.
Make sure that if AYUV is received it will detect that it can produce
both RGB and YUV formats
Signed-off-by: Ravi Kiran K N <ravi.kiran@samsung.com>
https://bugzilla.gnome.org/show_bug.cgi?id=725248
Probe supported formats in order of desirability rather than in
what order they may happen to be in the formats bitmask. Fixes
accidentally exposure of 8-bit formats in caps before 16-bit formats
(in case where U16 was not supported S8 might be listed before S16).
https://bugzilla.gnome.org/show_bug.cgi?id=706884
The code would previously crash trying to insert a NULL string
into a hash table.
It does seem a little broken that indexing is done by MIME type
and not by index though, unless the spec says there cannot be
two parts with the same MIME type.
https://bugzilla.gnome.org/show_bug.cgi?id=659573
This event was not sent. Send it before caps, this requires the pad to
be parented. This removes warning like: "Got data flow before
stream-start event".
Fixes https://bugzilla.gnome.org/show_bug.cgi?id=731475
If the wav header contains an extended chunk, we want to keep
the codec_data field, but not for raw audio.
This fixes some elements (such as adder) from failing to intersect
raw audio caps which would otherwise be intersectable.
This is required as during preroll we pass the first buffer twice, hence already
queued. It is also useful, to allow filters replaying a previous rendered buffers.
This will require 1 more buffer in sink if last-sample is enabled, since the last
sample will not be the same as the currently queued buffer.
https://bugzilla.gnome.org/show_bug.cgi?id=722303
For output device, we where queuing all the buffers, and then we would
dequeue one. This means we only have 1 buffer for the pipeline, no matter
the size of the queue. Instead, start dequeued when min_latency is reached.
Eventually, this the min_latency should also be affected by control
MIN_BUFFERS_FOR_OUTPUT (use by encoders).
Calculation of num_buffers (the max latency in buffers) was
up-side-down. If we can allcoate, then our maximum latency match
pool maximum number of buffers. Also renamed it to max latency. Finally
introduced a min_latency for clarity.
Fix the choice of min/max, don't override the min/max with own pool selected
size, correct other_pool is_active check, start from other_pool config when
configuring the other pool and finally validate the configuration.
