<!-- 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>

   tfiga: <u>svarbanov</u>: mjourdan: that doesn't seem to be a reasonable behavior
   <br> if a resolution change is not notified to the userspace, how does it know to update the visible size?
   ribalda: <u>sailus</u>: goood morning! Hyvää huomenta!
   svarbanov: <u>tfiga</u>: good question! I cannot remember, did you specify such behavior  in decoder's spec
   sailus: <u>ribalda</u>: Heippa!
   tfiga: <u>svarbanov</u>: I recall doing so
   <br> but maybe could be written more explicitly
   <br> generally source change event is not limited to frame buffer resolution change
   <br> it should be also signaled on change of crop or minimum number of buffers
   hverkuil: <u>tfiga</u>: do you have plans to post a new version of the stateful codec spec?
   tfiga: <u>hverkuil</u>: yes, sorry for taking so long
   <br> I started working on v2 before holidays last week
   svarbanov: <u>tfiga</u>: so I'm still on the process of implementing that so not a big issue. The biggest issue for me is lack of unit (api) testing.
   tfiga: but found some new corner cases
   <br> <u>hverkuil</u>: I think I sent an email describing those, did you have a chance to look?
   <br> <u>hverkuil</u>: also thanks for mentioning the format flags, I forgot about them
   <br> they should be useful for some other capabilities
   hverkuil: Can you point out your email with corner cases? Chances are I missed it.
   ribalda: <u>sailus</u>: On https://patchwork.linuxtv.org/patch/52310/ what do you mean by the link_freq should come from the firmware
   <br> shall I remove the control?
   sailus: <u>ribalda</u>: The firmware should contain the list of valid link frequencies.
   <br> If you only support one, I guess it's fine if the actual list comes from the driver and the driver checks this is what the firmware has.
   hverkuil: <u>svarbanov</u>: are you interested in improving v4l2-compliance tests?
   ribalda: <u>sailus</u>: I check the frequency at probe.
   sailus: I think that's fine then.
   <br> I probably missed that when reviewing it.
   ribalda: <u>sailus</u>: thanks :)
   sailus: Please ignore the comment.
   hverkuil: (going to the office, ttyl)
   svarbanov: <u>hverkuil</u>: yes, I am
   tfiga: <u>hverkuil</u>: https://lore.kernel.org/patchwork/patch/966933/#1172685
   ***: smartin has quit IRC (*.net *.split)
   <br> TFKyle has quit IRC (*.net *.split)
   svarbanov: <u>hverkuil</u>: tfiga: but just improving v4l2-compliance is not enough. We have to add simple parsers and test streams with dynamic changing resolution too.
   tfiga: <u>svarbanov</u>: we need those indeed, but I think that could be still a part of the v4l2-compliance suite
   <br> the need to improve codec API testing is undisputable :)
   <br> but maybe after we actually specify it? ;)
   <br> I'd also want to see some multi-instance testing too
   <br> we caught so many bad races in s5p-mfc by playing videos in few browser tabs on Chrome OS
   hverkuil: <u>tfiga</u>: svarbanov: I would really like to see those test sequences being part of v4l2-compliance (or possibly in a separate repo maintained on linuxtv.org).
   <br> In fact, creating such sequences using the V4L2 test pattern generator as the source of the raw video would be particularly useful, since (if configured correctly) this will also help in testing correct colorspace support of the codecs.
   <br> Note that it is often very useful to develop drivers/documentation/tests at the same time. Writing a test is a great way to discover missing corner cases or unwieldy APIs.
   <br> The biggest missing feature of v4l2-compliance w.r.t. testing codecs is that it can't read from a file. v4l2-ctl does have support for that, and that should be transplanted into v4l2-compliance as well.
   <br> <u>pinchartl</u>: can you reply to this message: https://www.mail-archive.com/linux-media@vger.kernel.org/msg134930.html
   <br> (I forgot about it until the reminder today from Intel)
   pinchartl: <u>hverkuil</u>: not today. hopefully by the end of the week
   ezequielg: <u>hverkuil</u>: hi, if you want to discuss about the jpeg pixel format, let me know!
   hverkuil: <u>ezequielg</u>: ping me tomorrow, I'll have time then.
   ezequielg: ok
   DrMattTS: I’m putting together a camera recording pipeline from an MJPEG camera and want to use a hardware jpeg decoder and hardware h265 encoder. I’ve got example code and I think I know what I need to do. Is this the sort of thing people here have experience with?
   hverkuil: <u>DrMattTS</u>: I think gstreamer is typically used for that. What SoC is this running on?
   DrMattTS: Jetson TX2
   hverkuil: Then we can't help. There is no support for that in the mainline kernel, so you should ask your question on an nvidia forum.
   DrMattTS: The API is built on V4L but yeah, it’s not standard
   <br> Thanks
   hverkuil: for the camera I think it is v4l based, but AFAIK not for the encoders.
   <br> (although the MJPEG decoder might be v4l based, I'm not sure)
   DrMattTS: The encoder uses V4L2 pixel formats and memory types for the output and capture planes so I assumed it was
   ***: prabhakarlad has left
   <br> _jmleo has quit IRC (Quit: Disconnecting from stoned server.)
   <br> griffinp- has quit IRC (Remote host closed the connection)
   <br> prabhakarlad has left
   <br> _abbenormal has quit IRC (Quit: Leaving)
   <br> angelo_ts has quit IRC (Changing host)
   <br> cybrNaut has quit IRC (Ping timeout: 272 seconds)