summaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2017-04-06libs: encoder: vp9: Fix initialization of ref_listScott D Phillips1-1/+2
gcc 7.0.1 gives a memset-elt-size warning in gst_vaapi_encoder_vp9_init: 'memset' used with length equal to number of elements without multiplication by element size [-Werror=memset-elt-size] https://bugzilla.gnome.org/show_bug.cgi?id=780947
2017-03-31encoder: h264: Fix Backward ReferencePicture flag settingSreerenj Balachandran1-1/+2
This is a regression introduced by e829b62 which override the reference flags and caused issues with latest intel-vaapi-driver.
2017-03-29libs: encoder: h265: fix code styleVíctor Manuel Jáquez Leal1-1/+1
Trivial patch to remove a double ';' as end of instruction.
2017-03-28encoder: h264: Fix B frame encoding artifactsSreerenj Balachandran1-0/+14
The current implementation is updating the POC values only in Slice parameter Buffer.But we are not filling the picture order count and reference flags in VAPictureH264 while populating VA Picture/Slice structures.The latest intel-vaapi-driver is directly accessing the above fields from VAPicutreH264 provided as RefPicLists, which resulted some wrong maths and prediction errors in driver. https://bugzilla.gnome.org/show_bug.cgi?id=780620
2017-03-21libs: encoder: h265: remove unused macro definitionVíctor Manuel Jáquez Leal1-5/+0
Since the h265 encoder doesn't use GValueArray, there is no need to disable the Glib deprecation warnings, thus removing the macro definition.
2017-03-20plugins: when debug disabled, default category is NULLVíctor Manuel Jáquez Leal4-0/+16
As in gstreamer-vaapi a common base class is used, the specific default category is passed to the base-plugin initializator, thus the log messages are categorized with the used plugin. Nonetheless, when the gst-debug is disabled in compilation time, it is needed to pass NULL to the base-plugin initializator. This patch does that. https://bugzilla.gnome.org/show_bug.cgi?id=780302
2017-03-20libs: h26x: adds gst_vaapi_utils_h26x_write_nal_unit()Hyunjun Ko4-10/+127
Implements gst_vaapi_utils_h26x_write_nal_unit(), which writes NAL unit length and data to a bitwriter. Note that this helper function applies EPB (Emulation Prevention Bytes), since otherwise produced codec_data might be broken when decoder/parser considering EPB, starts parsing. See sections 7.3 and 7.4 of the H264 and H264 specifications, which describes the emulation_prevention_three_byte. https://bugzilla.gnome.org/show_bug.cgi?id=778750 Signed-off-by: Víctor Manuel Jáquez Leal <victorx.jaquez@intel.com>
2017-03-20libs: utils: h26x: create vaapiutils_h26xHyunjun Ko6-150/+145
Since there is duplicated code in h264/265 encoder, we could refactor it to avoid duplicated code. https://bugzilla.gnome.org/show_bug.cgi?id=778750 Signed-off-by: Víctor Manuel Jáquez Leal <victorx.jaquez@intel.com>
2017-03-17libs: encoder: h264/5: fix wrong return valueHyunjun Ko2-2/+2
https://bugzilla.gnome.org/show_bug.cgi?id=778750
2017-03-14docs: h264/h265: put parser to the example pipelineHyunjun Ko2-2/+2
https://bugzilla.gnome.org/show_bug.cgi?id=778749
2017-03-14libs: encoder: h265: fix reserved length of bitsHyunjun Ko1-2/+2
Fix reserved length of bits for bit_depth_luma_minus8 and bit_depth_chroma_minus8 https://bugzilla.gnome.org/show_bug.cgi?id=778749
2017-03-14O_CLOEXEC needs _GNU_SOURCE definedThomas Petazzoni2-0/+2
From man open(2): The O_CLOEXEC, O_DIRECTORY, and O_NOFOLLOW flags are not specified in POSIX.1-2001, but are specified in POSIX.1-2008. Since glibc 2.12, one can obtain their definitions by defining either _POSIX_C_SOURCE with a value greater than or equal to 200809L or _XOPEN_SOURCE with a value greater than or equal to 700. In glibc 2.11 and earlier, one obtains the definitions by defining _GNU_SOURCE. And indeed, with the uClibc C library, O_CLOEXEC is not exposed if _GNU_SOURCE is not defined. Therefore, this commit fixes the build of gstreamer-vaapi with the uClibc C library. Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> https://bugzilla.gnome.org/show_bug.cgi?id=779953
2017-03-14README: fix "Sources" sectionVíctor Manuel Jáquez Leal1-1/+1
Update the URL where the release source tarballs can be downloaded.
2017-03-14README: fix "Reporting bugs" sectionThomas Petazzoni1-4/+1
The "Reporting bugs" section gives https://bugzilla.gnome.org/enter_bug.cgi?product=gstreamer-vaapi as the link to report a bug, but this link says "Sorry, entering a bug into the product gstreamer-vaapi has been disabled.". This commit fixes the URL to point to the proper location, and also removes the following paragraph that is no longer correct. Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> https://bugzilla.gnome.org/show_bug.cgi?id=779954
2017-03-03plugins: retry to create the VA displayVíctor Manuel Jáquez Leal1-3/+9
Particularly in GNOME Wayland, the negotiated or created GL context defines a GLX environment, but VAAPI fails to create a GLX VA display because there is no a DRI2 connection. This patch retries to create the VA display if VA cannot create one with the GL context parameters. Now using the old list of display types. This should also work in the case of systems with two GPU, when the non-VAAPI has the graphics environment, and the VAAPI-enabled one shall work headless. https://bugzilla.gnome.org/show_bug.cgi?id=772838
2017-03-03vaapipostproc: texture upload if driver supports GLJulien Isorce1-1/+3
Removes GstVideoGLTextureUploadMeta caps feature if the driver doesn't support opengl. Signed-off-by: Víctor Manuel Jáquez Leal <victorx.jaquez@intel.com> https://bugzilla.gnome.org/show_bug.cgi?id=772838
2017-03-03vaapidecode: texture upload if driver supports GLVíctor Manuel Jáquez Leal1-1/+2
When the allowed source pad caps are generated, the GLTextureUpload caps are only inserted if the driver support OpenGL. https://bugzilla.gnome.org/show_bug.cgi?id=772838
2017-03-02configure: Add missing compiler flagsSreerenj Balachandran1-14/+12
The AC_CHECK_HEADERS macro was failing to locate some headers, in particular the va_enc_* headers due to missing compiler flags. https://bugzilla.gnome.org/show_bug.cgi?id=779101 Signed-off-by: Víctor Manuel Jáquez Leal <victorx.jaquez@intel.com>
2017-03-02libs: window: wayland: handle more VAStatus to use vppHyunjun Ko1-1/+3
Since the commit landed https://github.com/01org/intel-vaapi-driver/pull/55, we should consider more returned VAStatus to use vpp. https://bugzilla.gnome.org/show_bug.cgi?id=779400
2017-02-28libs: encoder: ensure profile when context initializationHyunjun Ko1-1/+1
We can't be sure that encoder's profile is assgined already or not at context initialization. https://bugzilla.gnome.org/show_bug.cgi?id=779120
2017-02-28libs: encoder: set rate control info only when query succeedHyunjun Ko1-3/+4
Currently, it set rate control information even when query fails. In addition, it doesn't update any more since the flag got_rate_control_mask is set to TRUE. https://bugzilla.gnome.org/show_bug.cgi?id=779120
2017-02-24meson: Update versionSebastian Dröge1-1/+1
2017-02-24Back to developmentSebastian Dröge1-4/+4
2017-02-24Release 1.11.21.11.2Sebastian Dröge4-10/+437
2017-02-22vaapiencode: merge tags for downstream's infoVíctor Manuel Jáquez Leal1-1/+33
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
2017-02-22libs: encoder: caps can change at any timeVíctor Manuel Jáquez Leal1-10/+0
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
2017-02-22libs: encoder: h265: bail if nal unit type failsVíctor Manuel Jáquez Leal1-1/+2
Bail out if the NAL unit type is not recognized. https://bugzilla.gnome.org/show_bug.cgi?id=778782
2017-02-16libs: decoder: h264,h265 avoid uninitialized variableVíctor Manuel Jáquez Leal2-8/+8
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
2017-02-16build: rename USE_HEVC_DECODER to USE_H265_DECODERScott D Phillips4-12/+12
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
2017-02-15meson: gstreamer-codecparsers is a required depTim-Philipp Müller1-1/+1
Just like in configure.ac.
2017-02-15meson: dist meson build filesTim-Philipp Müller1-1/+3
Ship meson build files in tarballs, so people who use tarballs in their builds can start playing with meson already.
2017-02-10libs: encoder: vp8: add CBR encoding modeHyunjun Ko1-1/+67
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
2017-02-10libs: encoder: vp8: fix bitrate calculationHyunjun Ko1-2/+3
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
2017-02-09plugins: fix build when gccVíctor Manuel Jáquez Leal1-1/+1
In commit a8e482f9 we added a function without parameters, but gcc doesn't like that.
2017-02-09vaapi: add meson buildScott D Phillips8-0/+441
https://bugzilla.gnome.org/show_bug.cgi?id=778250
2017-02-09make: remove gstvaapiversion.h generationScott D Phillips4-81/+1
https://bugzilla.gnome.org/show_bug.cgi?id=778250
2017-02-09plugins: use linear storage if not the same deviceJulien Isorce1-4/+22
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
2017-02-08libs: utils: add HEVC profiles representationHyunjun Ko1-0/+4
https://bugzilla.gnome.org/show_bug.cgi?id=778318
2017-02-07libs: decoder: h264: reduce frame number of gapsHyunjun Ko1-2/+15
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
2017-02-03vaapidecode: don't GLTextureUpload if dmabufVíctor Manuel Jáquez Leal1-5/+8
Do not add the meta:GstVideoGLTextureUploadMeta feature if the render element can handle dmabuf-based buffers, avoiding its negotiation.
2017-02-03vaapidecode: make pool to export decoder's surfaceJulien Isorce1-5/+29
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
2017-02-03plugins: decoder can negotiate dmabuf downstreamVíctor Manuel Jáquez Leal1-1/+1
2017-02-03vaapivideobufferpool: override acquire_buffer()Julien Isorce1-0/+70
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
2017-02-02vaapivideomemory: export surface if it is providedJulien Isorce2-15/+48
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
2017-02-02vaapivideobufferpool: add GstVaapiVideoBufferPoolAcquireParamsJulien Isorce1-0/+20
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
2017-02-02libs: surface: add gst_vaapi_surface_{set,peek}_buffer_proxy()Julien Isorce2-0/+40
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
2017-02-02libs: bufferproxy: gst_vaapi_buffer_proxy_{set,peek}_mem()Julien Isorce3-0/+47
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
2017-02-02vaapipostproc: don't GLTextureUpload if dmabufJulien Isorce1-1/+9
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
2017-02-02plugins: enable DMAbuf allocator to downstreamVíctor Manuel Jáquez Leal1-4/+17
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.
2017-02-02plugins: check if negotiate dmabuf with downstreamVíctor Manuel Jáquez Leal2-1/+10
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>
generated by cgit v1.2.3 (git 2.39.1) at 2024-04-20 00:43:56 +0000