summaryrefslogtreecommitdiff
path: root/sys
Commit message (Collapse)AuthorAgeFilesLines
* wasapi: try to satisfy both mingw and msvcTim-Philipp Müller2018-03-182-0/+3
| | | | Fix-up for previous commit, hopefully.
* kmssink: Add Amlogic upstreamer DRM driver supportNicolas Dufresne2018-03-181-1/+1
| | | | | Amlogic Upstream driver is named meson, not to be confuse with the build system.
* wasapi: fix indentationTim-Philipp Müller2018-03-171-2/+3
|
* wasapi: fix unresolved symbol linker error with vs2017 on win10Tim-Philipp Müller2018-03-172-1/+1
| | | | | | | | | | ERROR: unresolved external symbol PKEY_AudioEngine_DeviceFormat Apparently the order of the header includes matters, and initguid.h must be included first. Let's hope this doesn't break anything on the other toolchains. https://social.msdn.microsoft.com/Forums/windowsdesktop/en-US/ceff4e2d-8f63-4ab6-b09b-fdac65d62a80/pkeyaudioenginedeviceformat-link-error?forum=windowspro-audiodevelopment
* msdk: libva: remove unnecessary code and commentsHyunjun Ko2018-03-131-8/+0
| | | | https://bugzilla.gnome.org/show_bug.cgi?id=794276
* msdk: adds new debug categoryHyunjun Ko2018-03-132-2/+4
| | | | https://bugzilla.gnome.org/show_bug.cgi?id=794276
* msdk: fix typoHyunjun Ko2018-03-132-6/+6
| | | | https://bugzilla.gnome.org/show_bug.cgi?id=794276
* msdk: Fix the I420 video format supportWang,Fei2018-03-131-2/+8
| | | | | | | 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
* wasapi: Minor fixes for debug loggingNirbheek Chauhan2018-03-101-3/+3
|
* meson: Add deviceprovider changes to directsoundsrcNirbheek Chauhan2018-03-101-1/+10
| | | | These were missed when they were added to Makefile.am
* wasapi: Guard IAudioClient2 structs and enumsNirbheek Chauhan2018-03-101-13/+11
| | | | | | | These are already defined in the audioclient.h provided by the latest MinGW headers, and the existing #ifndef were obviously wrong. https://bugzilla.gnome.org/show_bug.cgi?id=794197
* meson: fix build when msdk is not foundTim-Philipp Müller2018-03-091-0/+4
|
* msdk: Fix the misspelled file name in meson buildSreerenj Balachandran2018-03-091-1/+1
|
* wasapi: ship audioclient3 header in tarballsEmilio Pozuelo Monfort2018-03-091-1/+2
| | | | https://bugzilla.gnome.org/show_bug.cgi?id=794197
* msdk: enc: fix missing some frames to be encodedHyunjun Ko2018-03-082-31/+36
| | | | | | | | | | | | | | | 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
* msdk: dec: fix leaks when flushingHyunjun Ko2018-03-081-8/+16
| | | | https://bugzilla.gnome.org/show_bug.cgi?id=793708
* msdk: manage child sessions on parent GstMsdkContextHyunjun Ko2018-03-081-3/+19
| | | | | | | | | | | | 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
* msdk: dec: remove code to manage buffers with locked surfaceHyunjun Ko2018-03-082-66/+2
| | | | https://bugzilla.gnome.org/show_bug.cgi?id=793413
* msdk: manage MSDK surfaces seperatelyHyunjun Ko2018-03-085-43/+279
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* wasapi: Increase rank to prefer over directsoundsrcNirbheek Chauhan2018-03-012-3/+5
| | | | | | | | | Directsoundsrc/sink have multiple issues, most of which cannot be fixed at all because the API is deprecated and is implemented as a compatibility wrapper around WASAPI since Vista. Users and developers should now use the wasapisrc/sink elements, and future development efforts should go towards that.
* wasapi: Clarify usage of low-latency property, add myself as authorNirbheek Chauhan2018-02-262-2/+12
| | | | | | | | | | | | | | | The low-latency property is *always* safe to enable, so applications that do realtime communication should set it, and the elements will automatically configure WASAPI to use the lowest possible device period, and the audioringbuffer in audiobasesink will also be configured accordingly. Applications can also use exclusive mode during capture and playback for the lowest possible latency if they know that the device will not be used by any other application. In this mode, the latency-time and buffer-time properties will be completely ignored.
* wasapi: Add a property for trying the AudioClient3 APINirbheek Chauhan2018-02-264-8/+64
| | | | | | | | | | | | | The AudioClient3 API is only available on Windows 10, and we will automatically detect when it is available and use it. However, using it for capturing audio with low latency and without glitches seems to require setting the realtime priority of the entire pipeline to "critical", which we cannot do from inside the element. Hence, we can only enable that by default for wasapisink since apps should be able to safely set the low-latency property to TRUE if they need low-latency capture or playback.
* wasapi: Set realtime thread priority at runtimeNirbheek Chauhan2018-02-264-20/+67
| | | | | Use LoadLibrary() to set the thread characteristics at runtime so it works automagically regardless of where or how the plugin was built.
* wasapi: Use IAudioClient3 interface when availableNirbheek Chauhan2018-02-265-124/+434
| | | | | | | | | | This allows us to request ultra-low-latency device periods even in shared mode. However, this requires good drivers and Windows 10, so we only enable this when we detect that we are running on Windows 10 at runtime. You can forcibly disable this feature on Windows 10 by setting GST_WASAPI_DISABLE_AUDIOCLIENT3=1 in the environment.
* wasapi: __uuidof is simply not available in CNirbheek Chauhan2018-02-261-13/+2
| | | | Fix comment, and don't try to use it at all.
* wasapi: Set a default category for util functionsNirbheek Chauhan2018-02-262-0/+8
| | | | | Without this, they all go to the default category where they can be missed
* wasapi: Use a macro for HRESULT failure pathsNirbheek Chauhan2018-02-264-246/+85
| | | | Saves a lot of boilerplate across all files.
* msdk: remove unused codeHyunjun Ko2018-02-231-182/+0
| | | | | | There's unused code remaining since MSDK bufferpool patches landed. https://bugzilla.gnome.org/show_bug.cgi?id=793741
* msdkenc: remove unnecessary memsetSreerenj Balachandran2018-02-221-5/+0
| | | | https://bugzilla.gnome.org/show_bug.cgi?id=791479
* msdk: enc: Support force-key-unit eventsSreerenj Balachandran2018-02-222-1/+13
| | | | https://bugzilla.gnome.org/show_bug.cgi?id=791479
* msdk: enc: Fix typoSreerenj Balachandran2018-02-201-1/+1
|
* msdk: h264_enc: Enable B-pyramid prediction supportSreerenj Balachandran2018-02-202-0/+22
| | | | | | | | | | | | | 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
* msdk: Add more tuning optionsSreerenj Balachandran2018-02-205-17/+99
| | | | | | | 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
* msdk: h264_enc: Add slice size tuning optionSreerenj Balachandran2018-02-202-3/+19
| | | | | | | | 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
* msdk: move enum definitions to separte fileSreerenj Balachandran2018-02-207-77/+163
| | | | | | | 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
* msdk: encoder: h264: Enable trellis quantization tuningSreerenj Balachandran2018-02-202-0/+42
| | | | | | | | | | | | | 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
* msdk: h264_enc: Add LookaheadDownsampling supportSreerenj Balachandran2018-02-202-7/+45
| | | | | | | | | | | 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
* msdk: encode: Add more rate control optionsSreerenj Balachandran2018-02-202-9/+113
| | | | | | | | | | | | | 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
* msdk: encode: Add property to set slice/partitioningSreerenj Balachandran2018-02-202-0/+4
| | | | | | | | 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
* msdk: encoder: h265: generalize the behavior of "i-frames" propertySreerenj Balachandran2018-02-201-0/+7
| | | | | | | | | | | | | 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
* msdk: encoder: register only the required propertiesSreerenj Balachandran2018-02-206-167/+400
| | | | | | | | | 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
* msdk: add missing files for dist targetVíctor Manuel Jáquez Leal2018-02-191-0/+7
| | | | https://bugzilla.gnome.org/show_bug.cgi?id=793563
* decklink: Fix array of devices usageEdward Hervey2018-02-141-31/+31
| | | | | | | We need to allocate actual Device structures since we are going to be setting callbacks with address to that structure https://bugzilla.gnome.org/show_bug.cgi?id=777239
* msdk: vc1_dec: Add Advanced profile (WVC1) supportSreerenj Balachandran2018-02-131-5/+25
| | | | | | | 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
* msdk: dec: Add non-packetized stream handling supportSreerenj Balachandran2018-02-132-3/+34
| | | | | | | | | | | | | | | | | | | The gst-msdk decoders prefer packetized streams as input and in this case we can avoid unnecessary input bitstream copy to mfxBitstream. This works fine for codecs like h264 where we only support byte-stream with au alignment. Other format conversions should be done thorugh parsers. But this won't work for codecs like vc1 where we don't have an autoplugged parser. Even the parser is not capable to do format conversions. Packetizing through base decoders parse() routine will bring a lot of uncecessary of complexities and codecparser libraray dependency. So we just use an interal gst_adaper to keep track of bitstream which is not consumed by msdk durig AsynchronusDecoding. This adapter will get used only if subclass implementations set the "is_packetized" to FALSE for msdk base encoder. https://bugzilla.gnome.org/show_bug.cgi?id=792589
* msdk: Add VC1 decoder (simple and main profiles)Sreerenj Balachandran2018-02-135-1/+189
| | | | | | | | | | | | | | | | | Adding Simple and Main profiles decode support. Currently msdkvc1dec is not capable to handle the codec_data, only instream headers are supported. Also msdk vc1 decoder expecting instream with Sequence header as per SMPTE 421M Annex L. Most of the decdoebin/playbin pipeline won't work with the above constraints because vc1parse is still not an autoplug element. Only way to make mskdvc1dec work is by connecting a vc1parse as an upstream element. https://bugzilla.gnome.org/show_bug.cgi?id=792589
* msdk : Add RenderNode supportSreerenj Balachandran2018-02-133-9/+69
| | | | | | | | | | | | | Use drm render node as the first choice of device node file. Fall backs to use drm primary (/dev/dri/card[0-9]) if there is no render node available Basic logic is inherited from gstreamer-vaapi, but using gudev API rather than libudev directly. Added gudev library as dependency for msdk. https://bugzilla.gnome.org/show_bug.cgi?id=791599
* msdk: Avoid build failures on Windows until d3d allocator is implementedHyunjun Ko2018-02-134-3/+102
| | | | https://bugzilla.gnome.org/show_bug.cgi?id=790752
* msdkdec: use video memory if there's another MSDK context in a pipelineHyunjun Ko2018-02-131-9/+14
| | | | | | | | | | | 1\ If downstream's pool is MSDK bufferpool, 2\ If there's shared GstMsdkContext in the pipeline, a decoder decides to use video memory. This policy should be improved to handle more cases. https://bugzilla.gnome.org/show_bug.cgi?id=790752
* msdk: add async depth from each msdk element to GstMsdkContext to be sharedHyunjun Ko2018-02-134-1/+36
| | | | | | | | | | | | In case that pipeline is like ".. ! decoder ! encoder ! ..." with using video memory, decoder needs to know the async depth of the following msdk element so that it could allocate the correct number of video memory. Otherwise, decoder's memory is exhausted while processing. https://bugzilla.gnome.org/show_bug.cgi?id=790752
View Lorry Controller Status