summaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2020-01-24libs: display: driver quirks mechanismVíctor Manuel Jáquez Leal4-18/+87
This mechanism comes from ffmpeg vaapi implementation, where they have their own quirks. A specific driver is identified by a substring present in the vendor string. If that substring is found, a set of bitwise flags are store. These flags can be accessed through the function gst_vaapi_display_has_driver_quirks(). The purpose for this first quirks is to disable the put image try for AMD Gallium driver (see [1]). 1. https://gitlab.freedesktop.org/gstreamer/gstreamer-vaapi/merge_requests/72
2020-01-24plugins: renable Mesa Gallium driverVíctor Manuel Jáquez Leal1-0/+1
2020-01-24vaapivideobufferpool: validate returned metaVíctor Manuel Jáquez Leal1-2/+5
Validate if the meta returned by gst_buffer_get_vaapi_video_meta() in the acquired buffer is not null. This situation should be very "pathological", but still it is better be safe since that meta might be used later to create a new dma buffer.
2020-01-24vaapivideobufferpool: always update/release the underlying surface proxyPhilipp Zabel1-8/+13
gst_vaapi_video_buffer_pool_reset_buffer() is called when the sink releases the last reference on an exported DMA buffer. This should release the underlying surface proxy. To avoid releasing the wrong surface due to a stale surface proxy reference in the buffer's GstVaapiVideoMeta, always update the reference to the correct surface in gst_vaapi_video_buffer_pool_acquire_buffer().
2020-01-23libs: context: select vaCreateSurfaces version according attributesVíctor Manuel Jáquez Leal4-69/+45
This commit tries to centralize the selection of vaCreateSurfaces version, instead of having fallbacks everywhere. These fallbacks are hacks, added because new drivers use the latest version of vaCreateSurfaces (with surface attributes) [1], meanwhile old drivers (or profiles as JPEG decoder in i965) might rather use the old version. In order to select which method, there's detected hack: each config context has a list of valid formats, in the case of JPEG decoder the list only contains "rare" 4:2:2 formats (ICM3, GRAY8) which aren't handled correctly by the current gstreamer-vaapi code [2]. The hack consist in identify if the format list contains an arbitrary preferred format (which is suposedly well supported by gstreamer-vaapi, mostly NV12). If no prefered colour format is found, the the old version of vaCreateSurfaces is used, and the surfaces wil be mapped into a image with their own color format. 1. https://bugzilla.gnome.org/show_bug.cgi?id=797143 2. https://bugzilla.gnome.org/show_bug.cgi?id=797222
2020-01-22libs: context: add debug category for contextVíctor Manuel Jáquez Leal1-5/+23
2020-01-22libs: blend: guard VA_BLEND_GLOBAL_ALPHAVíctor Manuel Jáquez Leal1-1/+3
2020-01-21vaapiencode: promote info to warningVíctor Manuel Jáquez Leal1-2/+2
Let's notify user about using constrained-baseline instead on requested basline profile.
2020-01-19vaapih264dec: Add a property to assume constrained-baselineNicolas Dufresne5-2/+54
When baseline-as-constrained is set, the decoder will expose support for baseline decoding and assume that the baseline content is constrained-baseline. This can be handy to decode streams in hardware that would otherwise not be possible to decode. A lot of baseline content is in fact constrained.
2020-01-19vaapih264enc: accept baseline as constrained baseline compatibleVíctor Manuel Jáquez Leal2-0/+10
2020-01-19vaapih264enc: update level in src capsVíctor Manuel Jáquez Leal1-7/+13
And, if downstream requests a specific level, the caps are not negotiated, because there is no mechanism right now to specify a custom level in the internal encoder.
2020-01-19libs: encoder: h264: document gst_vaapi_encoder_h264_supports_avc()Víctor Manuel Jáquez Leal1-0/+9
2020-01-19vaapih264enc: force byte-stream if avc isn't supportedVíctor Manuel Jáquez Leal1-15/+5
Removing the validation in gst_vaapiencode_h264_get_caps() since that ought be handled in gst_vaapiencode_h264_set_config()
2020-01-19vaaph264enc: suppress avc if the driver does not support packed headersPhilipp Zabel1-0/+25
Do not negotiate AVC output if the driver does not support it.
2020-01-19libs: encoder: h264: Add gst_vaapi_encoder_h264_supports_avc()Philipp Zabel2-0/+11
AVC output requires packed header support in the driver.
2020-01-19vaapih264enc: intersect the new proposed capsVíctor Manuel Jáquez Leal1-2/+10
Instead of just leave to keep the proposed caps, with the best profile in the allowed caps, is its intersected again.
2020-01-19vaapih264enc: propose new profile caps and fixate itVíctor Manuel Jáquez Leal1-15/+12
When the available caps doesn't intersect with the allowed caps in the pipeline, a new caps is proposed rather than just expecting to iterate. Later, the intersected caps (profile_caps) is fixated in order to extract the configuration.
2020-01-19vaapih264enc: common fail for gst_vaapiencode_h264_set_config()Víctor Manuel Jáquez Leal1-8/+11
Add a common fail code path for gst_vaapiencode_h264_set_config().
2020-01-19libs: encoder: unref formats array if noneVíctor Manuel Jáquez Leal1-1/+3
The formats array is always created, in order to keep the logic and to avoid broken caps, if this formats array doesn't contain any elements, it has to be unref and the function should return NULL.
2020-01-19vaapih264enc: fix log messageVíctor Manuel Jáquez Leal1-2/+2
Before the log wasn't processed because wrong instance pointer.
2020-01-17plugin: encode: Add H265 main-444 profile.He Junyan4-2/+6
Expose the main-444 profile to h265enc caps, when the upstream chooses to use VUYA as input, we choose main 4:4:4 profile to encode the frames.
2020-01-17libs: encoder: h265: Consider main-444 profile when encoding.He Junyan1-9/+64
Add support of main-444 profile for parameter setting and packed header generation.
2020-01-17vaapiencode: DMABuf only if PRIME is availableVíctor Manuel Jáquez Leal5-13/+37
Add DMABuf capsfeature in encoders' allowed sinkcaps only if PRIME memory type is available in the VA surface attributes of codec context.
2020-01-16Add hooks/pre-commit.hookHaihao Xiang1-0/+83
meson.build in gstreamer-vaapi requires hooks/pre-commit.hook Copied and pasted pre-commit.hook from other gstreamer modules to make sure gstreamer-vaapi follows the same code style
2020-01-15libs: encoder: h265: Set encoder paramters base on entrypoint.He Junyan1-10/+12
When the tune is NONE, we now can choose entrypoint freely. So the GST_VAAPI_ENCODER_TUNE macro may not return the correct current entrypoint. We also delay CTU size calculation after entrypoint has been decided.
2020-01-15Remove all FEI relatedVíctor Manuel Jáquez Leal39-12794/+1
FEI encoders are not actively mantained neither tested, and it is using infrastructure that is changing and FEI is stopping this effort. Also it is required to rethink how FEI can be used in GStreamer.
2020-01-14vaapioverlay: ensure sinkpad has current bufferU. Artie Eoff1-4/+5
Use the gst_video_aggregator_pad_has_current_buffer API to check if the current sinkpad has a queued buffer before attempting to obtain a input buffer from the base plugin. If the sinkpad does not have a current buffer, then it is either not producing them yet (e.g. current time < sinkpad start time) or it has reached EOS. Previously, we only handled EOS case. Example: gst-launch-1.0 videotestsrc num-buffers=100 \ ! vaapipostproc ! vaapioverlay name=overlay \ ! vaapisink videotestsrc timestamp-offset=1000000000 \ num-buffers=100 ! video/x-raw,width=160,height=120 \ ! overlay.
2020-01-14vaapioverlay: unroll the recursive callVíctor Manuel Jáquez Leal1-38/+34
Recursive functions are elegant but dangerous since they might overflow the stack. It is better to turn them into a list tranversal if possible, as this case.
2020-01-14vaapioverlay: add minimal documentationVíctor Manuel Jáquez Leal2-0/+34
2020-01-14libs: blend: simplify generator APIVíctor Manuel Jáquez Leal3-25/+19
Instead of using a parent structure that has to be derived by API consumers, this change propse a simplification by using the common pattern of GTK of passing a function pointer and user data which will be passed as its parameter. That user data contains the state and the function will be called to update that state.
2020-01-14libs: blend: remove begin/render/end APIU. Artie Eoff2-172/+0
This API was risky and is superseded by the surface generator (process) API. Resolves #219
2020-01-14vaapioverlay: use blend surface generator APIU. Artie Eoff1-44/+63
See #219
2020-01-14libs: blend: add surface generator APIU. Artie Eoff2-0/+117
This new API allows the user to call a single method (process) which handles the [display] lock/unlock logic internally for them. This API supersedes the risky begin, render, end API. It eliminates the need for the user to call a lock method (process_begin) before processing the input buffers (process_render) and calling an unlock method (process_end) afterwards. See #219
2020-01-14plugin: encode: List all possible profiles to detect input formats.He Junyan6-83/+57
The current get_profile just return one possible profile for the encode, which is not enough. For example, if we want to support HEVC 4:4:4 profile, the input of encode should be VYUA rather than NV12 in HEVC main profile. So the command line: gst-launch-1.0 videotestsrc num-buffers=200 ! capsfilter \ caps=video/x-raw,format=VUYA,width=800,height=600 ! vaapih265enc \ tune=low-power init-qp=30 ! fakesink can not work because vaapih265enc just report NV12 in sink caps, we need to specify the profile obviously like: gst-launch-1.0 videotestsrc num-buffers=200 ! capsfilter \ caps=video/x-raw,format=VUYA,width=800,height=600 ! vaapih265enc \ tune=low-power init-qp=30 ! capsfilter caps=video/x-h265, \ profile=main-444 ! fakesink The encode should have the ability to choose the profile based on input format automatically. If the input video format is VUYA, the main-444 profile should be auto choosed. We modify to let get_allowed_profiles of each encode sub class to return an array of all supported profiles based on downstream's allowed caps, or return NULL if no valid profiles specified by downstream. If no allowed profiles found, all profiles which belong to the current encoder's codec will be the candidates. The function gst_vaapi_encoder_get_surface_attributes collects the surface's attributes for that profile list we just get. So for this case, both NV12 and VUYA should be returned. TODO: some codec like VP9, need to implement the get_profile() function.
2020-01-14plugin: util: add helper function to detect profiles in caps.He Junyan2-0/+71
2020-01-14libs: encoder: add a helper function to get all supported profilesHe Junyan2-0/+52
2020-01-13libs: decoder: Don't unref null objectSeungha Yang1-2/+4
** (gst-launch-1.0:9789): CRITICAL **: 15:29:09.330: gst_vaapi_context_unref: assertion 'context != NULL' failed
2020-01-10plugins: overlay: use proper NULL check on double pointerU. Artie Eoff1-1/+1
Check the address of the variable is not NULL, not the address of the pointer.
2020-01-08libs: codedbuf: delete a useless field.He Junyan1-1/+0
The context field in GstVaapiCodedBuffer is not inited correctly and is never used, just delete it.
2020-01-08plugins: add iHD driver in whitelistVíctor Manuel Jáquez Leal1-0/+1
2020-01-08libs: encoder: modify 265 SPS header's profile compatibility flag.He Junyan1-8/+44
Make the SPS profile compatibility flags more precisely conform to the HEVC Spec.
2020-01-06test: vaapioverlay: bail test if not availableVíctor Manuel Jáquez Leal1-1/+6
vaapioverlay is only registered if the VA driver support the blend operation. This patch only executes the test if vaapioverlay is available, otherwise the test is bail out without raising an error.
2020-01-06tests: vaapioverlay: force drm backendVíctor Manuel Jáquez Leal1-1/+1
2020-01-06libs: blend: update to new mini-object APIVíctor Manuel Jáquez Leal1-2/+2
2020-01-06tests: check: add basic vaapioverlay testU. Artie Eoff2-0/+214
Add test_overlay_position test to verify sink_1 input is overlayed onto sink_0 input at the appropriate position.
2020-01-06plugins: add vaapioverlay pluginU. Artie Eoff4-0/+758
A plugin similar to the base compositor element but uses VA-API VPP blend functions to accelerate the overlay/compositing. Simple example: gst-launch-1.0 -vf videotestsrc ! vaapipostproc \ ! tee name=testsrc ! queue \ ! vaapioverlay sink_1::xpos=300 sink_1::alpha=0.75 \ name=overlay ! vaapisink testsrc. ! queue ! overlay.
2020-01-06libs: add a vaapi blend classU. Artie Eoff3-0/+436
Support for the VA-API VPP blend functions.
2020-01-06plugins: base: add GstVideoAggregator subclass supportU. Artie Eoff2-15/+105
2020-01-06libs: image: init all image fields correctly.He Junyan1-0/+4
2020-01-06doc: fix pipeline typo in vaapipostprocStéphane Cerveau1-1/+1
generated by cgit v1.2.3 (git 2.39.1) at 2024-04-24 10:36:33 +0000