The spec mentions a version of the MPEG-2 frame with a base frame and
extension frame. I don't have IEC 13818-3 to figure out what that is,
and don't see any references in search results, so it's a FIXME for now.
https://bugzilla.gnome.org/show_bug.cgi?id=736797
Move the conversion code used in videoconvert to the video library
and expose a simple but generic API to do arbitrary conversion. It can
currently do colorspace conversion but the plan is to add videoscale to
it as well.
See https://bugzilla.gnome.org/show_bug.cgi?id=732415
When playing chained data the audio ringbuffer is released and
then acquired again. This makes it reset the segbase/segdone
variables, but the next sample will be scheduled to play in
the next position (right after the sample from the previous media)
and, as the segdone is at 0, the audiosink will wait the duration
of this previous media before it can write and play the new data.
What happens is this:
pointer at 0, write to 698-1564, diff 698, segtotal 20, segsize 1764, base 0
it will have to wait the length of 698 samples before being able to write.
In a regular sample playback it looks like:
pointer at 677, write to 696-1052, diff 19, segtotal 20, segsize 1764, base 0
In this case it will write to the next available position and it
doesn't need to wait or fill with silence.
This solution is borrowed from pulsesink that resets the clock to
start again from 0, which makes it reset the time_offset to the time
of the last played sample. This is used to correct the place of
writing in the ringbuffer to the new start (0 again)
https://bugzilla.gnome.org/show_bug.cgi?id=737055
Move the assert to the error handling block at the end of the function so the
the logging is still triggered. Reword the logging slightly and add another
comment to hint what went wrong.
Fixes#737138
Issue:
During a PAUSED->PLAYING transition when we are rendering an audio buffer in AudioBaseSink
we make adjustments to the sink's provided clock i.e. fix clock calibration using the external
pipeline clock, within "gst_audio_base_sink_sync_latency function inside gstaudiobasesink.c".
For the calibration adjustment we need to get the sink clock time using "gst_audio_clock_get_time".
But before calling "gst_audio_clock_get_time" we acquire the Object Lock on the Sink. If sink is
a pulsesink, "gst_audio_clock_get_time" internally calls "gst_pulsesink_get_time" which needs to
acquire Pulse Audio Main Loop Lock before querying Pulse Audio for its stream time using
"pa_stream_get_time". Please see "gst_pulsesink_get_time in pulsesink.c".
So the situation here is we have acquired the Object lock on Sink and need PA Main Loop Lock.
Now Pulse Audio Main Thread itself might be in the process of posting a stream status
message after Paused to Playing transition which in turn acquires the PA Main loop lock and
needs the Object Lock on Pulse Sink. This causes a deadlock with the earlier render thread.
Fix:
Do not acquire the object Lock on Sink before querying the time on PulseSink clock. This is
similar to the way we have used get_time at other places in the code. Acquire it after the
get_time call. This way PA Main loop will be able to post its stream status message by
acquiring the Sink Object lock and will eventually release its Main Loop lock needed for
gst_pulsesink_get_time to continue.
https://bugzilla.gnome.org/show_bug.cgi?id=736071
The timeout parameter is only allowed in a session response header
but some clients, like Honeywell VMS applications, send it as part
of the session request header. Ignore everything from the semicolon
to the end of the line when parsing session id.
Fixes https://bugzilla.gnome.org/show_bug.cgi?id=736267
Fixes a crash when controlsrc, readsrc or writesrc are modified from
gst_rtsp_source_dispatch_read/write and gst_rtsp_watch_reset at the
same time.
https://bugzilla.gnome.org/show_bug.cgi?id=735569
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.
* Only check for conditions we are interested in.
* Makes no sense to specify G_IO_ERR and G_IO_HUP in condition, they
will always be reported if they are true.
* Do not create timed source if timeout is NULL.
* Correctly wait for sources to be dispatched, context_iteration() is
not guaranteed to always block even if set to do so.
Fixes https://bugzilla.gnome.org/show_bug.cgi?id=726641
Previously the sequence number kept track of by GstRTPBasePayload would
only be set when going from READY to PAUSED state. This meant that a
downstream element that attempted to configure a basepayloader by
setting seqnum-offset e.g. in its sinkpad's caps template would have
trouble configuring the basepayloader. The reason was that the caps
event which arrives with the desired value for seqnum-offset did not
arrive at the basepayloader until caps negotiation took place,
significantly later than the transition from READY to PAUSED.
The result after this patch is that the default value for the
seqnum-offset property, or later set values for this property, will take
effect when going from READY to PAUSED like before. In addition the an
arriving caps event will also affect the basepayloaders configured
sequence number as the event arrives.
The payload type field in an RTP packet header is 7 bits wide, hence the
boundary values ought to be 0x00 and 0x7f, not the previously stated
values 0x00 and 0x80.
Two new functions have been added,
gst_rtsp_connection_set_tls_database() and
gst_rtsp_connection_get_tls_database(). The certificate database will be
used when a certificate can't be verified with the default database.
https://bugzilla.gnome.org/show_bug.cgi?id=724393
This was a regression introduced by f52fd7a68, where we started using
the stride to encode the dimensions in tiles. This patch simply updates
offset and size calculation as described in the documentation,
part-mediatype-video-raw.txt.
Fixes problem in audioconvert, which would end up using
a mixmatrix when converting between different mono format
because it thinks MONO positioning is different from
unpositioned channels, which is not the case in this
special case. The mixmatrix would end up being 0.0 so
audioconvert would convert to silence samples.
https://bugzilla.gnome.org/show_bug.cgi?id=724509
* Change running time type to guint64
* Use GST_CLOCK_TIME_NONE() to check for invalid timestamps
* Name variables so ns-based and hz-based timestamps are evident
Fixes https://bugzilla.gnome.org/show_bug.cgi?id=719383
We call the _get_time function from the provided clock and we don't lock
the sink object for performance reasons. Make sure we only read and
check variables once so that they don't change while we are executing
the code.
Fixes https://bugzilla.gnome.org/show_bug.cgi?id=720661
For default caps generation when handling gap events that are sent
before any buffer, try to use caps that are closer to what upstream
provided to avoid fixating rate or channels to 1 as default.
So there are the steps:
1) Try to set rate, channels and channel-mask from upstream if provided
2) Fixate the rate and channels to the default rate and channels from
audio lib
3) Fixate the caps just to be sure everything is fixed
4) If no channel-mask was provided and channels > 2, use a default
channel-mask (taken from audioconvert code)
https://bugzilla.gnome.org/show_bug.cgi?id=722144
Before trying to generate a default fixated caps when handling a gap
event, make sure that the same strategy that is used when handling
a buffer has been attempted. Otherwise audiodecoder will ignore
upstream caps settings such as rate and channels and will likely
end with a caps with channels=1 and rate=1.
https://bugzilla.gnome.org/show_bug.cgi?id=722144
Instead of using extra plane, we encode the number of tiles in x and y in the stride of
each planes (i.e. y_tiles << 16 | x_tiles) and introduce tile_mode, tile_width and
tile_height into GstVideoFormatInfo structure.
https://bugzilla.gnome.org/show_bug.cgi?id=707361
For reverse playback, the segment event will only be pushed when
the first buffer is actually pushed. But for decoding frames and storing
those into the list to be pushed the output_segment.rate value is used
to determine if it is forward or reverse playback.
In case a previous segment event (or none) is in use it will mistakenly
think it is doing forward playback and push the buffers immediatelly and
try to clip buffers based on an old segment (or an uninitialized one, leading
to an assertion)
This patch fixes this by copying the segment earlier if on reverse playback
https://bugzilla.gnome.org/show_bug.cgi?id=721666
Add a method to make a media-type from the transport. Deprecate the old
method that only used the mode.
Based on patch from Aleix Conchillo Flaqué <aleix@oblong.com>
Fixes https://bugzilla.gnome.org/show_bug.cgi?id=720219
Port a change from audiobasesink from def07410, to ignore setcaps
when the caps don't actually change, and avoid a reconfiguration
and reset of the ringbuffer in that case.
And don't assume in other code that set_format() preserves any fields at
all. These assumptions were already made here for fields that were changed
by set_format().
If there are no caps from the audio decoder when handling a GAP
event - as when one is received right at the start on a DVD without
initial audio - then choose any default caps for downstream and
then send the GAP, so the audio sink has a configured format in
which to start the ringbuffer.
Also, make the audio sink reject a GAP without caps with a clearer
error message.
Fixes bug https://bugzilla.gnome.org/show_bug.cgi?id=603921
Fixes "Unitialized Scalar Variable" issues reported by Coverity.
Has the added advantage of detecting whether somebody *does* use those
fields (ending up with a invalid address).
https://bugzilla.gnome.org/show_bug.cgi?id=720810
This must only ever be used in caps in combination with a non-system
memory GstCapsFeatures, and where it does not make sense to specify
any of the other video formats. Examples of this would be in gst-vaapi.
This reverts commit 5fcdabd907.
Instead of making it impossible to use the ENCODED format we should
just document that it must not be used for capsfeature-less caps.
Also this commit broke API/ABI.
GST_VIDEO_FORMAT_ENCODED was added to support *extracting* video-related
information (like width, height, framerate,...) from caps.
It is __NOT__ intended to be used as a format field on video/x-raw caps.
So that it avoids to send an allocation query twice.
One from an early call to gst_audio_encoder_negotiate from a
subclass, then one from gst_audio_encoder_allocate_output_buffer.
Which means that previously gst_audio_encoder_negotiate was not
clearing the GST_PAD_FLAG_NEED_RECONFIGURE even on success.
Fixes bug https://bugzilla.gnome.org/show_bug.cgi?id=719684
So that it avoids to send an allocation query twice.
One from an early call to gst_video_encoder_negotiate from a
subclass, then one from gst_video_encoder_allocate_output_frame.
Which means that previously gst_video_encoder_negotiate was not
clearing the GST_PAD_FLAG_NEED_RECONFIGURE even on success.
Fixes bug https://bugzilla.gnome.org/show_bug.cgi?id=719684
... so subclasses can release a frame all the way (also from frame list)
without having to pass through _finish_frame or _drop_frame.
The latter may not be applicable, or may or may not have already
been called for the frame in question.
See https://bugzilla.gnome.org/show_bug.cgi?id=693772
allows configuration of whether GstVideoGLTextureUploadMeta is
added to buffers resulting from a buffer pool. This is sperate
to the caps feature in that an element may want to add the upload
meta itself rather than allowing the buffer pool to.
https://bugzilla.gnome.org/show_bug.cgi?id=712798
Raise an error in case no frames are decoded before EOS and we
have input, meaning that data was received but it was somehow invalid.
Based on the videodecoder change, merged here for consistency.
https://bugzilla.gnome.org/show_bug.cgi?id=711094
Allows using -1 to make audiodecoder never post an error message
after decoding errors.
Based on the videodecoder change, merged here for consistency.
https://bugzilla.gnome.org/show_bug.cgi?id=711094
We could have allocation query before caps event and even without caps inside
the query. In such cases , the downstream can return a bufferpool object with
out actually configuring it. This feature is helpful to negotiate the bufferpool
with out knowing the output video format. For eg: some hardware accelerated
decoders can interpret the o/p video format only after it finishes the decoding
of one buffer at least.
https://bugzilla.gnome.org/show_bug.cgi?id=687183
Accumulate buffers in an adapter instead of appending them because append causes
a lot of memcpys.
Keep track of the last tagsize and accumulate enough data before attempting to
parse more data.
This patch implements a minimal amount of changes in order to not change the
behaviour. We should really rewrite the tag handling and trimming using
the adapter API instead of merging and trimming into a buffer.
Added new functions gst_rtsp_connection_set_tls_validation_flags() to
allow setting the TLS certificate validation flags when establishing a
TLS connection.
A getter is also available, gst_rtsp_connection_get_tls_validation_flags().
https://bugzilla.gnome.org/show_bug.cgi?id=711231
gst_audio_ring_buffer_set_channel_positions() checks whether the given
positions are identical with the current setup and returns
immediately if so. But it also clears need_reorder flag before this
comparison, thus this flag might be wrongly cleared if the function is
called twice with the same channel positions.
Move the flag clearance after the check.
https://bugzilla.gnome.org/show_bug.cgi?id=709754
We're checking the caps to see if we got more caps details after a parser got
plugged. This will also have a flipped 'parsed' field. If the field was already
present before the parse the match will fail. Add a function that will do the
check while excluding this field.
Creating a GSource and not attaching it to a context will cause
a leak of it's child sources. That is why we create writesrc right
before attaching it to a context.
https://bugzilla.gnome.org/show_bug.cgi?id=708667
Makes it easier to track how many users there are
Also make it possible to create a dmabuf struct on systems without mmap,
it just won't be possible to map it.
https://bugzilla.gnome.org/show_bug.cgi?id=707793
The payload type can't be between 72 and 76 because with the marker bit set,
this could be mistaken for an RTCP packet then. We do a relaxed check and
only refuse 72-76 when the marker bit is set. The effect is that when
we try to map an RTCP packet as an RTP packet, we will certainly fail.
id3mux and id3v2mux expect GST_TAG_ID3V2_FRAME type to be stored in a
GstSample and not a buffer, which is also needed because we can't
attach extradata/caps to buffers any more. These are private tags
no one should be poking at, and also the extra info is missing.
https://bugzilla.gnome.org/show_bug.cgi?id=707765
Mark terms such as "planar", "packed", and "palettized" as
translatable, and re-arrange strings a bit to make them
better suited for translation.
Also fix bug in yuv descriptions, one plane is packed, more
is planar (or semi-planar).
https://bugzilla.gnome.org/show_bug.cgi?id=707789
Windows Media Video Screen (WMV Screen) are video formats that
specilise in screencast content. This provides a correct media type
for them instead of just video/x-asf-unknown.
A successful gst_dmabuf_mem_map must always increment the mmap count.
Otherwise the first gst_dmabuf_mem_unmap will unmap the memory and all
other user will access unmapped memory.
https://bugzilla.gnome.org/show_bug.cgi?id=706680
This avoids triggering plenty of extra code/methods/overhead downstream when
we can just quickly check whenever we want to set caps whether they are
identical or not
https://bugzilla.gnome.org/show_bug.cgi?id=706600
This avoids triggering plenty of extra code/methods/overhead downstream when
we can just quickly check whenever we want to set caps whether they are
identical or not
https://bugzilla.gnome.org/show_bug.cgi?id=706600
Differs from a plain gst-launch-1.0 playbin uri=... pipeline in that
it can take multiple arguments and as such allows testing of things
like gapless playback, switching between different formats and the
like. Very minimal at this point, we'll probably want to add
interactive controls and more options at some point.
https://bugzilla.gnome.org/show_bug.cgi?id=553520
