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

   APic: I hope so.
   <br> Good Night.
   awalls_: not with v4l hardware and drivers.  you want a SDR unit
   Sloyment: :-(
   tiffanylin: Could we use V4L2_EVENT_SOURCE_CHANGE event to notify user space that current BS is interface after codec driver parse frame level info?
   <br> There are 'field' in v4l2_buffer, vb2_v4l2_buffer,  v4l2_pix_format_mplane. What's different between them. Could we assign same for all 'field' in different data structure?
   sailus: <u>tiffanylin</u>: v4l2_pix_format_mplane field is the field of the format. It can be e.g. interlaced, whereas the field in v4l2_buffer and vb2_v4l2_buffer is the field of that very buffer (e.g. top or bottom).
   hverkuil: <u>tiffanylin</u>: the field value in v4l2_pix_format* and v4l2_buffer is normally the same, except if the field in v4l2_pix_format* is set to V4L2_FIELD_ALTERNATE: in that case the field in v4l2_buffer will be V4L2_FIELD_TOP or _BOTTOM (i.e. which field is stored in the buffer).
   <br> Drivers that only deal with progressive frames can just always set it to V4L2_FIELD_NONE.
   tiffanylin: sailus, hverkuil: got it. If user space set V4L2_FIELD_NONE to output queue fmt, but after codec parsing frame slice info and found it is field content, could we use V4L2_EVENT_SOURCE_CHANGE event to notify user space? Since this is a kind of source format change.
   sailus: <u>tiffanylin</u>: Is that a decoder?
   <br> I guess that'd be fine. I wonder what hverkuil thinks.
   <br> The user space would learn that the field actually changed and it may be important.
   tiffanylin: <u>sailus</u>: yes. it's decoder
   <br> So driver could directly update field in v4l2_pix_format* and v4l2_buffer without notify user space. user space monitor the field in v4l2_buffer to check if field changed?
   sailus: Sounds good to me.
   tiffanylin: Will this impact performance? since this need to check field in capture buffer every time dq from driver.
   sailus: I can't see how it could have a noticeable effect.
   <br> You'll just provide an event to the user space when the field changes in the format.
   <br> I wouldn't expect this to be very common.
   tiffanylin: Sorry. I don't understand. You mean you don't expect "provide an event to user space" to be very common.
   sailus: How often does the field configuration of the stream change?
   <br> I suppose it could if the video consists of multiple parts that have been captured using different cameras. That's you use case, isn't it?
   tiffanylin: not very often. Most of time once after decode first frame...... In some case, user space to not provide correct field info, this will happen
   sailus: Yes.
   tiffanylin: No....Our case is that user space dmx or parse do not pass correct field info to driver, and need driver to report that this content is interlace content.
   <br> Now we do not support field change in middle of the stream. So this event will happen once
   sailus: Yes.
   <br> Both are possible.
   <br> But it's unlikely it'd happen on every frame I presume.
   <br> Or even every other.
   tiffanylin: I got it. Now we do not support this kind of data, so we think it will only happen once after stream. But if user space test this kind of content, driver will sent event every or every other frame.
   <br> If user space test this kind of content, driver sent event on every or every other frame -&gt; then user space check each capture frame is better. But most time, this case will not happen
   hverkuil: Hmm, I posted several patches to linux-media, but none arrived. And I don't see any new messages since the daily build cron job.
   ***: prabhakarlad has left
   headless: [    1.292322] vsp1 fe928000.vsp1: unsupported IP version 0x01011201
   <br> [    1.298628] vsp1 fe930000.vsp1: unsupported IP version 0x01011301
   <br> [    1.304884] vsp1 fe938000.vsp1: unsupported IP version 0x01011301
   <br> <u>pinchartl</u>: you only used VSP1 driver on gen3?
   <br> ah, they seem to be diff even within gen2...
   <br> and the IP version is undocumented in gen2 :-/
   <br> and gen3 as well...
   <br> ah, /away
   <br> <u>pinchartl</u>: when adding FCP support, you broke gen2 VSP1 probing -- it fails w/-0ENOSYS now unless the FCP driver is enabled
   <br> -0
   ***: Renault has left "Au revoir"