Commit graph

274 commits

Author SHA1 Message Date
Tim-Philipp Müller
39e21bb6dd baseparse: fix taglist update spam
We would constantly re-post the taglist because
posted_avg_rate only gets set to avg_bitrate if
parse->priv->post_avg_bitrate is true, so if it's
false the posted rate will always differ from the
current average rate and we'd queue an update,
which leads to us spamming downstream and the
application with taglist updates.

Fix this by only queuing an update if the average
rate will actually be posted.

These taglists updates could cause expensive
operations on the application side, e.g. in Totem.

https://bugzilla.gnome.org/show_bug.cgi?id=786561
2017-08-25 17:36:33 +01:00
Nicolas Dufresne
632952be87 baseparse: sinkcaps can be NULL in default caps negotiation
This was causing harmless assertion about the unreffed caps not being of
type caps.

https://bugzilla.gnome.org/show_bug.cgi?id=784041
2017-06-22 16:00:45 -04:00
Sebastian Dröge
35b426ff19 base: Export boxed type copy/free functions for the remaining types 2017-06-20 09:57:01 +03:00
Jan Schmidt
e571002dcb baseparse: Don't forget error returns when processing more
If parsing returns a non-OK flow return in the middle
of processing an input buffer, don't overwrite that
if a later return is OK again - the subclass might
return not-linked in the middle, and then discard
subsequent data without pushing while returning OK.

A later success doesn't invalidate the earlier failure,
but we should continue processing after not-linked, so
as to keep parse state consistent.

https://bugzilla.gnome.org/show_bug.cgi?id=779831
2017-03-22 11:42:53 +11:00
Thibault Saunier
a87b4551a6 Port gtk-doc comments to their equivalent markdown syntax
Modernizing our documentation and preparing a possible move to hotdoc.
This commits also adds missing @title metadatas to all SECTIONs
2017-01-27 16:36:38 -03:00
Julien Isorce
b2c05cac8e baseparse: correctly handle non-flush seek
Otherwise when seeking/looping to the start when reaching the end,
the sink waits for the duration of the stream. So the user hears
nothing for the duration of the stream before it actually loop again.
See example attached to the bug for that.

Existing test:
gst-plugins-good/tests/icles/test-segment-seeks foo.flac
Without the patch the user hears a crack/cut at each seek.

https://bugzilla.gnome.org/show_bug.cgi?id=777780
2017-01-26 16:51:21 +00:00
Mark Nauwelaerts
9bcebaacc7 baseparse: also unset DISCONT on buffers in reverse playback fragments 2016-12-28 13:46:33 +01:00
Jan Schmidt
2e579a7c1b baseparse: Fix previous commit
Check the correct segment format value.

parse->segment.format is the format we're outputting in,
not the upstream format. Use parse->priv->upstream_format instead,
and make sure it's set in pull mode.
2016-11-16 00:30:26 +11:00
Jan Schmidt
d81c0aec81 baseparse: Restrict query/convert responses when demuxing
If the parser is not parsing a raw elementary stream, restrict
the position, duration and conversion query replies to
things we can sensibly answer about - especially don't do
random conversions to/from bytes.
2016-11-16 00:12:22 +11:00
Tim-Philipp Müller
bce5d0fc55 baseparse: add since marker for new API to docs and fix win32 .def file 2016-11-10 13:49:29 +00:00
Vincent Penquerc'h
4caf66fbca baseparse: expose gst_base_parse_drain 2016-11-10 12:47:37 +00:00
Sebastian Dröge
9ea6af280d Revert "baseparse: fix draining with less data than min frame size available"
This reverts commit 2e278aeb71.

Some parsers, specifically audio parsers, assume to get all remaining
data on EOS and just pass them onwards. While the idea here is correct,
we will probably need a property for this on baseparse for parsers to
opt-in.

https://bugzilla.gnome.org/show_bug.cgi?id=773666
2016-11-02 09:35:05 +02:00
Tim-Philipp Müller
2e278aeb71 baseparse: fix draining with less data than min frame size available
baseparse would pass whatever is left in the adapter to the
subclass when draining, even if it's less than the minimum
frame size required. This is bogus, baseparse should just
discard that data then. The original intention of that code
seems to have been that if we have more data available than
the minimum required we should pass all of the data available
and not just the minimum required, which does make sense, so
we'll continue to do that in the case that more data is available.

Fixes assertions in rawvideoparse on EOS after not-negotiated with
fakesrc sizetype=random ! queue ! rawvideoparse format=rgb ! appsink caps=video/x-raw,format=I420

https://bugzilla.gnome.org/show_bug.cgi?id=773666
2016-11-01 20:33:56 +02:00
Thibault Saunier
4714ef2f8e Make use of the new GST_ELEMENT_FLOW_ERROR API all around.
https://bugzilla.gnome.org/show_bug.cgi?id=770158
2016-08-27 09:33:20 -03:00
Jan Alexander Steffens (heftig)
d71e03b3be baseparse: Don't add calculated bitrates until threshold
Waiting before posting calculated bitrates seems to be the
intent of the code, so avoid adding them to the tag list
pushed with the first frame.

When the threshold is reached, gst_base_parse_update_bitrates
sets tags_changed, so this posts the calculated ones right
that moment.

This prevents an insane average calculated from just the
first (key) frame from getting posted.

https://bugzilla.gnome.org/show_bug.cgi?id=768439
2016-07-05 19:42:38 +03:00
Sebastian Dröge
8e8b8a8d34 baseparse: Make sure to not create an invalid event order when generating the default CAPS event because of a GAP event
There must be a SEGMENT event before the GAP event, and SEGMENT events must
come after any CAPS event. We however did not produce any CAPS yet, so we need
to ensure to insert the CAPS event before the SEGMENT event into the pending
events list.

https://bugzilla.gnome.org/show_bug.cgi?id=766970
2016-07-04 10:35:41 +02:00
Edward Hervey
ea395c2498 baseparse: Make sure DISCONT flags are properly propagated
If we drop a frame that contained a discontinuity, we must remember
that for the next frame that *will* be pushed downstream.

https://bugzilla.gnome.org/show_bug.cgi?id=766795
2016-06-07 09:42:39 +02:00
Sebastian Dröge
5294065985 baseparse: Remember if we interpolated DTS from PTS and refresh it whenever we update the PTS
Otherwise PTS and DTS will come out of sync if upstream continues to provide
PTS and not DTS, and we have to skip some data from the stream or PTS are not
exactly increasing with the duration of each packet.

https://bugzilla.gnome.org/show_bug.cgi?id=765260
2016-04-20 11:49:24 +03:00
Sebastian Dröge
895332e056 baseparse: When initializing DTS from PTS, remember that we did so
If we don't store the value in prev_dts, we would over and over again
initialize the DTS from the last known upstream PTS. If upstream only provides
PTS every now and then, then this causes DTS to be rather static.

For example in adaptive streaming scenarios this means that all buffers in a
fragment will have exactly the same DTS while the PTS is properly updated. As
our queues are now preferring to do buffer fill level calculations on DTS,
this is causing huge problems there.

See https://bugzilla.gnome.org/show_bug.cgi?id=691481#c27 where this part of
the code was introduced.

https://bugzilla.gnome.org/show_bug.cgi?id=765096
2016-04-15 16:02:29 +03:00
Sebastian Dröge
87c0513569 baseparse: Recheck after pre_push_frame() if there are tags pending
Many parsers are storing tags only in pre_push_frame(), if we wouldn't check
afterwards we would push buffers before those tags and a lot of code assumes that
tags are available before preroll.

https://bugzilla.gnome.org/show_bug.cgi?id=763553
2016-03-14 12:23:29 +02:00
Tim-Philipp Müller
78a832ebd5 baseparse: fix stray discont flag set on outgoing buffers in push mode
We have no guarantees about what flags are set on buffers we take
out of the GstAdapter. If we push out multiple buffers from the
first input buffer (which will have discont set), only the first
buffer we push out should be flagged as discont, not all of the
buffers produced from that first initial input buffer.

Fixes issue where the first few mp3 frames/seconds of data in push
mode were skipped or garbled in some cases, and the discont flags
would also trip up decoders which were getting drained/flushed for
every buffer. This was a regression introduced in 1.6 apparently.
2016-02-04 19:04:41 +00:00
HoonHee Lee
f90fd86d5f baseparse: Try to generate caps on the srcpad before forwarding GAP event
To configure downstream elements and complete initial pre-rolling,
ensure we have default output caps before forwarding GAP event.

https://bugzilla.gnome.org/show_bug.cgi?id=753899
2016-01-29 10:49:24 +01:00
Athanasios Oikonomou
d10c488d63 baseparse: post tag list when avg bitrate changes at least 2%
Watching videos with variant bitrate is common to have delta
more than 10 kbps, resulting in tag list spam.

Instead of relying on fixed 10 kpbs delta, it is better to
calculale the difference in percentage and update tag list
only when bitrate changes more than 2%.

https://bugzilla.gnome.org/show_bug.cgi?id=759055
2015-12-08 11:34:13 +02:00
Thiago Santos
b93369c78a Revert "baseparse: do not overwrite header buffer timestamps"
This reverts commit 2c475a0355.

This causes issues with h264parse. It breaks timestamps as
there are headers in the middle of the stream and this patch
makes the timestamps for those differ from the ones that
are adjusted, creating a discontinuity and leading to sync
issues.
2015-11-19 00:57:17 -03:00
Thiago Santos
5feba38a4e Revert "baseparse: simplify code a bit"
This reverts commit 3984f7159a.
2015-11-19 00:57:08 -03:00
Thiago Santos
3984f7159a baseparse: simplify code a bit
Avoid repeated checks for testing if a buffer is a header
2015-11-16 08:22:14 -03:00
Thiago Santos
971ac61c36 baseparse: do not overwrite header buffer timestamps
baseparse tries to preserve timestamps from upstream if
it is running on a time segment and write that to
output buffers. It assumes the first DTS is going to be
segment.start and sets that to the first buffers. In case
the buffer is a header buffer, it had no timestamps and
will have only the DTS set due to this mechanism.

This patch prevents this by skipping this behavior for
header buffers.

https://bugzilla.gnome.org/show_bug.cgi?id=757961
2015-11-14 10:50:35 -03:00
Edward Hervey
55f6582159 baseparse: Update internal position even if not linked
Our current position has nothing to do with being linked or not.

Avoids having stray segment updates fired every 2s
2015-10-12 17:30:38 +02:00
Tim-Philipp Müller
a887d81bfa baseparse: avoid tag list spam if upstream provides bitrate tags already
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
2015-08-18 15:51:53 +01:00
Tim-Philipp Müller
4ec358773a baseparse: fix tag handling
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
2015-08-16 14:32:24 +01:00
Tim-Philipp Müller
41b85d91eb baseparse: add API for subclass to set tags
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
2015-08-16 14:32:23 +01:00
Tim-Philipp Müller
d60c249f51 baseparse: save upstream stream tags
We'll need those later.

https://bugzilla.gnome.org/show_bug.cgi?id=679768
2015-08-16 12:29:10 +01:00
Tim-Philipp Müller
bc1fb2d8b0 baseparse: minor code simplification
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.
2015-08-15 18:41:31 +01:00
Nicolas Dufresne
5b5cebf540 baseparse: Don't override gst_segment_do_seek()
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
2015-07-17 17:44:52 -04:00
Nicolas Dufresne
8b6e8701d5 baseparse: Fix extrapolation of seeksegment.stop
The stop shall be relative to start if extrapolated from the
duration.

https://bugzilla.gnome.org/show_bug.cgi?id=750783
2015-07-17 17:44:44 -04:00
Vineeth TM
6d78d32d51 baseparse: estimate duration on EOS
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
2015-07-10 15:23:43 -04:00
Arnaud Vrac
ea8cabe084 baseparse: put buffer in a correct state after gst_adapter_get_buffer call
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
2015-07-08 13:33:37 +03:00
Vineeth TM
274f4b784a baseparse: reverse playback in pull mode
right now reverse playback is disabled in pull mode.
enabling the code for the same and changing a bit of logic
to make reverse playback work.

https://bugzilla.gnome.org/show_bug.cgi?id=750783
2015-07-06 09:56:27 -04:00
Sebastian Dröge
c3bcbadd54 baseparse: Use new gst_adapter_get_buffer() API instead of gst_adapter_map()
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
2015-06-30 18:40:28 +02:00
Ilya Konstantinov
b58245ac0a baseparse: fix GST_BASE_PARSE_FLAG_LOST_SYNC
Since frame->priv->discont was cleared earlier,
GST_BASE_PARSE_FLAG_LOST_SYNC was never being set.

Take the chance to refactor the frame creation a bit to
organize the flags setting and reset.

https://bugzilla.gnome.org/show_bug.cgi?id=738237
2015-04-28 12:57:35 -03:00
Thiago Santos
8641997630 baseparse: respect DISCONT flag on buffers
Drain the parser when a DISCONT buffer is received and then mark
the next buffer to be pushed as a DISCONT one

https://bugzilla.gnome.org/show_bug.cgi?id=745927
2015-04-28 12:54:08 -03:00
Sebastian Dröge
370076edd5 baseparse: Forward SEGMENT_DONE events immediately
There might be no more data coming afterwards, and we just drained everything
that was left to be pushed anyway.
2015-04-06 18:46:06 -07:00
Thiago Santos
a041d8862d baseparse: only post 'no valid frames' error if buffers were received
Otherwise baseparse will consider empty streams to be an error while
an empty stream is a valid scenario. With this patch, errors would
only be emitted if the parser received data but wasn't able to
produce any output from it.

This change is only for push-mode operation as in pull mode an
empty file can be considered an error for the one driving the
pipeline

Includes a unit test for it

https://bugzilla.gnome.org/show_bug.cgi?id=733171
2015-03-26 12:25:57 -03:00
Olivier Crête
187570aded baseparse: remove duplicate code
These are already freed by gst_base_parse_clear_queues()

https://bugzilla.gnome.org/show_bug.cgi?id=679768
2015-03-17 19:35:08 +00:00
Vincent Penquerc'h
780f71c4d5 baseparse: reset skip on segments and discontinuities
Large scale skip is an optimization, and thus it is safer to
stop skipping than to continue. Clear skip on segments and
discontinuities, as these are points where it is possible that
the original idea of "bytes to skip" changes.
2015-03-16 12:53:50 +00:00
Edward Hervey
c1d2254b23 baseparse: Don't emit errors on EOS if we saw GAP events
If we saw GAP events (meaning the streams is advancing) before we get
EOS, we should not post an ERROR, since it is not fatal.

https://bugzilla.gnome.org/show_bug.cgi?id=745143
2015-02-26 07:52:05 +01:00
Mark Nauwelaerts
aca7faf520 baseparse: drain segment upon SEGMENT_DONE to ensure proper event order 2015-02-23 20:08:20 +01:00
Mark Nauwelaerts
84f0410186 baseparse: clean up some bogus commented code 2015-02-23 20:08:20 +01:00
Sebastian Dröge
4a5ce862a2 Improve and fix LATENCY query handling
This now follows the design docs everywhere.

https://bugzilla.gnome.org/show_bug.cgi?id=744106
2015-02-11 17:53:04 +02:00
Vincent Penquerc'h
dd40d99710 baseparse: jump over large skips in pull mode
This bypasses the dumping of buffers we still have to do in push mode.

https://bugzilla.gnome.org/show_bug.cgi?id=730053
2014-12-18 13:11:46 +00:00