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 :)
And especially don't use the stream lock for that, as otherwise non-serialized
queries (CONVERT) will cause the stream lock to be taken and easily causes the
application to deadlock.
https://bugzilla.gnome.org/show_bug.cgi?id=768361
By default we'll wait for a certain amount of data before
attempting typefinding. However, if the stream is fairly
short, we might get EOS before we ever attempted any
typefinding, so at this point we should force typefinding
and output any pending data if we manage to detect the
type.
https://bugzilla.gnome.org//show_bug.cgi?id=768178
In 0.10 the source pad was a dynamic pad that was only added once
the type had been detected, but in 1.x it's an always source pad,
so checking whether it's still NULL won't work to detect if the
type has been detected.
Makes tagdemux error out when we get EOS but haven't managed to
identify the format of the data after the tag.
https://bugzilla.gnome.org//show_bug.cgi?id=768178
Fix problem with the line cache where it would forget the first line in
the cache in some cases.
Keep as much backlog as we have taps. This generally works better and we
could do even better by calculating the overlap in all taps.
Allocated enough lines for the line cache.
Use only half the number of taps for the interlaced lines because we
only have half the number of lines.
The pixel shift should be relative to the new output pixel size so scale
it.
Fixes: https://bugzilla.gnome.org/show_bug.cgi?id=767921
gst_buffer_copy_region() does not copy the duration if it doesn't start
with the first byte. We just skip the tag here, so the duration is still
valid.
https://bugzilla.gnome.org/show_bug.cgi?id=767791
Elements inherited from GstAudioDecoder, supporting PLC and introducing
delay produce invalid timestamps. Good example is opusdec with in-band FEC
enabled. After receiving GAP event it delays the audio concealment until
the next buffer arrives. The next buffer will have DISCONT flag set which
will make GstAudioDecoder to reset it's internal state, thus forgetting
the timestamp of GAP event. As a result the concealed audio will have the
timestamp of the next buffer (with DISCONT flag) but not the timestamp
from the event.
The serialization of double typed geographical
coordinates to DMS system supported by the exif
standards was previously truncated without need.
The previous code truncated the seconds part of
the coordinate to a fraction with denominator
equal to 1 causing a bug on the deserialization
when the test for the coordinate to be serialized
was more precise.
This patch applies a 10E6 multiplier to the numerator
equal to the denominator of the rational number.
Eg. Latitude = 89.5688643 Serialization
DMS Old code = 89/1 deg, 34/1 min, 7/1 sec
DMS New code = 89/1 deg, 34/1 min, 79114800UL/10000000UL
Deserialization
DMS Old code = 89.5686111111
DMS New code = 89.5688643
The new test tries to serialize a higher precision
coordinate.
The types of the coordinates are also guint32 instead
of gint like previously. guint32 is the type of the
fraction components in the exif.
https://bugzilla.gnome.org/show_bug.cgi?id=767537
For reverse playback it is important to handle correctly the frame sync
points, which is set when the input buffer doesn't have the DELTA_UNIT flag.
This is handled correctly when decoder is packetized, but when it is not the
frame's sync point is not copied, and the reverse playback never decodes frame
batches.
The current patch adds the buffer's flags to the Timestamp list, where the
timestamp and duration of the input buffers are hold.
There were two consecutive log messages in gst_video_decoder_decode_frame().
Given the information they provide, it is more efficient to squash them into a
single one.
The playback rate is hold in the input_segment member variable, not in the
output_segment, and the parse_gather list was never filled because of that.
This patch changes the comparison with input_segment.
The output segment is only set up after data is output, which might be far in
the future for reverse playback. Also we are here interested in the state at
the current *input* frame (which is the keyframe), not any possible output.
For reverse playback the same behaviour was already implemented in
flush_parse().
For reverse playback, chain_forward() is only used to gather frames and not
for decoding, and it is actually called by the draining logic, causing an
infinite recursion.
While it's a bit tricky to discard frames *before* decoding (because
we might not be sure which data is needed or not by the decoder), we
can discard them after decoding if they are too late anyway.
Any following basetransform based element or similar would drop the frame too.
When asked to just decode keyframe, if we got a keyframe drain out
the decoder straight away.
This avoids having to wait for the next frame and reduces delay even
more.
https://bugzilla.gnome.org/show_bug.cgi?id=767232
This ensures the decoder is properly drained out when receiving a
DISCONT buffer. The optimal way of doing this would have been to
receive a GAP event before hand but it is not always possible.
Fixes big delays with some decoders (ex gst-libav) that will not
drain out data when only decoding keyframes.
https://bugzilla.gnome.org/show_bug.cgi?id=767232
gst_buffer_copy_region() does not copy the timestamp if it doesn't start
with the first byte. We just skip the tag here, so the timestamp is still
valid.
https://bugzilla.gnome.org/show_bug.cgi?id=767173
The base class was setting the DISCONT flag before checking whether the buffer
would be in segment or not.
Fix issues with DISCONT flags not being properly propagated downstream when
decoders buffers were out of segment.
https://bugzilla.gnome.org/show_bug.cgi?id=766800
gst_video_sink_center_rect() can be called without a GstVideoSink
having been instantiated so we can't relly on the video sink
class_init function to init the category.
Fix a warning when running:
GST_CHECKS=test_video_center_rect GST_DEBUG=6 G_DEBUG=fatal_warnings make libs/video.check-norepeat
https://bugzilla.gnome.org/show_bug.cgi?id=766510
If we e.g. have AVI with DV container with video/audio inside the DV
container, we can't handle this at this point with an encoding profile.
Instead of erroring out, flatten the container hierarchy.
https://bugzilla.gnome.org/show_bug.cgi?id=765708
This tag match the EXIF_TAG_FOCAL_LENGTH_IN_35_MM_FILM exif tag and is
stored on a short. Hence there is a precision loss compared to the
GstTag which is a double value.
https://bugzilla.gnome.org/show_bug.cgi?id=753930
It is the 35 mm equivalent focal length of the lens, mainly used in
photography. Tag value is stored in a double value to be consistent with
GST_TAG_CAPTURING_FOCAL_LENGTH.
https://bugzilla.gnome.org/show_bug.cgi?id=753930
When converting discoverer output to an encoding profile, it makes sense to
omit these. It's very very unlikely that our encoder is going to produce bit
by bit the same codec_data or streamheader.
https://bugzilla.gnome.org/show_bug.cgi?id=765534
We add a couple of new functions gst_sdp_media_parse_keymgmt and
gst_sdp_media_parse_keymgmt. We also implement
gst_sdp_message_attributes_to_caps and gst_sdp_media_attributes_to_caps
in terms of these new functions and also gst_mikey_message_to_caps.
Current implementation requires all srtp and srtcp parameters to be
given in the caps. MIKEY uses only one algorithm for encryption and one
for authentication so we now allow passing srtp or srtcp parameters. If
both are given srtp parametres will be preferred.
https://bugzilla.gnome.org/show_bug.cgi?id=765027
As said in its doc GST_AUDIO_CHANNEL_POSITION_NONE is meant to be used
for "position-less channels, e.g. from a sound card that records 1024
channels; mutually exclusive with any other channel position".
But at the moment using such positions would raise a
'g_return_if_reached' warning as gst_audio_get_channel_reorder_map()
would reject it.
Fix this by preventing any attempt to reorder in such case as that's not
what we want anyway.
https://bugzilla.gnome.org/show_bug.cgi?id=763799
We currently don't log much about channel positions making debugging
harder as it should be. This is the first step in my attempt to improve
this.
https://bugzilla.gnome.org/show_bug.cgi?id=763985
There is a small window of time where the audio ringbuffer thread
can access the parent thread variable, before it's initialized
by the parent thread. The patch replaces this variable use by
g_thread_self().
https://bugzilla.gnome.org/show_bug.cgi?id=764865
Since the allocation query caps contains memory size and the pad's caps
contains the display size, an audio encoder or decoder might need to allocate
a different buffer size than the size negotiated in the caps.
This patch splits this logic distinction for audiodecoder and audioencoder.
Thus the user, if needs a different allocation caps, should set it through
gst_audio_{encoder,decoder}_set_allocation_cap() before calling the negotiate()
vmethod. Otherwise the allocation_caps will be the same as the caps in the
src pad.
https://bugzilla.gnome.org/show_bug.cgi?id=764421
Since the allocation query caps contains memory size and the pad's caps
contains the display size, a video encoder or decoder might need to allocate
a different frame size than the size negotiated in the caps.
This patch splits this logic distinction for videodecoder and videoencoder.
The user if needs a different allocation caps, should set the allocation_caps
in the GstVideoCodecState before calling negotiate() vmethod. Otherwise the
allocation_caps will be the same as the caps set in the src pad.
https://bugzilla.gnome.org/show_bug.cgi?id=764421
Doing so prevents us dropping buffers in the rare, but possible, situations,
when the stream changes SSRC and new sequence numbers does not differ
much from the last sequence number from previous SSRC. For example:
ssrc - 0xaaaa 101,102,103,104 ssrc - 0xbbbb 102, 103, 104, 105...
In the scenario above we don't want to drop the first 3 packets of
0xbbbb stream.
https://bugzilla.gnome.org/show_bug.cgi?id=764459
The function gst_discoverer_info_copy doesn't copy the data members seekable
and result of the source GstDiscovererInfo.
In the case of copying a GstDiscovererInfo for later use, the seekbale will be
undefined, which in practice usually will be false, even though the seekable of
the original GstDiscovererInfo is true.
https://bugzilla.gnome.org/show_bug.cgi?id=762710
The parameter type was wrongly documenting that a GstVideoInfo structure
pointer was needed, while it needs a GstVideoFormatInfo structure
pointer.
https://bugzilla.gnome.org/show_bug.cgi?id=764414
P010 is a YUV420 format with an interleaved U-V plane and 2-bytes per
component with the the color value stored in the 10 most significant
bits.
https://bugzilla.gnome.org/show_bug.cgi?id=761607
---
Changes since v2:
- Set bits=16 in DPTH10_10_10_HI
Changes since v1:
- Fixed x-offset calculation in uv.
- Added 6-bit shifts to FormatInfo.
Store the filter in the desired sample format so that we can simply do a
linear or cubic interpolation to get the new filter instead of having to
go through gdouble and then convert.
Remove some unused variables from the inner product functions.
Make filter coefficients by interpolating if required.
Rename some fields.
Try hard to not recalculate filters when just chaging the rate.
Add more proprties to audioresample.
Rearrange the oversampled taps in memory to make it easier to use
SIMD instructions on them. this simplifies some sse code.
Add some more optimizations
