summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
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-03Missing comment.Darren Salt
2012-01-03Changelog update.Darren Salt
2012-01-03Ignore xz-compressed tarballs.Darren Salt
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-03Disable Sun / OSS audio backends on OpenBSDBrad Smith
2012-01-03Build-depend on libbluray-dev.Darren Salt
--HG-- extra : rebase_source : a9a2a92c17a5389044aaa206f16961c832345616
2012-01-03Update changelog.Darren Salt
2012-01-02Added tag 1.2.0 for changeset 01846b148cbaDarren Salt
2012-01-02Update changelog.Darren Salt
2012-01-02FTBFS on hurd-i386: not compiled pluginsPino Toscano
The problem is that there are some audio and video plugins that are not enabled (while they could be).
2012-01-01Oops. Omitted headers.1.2.0Darren Salt
2012-01-01xine-lib 1.2.0, and about time too!Darren Salt
2012-01-01Merge from 1.1.Darren Salt
2012-01-01Update version no.Darren Salt
2012-01-01Merge.Darren Salt
2012-01-01Added tag 1.1.20.1 for changeset dde68fe11b97Darren Salt
--HG-- branch : point-release
2012-01-011.1.20.1.1.1.20.1Darren Salt
--HG-- branch : point-release
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
generated by cgit v1.2.3 (git 2.25.1) at 2025-04-25 01:57:32 +0000