They take a GstBaseSink instance as argument at not a GstPad. Rename the
argument to 'obj' which is not miss leading and in line with
GST_BASE_SINK_PAD(obj).
https://bugzilla.gnome.org/show_bug.cgi?id=756954
gst_segment_to_position might cause confusion, especially with the addition of
gst_segment_position_from_stream_time . Deprecated gst_segment_to_position
now, and replaced it with gst_segment_position_from_running_time.
Also added unit tests.
There exist cases where a reconfigure event was propagated from
downstream, but caps didn't change. In this case, we would
reconfigure only when the next buffer arrives. The problem is that
due to the allocation query being cached, the return query parameters
endup outdated.
In this patch we refactor the reconfigurating code into a function, and
along with reconfiguring when a new buffer comes in, we also reconfigure
when a query allocation arrives.
https://bugzilla.gnome.org/show_bug.cgi?id=753850
Explicitly keep track again whether upstream tags or parser tags
already contain bitrate information, and only force a tag update
for a bitrate if we are actually going to add the bitrate to the
taglist later. This fixes constant re-sending of the same taglist,
because upstream provided a bitrate already and we didn't add it,
so we didn't save the 'posted' bitrate, which would then in turn
again trigger the 'bitrate has changed too much, update tags'
code path. Fixes tag spam with m4a files for example.
https://bugzilla.gnome.org/show_bug.cgi?id=679768
In 0.10 there were no sticky events, and all tag events
sent would just be merged with the previously-received
tags. In 1.x we have sticky events, and the tags in the
tag event(s) should at all times carry the complete tags,
so we can't just push some tags and then just push tags
with just bitrates to update the bitrates, etc.
Instead we need to keep track of the upstream stream tags
received, of the tags set by the video decoder subclass,
and send an updated tag event with the combined tags
including our own bitrate tags (if applicable) whenever
the upstream tags, the subclass tags or any of our bitrates
change.
https://bugzilla.gnome.org/show_bug.cgi?id=679768
This is needed so that we can do proper tag handling
all around, and combine the upstream tags with the
tags set by the subclass and any extra tags the
base class may want to add.
API: gst_base_parse_merge_tags()
https://bugzilla.gnome.org/show_bug.cgi?id=679768
Use gst_pad_peer_query_duration() and remove a few
unnecessary levels of indentation. Rest of code might
looks a bit questionable, but leave it as is for now.
According to the design docs:
The ACCEPT_CAPS query is not required to work recursively, it can simply
return TRUE if a subsequent CAPS event with those caps would return
success.
So make it a shallow check instead of recursivelly check downstream.
https://bugzilla.gnome.org/show_bug.cgi?id=748635
GstPad has a flag for suggesting if the accept-caps
query should use intersect instead of the default
subset caps operation to verify if the caps would be
acceptable.
basetransform currently always uses the subset check and
this patch makes it honor the flag for using intersect
if it is set.
https://bugzilla.gnome.org/show_bug.cgi?id=748635
As of now, even for stream completly inside segment, there is no
guarantied that the DTS will be inside the segment. Specifically
for H.264 with B-Frames, the first few frames often have DTS that
are before the segment.
Instead of using the sync timestamp to clip out of segment buffer,
take the duration from the start/stop provided by the sub-class, and
check if the pts and pts_end is out of segment.
https://bugzilla.gnome.org/show_bug.cgi?id=752791
gst_query_find_allocation_meta() requires the query to be
writable to work. This patch ensure avoids taking a reference
on the query, so we can now check if a certain allocation meta
is present.
https://bugzilla.gnome.org/show_bug.cgi?id=752661
This line has no purpose, clearly gst_segment_do_seek() is doing
the right job, also, having the start time (a timestamp) be that
same as time (the stream time) is quite odd.
https://bugzilla.gnome.org/show_bug.cgi?id=750783
For files which are smaller than 1.5 seconds, the duration
estimation does not happen. So the duration will always be
displayed as 0. Updating the duration on EOS when the estimation
has not happened already
https://bugzilla.gnome.org/show_bug.cgi?id=750131
We must make the buffer writable to write its PTS and DTS, and also
reset its duration.
The behaviour is now the same as before commit c3bcbadd, except metas
might still be attached to the buffer extracted from the adapter.
https://bugzilla.gnome.org/show_bug.cgi?id=752092
This way we don't have to allocate/free temporary structs
for storing things in the queue array.
API: gst_queue_array_new_for_struct()
API: gst_queue_array_push_tail_struct()
API: gst_queue_array_peek_head_struct()
API: gst_queue_array_pop_head_struct()
API: gst_queue_array_drop_struct()
https://bugzilla.gnome.org/show_bug.cgi?id=750149
POOL meta just means that this specific instance of the meta is related to a
pool, a copy should be made when reasonable and the flag should just not be
set in the copy.
POOL meta just means that this specific instance of the meta is related to a
pool, a copy should be made when reasonable and the flag should just not be
set in the copy.
This preserves GstMeta properly unless the subclass does special things. It's
enough to make h264parse's stream-format/alignment conversion pass through
metas as needed.
https://bugzilla.gnome.org/show_bug.cgi?id=742385
All functions that return a GstBuffer or a list of them will now copy
all GstMeta from the input buffers except for meta with GST_META_FLAG_POOLED
flag or "memory" tag.
This is similar to the existing behaviour that the caller can't assume
anything about the buffer flags, timestamps or other metadata. And it's
also the same that gst_adapter_take_buffer_fast() did before, and what
gst_adapter_take_buffer() did if part of the first buffer or the complete
first buffer was requested.
https://bugzilla.gnome.org/show_bug.cgi?id=742385
The doc generator get confused with the inline structure. So
workaround by wrapping the inner of the structure with
public/private mark, and document that GST_COLLECT_PADS_DTS macro
shall be used to access this.
* Fix function name in sections.txt
* Add few missing or fix miss-named
* Workaround gtk-doc being confused with non typedef
types (loose track of public/private
There was few Since: mark missing their column. Also unify the way
we set the Since mark on enum value and structure members. These
sadly don't show up in the index.
These are not usable as they are, and can easily lead to crash
or leaks. This also silence warning from the scanner. If we manage to
make this usable, we can then remove that mark, it will require
to make this type boxed.
gstbasetransform.h:196: Warning: GstBase: "@submit_input_buffer" parameter unexpected at this location:
* @submit_input_buffer: Function which accepts a new input buffer and pre-processes it.
gstnetcontrolmessagemeta.c:103: Warning: GstNet: gst_buffer_add_net_control_message_meta: unknown parameter 'message' in documentation comment, should be 'addr'
Make gst_collect_pads_clip_running_time() function also store the
signed DTS in the CollectData. This signed DTS value can be used by
muxers to properly handle streams where DTS can be negative initially.
https://bugzilla.gnome.org/show_bug.cgi?id=740575
