Commit ff6d1a2a25 changed sample's type from
gint to gsize (and renamed it to in_samples). gsize is an unsigned long,
which means it can never be a negative value and the check making sure that
in_samples is >= 0 is never going to be false. Removing it.
CID 1338689
Move the audio quantize code from audioconvert to the audio library.
work on making an audio converter helper function similar to the video
converter.
Fold fastrandom directly into the quantizer, add some ORC code to
optimize this later.
Rename _get_default_mask() to _get_fallback_mask() to make it more
clear that the function only provides a fallback if nothing else can be
done. Also clarify this in the documentation.
API: gst_audio_channel_get_fallback_mask()
Add a TRUNCATE_RANGE flag for unpack functions to fill the least
significate bits with 0 (as did the old code). Also add functions
that don't truncate. Use the TRUNC flag in audioconvert for
backwards compatibility for now.
No need to use G_GINT64_FORMAT for potentially negative values of
GstClockTimeDiff. Since 1.6 these can be handled with GST_STIME_ARGS.
Plus it creates more readable values in the logs.
https://bugzilla.gnome.org/show_bug.cgi?id=757480
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
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
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
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
Otherwise the application might push new buffers into the queue while we're
flushing, potentially causing the GQueue data structure to become inconsistent
and causing crashes soon after.
https://bugzilla.gnome.org/show_bug.cgi?id=754597
The dependency setup does not seem to work for all systems,
causing the build to fail with:
gstrtpbaseaudiopayload.c:65:0:
fatal error: gst/audio/audio-enumtypes.h: No such file or directory
My setup:
gcc (Ubuntu 4.8.4-2ubuntu1~14.04) 4.8.4
autoconf (GNU Autoconf) 2.69
automake (GNU automake) 1.14.1
libtool (GNU libtool) 2.4.2
https://bugzilla.gnome.org/show_bug.cgi?id=754344
Before we just merged everything in pretty much random ways
ad-hoc instead of keeping state properly. In 0.10 that was
how it worked, but in 1.x the tag events sent should always
reflect the latest state and replace any previous tags.
So save the upstream (stream) tags, and save the tags set
by the decoder subclass with merge mode, and then update
the merged tags whenever either of those two changes.
This slightly changes the behaviour of gst_video_decoder_merge_tags()
in case it is called multiple times, since now any call replaces
the previously-set tags. However, it leads to much more predictable
outcomes, and also we are not aware of any subclass which sets this
multiple times and expects all the tags set to be merged.
If more complex tag merging scenarios are required, we'll have
to add a new vfunc for that or the subclass has to intercept
the upstream tags itself and send merged tags itself.
https://bugzilla.gnome.org/show_bug.cgi?id=679768
Before we just merged everything in pretty much random ways
ad-hoc instead of keeping state properly. In 0.10 that was
how it worked, but in 1.x the tag events sent should always
reflect the latest state and replace any previous tags.
So save the upstream (stream) tags, and save the tags set
by the decoder subclass with merge mode, and then update
the merged tags whenever either of those two changes.
This slightly changes the behaviour of gst_audio_decoder_merge_tags()
in case it is called multiple times, since now any call replaces
the previously-set tags. However, it leads to much more predictable
outcomes, and also we are not aware of any subclass which sets this
multiple times and expects all the tags set to be merged.
If more complex tag merging scenarios are required, we'll have
to add a new vfunc for that or the subclass has to intercept
the upstream tags itself and send merged tags itself.
https://bugzilla.gnome.org/show_bug.cgi?id=679768
Apparently I forgot how gobject works, there is no need to expose
it directly as one can call it from the parent_class pointer
This reverts commit 8a64592481.
Apparently I forgot how gobject works, there is no need to expose
it directly as one can call it from the parent_class pointer
This reverts commit ea9b6a7e3c.
Add gst_audio_decoder_set_use_default_pad_acceptcaps() to allow
subclasses to make videodecoder use the default pad acceptcaps
handling instead of resorting to the caps query that is, usually,
less efficient and unecessary
API: gst_audio_decoder_set_use_default_pad_acceptcaps
Add gst_video_decoder_set_use_default_pad_acceptcaps() to allow
subclasses to make videodecoder use the default pad acceptcaps
handling instead of resorting to the caps query that is, usually,
less efficient and unecessary
API: gst_video_decoder_set_use_default_pad_acceptcaps
Use the object lock to protect the internal segment when updating
against access from getting the stats property.
Fix a critical in gst-inspect or when retrieving the stats
before any segment has arrived by checking whether the
segment has been initted..
last_segment is only being updated in dequeue_buffer(),
which is only called from _pull_sample(). _pull_preroll()
simply re-uses an old or dummy segment while the actual
one sits and waits in the queue.
https://bugzilla.gnome.org/show_bug.cgi?id=751147
Subclasses can use it to select what queries they want to handle
and forward the rest to the default handling function.
API: gst_video_decoder_sink_query_default
https://bugzilla.gnome.org/show_bug.cgi?id=753623
Subclasses can use it to select what queries they want to handle
and forward the rest to the default handling function.
API: gst_audio_decoder_sink_query_default
https://bugzilla.gnome.org/show_bug.cgi?id=753623
The payloader didn't copy anything so far, the depayloader copied every
possible meta. Let's make it consistent and just copy all metas without
tags or with only the audio tag.
https://bugzilla.gnome.org/show_bug.cgi?id=751774
There was a confusion, six depayloaders where passing through the
timestamp while the base class was re-timestamping to running
time. This inconstancy has been unnoticed has in most use cases
the incoming segment is [0, inifnity] in which case timestamps are
the same as running time. With DTS/PTS shifting added (to avoid
negative values) and pcapparse sending a different segment this
started being an issue.
https://bugzilla.gnome.org/show_bug.cgi?id=753037
gstvideoencoder.h:228: Warning: GstVideo: "@transform_meta"
parameter unexpected at this location:
* @transform_meta: Optional. Transform the metadata on ...
