Age | Commit message (Collapse) | Author |
|
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
|
|
For smooth operation of frame displaying on platforms with less processing power
(and in preparation for a new frame grabbing extension) the vdpau display queue length,
which is actually fixed at size 2, could now be increased by configuration. There is a new
configuration parameter 'video.output.vdpau_display_queue_length' with default value of 2.
Maximum queue length is 8. Increasing this parameter by 1 should almost be enough.
--HG--
extra : rebase_source : b8d045053d744b6693c50e4a8d81199ba7f315e2
|
|
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 surfaces not using
a dedicated output surface for ARGB images any more.
Processing of YCBCR overlay images now uses corresponding vdpau bitmap surfaces
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 not take the dirty rect information of a ARGB overlay into account for optimization (but is there actually a existing player implementation that provides this data?).
--HG--
extra : rebase_source : 037f67efdabb0b197e4d1ea2ce14d15f3eb3d8fe
|
|
recalculation of displayed window.
This issue comes up when a post plugin only changes the cropping parameters of a frame without changing width, height or ratio of the frame.
--HG--
extra : rebase_source : 18832d5ec6acdb8ebe7a0d1d10ceaefb2aef663f
|
|
recalculation of displayed window.
This issue comes up when a post plugin only changes the cropping parameters of a frame without changing width, height or ratio of the frame.
|
|
Intercepted frames should never pass function vdpau_update_frame_format.
--HG--
extra : rebase_source : d1d05b67865eb6cc79225f96159184852f239262
|
|
--HG--
rename : src/libxineadec/gsm610/Makefile.am => contrib/gsm610/Makefile.am
rename : src/libxineadec/nosefart/diff_to_nosefart_cvs.patch => contrib/nosefart/diff_to_nosefart_cvs.patch
rename : src/libxineadec/nosefart/nes6502.c => contrib/nosefart/nes6502.c
rename : src/libxineadec/nosefart/nes6502.h => contrib/nosefart/nes6502.h
rename : src/libxineadec/nosefart/nes_apu.c => contrib/nosefart/nes_apu.c
rename : src/libxineadec/nosefart/nes_apu.h => contrib/nosefart/nes_apu.h
rename : src/libxineadec/nosefart/nsf.c => contrib/nosefart/nsf.c
rename : src/libxineadec/nosefart/nsf.h => contrib/nosefart/nsf.h
rename : src/libxineadec/nosefart/types.h => contrib/nosefart/types.h
rename : src/libxineadec/nosefart/version.h => contrib/nosefart/version.h
rename : doc/faq/faq.sgml => doc/faq/faq.docbook
rename : src/libsputext/demux_sputext.c => src/spu_dec/sputext_demuxer.c
rename : src/libxinevdec/image.c => src/video_dec/image.c
|
|
VDPAU applies different constraints to surface size and memory consumption
than xine. Hence, when decoding bad streams (due to receptions issues for
examples) with broken image sizes, it is likely that segfaults happen due
to different memory size assumptions.
So by adjusting image size to meet xine and VDPAU constraints, segfaults
can be avoided.
--HG--
extra : rebase_source : c493fac162bb34ab357783821bc72be85682c1eb
|
|
When using pitch 0 it is sufficient to allocate just a single row.
--HG--
extra : rebase_source : 47b554da704a5c6fc073fee587a968145d3fa230
|
|
--HG--
extra : rebase_source : 686c74f934f4f780d08909c24238114cc9f64f4c
|
|
As both types have the same signature, there was error during build
nor at runtime.
--HG--
extra : rebase_source : 125cbc9417554303cc6a3c04dfedfedcdcc4710b
|
|
guarded_vdp_output_surface_destroy() calls XLockDisplay() and
XUnlockDisplay() always and not depending on define LOCKDISPLAY.
This may cause a deadlock among threads using VDPAU API due to
different resource allocation orders when guarding is not used
(i. e. #undef LOCKDISPLAY is enabled).
--HG--
extra : rebase_source : abafc9604d8cfb6efe07f665361c4e01e60adc37
|
|
|
|
Useful for example when composite managers occupy the HW.
|
|
|
|
|
|
Source: informational messages generated by lintian.
|
|
Recently I've posted a patch for xine-ui which uses a timed lock to avoid a
deadlock when the output callback happens while changing the drawable. It is
possible to avoid this deadlock at all by moving the drawable lock (and the
reinit call which it is not necessary for the callback) after the callback.
As a result the mentioned patch for xine-ui may be reverted.
|
|
It is known to everyone that locking serveral resources requires a consistent
order on all places where these resources are required. Otherwise a deadlock
will happen.
|
|
At least two threads operate on the drawable -- the video output thread and
the xine-ui gui thread. When xine-ui changes the drawable while the output
thread is displaying a frame it is likely that the video output thread
triggers the X11 error bad drawable. Usually XLockDisplay() is used to
synchronize these threads but it causes too much impact and should only be
used to implement short atomic operations. In this case scheduling two
fields of a frame for displaying may take at least one field duration which
is quite a long time. Therefore a separate mutex is used for synchronizing
those threads.
|
|
|
|
|
|
|
|
--HG--
extra : rebase_source : 74bbd9ee7e0732ce16838356a666a07c9a44acd4
|
|
|
|
--HG--
rename : include/xine.h.in => include/xine.h
rename : src/xine-engine/video_out.h => include/xine/video_out.h
|