This avoids a race where we would get new tag but we are already
prerolled and analyzing results.
It is the way it is supposed to be handled as stated in comment:
"If preroll is complete, drop these tags - the collected information is
possibly already being processed and adding more tags would be racy"
Reset last_timestamp_out when applying the output segment
change, to avoid decoder confusion over new timestamp timelines when
a seamless segment change happens.
Move some locks/unlocks to later when they're actually needed.
https://bugzilla.gnome.org/show_bug.cgi?id=734617
As was done for the base video decoder in commit 695675, don't
flush out the decoder on a new SEGMENT event. Segment events
may be a new segment, but are also often segment updates for
the current segment where the old data should be kept. For new
segments, a STREAM_START event will already trigger a drain, but
make sure to flush any remaining partial data then as well.
https://bugzilla.gnome.org/show_bug.cgi?id=734666
This fixes the reverse playback scenario when upstream is not fully
parsing the stream and does not send every keyframe chain separately
with the DISCONT flag on the keyframe.
To explain this, let's suppose we have this stream:
0 1 2 3 4 5 6 7 8
K K K
In most circumstances, the upstream parser will chain in the
decoder the buffers in the following order:
6 7 8 3 4 5 0 1 2
D D D
In this case, GstVideoDecoder will flush the parse queue every time
it receives discont (D) and we will eventually get in the output queue:
(flush here) 8 7 6 (flush here) 5 4 3 (flush here) 2 1 0
In case the upstream parser doesn't do this work, though,
GstVideoDecoder will receive the whole stream at once and will flush
the parse queue afterwards:
0 1 2 3 4 5 6 7 8
D
During the flush, it will look backwards for keyframes and will
decode in this order:
6 7 8 3 4 5 0 1 2
This is the same order that it would receive from upstream if
upstream was parsing and looking for the keyframes, only that now
there is no flushing of the output queue in between keyframes,
which will result in the output queue looking like this:
2 1 0 6 5 3 8 7 6
This will confuse downstream obviously and will play incorrectly.
This patch forces the decoder to flush the output queue every time
it picks a new keyframe to decode, so it will end up decoding 6 7 8
and then flushing before picking 3 for decoding, so the output will
get 8 7 6 before 6 5 3 and the video will play back correctly.
https://bugzilla.gnome.org/show_bug.cgi?id=734441
Otherwize the pipeline would be in an wrong state and on the next
iteration any kind of error could happen
Everytime an error happens in a pipeline the application has to set the
pipeline back to NULL instead of READY.
https://bugzilla.gnome.org/show_bug.cgi?id=733976
This prevent implementing allocation query, as the format need to be
known in order to determin the size and number of buffers needed.
Note: This may lead to few regressions that will need fixing
https://bugzilla.gnome.org/show_bug.cgi?id=732288
Fixes regression introduced by:
commit b60888fd4b
Author: Michael Olbrich <m.olbrich@pengutronix.de>
Date: Tue May 20 11:18:56 2014 +0200
dmabuf: share the mapping with shared copies of the memory
https://bugzilla.gnome.org/show_bug.cgi?id=730441
Fix gst_video_decoder_parse_available() to really parse any pending
source data that is still available in the adapter. This is a memory
optimization to avoid expansion of video packed added to the adapter,
but also a fix to EOS condition when the subclass parse() function
ultimately only needed to call into gvd_have_frame() and no additional
source bytes were consumed, i.e. gvd_add_to_frame() is not called.
This situation can occur when decoding H.264 streams in byte-stream/nal
mode for instance. A decoder always requires the next NAL unit to be
parsed so that to determine picture boundaries. When a new picture is
found, no byte is consumed (i.e. gvd_add_to_frame() is not called)
but gvd_have_frame() is called (i.e. priv->current_frame is gone).
Also make sure to avoid infinite loops caused by incorrect subclass
parse() implementations. This can occur when no byte gets consumed
and no appropriate indication (GST_VIDEO_DECODER_FLOW_NEED_DATA) is
returned.
https://bugzilla.gnome.org/show_bug.cgi?id=731974
Signed-off-by: Gwenole Beauchesne <gwenole.beauchesne@intel.com>
Make the MIKEY message and payload objects miniobjects so that they have
a GType and are refcounted.
We can reuse the dispose method to clear our payload objects.
Add some annotations.
Implement a copy function for the MIKEY message.
Fix the unit test.
Fixes https://bugzilla.gnome.org/show_bug.cgi?id=732589
Recognize H.264 Level 5.2, as exposed by modern 2160p30+ streams,
i.e. commonly known as 4K. Also add initial support for handling
Annex.G (SVC) profiles.
https://bugzilla.gnome.org/show_bug.cgi?id=732269
Signed-off-by: Gwenole Beauchesne <gwenole.beauchesne@intel.com>
With most decoder libraries, and especially when accessing codecs via
OpenMAX or similar APIs, we don't have the ability to properly related
the output buffers to a number of input samples. And could e.g. get
a fractional number of input buffers decoded at a time.
Previously this would in the end lead to an error message and stopped
playback. Change it to a warning message instead and try to handle it
gracefully. In theory the subclass can now get timestamp tracking
wrong if it completely misuses the API, but if on average it behaves
correct (and gst-omx and others do) it will continue to work properly.
Also add a test for the new behaviour.
We don't change it in the encoder yet as that requires more internal logic
changes AFAIU and I'm not aware of a case where this was a problem so far.
We are scaling from a unit in microseconds to a unit in ((1 << 32) per seconds).
We therefore scale the microseconds values by:
value of a second in the target unit (1 << 32)
--------------------------------------------------------------
value of a second in the origin format (1 000 000 microsecond)
A simple '&' is not sufficiant. With mmapping_flags == PROT_READ and
prot == PROT_READ|PROT_WRITE the check produces the wrong result.
Change the check to make sure that prot is a subset of mmapping_flags.
https://bugzilla.gnome.org/show_bug.cgi?id=730559
With lots of shared memory instances (e.g. created by a RTP payloader) the
overhead of duplicating the file descriptor and creating extra mappings is
significant. To avoid this, the parent memory maps the whole region and the
shared copies just reuse the same mapping.
https://bugzilla.gnome.org/show_bug.cgi?id=730441
Add a read source on write socket when lost tunnel.
To be able to detect when clint closes get channel.
This is already done in gst_rtsp_source_dispatch_write but
only when the queue is empty.
Fixes https://bugzilla.gnome.org/show_bug.cgi?id=730368
By re-using the uri argument for storing local data, we could end up in
a situation where we would free uri ... which would actually be the
string passed in argument.
Instead explicitely use a local variable. Fixes double-free issues.
CID #1212176
Buffer pool set_config() may return FALSE if requested configuration needed small
changes. Reget the config and try setting it again. This ensure we have a configured
pool if possible.
Currently the API is far from optimal and the user has to work around
our badly defined API to simply install missing plugins.
API:
new:
gst_discoverer_info_get_missing_elements_installer_details
deprecated:
gst_discoverer_info_get_misc
gst_discoverer_stream_info_get_misc
https://bugzilla.gnome.org/show_bug.cgi?id=720596
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.
We were returning in various places without unreffing the caps, and
we were also leaking (overwriting) the caps we got from _get_current_caps()
Spotted by Haakon Sporsheim in #gstreamer
This should allow for more meaningful errors. Dereferencing NULL
is more useful information than dereferencing a random address
happened to be on the stack.
If gst_video_overlay_rectangle_apply_global_alpha is called with
a rectangle with unsuitable alpha, expanding the alpha plane will
fail, and thus lead to dereferencing a NULL src pointer. It's not
certain this will happen in practice, as the function is static
and callers might ensure suitable alpha before calling, but there
is no apparent explicit such check.
Add prologue asserts for proper alpha to explicitely prevent this.
Coverity 1139707
Videodecoder does late renegotiation, it will wait for the next
buffer before renegotiating its caps and bufferpool. It might happen
that downstream element switched from passthrough to non-passthrough
and sent a reconfigure upstream (that caused this renegotiation).
This downstream element will ask the video sink below for the bufferpool
with an allocation query and will get the same bufferpool that
videodecoder is holding, too.
When renegotiating, if videodecoder deactivates its bufferpool it
might be deactivating the bufferpool that some element downstream
is using and cause the pipeline to fail.
https://bugzilla.gnome.org/show_bug.cgi?id=727498
Clock slaving can clip start time to zero, giving us a shorted
duration than we originally got. To keep in sync, we must then
discard the samples falling before that zero timestamp.
This possibly fixes random distortion caused by constant PA
underflows which are never resynced.
The KEMAC payload actually needs to have subpayloads and the key should
go into the KEY_DATA subpayload. Add support for subpayloads and
implement the KEY_DATA payload.
Add some pointers to the conversion functions that allow us to add
encryption and decryption later.
baseparse will reverse each GOP for us already, so the segment events can
be after our keyframe. Make sure to get it and all other relevant sticky
events before starting to decode.
MIKEY is defined in RFC 3830 and is used to exchange SRTP encryption
parameters between a sender and a receiver in a secure way.
This library implements a subset of the features, enough to implement
RFC 4567, using MIKEY in SDP and RTSP.
