This is, practically, a revert of commit dcf135e2.
The parent logic is useful for the EGL display, which is a decorator
of the real windowing subsystem (X11 or Wayland). Thus it is avoided
calling vaInitialize() and vaTerminate() twice.
https://bugzilla.gnome.org/show_bug.cgi?id=795391
gst_vaapi_display_egl_new_with_native_display() has been broken since
it wasn't used.
Currently it's needed to call this API to create a display providing
the EGL display, so it could avoid duplicated calls to the native
display (eg. eglTerminate).
Signed-off-by: Victor Jaquez <vjaquez@igalia.com>
https://bugzilla.gnome.org/show_bug.cgi?id=795391
This change is due a problem decoding JPEGs with Intel's media-driver:
no image was generated.
This patch relases the VA buffers after vaEndPicture() is called,
and not before (after vaRenderPicture()).
https://bugzilla.gnome.org/show_bug.cgi?id=796505
The specification says,
"log2_max_pic_order_cnt_lsb_minus4 shall be in the range of 0 to 12, inclusive."
This patch changes the upper limit from 6 to 12.
https://bugzilla.gnome.org/show_bug.cgi?id=796179
This removes hard-coded checks on the parent subsystem of potential DRM
devices. These checks were set to exlude devices that do not originate
from the PCI bus, which is only a valid approach on x86 devices.
Other devices may have a DRM device originating from the platform
subsystem, so the checks that were previously restricted to PCI are
extended to cover platform devices as well.
https://bugzilla.gnome.org/show_bug.cgi?id=794840
Signed-off-by: Paul Kocialkowski <paul.kocialkowski@bootlin.com>
Otherwise the following poll may not return for an arbitrary amount of
time. This can happen if another wayland event queue has flushed and read
our events.
https://bugzilla.gnome.org/show_bug.cgi?id=795224
pic_width_in_luma_samples/pic_height_in_luma_samples can be 16-bit rounded
instead of 32-bit.
In addition, codedbuf_size must be calculated according to this change.
https://bugzilla.gnome.org/show_bug.cgi?id=753229
Even if it is the h264parse fault or bad video file, vaapih264dec
should set a proper value for VAPictureParameterBufferH264.num_ref_frames
as the driver might use it.
Also see "info.ref_frames = dpb_size;" in
gstvaapidecoder_h264.c::ensure_context
https://bugzilla.gnome.org/show_bug.cgi?id=793836
Check input buffers for ROI metas and pass them to VA. Also added a
new "default-roi-delta-qp" property in order to tell the encoder what
delta QP should be applied to ROI by default.
Enabled it for H264 and H265 encoders.
https://bugzilla.gnome.org/show_bug.cgi?id=768248
According to Debian package auto-building, uintptr_t is not an
unsigned long in i386 arch, raising an "incompatible pointer type"
error.
This patch adds a casting for compiler's satisfaction in i386.
Increased max values of periodic key frame for h26x codecs.
This allow more fine tunning of encoder that in certian scenario
want higher periodic key frame.
For example: it doesn't want a key frame each 10 seconds but
each 120 seconds.
https://bugzilla.gnome.org/show_bug.cgi?id=786320
eglGetDisplay() is currently broken in Mesa for Wayland. Also using
eglGetDisplay() is rather fragile, and it is recommended to use
eglGetPlatformDisplay() when possible.
In order to do that, this patch uses the helper in GstGL. If
gstreamer-vaapi is not compiled with GstGL support, eglGetDisplay()
will be used.
https://bugzilla.gnome.org/show_bug.cgi?id=790493
Frames are encoded as different layers. Frame in a particular
layer will use pictures in lower or same layer as references.
Which means decoder can drop the frames in upper layer but still
decode lower layer frames.
B-frames, except the one in top most layer, are reference frames.
All the base layer frames are I or P.
eg: with 3 temporal layers
T3: B1 B3 B5 B7
T2: B2 B6
T1: I0 P4 P8
T1, T2, T3: Temporal Layers
P1...Pn: P-Frames:
B1...Bn: B-frames:
T1: I0->P4 , P4->P8 etc..
T2: I0--> B2 <-- P4
T3: I0--> B1 <-- B2, B2 --> B3 <-- P4
Signed-off-by: Sreerenj Balachandran <sreerenj.balachandran@intel.com>
https://bugzilla.gnome.org/show_bug.cgi?id=788918
Frames are encoded as different layers. A frame in a particular
layer will use pictures in lower or same layer as references.
Which means decoder can drop the frames in upper layer but still
decode lower layer frames.
eg: with 3 temporal layers
T3: P1 P3 P5 P7
T2: P2 P6
T1: P0 P4 P8
T1, T2, T3: Temporal Layers
P1...pn: P-Frames:
P0->P1 , P0->P2, P2->P3, P0->P4......repeat
Signed-off-by: Sreerenj Balachandran <sreerenj.balachandran@intel.com>
https://bugzilla.gnome.org/show_bug.cgi?id=788918
The frame_num generation was not correctly implemented.
According to h264 spec, frame_num should get incremented
for each frame if previous frame is a referece frame.
For eg: IPBPB sequece should have the frame numbers 0,1,2,2,3
Signed-off-by: Sreerenj Balachandran <sreerenj.balachandran@intel.com>
https://bugzilla.gnome.org/show_bug.cgi?id=788918
Adds new property "prediction-type" to select different reference
picture selection modes like hierarchical-p, hierarchical-b etc.
Signed-off-by: Sreerenj Balachandran <sreerenj.balachandran@intel.com>
https://bugzilla.gnome.org/show_bug.cgi?id=788918
Adds some basic building blocks to ease the implementation
of hierarchical prediction modes.
-- add an utility method to find temporal level of each frame
-- define max_ref_frame count based on temporal level count
-- add temporal_level_div[] for finding temporal level each frame
to be encoded.
-- find ip_period based on temporal level count
Signed-off-by: Sreerenj Balachandran <sreerenj.balachandran@intel.com>
https://bugzilla.gnome.org/show_bug.cgi?id=788918
Adds new property "temporal-levels" to select the number of
temporal levels to be included in the encoded stream.
Signed-off-by: Sreerenj Balachandran <sreerenj.balachandran@intel.com>
https://bugzilla.gnome.org/show_bug.cgi?id=788918
We can have p-frame as non-ref and also b-frame as ref
which are not supported yet. Reference flag
is the first machinery needed for more advanced
reference picture selection modes.
Signed-off-by: Sreerenj Balachandran <sreerenj.balachandran@intel.com>
https://bugzilla.gnome.org/show_bug.cgi?id=788918
Adds a new function that changes the internal EGL display to the
current one (eglGetCurrentDisplay()) and sets the current context
too (eglGetCurrentContext()).
This new function is called by gst_vaapi_texture_egl_create() updating
the GstVaapiDisplayEGL with the current EGL display.
https://bugzilla.gnome.org/show_bug.cgi?id=773453
It is required to use the context of the calling thread when wrapping
a foreign texture. According the documentation of
GstVideoGLTextureUploadMeta:
"The caller of gst_video_gl_texture_upload_meta_upload() must
have OpenGL set up and call this from a thread where it is valid
to upload something to an OpenGL texture."
This patch updates the EGL display and context in GstVaapiDisplay
instance to the one used by te renderer that uploads the texture.
Original-patch-by: Daniel van Vugt <daniel.van.vugt@canonical.com>
https://bugzilla.gnome.org/show_bug.cgi?id=773453
Instead of silently fail to export the image if there is not available
the EGL_MESA_drm_image, log an error message. Also a code refactoring
was done.
https://bugzilla.gnome.org/show_bug.cgi?id=773453
In case of streaming, controlling bitrate dynamically for encoder might be
important to manage quality of the streaming.
This patch is to support such a scenario.
https://bugzilla.gnome.org/show_bug.cgi?id=786321
gstreamer-vaapi initializes the display by trial-and-error, thus
logging an error message if the display initialisation fails the user
may be weary of the error message in the screen, if using VA-API 1.0
This commit set the VA error log handler to GStreamer warning level
while calling vaInitialize() and set it to error after that.
https://bugzilla.gnome.org/show_bug.cgi?id=783169
GstVaapiDisplayEGL is a wrapper of another GstVaapiDisplay, either X11
or Wayland. Nonetheless it created another vaDisplay for it, instead
of using the wrapped one.
This patch enables the reuse of the wrapped vaDisplay avoiding
instantiating two.
https://bugzilla.gnome.org/show_bug.cgi?id=782212
This is a difference between the GObject API and the GstVaapi one: the
GValue passed to get a property value, in GObject has to be
initialized with g_value_init(), but in GstVaapi is has not.
In order to overcome this mismatch, this patch call g_value_init()
internally only in the passed one is not already initialized.
https://bugzilla.gnome.org/show_bug.cgi?id=788058
Shuffled some code to avoid to find the properties descriptor in the
array twice, adding the internal functions _set_property() and
_get_property().
https://bugzilla.gnome.org/show_bug.cgi?id=788058
Fixes regression introduced by commit 2eb2b26a.
There is a use case when the decoder set the src caps and immediatly
tries to process the media codec_data, this happens before decoder is
even opened, thus priv->parser is not instantiated yet.
https://bugzilla.gnome.org/show_bug.cgi?id=787818
Instead of handling the macroblock bitrate control as a integer, this
patch changes it as a enum, which is more self documented in the
GStreamer elements.
https://bugzilla.gnome.org/show_bug.cgi?id=787855
This patch fixes a regression introduced in commit 148f867c, since the
props variable is set to object's member variable
encoder->properties. And it is set in the instance initialization,
thus it will not be leaked.
https://bugzilla.gnome.org/show_bug.cgi?id=787733
Creates 2 properties, qp-ip and qp-ib for setting different QP for P/B
frames
and set slice_qp_delta for each frame according to the value provided.
https://bugzilla.gnome.org/show_bug.cgi?id=785923
Creates 2 properties, qp-ip and qp-ib for setting different QP for P/B
frames
and set slice_qp_delta for each frame according to the value provided.
In addition, remove the limitation of (<= 4) when setting
slice_qp_delta.
https://bugzilla.gnome.org/show_bug.cgi?id=785923
Creates new variable for QP for I frame and keep it at configuration and
use this for pic_init_qp and slice_qp_delta setting.
Since changing min qp doesn't make sense, keep min qp as is.
https://bugzilla.gnome.org/show_bug.cgi?id=785923
This is doing the same as h264 encoder as the following:
Using num_ref_frames provided and the result of the Query
VAConfigAttribEncMaxRefFrames, it determines the size of reference list
and perform encoding with multi reference frames as the following:
1\ The num_ref_frames is being considered as the number of
reference picture list0
2\ Encoder adds 1 reference frame more to the reference picture list1
internally if b-frame encoding.
3\ If num_ref_frames is bigger than the number of refrence frames
supported in the driver, it will be lowered.
Also this patch includes:
- Set num_negative_pics and num_positive_pics according to the number of
refs.
- Set delta_poc according to the number of refs.
- Increase max_dec_pic_buffering according to the number of refs
- Change max_num_reorder_pics according to num of bframes
https://bugzilla.gnome.org/show_bug.cgi?id=783804
Users can provide the number of reference frame by this property,
which is exaclty same as h264.
The value of the property will be considered as the number of
reference picture list0 and will add 1 reference frame more to the
reference picture list1 internally if b-frame encoding.
If the value provided is bigger than the number of refrence frames
supported in the driver, it will be lowered.
The maximum value is aligned to the value of the driver supported now.
https://bugzilla.gnome.org/show_bug.cgi?id=783804
Follows the specification as below:
7.4.7.1 in Rec. ITU-T H.265 v4 (12/2016)
num_ref_idx_active_override_flag equal to 1 specifies that the syntax
element num_ref_idx_l0_active_minus1 is present for P and B slices and
that the syntax element num_ref_idx_l1_active_minus1 is present for B
slices.
num_ref_idx_active_override_flag equal to 0 specifies that the syntax
elements num_ref_idx_l0_active_minus1 and num_ref_idx_l1_active_minus1
are not present.
https://bugzilla.gnome.org/show_bug.cgi?id=783804
Remove FIXME code, which makes previous assignation spurious.
This also means to make idr_period equal to keyframe period,
which is same as h264 encoder.
https://bugzilla.gnome.org/show_bug.cgi?id=783804
Adding FEI encoder to core lib.
The code is splitted into three session:
1: gstvaapiencoder_h264_fei.{h,c}
This is the replica of gstvaapiencoder_h264.{c,h} but with FEI.
All the modes ENC, PAK and ENC_PAK are running based
the code in these files.
2: gstvaapifeienc_h264.{h,c}
Abstract implementation intended for ENC (only VME) operation.
3: gstvaapifeipak_h264.{h,c}
Abstrct implementation intended for PAK (only the PAK module)
Right now ENC_PAK, ENC and PAK are running based on code
in gstvaapiencoder_h264_fei.{h,c}. The abstract implementations
in gstvaapifeienc_h264.{h,c} and gstvaapifeipak_h264.{h,c} are
needed if user request for ENC+PAK mode operation.
ENC+PAK: Here we need to invoke two sequence of
vaBeginPicture/vaRenderPicutre/vaEndPicture for each frame,
first for the ENC only and the second for PAK only.
Each mode associated with separate context ,but same pool of surfaces are
shared between the modes.
This is more useful once we have custom BRC algorithms.
Other Contributors:
Wang, Yi <yi.a.wang@intel.com>
Leilei <leilei.shang@intel.com>
Zhong, Xiaoxia <xiaoxia.zhong@intel.com>
xiaominc <xiaomin.chen@intel.com>
Li, Jing B <jing.b.li@intel.com>
https://bugzilla.gnome.org/show_bug.cgi?id=785712https://bugzilla.gnome.org/show_bug.cgi?id=784667
MbCode, MV and Distortion buffers (fei codec objects)
can be treated as output of different fei modes based user request.
For eg: MbCode and MV are the output of ENC only. MbCode, MV and Dist
can be dumped as output in ENC_PAK mode for analysis purpose.
So treating them as a part of CodedBufferProxy too.
Here we avoided Qp, MbControl and MvPredictor codec objects since
there is no practical use case of treating them as "output buffers".
Other contributors:
Zhong, Xiaoxia <xiaoxia.zhong@intel.com>
xiaominc <xiaomin.chen@intel.com>
Leilei <leilei.shang@intel.com>
Li, Jing B <jing.b.li@intel.com>
https://bugzilla.gnome.org/show_bug.cgi?id=785712https://bugzilla.gnome.org/show_bug.cgi?id=784667
Add fei codec objects to surface proxy since handling the
fei buffers(codec objects here) external to gstvaapisurfaceproxy
will make the code complicated. Especially considering the behavior
of encoder where the input frame order from upstream and output
frame order to the downstream are not sequential.
Other contributors:
Zhong, Xiaoxia <xiaoxia.zhong@intel.com>
xiaominc <xiaomin.chen@intel.com>
Leilei <leilei.shang@intel.com>
Li, Jing B <jing.b.li@intel.com>
https://bugzilla.gnome.org/show_bug.cgi?id=785712https://bugzilla.gnome.org/show_bug.cgi?id=784667
There are 6 new va buffer types, each defined as a specific codec object.
Borrowed the code from gstvaapicodecobject , but made a clear separation
to avoid any possible mess-up. Because unlike the other gstvaaicodecobjects,
feicodecobjects can be shared between elements and also can be accessed
from different thread.
Unlike the other fei codecs object, VAEncMiscParameterTypeFEIFrameControl
object is not shared between elements.So we utilize the already
existing gst_vaapi_enc_misc_param_new(), but still keeping the code
in gstvaapfei_objects_priv.h in order to have a better
code readability.
Fixme:
-- Probably we need _locked_map() and _unlocked_map()
-- Context can be associated with PreEnc(not just Enoder)
once we have the proper support inplace, but for now we don't have
PreEnc support, so should be safe enough to use GstVaapiEncoder.
https://bugzilla.gnome.org/show_bug.cgi?id=785712https://bugzilla.gnome.org/show_bug.cgi?id=784667
Add a new vitrual method ensure_secondary_context to the
base encoder which is only required for the FEI entrypoint, that too
only when user configures the ENC+PAK mode. ENC+PAK mode is not something
supported directly by libva or driver, but this can be enabled
from the middleware.
Original Author of this idea: Leilei Shang <leilei.shang@intel.com>
Signed-off-by: Leilei Shang <leilei.shang@intel.com>
Signed-off-by: xiaominc <xiaomin.chen@intel.com>
Signed-off-by: Sreerenj Balachandran <sreerenj.balachandran@intel.com>
https://bugzilla.gnome.org/show_bug.cgi?id=785712https://bugzilla.gnome.org/show_bug.cgi?id=784667
Drops non-base NALs when the base-only property is set to TRUE.
This modifies the behavior for MVC streams with base-only too: All the
non-base units are dropped before they are decoded instead of dropping
the non-base frames.
The relevant part from the H264 spec is:
> Decoders that conform to one or more of the profiles specified in
Annex A rather than the profiles specified in Annexes G or H shall
ignore (remove from the bitstream and discard) the contents of all NAL
units with nal_unit_type equal to 14, 15, or 20.
To eliminate side effects from the offending units:
- PPS's with a broken seq_parameter_set_id (referring to dropped subset
SPS's) are ignored.
- The NAL parsing is skipped and their flags are set to
GST_VAAPI_DECODER_UNIT_FLAG_SKIP.
- Prefix units are not stored in prev_pi. Otherwise, parse_slice() would
use them even if they are flagged to be skipped. Subset SPS's and slice
extension units are not stored there either.
https://bugzilla.gnome.org/show_bug.cgi?id=732266
Signed-off-by: Sreerenj Balachandran <sreerenj.balachandran@intel.com>
In VA-API 1.0 the enum VAEncPackedHeaderH264_SEI is deprecated, and
instead VAEncPackedHeaderRawData should be used.
This patch creates a compatibility symbol,
VA_ENC_PACKED_HEADER_H264_SEI, to expose the used enum according the
VA-API version.
https://bugzilla.gnome.org/show_bug.cgi?id=784398
In VA-API 1.0 the union bits in VAEncMiscParameterBufferROI has
renamed one member from roi_value_is_qp_delat to
roi_value_is_qp_delta, which is the correct name.
In order to keep back compatibility a macro has added to access this
union member.
https://bugzilla.gnome.org/show_bug.cgi?id=784398
Coverity scan bug:
An assigned value that is never used may represent unnecessary
computation, an incorrect algorithm, or possibly the need for cleanup
or refactoring.
ip_period is assigned first to be rewritter inmediatly after. The
first assignation is spurious.
Coverity scan:
Logically dead code: The indicated dead code may have performed some
action; that action will never occur.
By using pointer arithmetic is impossible to get NULL.
Coverity scan bug:
Out-of-bounds write. This could cause an immediate crash or incorrect
computations.
Coverity basically found that it is possible to assign more than 4
attribs in the array.
In my opinion this was produced because code pattern used pointer
arithmetic, which is not readable nor maintainable.
This patch refactors config_create() to use an array index rather than
pointer arithmetic. Also a run-time check for index size was added.
Converity scan bug:
If the function returns an error value, the error value may be
mistaken for a normal value.
If g_atomic_pointer_compare_and_exchange() fails because the frame is
not the last one, the function fails. Thus, logging an info message.
Coverity scan bug:
If the function returns an error value, the error value may be
mistaken for a normal value.
Function sscanf returns the number of assignations done. Validate this
return value with the number of expected variables to match.
Coverity scan bug:
Dereference after null check: Either the check against null is
unnecessary, or there may be a null pointer dereference.
Variable klass has been validated as non-NULL several time before in
gst_vaapi_object_new() function, so there is no need to check it
again.
Coverity scan bug:
An assigned value that is never used may represent unnecessary
computation, an incorrect algorithm, or possibly the need for cleanup
or refactoring.
ip_period is assigned first to be rewritter inmediatly after. The
first assignation is spurious.
Coverity scan bug:
The copied code will not have its intended effect.
This is a bug from commit cdaf15b2, where the intention is to
initialize RefPicList1 while setting RefPicList0.
Coverity scan bug:
Unintentional integer overflow. The expression's value may not be what
the programmer intended, because the expression is evaluated using a
narrow (i.e. few bits) integer type.
Cast operator to guint64 before computation to avoid narrowing.
merge with 3c5a6add
Coverity scan bug:
An assigned value that is never used may represent unnecessary
computation, an incorrect algorithm, or possibly the need for cleanup
or refactoring.
In the return value of decode_slice() or
gst_mpeg4_parse_video_packet_header() are not success, thus fail
decode_packet() function.
Coverity scan bug:
Dereference after null check: Either the check against null is
unnecessary, or there may be a null pointer dereference.
While looking for hte lowest poc, according to rest of the code, the
picture in the dbp (decoded picture buffer) might be NULL, thus we
could check for a NULL picture before assigned as found.
Also, split a comma operator because it is considered as a bad
practice because it possible side effects.
Coverity scan bug:
Scalars (for example, integers) are not properly
bounds-checked (sanitized) before being used as array or pointer
indexes, loop boundaries, or function arguments are considered as
tainted.
In this case, num_nals were not checked before used as loop control.
Coverity scan bug:
Dereference after null check: Either the check against null is
unnecessary, or there may be a null pointer dereference.
In the original commit for fill_picture_gaps() (commit 5abd2b90) the
prev_picture could be NULL, that's why the code did a null check. But,
since commit 52adebe7, the previous reference frames are tracked, thus
there is no need to check null anymore.
Using num_ref_frames provided and the result of the Query
VAConfigAttribEncMaxRefFrames, it determines the size of reference list
and perform encoding with multi reference frames as the following:
1\ The num_ref_frames is being considered as the number of
reference picture list0
2\ Encoder adds 1 reference frame more to the reference picture list1
internally if b-frame encoding.
3\ If num_ref_frames is bigger than the number of refrence frames
supported in the driver, it will be lowered.
https://bugzilla.gnome.org/show_bug.cgi?id=783803
Users can provide the number of reference frame by this property.
The value of the property will be considered as the number of
reference picture list0 and will add 1 reference frame more to the
reference picture list1 internally if b-frame encoding.
If the value provided is bigger than the number of refrence frames
supported in the driver, it will be lowered.
https://bugzilla.gnome.org/show_bug.cgi?id=783803
This function will query VAConfigAttribEncMaxRefFrames to get the
maximum number of reference frames supported in the driver.
This will be used for h264/h265 encoding.
https://bugzilla.gnome.org/show_bug.cgi?id=783803
Added a new property "compliance-mode", which default is the normal
strict compliant mode.
The second mode, "restrict-buf-alloc", is to limit the coded buffer
allocation size to improve performance in some specific Intel
platforms (there is asignificant performance improvement in parallel
encodings). Under this new mode, we use the MinCR field in A.3.1 for
pre-calculating the coded-buffer size.
https://bugzilla.gnome.org/show_bug.cgi?id=784590
Push frames downstream as soon as possible instead of waiting until
they are ejected from the DPB.
This patch makes the decoder not comply with the H.264 specification,
but it is required for some video cameras.
https://bugzilla.gnome.org/show_bug.cgi?id=762509
Signed-off-by: Víctor Manuel Jáquez Leal <vjaquez@igalia.com>
If the picture is IDR, also submit a SPS header.
This means when frame number reaches to keyframe-period or an force
key unit event arrives, we insert SPS/PPS again.
https://bugzilla.gnome.org/show_bug.cgi?id=776712
GST_VIDEO_CODEC_FRAME_IS_FORCE_KEYFRAME() is a flag usually used to manage
the `frame-lost` event in the case of streaming, such as RTP.
In case of this event, it is needed to start new GOP rather than just
produce an I-frame.
https://bugzilla.gnome.org/show_bug.cgi?id=776712
Insert an AUD as the first NAL of each encoded frame.
Some applications require Access Unit Delimiter for decoding the
stream.
The AU delimeter insertion is done only when the aud parameter is
TRUE (by default is disabled). The reason of this it is because this
header is only available from Intel Gen9 and the VA intel driver
should be 1.8 or superior. Otherwise, the output will be corrupted.
https://bugzilla.gnome.org/show_bug.cgi?id=776712
Signed-off-by: Victor Jaquez <vjaquez@igalia.com>
Currently when num_views is changed by multiview-mode on sink caps, it produces
wrong MVC encoded stream since the array view_ids is not set properly according
to changed num_views.
So this patch initializes all of the array sequentially to handle this case.
Side effect is not going to happen by this patch since this array is being
handled by num_views.
https://bugzilla.gnome.org/show_bug.cgi?id=784321
Until now, the encoder ignored the profile in src caps and chose one
according with the given parameters. But the encoder must honor the
profile specifed in src caps.
This patch do that, and if the encoder needs to choose the profile,
it will do it by following these rules:
1\ If given parameters are not compatible with given profile, the
encoder will bail out with an error.
2\ The encoder will choose the higher profile indicated in the
src caps.
https://bugzilla.gnome.org/show_bug.cgi?id=757941
Since commits in https://bugzilla.gnome.org/show_bug.cgi?id=781142 landed,
they introduced regression in seek.
Formerly, once seek is done, decoder drops P-frames until I-frame arrives.
But since the commits landed, it doesn't drop P-frame and does try to
decode it continuously because active_sps is still alive. See ensure_sps function.
But there are prev_frames and prev_ref_frames reset already, then it
causes assertion.
So it's necessary to reset active_sps/pps also in reset method.
https://bugzilla.gnome.org/show_bug.cgi?id=783726
There are some symbols that are not used when compiling with old
version of libva and those generates a compilation error.
Original-patch-by: Matt Staples <staples255@gmail.com>
Change the hard-coded range of quality-level from {1-8} to {1-7},
since it is the range Intel Open source driver supports.
Also perform the range clamping only if the user provided
quality-level is greater than the max-range suppored by the driver,
because there could be non-intel drivers giving lower value than
the hard-coded max value 7.
https://bugzilla.gnome.org/show_bug.cgi?id=783567
Just set the framerate parameter if the framerate numerator and
denominator are bigger than zero.
Otherwise, in Intel Gen6 driver, a warning is raised disabling the
bitrate control.
Original-patch-by: Hyunjun Ko <zzoon@igalia.com>
https://bugzilla.gnome.org/show_bug.cgi?id=783532
