Commit graph

177 commits

Author SHA1 Message Date
Jan Schmidt
4b373d4c97 videodecoder: Copy multiview-mode, flags and view count from ref info
When copying info from the reference input state, duplicate
all the fields of the video info. The sub-class will have the
chance to override them later.
2015-06-13 01:36:45 +10:00
Sebastian Dröge
f74524b58d videodecoder: Also negotiate with downstream if needed before handling a GAP event 2015-05-08 15:07:56 +02:00
Sebastian Dröge
21b5741251 videodecoder: Try to be smarter when clipping buffers without duration/framerate to the segment
2 second frame duration is rather unlikely... but if we don't clip
away buffers that far before the segment we can cause the pipeline to
lockup. This can happen if audio is properly clipped, and thus the
audio sink does not preroll yet but the video sink prerolls because
we already outputted a buffer here... and then queues run full.

In the worst case we will clip one buffer too many here now if no
framerate is given, no buffer duration is given and the actual
framerate is less than 0.5fps.

Fixes seeking on HLS/DASH streams, when seeking into the middle of
fragments and having no framerate/buffer duration.
2015-05-06 12:42:33 +02:00
Sebastian Dröge
6539d1da29 videodecoder: Break instead of return if default negotiation on GAP events fails
Otherwise we're going to leak the event.
2015-04-11 19:52:50 +02:00
Sebastian Dröge
f268f2be92 videodecoder: Try to invent default caps instead of setting none at all when getting a GAP event before CAPS
Otherwise we would forward the GAP event without ever providing any caps,
which then would make decodebin expose a srcpad without any caps set. That's
confusing for applications and can lead to all kinds of interesting bugs.

Instead do the same as already is done in GstAudioDecoder, and try to invent
caps based on the sinkpad caps and the caps allowed by downstream and the
srcpad template caps.

https://bugzilla.gnome.org/show_bug.cgi?id=747190
2015-04-08 20:49:39 -07:00
Sebastian Dröge
0c72d0acdf {audio,video}decoder: Forward SEGMENT_DONE events immediately and drain decoders
Otherwise we're going to wait with draining until the next data comes, which
is a bit suboptimal and might take a long time... or maybe never happens.
2015-04-06 19:20:51 -07:00
Vincent Penquerc'h
2954813b86 audio,video: use gst_segment_is_equal instead of memcmp
memcmp will blindly compare the reserved fields, as well as any
padding the compiler may choose to sprinkle in GstSegment.

Fixes valgrind complaints in unit tests, as well as some found via
https://bugzilla.gnome.org/show_bug.cgi?id=738216
2015-04-03 12:09:41 +01:00
Mark Nauwelaerts
f134072c66 videodecoder: only return EOS upon clipping if applicable
See also https://bugzilla.gnome.org/show_bug.cgi?id=709224
2015-03-07 20:12:23 +01:00
Jan Schmidt
af26201429 videodecoder: Add drain() vfunc
drain() is a new vfunc which does what finish() does, while
explicitly requiring the decoder be able to continue processing
data afterward.

https://bugzilla.gnome.org/show_bug.cgi?id=734617
2015-02-24 01:36:44 +11:00
Mark Nauwelaerts
ccee86a7dd Revert "videodecoder: drain current segment upon new one to ensure correct flow return"
This reverts commit cc1b4eaf9e.

See https://bugzilla.gnome.org/show_bug.cgi?id=734617
2015-02-22 16:59:08 +01:00
Mark Nauwelaerts
cc1b4eaf9e videodecoder: drain current segment upon new one to ensure correct flow return
See also https://bugzilla.gnome.org/show_bug.cgi?id=709224
2015-02-22 13:23:44 +01:00
Thiago Santos
7e39a51a50 audio: video: fix a few GI annotations
transfer-full -> transfer full
@Since -> Since
2015-02-19 15:51:42 -03:00
Sebastian Dröge
8547594727 Improve and fix LATENCY query handling
This now follows the design docs everywhere, especially the maximum latency
handling.

https://bugzilla.gnome.org/show_bug.cgi?id=744106
2015-02-11 17:53:49 +02:00
Sebastian Dröge
aa645b11f1 video{enc,dec}oder: Don't reset latency all the time and handle max=GST_CLOCK_TIME_NONE correctly
max=NONE means that *this* element has no maximum latency. If upstream had a
maximum latency we must not override it with NONE.
2015-02-03 12:24:01 +01:00
Sebastian Dröge
87d6c265a8 video{en,de}coder: Call reset() before the start() vfunc
This makes sure that the element is in the same state before start() is called
the very first time and every future call after the element was used already.

Also it ensure that we always have a clean state before start(), cleaned the
same way in every case.
2014-12-22 11:38:20 +01:00
Sebastian Dröge
098b42f36b video{en,de}coder: Reset the codec after calling the stop() vfunc
The stop() vfunc might mess with some of our fields we have just
reset, which could cause memory leaks or invalid state taken over
to later.

Also the stop() vfunc, or anything called until it from another thread,
might want to be able to use the fields that were just resetted and
become confused because of that.

In the decoder we already had a workaround for things like this happening,
this workaround is not needed anymore.
2014-12-22 11:33:14 +01:00
Thiago Santos
8085352fb3 videodecoder: expose getcaps virtual function
Allows subclasses to do custom caps query replies.

Also exposes the standard caps query handler so subclasses can just
extend on top of it instead of reimplementing the caps query proxying.

https://bugzilla.gnome.org/show_bug.cgi?id=741263
2014-12-17 19:15:23 -03:00
Thiago Santos
4956800549 videodecoder: accept-caps should only require fields from the template
With the new caps query results the caps returned might have extra fields
that are not required by the decoder (framerate for image decoders) and it
causes a regression making, for example, jpegdec reject caps that don't
have framerates.

The accept-caps implementation will do 2 checks:

1) Do subset check with the template caps, making sure all the required
fields that are present on the template are present on the received caps.
2) Do a intersection check with the result of a caps query, making sure
that downstream can accept the fields in the received caps.

https://bugzilla.gnome.org/show_bug.cgi?id=741263
2014-12-17 19:15:23 -03:00
Thiago Santos
f24075887f videodecoder: implement caps query
Refactor the encoder's caps query proxying function to a common place
and use it in the videodecoder to proxy downstream restrictions.

The new function is private to the gstvideo lib.

https://bugzilla.gnome.org/show_bug.cgi?id=741263
2014-12-17 19:15:23 -03:00
Thiago Santos
2034e5c153 videodecoder: do not use fixed caps on source pad
decoders can change the caps on their source pads, so they don't
use fixed caps. Having fixed caps can cause renegotiation issues.
2014-12-11 17:35:03 -03:00
Ognyan Tonchev
29f548a7cd videodecoder: do not leak events when flushing them
https://bugzilla.gnome.org/show_bug.cgi?id=736796
2014-09-18 12:40:15 +03:00
Ognyan Tonchev
787b3fa7ec videodecoder: do not leak pool and allocator in error case
https://bugzilla.gnome.org/show_bug.cgi?id=736679
2014-09-15 10:43:23 -04:00
Sebastian Dröge
0a19783291 videodecoder: Fix broken boolean expression
We can seek with end_type==NONE and end_type==SET && end_position=-1. The
check for end_type!=NONE made the second condition impossible.

CID 1226440
2014-08-28 17:06:22 +03:00
Jan Schmidt
946dc6b09f videodecoder: Reset last_timestamp_out on new segment
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
2014-08-14 17:59:06 +10:00
Jan Alexander Steffens (heftig)
8a1f8623fa videodecoder: Don't set decoding timestamps on raw video
https://bugzilla.gnome.org/show_bug.cgi?id=733720
2014-08-11 10:29:33 +02:00
George Kiagiadakis
a4d97f49e2 videodecoder: In reverse playback, flush the output queue after decoding each keyframe chain
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
2014-08-11 10:22:55 +02:00
Sebastian Dröge
11ef208736 videodecoder: Handle CAPS events immediately instead of delaying them
https://bugzilla.gnome.org/show_bug.cgi?id=733147
2014-07-21 09:35:37 +02:00
Gwenole Beauchesne
fb44ec9615 videodecoder: parse any source data that is still available.
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>
2014-07-03 09:47:20 +02:00
Evan Nemerson
7b791749a0 docs: Assorted documentation and introspection fixes for new 1.4 API
https://bugzilla.gnome.org/show_bug.cgi?id=732595
2014-07-02 09:09:44 +02:00
Thibault Saunier
d2ea3260e9 videodecoder: Keep still meaningfull pending events on FLUSH_STOP
Only EOS and segment should be deleted in that case.

+ Add a testcase

https://bugzilla.gnome.org/show_bug.cgi?id=709868
2014-06-03 13:03:49 +02:00
Thiago Santos
0cb5ea4396 videodecoder: actually return the push result in backwards playback
It was always returning _OK regardless of what downstream returned
2014-05-26 23:24:56 -03:00
Thiago Santos
ff9e37ea66 videodecoder: return EOS when segment is over
if a buffer is clipped by being completely out of segment, check if this
buffer is after the end of the segment and return EOS upstream

https://bugzilla.gnome.org/show_bug.cgi?id=709224
2014-05-26 19:26:45 -03:00
Edward Hervey
ec95963b1f videodecoder: Free data after removing it from the list
While it wouldn't have caused any failures (g_list_remove doesn't dereference
the provided pointer), it does make the code cleaner.

CID #1212174
2014-05-12 17:17:07 +02:00
Nicolas Dufresne
64d58b80c0 videodecoder: Retry setting configuration with modified config
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.
2014-05-08 15:09:47 -04:00
Thiago Santos
5ac9476b40 videodecoder: do not parse caps for not using it
Saving some cpu
2014-05-01 19:31:25 -03:00
Thiago Santos
05e957106f videodecoder: do not deactivate the bufferpool, just unref
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
2014-04-04 13:50:03 -03:00
Sebastian Dröge
6189847ed0 videodecoder: Always drain the decoder after a discont group in reverse playback mode 2014-03-30 18:26:59 +02:00
Sebastian Dröge
5a4fbb1638 videodecoder: Flush the decoder once per discont group, not once per keyframe 2014-03-30 18:00:53 +02:00
Sebastian Dröge
f1f8731ff5 videodecoder: Handle reverse playback with multiple GOPs per discont group properly
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.
2014-03-30 17:59:55 +02:00
Sebastian Dröge
50c2218d4d videodecoder: Log event types of events that are pushed downstream 2014-03-29 10:33:01 +01:00
Sebastian Dröge
1c26e5734c videodecoder: In reverse playback mode we need to finish the subclass after passing all frames to it 2014-03-29 10:33:01 +01:00
Sebastian Dröge
87829debe4 videodecoder: Add API to get the currently pending frame size for parsing
https://bugzilla.gnome.org/show_bug.cgi?id=719890
2014-01-18 13:54:22 +01:00
Thiago Santos
47f720a8f0 videodecoder: plug leak when frames are released on subclass stop
They end up stored in the 'pending_events' list and should be
freed after calling stop
2014-01-17 11:21:33 -03:00
Wim Taymans
ecac298e4e videodecoder: only copy chroma_site when known
Only overwrite the chroma-site if we have a valid value in the reference
format.
2014-01-13 17:24:01 +01:00
Thiago Santos
672cda66db videodecoder: do not lose events when dropping frames
Events must be persisted after a frame is dropped to avoid
losing obligatory information for the stream.

https://bugzilla.gnome.org/show_bug.cgi?id=721835
2014-01-13 06:11:09 -03:00
Thiago Santos
5b8e1925b5 videodecoder: use new segment earlier for reverse playback
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
2014-01-13 06:11:09 -03:00
Julien Isorce
2e38741b94 videodecoder: release buffer pool and allocator on full reset
It allows to release the buffer pool sooner (i.e. when going
to GST_STATE_READY). Previously it was released in finalize.

Fixes bug https://bugzilla.gnome.org/show_bug.cgi?id=720389
2013-12-16 16:07:05 +00:00
Sebastian Dröge
b5d26f3907 videodecoder: gst_video_decoder_release_frame() is available since 1.2.2 2013-12-13 14:37:24 +01:00
Nicolas Dufresne
09a6ca97d2 videodecoder: Add sink_query() src_query() virtual
https://bugzilla.gnome.org/show_bug.cgi?id=720103
2013-12-09 09:41:46 -05:00
Julien Isorce
79ef75888c videodec/enc: clear reconfigure flag if negotiate succeeds
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
2013-12-05 15:19:16 +00:00