summaryrefslogtreecommitdiff
path: root/sys/msdk
Commit message (Collapse)AuthorAgeFilesLines
...
* msdk: add missing breaksXiang, Haihao2018-12-032-0/+2
|
* msdk: fix the wrong operatorXiang, Haihao2018-12-031-1/+1
| | | | | The condition is for video memory only, so the operator should be & instead of |
* msdk: remove unnecessary assignmentXiang, Haihao2018-11-261-1/+0
| | | | | | CodecProfile will be set in MFXVideoDECODE_DecodeHeader() to match the input stream. Setting the hard-coded profile here will mislead user that msdkh265dec supports a special profile only.
* msdk: update the sink and src caps of msdkh265decXiang, Haihao2018-11-261-2/+3
| | | | | | | Now hevc 10bit video can be decoded correctly, so update the sink and src caps accordingly. This fixes https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/issues/720
* msdk: set right BitDepth and Shift for P010 mfx frameXiang, Haihao2018-11-261-0/+6
| | | | | BitDepth is 10 and Shitf must be set to 1 when creating P010 mfx frame in MSDK
* msdk: don't use hard-coded video formatXiang, Haihao2018-11-263-1/+28
| | | | | Some codecs may support varied formats, e.g. HEVC may support NV12 and P010_10LE etc
* msdk: adjust the RT format for P010 surfaceXiang, Haihao2018-11-261-0/+3
| | | | | According to VA API, VA_RT_FORMAT_YUV420_10 is expected for P010 surface
* msdk: create VA_FOURCC_P010 surface from dmabufXiang, Haihao2018-11-261-0/+4
|
* msdk: VA_FOURCC_P010 frame lockXiang, Haihao2018-11-261-0/+1
| | | | | P010 and NV12 have the same layout, so we may reuse the code in gst_msdk_frame_lock()
* msdk: map MFX_FOURCC_P010 to VA_FOURCC_P010Xiang, Haihao2018-11-261-0/+1
|
* msdk: make sure the surface data is set for GST_VIDEO_FORMAT_P010_10LEXiang, Haihao2018-11-261-0/+1
| | | | P010_10LE and NV12 have the same layout, so we may reuse the code.
* msdk: map GST_VIDEO_FORMAT_P010_10LE to MFX_FOURCC_P010Haihao Xiang2018-11-261-0/+1
|
* msdk: add an assert in gst_msdk_frame_lock() for unhandled formatsXiang, Haihao2018-11-261-0/+3
| | | | | We will add support for more formats, e.g. P010, Adding an assert here may catch the error early
* msdk: use separate src caps for msdkh265decHaihao Xiang2018-11-261-0/+14
| | | | | | We will add more formats in the src caps of msdkh265dec, so let msdkh265dec uses separate src caps. Note it doesn't change any capability
* msdk: Make sure a variable is initialized when it is usedXiang, Haihao2018-11-261-8/+9
| | | | | | 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.
* msdk: Close fd handleXiang, Haihao2018-11-261-0/+1
| | | | Otherwise it will result in resource leak if mem == NULL
* msdk: don't declare headers in mesonVíctor Manuel Jáquez Leal2018-11-231-30/+1
| | | | | | | This partially reverts commit 0bae64835302574953c3e5e89fa0822eb4f6ca4b. The compiler tells ninja the header dependency, then there is no need to add them explicity.
* msdk: declare headers in mesonVíctor Manuel Jáquez Leal2018-11-231-9/+38
|
* msdkdec: move output-order out of decode bass class.Wangfei2018-11-2318-37/+481
| | | | | | | 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
* msdk: add support for open sourced MediaSDKVíctor Manuel Jáquez Leal2018-11-221-1/+4
| | | | | | | | | | | | MediaSDK has been released as open source [1], but the directories where it installs its files, are different from the binary only distribution. This patch adds to the libraries path the directory /lib. Also it is defined in meson if the include directory has the mfx/ prefix, something that is already handled in autotools. 1. https://github.com/Intel-Media-SDK/MediaSDK
* meson: avoid unkown variables in the msdk testsJordan Petridis2018-11-061-3/+3
|
* msdk: fix intel sdk libdir pathFlorent Thiéry2018-11-061-1/+1
| | | | | | | | the 2018.3.1 intel sdk release places libraries into /lib64 instead of /lib/lin_x64 or /lib/x64, this commit adds /lib64 to the libdir locations list Fixes #815
* meson: Add a feature option for the MSDK pluginNirbheek Chauhan2018-10-281-7/+15
|
* msdk: Fix building on MSVCSeungha Yang2018-10-024-1/+9
| | | | | | And add missing #ifdef _WIN32 for MSVC build https://bugzilla.gnome.org/show_bug.cgi?id=797211
* msdk: Fix meson buildSeungha Yang2018-10-021-1/+1
| | | | | | gst-plugins-bad\sys\msdk\meson.build:57:4: ERROR: File msdk-enum.c does not exist. https://bugzilla.gnome.org/show_bug.cgi?id=797211
* Add feature options for almost all pluginsNirbheek Chauhan2018-07-271-0/+1
| | | | | | | The only plugins remaining are those that haven't been ported to Meson yet, and msdk. Also, the tests are still automagic. https://bugzilla.gnome.org/show_bug.cgi?id=795107
* msdkdec: Fix latency calculationSreerenj Balachandran2018-07-031-1/+1
| | | | | | 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().
* msdk: Set 16 bit alignment for widthSreerenj Balachandran2018-07-023-11/+11
| | | | | | | | | | | 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
* msdkdec: avoid early destruction of frame in dynamic resolution changeSreerenj Balachandran2018-07-021-0/+6
| | | | | | 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.
* msdkdec: vc1: Fix handling of advanced profile elementary streamSreerenj Balachandran2018-07-021-4/+6
| | | | | Advanced profile elementary streams may not have codec_data always. So make sure we don't do anything with null buffer.
* msdkdec: Fix advanced profile vc1 decode when codec_data presentsSreerenj Balachandran2018-07-021-8/+24
| | | | | | | | | 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.
* msdkdec: Fix the PTS of output framesSreerenj Balachandran2018-07-021-2/+46
| | | | | | | | | | 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
* msdkdec: Remove dead codeSreerenj Balachandran2018-07-022-7/+0
| | | | We are not using any ExtendedParams for decoding.
* msdk: dec: Add dynamic-configuration change supportSreerenj Balachandran2018-07-023-96/+334
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* msdk: Update for g_type_class_add_private() deprecation in recent GLibTim-Philipp Müller2018-06-242-24/+14
| | | | Untested.
* msdk: vpp: remove mfxExtVPPDoUse from vpp filters.Wang,Fei2018-06-072-30/+0
| | | | | | | | | | | | | According to msdk spec, there are two ways to enable filters: 1: Filters can be enabled by adding a filter ID to mfxExtVPPDoUse. In this case, default filter parameters are used 2: Add filter configuration structures directly to mfxVideoParam. Using 1 with 2 is optional but legal. Unfortunately it won't work with some specific use cases like Detail/EdgeEnhancement. Let's stick with option2 which works fine for all VPP operations. https://bugzilla.gnome.org/show_bug.cgi?id=796468
* msdk: vpp: set passthrough from set_caps method for code claritySreerenj Balachandran2018-06-071-5/+3
| | | | | Call passthrough setting method from set_caps so that msdk initialize subroutine looks more clear.
* mskd: vpp: error out gracefully instead of segfaulting if Init failedSreerenj Balachandran2018-06-072-1/+4
| | | | | | | | | | Since we do the MSDK initializing in set_caps(), a FALSE return may still cause the invokation of set_caps() again and this will leads to buffer allocation and other mess-up. So make sure the msdk initialized correctly before trying to do any buffer allocation. https://bugzilla.gnome.org/show_bug.cgi?id=796465
* msdk: vpp: Add filters to VideoParm before doing the QuerySreerenj Balachandran2018-06-071-9/+9
| | | | | | | | Make sure all the enabled filter structures are added in the mfxVideoParm before doing the VPPQuery so that msdk can do the input param validation https://bugzilla.gnome.org/show_bug.cgi?id=796465
* msdk: vpp: fix the filter count in mfxExtVPPDoUseSreerenj Balachandran2018-06-051-10/+10
| | | | | Repostion the mfxExtVPPDoUse enabling code so that it will get the filter algorithm count correctly.
* msdk: vpp: don't use NV12 as vpp default output for DMABuf usecaseSreerenj Balachandran2018-05-301-4/+5
| | | | | | | | | | Using NV12 layout in dmabuf mode giving mis-aligned VPP output with the media-driver. Keep the NV12 support (so that we can file the bug agianst msdk or mediadriver), but lower the ordering so that BGRA picks as default. NV12 issue can be reproduced with explicit capfilter: vidoetestsrc ! msdkvpp ! video/x-raw\(memory:DMABuf\),format=NV12 ! glimagesink
* msdk: enc: Add supprot for dmabuf-importSreerenj Balachandran2018-05-301-16/+81
| | | | | | | | | | | | | | | | | | | MediaSDK requires all the input buffers to be pre-allocated during init phase and this won't work with current design of GStreamer or gst-msdk. But this can be done in future once we have a solution for: https://bugzilla.gnome.org/show_bug.cgi?id=795747 There is a workaround possible as per https://github.com/Intel-Media-SDK/MediaSDK/issues/155#issuecomment-381790504 by faking the mem-id during MFXInit. This patch enabling it in gst-msdk by replacing the MemID of mfxSurface with dmabuf-backed vasurface dynamically. Important: v4l2 ! msdkenc won't work without a copy because of the GMMLib (https://github.com/intel/gmmlib) memory restrictions. https://bugzilla.gnome.org/show_bug.cgi?id=794817
* msdk: vpp: Add supprot for dmabuf-importSreerenj Balachandran2018-05-301-2/+85
| | | | | | | | | | | | | | | | | | MediaSDK requires all the input and output buffers to be pre-allocated during init phase and this won't work with current design of GStreamer or gst-msdk. But this can be done with https://bugzilla.gnome.org/show_bug.cgi?id=795747 There is a workaround possible as per https://github.com/Intel-Media-SDK/MediaSDK/issues/155#issuecomment-381790504 by faking the mem-id during MFXInit. This patch do this in gst-msdk by replacing the MemID of mfxSurface with dmabuf-backed vasurface dynamically. Important: v4l2 ! msdkvpp won't work without a copy because of the GMMLib (https://github.com/intel/gmmlib) memory restrictions. https://bugzilla.gnome.org/show_bug.cgi?id=794817
* msdk: Add method to replace internal VASurface of mfxFrameSurfaceSreerenj Balachandran2018-05-302-0/+68
| | | | | | | | Added a utility method to replace the MemID (interanl VASurfaceID) associated with the mfxFrameSurface. This is usefull for dmabuf-import where we need to replace the memID dynamically https://bugzilla.gnome.org/show_bug.cgi?id=794817
* msdk: Add method to export dmabuf to VASurfaceSreerenj Balachandran2018-05-302-0/+95
| | | | | | | | | Exporting DRM_PRIME fd to VASurface requires direct invocation of VA api VACreateSurface with VASurfaceAttribExternalBufferDescriptor and other necessary surface attributes. https://bugzilla.gnome.org/show_bug.cgi?id=794817
* msdk: Add conditional build for vp9 decoderSreerenj Balachandran2018-05-153-4/+13
| | | | https://bugzilla.gnome.org/show_bug.cgi?id=796119
* msdk: dec: Add VP9 decoderSreerenj Balachandran2018-05-154-0/+194
| | | | https://bugzilla.gnome.org/show_bug.cgi?id=796119
* msdk: allow building against open sourced msdkSreerenj Balachandran2018-05-158-8/+8
| | | | | | | | Building against mfx_dispatcher is used to search for headers in PREFIX/include/mfx/ only (commit: 62f04e801bd7e247102ac67df889bee33ab74ff7), but it is just PREFIX/include with open source msdk version. https://bugzilla.gnome.org/show_bug.cgi?id=796118
* msdk:dec: Add new propery to dump frames in decoded orderSreerenj Balachandran2018-05-074-0/+52
| | | | | | | | | | | | | | | | | | | | | | 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
* msdk: dec: inform msdk if the buffer contains a complete frameSreerenj Balachandran2018-05-071-0/+1
| | | | | | | | | | 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
View Lorry Controller Status