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.
Use (1 << 31) as the multiplier for int<->float conversions. This makes
sure that int->float conversions always end up with floats between
[-1.0, 1.0].
For the conversion from float to int, this multiplier will give the complete
int range after we perform clipping.
Change the unit test to take this into consideration.
Fixes https://bugzilla.gnome.org/show_bug.cgi?id=755301
The client-removed signal used G_INT_TYPE instead of G_SOCKET_TYPE
in its definition leading to problems on platforms where the size
of a pointer is larger than the size of an integer, It would also
not work at all with dynamic language bindings.
https://bugzilla.gnome.org/show_bug.cgi?id=757155
Rewrite audioconvert to try to make it more clear what steps are
executed during conversion.
Add passthrough step that just does a memcpy when possible.
Add ORC optimized dither and quantization functions.
Implement noise-shaping on S32 samples only and allow for arbitrary
noise shaping coefficients if we want this later.
This makes sure that they will always get SEEK events, even if we're currently
in the middle of a group switch (i.e. switching to another
representation/bitrate/etc).
https://bugzilla.gnome.org/show_bug.cgi?id=606382
As stated in GST_PAD_PROBE_HANDLED's documentation, we are
supposed to unref the event before returning.
Fixes an event leak in the validate.hls.playback.play_15s.hls_bibbop
validate scenario.
https://bugzilla.gnome.org/show_bug.cgi?id=754459
Rework the converter to use the pack/unpack functions
Because the unpack functions can only unpack to 1 format, add a separate
conversion step for doubles when the unpack function produces int.
Do conversion to S32 in the quantize function directly.
Tweak the conversion factor for doing float->int conversion slightly to
get the full range of negative samples, use clamp to make sure we don't
exceed our int range on the positive axis (see also #755301)
Send event directly to playsink instead of letting GstBin iterate
over all sink elements. The latter might send the event multiple times
in case the SEEK causes a reconfiguration of the pipeline, as can easily
happen with adaptive streaming demuxers.
What would then happen is that the iterator would be reset, we send the
event again, and on the second time it will fail in the majority of cases
because the pipeline is still being reconfigured
The logic introduced by
[d50b713: decodebin: set the decode pad target before setting elements to PAUSED]
to expose pads would only ever be able to possibly expose one (the last) pad per element.
Make it so that any exposable pads are able to be exposed rather than just the
last pad returned by connect_element.
https://bugzilla.gnome.org/show_bug.cgi?id=742924
In the case of analyzing a demuxer chain, analyze_new_pad may create
a new GstDecodeChain. This was not propagated to the calling function which as
of [d50b713f decodebin: set the decode pad target before setting elements to PAUSED]
is now required to be able to expose the correct pad.
https://bugzilla.gnome.org/show_bug.cgi?id=742924
In case of reconfiguration, text_pad should be re-connected with
stream synchronizer sink pad. Otherwise we'll leave an unlinked pad around if
there always was a streamsynchronizer text pad.
https://bugzilla.gnome.org/show_bug.cgi?id=756804
Otherwise caps and context queries will disappear into nothing and therefore
fail. With autoplug-query now actually working, users (such as playbin) can
proxy these queries to the selected video sink and be able to select an
more appropriate configuration.
https://bugzilla.gnome.org/show_bug.cgi?id=731204
In case sink implements a streamvolume interface, volume element is being got
from the sink. But this is transfer full. So the memory should be freed before
setting it to NULL. This was resulting in major memory leaks
https://bugzilla.gnome.org/show_bug.cgi?id=755867
Allows to run such a command line :
gst-launch-1.0 uridecodebin uri=file:///home/meh/Music/sthg.mp4 ! \
encodebin profile-string="audio/x-wav|1" ! filesink location=sthg.wav
Previously the code failed because wavenc is considered as a muxer.
We still want encodebin to audio/x-wav as an AudioEncodingProfile,
so this simple fix allows that.
Ability to mux raw streams in containers such as matroskamux
is a different issue.
https://bugzilla.gnome.org/show_bug.cgi?id=751470
intersection with a downstream that accepts any video/x-raw caps
with no further detail won't create a framerate field. If it's
not in the caps, don't fixate it, just set it to 30/1
Casting to gpointer from gulong generates the following warning with
64bit Windows target MinGW:
gstplaybin2.c: In function 'pad_added_cb':
gstplaybin2.c:3476:7: error: cast to pointer from integer of different size [-Werror=int-to-pointer-cast]
(gpointer) group_id_probe_handler);
^
cc1: all warnings being treated as errors
We should cast to guintptr from gulong before we cast to gpointer.
https://bugzilla.gnome.org/show_bug.cgi?id=754755
The default one will just go through the internal elements which might
just be identity when it is in passthrough which will lead to the query
being handled by the downstream sink, ignoring all that playsinkconvertbin
could actually handle and convert.
https://bugzilla.gnome.org/show_bug.cgi?id=754235
It's only relevant for each group, and by storing it in the group
we have locking and everything else like for the other buffering-related
variables. Locking looks a bit fishy still, but it was like that for a long
time already so shouldn't be worse than before.
Overview:
There are some of interleaved streams which has long-term location of audio data.
It mean the audio data is located far away more than multiqueue size.
In this case, because of multiqueue overrun, the pipeline is stopped.
To prevent hanging-like state, the decodebin needs to handle the queue size.
Caused:
The multiqueue size is not enough, the pipeline will stay being stalled status
and decodebin cannot complete to build decode chain.
In this issue file, decodebin did not receive no_more_pads signal or audio data yet.
Steps to Reproduce:
play the high-resolution(4K file) files or some streaming media(push mode).
Actual Results:
There is no audio or subtitle.
We can see only video or infinite loading.
Resolution:
Decodebin detect this problem, and add extra buffer size to multiqueue.
The multiqueue is larger than before, the next data can be pushed the downstream element.
Additional Information:
The max-preroll extra buffer size is set 8MB.
We can use total pre-roll buffer 10MB.
Only first overrun callback can handle multiqueue size.
https://bugzilla.gnome.org/show_bug.cgi?id=733235
