[ultrabrutal]

gamester, if the renderer is deprecated or/and obsolete, why not just remove it? the less options the better and also less support.

plugh, if I have one or two Xboxes with Focus chip if you need me to test anything!

elupus, regarding the colorspace conversions. how much control is there, from the source to the hardware displaying the video, in terms of real number calculations? precision/rounding problems can be fixed by using fractions, however that is ofcourse slower (needs a class or higher level functions for it?) but does not lose any precision/decimals up to the point that the value is passed to the gpu. maybe this is not even possible with the current source (never got around reading any of it ) or too hard to implement. I would understand this as a dev

http://en.wikipedia.org/wiki/Fraction_%28mathematics%29

[plugh]

'brutal - nothing can be done. The result of each conversion, by definition, is a set of octets. You can use all the precision you want doing the conversion, but you still need to store an 8 bit result. Problem is, with three seperate conversions on the first path, roundoff error accumulates and becomes visible.

Gamester - it may be obsolete, but it _is_ faster (good for my HD xvids) and {apparently} allows me to eliminate all three colorspace conversions from my reproduction chain, which gives a visibly better result (good for bt709 HD source thru to bt709 HD display).

[elupus]

plugh:
it probably does limit the number of conversions so yea, it is probably the path with the least amount of distortions due to colorspace conversion. it however is so limited in what can be done with it, which is why i consider it depreciated. ie no handling of interlaced content, no alpha blending and so on.

your path 1) why change colorspace in the encode? that is very wrong since we use BT709 as default.


we do one colorspace conversion (generally BT709 -> RGB), as that is our default and used for all content from mplayer, and most from dvdplayer. this is done with a lookup table and is very very precise. if you use component out, then yes there probably is a colorspace conversion done in the tv encoder, and we really don't know how good it is, so go get yourself a VGA out instead .


<correction>
I'm lying when i'm saying that BT709 is default after looking at the code .. dvdplayer uses BT709 as default for everything except mpeg2, where it uses whatever the stream specified, while mplayer apperently used BT601 for everything.. Heh... now to the big question, which one should one use? it's very obtrustive change to allow mplayer to output the colorspace (it would render old mplayer.dll unusable forexample).
</correction>

[plugh]

This topic is really starting to branch out, but since gamester17 brought up that wiki page...

Out of curiosity, how do you get 56 bits/pixel with overlay renderer?
yuy2 (4:2:2) data would be 32 bits per two pixels - two Y's, one U, one V.
(Hmmm. perhaps it is color keyed overlay, vs 'direct' overlay - I guess that could eat up some more memory...)

similar question about the 44 bits per pixel with hqps - RGB would be 24 bpp, or 32 with an an alpha channel...

"Inquiring minds want to know"

[plugh]

plugh:
<correction>
I'm lying when i'm saying that BT709 is default after looking at the code .. dvdplayer uses BT709 as default for everything except mpeg2, where it uses whatever the stream specified, while mplayer apperently used BT601 for everything.. Heh... now to the big question, which one should one use? it's very obtrustive change to allow mplayer to output the colorspace (it would render old mplayer.dll unusable forexample).
</correction>

Interesting... You may recall me asking a while back about the coeffs used in the pixel shader (answer was bt601 at the time) - that discussion led to the switchable stuff you are now doing in dvdplayer / mpeg2.

So dvdplayer uses bt709 coeffs in hqps when decoding mpeg4-asp? That's pretty much 'wrong' - convention (standard?) adopted by xvid etc is bt601 (and related topics from mpeg*1*). For example, if you feed xvid RGB, it uses bt601 to convert to YUV then downsamples to YV12 (I think using the UV-centered model - would need to check that).

However, dvdplayer + mpeg4-asp + bt709-hqps is interesting in that it adds a third path to the two I posted above, which would eliminate one colorspace conversion from the three. Perhaps an informative test, but as I said above, probably wrong for mpeg4-asp.

[jmarshall]

Overlay Renderer: There are 2 YV12 planes (12 bits/pixel) and 2 YUV2 planes (16bits/pixel), thus 56bits/pixel total.

RGB renderer: Only has 1 12bit/pixel YV12 plane, and one 32bit/pixel RGB plane, or at least that's what it had when the wiki article was written :p

Cheers,
Jonahtan