neg, hi!
headless: hi
headless: some progress today, I figured out how to solve it working on fix now. But where lots of misstakes in the rcar-vin driver related to TOP and BOTTOM which came to light when I added ALTERNATE, working on fixing them now
neg, excellent!
thank you
but all is based on that Steve changes his patch so that adv7180 reports ALTERNATE and not SEQ field
neg, Steve's patch ius not good anyway (at least for us)
feel free to rewrite it
*is
and the field order was wrong in that patch, IIRC
*IIUC
yes it was
neg: if you get it to work with ALTERNATE let me know, I'll talk to Steve and see if I can get him to agree that this is the way to go
larsc: I have a series ready to go using ALTERNATE, I included Steves patch in it but I reworeked it to report ALTERNATE
I'm only waiting for headless to return so I can figure out his email so I can CC him in the series, then I will send it out
larsc: or is it rude of me to include a reworked patch from Steve? I have keep him as author only s/V4L2_FIELD_SEQ_/V4L2_FIELD_ALTERNATE/. I can drop the patch from the series and you can talk to Steve instead?
it's ok I guess
how do you handle field order?
for ALTERNATE? Hw provides iformation if it's a odd or even field that was captured
does it? or just the field number?
whether field 0 is odd or even depends on whether it is NTSC o PAL
there is 1 bit flag in a register indicating if the current buffer captured was odd or even
but how does it know?
that I don't know, can't find any explanation in the datasheet
the only info it gets from the adv is whether it is field 0 or field 1
but lets wait for headless to test it with ntsc
maybe there is some magic in the controller
neg, you posted patches?
not seeing them. not subscribed to linux-media
not sure why you need me to test. neg also has a NTSC camera IIRC :-)
would we notice if the field order was wrong?
yes
larsc: we should notice
zigzag'ged edges, etc.
headless: I sent the patches now
started receiving now
the 2nd adv7180 patch loks strange
n/m, it's alright
yea the patches needs a good review, I might have missunderstond how things are suppose to wrok
larsc: as for oid/even detection, doesn't odd/even field contain the odd/even # of lines?
IIRC vtotals are 525 and 625
*odd
OK, will start testing now.. I guess it's enough to merge only patches 4 & 6?
s/merge/import/
Nice figures with line numbers in relations to the start and end of fields: https://linuxtv.org/downloads/v4l-dvb-apis/raw-vbi.html#vbi-525
OK, booted
neg, the picture seems OK
if you're still there... sorry for a delay
I haven't imported patch #1 tho... will try importing it now
headless: nice, thanks for testing
headless: you should be fine without patch 1, but then you can't force a specific field. And if you look at patch 4/6 you se it will not use ALTERNATE but INTERLACE_{BT,TB} if it can find a video standard. I'm not sure this is correct but it feelt right the correct solution
that part seemed a bit starnge to me
ALTERNATE assumes to buffers per frame, while INTERLACED* only one. no?
s/to/2/
this is a legacy from the old driver I guess
yes
one buffer for each field
no, 1 buffer for both
see e.g. https://linuxtv.org/downloads/v4l-dvb-apis/field-order.html
yes but the test tool i use (qv4l) do not merge two frames in ALTERNATE but show each frame as is, it tried to do something clever with the pixel aspectratio
s/frame/buffer/?
yes sorry
hum, that doesn't seem right
so what was the point of teaching it ALTERNATE then, if you override that setting anyway?
or I'm misunderstanding?
well the driver delviers one field per buffer in ALTERNATE and sets the TOP/BOTTOM flag, the rest is up to userspace to assemble the end frame right?
neg, not sure
headless: the adv7180 delivers one field at a time
that's why ALTERNATE is the right thing for the adv7180
larsc: ah, I see now
the rcar-vin might assemble this into something else
like INTERLACED or SEQ
or pass it through as is
up to userspace what it can best work with
but why be so specific and not use just INTERLACED type?
at what level?
in the patches I sent it will report INTERLACE to userspace and capter both fields and pass them in one buffer if the source provideds ALTERNATE and the video standard is returned from g_std. The user can also explicity request ALTERNATE and then the driver will be happy to supply it in that format
if that is right or not I do not know, but it feels like it should be OK
larsc: in the VIN driver
why call sudev's g_std() at all?
*subdev's
sorry for being dense :-)
the driver should expose the hardware capabilities to userspace and let userspace decide what it wants
there might be cases where one format works better and others where another works better
or maybe I dont understand what you mean
I'm just not sure it's worth to be as specific as TB or BT for the userspace
well, if you think it is, let it be so
sorry for being a lazy sod
inporting a part of a series was a bit too much self-confident :-)
with git am it is really easy to import the whole series
WTF? it's alll messed up again!
headless: ?
neg, fields swapped
I'm suing the capture example still
*using
neg, it must be your 1st patch
headless: I will turn in for the night now, but I will give the capture example another go tomorrow
yeah
neg, it's the 1st patch
note that' I'm not seeing midframe captures anymore
even on the Porter where I saw them at first
now let's see what mess that caused in the old driver :-)
great mess
so, in the end, not importing a whole series wasn't such a bad idea :-)
hum, the first frame was very strange, now when I fixed the camera orientation, it's just half a frame
sigh
larsc: prosit! :-)
if you're still there
trying to reach the ballmer peak?
midnight disconnect again :-/
neg, thanks for your work. don't forget that tomorrow (today here already) is a Saturday :-)
note that I ran capture with -f
perhaps I should try omiting that
tt
Nacht