summaryrefslogtreecommitdiff
path: root/gst
AgeCommit message (Collapse)AuthorFilesLines
2017-08-08vaapiencode: h264: remove spurious codeVíctor Manuel Jáquez Leal1-1/+1
Coverity scan bug: An unsigned value can never be negative, so this test will always evaluate the same way. As len is guint32, there is no need to check it if it is equal or bigger than zero.
2017-08-08vaapidecode: initialize variableVíctor Manuel Jáquez Leal1-1/+1
Coverity scan bug: The variable will contain an arbitrary value left from earlier computations. Variable base_only is fetched from base-only property, and it may be not assigned. It needs to be initialized.
2017-08-03vaapidecode: fix gst_caps_new_simple callorestisf1-1/+2
https://bugzilla.gnome.org/show_bug.cgi?id=732265
2017-08-03vaapidecode: force add h264 MVC profiles in capsorestisf1-0/+33
When vaapih264dec's base-only profile is set to TRUE, fake MVC profile support in caps. https://bugzilla.gnome.org/show_bug.cgi?id=732265
2017-08-03vaapidecode: set h264 base-only to decoderorestisf2-0/+5
Set the base-only value when property is set and the internal decoder is already instantiated or when the internal decoder is created. https://bugzilla.gnome.org/show_bug.cgi?id=732265
2017-08-03vaapidecode_props: h264: add base-only propertyorestisf2-0/+13
https://bugzilla.gnome.org/show_bug.cgi?id=732265
2017-08-01vaapiencode: h265: compare an unsigned int if not zeroVíctor Manuel Jáquez Leal1-1/+1
An unsigned value can never be negative, so this test (greater than zero) will always evaluate the same way. Thus change it to just if it's not zero.
2017-08-01plugins: check gst_gl_ensure_element_data() return valueVíctor Manuel Jáquez Leal1-8/+14
Refactor gst_vaapi_plugin_base_create_gl_context() in order to check the return value of gst_gl_ensure_element_data(). The result is a code bit cleaner.
2017-08-01plugins: avoid dead code detectionVíctor Manuel Jáquez Leal1-2/+1
By using #elif macro, the static code analysis would stop to detect these lines as dead code. Also it is inforced the mutually exclusive environments.
2017-08-01vaapivideobufferpool: don't shift by negative since it's undefinedVíctor Manuel Jáquez Leal1-3/+6
The function g_bit_nth_lsf() may return -1 if the request bit position is not avaible. Thus, this patch check if the return value is not -1 in order to continue.
2017-08-01vaapisink: fix memory leakVíctor Manuel Jáquez Leal1-2/+3
2017-08-01vaapipostproc: fix memory leaksVíctor Manuel Jáquez Leal1-3/+9
2017-07-26vaapisink: fail if surface display is differentHyunjun Ko1-2/+10
Replacing GstVaapiDisplay during rendering might be hiding problems at some cases, even though it's safe currently since we use cache of GstVaapidisplay. Play safe by failing if this happens. https://bugzilla.gnome.org/show_bug.cgi?id=766704
2017-07-18videocontext: support "gst.vaapi.app.Display" contextHyunjun Ko2-6/+37
Through "gst.vaapi.app.Display" context, users can set their own VADisplay and native display of their backend. Attributes: - display : pointer of VADisplay - x11-display : pointer of X11 display (Display *), if they're using. This patch creates GstVaapidisplayX11 if information provided through "gst.vaapi.app.Display" https://bugzilla.gnome.org/show_bug.cgi?id=766704
2017-07-18postproc: reconfigure when width or height changesHyunjun Ko1-1/+10
https://bugzilla.gnome.org/show_bug.cgi?id=754885
2017-07-13vaapiencode: h264: add plugin documentationVíctor Manuel Jáquez Leal1-0/+25
Comment how the profile is set and other parameters.
2017-07-10vaapidecode_props: h264: set low-latency in decoderVíctor Manuel Jáquez Leal1-0/+7
Set the low-latency property if the H264 decoder is already instantiated, thus you could change the behavior in run-time. https://bugzilla.gnome.org/show_bug.cgi?id=783588
2017-07-07vaapidecode: set h264 low latency to decoderVíctor Manuel Jáquez Leal1-0/+7
https://bugzilla.gnome.org/show_bug.cgi?id=783588
2017-07-07vaapidecode_props: h264: add low latency propertyVíctor Manuel Jáquez Leal2-0/+59
Adding support for private data. https://bugzilla.gnome.org/show_bug.cgi?id=783588
2017-07-07vaapidecode_props: add skeleton for h264 decoder propertiesVíctor Manuel Jáquez Leal5-1/+85
https://bugzilla.gnome.org/show_bug.cgi?id=783588
2017-07-07vaapidecode: properties callback in decoders mapVíctor Manuel Jáquez Leal1-10/+15
https://bugzilla.gnome.org/show_bug.cgi?id=783588
2017-07-03vaapiencode: h264: set profile to src capsHyunjun Ko1-1/+57
So far vaapi encoder does not set profile to src caps. This patch makes it setting profile to src caps, which is determined by itself. In addition, if encoder chose different profile, which is not negotiated with downstream, we should set compatible profile to make negotiation working. https://bugzilla.gnome.org/show_bug.cgi?id=757941
2017-07-03vaapiencode: h264: verify if requested profile is supportedVíctor Manuel Jáquez Leal2-0/+61
Check if the requested profile in source caps, is supported by the VA driver. If it is not, an info log message is send saying that another (compatible?) profile will be used. https://bugzilla.gnome.org/show_bug.cgi?id=757941
2017-07-03vaapiencode: h264: improve set_config() vmethodVíctor Manuel Jáquez Leal1-28/+48
First check if downstream requests ANY caps. If so, byte-stream is used and the profile will be choose by the encoder. If dowstream requests EMPTY caps, the negotiation will fail. Lately, byte-stream and profile are looked in the allowed caps. https://bugzilla.gnome.org/show_bug.cgi?id=757941
2017-07-03vaapiencode: h264: check for avc in set_config()Víctor Manuel Jáquez Leal1-23/+18
The check for avc stream format was done in the vaapi encoder's vmethod get_caps(), but that is wrong since it has to be check when encoder set_format(). https://bugzilla.gnome.org/show_bug.cgi?id=757941
2017-07-03vaapipostproc: set multivew-mode flags to src capsHyunjun Ko1-0/+25
vaapipostproc didn't negotiate the proper multiview caps losing downstream information. This patch enables the playing of MVC encoded stream by setting the proper multiview mode/flags and views to src caps, according to sink caps. https://bugzilla.gnome.org/show_bug.cgi?id=784320
2017-06-23vaapipostproc: add support for DMABuf caps featureJulien Isorce1-1/+2
https://bugzilla.gnome.org/show_bug.cgi?id=755072 Signed-off-by: Julien Isorce <j.isorce@samsung.com>
2017-06-23vaapidecode: add support for DMABuf caps featureVíctor Manuel Jáquez Leal1-1/+5
https://bugzilla.gnome.org/show_bug.cgi?id=755072 Original-patch-by: Julien Isorce <j.isorce@samsung.com>
2017-06-23vaapipluginbase: force dmabuf allocator if DMABuf caps featureVíctor Manuel Jáquez Leal1-0/+6
Instantiate all dmabuf allocator for src pad buffer pool if the src caps ask for memory:DMABuf feature. https://bugzilla.gnome.org/show_bug.cgi?id=755072
2017-06-23vaapipluginutil: add support for DMABuf caps featureJulien Isorce2-0/+9
https://bugzilla.gnome.org/show_bug.cgi?id=755072 Signed-off-by: Julien Isorce <j.isorce@samsung.com> Signed-off-by: Victor Jaquez <vjaquez@igalia.com> vaapipluginutil: add support for DMABuf caps feature
2017-06-23vaapipluginbase: dmabuf memory map trial for raw capsVíctor Manuel Jáquez Leal1-7/+29
Only push dmabuf-based buffers with raw caps if gst_memory_map() succeeds. Otherwise, use the the vaapi surfaces allocator. https://bugzilla.gnome.org/show_bug.cgi?id=755072 https://bugzilla.gnome.org/show_bug.cgi?id=774649 Original-patch-by: Julien Isorce <j.isorce@samsung.com>
2017-06-23vaapivideomemory: add gst_vaapi_dmabuf_can_map()Víctor Manuel Jáquez Leal2-0/+51
This new method checks the specified allocator can create GstMemory that can be mapped. https://bugzilla.gnome.org/show_bug.cgi?id=755072
2017-06-23vaapivideobufferpool: fix regression with video metasVíctor Manuel Jáquez Leal1-2/+2
There is another regression with 7a206923 when setting the video info for the video meta, it should be the one from the image's allocator rather from the allocation caps. Test pipeline: gst-launch-1.0 filesrc location=bug766184.flv ! decodebin \ ! tee ! videoconvert ! videoscale \ ! video/x-raw, width=1920, height=1080 ! xvimagesink
2017-06-23plugins: update buffer size with the one reported by allocatorVíctor Manuel Jáquez Leal2-11/+27
There is a regression in 7a206923, since the buffer pool ditches all the buffers generated by them because the pool config size is different of the buffer's size. Test pipeline: gst-launch-1.0 filesrc location=big_buck_bunny_1080p_h264.mov \ ! qtdemux ! vaapih264dec ! vaapipostproc ! xvimagesink \ --gst-debug=GST_PERFORMANCE:5 The allocator may update the buffer size according to the VA surface properties. In order to do this, the video info is modified when the allocator is created, which reports through the allocation info the updated size, and set it to the pool config.
2017-06-12vaapivideobufferpool: remove allocation_vinfo private attributeVíctor Manuel Jáquez Leal1-10/+6
There is no need to keep this attribute internally since it is already managed by the allocator. https://bugzilla.gnome.org/show_bug.cgi?id=783599
2017-06-12vaapivideobufferpool: refactor set_config()Víctor Manuel Jáquez Leal1-44/+66
Refactor the set_config() virtual method considering a cleaner approach to allocator instanciation, if it it not set or if it is not valid for the pool. https://bugzilla.gnome.org/show_bug.cgi?id=783599
2017-06-12plugins: distinguish allocation and negotiation capsVíctor Manuel Jáquez Leal4-40/+98
The vaapi video decoders might have different allocation caps from the negotiation caps, thus the GstVideoMeta shall use the negotiation caps, not the allocation caps. This was done before reusing gst_allocator_get_vaapi_video_info(), storing there the negotiation caps if they differ from the allocation ones, but this strategy felt short when the allocator had to be reset in the vaapi buffer pool, since we need both. This patch adds gst_allocator_set_vaapi_negotiated_video_info() and gst_allocator_get_vaapi_negotiated_video_info() to store the negotiated video info in the allocator, and distinguish it from the allocation video info. https://bugzilla.gnome.org/show_bug.cgi?id=783599
2017-06-09vaapivideomemory: rename qdata quarks and idsVíctor Manuel Jáquez Leal2-19/+25
Also the parameter names were renamed to reflect their origin and purpose. https://bugzilla.gnome.org/show_bug.cgi?id=783599
2017-06-09vaapivideobufferpool: rename local variablesVíctor Manuel Jáquez Leal1-13/+15
Renamed local video info structure names in set_config() vitual method. The purpose of their renaming is to clarify the origin of those structures, whether come from passed caps parameter (new_allocation_vinfo) or from the configured allocator (allocator_vinfo). https://bugzilla.gnome.org/show_bug.cgi?id=783599
2017-06-09vaapivideobufferpool: rename video info structuresVíctor Manuel Jáquez Leal1-15/+16
Renamed private GstVideoInfo structure video_info to allocation_vinfo and alloc_info to negotiated_vinfo. The purpose of these renaming is to clarify the origin and purpose of these private variables: video_info (now allocation_vinfo) comes from the bufferpool configuration. It describes the physical video resolution to be allocated by the allocator, which may be different from the negotiated one. alloc_info (now vmeta_vinfo) comes from the negotiated caps in the pipeline. It represents how the frame is going to be mapped using the video meta. In Intel's VA-API backend, the allocation_vinfo resolution is bigger than the negotiated_info. https://bugzilla.gnome.org/show_bug.cgi?id=783599
2017-05-12vaapisink: keep handle_events flag except that if user want to setHyunjun Ko1-1/+1
When state of vaapisink is changed from PLAYING to NULL, the handle_events flag is set to FALSE, and never recovered, and then event thread is never going to run. So we should allow to set the flag only when users try it. https://bugzilla.gnome.org/show_bug.cgi?id=782543
2017-05-12plugins: remove par from caps negotiationVíctor Manuel Jáquez Leal1-2/+1
https://bugzilla.gnome.org/show_bug.cgi?id=781759
2017-05-12vaapiencode: handle custom event GstVaapiEncoderRegionOfInterestHyunjun Ko2-0/+113
Handles new custom event GstVaapiEncoderRegionOfInterest to enable/disable a ROI region. Writes a way to use new event to document. https://bugzilla.gnome.org/show_bug.cgi?id=768248 Signed-off-by: Víctor Manuel Jáquez Leal <vjaquez@igalia.com>
2017-05-04Revert "vaapidecodebin: fix element's classification"Víctor Manuel Jáquez Leal1-1/+1
This reverts commit 8cbe03599a4f27c2001380e2ec150c4f4267a9cf.
2017-05-02vaapidecodebin: fix element's classificationVictor Toso1-1/+1
This bin should have similar classification as decodebin which is "Generic/Bin/Decoder" otherwise it will appear wrongly as video decoder. Signed-off-by: Victor Toso <victortoso@redhat.com> https://bugzilla.gnome.org/show_bug.cgi?id=782063
2017-04-27Revert "plugins: reject pixel-aspect-ratio with value 0/1"Víctor Manuel Jáquez Leal1-1/+1
This reverts commit c0be7b1890ea8da915a81ae82bc9f504aee7cc26.
2017-04-27plugins: reject pixel-aspect-ratio with value 0/1Víctor Manuel Jáquez Leal1-1/+1
Do not negotiate a pixel-aspect-ratio of 0/1. https://bugzilla.gnome.org/show_bug.cgi?id=781759
2017-04-27plugins: handle pixel-aspect-ratio with value 0/1Víctor Manuel Jáquez Leal2-0/+4
When downstream negotiates a pixel-aspect-ratio of 0/1, the calculations for resizing and formatting in vaapipostproc and vaapisink, respectively, failed, and thus the pipeline. This patch handles this situation by converting p-a-r of 0/1 to 1/1. This is how other sinks, such as glimagesink, work. https://bugzilla.gnome.org/show_bug.cgi?id=781759
2017-04-27vaapivideobufferpool: fix leak of created allocatorHyunjun Ko1-0/+1
Since it's created by itself, it should be unref-counted after gst_buffer_pool_config_set_allocator call. Afterwards, this allocator will be ref-counted again when assigning to priv->allocator. https://bugzilla.gnome.org/show_bug.cgi?id=781577
2017-04-25vaapivideobufferpool: create or reconfig allocatorVíctor Manuel Jáquez Leal1-0/+21
Sometimes a video decoder could set different buffer pool configurations, because their frame size changes. In this case we did not reconfigure the allocator. This patch enables this use case, creating a new allocator inside the VAAPI buffer pool if the caps changed, if it is not dmabuf-based. If so, it is just reconfigured, since it doesn't have a surface pool. https://bugzilla.gnome.org/show_bug.cgi?id=781577
generated by cgit v1.2.3 (git 2.39.1) at 2024-06-05 16:37:58 +0000