GitLab

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

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 Apr 02, 2018 and Sreerenj Balachandran committed Apr 02, 2018

As long as we negotiate the "DMABuf" capsfeatures for now, map can't be
working. So we need to confirm not to do it if using DMABuf memory.

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 30, 2018 and Sreerenj Balachandran committed Mar 30, 2018

This patch includes:
1\ Implements MsdkDmaBufAllocator and allocation of msdk dmabuf memroy.
2\ Each msdk dmabuf memory include its own msdk surface kept by GQuark.
3\ Adds new option GST_BUFFER_POOL_OPTION_MSDK_USE_DMABUF

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 30, 2018 and Sreerenj Balachandran committed Mar 30, 2018

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

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

There needs to be generalized for the parameter from
GstVideoMsdkVideoMemory to GstMemory.

Thus we can call these functions if using DMABuf memory.

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

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

The current way to find proper response by just comparing request's
value is wrong.  We need to compare the size of a frame and the
number of suggested frames.

Refer to the sample in https://github.com/Intel-Media-SDK/samples.

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

Removes unessential field framerate for decoder so that negotiation
works even if framerate is not provided from upstream.

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

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 29, 2018 and Sreerenj Balachandran committed Mar 29, 2018

Removes unessential field framerate for decoder so that negotiation
works even if framerate is not provided from upstream.

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

MJPEG doesn't have support for extended coding options

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

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

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

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

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

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

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

wangfei authored Mar 13, 2018 and Sreerenj Balachandran committed Mar 13, 2018

Make sure I420 surface mapping works as expected by using
YV12 format and swap U/V plane's offset and pitches.

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

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

There was not handling the end of encoding sequence in encoder.
This patch does drain any remaining internal streams while decoder
already does this.

Document says:
"To mark the end of the encoding sequence, call this function with a
NULL surface
pointer. Repeat the call to drain any remaining internally cached
bitstreams—one
frame at a time—until MFX_ERR_MORE_DATA is returned."

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

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

Sometimes parent context is released before its children get released.
In this case MFXClose of parent session fails.

To make sure that child sessions are closed before closing a parent
session,
Parent context needs to manage child sessions and close them first when
it's released.

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

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

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

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

Currently a gst buffer has one mfxFrameSurface when it's allocated and
can't be changed.
This is based on that the life of gst buffer and mfxFrameSurface would
be same.
But it's not true. Sometimes even if a gst buffer of a frame is finished
on downstream,
mfxFramesurface coupled with the gst buffer is still locked, which means
it's still being used in the driver.

So this patch does this.
Every time a gst buffer is acquired from the pool, it confirms if the
surface coupled with the buffer is unlocked.
If not, replace it with new unlocked one.
In this way, user(decoder or encoder) doesn't need to manage gst buffers
including locked surface.

To do that, this patch includes the following:
1. GstMsdkContext
- Manages MSDK surfaces available, used, locked respectively as the
following:
  1\ surfaces_avail : surfaces which are free and unused anywhere
  2\ surfaces_used : surfaces coupled with a gst buffer and being used
now.
  3\ surfaces_locked : surfaces still locked even after the gst buffer
is released.

- Provide an api to get MSDK surface available.
- Provide an api to release MSDK surface.

2. GstMsdkVideoMemory
- Gets a surface available when it's allocated.
- Provide an api to get an available surface with new unlocked one.
- Provide an api to release surface in the msdk video memory.

3. GstMsdkBufferPool
- In acquire_buffer, every time a gst buffer is acquired, get new
available surface from the list.
- In release_buffer, it confirms if the buffer's surface is unlocked or
not.
  - If unlocked, it is put to the available list.
  - If still locked, it is put to the locked list.

This also fixes bug #793525.

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

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

There's unused code remaining since MSDK bufferpool patches landed.

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

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

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

Since there is already an "adaptive-B" option, just
use boolean property for B-pyramid enabling.

Fixme: Not sure whether this can be supported in vp8 and vp9.
It could be possible through GPB (b without backward ref) but
can't verify currently. We can move this as common property
once verified with vp8 and vp9 without breaking any backward
compatibility.

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

Added tuning options for mb level bitrate control,
adaptive I-frame insertion, and adaptive B-frame insertion.

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

According to spec, it is a general property. But based on
testing it only works for h264 encoder.
Let's keep it as h264 specific for now.

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

Move enum value defintions which are (or in future) supported
by more than one codec into a common file.

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

Add a new property "trellis" to enable trellis quantization.
Keeping trellis as a flag value (which is boolean for gst x264 enc element)
since it is possible to enable/disable this seperately for
I,P and B frames through MediaSDK ext option headers.

The subclass implementations always need to inform base-encoder
if it requires the inclusion of Extend Header buffers (mfxExtCodingOption2
 and mfxExtCodingOption3).

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

This option controls down sampling in look ahead bitrate
control mode. According to spec it is only supported in AVC.

Fixme: Probably HEVC also have support for this in recent
MSDK versions. We could move the enumeration types to common
header usable for multiple codecs.

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

MediaSDK has support for a number of rate control algorithms.
Adding all possible options to the property rate-control.

Fixme1: In case of failure, currently we don't have a proper method
to show which rate-control has been failed. It could be better
to add some extensive validation on EncQuery output in case of error.
Unfortunately, not all ratecontrol methods are supported by every codecs
and we don't have the dynamic detection of supported ratecontrol methods yet.

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

Adding a new property num-slices to set the number of
slices/partitions per frame. Adding it as a general
property for all codecs (except jpeg).

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

We have the property "i-frames" to set the IDR interval in a
gop. Unfortunately MSDK HEVC encoder behaves bit differently
for IdrInterval field, IdrInteval == 1 indicate every
I-frame should be an IDR (which is IdrInterval == 0 for other codecs),
IdrInteval == 2 means every other I-frame is an IDR
(which is IdrInterval == 1 for other codecs) etc.
So we generalize the behaviour of property "i-frames" by
incrementing the value by one in each case (only for HEVC).

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

The base encoder common properties are not valid for
mjpeg encoder where there is no motion compensation or rate control.
Delaying the property installation on the base gobject
untill the subclass class_init get invoked.

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

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

Only supporting asf header-format having BDUs with startcode.
It might be possible to support other formats too, but haven't tested.

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