Age | Commit message (Collapse) | Author |
|
|
|
|
|
yuv2rgb_mmx.c scales YUV and rounds them down to 8 bits
individually before the addition. That causes red and
blue to be off by up to 2, green even off by 3.
This little patch does the stuff using 10 bits per
component, plus correct rounding.
There seems to be no noticable impact on performance,
but color gradients come out much smoother now.
|
|
--HG--
rename : src/xine-utils/xineutils.h => include/xine/xineutils.h
|
|
|
|
|
|
|
|
--HG--
branch : 1.2.1-branch
|
|
driver.
|
|
|
|
conversion.
Proper (HW-accelerated) implementation would use OpenGL texture to blend the OSD directly to RGB video texture.
|
|
|
|
--HG--
rename : src/libspudvb/xine_spudvb_decoder.c => src/spu_dec/spudvb_decoder.c
|
|
|
|
|
|
|
|
|
|
It's only a cosmetic change.
--HG--
extra : rebase_source : a759588226bbc43bca331c746d14ec2e2d84c9a4
|
|
The current osd and grab logic needs a lot of output surface objects
for rendering.
The current implementation create and destroy these objects on demand.
This patch introduce a new buffer where output surfaces are hold for
reuse preventing most of the create and destroy calls.
The size of the new buffer could be configured with parameter
"video.output.vdpau_output_surface_buffer_size".
Default value is 10 surfaces. Possible range is 2...25
To further minimize surface creation and destroy the first n created surfaces
get a minimum size according to the actual display and frame size where n
is the size of the surface buffer.
These first objects will be allocated as rather big surfaces so that they
fit for most of the surface requests.
This should be considered when choosing higher buffer values.
This patch also improves dirty rect handling within osd handling.
Now dirty rect information is used even if more than one osd
object is displayed at the same time.
--HG--
extra : rebase_source : b40e365ab1f81ebdd72b2e1713cf3526d6dd7493
|
|
actual display dimension
To minimize output surface reallocation while resizing the video window
these output surfaces are now allocated with the actual display
dimension.
--HG--
extra : rebase_source : 41e16c3f5bc0c66e1c3e63221f0cc38ffe9d08be
|
|
Because displayed output surfaces are only increased in size when gui
window dimension changes the surface size could be greater than the
actual gui window size.
--HG--
extra : rebase_source : 4f7be362af8ccfe5851900bda095d0949d1c6e15
|
|
for grab feature of vdpau output driver
Fixed usage of wrong variables to determine current gui output window size for grab feature of vdpau output driver
--HG--
extra : rebase_source : f605be7e19142756f3ab388e558d8e65e3ddba5d
|
|
|
|
|
|
|
|
The new implementation has the following advantages towards the existing one:
There is now a unique processing of RLE coded images and ARGB based overlay images.
For both formats scaled and unscaled images and a video window are supported.
Both formats are rendered now in given order into the same output surface not using
a dedicated output surface for scaled, unscaled and ARGB images any more.
Processing of YCBCR overlay images now uses corresponding vdpau upload functions
eliminating the existing (possible slower) conversation to RGB images.
Optimized processing of first overlay from stack avoiding unnecessary
surface initialization and rendering operations.
Currently the new implementation does only take the dirty rect
information of a ARGB overlay into account for optimization
if this is the only one object that should be displayed.
|
|
--HG--
rename : src/libdts/xine_dts_decoder.c => src/audio_dec/xine_dts_decoder.c
rename : src/libxineadec/xine_lpcm_decoder.c => src/audio_dec/xine_lpcm_decoder.c
rename : src/combined/decoder_flac.c => src/combined/flac_decoder.c
rename : src/combined/demux_flac.c => src/combined/flac_demuxer.c
rename : src/libsputext/xine_sputext_decoder.c => src/spu_dec/sputext_decoder.c
|
|
--HG--
branch : point-release
|
|
--HG--
branch : point-release
|
|
--HG--
branch : point-release
|
|
--HG--
branch : point-release
|
|
--HG--
branch : point-release
|
|
--HG--
branch : point-release
|
|
|
|
|
|
|
|
|
|
--HG--
rename : src/xine-utils/attributes.h => include/xine/attributes.h
rename : src/xine-engine/xine_internal.h => include/xine/xine_internal.h
rename : src/xine-utils/xineutils.h => include/xine/xineutils.h
|
|
xine_socket_cloexec() function.
|
|
This patch creates two utility functions:
int open_cloexec(pathname, flags)
int create_cloexec(pathname, flags, mode)
These return a file descriptor with the CLOEXEC flag set, to ensure
that the descriptor is not inherited across a fork/exec operation.
The sockets returned by:
_x_io_tcp_connect_ipv4()
_x_io_tcp_connect()
now also have their CLOEXEC flag set.
|
|
--HG--
rename : src/libxineadec/xine_lpcm_decoder.c => src/audio_dec/xine_lpcm_decoder.c
|
|
|
|
|
|
In opposite to the 'xine_get_current_frame' based snapshot function this grabbing
feature allow continuous grabbing of last or next displayed video frame.
Grabbed video frames are returned in simple three byte RGB format.
Depending on the capabilities of the used video output driver video image data is
taken as close as possible at the end of the video processing chain. Thus a returned
video image could contain the blended OSD data, is deinterlaced, cropped and scaled
and video properties like hue, sat could be applied.
With this patch such a decent grabbing feature is implemented for vdpau video out driver.
If a video output driver does not have a decent grabbing implementation then there
is a generic fallback feature that grabs the video frame as they are taken from the video
display queue (like the xine_get_current_frame' function).
In this case color correct conversation to a RGB image incorporating source cropping and
scaling to the requested grab size is also supported.
A more detailed description can be found in file "xine.h".
|
|
|
|
|
|
|
|
|
|
actual video format (SD or HDTV) for vdpau output driver.
With the new configuration parameter 'video.output.vdpau_sd_only_properties" enabling of this video properties can be restricted
to SD video only. Videos with a frame width < 800 are considered as SD videos.
Often noise and sharpness corrections are only necessary for SD videos and are counterproductive to HDTV videos. With the restriction
enabled the user do not have to correct these settings each time the format changes.
--HG--
extra : rebase_source : 874a98cd3e9fc64084c0b5c2e9a7eec34414db2a
|
|
According to the nvidia vdpau documentation for the used formats in this function
there are no needs for special alignment for the fetched bitmap images . Thus we
can fetch the image data directly to the supplied image buffer avoiding heap memory allocation and additional copying of image data.
--HG--
extra : rebase_source : 0956eab8cd2f23ecc1452aa5ecc3db27fca635b9
|