2014-03-24, 14:56
Once scaled from full to limited, it's non reversible.
(2014-03-06, 20:21)zag Wrote: For me r17780 is the last working release using livetv and hardware acceleration.
Can anyone else confirm its broken in recent releases? It seems fine on videos, just not Live TV
(2014-03-24, 15:59)axbmcuser Wrote:(2014-03-06, 20:21)zag Wrote: For me r17780 is the last working release using livetv and hardware acceleration.
Can anyone else confirm its broken in recent releases? It seems fine on videos, just not Live TV
I also get blocking/artefacts with all the latest nightlies with Live-TV on my D54250WYK(H). As you mentioned, videos are fine.
I tried an old build around the one you mentioned (i used r17733) and with that one hardware accerlation + Live TV works fine.
+1 from me regarding what you experience.
(2014-03-24, 14:56)fritsch Wrote: Once scaled from full to limited, it's non reversible.
(2014-03-20, 06:57)trsqr Wrote: August T210 should be supported in kernel 3.14. I've ordered one from China, but it takes weeks to arrive... I don't know any other USB T2 tuners that do work with Linux.
I've got 2 290e tuners, and might be interested in selling one if the August one works ok...
(2014-03-24, 17:30)fritsch Wrote: Check:
Input: Full Range 0 .. 255
Scale to Limited: sl(255) = ? sl(235) = ?
scale back to full: sf(sl(255)) = ? sf(sl(235) = ?
Assumption linear weighting. Please solve the equations.
(2014-03-24, 13:05)kouze Wrote:With current OE you can use VAAPI decoding, SW filtering and 16-235 xbmc setting. You won't even need my passthrough patch with a Panasonic - it assumes limited range. You just need to use xrandr to set full range output (to avoid GPU scaling your limited range signal again).(2013-12-05, 02:17)lmyllari Wrote: The banding comes from expanding luma from 16-235 to 0-255. This is done for typical PC monitors, which expect a full range signal. New Intel linux drivers by default give TVs a limited range signal, taking the expanded 0-255 and scaling it to 16-235. This does not eliminate the banding that was created by the original expansion, and original information below 16 and above 235 was already lost in that same step. (Why do they do it? It's the right thing according to the standards, and some TVs don't like full range -> crushed blacks.)Hi guys,
If the player software (xbmc in this case) decodes to 16-235 (meaning "don't change luminance, keep black at 16 and white at 235"), the video card outputs full range 0-255 (meaning "don't scale the levels, just output what you're given"), and display is set to limited range input (meaning "16 is black, 235 white"), we eliminate the banding in greyscale ramp (because the range is not scaled at any point) and keep blacker-than-black (luma values under 16) and white-than-white (luma values above 235).
If your plasma defaults to limited range RGB (and doesn't listen to the infoframes in the HDMI stream) or you can set limited range manually, you don't need anything special. Just set your player software to 16-235 (which you can now do with Gotham and software decoding) and make sure the video card doesn't change the signal (the xrandr broadcast range "Full" setting mentioned a lot in this thread). In my case, the monitor obeys the infoframes (and there are other devices connected to the same input preventing a manual setting), so I need a patch to switch it to limited range without altering the video signal.
I'm actually facing this issue with my NUC Haswell I3 with the latest openelec gotham beta 2 with my Panasonic 50VT30 Plasma TV.
Using only software rendering is not really an option as I saw some slow rendering issue with 1080p mkv files.
I'm thinking using Gotham XBMC under Windows 8.1. Could it be an option to get good RGB signal on my TV?
Thanks !
(2014-03-24, 18:19)noggin Wrote: There was a statement made that this double scaling introduced banding on the output as well as clipping <16 and >235 content. Whilst I agree about the <16 and >235 content - isn't the Limited-Full-Limited processing potentially transparent?I think that would be ok if you were just scaling luminance back and forth, but you are also doing YCbCr -> RGB in the first step.
(2014-03-24, 20:12)lmyllari Wrote: I think that would be ok if you were just scaling luminance back and forth, but you are also doing YCbCr -> RGB in the first step.That's a very good point. YCrCb/RGB round-tripping in 8-bit truncated space isn't a good idea is it...
(2014-03-24, 20:12)lmyllari Wrote: With current OE you can use VAAPI decoding, SW filtering and 16-235 xbmc setting. You won't even need my passthrough patch with a Panasonic - it assumes limited range. You just need to use xrandr to set full range output (to avoid GPU scaling your limited range signal again).Brilliant ! Thank you so much !
The SW filtering downloads decoded frames and puts them through the same path as software decoded frames -> the 16-235 setting in xbmc works fine and you get a nice untouched signal.
No idea about Windows, sorry. Usually I don't associate Microsoft with "good RGB signal". (<- unfair stab at the whole xbox360 fiasco)
(2014-03-24, 20:12)lmyllari Wrote: With current OE you can use VAAPI decoding, SW filtering and 16-235 xbmc setting. You won't even need my passthrough patch with a Panasonic - it assumes limited range. You just need to use xrandr to set full range output (to avoid GPU scaling your limited range signal again).
The SW filtering downloads decoded frames and puts them through the same path as software decoded frames -> the 16-235 setting in xbmc works fine and you get a nice untouched signal.
No idea about Windows, sorry. Usually I don't associate Microsoft with "good RGB signal". (<- unfair stab at the whole xbox360 fiasco)
(2014-03-26, 12:30)deaerator Wrote:SSH to openelec box and type:(2014-03-24, 20:12)lmyllari Wrote: With current OE you can use VAAPI decoding, SW filtering and 16-235 xbmc setting. You won't even need my passthrough patch with a Panasonic - it assumes limited range. You just need to use xrandr to set full range output (to avoid GPU scaling your limited range signal again).
The SW filtering downloads decoded frames and puts them through the same path as software decoded frames -> the 16-235 setting in xbmc works fine and you get a nice untouched signal.
No idea about Windows, sorry. Usually I don't associate Microsoft with "good RGB signal". (<- unfair stab at the whole xbox360 fiasco)
Can you explain in detail how to set this up or is there a sticky somewhere.