The logic introduced by
[d50b713: decodebin: set the decode pad target before setting elements to PAUSED]
to expose pads would only ever be able to possibly expose one (the last) pad per element.
Make it so that any exposable pads are able to be exposed rather than just the
last pad returned by connect_element.
https://bugzilla.gnome.org/show_bug.cgi?id=742924
In the case of analyzing a demuxer chain, analyze_new_pad may create
a new GstDecodeChain. This was not propagated to the calling function which as
of [d50b713f decodebin: set the decode pad target before setting elements to PAUSED]
is now required to be able to expose the correct pad.
https://bugzilla.gnome.org/show_bug.cgi?id=742924
In case of reconfiguration, text_pad should be re-connected with
stream synchronizer sink pad. Otherwise we'll leave an unlinked pad around if
there always was a streamsynchronizer text pad.
https://bugzilla.gnome.org/show_bug.cgi?id=756804
If the flush-start is arrived during _eos_wait() in basesink,
the 'eos' flag is overwritten to TRUE after exiting the _eos_wait().
To resolve the overwritten issue,
the subclass doing the _eos_wait() call should return the right value.
If the eos flag is set to TRUE again, it will cause error(enter the eos flow)
of the following state changing from PAUSED to PLAYING in basesink.
https://bugzilla.gnome.org/show_bug.cgi?id=754980
Otherwise caps and context queries will disappear into nothing and therefore
fail. With autoplug-query now actually working, users (such as playbin) can
proxy these queries to the selected video sink and be able to select an
more appropriate configuration.
https://bugzilla.gnome.org/show_bug.cgi?id=731204
Encrypted RTP buffers may contain encrypted padding, hence it's
necessary to have an option to relax the validation in order to
successfully map the buffer.
When the flag GST_RTP_BUFFER_MAP_FLAG_SKIP_PADDING is set
gst_rtp_buffer_map() will map the buffer like if padding is not
present.
https://bugzilla.gnome.org/show_bug.cgi?id=752705
In case sink implements a streamvolume interface, volume element is being got
from the sink. But this is transfer full. So the memory should be freed before
setting it to NULL. This was resulting in major memory leaks
https://bugzilla.gnome.org/show_bug.cgi?id=755867
Usually these loops only run once, so there's no problem here. But sometimes
they run twice, and by adding the number of bytes to a 16 bit pointer type we
would advance twice as much as we should.
Also use snd_pcm_frames_to_bytes() in alsasrc to calculate
the number of bytes to skip, same as we do in alsasink.
Thanks to Lucio A. Hernandez <lucio.a.hernandez@gmail.com> for reporting.
When g_option_context_parse fails, context and error variables are not getting free'd
which results in memory leaks. Free'ing the same.
And replacing g_error_free with g_clear_error, which checks if the error being passed
is not NULL and sets the variable to NULL on free'ing.
https://bugzilla.gnome.org/show_bug.cgi?id=753852
Allows to run such a command line :
gst-launch-1.0 uridecodebin uri=file:///home/meh/Music/sthg.mp4 ! \
encodebin profile-string="audio/x-wav|1" ! filesink location=sthg.wav
Previously the code failed because wavenc is considered as a muxer.
We still want encodebin to audio/x-wav as an AudioEncodingProfile,
so this simple fix allows that.
Ability to mux raw streams in containers such as matroskamux
is a different issue.
https://bugzilla.gnome.org/show_bug.cgi?id=751470
intersection with a downstream that accepts any video/x-raw caps
with no further detail won't create a framerate field. If it's
not in the caps, don't fixate it, just set it to 30/1
The alsamidisrc element allows to get input event from ALSA MIDI
sequencer devices, and possibly convert them to sound using some
downstream element like fluiddec.
Fixes#738687
gir include search directories should respect PKG_CONFIG_PATH,
just like we do everywhere else. Makes g-i pick up the right
paths when using ./configure --with-pkg-config-path=
https://bugzilla.gnome.org/show_bug.cgi?id=755494
v210, UYVP and IYU1 are complex formats for which pixel stride does not really
have a meaning. If we copy width*pstride bytes per line, it's not going to do
the right thing. As a fallback, copy stride bytes per line. This might copy
uninitialized bytes at the end of each line, but at least copies the frame.
https://bugzilla.gnome.org/show_bug.cgi?id=755392
