summaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2018-01-10tests: y4mreader: fix incompatible castVíctor Manuel Jáquez Leal1-6/+9
Passed pointer in parse_int() are unsigned int (32 bits, unsigned) but they are dereferenced as a wider long (64 bits, signed). This may lead to memory corruption.
2017-12-19meson: fix fallback for gstreamer-gl-1.0, it's now in -baseTim-Philipp Müller1-1/+1
2017-12-14Automatic update of common submoduleMatthew Waters1-0/+0
From e8c7a71 to 3fa2c9e
2017-12-06videoconvert: gst_element_post_message() is transfer full on msgNicolas Dufresne1-1/+0
For this reson we need not to unref the message, even if it failed.
2017-12-06Revert "vaapivideocontext: possible memleak when no bus attached"Nicolas Dufresne1-3/+1
This reverts commit 0438a3e62660e64ed390b6bb83bfb560b91664aa.
2017-12-06test: vaapicontext: process have-context bus messageVíctor Manuel Jáquez Leal1-0/+40
2017-12-06test: vaapicontext: app context is not persistentVíctor Manuel Jáquez Leal1-1/+1
2017-12-01vaapivideocontext: only vaapisink process app contextVíctor Manuel Jáquez Leal3-18/+60
gst.vaapi.app.Display context is made for applications that will provide the VA display and the native display to used by the pipeline, when are using vaapisink as overlay. There are no use case for encoders, decoders, neither for the postprocessor. In the case of the vaapisink, it shall query for gst.vaapi.Display upstream first, and then, if there is no reply, gst.vaapi.app.Display context will be posted in the bus for the application. If the application replies, a GstVaapiDisplay object is instantiated given the context info, otherwise a GstVaapiDisplay is created with the normal algorithm to guess the graphics platform. Either way, the instantiated GstVaapiDisplay is propagated among the pipeline and the have-message bus message. Also only vaapisink will process the gst.vaapi.app.Display, if and only if, it doesn't have a display already set. This is caused because if vaapisink is in a bin (playsink, for example) the need-context is posted twice, leading to an error state. https://bugzilla.gnome.org/show_bug.cgi?id=790999
2017-12-01vaapivideocontext: log the name of GstVaapiDisplayVíctor Manuel Jáquez Leal1-5/+8
https://bugzilla.gnome.org/show_bug.cgi?id=790999
2017-12-01vaapivideocontext: possible memleak when no bus attachedVíctor Manuel Jáquez Leal1-1/+3
https://bugzilla.gnome.org/show_bug.cgi?id=790999
2017-11-27libs: window: wayland: remove unused header includeVíctor Manuel Jáquez Leal1-1/+0
Remove wayland-client.h include since there is no exposed symbols from it.
2017-11-27libs: encoder: h264,h265: guard rate control's macroblockVíctor Manuel Jáquez Leal2-0/+6
macroblock parameter appear on VA-API 1.0.0. It should be guarded.
2017-11-27Automatic update of common submoduleMatthew Waters1-0/+0
From 3f4aa96 to e8c7a71
2017-11-08libs: encoder: h264: Add Hierarchical-B encodeSreerenj Balachandran1-15/+157
Frames are encoded as different layers. Frame in a particular layer will use pictures in lower or same layer as references. Which means decoder can drop the frames in upper layer but still decode lower layer frames. B-frames, except the one in top most layer, are reference frames. All the base layer frames are I or P. eg: with 3 temporal layers T3: B1 B3 B5 B7 T2: B2 B6 T1: I0 P4 P8 T1, T2, T3: Temporal Layers P1...Pn: P-Frames: B1...Bn: B-frames: T1: I0->P4 , P4->P8 etc.. T2: I0--> B2 <-- P4 T3: I0--> B1 <-- B2, B2 --> B3 <-- P4 Signed-off-by: Sreerenj Balachandran <sreerenj.balachandran@intel.com> https://bugzilla.gnome.org/show_bug.cgi?id=788918
2017-11-08libs: encoder: h264: Add Hierarchical-P encodeSreerenj Balachandran1-12/+143
Frames are encoded as different layers. A frame in a particular layer will use pictures in lower or same layer as references. Which means decoder can drop the frames in upper layer but still decode lower layer frames. eg: with 3 temporal layers T3: P1 P3 P5 P7 T2: P2 P6 T1: P0 P4 P8 T1, T2, T3: Temporal Layers P1...pn: P-Frames: P0->P1 , P0->P2, P2->P3, P0->P4......repeat Signed-off-by: Sreerenj Balachandran <sreerenj.balachandran@intel.com> https://bugzilla.gnome.org/show_bug.cgi?id=788918
2017-11-08libs: encoder: h264: Fix frame_num generationSreerenj Balachandran1-18/+30
The frame_num generation was not correctly implemented. According to h264 spec, frame_num should get incremented for each frame if previous frame is a referece frame. For eg: IPBPB sequece should have the frame numbers 0,1,2,2,3 Signed-off-by: Sreerenj Balachandran <sreerenj.balachandran@intel.com> https://bugzilla.gnome.org/show_bug.cgi?id=788918
2017-11-08libs: encoder: h264: Add new property "prediction-type"Sreerenj Balachandran2-0/+52
Adds new property "prediction-type" to select different reference picture selection modes like hierarchical-p, hierarchical-b etc. Signed-off-by: Sreerenj Balachandran <sreerenj.balachandran@intel.com> https://bugzilla.gnome.org/show_bug.cgi?id=788918
2017-11-08libs: encoder: h264: Add machinery for implementing hierarchical-predictionXuGuangxin2-5/+46
Adds some basic building blocks to ease the implementation of hierarchical prediction modes. -- add an utility method to find temporal level of each frame -- define max_ref_frame count based on temporal level count -- add temporal_level_div[] for finding temporal level each frame to be encoded. -- find ip_period based on temporal level count Signed-off-by: Sreerenj Balachandran <sreerenj.balachandran@intel.com> https://bugzilla.gnome.org/show_bug.cgi?id=788918
2017-11-08libs: encoder: h264: Add property "temporal-levels"XuGuangxin2-0/+24
Adds new property "temporal-levels" to select the number of temporal levels to be included in the encoded stream. Signed-off-by: Sreerenj Balachandran <sreerenj.balachandran@intel.com> https://bugzilla.gnome.org/show_bug.cgi?id=788918
2017-11-08libs: encoder: objects: Add a reference flagXuGuangxin1-2/+6
We can have p-frame as non-ref and also b-frame as ref which are not supported yet. Reference flag is the first machinery needed for more advanced reference picture selection modes. Signed-off-by: Sreerenj Balachandran <sreerenj.balachandran@intel.com> https://bugzilla.gnome.org/show_bug.cgi?id=788918
2017-11-06libs: surface: egl: add commentDaniel van Vugt1-0/+10
Add a warning comment when using old intel-vaapi-drivers (>1.8.4), where the creation of surfaces from GEM fd may fail. https://bugzilla.gnome.org/show_bug.cgi?id=773453
2017-11-02libs: display: egl: add gst_vaapi_display_egl_set_current_display()Víctor Manuel Jáquez Leal3-14/+28
Adds a new function that changes the internal EGL display to the current one (eglGetCurrentDisplay()) and sets the current context too (eglGetCurrentContext()). This new function is called by gst_vaapi_texture_egl_create() updating the GstVaapiDisplayEGL with the current EGL display. https://bugzilla.gnome.org/show_bug.cgi?id=773453
2017-11-01libs: texture: egl: update EGL display and contextVíctor Manuel Jáquez Leal1-1/+20
It is required to use the context of the calling thread when wrapping a foreign texture. According the documentation of GstVideoGLTextureUploadMeta: "The caller of gst_video_gl_texture_upload_meta_upload() must have OpenGL set up and call this from a thread where it is valid to upload something to an OpenGL texture." This patch updates the EGL display and context in GstVaapiDisplay instance to the one used by te renderer that uploads the texture. Original-patch-by: Daniel van Vugt <daniel.van.vugt@canonical.com> https://bugzilla.gnome.org/show_bug.cgi?id=773453
2017-11-01plugins: centralize assignation of GL objectsVíctor Manuel Jáquez Leal1-7/+18
Add plugin_set_gst_gl() where the GstGL objects are assigned. https://bugzilla.gnome.org/show_bug.cgi?id=773453
2017-11-01plugins: set GL objects if ensuredVíctor Manuel Jáquez Leal1-9/+7
Only set the GL display and GL other context if they are ensured. https://bugzilla.gnome.org/show_bug.cgi?id=773453
2017-11-01plugins: set GL objects if context is handledVíctor Manuel Jáquez Leal1-3/+10
Only set the GL display and GL other context if they are extracted correctly from the gstreamer's context. https://bugzilla.gnome.org/show_bug.cgi?id=773453
2017-11-01plugins: fix memory leak when GL context is createdVíctor Manuel Jáquez Leal1-0/+2
When the GL display and context are created inside an VAAPI element the created GL context is leaked. https://bugzilla.gnome.org/show_bug.cgi?id=773453
2017-11-01libs: display: egl: free leaked memoryVíctor Manuel Jáquez Leal1-0/+5
The EGL VAAPI display forgot to release the egl display, context and proxied VAAPI display. https://bugzilla.gnome.org/show_bug.cgi?id=773453
2017-11-01libs: texture: egl: code styleVíctor Manuel Jáquez Leal1-6/+12
https://bugzilla.gnome.org/show_bug.cgi?id=773453
2017-11-01libs: surface: egl: error message if no extensionVíctor Manuel Jáquez Leal1-13/+21
Instead of silently fail to export the image if there is not available the EGL_MESA_drm_image, log an error message. Also a code refactoring was done. https://bugzilla.gnome.org/show_bug.cgi?id=773453
2017-10-31plugins: direct rendering on memory:VASurfaceVíctor Manuel Jáquez Leal1-6/+8
As buffers negotiated with memory:VASurface caps feature can also be mapped, they can also be configured to use VA derived images, in other words "direct rendering". Also, because of the changes in dmabuf allocator as default allocator, the code for configuring the direct rendering was not clear. This patch cleans up the code and enables direct rendering when the environment variable GST_VAAPI_ENABLE_DIRECT_RENDERING is defined, even then the memory:VASurface cap feature is negotiated. https://bugzilla.gnome.org/show_bug.cgi?id=786054
2017-10-20plugins: only dmabuf on srcpad if downstreamVíctor Manuel Jáquez Leal2-1/+3
Set if source pad can handle dmabuf only if the GstGL context comes from downstream. It is possible to know that at two moments: 1\ In the case of GstGLTextureUpload caps feature is negotiated and downstream pool reports back gst.gl.GstGLContext. 2\ When GstGLContext is found as GstContext from dowstream. https://bugzilla.gnome.org/show_bug.cgi?id=788503
2017-10-20vaapivideocontext: add inline documentationVíctor Manuel Jáquez Leal1-0/+12
Document function gst_vaapi_find_gl_local_context(). https://bugzilla.gnome.org/show_bug.cgi?id=788503
2017-10-20vaapivideocontext: return the direction of gl contextVíctor Manuel Jáquez Leal3-3/+9
In function gst_vaapi_find_gl_context() add a direction parameter to return back the direction where the GstGL context was found. This is going to be useful when checking if downstream can import dmabuf-based buffers. https://bugzilla.gnome.org/show_bug.cgi?id=788503
2017-10-20plugins: add gst_vaapi_plugin_base_set_srcpad_can_dmabuf()Víctor Manuel Jáquez Leal2-6/+30
This patch refactors the code by adding the function vaapi_plugin_base_set_srcpad_can_dmabuf(), it determines if the passed GstGLContext can handle dmabuf-based buffers. The function is exposed publicly since it is intended to be used later at GstVaapiDisplay instantiation. https://bugzilla.gnome.org/show_bug.cgi?id=788503
2017-10-20vaapiencode: allow to set property on runtimeHyunjun Ko1-0/+7
Tis patch, allows some properties that we want to be set on runtime. (eg. bitrate) Note that all properties are under control by num_codedbuf_queued. https://bugzilla.gnome.org/show_bug.cgi?id=786321
2017-10-20libs: encoder: allow to set bitrate on runtimeHyunjun Ko1-9/+5
In case of streaming, controlling bitrate dynamically for encoder might be important to manage quality of the streaming. This patch is to support such a scenario. https://bugzilla.gnome.org/show_bug.cgi?id=786321
2017-10-20vaapidecodebin: Register element if no VPP support is available tooSebastian Dröge3-4/+50
VPP support is only needed for advanced deinterlacing, which is not enabled by default either. Error out if it is selected but VPP is not supported, and otherwise just work without VPP support. https://bugzilla.gnome.org/show_bug.cgi?id=788758
2017-10-16Avoid infinite loop when vaapi_create_display failsThibault Saunier1-1/+1
Which might be the case when using, for example, xvfb.
2017-10-03libs: utils: log warn if display failVíctor Manuel Jáquez Leal1-1/+18
gstreamer-vaapi initializes the display by trial-and-error, thus logging an error message if the display initialisation fails the user may be weary of the error message in the screen, if using VA-API 1.0 This commit set the VA error log handler to GStreamer warning level while calling vaInitialize() and set it to error after that. https://bugzilla.gnome.org/show_bug.cgi?id=783169
2017-10-03plugins: try to create test display in orderVíctor Manuel Jáquez Leal1-2/+22
When creating the test display for querying capabilites, it try in certain order: DRM, Wayland and finally X11. GLX nor EGL are tried since they are either composited with X11 or Wayland. The reason for this is to reduce the posibility of failure that could blacklist the plugin. https://bugzilla.gnome.org/show_bug.cgi?id=782212
2017-10-03libs: display: delay getting screen resolutionVíctor Manuel Jáquez Leal2-5/+28
Instead of extracting the screen resolution at GstVaapiDisplay creation, this patch delay it until the screen size is requested for first time. https://bugzilla.gnome.org/show_bug.cgi?id=782212
2017-10-03libs: display: egl: avoid two vaDisplay instantiatesVíctor Manuel Jáquez Leal1-0/+7
GstVaapiDisplayEGL is a wrapper of another GstVaapiDisplay, either X11 or Wayland. Nonetheless it created another vaDisplay for it, instead of using the wrapped one. This patch enables the reuse of the wrapped vaDisplay avoiding instantiating two. https://bugzilla.gnome.org/show_bug.cgi?id=782212
2017-10-03libs: display: remove display_type from display infoVíctor Manuel Jáquez Leal5-8/+0
Since it's no required to pass the display type in the display info, the structure member is removed. https://bugzilla.gnome.org/show_bug.cgi?id=782212
2017-10-03libs: display: remove display_type memberVíctor Manuel Jáquez Leal2-8/+3
It is not used any more since GstVaapiDisplay was ported as a GstObject-based. This information is part of the class information. https://bugzilla.gnome.org/show_bug.cgi?id=782212
2017-10-03libs: display: remove parent memberVíctor Manuel Jáquez Leal2-13/+3
Parent was a crumb left from display cache. https://bugzilla.gnome.org/show_bug.cgi?id=782212
2017-10-03vaapi: Also register vaapipostproc without VPP supportSebastian Dröge1-3/+3
It can still do simple deinterlacing then.
2017-10-03vaapipostproc: Allow running without VPP supportSebastian Dröge1-2/+2
We returned FALSE from ::start() if VPP support is not available, but it is only really needed for complex filters and during transform we check for that. For simple deinterlacing it is not needed.
2017-09-28vaapipostproc: use scoped variable for return valueVíctor Manuel Jáquez Leal1-7/+11
Instead of reusing a parameter variable for the return value of gst_vaapipostproc_transform_caps(), this patch uses the function scoped pointer. Thus, the code is cleaner. https://bugzilla.gnome.org/show_bug.cgi?id=785706
2017-09-28vaapipostproc: removed unused parameterVíctor Manuel Jáquez Leal1-2/+2
Removed caps parameter from gst_vaapipostproc_transform_caps_impl() helper function since the it is not used. https://bugzilla.gnome.org/show_bug.cgi?id=785706
generated by cgit v1.2.3 (git 2.39.1) at 2024-05-01 13:42:27 +0000