When calculating duration in push-mode we seek to a certain position
and discard any data until we get data from that requested position.
The problem is that basing ourselves solely on offset to determine
whether we reached the target offset is wrong since the source might
be fast enough to send us that target position *before* it processed
the requested seek.
This would end up in a situation where:
* We think we're done with duration estimate
* We fire a seek back to "0" in the loop thread
* We resume normal processing
* ... except that we're still getting data from too far ahead which
we decide to process.
* And we start doing totally wrong granule/time/duration calculation
and pushing wrong data.
Instead of this confusion, wait until we receive data from the requested
seek. We do that by using the fact that the seqnum in
seek_event_drop_til will be non-zero until the SEGMENT corresponding
to the requested SEEK has been received.
Bonus: makes startup slightly faster
Code using the push_loop_thread (using for sending seeks) assumes
that the thread was properly started, except that this isn't always
true and the thread might not have completely started.
Instead wait for the thread to properly start before doing anything
else.
If we are going to return a (potentially) 64bit integer, don't use
a 32bit one for calculation, otherwise we could end up exceeding
the maximum size of a 32bit int.
For stream mappers that don't set a specific granuleshift, it will
have the default value of -1.
Protect the code for that and return the granule value as-is
Since the default value of a GstOggPad.map.map was 0 ... we would
end up using wrong functions from mappers() if the stream wasn't
initialized yet.
Instead of that, use a default blank/empty first entry.
In some corner cases we end up with the building chain not being
properly tracked (and therefore not properly freed).
Add a FIXME so it can later be fixed, but for now just fix the leak
... as expected later on when end time is used to determine end running time.
Otherwise the latter is determined as NONE and the resulting text buffer is
then used indefinitely.
Fix various issues with reverse playback by clearing tracking
vars when working in reverse, and where possible using the
timestamp interpolation code to generate timestamps for
outgoing buffers. Make sure to mark things as discontinuous
only when looping backward to a new position and fix seeking
to the next page when starting.
In gst_ogg_demux_do_seek() when calculating the
keyframe time, account for a non-zero start-time
Handle a discontinuous first packet in
gst_ogg_demux_setup_first_granule() because that's pretty
normal after a seek. Also differentiate between a genuinely
truncated first packet and just bailing out early, by not using
granule = -1 as an error code.
Make the debug output logs clearer about which timestamps
are stream times (PTS) and which are ogg timestamps.
This is a followup commit to b95725c37e
* Resetting the decoder should only happen when we get a new initialization
header (0x01) and not on the other headers
* The initialized variable only gets set to TRUE once all headers have
been parsed. Also check if the vorbis_info struct has been properly resetted
also. Failure to do that would cause vorbisdec to error if it got
two initialization header in a row (the first would configure the underlying
library and the second one would error out because it's already initialized)
https://bugzilla.gnome.org/show_bug.cgi?id=779515
This fixes missing audio when we get buffers with zero
duration, denoting unknown duration. When several such
buffers are received in a row, they're all at the same
timestamp, with zero duration.
https://bugzilla.gnome.org/show_bug.cgi?id=771723
Always supply a buffer with max size to the decoder, as we
can't really decide how many samples will be in the lost packet
based on the timestamps we get.
https://bugzilla.gnome.org/show_bug.cgi?id=771723
If we can't find a valid granule near the end of the file, we
disable seeking. This guards against the whole file being then
read and never going to PLAYING.
https://bugzilla.gnome.org/show_bug.cgi?id=770314
https://github.com/mesonbuild/meson
With contributions from:
Tim-Philipp Müller <tim@centricular.com>
Jussi Pakkanen <jpakkane@gmail.com> (original port)
Highlights of the features provided are:
* Faster builds on Linux (~40-50% faster)
* The ability to build with MSVC on Windows
* Generate Visual Studio project files
* Generate XCode project files
* Much faster builds on Windows (on-par with Linux)
* Seriously fast configure and building on embedded
... and many more. For more details see:
http://blog.nirbheek.in/2016/05/gstreamer-and-meson-new-hope.htmlhttp://blog.nirbheek.in/2016/07/building-and-developing-gstreamer-using.html
Building with Meson should work on both Linux and Windows, but may
need a few more tweaks on other operating systems.
This workaround tried to avoid an EOS event when seeking to the
end of an Ogg stream in order to find its duration. At some point,
an EOS event there would cause any queue2 upstream to pause and
not restart on a seek back to the beginning. This now appears to
not be the case anymore, and so the workaround can be removed.
https://bugzilla.gnome.org/show_bug.cgi?id=767689
This reverts commit a16cd5d2a5.
Setting the stop time on the segment breaks reconfiguration, as the
encoder signals an EOS, but we reconfigure it an continue to produce
buffers.
This information should not be required via the segment downstream
since we already have the sample count being used to generate buffer
durations.
https://bugzilla.gnome.org/show_bug.cgi?id=768763
If the duration is not known from the chain, it might be known
by the startup seek.
This fixes failure to seek.
Merged with a patch from Tim-Philipp Müller <tim@centricular.com>
https://bugzilla.gnome.org/show_bug.cgi?id=768991
Dropping a buffer because we have a seek pending is normal,
and will now happen when we trigger a seek while going through
the packets in a page. So this should not be an error.
A low bitrate stream which can pack more than 2 seconds of audio
in a page would cause the stream's position to be updated not
often enough, and would trigger a spurious "jump" via a GAP
event. Instead, we update the stream position after calculating
the new overall segment position.
https://bugzilla.gnome.org/show_bug.cgi?id=764966
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
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.
This should not cause any actual bug since Theora and Daala have
a maximum shift of 31, and a packet duration of 2^31 seems very
implausible. But it fixes:
Coverity 1139804, 1139803, 1139802
Add an extra function to the oggstream map to inform it about
the incoming buffers. This way oggmux can keep a count on the
vp8 invisible frames and calculate the granulepos correctly.
https://bugzilla.gnome.org/show_bug.cgi?id=722682
vp8 stream header shouldn't be assumed to be provided in caps always
as this would repeat the same code in all demuxers/encoders. Instead,
make oggmux generate them if they are not supplied.
https://bugzilla.gnome.org/show_bug.cgi?id=722682
When seeking back to original state after duration seeks, let
upstream know that we want the whole file, including the last
byte that wasn't requested on the duration seeks.
https://bugzilla.gnome.org/show_bug.cgi?id=724633
video time uses the 'segment' and the text time should use
the 'text_segment'.
If different segments are used for video and text it would
lead to out of sync video/subtitles.
A change in gst_ogg_demux_do_seek caused oggdemux to wait for
a page for each of the streams, including a skeleton stream if
one was present. Since Skeleton only has header pages, that
was never going to end well.
Also, the code was skipping CMML streams when looking for pages,
so would also have broken on CMML streams.
Thus, we change the code to disregard Skeleton streams, as well
as discontinuous streams (such as CMML and Kate). While it may
be desirable to consider Kate streams too (in order to avoid
losing a subtitle starting near the seek point), this may be
a performance drag when seeking where no subtitles are. Maybe
one could add a "give up" threshold for such discontinuous
streams, so we'd get any page if there is one, but do not end
up reading preposterous amounts of data otherwise.
In any case, it is important that the code that determines
the amount of streams to look pages for remains consistent with
the "early out" conditions of the code that actually parses
the incoming pages, lest we never decrease the pending counter
to zero.
This fixes seeking on a file with a skeleton track reading all
the file on each seek.
https://bugzilla.gnome.org/show_bug.cgi?id=719615
Ogg data is read chunk by chunk, and the chunk size used was
originally taken from libvorbisfile. However, this value leads
to poor performance when used on an Ogg file with large pages
(Ogg pages can be close to 64 KB).
We can't just use a larger chunk size, since this will decrease
performance on small page streams, so we use an adaptive scheme
where the chunk size is twice the largest page size we've seen
so far in the stream. For "typical" Ogg/Vorbis, this gives us
almost the same chunk size (a bit lower), and this lets us get
better performance on streams with large pages.
1275 is the maximum size of a frame, but the encoder may return
up to 3 frames, and we need a few extra bytes for TOC, etc. We
use 4000, which is a bit more, and suggested in the libopus docs.
In case we receive a flush event before having our caps set, we will
end up trying to create a theora encoder even though we are not ready.
Avoid that situation making sure we are initialized before accepting to
be flushed.
https://bugzilla.gnome.org/show_bug.cgi?id=709858
The initial support for the new ALSA chmap API.
Just translate the current chmap to GstAudioChannelPosition during the
setup. No function to specify the channel map manually yet, so still
impossible to assign any non-standard positions or to configure in a
different order even if the hardware allows.
https://bugzilla.gnome.org/show_bug.cgi?id=709755
Store the seek stop and seqnum and properly restore them when
receiving the corresponding Segment from upstream. Also fixes
seqnum for converted seek events.
When bisecting after an earliest time has been found, we need
to only consider the stream for which the earliest time was found.
Before, the following scenario could be and was encountered:
a) Find the earliest time for stream X
b) bisect and find a page which granuletime is indeed < target, but
contains another stream.
c) decide to seek at the wrong offset, sometimes inferior to
the real one, in which case the error was undected or
d) the offset was superior, and thus the actual target keyframe was
not processed, and packets were skipped waiting
for a granulepos.
https://bugzilla.gnome.org/show_bug.cgi?id=700537
The problem experienced is that the EOS was never emitted by oggmux during a
rendering with GES. The proposed patch checks if the pad is EOS before deciding
it's the "best pad".
https://bugzilla.gnome.org/show_bug.cgi?id=699792
If our previous flow return was NOT_LINKED, don't try to push on the pads some
more. If we get a RECONFIGURE event on the pad, try to push on it again.
Changed the check to a current_time equal to the stop will produce
EOS instead of the next one. Also, segment.start can't be NONE, so removing
this check.
Fixes https://bugzilla.gnome.org/show_bug.cgi?id=696899
gst_query_set_nth_allocation_pool() requires there to be a pool in the
query already. This is not always the case when we get the query from
upstream. Use gst_query_add_allocation_pool() instead in such case.
https://bugzilla.gnome.org/show_bug.cgi?id=681719
Instead, remember we need a keyframe, and we will force the encoder
to emit one next time we submit a new frame.
Since libtheora does not have an API to request a keyframe, we reset
the max keyframe interval to 1 temporarily.
This has the advantage that the rate control keeps its history,
and that the encoder won't choose different quant tables or
somesuch, thus requiring new streamheaders (although this is
probably only a theoretical possibility). Should also be a
bit faster than resetting the encoder.
https://bugzilla.gnome.org/show_bug.cgi?id=663350
The current code is memsetting the GstVideoFrame.data address to 0s (which
causes a segfault). This member is actually an array of data buffers (one for
each plane). This fix iterates over each data plane to clear them all.
https://bugzilla.gnome.org/show_bug.cgi?id=695655
No need to copy buffers we put into the streamheader any more
now that we don't put caps on buffers any more, so there's no
danger of a refcount cycle.
No need to copy buffers we put into the streamheader any more
now that we don't put caps on buffers any more, so there's no
danger of a refcount cycle.
No need to copy buffers we put into the streamheader any more
now that we don't put caps on buffers any more, so there's no
danger of a refcount cycle.
Really really fix attribute list handling by taking a
copy of the original attributes that pango_attr_list_filter
can mutate, but keep the original around intact to restore
later.
The root cause is that alsa-lib is not thread safe for the same handle.
There are two threads in the gstreamer accessing alsa-lib not serilized.
The race condition happens when one thread holds the old framebuffer app_ptr
position in the kernel, another thread advances the framebuffer app_ptr.
when the former thread is scheduled to run again, it overwrites the app_ptr
to old value by copying from kernel.Thus,the app_ptr in the upper
alsa-lib(pcm_rate) become one period size more advanced than the lower
alsa-lib(pcm_hw & kernel).
gstreamer uses noblock and poll method to communicate with the alsa-lib.
The app_ptr unsync situation as described above makes the poll return immediately because
it concludes there is enough space for the ring-buffer via the low-level alsa-lib.
The write function returns immediately because it concludes there is not enough
space for the ring-buffer from the upper-level alsa-lib. Then the loop of poll
and write runs again and again until another period size is available for
ring-buffer.This leads to the cpu 100 problem.
delay_lock is used to avoid the race condition.
Fixes: https://bugzilla.gnome.org/show_bug.cgi?id=690937
Don't loop forever if an USB audio device gets disconnected
while in use. Post an error message instead. This is not
enough yet though, we still need to make the base class
and/or the ring buffer bail out.
https://bugzilla.gnome.org/show_bug.cgi?id=690197
The format probing code was assuming there'd be one caps
structure for each separate width/depth combination like
we did in 0.10 all over the place: for one, we'd query
unsigned/signed formats together for the same width/height,
and we'd add the entire current structure to the probed
caps when we find a format is supported. Now that we have
all raw formats in a single structure, this is all not going
to work so well any more. We added the entire structure with
all possible formats to the caps if we support just one format.
Fix probing so that we only return the list of actually
supported raw audio formats (with native endianness) from
get_caps().
opus + jpegformat plugin builds fail when gstreamer is configured with
--disable-gst-debug as they are checking the GST_DISABLE_DEBUG symbol
instead of GST_DISABLE_GST_DEBUG.
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
https://bugzilla.gnome.org/show_bug.cgi?id=683850
Make it possible for subclasses to provide the timestamp (as an absolute time
against the pipeline clock) of the last read data.
Fix up alsa to provide the timestamp received from alsa. Because the alsa
timestamps are in monotonic time, we can only do this when the monotonic clock
has been selected as the pipeline clock.
Fixes https://bugzilla.gnome.org/show_bug.cgi?id=635256
This reverts part of "visual: enable commented out code again."
(commit 8222ba16c8).
The shader code does indeed look broken (or rather,
it makes assumptions that are not necessarily true here,
namly that pixel stride is 4, for example), which
makes totem very crashy and causes other weird behaviour.
Also see https://bugzilla.gnome.org/show_bug.cgi?id=683527
gst_element_class_get_pad_template() does not return a ref,
so we mustn't unref the template returned. Fixes crashes
when switching back and forth between different types of
subtitle streams.
Add support for GstVideoMeta and GstVideoFrame.
Remove some redundant fields that are also in GstVideoInfo
Disable the shader code, it looks broken.
Fixes https://bugzilla.gnome.org/show_bug.cgi?id=681719
We don't really care about what's inside those channels. This also makes the
caps valid because now it's no longer possible to have channels=1 and a mask
of 0x3.
Pick delta pad earlier during header parsing, and pick it based
on whether it's a video stream or not rather than some rather
byzantine signalling from theoraenc etc. which would set the delta
flag on header packets which oggmux would then pick up and determine
that this is a "delta-able" stream.
Since the new videodecoder-based theoraenc didn't do that any more,
we would only see the first delta flag on the second video packet,
which is after we've already muxed a few audio packets flagged as
key units, which trips up the unit test.
Fixes pipelines/oggmux unit test.
https://bugzilla.gnome.org/show_bug.cgi?id=679958
Add a copy of the base class until it is stable. Right now the extra effects of
the baseclass are not supported as the sublass overwrites the buffer instead of
blending.
We now support pre-multiplied alpha in the overlay composition API,
and can avoid multiple conversions if the the overlay also supports
pre-multiplied alpha. We should probably also have mapped the
buffer as READWRITE when unpremultiplying.
A crafted file with invalid pages will cause repeated searches from
earlier offsets in steps of 8500 bytes, but reading till the end of
the stream. Since we know the maximum size of an Ogg page, we can
bound the search for next page, to get a linear behavior (though
still not good enough as it will read the entire file backwards if
there's no valid page till then).
Take chain lock when accessing chains. Fall back gracefully
when there's no current chain Hopefully fixes crash when
seeking in Jamendo or Magnatune streams in Amarok.
https://bugzilla.gnome.org/show_bug.cgi?id=675609
They're hardly used, and probably more confusing than anything
else, and it's not clear that anyone would really need to be
able to tell them apart at the media type level.
This never really took off - it's hardly used anywhere
and deprecated in favour of Kate. Exposing pads just
leads to confusing 'you are missing a plug-in' messages
when people come across such streams. We could still post
the data on the bus for applications to parse.
Video base classes and theora plugin still needs to be ported again
Conflicts:
docs/libs/gst-plugins-base-libs-docs.sgml
docs/libs/gst-plugins-base-libs-sections.txt
docs/libs/gst-plugins-base-libs.types
ext/theora/gsttheoradec.c
ext/theora/gsttheoradec.h
ext/theora/gsttheoraenc.c
ext/theora/gsttheoraenc.h
gst-libs/gst/video/Makefile.am
gst-libs/gst/video/video.c
gst-libs/gst/video/video.h
gst/playback/gsturidecodebin.c
tests/check/libs/video.c
tests/check/pipelines/theoraenc.c
win32/common/libgstvideo.def
FIXME : Don't forget to backport changes that happened to theoraenc
since April 2011
theoraenc: Don't create keyframe on time gap
There is no rational to do so, and also gst_video_encoder_set_discont() is
gone from base class.
Tremor changed to use standard libogg rather than its own incompatible
copy back in Aug 2010 (r17375), causing gst-plugin-base build to fail.
Tremolo so far unfortunately hasn't been updated. Restructure
vorbisdeclib.h so the int/float logic is seperate from the ogg handling,
and only use the legacy _ogg_packet_wrapper code for Tremolo.
https://bugzilla.gnome.org/show_bug.cgi?id=668726
... since it is specified in _finish_frame that input buffer may be invalidated
after calling it, and is as such not reliably available for further encoding.
Also, requesting or allowing several frames is only useful if subclass intends
to process these "in 1 run" (as in, 1 output buffer), not for having another
(inner) loop in subclass where the baseclass one will do just fine.
Store the uncropped frame dimensions in the videoinfo.
Always set the caps with the dimension of the cropped output.
Don't negotiate the bufferpool multiple times.
Remove the old crop feature, we always crop now.
_BAD_CFLAGS should always come first, then GST_PLUGINS_BASE_CFLAGS,
then GST_BASE_CFLAGS then GST_CFLAGS. Same for libs: first plugins
base libs, then GST_BASE_LIB then GST_LIBS.
In case many packets fit on a page, we may not see a granpos for
a while, and granpos interpolation can wrap the 'frames since last
keyframe' part of the granpos, generating a granpos which is smaller
than what it should be.
This is fixed by detecting keyframe packets (at least for Theora),
and updating the last keyframe granpos from this.
This may still be generating potentially wrong granpos for streams
which have a Theora like granpos (keyframes, a max keyframe distance
and a count of frames since last keyframe), and which allow implicit
granules on packets. For these streams, a custom keyframe detection
routine should be plugged into their GstOggStream mapper.
https://bugzilla.gnome.org/show_bug.cgi?id=669164
It was matching non header packets.
This fixes various leaks, where buffers would be pushed onto a headers
list, but never popped.
Might also fix corruption as those buffers were dropped from the output
silently...
https://bugzilla.gnome.org/show_bug.cgi?id=669167
An ALSA sink may select a different rate (as we use the _set_rate_near
API, which is not guaranteed to set the exact target rate).
The rest of the code seems to already handle this well, as output
from a 88200 Hz file seems to have the correct pitch when selecting
a 96 kHz rate.
For the USE_TREMOLO case, GstVorbisDec doesn't have
a vb member. Besides, Tremolo's vorbis_dsp_synthesis()
expects a vorbis_dsp_state to be passed as first
argument. Not a vorbis_block.
When I first implemented push mode seeking, I removed the chain
freeing there as it could be used later. The current code does not
seem to do that though, so I'm restoring the previous freeing,
which plugs the leak while apparently not reintroducing use of
freed data with chained and normal files, both with gst-launch
playbin2 and Totem.
