<!-- Some styling for better description lists --><style type='text/css'>dt { font-weight: bold;float: left;display:inline;margin-right: 1em} dd { display:block; margin-left: 2em}</style>
narmstrong: <u>hverkuil</u>: hi
hverkuil: <u>narmstrong</u>: what is the status of https://patchwork.linuxtv.org/cover/64281/ ?
narmstrong: <u>hverkuil</u>: waiting for a new v4l2_fmt_ext serie with modifier support
hverkuil: OK, can I set this series to 'Changes Requested' in patchwork?
<br> Or perhaps RFC?
narmstrong: <u>hverkuil</u>: yeah RFC is ok
hverkuil: Thanks, updated.
narmstrong: thx
hverkuil: paulk-leonov: ping
<br> paulk-leonov: re: https://patchwork.linuxtv.org/cover/63468/
<br> It looks like patches 1 & 2 need more work, but 3 & 4 are ready to go and are also independent of 1 & 2. Correct?
paulk-leonov: <u>hverkuil</u>: oh right, I need to send a new version for patches 1 and 2
<br> <u>hverkuil</u>: indeed 3 and 4 are ready to go
hverkuil: ack
gbisson: <u>hverkuil</u>: Hi! I was wondering about the state of the tc358840 driver in the branch of the same name in your tree, was this version ever submitted? Do you accept contributions on it?
hverkuil: <u>gbisson</u>: it's not been submitted, but I hope it will happen this year. The problem is that I need a mainline kernel to test it before I can upstream it. The current driver was developed for kernel 4.4, and I can't upstream that.
<br> The work that is done on the tegra video input driver should finally enable me to upstream it. We're not quite there yet, but it is getting close.
<br> Once the driver is finally merged I will definitely accept submissions. In the current state I can only promise that I will look at it :-)
gbisson: <u>hverkuil</u>: thanks for the details! much appreciated, I understand the WIP state. My plan is to get it to work on i.MX8MQ
pinchartl: <u>hverkuil</u>: what's the status of that driver ? is it MC-centric now, or still uses the legacy API ?
<br> (I mean the Tegra driver)
hverkuil: Tegra driver is legacy API for now. The ti-vpe cal work you've been doing should be interesting since I gather that it adds a config option so you can choose. That's probably something the tegra driver can also use.
gbisson: FYI my main change so far is to the documentation to list all the properties needed in the dt
pinchartl: <u>hverkuil</u>: I'd really really recommend going MC from the very start
<br> doing anything else will be a mistake
hverkuil: <u>pinchartl</u>: But for now we keep it as legacy API. Basic plan: 1) merge driver with just TPG support (done), 2) add sensor support (in progress), 3) add tc358840 (aka HDMI) support, and 4) look into legacy vs MC.
<br> <u>pinchartl</u>: the problem is, the current out-of-tree driver is legacy API and there is a huge installed base. And speaking with my Cisco hat on: the legacy API works just fine for us, the MC API would just complicate matter for us.
<br> <u>gbisson</u>: that sounds great since that is one of the things that still needs to be done to make it ready for mainline.
pinchartl: <u>hverkuil</u>: that's ok, I can't prevent everybody from making mistakes ;-)
hverkuil: If it wasn't for the installed base (i.e. it is a completely new driver), then it would have been a no-brainer.
pinchartl: RPi raised the same issue
<br> I should have started libcamera 10 years ago... :-)
hverkuil: we probably would have if Nokia kept funding the MC work.
pinchartl: possibly
<br> we'll never know what would have happened :-)
<br> Eino-Ville would probably not have gone to Google to create the Android camera HAL API
<br> maybe OpenKCam would be a thing
tfiga: and I would have perhaps not started working on cameras and instead continue exploring other peaceful areas :P
montjoie: hello I have progressed a bit on zoran, but still I am stuck on output. I am now sure that ffmpeg give good jpeg data via v4l. I have dumped some frame which accordind to "file" are JPEG image data, JFIF standard 1.02, aspect ratio, density 4466x6075, segment length 16, comment: "Lavc58.93.100", baseline, precision 8, 720x406, components 3
<br> but when capturing mjpeg, zoran give JPEG image data, baseline, precision 8, 768x288, components 3
<br> perhaps my problem is the excess of metadata ?
hverkuil: 720x406? That looks like a wrong height (and possibly width). Does zoran even support non-standard (i.e. non-PAL/NTSC) sizes for output?
montjoie: ok I validate this. I keep a frame when capturing, and overun frames with it
<br> and now I have a correct output
<br> so zoran does not like exif data and other "comments"
hverkuil: It's really old hardware, so this does not really surprise me.
montjoie: does you know a way to remove them ?
<br> or does v4l have this ?
<br> like a clean_jpgcomments(vbuf*)
hverkuil: No, but I'm sure that there must be a utility to remove it. There are some zoran-specific utilities (not maintained by us): I wonder if those perhaps remove such jpeg extensions.
<br> http://mjpeg.sourceforge.net/
montjoie: I mean, cleaning it in the kernel
hverkuil: There are some parsing functions: include/media/v4l2-jpeg.h
<br> Not sure if that's helpful.
montjoie: this file is not in my tree
hverkuil: it's in our media_tree master branch.
<br> Landed in 5.8
ezequielg: <u>montjoie</u>: fwiw, jpeg syntax is not too hard.
<br> so quite a few drivers parse and produce jpeg syntax.
tfiga: https://www.cvedetails.com/cve/CVE-2004-0200/
<br> :)
-: ezequielg hides
tfiga: although it's true that some drivers simply parse JPEG headers in the kernel
<br> I suppose we don't need to parse all the syntax elements
<br> I wonder if we could spawn some isolated kernel threads for this kind of tasks
<br> basically userspace processes, but spawned from the kernel
<br> actually I was contemplating isolating the whole V4L2 subsystem into its own isolated address space
<br> there is surprisingly little interaction with the outside
ezequielg: that'd be nice.
<br> <u>montjoie</u>: otoh, if you simply need to skip an app1 segment, i suppose it's really easy in userspace.
***: benjiG has left
montjoie: <u>ezequielg</u>: goal is to not modify userspace...
<br> anything zoran specific in ffmpeg will be nak I think
<br> and bypassing app1 is simple