ChangeLog
=========
2016-04-20 Sebastian Dröge <sl...@coaxion.net>
* configure.ac:
releasing 1.8.1
2016-04-20 15:29:15 +0300 Sebastian Dröge <sebast...@centricular.com>
* po/da.po:
po: Update translations
2016-04-20 11:46:19 +0300 Sebastian Dröge <sebast...@centricular.com>
* libs/gst/base/gstbaseparse.c:
baseparse: Remember if we interpolated DTS from PTS and refresh it
whenever we update the PTS
Otherwise PTS and DTS will come out of sync if upstream continues to
provide
PTS and not DTS, and we have to skip some data from the stream or PTS
are not
exactly increasing with the duration of each packet.
https://bugzilla.gnome.org/show_bug.cgi?id=765260
2016-04-14 11:54:32 +0200 Carlos Rafael Giani <d...@pseudoterminal.org>
* plugins/elements/gstmultiqueue.c:
* tests/check/elements/multiqueue.c:
multiqueue: Recheck buffering status after changing low threshold
https://bugzilla.gnome.org/show_bug.cgi?id=763757
2016-04-14 00:09:44 +0200 Carlos Rafael Giani <d...@pseudoterminal.org>
* plugins/elements/gstmultiqueue.c:
* tests/check/elements/multiqueue.c:
multiqueue: Recalculate fill level after changing high-threshold
This ensures the following special case is handled properly:
1. Queue is empty
2. Data is pushed, fill level is below the current high-threshold
3. high-threshold is set to a level that is below the current fill
level
Since mq->percent wasn't being recalculated in step #3 properly, this
caused the multiqueue to switch off its buffering state when new data
is
pushed in, and never post a 100% buffering message. The application
will
have received a <100% buffering message from step #2, but will never
see
100%.
Fix this by recalculating the current fill level percentage during
high-threshold property changes in the same manner as it is done when
use-buffering is modified.
https://bugzilla.gnome.org/show_bug.cgi?id=763757
2016-04-15 13:50:30 +0300 Sebastian Dröge <sebast...@centricular.com>
* libs/gst/base/gstbaseparse.c:
baseparse: When initializing DTS from PTS, remember that we did so
If we don't store the value in prev_dts, we would over and over again
initialize the DTS from the last known upstream PTS. If upstream only
provides
PTS every now and then, then this causes DTS to be rather static.
For example in adaptive streaming scenarios this means that all
buffers in a
fragment will have exactly the same DTS while the PTS is properly
updated. As
our queues are now preferring to do buffer fill level calculations on
DTS,
this is causing huge problems there.
See https://bugzilla.gnome.org/show_bug.cgi?id=691481#c27 where this
part of
the code was introduced.
https://bugzilla.gnome.org/show_bug.cgi?id=765096
2016-03-02 17:47:33 +0100 Edward Hervey <edw...@centricular.com>
* plugins/elements/gstqueue.c:
* plugins/elements/gstqueue.h:
queue: Use full running time for level calculation
Ensures we have proper time level estimation for the cases where
the incoming buffers have PTS/DTS outside of the segment start/stop
values.
https://bugzilla.gnome.org/show_bug.cgi?id=762995
2016-01-27 11:46:06 +0100 Stian Selnes <st...@pexip.com>
* gst/gstpad.c:
pad: Fix race between gst_element_remove_pad and state change
When going from READY to NULL all element pads are deactivated. If
simultaneously the pad is being removed from the element with
gst_element_remove_pad() and the pad is unparented, there is a race
where the deactivation will assert (g_critical) if the parent is lost
at
the wrong time.
The proposed fix will check parent only once and retain it to avoid
the
race.
https://bugzilla.gnome.org/show_bug.cgi?id=761912
2016-03-25 12:05:41 +0200 Sebastian Dröge <sebast...@centricular.com>
* tests/check/elements/valve.c:
valve: Fix unit test by sending caps before buffers
Unexpected critical/warning: gstpad.c:4400:gst_pad_push_data:<'':src>
Got data flow before segment event
https://bugzilla.gnome.org/show_bug.cgi?id=763753
2016-03-16 15:13:39 +0100 Havard Graff <havard.gr...@gmail.com>
* plugins/elements/gstvalve.c:
* tests/check/elements/valve.c:
valve: don't send sticky events as a direct response to upstream
events
Also refactor the existing valve test to actually test the valve,
and not just test the EOS mechanism of a pad.
https://bugzilla.gnome.org/show_bug.cgi?id=763753
2016-03-24 11:49:44 +0200 Sebastian Dröge <sebast...@centricular.com>
* plugins/elements/gsttypefindelement.c:
typefind: Remove redundant assignment
CID 1357158
Download
========
https://download.gnome.org/sources/gstreamer/1.8/gstreamer-1.8.1.tar.xz (3.44M)
sha256sum: 5a3722fb9302dd977c17ced4240293dc777cb716dc98c8cca63d75c27e5e3107
_______________________________________________
ftp-release-list mailing list
ftp-release-list@gnome.org
https://mail.gnome.org/mailman/listinfo/ftp-release-list
