summaryrefslogtreecommitdiff
path: root/src
AgeCommit message (Collapse)Author
2012-01-12Hide "warning: cast from pointer to integer of different size"Petri Hintukainen
2012-01-12Fixed pointer typePetri Hintukainen
2012-01-12Fixed pointer castPetri Hintukainen
2012-01-12Fixed leakPetri Hintukainen
2012-01-12Put lock display calls into macrosAndreas Auras
It's only a cosmetic change. --HG-- extra : rebase_source : a759588226bbc43bca331c746d14ec2e2d84c9a4
2012-01-12Introduce buffering for output surfaces for vdpau output driverAndreas Auras
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
2012-01-12Initially allocate vdpau output surface objects for display queue with ↵Andreas Auras
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
2012-01-12Set clipping region of displayed output surfaces to rendered regionAndreas Auras
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
2012-01-12Fixed usage of wrong variables to determine current gui output window size ↵Andreas Auras
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
2012-01-12Removed wrong setting of fixed extent size of osd objects in dvb spu decoderAndreas Auras
Currently the spu decoder sets the extend size of each generated osd object to a fixed size of 1920x1080. Output drivers which are extend capable (like vdpau) will do bad scaling of these objects if video frame format is different. This patch fixes the issue by removing the explicit extend setting. The video driver will now use the actual video frame size by default. --HG-- extra : rebase_source : 5800f84391bba725f5cb1ef28025412a2b6b6a35
2012-01-11Fixed pointer castsPetri Hintukainen
* * * Fixed pointer cast
2012-01-11Fixed #includePetri Hintukainen
2012-01-11Fixed using uninitialized value (return random size)Petri Hintukainen
2012-01-11Fixed id3v2 tag check (broken in r9654)Petri Hintukainen
2012-01-10Merge.Darren Salt
2012-01-10And the other two similar printf()s.Darren Salt
2012-01-10Pointer type fixesPetri Hintukainen
2012-01-10Added missing constPetri Hintukainen
2012-01-10Removed unused variablePetri Hintukainen
2012-01-10Fixed printf formatPetri Hintukainen
2012-01-10Define LOG_MODULE before including xine headersPetri Hintukainen
2012-01-10Fixed includePetri Hintukainen
2012-01-10Removed unused variablesPetri Hintukainen
2012-01-10Merge from 1.1Petri Hintukainen
--HG-- rename : src/libsputext/xine_sputext_decoder.c => src/spu_dec/sputext_decoder.c
2012-01-10Added constPetri Hintukainen
2012-01-10Fixed printf argumentPetri Hintukainen
2012-01-10Removed unused variable from enum definitionPetri Hintukainen
2012-01-10Include xine_private.h to get xine_probe_fast_memcpy() definitionPetri Hintukainen
2012-01-10Fixed include orderPetri Hintukainen
2012-01-03Fix VDR input plugin build.Brad Smith
2012-01-03Fix up sndio plugin #includes (FTBFS).Darren Salt
2012-01-03Complete rewrite of vdpau output driver osd handling.Andreas Auras
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.
2012-01-01Oops. Omitted headers.1.2.0Darren Salt
2011-12-31Merge from 1.1.Darren Salt
2011-12-31Kill a few trivial compiler warnings.Darren Salt
2011-12-31A new vdpau h264 decoder that has proven to work better than the previous one.Christophe Thommeret
2011-12-31Merge.Darren Salt
2011-12-27Fixes nasty mpeg2 on ts A/V lag when using ff."Torsten Jager"
--HG-- branch : point-release extra : rebase_source : 6e059c732a63d40b65b09f4ef725ec5ca45c4c1c
2011-12-22Use proper chroma upsampling for yv12 to yuy2 conversionRoland Scheidegger
The old code did some "averaging" which, while cheap, lead to serious chroma shift because the weighting factors turned out to be pretty random (arguably no averaging likely would have been given more correct results). It also in fact lead to chroma ghosts. To see why this was wrong read the following and then do the math. http://www.hometheaterhifi.com/the-dvd-benchmark/179-the-chroma-upsampling-error-and-the-420-interlaced-chroma-problem.html http://avisynth.org/mediawiki/Sampling As an example, let's look what happens at line 4 for interlaced content (where the code would have averaged chroma from chroma line 2 and 4): Chroma line 2 contains chroma values for line 2 (25%) and 4 (75%) while chroma line 4 contains chroma values for line 6 (25%) and 8 (75%) of the original (prior to subsampling) frame. Average these together and you get something quite wrong. Most importantly the center of these weights will be at 5.5 instead of 4 (hence chroma shift). For odd lines it is different (better but still wrong). So, fix this by using the correct weights for reconstruction of the chroma values (which is averaging for the progressive case for all pixels since the samples are defined to be between the lines, and use different weighting factors for odd/even/"upper"/"lower" lines). This runs more than twice the instructions (for the mmx case), but I measured only a performance impact of roughly 5% (on a Athlon64 X2) - seriously bound by memory access (by comparison the sort-of-pointless post-deinterlace chroma filter is nearly twice as slow hence if you don't need it because the values are correct this will be a lot faster). Note: this is only correct for codecs which use the same chroma positions as mpeg2 (dv is definitely different, mpeg1 is also different but only for horizontal positioning, which doesn't matter here). "yv12" as such seems underspecified wrt chroma positioning. On another note, while this algorithm may be correct, it is inherently suboptimal doing this pre-deinterlace (and a post-deinterlace chroma filter is not going to help much neither except it can blur the mess). This NEEDS to be part of deinterlace (which btw would also be quite a bit faster when handling planar directly due to saving one pass of going through all memory). The reason is while line 4 will now use the correct weighting factors, the fact remains it will use chroma values originating from lines 2, 4, 6 and 8 of the original image. However, if the deinterlacer decides to weave because there is no motion, it CAN and most likely wants to use chroma values from the other field (hence values originating from line 2, 3, 4, 5 in this case when using a very simple filter, with appropriate weighting). --HG-- branch : point-release extra : rebase_source : 808bb5785ca398970324bea6b391a9e24c576d2f
2011-12-21Merge from 1.1.Darren Salt
--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
2011-12-16MergePetri Hintukainen
2011-12-16flac decoder: int -> size_tPetri Hintukainen
--HG-- branch : point-release
2011-12-16Fixed flac_read_callback() signature for flac 1.1.3+ (when sizeof(size_t) != ↵Petri Hintukainen
sizeof(unsigned)) --HG-- branch : point-release
2011-12-16Hide aliasing problems in xcb pluginsPetri Hintukainen
--HG-- branch : point-release
2011-12-16Silenced warningPetri Hintukainen
--HG-- branch : point-release
2011-12-16MergePetri Hintukainen
2011-12-16Removed write-only variablesPetri Hintukainen
--HG-- branch : point-release
2011-12-16Fixed osd_hide() return valuePetri Hintukainen
--HG-- branch : point-release
2011-12-16Fixed using uninitialized dataPetri Hintukainen
--HG-- branch : point-release
2011-12-16define _XOPEN_SOURCE before including any system headersPetri Hintukainen
--HG-- branch : point-release
generated by cgit v1.2.3 (git 2.25.1) at 2025-07-21 12:36:56 +0000