This adds support for various compressed formats (AC3, E-AC3, DTS and
MP3) payloaded in IEC 61937 format (used for transmission over S/PDIF,
HDMI and Bluetooth).
The acceptcaps() function allows bins to probe for what formats the sink
being connected to support. This only works after the element is set to
at least READY.
If the underlying sink changes and the format we are streaming is not
available, we emit a message that will allow upstream elements/bins to
block and renegotiate a new format.
This exposes the source output index of the record stream that we open
so that clients can use this with the introspection if they want (to
move the stream, for example).
We need to keep the lock held because we don't want a push before the "new-ssrc-pad"
handler has completed. But we may want to push an event from inside that handler, hence
the recursive mutex.
https://bugzilla.gnome.org/show_bug.cgi?id=650916
gstavidemux.c: In function 'gst_avi_demux_parse_stream':
gstavidemux.c:1261:24: error: 'data' may be used uninitialized in this function [-Werror=uninitialized]
gstavidemux.c:1204:11: note: 'data' was declared here
Some h264 payloaders are unfortunately buggy and don't correctly set the
E bit in FU-A NAL when they have ended. Work around this by assuming
such a fragmentation unit has ended when there was no packet loss and a
new NAL is started
Use the more specialized type for the bufferpool.
Use the size from the driver as the size of the image to read.
Don't configure the pool when created. This will be done in the setup_allocation
method later or by upstream for sinks.
Remove unused properties and variables. Bufferpool sizes are now configured in
the bufferpool by the elements in the pipeline. We might want to influence the
pool size later somehow.
When pushing out buffers over S/PDIF or HDMI, IEC 61937 payloading
requires each buffer to contain 6 blocks from each substream. This adds
code to collect all the frames needed to meet this requirement before
pushing out a buffer.
https://bugzilla.gnome.org/show_bug.cgi?id=650313
Using the current RTCP interval to timeout SSRC collision can lead to
collisions being timed out immediately if a BYE packet is sent because
it is sent immediately, so the interval is 0. This is not what we
want. So just set a static 10 times the default RTCP interval, it
should be enough
https://bugzilla.gnome.org/show_bug.cgi?id=648642
Prefer to always use the default bufferpool queue for the _acquire function
because it properly supports unblocking when setting inactive etc. As a result,
we need to dequeue buffers and put them back in the bufferpool queue when we
have queued all buffers in the sink.
Rename some variables to more meaningfull names to avoid a problem with
freeing the wrong amount of buffers.
Remove old method, use neww _process method for the sink.
Inform the parent bufferpool class about the settings too. This is needed to let
it know about the max-buffers.
Allocate the negotiated max-buffers and initially mmap min-buffers. The idea is
that the bufferpool will allocate more when needed.
Improve debugging.
Only poll in capture mode, it does not seem to work in playback mode on this
beagleboard.
