... so as to allow one clearly defined (absolute) positioning mode
that can cater for a variety of absolute but also relative positioning
with respect to edge or center.
The flow return values was stored in the element before because the
result had to be set from callbacks. This is not the case anymore, we
can return the flow result directly from functions, making the code
easier to understand.
https://bugzilla.gnome.org/show_bug.cgi?id=777222
The current code configures libsoup to handle redirections
transparently, without informing the caller, thus preventing the element
to record the redirect code and location uri.
Fix this by always setting the SOUP_MESSAGE_NO_REDIRECT, preventing
libsoup from handling the redirection. When we receive a redirection
request and libsoup can safely handle it, return a custom error which
triggers a retry with the new URI.
https://bugzilla.gnome.org/show_bug.cgi?id=777222
The encoder fails to initialise when we try to set GST_TAG_PREVIEW_IMAGEs
sent to use by qtdemux from iTunes-generated m4a files. We should
not just blindly translate the PREVIEW tag to file icon image types,
but check if the specific conditions required are met (i.e. image
type 1 must be a 32x32 PNG icon, and what we're getting is 500x500).
https://bugzilla.gnome.org/show_bug.cgi?id=776962
Especially don't put them into GstStructures in one way or another, just
ignore them or error out cleanly depending on the importance of their
content.
1. Need set use-default-fbo to qquickwindow during set property
to support change render target on the fly.
2. Calculate qmlglsrc refresh frame rate in qtglwindow
https://bugzilla.gnome.org/show_bug.cgi?id=774035
While computing the x and y offsets, it's the video resolution and
resized overlay resolution to be used instead of actual overlay image
resoltuion. Due to this, the overlay image used to get wrongly overlayed
in undesired location
https://bugzilla.gnome.org/show_bug.cgi?id=757292
souphttpsrc maintains two variables for the position:
* 'request_position' is where we want to be
* 'read_position' is where we are
During Normal operations both are updated in sync when data arrives. A seek
changes 'request_position' but not 'read_position'.
When the two positions get out of sync, then a new request is send and the
'Range' header is adjusted to the current 'request_position'.
Without this patch, if reading fails, then the source is destroyed. This
triggers a new request, but the range remains unchanged. As a result, the
old range is used and old data will be read.
Changing the 'read_position' to -1 makes it explicitly different from
'request_position' and as a result the 'Range' header is updated correctly.
https://bugzilla.gnome.org/show_bug.cgi?id=773509
GstAudioRingBuffer doesn't needs us to have at least 2 segments. We make
sure that if our buffer parameters are such that the maxlength is not at
least 2x fragsize, we still request the ringbuffer to keep that much
space so it continues to work.
https://bugzilla.gnome.org/show_bug.cgi?id=770446
If jackd changes the buffer size or sample rate, jackaudiosink hangs
and can't be stopped. This also happens if jack is configured as slave
and a gstreamer pipeline is started on the slave machine while the jack
master isn't running yet. If the the jack master is started it changes
the buffer size / sample rate and jackaudiosink can't be stopped.
This fix calls jack_shutdown_cb when jack_sample_rate_cb or
jack_buffer_size_cb is called.
https://bugzilla.gnome.org/show_bug.cgi?id=771272
When start qmlglsink app, it will set NULL buffer to GstQSGTexture
in which case that qt_context_ will be a random value and cause
gst_gl_context_activate() fail.
https://bugzilla.gnome.org/show_bug.cgi?id=770925
https://github.com/mesonbuild/meson
With contributions from:
Tim-Philipp Müller <tim@centricular.com>
Jussi Pakkanen <jpakkane@gmail.com> (original port)
Highlights of the features provided are:
* Faster builds on Linux (~40-50% faster)
* The ability to build with MSVC on Windows
* Generate Visual Studio project files
* Generate XCode project files
* Much faster builds on Windows (on-par with Linux)
* Seriously fast configure and building on embedded
... and many more. For more details see:
http://blog.nirbheek.in/2016/05/gstreamer-and-meson-new-hope.htmlhttp://blog.nirbheek.in/2016/07/building-and-developing-gstreamer-using.html
Building with Meson should work on both Linux and Windows, but may
need a few more tweaks on other operating systems.
https://github.com/mesonbuild/meson
With contributions from:
Tim-Philipp Müller <tim@centricular.com>
Jussi Pakkanen <jpakkane@gmail.com> (original port)
Highlights of the features provided are:
* Faster builds on Linux (~40-50% faster)
* The ability to build with MSVC on Windows
* Generate Visual Studio project files
* Generate XCode project files
* Much faster builds on Windows (on-par with Linux)
* Seriously fast configure and building on embedded
... and many more. For more details see:
http://blog.nirbheek.in/2016/05/gstreamer-and-meson-new-hope.htmlhttp://blog.nirbheek.in/2016/07/building-and-developing-gstreamer-using.html
Building with Meson should work on both Linux and Windows, but may
need a few more tweaks on other operating systems.
https://github.com/mesonbuild/meson
With contributions from:
Tim-Philipp Müller <tim@centricular.com>
Jussi Pakkanen <jpakkane@gmail.com> (original port)
Highlights of the features provided are:
* Faster builds on Linux (~40-50% faster)
* The ability to build with MSVC on Windows
* Generate Visual Studio project files
* Generate XCode project files
* Much faster builds on Windows (on-par with Linux)
* Seriously fast configure and building on embedded
... and many more. For more details see:
http://blog.nirbheek.in/2016/05/gstreamer-and-meson-new-hope.htmlhttp://blog.nirbheek.in/2016/07/building-and-developing-gstreamer-using.html
Building with Meson should work on both Linux and Windows, but may
need a few more tweaks on other operating systems.
https://github.com/mesonbuild/meson
With contributions from:
Tim-Philipp Müller <tim@centricular.com>
Jussi Pakkanen <jpakkane@gmail.com> (original port)
Highlights of the features provided are:
* Faster builds on Linux (~40-50% faster)
* The ability to build with MSVC on Windows
* Generate Visual Studio project files
* Generate XCode project files
* Much faster builds on Windows (on-par with Linux)
* Seriously fast configure and building on embedded
... and many more. For more details see:
http://blog.nirbheek.in/2016/05/gstreamer-and-meson-new-hope.htmlhttp://blog.nirbheek.in/2016/07/building-and-developing-gstreamer-using.html
Building with Meson should work on both Linux and Windows, but may
need a few more tweaks on other operating systems.
At the end of a range request, we don't want to return GST_FLOW_EOS otherwise
the last bytes we just read will be dropped by basesrc.
Instead just return GST_FLOW_OK (which was set just before) and let basesrc
handle the fact we are at the end of the segment.
If we're at the end of a range request, read again to let libsoup
finalize the request. This allows to reuse the connection again later,
otherwise we would have to cancel the message and close the connection.
We have to get rid of the message on EOS when the complete stream is read to
remember that we successfully finished handling this specific message.
Otherwise we will cancel it later and close the connection instead of reusing
it at a later time.
It might also make sense to reuse connections if a non-200 response is
received. As long as there was no connection error, the HTTP connection should
be re-usable.
There's no real reason to avoid sending QOS/NAVIGATION events upstrea.
Some elements might want to have that information.
Also remove downstream-only CAPS event handling and minimize code
Compiler would complain about include directory that didn't
exist because QPA_INCLUDE_PATH gets subst-ed regardless
(and if it didn't we'd have just an empty -I argument).
https://bugzilla.gnome.org/show_bug.cgi?id=767553
Update the blocksize depending on how much is obtained from a read
of the input stream. This avoids doing too many reads in small chunks
when larger amounts of data are available and also prevents using
a very large memory area to read a small chunk of data.
https://bugzilla.gnome.org/show_bug.cgi?id=767833
The current state of c++ ABI's on Window's and Gst's/Qt's conflicting
mingw builds means that we cannot use mingw for building the qt plugin.
Instead, a qmake .pro file is provided that is expected to be used with the
msvc binaries provided by Qt like so:
(with the PATH environment variable containing the path to the qt biniaries
and PKG_CONFIG_PATH containing the path to GStreamer modules)
cd /path/to/sources/gst-plugins-bad/ext/qt
qmake -tp vc
Then open the resulting VS project and build the library. Then
cp debug/libgstqtsink.dll /path/to/prefix/lib/gstreamer-1.0/libgstqtsink.cll
https://bugzilla.gnome.org/show_bug.cgi?id=761260
The heuristic to choose between packetise or not was changed to use the
segment format. The problem is that this change is reading the segment
during the caps event handling. The segment event will only be sent
after. That prevented the decoder to go in packetize mode, and avoid
useless parsing.
https://bugzilla.gnome.org/show_bug.cgi?id=736252
The heuristic to choose between packetise or not was change to use the
segment format. The problem is that this change is reading the segment
during the caps event handling. The segment event will only be sent
after. That prevented the decoder to go in packetize mode, and avoid
useless parsing.
https://bugzilla.gnome.org/show_bug.cgi?id=736252
Previously the segment.time was wrong, and the position was not updated
correctly, resulting in seeks in PUSH mode with upstream providing a BYTES
segment to not work at all.
https://bugzilla.gnome.org/show_bug.cgi?id=767157
This fixes seeking in DV streams where upstream operates in PUSH mode with a
TIME segment (e.g. avidemux). Without this, we would generate wrong durations
and timestamps after a seek.
https://bugzilla.gnome.org/show_bug.cgi?id=767157
When early returning in gst_soup_http_src_read_buffer() because the
element is FLUSHING, we need to unmap and unref the buffer which was just created.
https://bugzilla.gnome.org/show_bug.cgi?id=766718
Directly setting audio/x-raw caps leads to problems when the delivered
data blocks do not align properly at sample boundaries (for example, a
data block with 391 bytes). So, instead, set audio/x-unaligned-raw to
let a parser be autoplugged.
https://bugzilla.gnome.org/show_bug.cgi?id=689460
Non-blocking read will return the amount of data available without
blocking to wait for the full requested size.
The downside is that now it souphttpsrc needs to have a waiting
mechanism in case there is no data available yet to avoid busy
looping arond the inputstream.
The previous ones resulted in odd display aspect ratios and were different
from the ones used by e.g. ffmpeg. The new ones now result in display aspect
ratios of 4:3 and 16:9.
https://bugzilla.gnome.org/show_bug.cgi?id=765946
When a frame's duration is too low, calling gst_util_uint64_scale()
to scale its value can result into it being truncated to zero, which
will cause the vpx encoder to return an VPX_CODEC_INVALID_PARAM error
when trying to encode.
To prevent this from happening, we simply ignore the duration when
encoding if it becomes zero after scaling, logging a warning message.
https://bugzilla.gnome.org/show_bug.cgi?id=765391
Fix syntax errors when compiling against cerbero-provided libmpg123
headers. We do the same as the libmpg123 internal visual studio
build here.
mpg123.h(1378): error C2143: syntax error: missing ')' before '('
mpg123.h(1378): error C2081: 'ssize_t': name in formal parameter list illegal
mpg123.h(1378): error C2143: syntax error: missing ')' before '*'
mpg123.h(1378): error C2091: function returns function
mpg123.h(1378): error C2143: syntax error: missing '{' before '*'
mpg123.h(1378): error C2059: syntax error: ')'
mpg123.h(1379): error C2143: syntax error: missing ')' before '*'
mpg123.h(1379): error C2365: 'off_t': redefinition; previous definition was 'typedef'
...
This reverts commit 0dd46accf6.
With some audiosinks, starting the ringbuffer on the first commit
causes audio glitches at startup by starting to output segments
from the ringbuffer before it has been filled / fully prerolled. This
doesn't usually happen with pulsesink because we map the pulseaudio
ringbuffer directly, but we should keep things consistent with
other sinks with regards to startup latency, plus it gives more
headway to avoid glitching, should the initial 2nd segment take
more than 10ms to generate.
https://bugzilla.gnome.org/show_bug.cgi?id=657076
Remove calls to gst_pad_has_current_caps() which then go on to call
gst_pad_get_current_caps() as the caps can go to NULL in between. Instead just
use gst_pad_get_current_caps() and check for NULL.
https://bugzilla.gnome.org/show_bug.cgi?id=759539
rename gst-launch --> gst-launch-1.0
replace old elements with new elements(ffmpegcolorspace -> videoconvert, ffenc_** -> avenc_**)
fix caps in examples
https://bugzilla.gnome.org/show_bug.cgi?id=759432
The old code was using gst_caps_normalize() and was generally overly
complex. Simplify by picking sample rate and number of channels from
upstream and the sample format from the allowed caps. If the format caps
is a list of strins, just pick the first one. And if the srcpad isn't
linked yet, use the default format (S16).
https://bugzilla.gnome.org/show_bug.cgi?id=740195
It's possible that the sink element will be freed before the widget is
destroyed. When the widget was eventually destroyed, it was attempting to
access member variables of the freed sink struct which resulted in undefined
behaviour.
Fix by disconnecting our signal on finalize.
https://bugzilla.gnome.org/show_bug.cgi?id=762098
CPU waits are more expensive and are only required if the CPU is ever going to
access the data. GPU waits perform inter-context synchronisation and are cheaper
as they don't require CPU intervention.
We already pass the entire frame to the decoder. If the decoder ask for
more data, don't pass the same data again as this leads to infinit loop.
Instead, simply fail the fill function to signal the problem with that
frame. It will then be skipped properly.
https://bugzilla.gnome.org/show_bug.cgi?id=761670
All code paths for handle_frame() must somehow take ownership of the frame, be
it by actually unreffing, forwarding the frame elsewhere or storing it for
later.
http://bugzilla.gnome.org/show_bug.cgi?id=760666
We don't directly link to GL in the element, though we use GL headers.
For this reason we need to include the proper GL headers path. This
prevent this element from using a different GL header then libgstgl.
The base class is useful for having multiple backing memory types other
than the default. e.g. IOSurface, EGLImage, dmabuf?
The PBO transfer logic is now inside GstGLMemoryPBO which uses GstGLBuffer
to manage the PBO memory.
This also moves the format utility functions into their own file.
With the VPX decoders it's not simple to use downstream buffer pool,
because we don't know the image size and alignment when buffers get
allocated. We can though use GstAllocator (for downstream, or the system
allocator) to avoid a copy before pushing if downstream supports
GstVideoMeta. This would still cause a copy for sink that requires
specialized memory and does not have a GstAllocator for that, though
it will greatly improve performance for sink like glimagesink and
cluttersink. To avoid allocating for every buffer, we also use a
internal buffer pool.
https://bugzilla.gnome.org/show_bug.cgi?id=745372
The scene graph can be initialized when the we receive window handle change
notification and so we will not receive a scenegraph initialization
notification. Initialize ourself in this case.
https://bugzilla.gnome.org/show_bug.cgi?id=758337
This adds an automatic mode to the threads property of vpxdec in order to
use as many threads as there is CPU on the platform. This brings back
GStreamer VPX decoding performance closer to what is achieved by other
players, including Chromium.
https://bugzilla.gnome.org/show_bug.cgi?id=758195
When jpeg_finish_decompress is called, output state reference is being created.
But if there is any failures in finishing decompress, it jumps to setjmp,
and at that point state was not referenced. Resulting in leak of output state.
Hence adding another setjmp after output state is referenced.
Similarly adding another setjmp to unmap the frame in case error happens before
finish_decompress
https://bugzilla.gnome.org/show_bug.cgi?id=753087
There is a possibility that the _get_caps impl will be called with the
feature in the filter caps which when interecting with the template,
will return EMPTY and therefore fail negotiation.
https://bugzilla.gnome.org/show_bug.cgi?id=757854
A GstGLShader is now simply a collection of stages that are
compiled and linked together into a program. The uniform/attribute
interface has remained the same.
The problem is that the filesrc and souphttpsrc are behaving
differently regarding the calculation of the segment boundaries. The
filesrc is using a non-inclusive boundaries, while the souphttpsrc
uses inclusive. Currently the hlsdemux calculates the boundaries as
inclusive, so for this reason there is no problem with the souphttpsrc,
but there is an issue in the filesrc.
The GstSegment is non-inclusive, so the proposed solution is to use
non-inclusive boundaries in the hlsdemux in order to be consistent.
Make the change in the hlsdemux, will break the souphttpsrc, which
will expect inclusive boundaries, but the hlsdemux will offer
non-inclusive. This change makes sure that the non-inclusive
boundaries are converted to inclusive.
https://bugzilla.gnome.org/show_bug.cgi?id=748316
These allow a failed request to be retried after the given number of seconds
instead of failing the pipeline. Take account of the Retry-After header if
present. Add retries parameter that controls the number of times an HTTP
request will be retried before failing.
https://bugzilla.gnome.org/show_bug.cgi?id=756318
If soup message is not created then the same should not be passed
on, which is resulting in segfault. Hence throwing a warning message
and returning
https://bugzilla.gnome.org/show_bug.cgi?id=755326
We don't necessarily have full control over the input tags, so
it's possible that the ISRC tag contains a longer string than
expected, in which case we'd write over the end of the static-size
13 byte buffer that is FLAC__StreamMetadata_CueSheet_Track::isrc.
Make sure to only copy the ISRC if it's not too long, and make
sure the buffer we write to is always NUL-terminated by using
g_strlcpy().
CID 1324931.
In case the format changed fast and the pending format is different
than the currently set but the currently set is equal to the pending
one we could end up having mismatch between the finally set format
and the data stream format.
https://bugzilla.gnome.org/show_bug.cgi?id=755542
When passing the taglist to gst_audio_decoder_merge_tags, the reference is increased
by audiodecoder and the caller should free the taglist being passed.
https://bugzilla.gnome.org/show_bug.cgi?id=753903
Should just compare with what can be immediatelly accepted by
the element. flacenc can't renegotiate so if it has a caps already
it should only accept if it is that caps otherwise just use the
template caps
Removes the need for custom caps query handling and makes it more
correct from the beginning on the template. It is a bit uglier
to read because there is 1 entry per channel but makes code easier
to maintain.
We need to keep the active buffer (the one we have retreive a
texture id from) otherwise it's racy and upstream may upload
new content before we have rendered or during later redisplay.
