Haihao Xiang authored Nov 20, 2018 and Víctor Manuel Jáquez Leal committed Nov 26, 2018

Previously alloc_info is initialized when both thiz->initialized
and thiz->allocation_caps are true, but only thiz->initialized is
checked when alloc_info is used.

wangfei authored Nov 20, 2018 and Víctor Manuel Jáquez Leal committed Nov 23, 2018

Since output-order is a deprecated attribute, move it out of decode
bass class and configure it in each sub decoder class who need it.

https://bugzilla.gnome.org/show_bug.cgi?id=796853

Use async_depth for latency calcuation instead of
the length of Tasks array which could be NULL since we
don't do the msdk decoder init in set_format().

According to MediaSDK specification,
Width must be a multiple of 16 and Height must be a multiple
of 16 for progressive frame sequence and a multiple of 32 otherwise.

This patch sets a 16 bit alignment for width and 32 bit alignment
for height as default.

https://bugzilla.gnome.org/show_bug.cgi?id=796566

In cases where we do hard resest, the current code destroys the frame
which has new resolution bit early and this causes buffer_unmap
warnings. Keep an extra ref to the frame internally to avoid this.

The gst-msdk decoders only support packetized formats for
all codecs except VC1. For VC1, it supports codec_data for advanced
profiles and this codec_data wan't submitting to MSDK's DecodeHeader APIs.
Make sure the subclass deocders correctly configured so that
the codec_data buffers are in place in the internal adapter for
MediaSDK's DecoderHeader usage.

Currently we use the gst_video_decoder_get_oldest_frame()
to get the old pending frame to output. But this is not correct
if pts re-ordering required. This patch uses a custom made
get_old_frame() which accounts the PTS too similar to the
v4l2decoder.

https://bugzilla.gnome.org/show_bug.cgi?id=796699

We are not using any ExtendedParams for decoding.

The patch adds a serios of changes to support dynamic resolution
change and efficient utilization of resources.
Major changes:

-- Use MSDK's apis to retrieve the headers instead of only relying
on upsteram notification. For eg: avc decoder requires SEI header
information for dpb count calculation which we don't get from caps.

-- For all codecs other than VP9, we force the reset of decoder
if resoultion changes to fit with gstreamer flow. VP9 enfource
the hard reset only if the new resolution is bigger.

-- delay the src caps setting till msdk api's invokation in
handle_frame to avoid caching multiple configuration values

-- ensure pool negotiation is based on decoder's allocation_caps.

--dynamic resoluttion change use an explicit allocation_query
to reclaim the buffers before closing the decoder (thanks to v4l2dec)

--In case if we don't get upstream notification of res change (for eg,
this can can happen for vp9 frames with ivfheader where ivfparse
is not able to notify the dynamic changes), we handle the the case
based on MFX_ERR_INCOMPATIBLE_VIDEO_PARAM which is the return value
of MFXVideoDECODE_DecodeFrameAsync

-- calculate the minimum surfaces to be preallocated based on
msdk suggestion, downstream requirement, async depth and scratch surface
count for smooth display.

https://bugzilla.gnome.org/show_bug.cgi?id=796566

The new property "output-order" can be set to either "display" order
which is the default where frames will be outputting in display order,
or "decoded-order" which will be outputting the frames in decoded order.

The "decoded order" output is generally useful for debugging. But there
are few
customers who use it for low-latency streaming. For eg if the customer
already knows that the stream doesn't have b-frames (which means no
algorithm requires for display order calculation), then they can use
"decoded-order"
output to skip some of the DPB logic to avoid the frame accumulation at
start-up.

The root cause of the above issue is a bit of unclarity in h264 spec +
lazy implementation of many H264 encoders; This is well handled in
gstreamer-vaapi using "low-latency" property:
https://bugzilla.gnome.org/show_bug.cgi?id=762509

https://bugzilla.gnome.org/show_bug.cgi?id=795783

For packetized input, inform the msdk that the buffer has
a complete frame or complementary field pairs. For decoding,
this means that the decoder can proceed with this buffer without
waiting for the start of the next frame, which effectively reduces
decoding latency.

https://bugzilla.gnome.org/show_bug.cgi?id=795783

Currently we use an async depth of 4 as default (based on
recommendations
in msdk apps), which indicates how many asynchronous operations an
application performs
before the application explicitly synchronizes the result. As a result,
we
queue four frames in decoder which might not be good approach for
live streaming.

This patch reset the async-depth to 1 as default so that we do sync for
each frame we decode without queuing. Customer can play with already
exposed "async-depth" property for other use cases

https://bugzilla.gnome.org/show_bug.cgi?id=795783

Hyunjun Ko authored Apr 02, 2018 and Sreerenj Balachandran committed Apr 02, 2018

https://bugzilla.gnome.org/show_bug.cgi?id=793707

Hyunjun Ko authored Mar 30, 2018 and Sreerenj Balachandran committed Mar 30, 2018

https://bugzilla.gnome.org/show_bug.cgi?id=793707

Hyunjun Ko authored Mar 29, 2018 and Sreerenj Balachandran committed Mar 29, 2018

For example, if framerate 0/1 is provided from upstream, the driver
fails to configure and complain about it.

We can let it go and make the driver assuming framerate itself.

https://bugzilla.gnome.org/show_bug.cgi?id=789752

Hyunjun Ko authored Mar 08, 2018 and Sreerenj Balachandran committed Mar 08, 2018

https://bugzilla.gnome.org/show_bug.cgi?id=793708

Hyunjun Ko authored Mar 08, 2018 and Sreerenj Balachandran committed Mar 08, 2018

https://bugzilla.gnome.org/show_bug.cgi?id=793413

The gst-msdk decoders prefer packetized streams as input
and in this case we can avoid unnecessary input bitstream copy
to mfxBitstream. This works fine for codecs like h264 where
we only support byte-stream with au alignment. Other format
conversions should be done thorugh parsers. But this won't work
for codecs like vc1 where we don't have an autoplugged parser.
Even the parser is not capable to do format conversions.

Packetizing through base decoders parse() routine will bring a
lot of uncecessary of complexities and codecparser libraray dependency.
So we just use an interal gst_adaper to keep track of bitstream
which is not consumed by msdk durig AsynchronusDecoding.
This adapter will get used only if subclass implementations
set the "is_packetized" to FALSE for msdk base encoder.

https://bugzilla.gnome.org/show_bug.cgi?id=792589

Hyunjun Ko authored Feb 13, 2018 and Sreerenj Balachandran committed Feb 13, 2018

1\ If downstream's pool is MSDK bufferpool,
2\ If there's shared GstMsdkContext in the pipeline,

a decoder decides to use video memory.

This policy should be improved to handle more cases.

https://bugzilla.gnome.org/show_bug.cgi?id=790752

Hyunjun Ko authored Feb 13, 2018 and Sreerenj Balachandran committed Feb 13, 2018

In case that pipeline is like ".. ! decoder ! encoder ! ..." with using
video memory,
decoder needs to know the async depth of the following msdk element so
that it could
allocate the correct number of video memory.

Otherwise, decoder's memory is exhausted while processing.

https://bugzilla.gnome.org/show_bug.cgi?id=790752

Hyunjun Ko authored Feb 13, 2018 and Sreerenj Balachandran committed Feb 13, 2018

How to share/create GstMsdkcontext is the following:

- Search GstMsdkContext if there's in the pipeline.
  - If found, check if it's decoder, encoder or vpp by job type.
    - If it's same job type, it creates another instance of
GstMsdkContext
     with joined-session.
    - Otherwise just use the shared GstMsdkContext.
  - If not found, just creates new instance of GstMsdkContext.

https://bugzilla.gnome.org/show_bug.cgi?id=790752

Hyunjun Ko authored Feb 13, 2018 and Sreerenj Balachandran committed Feb 13, 2018

According to the driver's instruction, if there are two or more encoders
or decoders in a process, the session should be joined by
MFXJoinSession.

To achieve this successfully by GstContext, this patch adds job type
specified if it's encoder, decoder or vpp.

If a msdk element gets to know if joining session is needed by the
shared context,
it should create another instance of GstContext with joined session,
which
is not shared.

https://bugzilla.gnome.org/show_bug.cgi?id=790752

Hyunjun Ko authored Feb 13, 2018 and Sreerenj Balachandran committed Feb 13, 2018

1\ In decide_allocation, it makes its own msdk bufferpool.
  - If downstream supports video meta, it just replace it with the msdk
bufferpool.
  - If not, it uses the msdk bufferpool as a side pool, which will be
decoded into.
    and will copy it to downstream's bufferpool.

2\ Decide if using video memory or system memory.
  - This is not completed in this patch.
  - It might be decided in update_src_caps.
  - But tested for both system memory and video memory cases.

https://bugzilla.gnome.org/show_bug.cgi?id=790752

Hyunjun Ko authored Feb 13, 2018 and Sreerenj Balachandran committed Feb 13, 2018

https://bugzilla.gnome.org/show_bug.cgi?id=790752

Hyunjun Ko authored Feb 13, 2018 and Sreerenj Balachandran committed Feb 13, 2018

Makes GstMsdkContext to be a descendant of GstObject so that
we could track the life-cycle of the session of the driver.

Also replaces MsdkContext with this one.
Keeps msdk_d3d.c alive for the future.

https://bugzilla.gnome.org/show_bug.cgi?id=790752

Hyunjun Ko authored Feb 13, 2018 and Sreerenj Balachandran committed Feb 13, 2018

Move the msdk_video_alignment function from decoder
to msdk.c and rename so that others could call this function
without duplicated declaration.

https://bugzilla.gnome.org/show_bug.cgi?id=790752

Hyunjun Ko authored Nov 23, 2017 and Sebastian Dröge committed Nov 23, 2017

Should continue draining so that it could try to
discard the rest of pending frames even if a finish_task fails.

https://bugzilla.gnome.org/show_bug.cgi?id=790312

Hyunjun Ko authored Nov 22, 2017 and Sebastian Dröge committed Nov 22, 2017

https://bugzilla.gnome.org/show_bug.cgi?id=790312

Scott D Phillips authored Jan 20, 2017 and Sreerenj Balachandran committed Jan 20, 2017

In some places a GST_FLOW_FLUSHING result was return as a FALSE
gboolean and then returned from a parent function as
GST_FLOW_ERROR. This prevented seeking from working.

https://bugzilla.gnome.org/show_bug.cgi?id=776360

Scott D Phillips authored Nov 07, 2016 and Josep Torra committed Dec 12, 2016

The decoder only supports system memory output presently.

https://bugzilla.gnome.org/show_bug.cgi?id=774587