- 07 Jul, 2013 40 commits
-
-
Jean-Baptiste Kempf authored
Close #8511
-
Rémi Denis-Courmont authored
-
Rémi Denis-Courmont authored
-
Rémi Denis-Courmont authored
-
Rémi Denis-Courmont authored
-
Rémi Denis-Courmont authored
This supports brightness, contrast, saturation and hue.
-
Rémi Denis-Courmont authored
(same as OpenGL shaders)
-
Rémi Denis-Courmont authored
-
Rémi Denis-Courmont authored
-
Rémi Denis-Courmont authored
-
Rémi Denis-Courmont authored
-
Rémi Denis-Courmont authored
This will be used for deinterlacing.
-
Rémi Denis-Courmont authored
This is for advanced filtering on the GPU. So far, only progressive scan is implemented.
-
Rémi Denis-Courmont authored
-
Rémi Denis-Courmont authored
-
Rémi Denis-Courmont authored
-
Rémi Denis-Courmont authored
-
Rémi Denis-Courmont authored
-
Rémi Denis-Courmont authored
-
Rémi Denis-Courmont authored
-
Rémi Denis-Courmont authored
-
Rémi Denis-Courmont authored
This is a corner case. The picture needs to be copied back to the main memory from the decoding GPU, and from there onto the rendering GPU.
-
Rémi Denis-Courmont authored
-
Rémi Denis-Courmont authored
...instead of copying YCbCr planes back to the main memory.
-
Rémi Denis-Courmont authored
This avoids loosing the picture context if there is one. If the original picture has no context, it makes no difference whether the original or the copy is kept since blending failed anyway.
-
Rémi Denis-Courmont authored
-
Rémi Denis-Courmont authored
If the picture copy fails or blending is unavailable(1), discard only the subpicture and keep the original picture. (1) In practice, this never happens as the blender object is kept all the time even without a "blend" module.
-
Rémi Denis-Courmont authored
-
Rémi Denis-Courmont authored
This provides colour space conversion, cropping and scaling of existing video surfaces (as would come from a hardware decoder).
-
Rémi Denis-Courmont authored
This enables using the pass-through hardware-accelerated decoder (from a later commit) with transcode in stream output or with a video output that does not support VDPAU surfaces.
-
Rémi Denis-Courmont authored
-
Rémi Denis-Courmont authored
-
Rémi Denis-Courmont authored
-
Rémi Denis-Courmont authored
-
Rémi Denis-Courmont authored
-
Rémi Denis-Courmont authored
This uses a VDPAU presentation queue to render VDPAU output surfaces (i.e. screen-scaled RGBA pictures) on an X11 window. It is assumed that a video filter will eventually convert pictures in the source video format to VDPAU output surfaces of adequate dimensions. The common VLC XCB event handling is used for X11 matters.
-
Rémi Denis-Courmont authored
This enables importing I420, YV12, NV12, YUYV and UYVY pictures into the GPU's VDPAU back-end. Conversion to RGBA color space and scaling to the target resolution are performed on the fly by the GPU.
-
Rémi Denis-Courmont authored
-
Rémi Denis-Courmont authored
-
Rémi Denis-Courmont authored
This define several codec identifiers for each of the VDPAU video surface types (YUV 4:2:0 and 4:2:2) and one for VDPAU output surfaces regardless of their internal type. (At this point, it does not seem that the output surface type affects VLC processes). VDPAU bitmap surfaces are not included as they do not seem useful. VDPAU pictures have zero pixel planes since they only carry picture infos and handles to GPU resources, no actual pixel data. Nevertheless, inclusion in chroma description is required for picture setup to work.
-