ChangeLog
=========
2014-11-06 Sebastian Dröge <[email protected]>
* configure.ac:
releasing 1.4.4
2014-11-06 09:39:08 +0000 Tim-Philipp Müller <[email protected]>
* tests/check/Makefile.am:
tests: dist header file needed for ABI checks on powerpc32
Fixes 'make check' on debian powerpc32 buildbot:
libs/libsabi.c:95:26: fatal error: struct_ppc32.h: No such file or
directory
2014-10-01 15:04:09 -0700 Aleix Conchillo Flaqué <[email protected]>
* gst-libs/gst/rtsp/gstrtspconnection.c:
rtspconnection: call watch notify before freeing any watch resources
This gives control to the notify function allowing it to finish other
watch related functionality.
https://bugzilla.gnome.org/show_bug.cgi?id=737752
2014-10-20 15:31:29 +0200 Sebastian Dröge <[email protected]>
* gst-libs/gst/app/gstappsink.c:
appsink: Fix gst_app_sink_pull() docs to transfer full for the return
value
Also we get a GstSample, not a GstBuffer here.
2014-10-13 22:24:31 -0300 Thiago Santos <[email protected]>
* gst-libs/gst/audio/gstaudiodecoder.c:
audiodecoder: should post DECODE errors and not ENCODE
Fix error code for audio decoder
2014-10-10 12:14:17 +0300 Heinrich Fink <[email protected]>
* gst/playback/gstplaysink.c:
playsink: Use correct property enum value for video-filter property
installation
2014-10-07 12:10:42 +0400 Andrei Sarakeev <[email protected]>
* gst/playback/gstdecodebin2.c:
decodebin: Only emit the drain signal for the main decode chain, not
any subchains
https://bugzilla.gnome.org/show_bug.cgi?id=738064
2014-10-04 23:09:19 +0300 Sebastian Dröge <[email protected]>
* gst-libs/gst/video/gstvideoencoder.c:
videoencoder: Stop storing if we received EOS
This was never reset when going from PAUSED->READY and resulted
in encoders being not reusable after EOS. They just rejected any
buffer because they received EOS in their previous life.
The flag wasn't used anywhere except for rejecting buffers after
EOS, and this is now handled by GstPad directly.
2014-10-02 00:14:03 +0200 Aurélien Zanelli <[email protected]>
* ext/vorbis/gstvorbisdeclib.c:
vorbisdec: don't reorder streams with channels count greater than
eight
vorbis_reorder_map is defined for eight channels max. If we have more
than eight channels, it's the application which shall define the
order.
Since we set audio position to none, we just interleave all the
channels
without any particular reordering.
https://bugzilla.gnome.org/show_bug.cgi?id=737742
2014-10-01 11:16:30 +0200 Aurélien Zanelli <[email protected]>
* gst-libs/gst/video/gstvideoencoder.c:
videoencoder: release frame in finish_frame when no output state is
configured
Otherwise, frame is leaked.
https://bugzilla.gnome.org/show_bug.cgi?id=737706
2014-09-23 14:14:36 -0300 Thiago Santos <[email protected]>
* gst-libs/gst/audio/gstaudiosink.c:
audiosink: compensate for segment restart with clock's time_offset
When playing chained data the audio ringbuffer is released and
then acquired again. This makes it reset the segbase/segdone
variables, but the next sample will be scheduled to play in
the next position (right after the sample from the previous media)
and, as the segdone is at 0, the audiosink will wait the duration
of this previous media before it can write and play the new data.
What happens is this:
pointer at 0, write to 698-1564, diff 698, segtotal 20, segsize 1764,
base 0
it will have to wait the length of 698 samples before being able to
write.
In a regular sample playback it looks like:
pointer at 677, write to 696-1052, diff 19, segtotal 20, segsize
1764, base 0
In this case it will write to the next available position and it
doesn't need to wait or fill with silence.
This solution is borrowed from pulsesink that resets the clock to
start again from 0, which makes it reset the time_offset to the time
of the last played sample. This is used to correct the place of
writing in the ringbuffer to the new start (0 again)
https://bugzilla.gnome.org/show_bug.cgi?id=737055
Download
========
https://download.gnome.org/sources/gst-plugins-base/1.4/gst-plugins-base-1.4.4.tar.xz
(2.51M)
sha256sum: 49cd9e8f23c416b1607b43837a09833fa03e0106929d81ead2ddfde6c0ade44b
_______________________________________________
[email protected]
https://mail.gnome.org/mailman/listinfo/release-team
Release-team lurker? Do NOT participate in discussions.
