javier___: so on Exynos 5, there is no overlay plain ? instead you can do YUV straight to universal planes ?
ndufresne: hi, yes there are overlay planes but not associated with the HDMI CRTC (are associated with the built-in display for the Peaci Pi Chromebook though)
ndufresne: I'm not doing straithg YUV output to the primary plane, but I'm still using videoconvert for YUV -> RGB color space conversion
ndufresne: I've been looking at the general scaler DRM and v4l2 drivers but still couldn't make it work
ndufresne: but in any case I believe that both new properties makes sense, although I'm very far from being a gfx expert and not familiar with gst
ndufresne: have to leave for a while to do some errands, bbl
javier___: ok, see you later, I'm all fine with the properties btw
javier___: kmssink is mostly for early boot display and testing
ndufresne: great, thanks a lot for your feedback
ndufresne: BTW, I'm having some issues with gst v4l2{src,sink} elements and vivid
ndufresne: just trying to do $ gst-launch-1.0 v4l2src device=/dev/video1 ! v4l2sink device=/dev/video2 but gst fails to negotiate the caps
AFAICT it should work when passing input_types=0x9 as module parameter to vivid
ndufresne: looking at the logs with GST_DEBUG=*CAPS*:5 I see that the only difference is in the colorimetry
colorimetry=(string)2:4:7:1 for v4l2src and colorimetry=(string)bt601 for v4l2sink
ndufresne: any hints what I'm missing to make it work?
javier___: there is a bug in gst, in v4l2 they added the extented caps, which is an ABI break and gst was never ported
I'll do that as soon as I find the time, it's not hard, it's just that it's looking at the module caps, instead of the instance caps
so with vivid it kind of get confused
there could be colorimetry bug too, but so far colorimetry bugs where all in the drivers
ndufresne: I see, do you recall how gst queries the colorimetry? is there a v4l2 ioctl for that or is deduced from other frame format properties?
trying to figure out if the colorimetry mismatch is the gst bug you are mentioning or a problem with vivid
javier___: we simply try_fmt with the colorimetry, and check the returnd fmt structure
there is no enumeration method for that no
ndufresne: Ok, thanks for the info
v4l2 is missing a lot of enumerations
which makes the entire thing so inneficient
I see
ndufresne: are you planning to do the gst port to extended caps in the short term or makes sense if I (or reynaldo/luis) takes a look to that?
Dears,  I'd like to implement las version of v4l on an ancient kernel (3.14) which will be cross-copmiled for an ARM target. I red install scripts from media_built and I saw all the patches that I have to install. However, even after patching I still have compilation errors, some .h or functions are called that 3.14 does'nt support. Do you have any
 clue ?
javier___: if you guys have he time, it's not really hard, just need a careful review of all the code using the capabilities to check the flag, I'd probably add a new member with the "right" flags so we don't have to check everytime
javier___: if you do, please file a bug first, apparently I forgot, and assigned it to yourself, otherwise, if I find the time soon, I'll do the same and cc you
ndufresne: Ok, I'll talk with luis and reynaldo to see if any of them don't have too much on their plate to take a look to this
ndufresne: thanks a lot for your help
javier___: btw, I commented positively about Vitor's suggestion to implement a fallback rather then a properly for using universal planes
how much work that would be ?
ndufresne: not much, in fact I even considered this option but thought that maybe it wouldn't be pretty since it would be kind of brute force
so far with the kernel we are often forced to try and error due to the lack of information
and the fact that vendor just hardcode it for their board
but I'm working with the gfx team here to come out with proposals
One in our list is to be able to detect support for modifiers
ndufresne: and javier___: hello :)
luisbg: hi!
ndufresne: I'll propose an alternate patch for 2/2 doing the fallback
great !
ndufresne: javier has showed me your comments about the v4l2 issue in gstreamer and the extended caps change not being ported
since you are very busy I offer my help
do you think it would be good to open a bug in gstreamer's bugzilla and give me some guidance of what and where to look at
I understand the issue at a very high-level, but not much more
ok, I'll do
ndufresne: thank you :)
ndufresne: how is everything going? the baby?
luisbg: that's it, https://bugzilla.gnome.org/show_bug.cgi?id=768195
luisbg: yep, quite well, 2 weeks and half before holiday ;-P (leaving for 7weeks)
ndufresne: so even busier than normal finishing things
ndufresne: very nice! 7 weeks
I'm be missing a lot of the 1.10 window, that's why I'm pushing a lot these days
the echo canceller was a distraction, you know, client needs ;-P
I understand
Anyone know how to determine if a select() on a mem2mem device means that the Output is ready, or the Capture? - I can't see how to distinguish between the two as they are on the same fd :(
kbingham: the writefds are for the video output direction, the readfds are for the video capture direction. So the same fd is use in both select() arguments and you can check with FD_ISSET if you can read and/or write from the fd.
hverkuil: Aha - thats' quite obvious now I see it :) thanks
see also streaming_set_m2m() in v4l2-ctl-streaming.cpp in v4l2-ctl.
hverkuil: I didn't realise v4l2-ctl did m2m streaming :)
kbingham: it does, but with limitations: it doesn't support codecs that do not give one buffer back for each buffer you put in.
hverkuil: Then its not useful to me :(
hehe
or you can try and fix v4l2-ctl!
hverkuil: in the future yes, but between tonight and tomorrow ... no :)
hverkuil: any reason why qv4l2 doesn't support frame rate setting using just s_parm/g_parm (not enum_frame_rate) ?
it would be lovely to test tw686x :)