hverkuil: would it be interesting to add 411P support to vivid ?
and how does the vdownsampling array works ?
stormer: it will take a lot of effort to implement that, which is the reason it is not part of vivid.
hmm, ok, any insight why ?
The main issue is with the downsampled lines: for 4:2:2 each line is the average of two 'real' lines, for 4:1:1 it is the average of four lines.
the goal of the TPG is to precalculate everything so filling the buffer is always just a memcpy.
For 4:1:1 this is much harder (i.e. if the pattern is scrolling down/up by one line for each frame)
Of course, it is easy to do if you take shortcuts, but the whole point of the vivid driver is to be as close to real hardware as possible and it is good to see the chroma effects due to subsampling.
That said, a lot of hardware doesn't do proper averaging (certainly not for lines) and just skip lines instead.
That would be much easier to implement. I have thought about a setting that tells vivid how the hw does subsampling.
why do you need that format? there isn't a lot of hardware that produces 4:1:1.
only for testing porpose
We have all format from dmabuf to texture path in place now, but this is the only one we could not test
GL is a bit annoying, but we workaround the limitation by using DRM_R8, DRM_GR8 and DRM_BGRA when importing
so for the case GL does not handle color conversion, we can support pretty much everything with those 3 formats (which are supported by mostly all drivers)
and shaders ;-P
that is in GStreamer, and same happened in Weston (again using vivid for testing) few weeks ago
don't know if you've seen it, but qv4l2 has shaders as well and those include colorspace conversion support.
Anyway, I don't have time to add 411 support to vivid. I'm not sure how much work it would be to implement poor-man
's support for it.
yes, you told me
but the Gst ones supports GLES and various configuration (aka RG texture vs LA texture) there is templating for various sample (EXTERNAL_OES, RECTANGLE)
We also have plan to add proper upsample (will be configurable, cause that might be too much for low end GPUs)
but yeah, that is a bit out of scope I guess ;-P
hverkuil: thanks, I just wanted to know if there was a reason, so I know how much amount of works it would be (specially for an extremely rare format)
for now, we just code review that properly, and if it wasn't correct, we'll fix when we have a driver producing it, it's not a big deal