| ↑back Search ←Prev date Next date→ Show only urls | (Click on time to select a line by its url) |
| Who | What | When |
|---|---|---|
| ndufresne | pinchartl, so, more info, the resubmit error happens during tear down, I found why I still had couple of corrupt frame, rolling a patch now | [00:03] |
| .................................................................................. (idle for 6h48mn) | ||
| pinchartl | ndufresne: that makes more sense :-) | [06:51] |
| ........................... (idle for 2h10mn) | ||
| hfr | sailus: Hi Sakari, how are you ?
sailus: I have a question around sensor orientation management sailus: with my ov5640 setup, the image is 180° rotated sailus: The rotation is introduced by my daughter board where ov5640 is soldered sailus: is there a way through devicetree to tell driver to rotate image ? | [09:01] |
| pinchartl | hfr: we need a DT property for that
feel free to propose one :-) I'm not sure adding it to Documentation/devicetree/bindings/media/video-interfaces.txt would be best maybe we need a new Documentation/devicetree/bindings/media/camera-sensors.txt for that | [09:06] |
| ......... (idle for 43mn) | ||
| narmstrong | hfr: BTW, do you have issues with the ov5640 on DVP mode on mainline ? I know you are running STM32, but did you test v4.17 or media-next with the patches from mripard ? | [09:51] |
| ....... (idle for 30mn) | ||
| hfr | pinchartl: thanks Laurent, I will check what could be done, but I'm surprised that this case was never encountered yet, anyway I will check with other ov5640 clients about this rotation problem
narmstrong: I have the Maxime patch serie but I don't remember of registers change about orientation and I don't remember the image orientation, I will retest on my side | [10:21] |
| hverkuil | pH5: ping | [10:23] |
| pH5 | hverkuil: hi | [10:23] |
| hverkuil | I'm still not clear about the imx fim bit.
what exactly is it supposed to do? I see a bunch of controls, but only a few seem to have an implementation (s_ctrl). E.g. V4L2_CID_IMX_FIM_TOLERANCE_MIN is created, but as far as I can tell it does nothing. | [10:24] |
| pH5 | hverkuil: that is really a question for steve
hverkuil: that thing basically is a hardware counter assisted frame timing monitor, but I have never used it hverkuil: the controls are copied into internal fields in reset_fim(), which is called from fim_s_ctrl() hverkuil: tolerance_min for example is then used in frame_interval_monitor, which is called either from CSI EOF interrupt or, if the hardware counters are configured, from the fim_input_capture_handler. | [10:27] |
| hverkuil | Ah, and there is one fim per csi.
It's more of a generic helper module and it is not an implementation for hardware. So yes, I believe my patch is indeed correct. | [10:44] |
| .......... (idle for 45mn) | ||
| mripard | hfr: yeah, I haven't done any changes related to the rotation | [11:33] |
| ..... (idle for 21mn) | ||
| pH5 | hverkuil: yes, exactly | [11:54] |
| ..... (idle for 23mn) | ||
| hfr | mripard: I've just tested with your patch serie and I confirm that image is rotated on my side, could you confirm that on your side image have the right orientation ?
mripard: in that case I need someting new in DT to specify that driver must rotate image for my board... | [12:17] |
| mripard | hfr: yeah, it works fine for me
it's a loose camera anyway | [12:19] |
| hfr | mripard: ok thks ! | [12:19] |
| mripard | so there's no favored orientation | [12:19] |
| pinchartl | mripard: there's a sensor orientation relative to the "normal" orientation of the device | [12:20] |
| pH5 | pinchartl: should such a DT property invert the HFLIP/VFLIP sensor controls or just cause their default value to be set differently? | [12:22] |
| mripard | pinchartl: my point was that there's no normal orientation in my case
so I shouldn't really be used as a good example | [12:22] |
| ..... (idle for 20mn) | ||
| tfiga | pH5: thanks for review!
I'm wondering what you meant by colorimetry was it about color space, as in v4l2_pix_format_mplane.colorspace? | [12:42] |
| pinchartl | hfr: it's a good question. if inverting the flip controls doesn't produce any visible change behind rotation, I'd invert them. but if they result in changes to the bayer pattern, I'm not sure | [12:43] |
| pH5 | tfiga: yes, I meant colorspace, ycbcr_enc, xfer_func and quantization
tfiga: usually encoder/decoder don't care about them at all internally tfiga: so we just make sure that the same colorimetry is used for input and output tfiga: but colorimetry information can also be stored in h.264 streams so the decoder could determine colorimetry from the stream, and the encoder could store the set colorimetry data into the stream. | [12:47] |
| tfiga | pH5: got it, thanks! | [12:51] |
| hfr | pinchartl: here are the modifications I made to come back to the right orientation on my side:
- {0x3820, 0x41, 0, 0}, {0x3821, 0x07, 0, 0}, {0x3814, 0x31, 0, 0}, + {0x3820, 0x47, 0, 0}, {0x3821, 0x01, 0, 0}, {0x3814, 0x31, 0, 0}, 0x3820: Bit[2]:ISP vflip Bit[1]:Sensor vflip 0x3821: Bit[2]:ISP mirror Bit[1]:Sensor mirror so with default init sequence, the "mirrors" bits are set pinchartl: to have the right orientation I need to disable mirror and enable flip... | [12:59] |
| pinchartl: about sensor physical position, the flex is at bottom, that would mean that the natural position of this sensor is flex at top... I'll check datasheet if I found someting about that | [13:07] | |
| tfiga | pH5: is it possible to have a h264 stream that wouldn't have color space stored?
if it can't be parsed from the stream, I wonder if there is any point in letting userspace set it | [13:08] |
| pH5 | tfiga: yes, they can be stored in an optional part of the SPS (VUI parameters). | [13:10] |
| pinchartl | hfr: that's strange, I would have expected mirroring and flipping to be both enabled or both disabled | [13:10] |
| tfiga | IMHO CAPTURE queue could have V4L2_COLORSPACE_DEFAULT, which would mean that it wasn't parsed | [13:11] |
| pH5 | especially if h.264 is muxed into a container format that contains colorspace information itself, VUI is probably not set. | [13:11] |
| hfr | hfr: me too, I needed to do all combinations to have the right image ;( | [13:11] |
| tfiga | is it something that can change during streaming? | [13:11] |
| hfr | pinchartl: me too, I needed to do all combinations to have the right image ;( | [13:11] |
| pH5 | tfiga: not sure if this is a realistic scenario, but it's certainly possible. a new SPS NAL unit can appear in the stream at any time.
this should cause a normal source change event | [13:13] |
| tfiga | I see | [13:15] |
| ....... (idle for 30mn) | ||
| pH5: I posted my replies, but I need to defer some of the questions to Pawel, since my knowledge of codec internals is not as good
I'll be going to bed soon, so further replies tomorrow :) thanks for review again | [13:45] | |
| pH5 | tfiga: of course, I don't expect answers from you for all these questions :) but we should clarify uncertainties together. I'm looking forward to see what ndufresne's opinion is on this, for example. | [13:52] |
| narmstrong | jaganteki: hi, I finally got the "LP-11 timeout, phy_state = 0x00000230" message using the last media tree and imx_v6_v7_defconfig, using my custom defconfig it does not appear
but I still only have "[ 140.006543] ipu2_csi1: EOF timeout [ 141.046560] ipu2_csi1: wait last EOF timeout" on the DVP ov5640 | [13:54] |
| jaganteki | hmm, what diff in custom defconfig | [13:55] |
| narmstrong | quite a lot | [13:55] |
| jaganteki | can you paste if possible, may be I will try too | [13:56] |
| narmstrong | jaganteki: the custom defconfig narrows to imx6q | [13:56] |
| jaganteki | ok
don't understand what to debug further (: | [13:57] |
| narmstrong | jaganteki: here is the diffconfig betweem the custom and the imx_v6_v7_defconfig http://termbin.com/dia2 | [14:00] |
| ndufresne | pH5, these question, are they in an email ?
pH5, about the colorimetry / gstreamer, I was about to drop the probes completly for M2M, then I would set the info I got from the demuxer or parser, just in case the decoder do color conversion, but would ignore the value returned by the driver, so that copying this can be ignored by drivers For m2m converter, I will read back the value, and use it (unless invalid, e.g. we have converted to RGB) pH5, it's nice and all if driver passes back the input value, but it feels like it's not needed | [14:02] |
| ah, just saw the thread, great, I'll have a look at that, thanks tfiga | [14:11] | |
| pH5 | ndufresne: right, for GStreamer even if colorimetry is parsed from the h.264 stream itself, that's probably h264parse's job. otherwise this is probably part of the demux. | [14:15] |
| ndufresne | indeed, and in general, it's probably better to ask the video info code to make a guess, just for the sake of making sure these guess are consistant (I know gst guesses are not fantastic atm though)
pH5, but for the base you have a decoder combined with a color conversion, the decoder may need that information to post process correctly (does not apply to detiling, but if you convert to RGB, then it's needed) mchehab, I like your proposal to join the meeting in Japan through video call, may I invite my Korean colleague Justin (based in Seoul), he's been working with Android HAL3 for a while, and knows quite well the real usage of these cameras | [14:16] |
| narmstrong | jaganteki: yavta is happy using https://pastebin.com/aGSECk5Y
well it worked, once | [14:32] |
| pH5 | narmstrong: drive-by nit-pick: line 8 should still be UYVY2X8, I think. | [14:43] |
| narmstrong | pH5: sure
stupid question: whats is the simplest way to vizualise the output ? Video format: UYVY (59565955) 640x480 (stride 1280) buffer size 614400 | [14:46] |
| pinchartl | narmstrong: raw2rgbpnm
(after capturing the frames to files with the -F option to yavta) | [14:49] |
| mripard | narmstrong: I like rawpixels.net
I can never get around the needed options for raw2rgbpnm | [14:52] |
| javier__ | oh, I didn't know about rawpixels.net. I also use raw2rgbpnm, i.e:
yavta -f UYVY -s 720x480 -n 1 --capture=1 -F /dev/video0 raw2rgbpnm -f UYVY -s 720x480 frame-000000.bin frame.pnm | [14:55] |
| pinchartl | mripard: -f format -s size
is that so difficult ? :-) | [14:57] |
| mripard | pinchartl: I never said it was difficult, I'm probably just too forgetful / stupid to use it properly :) | [14:58] |
| ...... (idle for 26mn) | ||
| narmstrong | mripard: pinchartl: javier__: great thanks, I have something :-) but it often fails with between captures
"LP-11 timeout, phy_state = 0x00000230" | [15:24] |
| ..... (idle for 20mn) | ||
| *** | benjiG has left | [15:44] |
| narmstrong | mripard: but rawpixels.net is really useful ! | [15:49] |
| ........... (idle for 54mn) | ||
| jaganteki | narmstrong, I can't get https://paste.ubuntu.com/p/6w48wFKJtt/ | [16:43] |
| ..... (idle for 21mn) | ||
| narmstrong | jaganteki: is the clock to the ov5640 correct ? | [17:04] |
| jaganteki | yes, https://paste.ubuntu.com/p/87V9zZndKy/ | [17:08] |
| ↑back Search ←Prev date Next date→ Show only urls | (Click on time to select a line by its url) |