Commit graph

170 commits

Author SHA1 Message Date
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
Sebastian Dröge
5acc099479 videodecoder: Add API to allow subclasses to specify that they needs caps before any buffers 2013-12-05 11:36:54 +01:00
Mark Nauwelaerts
40fc306017 videodecoder: make _release_frame external API
... 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
2013-12-01 12:06:37 +01:00
Mark Nauwelaerts
614d35d795 videodecoder: fix spelling error in debug message 2013-12-01 12:06:36 +01:00
Thiago Santos
81471099d2 videodecoder: error out if no frames are decoded before eos
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.

https://bugzilla.gnome.org/show_bug.cgi?id=711094
2013-11-25 10:53:25 -03:00
Thiago Santos
0765962fbc videodecoder: allow using -1 for infinite tolerated errors
Allows using -1 to make videodecoder never post an error message
after decoding errors.

https://bugzilla.gnome.org/show_bug.cgi?id=711094
2013-11-25 10:53:14 -03:00
Mark Nauwelaerts
ee86a91957 videodecoder: avoid descending output timestamps
Fixes https://bugzilla.gnome.org/show_bug.cgi?id=712796
2013-11-23 19:39:52 +01:00
Sreerenj Balachandran
cd52ff313e videodecoder: try to negotiate the buffer pool even though there is no o/p format
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
2013-11-11 13:28:11 +01:00