summaryrefslogtreecommitdiff
path: root/gst-libs
AgeCommit message (Collapse)AuthorFilesLines
2021-03-01gstvaapiencoder_h264: add ENCODER_EXPOSURE on aud propertiePaul Goulpié1-1/+2
forgot during the following mainline commit: https://gitlab.freedesktop.org/gstreamer/gstreamer-vaapi/-/commit/bc2f8fd19e924aa0e193708307326acd037691ce# Signed-off-by: Paul Goulpié <paul.goulpie@ubicast.eu> Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer-vaapi/-/merge_requests/416>
2021-01-21glx: Iterate over FBConfig and select 8 bit color sizeRafał Dzięgiel1-2/+38
Texture upload mechanism used by gstreamer-vaapi relies on 8 bpc. In latest mesa versions the first fbconfig might not be 8 bit, so iterate over it to find the correct config with supported values. This also adds 8 bit alpha size to the framebuffer configuration which is required to get it working properly. Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer-vaapi/-/merge_requests/411>
2020-12-05libs: decoder: H265: Fix a typo in scc reference setting.He Junyan1-1/+1
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer-vaapi/-/merge_requests/403>
2020-09-07Update for gst_video_transfer_function_*() function renamingSebastian Dröge1-1/+1
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer-vaapi/-/merge_requests/391>
2020-08-22Revert "libs: decoder: h264, h265: in context at least 16 reference surfaces"Víctor Manuel Jáquez Leal2-2/+2
This reverts commit b387081a4d77d3da202da72686ab40fb9c83ee1e as discussed in https://gitlab.freedesktop.org/gstreamer/gstreamer-vaapi/-/commit/b387081a4d77d3da202da72686ab40fb9c83ee1e
2020-08-18libs: surface: egl: guard memory typeVíctor Manuel Jáquez Leal1-0/+2
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer-vaapi/-/merge_requests/384>
2020-08-14libs: egl: surface: export EGLImage as DMABuf if GEM not supportedVíctor Manuel Jáquez Leal4-41/+145
This code path is used when frames are rendered as textures through GstVideoGLTextureUploadMeta with EGL, mainly under Wayland. Originally the EGLImage was exported as GEM, which was handled by Intel drivers, but Gallium ones cannot create VA surfaces from GEM buffers, only DMABuf. This patch checks the memory types supported by VA driver to choose the render the EGLImages from GEM or DMABuf, because GEM is still better where supported. DMABuf is well handled either by intel-vaapi-driver and gallium. Fixes: #137 Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer-vaapi/-/merge_requests/122>
2020-08-14libs: filter: gst_vaapi_filter_get_memory_types()Víctor Manuel Jáquez Leal2-0/+21
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer-vaapi/-/merge_requests/122>
2020-08-08libs: util: h265: use common parser API to get vaapi profiles.He Junyan1-171/+50
We can reuse H265 parser's API to recognize the correct profile and then just need to convert them to VAAPI profiles. Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer-vaapi/-/merge_requests/356>
2020-08-07build: update for gl pkg-config file splitVíctor Manuel Jáquez Leal1-3/+4
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer-vaapi/-/merge_requests/378>
2020-08-06h264dec: mark remaining frames as unreference before ↵Xu Guangxin1-2/+2
exec_picture_refs_modification 8.2.4.2 required this. Some clips will crash if we do not fill the reference list like this. Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer-vaapi/-/merge_requests/376>
2020-08-06libs: encoder: H265: Enable Main 12 profile support.He Junyan3-4/+31
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer-vaapi/-/merge_requests/375>
2020-08-06video format: Fix P012_LE's chrome type typo.He Junyan1-1/+1
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer-vaapi/-/merge_requests/375>
2020-08-04gstvaapiminiobject.c: fix clang 10 warningsJordan Petridis1-1/+1
the typesystem checks in g_atomic_pointer_compare_and_exchange seem to trigger some false positives with clang 10 similar to gstreamer!584 Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer-vaapi/-/merge_requests/377>
2020-07-31libs: window: wayland: destroy all wayland buffers during finalizeMichael Olbrich1-18/+30
Some buffers and the associated FrameState state may still be pending at that point. If the wayland connection is shared, then messages for the buffer may still arrive. However, the associated event queue is already deleted. So the result is a crash. With a private connection the associated memory is leaked instead. Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer-vaapi/-/merge_requests/342>
2020-07-31libs: wayland: update the opaque region in set_render_rectMichael Olbrich1-15/+31
gst_vaapi_window_wayland_set_render_rect() may be called from an arbitrary thread. That thread may be responsible for making the window visible. At that point another thread will block in gst_vaapi_window_wayland_sync() because the frame callback will not be called until the window is visible. If that happens, then acquiring the display lock in gst_vaapi_window_wayland_set_render_rect() would result in a deadlock. Cache the size of the opaque rectangle separately and create the opaque region right before applying it to the surface. Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer-vaapi/-/merge_requests/342>
2020-07-31libs: window: implements gst_vaapi_window_set_render_rectangleHyunjun Ko4-0/+43
Implements new vmethod gst_vaapi_window_set_render_rectangle, which is doing set the information of the rendered rectangle set by user. This is necessary on wayland at least to get exact information of external surface. And vaapisink calls this when gst_video_overlay_set_render_rectangle is called. Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer-vaapi/-/merge_requests/342>
2020-07-31libs: wayland: implement video overlay APIMichael Olbrich5-8/+89
The Wayland sub-surfaces API is used to embed the video into an application window. See Appendix A. Wayland Protocol Specification as the following. """ The aim of sub-surfaces is to offload some of the compositing work within a window from clients to the compositor. A prime example is a video player with decorations and video in separate wl_surface objects. This should allow the compositor to pass YUV video buffer processing to dedicated overlay hardware when possible. """ Added new method gst_vaapi_window_wayland_new_with_surface() Original-Patch-By: Víctor Manuel Jáquez Leal <vjaquez@igalia.com> Zhao Halley <halley.zhao@intel.com> changzhix.wei@intel.com Hyunjun Ko <zzoon@igalia.com> Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer-vaapi/-/merge_requests/342>
2020-07-31doc: libs: wayland: add 'transfer full' to the returnvalye of ↵Michael Olbrich1-1/+1
gst_vaapi_window_wayland_new Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer-vaapi/-/merge_requests/342>
2020-07-31libs: display: always call close_display()Michael Olbrich1-5/+3
All close_display() have their own checks for use_foreign_display and only destroy locally created objects in that case. Without this objects other than the actuall foreign display itself are leaked. Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer-vaapi/-/merge_requests/342>
2020-07-31video-format: Add the missing P012_LE into GST_VAAPI_FORMATS_ALL.He Junyan1-1/+1
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer-vaapi/-/merge_requests/373>
2020-07-31libs: decoder: fix a crash issue when get_surface_formats.He Junyan1-0/+2
Some context does not report any valid format that we can support. For example, the HEVC 444 12 bits decoder context, all the formats it reports is not supported now, which make the formats list a NULL array. We should check that pointer before we use it. Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer-vaapi/-/merge_requests/372>
2020-07-30libs: encoder: h265: choose the profile based on allowed list.He Junyan1-79/+64
We can decide the profile in ensure_profile(), based on allowed list passed by the encode. We also need to check whether the entrypoint is available. Once it is decided, no need to check the hw entrypoint them again. Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer-vaapi/-/merge_requests/349>
2020-07-30libs: display: Add a helper function to get profiles by codec.He Junyan2-6/+36
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer-vaapi/-/merge_requests/349>
2020-07-30libs: encoder: h265: modify set_max_profile to set_allowed_profiles.He Junyan2-26/+23
In h265, bigger profile idc may not be compatible with the small profile idc. And more important, there are multi profiles with the same profile idc. Such as main-422-10, main-444 and main-444-10, they all have profile idc 4. So recording the max profile idc is not enough, the encoder needs to know all allowed profiles when deciding the real profile. Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer-vaapi/-/merge_requests/349>
2020-07-30libs: encoder: h265: No need to check hw_max_profile.He Junyan1-38/+0
In h265, higher profile idc number does not mean better compression performance and may be not compatible with the lower profile idc. So, it is not suitable to find the heighest idc for hw to ensure the compatibility. On the other side, when the entrypoint of the selected profile is valid, it means the hw really support this profile, no need to check it again. Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer-vaapi/-/merge_requests/349>
2020-07-29libs: profile: Use get_codec_from_caps to get codec type.He Junyan3-11/+47
There is no need to get a profile from the caps and then convert that profile into codec type. We can get the codec type by caps's name easily. Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer-vaapi/-/merge_requests/358>
2020-07-29libs: profile: h265: Fix return value of from_codec_data_h265.He Junyan1-4/+5
profile_from_codec_data_h265() returns wrong GstVaapiProfile for h265. The codec data of caps contain the profile IDC, but the mapping between profile IDC and GstVaapiProfile is wrong. Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer-vaapi/-/merge_requests/358>
2020-07-29libs: utils: vpx: Add utils vpx to handle VP8/9 misc things.He Junyan3-0/+130
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer-vaapi/-/merge_requests/188>
2020-07-29libs: display, context: handle broken jpeg decoder for i965 driverVíctor Manuel Jáquez Leal3-1/+29
JPEG decoding in i965 driver is pretty much broken, and the driver is deprecated which mean authors only accept trivial fixes. Surfaces for JPEG decoder context in i965 only handle IMC3[1] color format which is not a common format in GStreamer. It can export it to I420 at mapping raw bytes, but DMABuf exporting is problematic. This patch artificially adds NV12 to the context format list when it's JPEG decoder for i965 and force the usage of old VA-API for surface creation without specifying color format. Also it artificially disables the DMABuf announcement. 1. https://docs.microsoft.com/en-us/windows/win32/medfound/recommended-8-bit-yuv-formats-for-video-rendering#420-formats-16-bits-per-pixel Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer-vaapi/-/merge_requests/369>
2020-07-29libs: context: change function to internal code styleVíctor Manuel Jáquez Leal1-8/+11
Instead of a getter the function `get_preferred_format()` to `ensure_preferred_format()` which aligns to the code style. Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer-vaapi/-/merge_requests/369>
2020-07-27vaapidecode: build allowed srcpad caps from va contextVíctor Manuel Jáquez Leal2-21/+52
Instead of generating allowed srcpad caps with generic information, now it takes the size an formats limits from the decoder's context. This is possible since srcpad caps are generated after the internal decoder is created. The patch replaces gst_vaapi_decoder_get_surface_formats() with gst_vaapi_decoder_get_suface_attributes(). From these attributes, formats are only used for VASurface memory caps feature. For system memory caps feature, the old gst_vaapi_plugin_get_allowed_srcpad_caps() is still used, since i965 jpeg decoder cannot deliver mappable format for gstreamer. And for the other caps features (dmabuf and texture upload) the same static list are used. This patch also adds DMABuf caps feature only if the context supports that memory type. Nonetheless, we keep the pre-defined formats since they are the subset of common derive formats formats supported either by amd/gallium and both intel drivers, since, when exporting the fd through vaAcquireBufferHandle()/ vaReleaseBufferHandle(), the formats of the derivable image cannot be retriebable from the driver. Later we'll use the attribute formats for the DMABuf feature too, when the code be ported to vaExportSurfaceHandle(). Finally, the allowed srcpad caps are removed if the internal decoder is destroyed, since context attribues will change. Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer-vaapi/-/merge_requests/366>
2020-07-27libs: window: wayland: use dmabuf protocol if availableMichael Olbrich1-39/+306
Currently vaGetSurfaceBufferWl() is used to create wayland buffers. Unfortunately this is not implemented by the 'media-driver' and Mesa VA-API drivers. And the implementation provided by 'intel-vaapi-driver' is not compatible with a Wayland server that uses the iris Mesa driver. So create the Wayland buffers manually with the zwp_linux_dmabuf_v1 wayland protocol. Formats and modifiers supported by the Wayland server are taken into account. If necessary, VPP is enabled to convert the buffer into a supported format. Fall back to vaGetSurfaceBufferWl() if creating buffers via dambuf protocol fails. Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer-vaapi/-/merge_requests/346>
2020-07-27libs: window: allow choosing the format for the vpp poolMichael Olbrich2-1/+23
Signed-off-by: Michael Olbrich <m.olbrich@pengutronix.de> Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer-vaapi/-/merge_requests/346>
2020-07-27video-format: add DRM formats to the mapping tableMichael Olbrich2-41/+121
This will be needed for the DMABuf protocol support to map DRM formats to vaapi and gstreamer formats. Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer-vaapi/-/merge_requests/346>
2020-07-27libs: display: wayland: add basic dmabuf protocol supportMichael Olbrich3-0/+64
This is just the basic infrastructure. Hook up the interface and collect all supported formats. Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer-vaapi/-/merge_requests/346>
2020-07-27libs: window: wayland: wait for configure before committing the first bufferMichael Olbrich1-1/+12
Committing the first buffer for a surface must not be done before ack_configure() has been sent for the xdg_surface. With weston, the commit will fail with "error 3: xdg_surface has never been configured". Wait in gst_vaapi_window_wayland_show() until configure is done to avoid this. Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer-vaapi/-/merge_requests/346>
2020-07-27libs: encoder: h265: set no P frame automatically.He Junyan1-2/+49
The double reference lists may be required by drivers and there should be no P frames in the of stream. The old way of converting P frames to B frames is by setting `low-delay-b` property, which is unconvenient and has bad user experience, since most of the users do not know when to set this property, and if it is not set correctly, the encoding pipeline fails or even hangs on some platforms. VA driver now provides a attribute to query whether both reference lists must be un-NULL for a profile/entrypoint pair. Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer-vaapi/-/merge_requests/284>
2020-07-27libs: encoder: h265: Deprecate the low-delay-b property.He Junyan1-7/+24
In HEVC, P and B definitions are different from AVC: P frames have just one reference list and so 1 MV, while B frames have two reference lists and so 2 MVs. No matter B or P, ist reference lists can contain forward/backward reference. So P and B can both have bi-directions dependency, the difference is just their reference list number (i.e. MV number). This is different from the AVC. The *low delay b mode* refers to a special HEVC mode, in which the stream just contain I and B frames, without P frames, and all B frames only have forward direction dependencies (i.e. all inter frames have 2 reference lists but no backward reference in both lists). This is similar to AVC I/P mode, but changing the P to the forward dependent B. The `low-delay-b` property is now just used to simply convert all P frames to B frames when driver does not support P frames (so both reference lists have the same references frames). This is a little different from the meaning of low delay b mode (the two ref lists may have the different reference frames). And the driver now can report whether it supports P frames correctly, so there is no need to use this property and deprecate it. Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer-vaapi/-/merge_requests/284>
2020-07-20libs: decoder: H265: Add MAIN_12 profile supporting.He Junyan5-1/+31
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer-vaapi/-/merge_requests/359>
2020-07-20video-format: Add P012_LE format.He Junyan2-0/+2
It can be used as HEVC YUV_4:2:0 12bits stream's decoder output, and also can be used as the input format for encoding HEVC YUV_4:2:0 12bits stream. Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer-vaapi/-/merge_requests/359>
2020-07-12libs: profile: The VP9 profiles' name should be just "0,1,2,3"He Junyan1-4/+4
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer-vaapi/-/merge_requests/357>
2020-07-09vaapidecode: Remove NO_SURFACE error handlingVíctor Manuel Jáquez Leal2-21/+0
Since surfaces are not bounded to decoding context it makes no sense to keep the surface semaphore. This patch removes the handling of this error. Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer-vaapi/-/merge_requests/353>
2020-07-09libs: decoder: context: remove surfaces binding from context.He Junyan1-3/+19
The vaCreateContext do not need to specify the surfaces for the context creation now. So we do not need to bind any surface to the context anymore. Surfaces should be the resource belong to display and just be used in encoder/decoder context. The previous manner has big limitation for decoder. The context's surface number is decided by dpb size. All the surfaces in dpb will be attached to a gstbuffer and be pushed to down stream, and the decoder need to wait down stream free the surface and go on if not enough surface available. For more and more use cases, this causes deadlock. For example, gst-launch-1.0 filesrc location=a.h264 ! h264parse ! vaapih264dec ! x264enc ! filesink location=./output.h264 will cause deadlock and make the whole pipeline hang. the x264enc encoder need to cache more than dpb size surfaces. The best solution is seperating the surfaces number and the dpb size. dpb and dpb size shoule be virtual concepts maintained by the decoder. And let the surfaces_pool in context maintain the re-use of all surfaces. For encoder, the situation is better, all the surfaces are just used as reference frame and no need to be pushed to down stream. We can just reserve and set the capacity of the surfaces_pool to meet the request. Fix: #147 Fix: #88 Co-Author: Víctor Manuel Jáquez Leal <vjaquez@igalia.com> Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer-vaapi/-/merge_requests/353>
2020-07-07libs: decoder: h264, h265: in context at least 16 reference surfacesVíctor Manuel Jáquez Leal2-2/+2
Registering only stream's DBP size number of surfaces for decoding VA surfaces brings issues for certain streams. This change register all possible number of reference surfaces in a stream, which is 16. Fixes: #94
2020-07-05libs: encoder: h265: init tier to GST_VAAPI_TIER_H265_UNKNOWN.He Junyan1-0/+1
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer-vaapi/-/merge_requests/350>
2020-07-05libs: encoder: h265: fix a bug to get get_profile_tier_level.He Junyan1-1/+2
0 is a valid value for h265 tier. Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer-vaapi/-/merge_requests/350>
2020-07-03libs: encoder: h265: no need to check the high compression tune.He Junyan1-40/+0
The h265 encoder just support tune mode: (0): none - None (3): low-power - Low power mode So, no need to check and set the high compression parameters. And by the way, the current ensure_tuning_high_compression manner of choosing the hightest profile idc as the best compression profile is not correct. Unlike h264, in h265 the higher profile idc number does not mean it has more compression tools, and so it has better compression performance. It may even be un-compatible with the lower profile idc. For example, the SCREEN_CONTENT_CODING profile with idc 9 is not compatible with 3D_MAIN profile with idc 8. Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer-vaapi/-/merge_requests/348>
2020-06-19Update plugin docs and add more pluginsTim-Philipp Müller4-0/+12
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer-vaapi/-/merge_requests/344>
2020-06-17libs: wayland: display: only handle the first outputMichael Olbrich1-2/+4
Right now, all outputs are handled. The means that the registry object for all but the last are leaked. As a result the sizes are not used correctly. With two outputs, at first the mode and physical size of the second output are used. If the first output changes the mode, then the physical size of the second output is used in combination with the resolution of the first output. The resulting pixel aspect ratio is incorrect. There seems to be no way to determine on which output the window is shown, so just use the first one to get consistent results. Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer-vaapi/-/merge_requests/341>
generated by cgit v1.2.3 (git 2.39.1) at 2024-05-01 16:48:07 +0000