Create new GstMemory and GstAllocator base on dmabuf.
Memory is not allocated/freed by userland but mapped/unmmaped
from a dmabuf file descriptor when requested.
This allocator is included in a new lib called libgstallocators
https://bugzilla.gnome.org/show_bug.cgi?id=693826
This ensures the ghost pad will not stay in flushing mode
when it receives a flush stop event, and generally behave
badly.
This fixes at least one case of a dynamic decodebin2 + encodebin
pipeline finding a source that has not prerolled when it should
have been (due to the ghostpad staying in flushing mode).
We were setting the query-func on the sink-pad, which got overwritten when
adding the new pad to collect pads. Instead register our query-func with the
collect pads object. This fixes filter caps. Add a test for it.
DTS and PTS usually have a non-zero offset between them in MPEG-TS,
so assigning DTS to PTS is almost always wrong. The other, newer
timestamp recovery code does it correctly if we leave it as invalid.
Really really fix attribute list handling by taking a
copy of the original attributes that pango_attr_list_filter
can mutate, but keep the original around intact to restore
later.
For interlaced vertically subsampled images we need to combine alternating
chroma lines with alternating luma lines. That is line 0 and 2 are combined
with the first line of chroma samples and line 1 and 3 with the second line
of chroma samples.
See also: https://bugzilla.gnome.org/show_bug.cgi?id=588535
The root cause is that alsa-lib is not thread safe for the same handle.
There are two threads in the gstreamer accessing alsa-lib not serilized.
The race condition happens when one thread holds the old framebuffer app_ptr
position in the kernel, another thread advances the framebuffer app_ptr.
when the former thread is scheduled to run again, it overwrites the app_ptr
to old value by copying from kernel.Thus,the app_ptr in the upper
alsa-lib(pcm_rate) become one period size more advanced than the lower
alsa-lib(pcm_hw & kernel).
gstreamer uses noblock and poll method to communicate with the alsa-lib.
The app_ptr unsync situation as described above makes the poll return immediately because
it concludes there is enough space for the ring-buffer via the low-level alsa-lib.
The write function returns immediately because it concludes there is not enough
space for the ring-buffer from the upper-level alsa-lib. Then the loop of poll
and write runs again and again until another period size is available for
ring-buffer.This leads to the cpu 100 problem.
delay_lock is used to avoid the race condition.
Fixes: https://bugzilla.gnome.org/show_bug.cgi?id=690937