mchehab: This one was almost two months old, I had intended to mark it superseded indeed.
I'll send an update shortly.
The update is actually already there:
https://patchwork.linuxtv.org/patch/50567/
mchehab: ^
I added myself a bookmark to a search showing my own pull requests. That should help...
yes, I know the pull request is old, but, as it was still tagged as New at patchwork, I assumed it is valid. Next time, please don't forget to tag superseeded stuff as such
hi all
Hi Mauro!
yesterday I started handling pending git pull requests
I noticed that several patches were both on hverkuil and sailus trees
hverkuil, I doubt I'll have time to review the request API this week :-(
I sometimes take trivial sensor fixes as long as they are not delegated to sailus. I'm not sure if sailus always checks/changes the 'delegated' status.
hverkuil: I understand.
I suspect that sailus is forgetting to delegate the ones he handled to himself
it is understandable that sometimes the same patch arrives both trees, but this time I guess there were 3 or 4 patches
Where they trivial sensor patches?
yes
Ah, that explains it then.
Hello!
I don't have issues on solving such minor conflicts... I mean: it is better to have them applied twice than not applied...
but still this is sub-optimal
I've taken sensor patches not delegated to me (generally not delegated at all) but I've marked them as accepted in that case.
as the time to review those could be used reviewing other stuff
sailus: well, then perhaps you and hverkuil were reviewing both at the same time
That may be it, too.
no big deal
I wonder what Patchwork does if the patch status changed between page update and status change.
sailus: I'll just leave them for you in the future. Probably safer.
it is supported by a SQL database
hverkuil: Ack.
Speaking of sensor driver patches --- there are more here:
so, if both tries to change status at the same time, it will serialize
https://patchwork.linuxtv.org/patch/50567/
I'm handling them at the order it was stored on my quilt tree
And rotation property patches here:
https://patchwork.linuxtv.org/patch/50565/
the next one I'm handling right now are some git pull request with docs from hans
mchehab: when do you think you've finished the pending pull requests?
(for my planning)
no idea... it all depends on how many patches are there at the pending ones - and how complex they are
my plan is to do it this week
OK.
but I have some other unrelated stuff to handle internally
that is the next one
Subject: [GIT,PULL,v2,for,4.19] Add "rotation" property for sensors, use it
From: Sakari Ailus <sakari.ailus@iki.fi>
X-Patchwork-Id: 50565
mchehab: I have more sensor patches queued up. I didn't want to make this one bigger than it already is.
I've asked this before, but if you guys have 10 minutes free please look at this patch series: https://www.mail-archive.com/linux-media@vger.kernel.org/msg132942.html
\o/
hverkuil: Oh, yes.
hverkuil: can't open that link
The patches are small (media API improvements) but if OK I really want them merged.
Sorry for the delay. I've had quite a few pending reviews to do recently.
hmm... it opened... after ~30 seconds negotiating TLS
(I wished this was the only one.)
hmm... MEDIA_ENT_F_DTV_ENCODER
do we have DVB encoders?
 digital video encoders such as HDMI transmitters.
better to name it differently
we're using DTV as an alias for Digital TV
We use DTV_DECODER for HDMI receivers.
bad name
we use DTV decoder refering to something else on several places
Well, perhaps, but it is in use like that for a long time.
For DVB you'd call it a modulator I think, not encoder.
I suspect that the usage of DTV for digital TV at the subsystem is a lot older
Perhaps DV_ENCODER?
OK
please rename the DTV_DECODER (keeping an alias for the old one - for backward compat issue)
Ah, that was my next question :-)
:-D
DV corresponds with the DV_TIMINGS API, so that makes sense.
yes, DV makes complete sense
I'll try to review that series after finish handling git pull requests
BTW: since nobody else picked it up, and we really need it, I started work on a vicodec driver based on the work Tom aan de Wiel did for me to create a simple software encoder/decoder.
https://git.linuxtv.org/hverkuil/media_tree.git/log/?h=vicodec
good
It's already working but needs a few more improvements before I'll post it.
It encodes 720p at about 40 fps and decodes at 90-100 fps.
It obviously depends on your CPU.
encode/decode what?
what formats, I mean
Currently I concentrate on the stateful encoding/decoding, but the next step will be to do stateless encoding/decoding to test the request API.
I have one concern about it
people might be using it in production
YUV420 in, out is the FWHT format (Fast Walsh Hadamard Transform).
Not good enough quality for production. You clearly see the macroblocks.
Also the compression is no where good enough.
ok, good
It's perfectly fine for testing with a codec that has all the main properties of regular codecs.
better to avoid supporting more usual formats like mpeg/jpeg if possible
The codec source code is just 936 lines long (and will go down even further).
good
yeah, my main issue is to be sure that this will be used for what it is meant to be: to test the API
(and not as something that lazy people would use in production)
Also the algorith is very old, well over 20 years, so patent-free.
yeah, I don't think FWHT support would rise the issues I'm talking about
I'm quite pleased with it. It already helped me fix various v4l2-ctl bugs.
great!
Tom did a fantastic job. I tried to hire him for Cisco, but he went for ARM instead. Oh well, you can't win them all :-)
:-D
hverkuil: Reviewed.
sailus: thanks!
we need to discuss upstream about the date for the media summit
(either at ELCE or Plumbers)
I intend to drop an email likely next week about that
and see what works best
I can tell my preference is ELc-E.
I will be at ELCE, I will only be at Plumbers if the media summit is there. My preference is also the ELCE.
Most likely I won't be in Plumbers conference.
pinchartl told me in JP that he intends to be on both
anyway we need to set it up
better to see what people at ML think
BTW, I am still not seeing any signs of Intel or Google willing to actively put in resources to work on userspace support for complex cameras.
I'd like to do one in north america from time to time, to attract developers there
yeah, I'll ping them next week about that
We can always do something with the ELC (we can have two summits in a year, not a problem).
yeah, sure
I'm always at both ELCs.
One last note about vicodec: I want to do the same with that codec as I did with the v4l2-tpg: allow it to be used in applications as well, like v4l2-ctl.
I guess ELC NA already happened this year
the point with plumbers is that it will happen with KS
(although KS is getting weird with its new format, IMHO)
not sure if I understood your plan with vicodec
The same people who are there tend to be at the ELCs as well.
v4l2-ctl uses v4l2-tpg from the kernel
sync-with-kernel copies it)
I want to do the same for the vicodec sw codec so v4l2-ctl can use it and generate an encoded stream towards vicodec. Helps testing, esp. when I do the same with v4l2-compliance.
I.e. you run v4l2-compliance with vicodec and it can exercise the codec API checking for regressions without requiring test streams.
works for me
anything else for today?
hverkuil, if I don't review that patchset until monday, feel free to ping me again
I'm still recovering from a 12 hours TZ shift
Not from me. I'll update the media/mc patch series, replacing DTV_ENCODER by DV_ENCODER and repost it.
ok
That's all from me, too.
ok. let me go to another meeting then
hverkuil, sailus: all pull requests handled
mchehab: fantastic!