<div dir="ltr">Hi,<div class="gmail_extra"><br><div class="gmail_quote">On 12 December 2014 at 18:00, Ville Syrjälä <span dir="ltr"><<a href="mailto:ville.syrjala@linux.intel.com" target="_blank">ville.syrjala@linux.intel.com</a>></span> wrote:<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">On Fri, Dec 12, 2014 at 05:11:50PM +0000, Daniel Stone wrote:<br>> If you're doing it through GL, you've already lost. Either you're doing<br>
> some magic behind the user's back to bind multi-planar dmabuf-EGLImages to<br>
> TEXTURE_2D with RGB sampling, or you're binding to TEXTURE_EXTERNAL_OES,<br>
> which forces you to use linear/nearest filtering. Even if you do use<br>
> TEXTURE_2D binding, the EGLImage import spec does exactly the same as<br>
> what's suggested here, and treats them as hints, which the implementation<br>
> can use or ignore. So far I don't know of any implementation which doesn't<br>
> ignore them.<br>
<br>
</div></div>Well anyone who is serious about quality ought to handle that stuff.<br>
Or at least make sure both GL/whatever and planes ignore the hints in<br>
the same way. So if you GL implementation is lax then you anyway need<br>
to have some driver/hardware specific knowledge to know which way to go<br>
when using the plane path to get matching output.<br><span class=""></span></blockquote><div><br></div><div>Anyone who's serious about quality and is also using GL for video, is not serious about quality. Or accurate timing.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">> > But for some simpler cases like Xv it would seem perfectly OK to use the<br>
> > less strict rules. Well, unless someone implements Xv in a way that can<br>
> > also transparently switch between display planes and GL/software rendering.<br>><br>
> Well sure, if you absolutely want to ensure it works, you're going to need<br>
> some kind of query. Maybe, if the range/chroma-siting ones were part of a<br>
> bitmask, you could steal the top bit to mark that the hints are actually<br>
> requirements, and to fail if you can't respect the hints.<br>
<br>
</span>I was more thinking of some global "I want exactly what I said" kind<br>
of knob. Maybe as a client cap type of thingy.<br></blockquote><div><br></div><div>I like the idea of keeping it local to the chroma-siting/range hints, because it makes it far more clear exactly what it affects.</div><div><br></div><div>Cheers,</div><div>Daniel </div></div></div></div>