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
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.
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 _1_0 suffixed environment variables override the
non-suffixed ones, so if we're in an environment that
sets the _1_0 suffixed ones, such as jhbuild, we need
to set those to make sure ours actually always get
used.
We need to mark our clock as using some other clock source. Alsa source uses the
clock type to decide if it can use alsa driver timestamps or not.
Fixes https://bugzilla.gnome.org/show_bug.cgi?id=690465
Use new ringbuffer ERROR state to make all the various
threads bail out correctly when the subclass posts an
error. It's a bit iffy to communicate this properly
between the different bits of code.
https://bugzilla.gnome.org/show_bug.cgi?id=690197
In SKEW mode, use next_sample == -1 to check for the first sample
when starting to read samples so it resyncs the ringbuffer and
timestamps are ok.
Suggestion from Teemu Katajisto <teemu.katajisto@digia.com>
https://bugzilla.gnome.org/show_bug.cgi?id=648359
Add a limit to the amount of queued bytes or messages we allow on the watch.
API: GstRTSPConnection::gst_rtsp_watch_set_send_backlog()
API: GstRTSPConnection::gst_rtsp_watch_get_send_backlog()
The behaviour is sensibly changed here. Instead of purely falling when a
preset is set on the #GstEncodingProfile, we now make sure that the
element that is plugged corresponds to the one specified as preset. Then,
if we have a preset_name, we use it, if it fails, we fail (we might rather
just keep working even without setting the element properties?)
+ Add tests that it behave correctly
It was possible to decide only what #GstElement implementing #GstPreset
to use during the encoding, we can now let the user select a specific preset previously
saved using #gst_preset_save_preset specifying the name chosen when it was saved
in the gst_encoding_profile_set_preset_name.
Actually loading a preset with %NULL as a name would have always failed, so
in the current state of the API that feature is unusable
API:
gst_encoding_profile_set_preset_name
gst_encoding_profile_get_preset_name
