g_value_get_object() does not give us our own ref.
Fixes "Trying to dispose object "flacparse", but it still has a parent "registry0".
You need to let the parent manage the object instead of unreffing the object directly."
and similar warnings.
https://bugzilla.gnome.org/show_bug.cgi?id=658416
This is done by adding a capsfilter after every parser/converter that contains
all possible caps supported by downstream elements. A capsfilter is necessary
here because the decoder is only selected after the parser selected a format
and the parser can't know what downstream would support otherwise.
Sort muxers based on their caps and ranking before iterating to
find one that fits the profile.
Sorting is done by putting the elements that have a pad template
that can produce the exact caps that is on the profile. For example:
when asking for "video/quicktime, variant=iso", muxers that
have this exact caps on their pad templates will be put first on
the list than ones that have only "video/quicktime".
https://bugzilla.gnome.org/show_bug.cgi?id=651496
This reverts commit 105814e2c7.
The general consensus seems to be that we should revert this for
now. If such behaviour is desired, we should probably enable it
via a flag. And maybe use the scaletempo plugin instead.
Adds a Lanczos-derived scaling method, which is rather slow, but very
high quality. Adds a few properties that can be used to tune various
scaling properties: sharpness, sharpen, envelope, dither. Not currently
Orcified, but was designed with that in mind.
The average_period_set variable can be accessed in different threads, so
always lock it when reading. Furthermore when switching to averaging
mode we should make sure we don't have cached buffers that aren't used
in that mode. And any modeswitch will cause the latency to change, so we
should post a NewLatency message
Instead of just assuming all pads are created at the same time,
remember which ones are actually new (via ->pending_blocked_pads).
This allows the following use-case to properly work:
* Upstream starts with audio-only
* Only that pad gets data, blocks and a real audio sink is created
* Upstream laters adds a video stream
* A new pad is requested, blocks and reconfiguration kicks in in
order to add a new real video sink
Similar meaning same layer, same bitrate, and same number of channels
This fixes misdetection of (some MP3 files that have zero padding
between the ID3 tag and the MP3 stream) as H.264 video.
https://bugzilla.gnome.org/show_bug.cgi?id=656018
As encodebin doesn't connect to the queue signals, it can set
queues to silent mode to make queue not emit them.
Check https://bugzilla.gnome.org/show_bug.cgi?id=621299 for
more info on queue's silent property.
Use atomic ops on pending flags. Rename the segment_pending to
new_segment_pending. Set new_segment_pending not when we received seek, but
when we received the first upstream new_segment.
When we don't have specific {audio|video|text}-sink properties, don't
set them on playsink when reconfiguring.
If we do that, we end up setting the previous configured sink to
GST_STATE_NULL resulting in any potentially pending push being returned
with GST_FLOW_WRONG_STATE which will cause the upstream elements to
silently stop.
https://bugzilla.gnome.org/show_bug.cgi?id=655279
When we have a multi-stream (i.e. audio and video) input and the demuxer
adds/removes pads for a new stream (common in a mpeg-ts stream when the
program stream mapping is updated), the algorithm for EOS handling was
previously wrong (it would only drop the EOS of the *last* pad but would
let the EOS on the other pads go through).
The logic has only been changed a tiny bit for EOS handling resulting in:
* If there is no next group, let the EOS go through
* If there is a next group, but not all pads are drained in the active
group, drop the EOS event
* If there is a next group and all pads are drained, then the ghostpads
will be removed and the EOS event will be dropped automatically.
This allows us to make parsers accept both parsed and unparsed input
without decodebin plugging them in a loop until things blow up, ie.
without affecting applications that still use the old playbin or the
old decodebin.
(Making parsers accept parsed input is useful for later when we want
to use parsers to convert the stream-format into something the decoder
can handle. It's also much more convenient for application authors
who can plug parsers unconditionally in transcoding pipelines, for
example).
Add a flags property and two flags to allow one to disable the
conversion elements within encodebin. Doing so insists that the
uncompressed input to encodebin for the appropriate stream type is
sufficient to meet the caps requirements of the encoders, muxers and
encodebin target.
This is mostly beneficial to bypass slow caps negotiations in the
conversion elements.
Caps returned from gst_pad_peer_get_caps_reffed () may not be writable.
If they are not is should cause an assertion in gst_caps_merge (),
however, sometimes assertions are disabled in binary builds of -base and
it's safer to just be sure the caps are writable. Also, check that the
reffed caps pointer is not NULL.
The length check isn't sufficient, an source might
report the correct length, but then still fail to
read the requested number of bytes for some reason.
https://bugzilla.gnome.org/show_bug.cgi?id=652642
This is especially needed when switching between a non-sparse and sparse
video stream, see bug #537382. It also lowers the time needed for switching
between streams a bit.
Previously we checked mute_csource to determine wheter we need to premultiply
volumes and mute values. That fails as we unrefs mute_csource and set it to
NULL after. Use an extra flag instead.
make_lossless_changes() returns the same structure that we're passing (probably
to enable chaining). Instead of reusing s and making it point to s2 as well,
keep using s2. Drop the assignment which in the 2nd case is a dead one anyway.
Autoplug formatters for streams if a formatter with secondary or
higher rank is found. Formatters are autoplugged when there is no
muxer or when the muxer doesn't implement the tagsetter interface.
Currently only the first formatter found is plugged, this might
help in lots of cases, but it doesn't solve the
'lamemp3 ! xingmux ! id3mux'
case.
https://bugzilla.gnome.org/show_bug.cgi?id=649841
In particular, in audio only cases whose (estimated) metadata provides bitrate
information, the buffer-size based on such bitrate (and buffer-duration)
will be much more reasonable than queue2 default buffer-size.
For streams at low bitrates we need to set a limit in time because the limit
in bytes might not reached too late, sometimes more than 30 seconds.
This limit can only be set if upstream is seekable (see #584104)
Closes#647769
These reconfigure based on the caps and plugin in converters if
necessary. This also makes switching between compressed and raw
streams work flawlessly without loosing the states of any element
somewhere or having running time problems.
Before playbin2 would use different selectors for raw audio and
compressed audio (and the same for video) and used different
pads from playsink. This made the involved logic much more
complex and was not implemented completely in playsink, which
made it impossible to support files with a compressed and
uncompressed stream that is support by the sink.
playbin2 handles raw/non-raw streams the same now and the
decision is left to playsink, which now can also handle
caps changes from raw to non-raw and the other way around.
Fixes bug #632788.
Fixes#648548. Orc generates bad code for
gst_videoscale_orc_resample_merge_bilinear_u32, so we'll use the
slightly slower two-stage process. I'd fix Orc, but it's hard to
get excited about fixing a feature that I'm planning to deprecate
and replace.
Remove the android/ top dir
Fixe the Makefile.am to be androgenized
To build gstreamer for android we are now using androgenizer which generates the
needed Android.mk files.
Androgenizer can be found here:
http://git.collabora.co.uk/?p=user/derek/androgenizer.git
We should keep playlist/m3u8 available for normal m3u8 playlists,
which we we'll likely support some day. Also, we probably don't
want this handled like other playlists, so application/* seems
more appropriate in this case, even if it's really just a playlist.
