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
In order for 1.x and 1.(x+1) versions to not invade on each other
we need to have different lib versions.
So we need a consistent and predictable scheme:
library version number = MINOR * 100 + MICRO
Ex:
1.0.0 => 0 (duh)
1.0.3 => 3
1.1.0 => 100
1.1.1 => 101
1.2.0 => 120
1.10.5 => 1005
When the input buffers for a stream don't have a duration set,
timestamp_end might still be GST_CLOCK_TIME_NONE. When advancing
EOSed streams via GAP events (with other streams not yet EOS), we
would then use the invalid timestamp_end to calculate the duration
of the gap. This in turn would make baseaudiosink abort, because it
would try to allocate memory for a trizillion samples.
So if buffers don't have a duration set, assume a duration of
one second for stream catch-up purposes, just so we can still
continue to catch up in those cases. And make sure that
timestamp_end is valid before doing calculations with it.
http://bugzilla.gnome.org/show_bug.cgi?id=678530
And only return the proportion. The earliest time already can be
retrieved from get_max_decode_time() and by renaming we allow this
to be more extensible in the future.
Add a getter for the QoS proportion and earliest_time to help
subclasses do better estimations based on the proportion.
API: gst_video_decoder_get_qos_info()
https://bugzilla.gnome.org/show_bug.cgi?id=687991
