Pass the frame data and size explicitly to
id3v2_add_id3v2_frame_blob_to_taglist() and add a
comment that it's being deliberately / manually
passed the full ID3v2 frame including header.
Ensure that nothing is in any of the streaming thread functions
anymore when going from PAUSED to READY. While the parent's state change
function has deactivated all pads, there is nothing preventing
downstream from activating our srcpad again and calling the getrange()
function. Although we're in READY!
https://bugzilla.gnome.org/show_bug.cgi?id=775687
The flags and field order weren't properly initialized in the
gst_video_info_init().
Furthermore in gst_video_info_from_caps() we might set unitiliazed
values previously, this only sets them if valid.
Optimize LE<->BE conversion by adding a dedicated fast path instead of
using the generic converter. Implement transform_ip function in order to do the
endian swap in place.
This saves buffer allocation for the intermediate format, can be done in place
and also performs the conversion in one step instead of unpack-convert-pack.
For all bit widths the naive algorithm is implemented, which provides the best
performance when compiled with -O3. ORC was considered but eventually removed
as it requires a dedicated function for in-place conversion (due to the
"restrict" parameters).
A more complex algorithm for the 24-bit conversion with unrolled loop and
32-bit processing is implemented in the #if 0 section. It performs better if
compiled with -O2. With -O3 however the naive algorithm performs better.
https://bugzilla.gnome.org/show_bug.cgi?id=773073
It is not needed to store a pointer to every single chain element to free it.
Instead walk the channel list backwards and free the chain elements one by one.
Rename GstAudioConverter->chain_pack to chain_end.
https://bugzilla.gnome.org/show_bug.cgi?id=773073
The caps might not be fixated (which is required by GstVideoInfo) and we
would assert otherwise. However the caps often contain useful
information in the already-fixed parts that we can use here.
When gst_rtp_buffer_add_extension_onebyte_header() is used over a
GstRtpBuffer that only contains a memory for the whole packet,
ensure_buffers function crashes at the next point:
mem = gst_memory_copy (rtp->map[i].memory, offset, rtp->size[i]);
when i==2 because the payload is not mapped.
In addition the offset is calculated subtracting in the wrong direction.
https://bugzilla.gnome.org/show_bug.cgi?id=774959
For example mmap can fail with EACCES if the the fd has been open
with read only mode. And mapping the memory might be the only way
to check that. So no need to print out an error.
Ex: ioctl(dev, DRM_IOCTL_PRIME_HANDLE_TO_FD, flags & ~DRM_RDWR)
https://bugzilla.gnome.org/show_bug.cgi?id=765600
This class was made subclassable, though for future growth of the code,
it's better if we have some room for add class members. Using the small
padding since this is unlikely.
For drop-frame timecodes, the nsec_since_daily_jam doesn't necessarily
directly correspond to this many hours/minutes/seconds/frames. We have
to get the frame count as per frames_since_daily_jam and then convert.
https://bugzilla.gnome.org/show_bug.cgi?id=774585
Rename function parameter and make sure the name in the
declaration matches the name in the implementation, to
avoid g-i warnings. Also add Since markers for gtk-doc.
gstappsink.c:1248: Warning: GstApp: gst_app_sink_set_buffer_list_support:
unknown parameter 'buffer_list' in documentation comment, should be 'drop'
Refuse to answer BYTES queries ourselves. The only
time they make sense is on raw elementary streams,
in which case upstream would already have answered.
https://bugzilla.gnome.org/show_bug.cgi?id=757631
Refuse to answer BYTES queries ourselves. The only
time they make sense is on raw elementary streams,
in which case upstream would already have answered.
They especially don't make sense for encoders to answer
based on upstream values - although perhaps later
we could make it do TIME->BYTES conversion on the source
pad based on bitrate.
https://bugzilla.gnome.org/show_bug.cgi?id=757631
It is actually needed as we need some symbols. We do not link
to libgstsdp as the user of the lib should do it (same with
autotools build).
This reverts previous commit
gst_audio_buffer_reorder_channels() was always mapping the buffer read-write
regardless whether any reordering was needed. If the from and to channel order
is identical return immediately without remapping the buffer.
Add a small helper function gst_audio_channel_positions_equal() which is used
in both gst_audio_reorder_channels() and gst_audio_buffer_reorder_channels().
https://bugzilla.gnome.org/show_bug.cgi?id=773833
It adds a third argument to pass GstBufferPoolAcquireParams
to gst_buffer_pool_acquire_buffer.
If a user subclasses GstBufferPoolAcquireParams, this allows to
pass an updated param to the underlying buffer pool at each
gst_video_decoder_allocate_output_frame_with_params call.
https://bugzilla.gnome.org/show_bug.cgi?id=773165
Adds "memory:DMABuf" caps feature. Since 1.11 tag.
Useful when the the dma-buf buffer cannot be mapped to CPU for r/w requests.
Example: protected content or platform constraints.
https://bugzilla.gnome.org/show_bug.cgi?id=759358
Usually this information is static for the whole stream, and various
container formats store this information inside the headers for the
whole stream.
Having it inside the caps for these cases simplifies code and makes it
possible to express these requirements more explicitly with the caps.
https://bugzilla.gnome.org/show_bug.cgi?id=771376
All the GstAudioClock method declarations required object of GstClock type
as a first argument, but in fact, required GstAudioClock object (runtime
check in function body). Instead of checking type in run-time, we can
change functions declaration, to accept only GstAudioClock methods. Then,
runtime check is not necessary anymore, since always GstAudioClock object
is passed to a function.
https://bugzilla.gnome.org/show_bug.cgi?id=756628
Also the format must be fixed on the default raw caps. If not
gst_video_info_from_caps() will fail and
gst_video_decoder_negotiate_default_caps() return FALSE.
The test simulates the use case where a gap event is received before
the first buffer causing the decoder to fall back to the default caps.
https://bugzilla.gnome.org/show_bug.cgi?id=773103
Seen on the Jenkins CI:
FAILED: subprojects/gst-plugins-base/gst-libs/gst/audio/audio_resampler_sse41@sta/audio-resampler-x86-sse41.c.o
ccache cc '-Isubprojects/gst-plugins-base/gst-libs/gst/audio/audio_resampler_sse41@sta' '-fdiagnostics-color=always' '-I../subprojects/gst-plugins-base/gst-libs/gst/audio' '-Isubprojects/gst-plugins-base/gst-libs/gst/audio' '-Isubprojects/gst-plugins-base/.' '-I../subprojects/gst-plugins-base/.' '-Isubprojects/gst-plugins-base/gst-libs' '-I../subprojects/gst-plugins-base/gst-libs' '-Isubprojects/gstreamer/libs' '-I../subprojects/gstreamer/libs' '-Isubprojects/gstreamer/.' '-I../subprojects/gstreamer/.' '-pipe' '-Wall' '-Winvalid-pch' '-DHAVE_CONFIG_H' '-msse4.1' '-fPIC' '-O0' '-g' '-fPIC' '-I/usr/include/glib-2.0' '-I/usr/lib/glib-2.0/include' '-pthread' '-Isubprojects/gstreamer/gst' '-MMD' '-MQ' 'subprojects/gst-plugins-base/gst-libs/gst/audio/audio_resampler_sse41@sta/audio-resampler-x86-sse41.c.o' '-MF' 'subprojects/gst-plugins-base/gst-libs/gst/audio/audio_resampler_sse41@sta/audio-resampler-x86-sse41.c.o.d' -o 'subprojects/gst-plugins-base/gst-libs/gst/audio/audio_resampler_sse41@sta/audio-resampler-x86-sse41.c.o' -c ../subprojects/gst-plugins-base/gst-libs/gst/audio/audio-resampler-x86-sse41.c
In file included from ../subprojects/gst-plugins-base/gst-libs/gst/audio/audio-resampler.h:24:0,
from ../subprojects/gst-plugins-base/gst-libs/gst/audio/audio-resampler-private.h:23,
from ../subprojects/gst-plugins-base/gst-libs/gst/audio/audio-resampler-macros.h:25,
from ../subprojects/gst-plugins-base/gst-libs/gst/audio/audio-resampler-x86-sse41.h:23,
from ../subprojects/gst-plugins-base/gst-libs/gst/audio/audio-resampler-x86-sse41.c:24:
../subprojects/gst-plugins-base/gst-libs/gst/audio/audio.h:26:39: fatal error: gst/audio/audio-enumtypes.h: No such file or directory
#include <gst/audio/audio-enumtypes.h>
^
compilation terminated.
Workaround source_root being the root directory of all projects
in the subproject case.
Remove now unneeded getpluginsdir and define c++ tests in the same loop.
Bump meson requirement to 0.35
This makes sure that we only build files that need explicit SIMD support
with the relevant CFLAGS. This allows the rest of the code to be built
without, and specific SSE* code is only called after runtime checks for
CPU features.
https://bugzilla.gnome.org/show_bug.cgi?id=729276
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.
They are false positive overflows, because coverity doesn't realize that
hours <= 24, minutes < 60 and seconds < 60 in all functions. Also casting the
number 60 (seconds in minute, minutes in hour) to guint64 for the
calculations, in order to avoid overflowing once we allow more than 24-hour
timecodes.
CIDs #1371459, #1371458
_stdint.h is generated by Autotools and we don't really need it.
stdint.h is now available on all supported platforms.
This really only makes a difference for MSVC, which has it starting from
Visual Studio 2015.
Add GST_FD_MEMORY_FLAG_DONT_CLOSE to avoid closing the fd when the
memory is freed. When you can guarantee the lifetime of the fd is
longer than the memory, this can save a dup() call.
Most of them are overflow related and false positives, but coverity can't know
that these can't overflow without us giving it more information. Add some
assertions for this.
One was an actual issue with flags comparison.
CIDs #1369051, #1369050, #1369049, #1369048, #1369045
WAV is too generic to impose more-or-less arbitrary boundaries on the
sample rate and channel count caps. For example, there are 384 kHz WAV
files. Another example: it is in theory possible that somebody puts DSD
data into a WAV file, which will then have a sample rate of ~2.8 MHz.
For this reason, get rid of the rate and channel caps unless they are
fixed values. Downstream anyway usually knows the limitations better.
https://bugzilla.gnome.org/show_bug.cgi?id=761514
gst_rtp_buffer_add_extension_onebyte_header() and
gst_rtp_buffer_add_extension_twobytes_header() can have a const argument for
the actual extension data.
