xine-lib/src/video_out, branch 1.2.5 xine-lib git mirror VDPAU: silence warnings. 2014-04-05T15:03:35+00:00 Torsten Jager t.jager@gmx.de 2014-04-05T15:03:35+00:00 665833b1df2c7d6f99da1169c62fe17d3db112d4 






Silence compiler warnings on register_enum () arg #4.
2014-03-10T15:36:55+00:00

Torsten Jager
t.jager@gmx.de

2014-03-10T15:36:55+00:00

9dc01446b018803415e0fe02b0f060b037e0738a

Making them all "const char * const *" did work too
(even with Kaffeine build/run), but that would be
an API change.





Making them all "const char * const *" did work too
(even with Kaffeine build/run), but that would be
an API change.







YCgCo: enable VDPAU video out.
2013-12-10T14:25:30+00:00

Torsten Jager
t.jager@gmx.de

2013-12-10T14:25:30+00:00

18c4a9bbd184a660b862ba233cf07aaf3a7db068

Possibly only theory. Most real life YCgCo files are 4:4:4 what VDPAU dislikes.





Possibly only theory. Most real life YCgCo files are 4:4:4 what VDPAU dislikes.







YCgCo: enable opengl2 video out.
2013-12-10T14:25:25+00:00

Torsten Jager
t.jager@gmx.de

2013-12-10T14:25:25+00:00

70c2d00f21933efd677756f470352991b279b407












YCgCo: general preparation.
2013-12-10T14:25:15+00:00

Torsten Jager
t.jager@gmx.de

2013-12-10T14:25:15+00:00

9a74d75ff7a89f761f7926aecea8cab502773e0c

I stumbled upon something - the green orange transform :-)

No, it is not lossless as some publications say. Instead, like traditional
YCbCr it maps the RGB color cube to a pyramid with a central symmetric
hexagonal base. Roughly 80% of color depth gets lost this way. The green
resolution is again worse than ITU-R 709.
It will probably not replace traditional YCbCr. It is incompatible with
existing video equipment, and it lacks an mpeg range mode needed for live editing.

However, if you can live without video equalizer, it makes an interesting
alternative for slow devices like smartphones.

Anyway, just if someone likes...





I stumbled upon something - the green orange transform :-)

No, it is not lossless as some publications say. Instead, like traditional
YCbCr it maps the RGB color cube to a pyramid with a central symmetric
hexagonal base. Roughly 80% of color depth gets lost this way. The green
resolution is again worse than ITU-R 709.
It will probably not replace traditional YCbCr. It is incompatible with
existing video equipment, and it lacks an mpeg range mode needed for live editing.

However, if you can live without video equalizer, it makes an interesting
alternative for slow devices like smartphones.

Anyway, just if someone likes...







Clean up vaapi µs delay code.
2013-10-01T20:25:36+00:00

Darren Salt
devspam@moreofthesa.me.uk

2013-10-01T20:25:36+00:00

b158fdb88389b33de8e1447f77d29ff7a8975463












Hide warning: unused variable 'frame'
2013-09-30T06:30:43+00:00

Petri Hintukainen
phintuka@users.sourceforge.net

2013-09-30T06:30:43+00:00

d2391e6610c74661b5c2a61f97d1254272e02f05












Added const
2013-09-30T06:28:42+00:00

Petri Hintukainen
phintuka@users.sourceforge.net

2013-09-30T06:28:42+00:00

c5b1123ec560ed15f2aebafc0ef76a5448d29e17












color_matrix.c: default to "Signal+Size".
2013-09-27T13:52:30+00:00

Torsten Jager
t.jager@gmx.de

2013-09-27T13:52:30+00:00

1484cd98330543db0f70955cb8877aeab7f8f06f

This is preferred on any half-way sRGB compliant monitors.





This is preferred on any half-way sRGB compliant monitors.







yuv2rgb_mmx: fix swapped modes.
2013-09-27T13:52:29+00:00

Torsten Jager
t.jager@gmx.de

2013-09-27T13:52:29+00:00

86b02c35c856d53ac870203447387b1c5074dbb2

This bug probably never hit anyway. Nobody uses 24bpp X displays,
as they are way slower than 32 bit ones, or even unsupported by hw.





This bug probably never hit anyway. Nobody uses 24bpp X displays,
as they are way slower than 32 bit ones, or even unsupported by hw.