The only way for ALSA to expose a position-less multi channels is to
return an array full of SND_CHMAP_MONO. Converting this to a
GST_AUDIO_CHANNEL_POSITION_MONO array would be invalid as
GST_AUDIO_CHANNEL_POSITION_MONO is meant to be used only with one
channel.
Fix this by using GST_AUDIO_CHANNEL_POSITION_NONE which is meant to be
used for position-less channels.
https://bugzilla.gnome.org/show_bug.cgi?id=763799
Introduces [x-absolute, y-absolute] properties
for positioning in +/- MAX_DOUBLE range.
Adds new (h/v)alignment type "absolute" where coordinates
map the text area to be exactly inside of video canvas for [0, 0] - [1, 1]:
[0, 0]: Top-Lefts of video and text are aligned
[0.5, 0.5]: Centers are aligned
[1, 1]: Bottom-Rights are aligned
https://bugzilla.gnome.org/show_bug.cgi?id=761251
libgstreamer currently exports some debug category
symbols GST_CAT_*, but those are not declared in any
public headers.
Some plugins and libgstvideo just use GST_DEBUG_CATEGORY_EXTERN()
to declare and use those, but that's just not right at
all, and it won't work on Windows with MSVC. Instead look
up the categories via the API.
In order to detect graphical user input on the
textoverlay, the resulting rendering properties
need to be exposed to applications.
Fixes delayx property declaration.
https://bugzilla.gnome.org/show_bug.cgi?id=761251
The current position property is limited to X,Y positions
in the range of [0, 1]. This patch allows full control
over the overlay position, including partially outside
of the video area.
https://bugzilla.gnome.org/show_bug.cgi?id=761251
FEC may only be used when PLC is enabled on the audio decoder,
as it relies on empty buffers to generate audio from the next
buffer. Hooking to the gap events doesn't work as the audio
decoder does not like more buffers output than it sends.
The length of data to generate using FEC from the next packet
is determined by rounding the gap duration to nearest. This
ensures that duration imprecision does not cause quantization
to 2.5 milliseconds less than available. Doing so causes the
Opus API to fail decoding. Such duration imprecision is common
in live cases.
The buffer to consider when determining the length of audio
to be decoded is the previous buffer when using FEC, and the
new buffer otherwise. In the FEC case, this means we determine
the amount of audio from the previous buffer, whether it was
missing or not (and get the data either from this buffer, or
the current one if the previous one was missing).
rename gst-launch --> gst-launch-1.0
replace old elements with new elements(ffmpegcolorspace -> videoconvert, ffenc_** -> avenc_**)
fix caps in examples
https://bugzilla.gnome.org/show_bug.cgi?id=759432
The result of the two expressions will be promoted to guint64 anyway,
perform all the arithmetic in 64 bits to avoid potential overflows.
CID 1338690, CID 1338691
We always require the channel-mapping-field. If it's 0 we require nothing
else, otherwise we need channels, stream-count and coupled count to be
available.
oggdemux is outputting the meta now, and only outputs if it should really
apply to the current buffer. Previously we would skip N samples also if we
started the decoder in the middle of the stream.
https://bugzilla.gnome.org/show_bug.cgi?id=757153
It is doing the wrong thing because of the Opus pre-skip: while the timestamps
are shifted by the pre-skip, the granule positions are not shifted.
oggmux is doing the right thing here already.
https://bugzilla.gnome.org/show_bug.cgi?id=757153
The first frame has lookahead less samples, the last frame might have some
padding or we might have to encode another frame of silence to get all our
input into the encoded data.
This is because of a) the lookahead at the beginning of the encoding, which
shifts all data by that amount of samples and b) the padding needed to fill
the very last frame completely.
Ideally we would use LPC to calculate something better than silence for the
padding to make the encoding as smooth as possible.
With this we get exactly the same amount of samples again in an
opusenc ! opusdec pipeline.
https://bugzilla.gnome.org/show_bug.cgi?id=757153
... instead of relying on the segment. For the clipping at the start we assume
a proper value in the OpusHead, as generated by opusparse or opusenc.
Transmuxing in general is not guaranteed to produce the correct values, or
even have a OpusHead (e.g. when having RTP input).
https://bugzilla.gnome.org/show_bug.cgi?id=757153
The granulepos does not have the pre-skip subtracted while timestamps do,
and the last granulepos will be shorter by the number of samples that should
be dropped because of padding in the end.
As such, extrapolating the granule of the beginning of the first frame will
lead to a negative value, which is not a problem but intentional.
https://bugzilla.gnome.org/show_bug.cgi?id=757153
Usually these loops only run once, so there's no problem here. But sometimes
they run twice, and by adding the number of bytes to a 16 bit pointer type we
would advance twice as much as we should.
Also use snd_pcm_frames_to_bytes() in alsasrc to calculate
the number of bytes to skip, same as we do in alsasink.
Thanks to Lucio A. Hernandez <lucio.a.hernandez@gmail.com> for reporting.
The alsamidisrc element allows to get input event from ALSA MIDI
sequencer devices, and possibly convert them to sound using some
downstream element like fluiddec.
Fixes#738687
It is faster than doing a query that propagates downstream and
should be enough
Elements: faac, gsmenc, opusenc, sbcenc, voamrwbenc, adpcmenc, sirenenc
Removes the need for custom caps query handling and makes it more
correct from the beginning on the template. It is a bit uglier
to read because there is 1 entry per channel but makes code easier
to maintain.
accept-caps is not recursive and might stop at the next downstream element,
while caps queries are generally recursive. The next element might accept any
capsfeatures we want, but that doesn't mean that further downstream it will
also work.
Additionally for the future:
We should probably check if downstream *prefers* the
overlay meta, and only enforce usage of it if we can't handle
the format ourselves and thus would have to drop the overlays.
Otherwise we should prefer what downstream wants here.
the extents rectangle is what you need to know to properly position
a buffer that has been rendered in a surface of the ink rectangle
size. This patch make the placement on par with the placement we had
before without having to over allocate.
This patch also enable placement for vertical rendering. Note that
the halginement, valighment and line-alignment default are set to
the previous default when this property is set. This is for backward
compatibility, you can change the value after setting vertical render.
https://bugzilla.gnome.org/show_bug.cgi?id=728636
This patch uses the ink rectangle in order to compute the size
of the surface require to render. It also correctly compute the
transformation matrix as the ink_rect position might not be at
0, 0. Additionally, shadow_offset and outline_offset (which is
in fact the diameter of a dot, not a really an offset) is now
taken into account. Redundant matrix operation has been removed
for the vertical rendering.
Take note that the matrix operation in cairo are excuted in
reverse order.
https://bugzilla.gnome.org/show_bug.cgi?id=728636
* Only send the caps event once if the query had support for the
overlay composition meta.
* Only do the allocation query if it is supported through caps.
* Send overlay_caps before doing allocation query rather then normal
caps
https://bugzilla.gnome.org/show_bug.cgi?id=751157
The GstVideoOverlayComposition meta coordinates should always be
in stream scale, regardless of the window size downstream. This
way the sink can always scale the composition if the window size
have changed after a buffer (with his meta) was rendered before.
https://bugzilla.gnome.org/show_bug.cgi?id=751157
This avoids negotiating twice. Current the _setcaps() patch does
not clear the initial reconfigure flags, which lead to systematic
double renegotiation.
http://bugzilla.gnome.org/show_bug.cgi?id=751157
Remove the optimization to skip allocation query so we can
always have the latest window size information. Also, correctly
deal with the case where there is no window size information.
http://bugzilla.gnome.org/show_bug.cgi?id=751157
* cache window size event and update handle ratio
* init width with 1, don't use 0
* don't update overlay when receiving same window size
* receive window size from allocation query
https://bugzilla.gnome.org/show_bug.cgi?id=751157
This makes pipelines with multiple textoverlay elements possible.
The meta data is collected from the upstream textoverlay element,
merged into a new GstVideoOverlayComposition and passed down downstream.
https://bugzilla.gnome.org/show_bug.cgi?id=751157
Previously, PLC frames always had a length of 120ms, which caused audio
quality degradation and synchronization errors. Fix this by calculating an
appropriate length for the PLC frame.
The length must be a multiple of 2.5ms. Calculate a multiple of 2.5ms that
is nearest to the current PLC length. Any leftover PLC length that didn't
make it into this frame is accumulated for the next PLC frame.
https://bugzilla.gnome.org/show_bug.cgi?id=725167
Have all sections in alphabetical order. Also make the macro order consistent.
This is a preparation for generating the file. Remove GET_CLASS macro for
some elements, since it is not used and the header is not installed.
The intention was to skip the allocation query if upstream has decided
to use the overlay meta feature in the caps. We can safely assume that
upstream have done that query already before making this decision. This
is an optimization since doing allocation queries is relatively
expensive.
CID #1308943
upstream_has_meta is set to FALSE and never changed. The two checks for if
upstream_has_meta will never go to the true branch. Removing the boolean
and the true branches of these checks.
CID #1308943
This cleanup the negotiation function by properly splitting the probe
and the decisions. This allow handling correctly pipeline where upstream
caps have special memory type. An example pipeline is:
gltestsrc ! textoverlay text=bla ! fakesink
The upstream caps will be memory:GLMemory, which isn't supported by the
blitter.
https://bugzilla.gnome.org/show_bug.cgi?id=749243
This reverts commit 76647f2710.
Avoiding pull mode activation is a feature regression, and
demuxers should always use pull mode where that is possible,
e.g. if there's an upstream queue2 with a ring buffer or
a download buffer.
This patch made reverse playback no longer possible over http.
If the goal is to minimise seeks, then that can still be done
by making the demuxer behave differently in pull mode if
the SEQUENTIAL flag is set. If there are bugs, like the demuxer
needlessly scanning the entire file on start-up in pull mode,
then those should be fixed instead.
https://bugzilla.gnome.org/show_bug.cgi?id=746010
