... 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
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
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
