- Feb 24, 2017
-
-
Sebastian Dröge authored
-
- Feb 22, 2017
-
-
Víctor Manuel Jáquez Leal authored
Add encoder and codec name and the bitrate into the output for informational purposes. Some muxers or application use it as media metadata. https://bugzilla.gnome.org/show_bug.cgi?id=778781
-
Víctor Manuel Jáquez Leal authored
The encoder should be able to change its caps even it is already processing a stream. This is suppose to happen after a flush so the codedbuf_queue should be empty. https://bugzilla.gnome.org/show_bug.cgi?id=775490
-
Víctor Manuel Jáquez Leal authored
Bail out if the NAL unit type is not recognized. https://bugzilla.gnome.org/show_bug.cgi?id=778782
-
- Feb 16, 2017
-
-
Víctor Manuel Jáquez Leal authored
Configuring GCC to verify possible usage of uninitialized variables, shows that found_index might be used without previous assignation. This patch assigns a initial value to found_index, also avoid a branching when returning the result value. https://bugzilla.gnome.org/show_bug.cgi?id=778782
-
Scott D Phillips authored
Rename to be consistent with H.264 and also H.265 encoder. The meson build assumed this was already consistently named, and so previously was not able to actually build the H.265 decoder. https://bugzilla.gnome.org/show_bug.cgi?id=778576
-
- Feb 15, 2017
-
-
Tim-Philipp Müller authored
Just like in configure.ac.
-
Tim-Philipp Müller authored
Ship meson build files in tarballs, so people who use tarballs in their builds can start playing with meson already.
-
- Feb 10, 2017
-
-
Hyunjun Ko authored
This patch enables the Constant BitRate encoding mode in VP8 encoder. Basically it adds the configuration parameters required by libva to CBR enconding. Original-Patch-By: Víctor Manuel Jáquez Leal <victorx.jaquez@intel.com> https://bugzilla.gnome.org/show_bug.cgi?id=749950
-
Hyunjun Ko authored
Base encoder's unit of bitrate is in Kbps. We should honor it so we use the value of bitrate in VA, in which is expressed in bps. https://bugzilla.gnome.org/show_bug.cgi?id=749950
-
- Feb 09, 2017
-
-
Víctor Manuel Jáquez Leal authored
In commit a8e482f9 we added a function without parameters, but gcc doesn't like that.
-
-
-
Julien Isorce authored
When dmabuf is negotiated downstream and decoding and rendering are not done on the same device, the layout has to be linear in order for the memory to be shared accross devices, since each device has its own way to do tiling. Right now this code is rather just a to-do comment, since we are not fetching the device ids. https://bugzilla.gnome.org/show_bug.cgi?id=755072
-
- Feb 08, 2017
-
-
- Feb 07, 2017
-
-
Hyunjun Ko authored
Reduce frame num gaps so that we don't have to create unnecessary dummy pictures, just throw them away. Signed-off-by: Víctor Manuel Jáquez Leal <victorx.jaquez@intel.com> https://bugzilla.gnome.org/show_bug.cgi?id=777506
-
- Feb 03, 2017
-
-
Víctor Manuel Jáquez Leal authored
Do not add the meta:GstVideoGLTextureUploadMeta feature if the render element can handle dmabuf-based buffers, avoiding its negotiation.
-
Julien Isorce authored
Use new -base API gst_video_decoder_allocate_output_frame_full() to pass the current proxy/surface to the pool. The pool will will export thins given surface instead of exporting a brand new surface that will never be filled in with meaningfull data. https://bugzilla.gnome.org/show_bug.cgi?id=755072
-
Víctor Manuel Jáquez Leal authored
-
Julien Isorce authored
Overriding the vmethod acquire_buffer() it is possible to attach the right GstMemory to the current acquired buffer. As a matter of fact, this acquired buffer may contain any instantiated GstFdmemory, since this buffer have been popped out from the buffer pool, which is a FIFO queue. So there is no garantee that this buffer matches with the current processed surface. Evenmore, the VA driver might not use a FIFO queue. Therefore, it is no way to guess on the ordering. In short, acquire_buffer on the VA driver and on the buffer pool return none matching data, we have to manually attach the right GstFdMemory to the acquired GstBuffer. The right GstMemory is the one associated with the current surface. https://bugzilla.gnome.org/show_bug.cgi?id=755072
-
- Feb 02, 2017
-
-
Julien Isorce authored
gst_vaapi_dmabuf_memory_new() always exports a surface. Previously, it had to create that surface. Now it can also export an already provided surface. It is useful to export decoder's surfaces (from VA context). https://bugzilla.gnome.org/show_bug.cgi?id=755072
-
Julien Isorce authored
Useful to let the pool know the current surface proxy when calling gst_buffer_pool_alloc_buffer() / gst_buffer_pool_acquire_buffer() https://bugzilla.gnome.org/show_bug.cgi?id=755072
-
Julien Isorce authored
These functions are useful when a dmabuf-based memory is instantiated in order to relate the generated buffer @proxy with the processed @surface. https://bugzilla.gnome.org/show_bug.cgi?id=755072
-
Julien Isorce authored
This patch adds a GstMemory as a variable member of the buffer proxy, because we will need to associate the buffer proxy with the memory which exposes it. Later, we will know which memory, in the video buffer pool, is attached to the processed surface. https://bugzilla.gnome.org/show_bug.cgi?id=755072
-
Julien Isorce authored
Do not add the meta:GstVideoGLTextureUploadMeta feature if the render element can handle dmabuf-based buffers, avoiding its negotiation. Similar as "vaapidecode: do not add meta:GstVideoGLTextureUploadMeta feature if can dmabuf" https://bugzilla.gnome.org/show_bug.cgi?id=755072
-
Víctor Manuel Jáquez Leal authored
If the negotiated caps are raw caps and downstream supports the EGL_EXT_image_dma_buf_import extension, then the created allocator is the DMAbuf, configured to downstream. At this moment, the only element which can push dmabuf-based buffers to downstream, is vaapipostproc.
-
Víctor Manuel Jáquez Leal authored
In order to enable, in the future, dmabuf-based buffers, the vaapi base plugin needs to check if downstream can import dmabuf buffers. This patch checks if downstream can handle dmabuf, by introspecting the shared GL context. If the GL context is EGL/GLES2 and have the extension EGL_EXT_image_dma_buf_import, then dmabuf can be negotiated. Original-patch-by: Julien Isorce <j.isorce@samsung.com>
-
Julien Isorce authored
The surface created for downstream is going to be filled by VAAPI elements. So, the driver needs write access on that surface. This patch releases the derived image held by the proxy, thus the surface is unmarked as busy. This is how it has to be done as discussed on libva mailing list. https://bugzilla.gnome.org/show_bug.cgi?id=755072
-
Julien Isorce authored
Adds an API to request the user's data release in the buffer proxy. https://bugzilla.gnome.org/show_bug.cgi?id=755072
-
Julien Isorce authored
Add GstPadDirection param to gst_vaapi_dmabuf_allocator_new(), thus we later could do different thing when the allocated memory is for upstream or dowstream, as required by VA-API. https://bugzilla.gnome.org/show_bug.cgi?id=755072
-
- Feb 01, 2017
-
-
Hyunjun Ko authored
Thus, when generating the allowed caps, the element will throw a warning and it will use its caps template. This behavior might be a bug in the VA driver. https://bugzilla.gnome.org/show_bug.cgi?id=775490
-
Víctor Manuel Jáquez Leal authored
This reverts commit 200b1baa.
-
Hyunjun Ko authored
A value of width/height property should be set to out caps, if negotiation had been going properly. So we can use srcpad_info when making decision of scaling. https://bugzilla.gnome.org/show_bug.cgi?id=778010
-
- Jan 27, 2017
-
-
Víctor Manuel Jáquez Leal authored
If the element instantiated the GL display and context, they should handle them too through the context query. https://bugzilla.gnome.org/show_bug.cgi?id=777409
-
Víctor Manuel Jáquez Leal authored
If a GstVaapiDisplay is not found in the GStreamer context sharing, then VAAPI elements look for a local GstGLContext in gst context sharing mechanism ('gst.gl.local.context'). If this GstGLContext not found either then, only the VAAPI decoders and the VAAPI post-processor, will try to instantiate a new GstGLContext. If a valid GstGLContext is received, then a new GstVaapiDisplay will be instantiated with the platform, API and windowing specified by the instantiated GstGLContext. Original-Patch-By: Matt Fischer <matt.fischer@garmin.com> https://bugzilla.gnome.org/show_bug.cgi?id=777409
-
- Jan 26, 2017
-
-
Víctor Manuel Jáquez Leal authored
Instead of calling g_return_val_if_fail() to check the context type, we should use a normal conditional, since it is possible that other context types can arrive and try to be assigned. Otherwise a critical log message is printed. This happens when we use playbin3 with vaapipostproc as video-filter. https://bugzilla.gnome.org/show_bug.cgi?id=777409
-
- Jan 20, 2017
-
-
Víctor Manuel Jáquez Leal authored
Use the sink caps pixel-aspect-ratio to fixate the src caps, if it is not already set. https://bugzilla.gnome.org/show_bug.cgi?id=777395
-
Víctor Manuel Jáquez Leal authored
if the vaapipostproc is configured to not do deinterlacing, the interlace-mode in the src caps should be the same as the input caps. https://bugzilla.gnome.org/show_bug.cgi?id=777395
-
Víctor Manuel Jáquez Leal authored
warning: ISO C90 forbids mixed declarations and code [-Wdeclaration-after-statement]
-
- Jan 18, 2017
-
-
Víctor Manuel Jáquez Leal authored
Thus a race condition segfault is avoided. Original-patch-by: Matt Staples <staples255@gmail.com> https://bugzilla.gnome.org/show_bug.cgi?id=777146
-