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
gst_event_replace() takes its own reference on the event so we should drop
ours after creating and storing an event using it.
This fix leaks which can be reproduced using the
validate.http.media_check.vorbis_theora_1_ogg scenario.
https://bugzilla.gnome.org/show_bug.cgi?id=748247
If we don't consume the buffer by passing its reference to
overlay->text_buffer then we need to unref it.
Fix a leak with validate.file.playback.fast_forward.test5_mkv
when running inside Valgrind.
https://bugzilla.gnome.org/show_bug.cgi?id=747602
When a stream has a skeleton index, the stream time is taken from that
index. However, when part of the stream is captured, the index is
invalid as its offsets are now wrong. To avoid this, we ignore the index
when the last offset points beyond the end of the stream (when its
byte length is known).
https://bugzilla.gnome.org/show_bug.cgi?id=744070
When deltax is large enough to cause the text to push past the
width of the frame, it would disappear due to a bug in setting
the layout width.
While there, fix a log printing an incorrect width to set.
https://bugzilla.gnome.org/show_bug.cgi?id=739689
oggmux keeps a cached buffer per pad, and pulls buffers from
collectpads to this cached buffer for all pads before processing
the best pad. In some cases, the move from collectpads buffer
to cached buffer is delayed till next call. However, when there
is only one pad, this can't be delayed till next call as there
will be a deadlock since collectpads has no other pad to push to.
https://bugzilla.gnome.org/show_bug.cgi?id=740565
This way we let opusdec do the resampling if needed and don't carry
around buffers with a too high sample rate if not required.
While Opus always uses 48kHz internally, this information from the
header specifies which frequencies are safe to drop.
gstoggdemux.c:1233:11: error: format specifies type 'long' but the argument has type 'ogg_int64_t' (aka 'long long') [-Werror,-Wformat]
granule);
^~~~~~~
https://bugzilla.gnome.org/show_bug.cgi?id=746512
The code that was calculating the start granule from packet durations
was interpreting a negative value as an error, but this is actually a
valid case, to indicate clipping of data at start.
https://bugzilla.gnome.org/show_bug.cgi?id=743900
If we get EOS when we're trying to build a chain, we disable seeking
and continue instead of posting an error. This can happen for corner
cases such as a stream with a video that stops before the end, for
instance.
https://bugzilla.gnome.org/show_bug.cgi?id=745980
When looking for pages when seeking, we stop looking for non sparse
streams if we don't find one within a given threshold. This fixes
seeking filling up queues and blocking in corner cases such as an
audio file with a pathological 1 frame video stream (yes, I saw one).
https://bugzilla.gnome.org/show_bug.cgi?id=745980
Store the video info of the internal frame decode width/height
separate to the exposed (cropped) frame info, so that it can be
used for mapping the downstream allocated video frame buffer correctly
when using GstVideoCropMeta.
Fixes playback of files with sizes that aren't a multiple of 16-pixels
width or height.
https://bugzilla.gnome.org/show_bug.cgi?id=741030
This will usually deadlock, despite this patch being in master for
quite some time and working fine. Nevertheless, we deem it to be
not working, disregarding facts.
As such, we fix it by keeping track of seek events, and sending
them upstream from a separate thread. Buffers are then discarded
till we get a new segment with the expected seqnum.
READY->PAUSED can be too early as souphttpsrc can get the HTTP
headers after this. Try again in the chain function.
Also use seeking query to disable seeking if upstream reports
being unseekable.
Some resetting code has to be done in the NEW_SEGMENT
event handler, instead of the missing FLUSH_STOP one.
Segment base was also wrongly accounted for. This was hidden
by the fact that flushing resets the base.
A discontinuity is now also signalled on seeking. We have to
also ensure that the discontinuity "sticks" till a buffer
with a valid timestamp goes out, or the audio decoder base
class will ignore the discontinuity for purposes of keeping
track of the current time.
This allows using non flushing segment seeks for looping
HTML audio in particular, and more generally non flushing seeks.
https://bugzilla.gnome.org/show_bug.cgi?id=729198
The code was using the first nonnegative granulepos to seed the
granule tracking, which appeared to work since headers have zero
granulepos. However, this does not work for files with a hole at
start, which are common in live streaming.
The correct behavior is to look for the first granule, and subtract
the duration of all the packets finishing on this page.
The function which does this relies on the fact that the ogg_stream
structure can be duplicated by shallow copy, in order to pull the
packets from the first page(s) on the copy without affecting the
original stream state.
The max latency parameter is "the maximum time an element
synchronizing to the clock is allowed to wait for receiving all
data for the current running time" (docs/design/part-latency.txt).
https://bugzilla.gnome.org/show_bug.cgi?id=744338
Don't use private GMutex implementation details to check
whether it has been freed already or not. Just turn dispose
function into finalize function which will only be called
once, that way we can just clear the mutex unconditionally.
Makes theora work in cases where the header packets are only in the caps
(because theoradec was connected to oggdemux late and missed the
beginning of the stream)
If the streaming task attempts to read a chain while the pipeline
is stopping (which can happen if the pipeline stops shortly after
start or a new URI being setup in gapless playback case), it will
see a flushing return from upstream, and should then also return
flushing to the caller, rather than emit a flow error.
https://bugzilla.gnome.org/show_bug.cgi?id=722442
Fix leak of caps event and of caps objects when setting caps on sink and src
pads. Sync audiovisualizer class implementation to the one in gst-plugins-bad.
This commit matches c5ef1bee73 in that module.
https://bugzilla.gnome.org/show_bug.cgi?id=742875
This reverts commit a91d521a36.
Being a base class it is better to check the value instead of ignoring it since
a child class could be created that returns valuable information.
klass->setup (scope) will always return TRUE since all children of this class
do so, no need to store the return. Besides, the value is overwritten a few
lines down before it is ever used. Save the unnecessary memory and instructions.
CID #1226467
ret is assigned but not used and in the next cycle of the loop it is overwritten
with default_prepare_output_buffer (). If there is a flow error the function
should return instead.
CID #1226475
It might happen that the timestamp is before the segment and the
check would succeed. In this case reducing the duration makes no
sense and would lead to broken results.
The previous code was setting keytarget to target
to make sure the keyframe found for each pad was
indeed before the target.
Then if target == keytarget, it assumed a keyframe had been
found, which was not the case if target was before the first frame
in the file.
This patch checks that a keyframe was indeed found, and if not
seeks to 0, without bisecting again.
Assuming default gst qa assets in $HOME/gst-validate
seek_before_first_frame.scenario:
description, seek=true, handles-states=true
pause, playback-time=0.0
seek, playback-time=0.0, start=0.0, flags=accurate+flush
seek, playback-time=0.0, start=0.01, flags=accurate+flush
seek, playback-time=0.0, start=0.1, flags=accurate+flush
GST_DEBUG=*theoradec*:2 gst-validate-1.0 playbin \
uri=file://$HOME/gst-validate/gst-qa-assets/medias/ogg/vorbis_theora.0.ogg \
--set-scenario seek_before_first_frame.scenario
https://bugzilla.gnome.org/show_bug.cgi?id=741097
When encoding, libvorbis will tell us how many samples are encoded
in the buffer it returns. This number may be less than the maximum
of samples in the block, if this is the last packet. In we have no
segment end time, we set it to the end time of that last sample to
tell downstream that the buffer contains less samples.
Samples may be clipped at the end, and this is conveyed by a
granulepos that's smaller than it would otherwise be. Use the
segment stop time to detect this, and calculate the right
granulepos.
When the textoverlay is set outside the video frame by deltax or deltay the
calculation segfaults, but it is also unnecessary since it doesn't need to be
displayed. So we should clip the text.
https://bugzilla.gnome.org/show_bug.cgi?id=738242
vorbis_reorder_map is defined for eight channels max. If we have more
than eight channels, it's the application which shall define the order.
Since we set audio position to none, we just interleave all the channels
without any particular reordering.
https://bugzilla.gnome.org/show_bug.cgi?id=737742
The allocation query failure doesn't mean that the negotiation
has failed as the element can allocate buffers itself.
Instead, only fail if the pads are flushing and the allocation
query failed.
https://bugzilla.gnome.org/show_bug.cgi?id=735844
The source pad might be flushing while negotiating, resulting in
set_caps or the ALLOCATION query failing. In this case set the
reconfigure flag on the source pad so that negotiation is retried on the
next buffer.
When downstream claims to accept the overlay meta but fails to
provide it in the allocation query, properly fallback to setting
a new caps without the overlay meta as that is not going to be used.
Only do this if the original caps doesn't have the overlay already,
otherwise there isn't much that can be done.
https://bugzilla.gnome.org/show_bug.cgi?id=735800
Setting segment.base in the segment sent from gst_ogg_demux_handle_page() is
enough to ensure that chained oggs are played corretly (see bgo#706569).
Tweaking the base in gst_ogg_pad_submit_packet() as well result in delays when
playing a file with start != -1.
https://bugzilla.gnome.org/show_bug.cgi?id=735808
It's not done in any other code calling negotiate and will cause deadlocks
as it is sending events and queries in the pipeline.
Specifically this pipeline was deadlocking:
gst-launch-1.0 videotestsrc ! textoverlay ! textoverlay ! fakesink
Base time should be accumulated so non flushing seeks have the expected base.
Not accumulating result in segments appearing as "too late" and so are not
played by the sink.
https://bugzilla.gnome.org/show_bug.cgi?id=735509
Make textoverlay negotiate caps more correctly.
1) Check what caps we received in the video-sink
2) If it already has the overlay meta -> use it directly
3) If it doesn't, textoverlay try adding the overlay meta and using it,
if downstream doesn't support it, just use what is received in the
video-sink
4) Check if the allocation query also supports the meta to enable
really using it
Before it wasn't really doing renegotiation of any kind, just
re-checking if it should use the overlay meta or not
Also had to update the caps in the test as memory:SystemMemory seems
to be required when you use a caps feature otherwise intersection/subset
checks will fail.
https://bugzilla.gnome.org/show_bug.cgi?id=733916
The headers were never getting reffed when being added to the headers
list, which is later unreffed-and-freed by the caller (e.g.
gst_opus_parse_parse_frame()).
https://bugzilla.gnome.org/show_bug.cgi?id=733013
When a pipeline using alsasink and push mode upstream fails
to preroll, the following state will be the case:
- A loop upstream will be PAUSED, pushing a first buffer
- alsasink will be READY, pending PAUSED, because async
On error, the pipeline will switch to NULL. alsasink is in
READY, so goes to NULL immediately. It zeroes its cached
caps. Meanwhile, the upstream loop can cause a caps query,
conccurent with the state change. This will use those cached
caps. If the zeroing happens between the NULL test and the
dereferencing, GStreamer will critical down in the GstValue
code.
Since it appears that such a gap between states (PAUSED
and pushing upstream, and NULL downstream) is expected, we
need to protect the read/write access to the cached caps.
This fixes the critical.
See https://bugzilla.gnome.org/show_bug.cgi?id=731121
This lets oggdemux determine they are not delta units, and removes
spurious per packet warnings about being unable to determine the
packet's keyframeness.
They are very confusing for people, and more often than not
also just not very accurate. Seeing 'last reviewed: 2005' in
your docs is not very confidence-inspiring. Let's just remove
those comments.
