It is often usefull to make sure that you get a full copy of a profile.
For example you want to let the user modify it in the user interface
but still keep an unchanged version for later use.
API:
gst_encoding_profile_copy
Initialize min and max _get_property() to gets rid of these
compiler warnings:
gstappsrc.c:741:7: error: 'max' may be used uninitialized in this function
g_value_set_int64 (value, max);
^
gstappsrc.c:733:7: error: 'min' may be used uninitialized in this function
g_value_set_int64 (value, min);
^
Which happens because gcc doesn't know that GST_IS_APP_SRC will never
fail here.
https://bugzilla.gnome.org/show_bug.cgi?id=752052
This way special characters such as '@' can be used in
usernames or passwords, e.g.
rtsp://view:%40dm%4An@<IP-ADDR>/media/camera1
will now parse username and password into:
User: view
Pass: @dm:n
https://bugzilla.gnome.org/show_bug.cgi?id=758389
When parsing NUL-terminated strings, do not include the terminating
NUL byte(s). Depending on the encoding used, either g_utf8_validate()
failed due to this, or worse the call to g_utf16_to_utf8() would
return 0 items read on an empty string, causing it to fail parsing
certain frames.
https://bugzilla.gnome.org/show_bug.cgi?id=770355
encoding-profile.c: In function ‘get_profile_format_from_possible_factory_name’:
encoding-profile.c:1532:6: error: ‘fact’ may be used uninitialized in this function [-Werror=maybe-uninitialized]
if (fact)
^
encoding-profile.c: In function ‘profile_from_string’:
encoding-profile.c:1720:6: error: ‘res’ may be used uninitialized in this function [-Werror=maybe-uninitialized]
if (profile)
^
cc1: all warnings being treated as errors
Instead of enforcing the user to know and understand caps to describe
the encoding format, let him use element factory names directly.
This also makes it possible to ensure that a specific encodore/muxer
is used instead of letting the ranking system do it.
It is now possible to describe an encoding format simply specifying:
matroskamux:x264enc:vobisenc
Factor out functions in the parsing, cleaning up the whole thing.
Update documentation.
We used to only care about the name of the files even if the name
is defined in the encoding target serialized file.
That commit also allows user to define several names for a single
target file (using a ';' between the names) which allows us to have
a target for youtube that is called 'youtube;yt' or a target for
'ogg;ogv;oga' file extension.
We checked this already earlier, so this is dead code.
Leave an assert in place for consistency with the other
branch and in case the rest of the code changes.
CID 1397350.
The caps put into the stream topology by decodebin are the caps at the
moment the pads are exposed on it. This is usually before decoders
received any buffers.
In discoverer we however wait for pre-roll, which ensures that each
decoder handled buffers already. At this point, there might be more
information known about the caps already that we could make use of.
One example here is extra information stored in the SEI of H264, like
the multiview-mode. This will be known if there is a SEI before the
first keyframe, but decodebin won't put this into the topology as it
only waits for the initial caps of h264parse (which come directly after
SPS/PPS).
With this change, the multiview-mode is in the caps reported by
discoverer in many cases.
To make the structs usable in bindings, and fix
gstrtspmessage.c:1188: Warning: GstRtsp:
gst_rtsp_message_parse_auth_credentials: return value: Invalid
non-constant return of bare structure or union; register as
boxed type or (skip)
https://bugzilla.gnome.org/show_bug.cgi?id=774416
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.
The _pull_sample() and _pull_preroll() functions block
until a sample is available, EOS happens or the pipeline
is shut down (returning NULL in the last two cases).
This adds _try_pull_sample() and _try_pull_preroll()
functions with a timeout argument to specify the maximum
amount of time to wait for a new sample.
To avoid code duplication, wait forever if the timeout is
GST_CLOCK_TIME_NONE and use that to implement
_pull_sample/_pull_preroll with the original behavior.
Add also corresponding action signals "try-pull-sample"
and "try-pull-preroll".
https://bugzilla.gnome.org/show_bug.cgi?id=768852
Remove unnecessary helper struct for callbacks. The bclass
member of the helper struct was not used, so we can just
remove it and the GET_CLASS() call and simplify the whole
affair by passing the depayloader directly to the callback.
parsed, framed, stream-format and alignment are only relevant for parsers and
should not matter here. We still want to be able to use an encoder that can
only output byte-stream if the input was avc.
https://bugzilla.gnome.org/show_bug.cgi?id=768566
Caps are cleaned up for missing plugins, and for creating encoding profiles
and caps descriptions.
Fields like streamheader, parsed, framed, stream-format and alignment are not
relevant here. The last ones all because a parser will take care of them.
https://bugzilla.gnome.org/show_bug.cgi?id=768566
We need to take into account the input segment flags to know whether
we should drain the decoder after a new keyframe in trick mode.
Otherwise we would have to wait for the next frame to be outputted (and
the segment to be activated) which ... well ... kind of beats the whole
point of this draining :)
