| ↑back Search ←Prev date Next date→ Show only urls | (Click on time to select a line by its url) |
| Who | What | When |
|---|---|---|
| neg | larsc: I'm looking at the adv7180 patch you and headless talked about yesterday. I can however not figure out if V4L2_FIELD_SEQ_ or V4L2_FIELD_INTERLACED_ is the right filed typ for it to use. | [06:47] |
| larsc | INTERLACED is clearly wrong
INTERLEACED means line interleaved but the adv7810 sends frame interleaved data but each frame has a full vsync, so I'd argue that the right type is ALTERNATE how does the rcar-vin figure out which frame is which? the bt656 SAV codes indicate which frame it is, so in theory the hardware should be able to figure it out | [06:48] |
| neg | the VIN driver simply acts on whatever field type is provided by the subdevice. And right now rcar-vin do not support SEQ or ALTERNATE types, so I need to fix that | [06:54] |
| larsc | does it pack the two frames into the same buffer? | [06:56] |
| neg | yes | [06:56] |
| larsc | how is that done?
what does the FOC bit do? | [06:57] |
| neg | or hum, I think it can do both. I can select odd, even, odd+even and interlace modes
FOC selects which field is first for full interlace capturing | [07:01] |
| larsc | makes sense
I have to go now, I'll be back in 2-3h | [07:13] |
| ......................................................... (idle for 4h41mn) | ||
| neg: this is all really tricky since there is no clear definition what V4L2_FIELD_* means in the context of the bus
they are only defined in the context of a buffer the receiver hardware could easily assemble all kinds of buffer types from the same pixel stream | [11:55] | |
| neg | larsc: yes, I had a go at it but could not make much sens out of it from a rcar-vin perspective | [11:58] |
| larsc | there is probably no public documentation of how the core works, right? | [11:59] |
| neg | unfortunatly not, but from what I can see it should just be a matter of expanding the existing switch statement you already found with more combinations of the flags already avilable in the driver | [12:02] |
| larsc | VNMC_IM_FULL means it will line interleave the two frames?
and VNMC_IM_ODD_EVEN it will place the frames on top of each other?> when you look at the number of registers the core should be pretty straight forward | [12:03] |
| neg | VNMC_IM_FULL - Handles combinations of odd and even fields as single frams and stores them in external memory, FOC as we talked about eriler controls if top is odd or even | [12:04] |
| larsc | or so they are not interleaved, but on top of each other? | [12:05] |
| neg | VNMC_IM_ODD_EVEN - Handles odd and even fields as separte frames and stores them in external memory | [12:05] |
| larsc | ok, comparing this with https://linuxtv.org/downloads/v4l-dvb-apis/fieldseq_tb.gif it means interleaved is probably not supported at all
unless the decoder sends line interleaved data so you could support TOP, BOTTOM, SEQ_TB, SEQ_BT and ALTERNATE TOP is IM_ODD, BOTTOM is IM_EVEN, SEQ_TB is IM_FULL, SEQ_BT IM_FULL + FOC, ALTERNATE is IM_ODD_EVEN and that's for the same incoming pixel stream for ODD_EVEN does the core tag which outgoing frame is which? | [12:06] |
| headless | SEQ_* had strange effect on the image captures
captured | [12:11] |
| larsc | sorry for rambling so much, I've been renovating my apartment for the last 1 1/2 weeks. Need a bit of a break from that ;) | [12:11] |
| headless | it gets compressed horizontally | [12:11] |
| neg | I think I can support INTERLACED too. for VNMC_IM_FULL data in the capture start field is stored in every other line in the memory as the odd field data and then data in the next field is stored as the even field between the written lines so that the top and bottom field lines alternate with each other for interlace composition | [12:12] |
| larsc | headless: maybe ffmpeg also gets it wrong? | [12:12] |
| headless | larsc: I don't think so | [12:12] |
| larsc | neg: so it is line interleaved? | [12:13] |
| neg | larsc: yes that is my understanding, but I would like to test it | [12:14] |
| headless | the image is always 640x480, just the displayed width was about 1x8 of the image width | [12:14] |
| larsc | or can you set different base addresses for different frames?
headless: are you using the soc_camera or the other driver? | [12:14] |
| neg | larsc: yes I can read out of the current captured field was top or bottom
s/of/if | [12:15] |
| headless | larsc: I tested both old and new
drivers I was only able to get a good image with the new driver, after all my changes to Steve's patch which included s/SEQ/INTERLACED/ and reversing the field order | [12:16] |
| larsc | headless: I don't think that neither the adv7180 and vin driver are 100% correct, which makes this a bit more tricky
even if you get it work that does not mean it is correct in the sense of the spec | [12:18] |
| headless | lemme reboot to Linux (and finish some home work) | [12:22] |
| larsc | hm, the driver expects that buffers are always queued in the same order?
I don't understand rvin_fill_hw() it always starts at slot zero shouldn't it go round robin? save where it stopped previously and then continue there | [12:22] |
| neg | There are 3 possible buffers to store the image in if capturing in continues mode. rvin_fill_hw() only makes sure all buffers are available. But yes they are used in a round robin fashion by HW | [12:32] |
| larsc | lets say one buffer is in the queue and the the interrupt handler runs and calls rvin_fill_hw(). This would write the address to the first slot
then the buffer is dequeued next, processed and queued again. And thn the next interrupt handler runs and again rvin_fill_hw() will write the address of that buffer to the first slot even though the previous one might not have been completed yet | [12:33] |
| neg | no it will find the first slot that is free, see rvin_fill_hw_slot() | [12:35] |
| larsc | ok, sorry overlooked that | [12:36] |
| neg | before the interuppt handler calls rvin_fill_hw() it sets vin->queue_buf[slot] and it is this slot that will be filled by the call
hum set it to NULL that is | [12:36] |
| larsc | I overlooked that it skips used slots, I though it would just always start at 0 | [12:38] |
| pinchartl | hverkuil1: ping | [12:40] |
| headless | back | [12:44] |
| neg | stupid question, from a driver perspectiv the only difference for ALTERNATE and SEQ_* is that for ALTERNATE I need to set the correct v4l_buffer.field when I have captured a buffer and for SEQ the imagesize twice the size?
hum not size but height | [12:45] |
| larsc | yes
ALTENATE = one frame per buffer, SEQ_* = two frames per buffer on top of each other INTERLACED = two frames per buffer, line interleaved in theory you could support all of them, even if the DMA only captures one buffer at a time, by massaging the DMA base address and stride so it and do two transfers for SEQ_ and INTERLEAVED but if the hardware supports it in hardware even better | [12:46] |
| headless | if not tautological :-) | [12:49] |
| headless switched back to Porter | [13:00] | |
| SEQ only captures one field
the bottom part of the picture is black maybe it's rcar-vin bug indeed neg, wat do you think? what | [13:11] | |
| neg | hum if the adv7180 output is not INTERLACED but SEQ or ALTERNATE it would explain some other odd stuff in the VIN driver where it cuts the interlaced capture image size in half
I'm trying some stuff now | [13:13] |
| larsc | headless: The driver does not seem to support SEQ atm | [13:14] |
| headless | larsc: yeah
it does the same stuff tew old driver did WRT the fields almost | [13:14] |
| larsc | it's a matter of properly translating the FIELD stuff to vin register settings | [13:15] |
| headless | s/tew/the/ | [13:15] |
| neg | yes SEQ is not supported atm, it falls back to FIELD_ODD if it's encounterd | [13:15] |
| headless | which is odd :-) | [13:15] |
| larsc | well it explains why there is only half a frame | [13:16] |
| ..... (idle for 21mn) | ||
| headless | well, taught rvin_setup() to handle SEQ but that didn't change anything
and prolly shouldn't when capturing just 1 frame VIN just can't capture 2 fileds into one buffer, unless they are interlaced | [13:37] |
| larsc | you can do two captures into the same buffer | [13:41] |
| headless | larsc: yeah, just figured
still, Steve's patch is wrong, he has the fields reversed | [13:41] |
| larsc | I'm not convinced that it shouldn't be ALTERNATE
the adv7180 sends the data as separate frames how this is assembled by the dma into the buffers is independent of that | [13:43] |
| headless | headless -> outdoors | [13:51] |
| ............................. (idle for 2h20mn) | ||
| *** | benjiG has left | [16:11] |
| ...... (idle for 25mn) | ||
| snawrocki has quit IRC (Remote host closed the connection) | [16:36] | |
| .... (idle for 17mn) | ||
| headless | neg, anything new? or you've stopped looking into the NTSC regression?
(and adv7180) oops, stupid mobile router broke https again | [16:53] |
| neg | headless: well I'm trying to add V4L2_FIELD_ALTERNATE to the rcar-vin since that would solve the field order for PAL/NTSC (I think). But I have a hard time getting qv4l2 to assemble the two fields from two buffers to one frame
I'm probobly doing something wrong in the driver but now I need to run out and go to dinner, need to look more at this tomorrow. But I do agree with larsc I think the adv7180 filed ALTERNATE makes more senes then SEQ | [16:59] |
| headless | aha, thank you
ALTERNATE doesn't give you the field order, does it? | [17:01] |
| neg | d00h, you are right it will give me if it's a odd or even field (I can read this from HW) but not if it is TB or BT | [17:04] |
| headless | well, odd/even is good enough
but is there a way to store that info in the buffer? | [17:05] |
| neg | The doc I found at https://linuxtv.org/downloads/v4l-dvb-apis/field-order.html if I understnad it says I should set v4l_buffer.field to TOP or BOTTOM if I'm capturing ALTERNATE
this works but I only get half of the lines for each frame in qvl2 and I see the image dance 1 line up/down :) | [17:08] |
| headless | ah
perhaps it's qvl2's prob? OK, thank you for the update! | [17:09] |
| neg | don't know, maybe. I looked at some other driver and they look like they cut the requested image height in half when working with ALTERNATE. See saa7134
I'm so tierd right now so I might just be rambling, will start fresh in the morning :-) | [17:11] |
| headless | OK
if I understood larsc right, we're free to treat ALTERNATE any way we want, i.e. assemble a full frame? in 1 buffer, I mean | [17:12] |
| neg | yes, and if we treat it as INTERLACE the HW do the job for us, which is nice but then we are back at the BT or TB problem
got good image quality using NTSC with my hack patch, but ofc only for half the lines | [17:14] |
| ......... (idle for 42mn) | ||
| larsc | https://en.wikipedia.org/wiki/Field_dominance
the problem is mapping field number to field type is field 0 the even or the odd field this can probably only be done based on the resolution now the question is should the decoder device gather this data and make it available to the DMA device, or should the DMA device gather this data on its own? I'd say decoder, but I belive we dont have a API to propagate it to the DMA device I think TB and BT actually dont help here because it does not say anything about the temporal order, only how they are put into memory no actually it does and the problem is mapping field number to position which depends on the standard | [17:57] |
| awalls | The only way I know to tell which field it is for sure, is by looking at the V_SYNC pulses and the definition of field number in the particular TV standard.
But most chips don't tell you about the V_SYNC pulses they just saw. | [18:11] |
| larsc | the hardware only knows the field number
at some point, before reaching the userspace application, the kernel has to do the mapping from number to order | [18:12] |
| awalls | yup. | [18:12] |
| larsc | this is bt656 so the field number is embedded in the SAV/EAV codes
and the DMA hardware is able to extract them and act on them so that is good | [18:13] |
| awalls | The SAVE/EAV codes have the T,V,F bits that should tell you. | [18:14] |
| ............ (idle for 58mn) | ||
| larsc | ha! Just thought we should put this into the mbus format
http://lxr.free-electrons.com/source/include/media/v4l2-mediabus.h#L40 but there it is already | [19:12] |
| ..... (idle for 21mn) | ||
| on the other hand that is for the physical field pin
but we need something similar for the field signal embedded in the SAV code | [19:33] | |
| ......................... (idle for 2h1mn) | ||
| *** | awalls has left | [21:34] |
| ..... (idle for 22mn) | ||
| headless | night | [21:56] |
| ↑back Search ←Prev date Next date→ Show only urls | (Click on time to select a line by its url) |
