ChangeLog
=========
2014-02-08 Sebastian Dröge <[email protected]>
* configure.ac:
releasing 1.2.3
2014-01-24 19:19:08 +0100 Arnaud Vrac <[email protected]>
* plugins/elements/gstmultiqueue.c:
multiqueue: do not reduce single queue below current level
When the single queue size was just bumped by 1 to allow more buffers
to
be added, the buffers limit could be reduced to the current level when
setting the max-size-buffers property. This would result in a stall
since the queue would not grow anymore at this point.
Prevent this by not reducing a single queue size below the current
number of buffers + 1.
https://bugzilla.gnome.org/show_bug.cgi?id=712597
2014-02-04 16:20:08 +0100 Sebastian Dröge <[email protected]>
* po/id.po:
* po/nl.po:
* po/pt_BR.po:
* po/sk.po:
* po/sr.po:
po: Update translations
2014-01-17 22:53:01 -0300 Thiago Santos <[email protected]>
* gst/gstpad.c:
pad: fix sticky event leak after sticky_events_foreach
events_foreach adds an extra ref when giving the event to the
user function. In case it was unrefed by the user, this extra ref
disappeared, but events_foreach still should unref again to
lose its own ref before removing the event from the array.
https://bugzilla.gnome.org/show_bug.cgi?id=722467
2014-01-15 00:12:26 -0300 Thiago Santos <[email protected]>
* plugins/elements/gstmultiqueue.c:
multiqueue: prevent buffering forever with playbin
When prerolling/buffering, multiqueue has its buffers limit set
to 0, this means it can take an infinite amount of buffers.
When prerolling/buffering finishes, its limit is set back to 5, but
only if the current level is lower than 5. It should (almost) never be
and this will cause prerolling/buffering to need to wait to reach the
hard bytes and time limits, which are much higher.
This can lead to a very long startup time. This patch fixes this
by setting the single queues to the max(current, new_value) instead
of simply ignoring the new value and letting it as infinite(0)
https://bugzilla.gnome.org/show_bug.cgi?id=712597
2014-01-15 11:12:08 +0100 Sebastian Dröge <[email protected]>
* gst/gstsegment.c:
segment: gst_segment_offset_running_time() will be available in 1.2.3
2014-01-08 15:47:10 +0100 Wim Taymans <[email protected]>
* tests/check/gst/gstsegment.c:
tests: improve check, also check stream-time
2014-01-08 15:31:28 +0100 Wim Taymans <[email protected]>
* tests/check/gst/gstsegment.c:
tests: add unit test for segment _offset_running_time()
Add a unit test to check that positive and negative offsets are
applied
correctly in various cases.
2014-01-08 14:57:04 +0100 Wim Taymans <[email protected]>
* gst/gstpad.c:
pad: use new segment offset method to apply the offset
Fixes https://bugzilla.gnome.org/show_bug.cgi?id=721422
2014-01-08 14:54:47 +0100 Wim Taymans <[email protected]>
* gst/gstsegment.c:
* gst/gstsegment.h:
* win32/common/libgstreamer.def:
segment: add method to offset the segment running-time
Add a method that can apply an offset to the calculated running-time
of
a segment.
2014-01-08 16:28:54 -0300 Thiago Santos <[email protected]>
* libs/gst/base/gstbaseparse.c:
baseparse: do not ignore TIME segments
TIME segments are being ignored and a standard initialized
segment is used instead. This causes issues as not properly detecting
reverse playback or not cliping output based on the segment.
This seems to be a regression from one of the GstSegment/GstEvent
redesigns on the 0.10 -> 1.0 transition
2014-01-08 15:23:00 +0100 Wim Taymans <[email protected]>
* gst/gstsegment.c:
segment: take offset into account in _to_position()
Take the offset into account when converting between running-time and
segment positions.
2014-01-08 14:52:04 +0100 Wim Taymans <[email protected]>
* libs/gst/base/gstcollectpads.c:
collectpads: take offset into account for expected segment position
The firt valid segment position is start + offset.
Also add some more debug and a FIXME
2014-01-13 08:37:37 -0300 Thiago Santos <[email protected]>
* tests/check/libs/baseparse.c:
tests: baseparse: add test for reverse playback on passthrough
Baseparse stores buffers for reverse playback to push on the next
DISCONT, the issue was that it wouldn't ever check for a discont
on passthrough mode as it skips all real parsing. This test
was create to verify this issue and prevent it from happening again
https://bugzilla.gnome.org/show_bug.cgi?id=721941
2014-01-11 10:49:17 -0300 Thiago Santos <[email protected]>
* tests/check/Makefile.am:
* tests/check/libs/.gitignore:
* tests/check/libs/baseparse.c:
tests: baseparse: add basic test for baseparse
Just a small test to check that basic playback works
2014-01-10 09:10:06 -0300 Thiago Santos <[email protected]>
* libs/gst/base/gstbaseparse.c:
baseparse: do not accumulate buffers on passthrough mode
If on passthrough during reverse playback, do not accumulate buffers
as
baseparse will never check for DISCONT flag to push those buffers.
So just push buffers downstream as if it was forward playback.
https://bugzilla.gnome.org/show_bug.cgi?id=721941
2014-01-02 16:22:37 -0300 Thiago Santos <[email protected]>
* libs/gst/base/gstbaseparse.c:
baseparse: remove pending_segment as it was being misused
It wasn't required, instead baseparse was using it to check the media
caps to identify if it was handling audio or video.
The pending_segment was removed and a checked_media boolean
replaced it for a more accurate naming.
https://bugzilla.gnome.org/show_bug.cgi?id=721350
2014-01-02 13:43:54 -0300 Thiago Santos <[email protected]>
* libs/gst/base/gstbaseparse.c:
baseparse: push pending events before GAP event
A GAP event is handled as an empty buffer by sinks and they expect
to receive start up events before GAP events (like a segment).
This is important specially if there is a GAP at the beginning of
a stream (before any buffers) so that the segment event can be
pushed downstream before the GAP
https://bugzilla.gnome.org/show_bug.cgi?id=721350
2014-01-02 13:41:25 -0300 Thiago Santos <[email protected]>
* libs/gst/base/gstbaseparse.c:
baseparse: refactor pending events pushing
Refactor code repeated 3 times to a common function
https://bugzilla.gnome.org/show_bug.cgi?id=721350
2013-12-04 00:10:36 +0100 Sebastian Rasmussen <[email protected]>
* docs/Makefile.am:
* docs/design/Makefile.am:
docs: add missing files for distribution
* add some documentation files in docs/design
* add docs/list-ulink.xsl so check in docs/manual works
Fixes https://bugzilla.gnome.org/show_bug.cgi?id=719814
2014-01-03 11:47:23 +0800 YanpingZhang <[email protected]>
* plugins/elements/gstmultiqueue.c:
multiqueue: Fix hanging if shut down while handling a serialized query
https://bugzilla.gnome.org/show_bug.cgi?id=721253
2014-01-02 13:34:52 +0100 Sebastian Dröge <[email protected]>
* tests/check/gst/gstpad.c:
pad: Add unit test for adding/removing blocking probes while a pad is
blocked
And make sure that these new probes are actually called if they should
instead of silently blocking the pad forever.
https://bugzilla.gnome.org/show_bug.cgi?id=721289
2014-01-02 13:33:20 +0100 Sebastian Dröge <[email protected]>
* gst/gstpad.c:
pad: Check if new probes need to be called when adding/removing some
This allows blocking a pad, add a new blocking probe, removing
the first probe and then having the second probe called. Which
could then decide that data-flow should actually continue
instead of blocking now.
https://bugzilla.gnome.org/show_bug.cgi?id=721289
2014-01-02 11:13:27 +0100 Sebastian Dröge <[email protected]>
* plugins/elements/gsttee.c:
* plugins/elements/gsttee.h:
tee: Remove dyn lock
It was used for pad-alloc in 0.10 but currently is completely unused
and not necessary. All pad access is protected by the tee object lock
and keeping another reference to the current pad.
2014-01-02 11:09:59 +0100 Sebastian Dröge <[email protected]>
* plugins/elements/gsttee.c:
tee: Keep another ref to our one and only srcpad around while pushing
A pad probe on that pad might otherwise just release the pad, drop
the last reference and cause great misery.
https://bugzilla.gnome.org/show_bug.cgi?id=721300
2013-12-30 19:03:22 +0100 Sebastian Dröge <[email protected]>
* gst/gstpad.c:
pad: Keep an extra ref of the pad when calling an IDLE probe
immediately
The callback might destroy the pad.
2013-12-30 18:44:24 +0100 Sebastian Dröge <[email protected]>
* gst/gstpad.c:
pad: Only call IDLE probes if we are actually idle
Also only check the data types for non-IDLE probes. When we
are idle, we have no data type obviously.
Previously we were calling IDLE probes during data flow whenever
a non-blocking probe would be called. The pad was usually not idle
at that time.
2013-12-30 10:01:39 +0100 Sebastian Dröge <[email protected]>
* gst/gstpad.c:
pad: Don't ignore probe callback return value when immediately
calling IDLE probe
https://bugzilla.gnome.org/show_bug.cgi?id=721096
2013-12-29 14:06:55 +0000 Pedro Côrte-Real <[email protected]>
* scripts/git-update.sh:
scripts: git-update.sh: fix for non-master branches
Pull from tracking branch instead of origin/master, so
that this works with e.g. 1.2 as well.
Download
========
https://download.gnome.org/sources/gstreamer/1.2/gstreamer-1.2.3.tar.xz (3.07M)
sha256sum: 0f9a9817a384b3448c368c23345e5122435caef9c00f1c40d7b1953827b0d8eb
_______________________________________________
[email protected]
https://mail.gnome.org/mailman/listinfo/release-team
Release-team lurker? Do NOT participate in discussions.
