11:02 -!- sailus [~sailus@nblzone-211-213.nblnetworks.fi] has joined #v4l2codecs
11:02 [Users #v4l2codecs]
11:02 [@kdebski] [ mszyprow] [ sailus] [ snawrocki] 
11:02 -!- Irssi: #v4l2codecs: Total of 4 nicks [1 ops, 0 halfops, 0 voices, 3 
          normal]
11:02 -!- Channel #v4l2codecs created Thu Dec  1 10:53:39 2011
11:02 -!- Irssi: Join to #v4l2codecs was synced in 1 secs
11:02 < sailus> Morning!
11:02 <@kdebski> Hi Sakari
11:03 < sailus> Hi, Kamil!
11:03 <@kdebski> I have also invited Marek ans Sylwester to this chat. Marek 
                 might have some insights on videobuf2 ans Sylwester is also 
                 working with OpenMAX currently
11:04 < sailus> Sounds good.
11:04 < mszyprow> Morning :)
11:04 < sailus> Hi, Marek and Sylwester! :-)
11:05 <@kdebski> we'lll give a few minutes for Sebastian to join
11:07 <@kdebski> Sakrai, are you planning to do some work with codecs in the 
                 future? I mean creating a driver with v4l2, or using an 
                 existing v4l2 driver? I am just curious :)
11:08 < sailus> Well, I'm mostly interested that the interface supports codec 
                type devices well.
11:08 < sailus> I probably won't have time to work on codecs myself.
11:09 < sailus> I wish I did, though. :-)
11:10 < sailus> If the V4L2 supports codecs well enough, that would make it 
                possible to have more or less generic user space using them.
11:10 < sailus> E.g. a generic GStreamer V4L2 codec plugin.
11:10 <@kdebski> Ok, I  thought you might need information to work on a new 
                 driver. I agree, it is important to get it right :)
11:10 < sailus> Some codecs won't do all the processing by themselves so extra 
                user space libraries will be required.
11:11 -!- slomo [~slomo@pdbn-5d82564d.pool.mediaWays.net] has joined #v4l2codecs
11:11 < sailus> This would also make it easy to support both GStreamer and 
                OpenMAX (if you need it) natively without extra overhead.
11:11 < slomo> hi everybody, sorry for being late
11:12 <@kdebski> Yes, I also think that a general GStreamer plugin for v4l2 
                 codecs would be great.
11:12 <@kdebski> Hi, Sebastian! Maybe I should introduce other people that are 
                 in this channel.
--- Log opened Thu Dec 01 11:13:07 2011
11:13 -!- Irssi: Log file v4l2-chat.txt opened
11:13 #v4l2codecs: <@kdebski> Marek is working with videobuf2 in v4l2, so he could give use some insights, comments on using the memory.
11:14 #v4l2codecs: <@kdebski> Sylwester has created a driver for the image processing module on out SoC.
11:14 #v4l2codecs: <@kdebski> Sakari is working for Nokia with v4l2 drivers.
11:14 #v4l2codecs: < sailus> lpinchart is online; I'll ask him if he's like to join ad-hoc.
11:14 #v4l2codecs: <@kdebski> sailus: good
11:14 #v4l2codecs: < sailus> s/he's/he'd/
11:15 #v4l2codecs: < slomo> kdebski: thanks
11:16 -!- pinchartl [~pinchartl@perceval.ideasonboard.com] has joined #v4l2codecs
11:16 #v4l2codecs: < snawrocki> hi everyone :)
11:16 #v4l2codecs: < pinchartl> hi
11:16 #v4l2codecs: < sailus> pinchartl: Hi!
11:16 #v4l2codecs: < pinchartl> secret meeting ? :-)
11:16 #v4l2codecs: < snawrocki> :D
11:16 #v4l2codecs: < slomo> hi pinchartl 
11:16 #v4l2codecs: < pinchartl> as I've just told Sakari, I'm in a telco, so I might be slow to answer
11:16 #v4l2codecs: < snawrocki> not so secret as it seems ;)
11:16 #v4l2codecs: < sailus> pinchartl: Not so secret, just a very initial one.
11:17 #v4l2codecs: <@kdebski> I think that it would be great to create a lugin for GStreamer that uses V4L2 codec interface. We've talked for a while about this at the conference. I think you're comments could be important.
11:17 #v4l2codecs: < pinchartl> slomo: hi. I don't think we've met
11:17 #v4l2codecs: <@kdebski> s/you're/your/
11:19 #v4l2codecs: <@kdebski> slomo: I remember that the main problem was memory hadling. And changing the number/size of buffers during streaming.
11:19 #v4l2codecs: < slomo> kdebski: definitely a good idea (or as part of the existing v4l2 plugin to reuse some of the code, e.g. the bufferpool). i've also some news for you about the problems we talked about at the conference (the fixed, pre-allocated number of buffers. will be possible to solve in gstreamer 0.11 soon)
11:20 #v4l2codecs: <@kdebski> oh, that is good news in deed.
11:21 #v4l2codecs: < pinchartl> could someone briefly describe why those are issues ?
11:22 #v4l2codecs: < slomo> pinchartl: it's a problem in generic gstreamer (0.10) pipelines, if you have to allocate a fixed number of buffers and can't add/remove buffers later
11:23 #linaro-multimedia: < ibiris> benjiG: great!!!
11:23 #v4l2codecs: < sailus> slomo: Are there other issues?
11:23 #v4l2codecs: < sailus> I think it'd be nice to have a list of things that currently need to be supported, so we can check if something is missing in V4L2.
11:24 #v4l2codecs: < slomo> sailus: i could prepare such a list later and send it by mail... there are some more issues
11:25 #v4l2codecs: <@kdebski> I thought that for now i could do the following when the buffer paremeters are going to be changed. The plugin would handle this by creating  a new codec context with new buffers. Then pass the new buffers to GStreamer and slowly discard the old ones. But if this issue is going to be addressed in gstreamer 0.11 then  we could skip this hack.
11:25 #v4l2codecs: <@kdebski> slomo: such a list would be great
11:25 #v4l2codecs: < sailus> slomo: Ack.
11:26 #v4l2codecs: < slomo> kdebski: that's a different problem, if the codec parameters change you could still have old buffers downstream and in use but would already like to start handling the new input without waiting for the old buffers to be unused again (otherwise you will get stalled pipelines)
11:27 #v4l2codecs: < sailus> slomo: What kind of things are there in the codec parameters?
11:27 #v4l2codecs: < slomo> sailus: main problem should be a resolution change
11:27 #v4l2codecs: <@kdebski> slomo: ok, so either way we need to keep old buffers.
11:29 #v4l2codecs: < slomo> yes
11:29 #v4l2codecs: < pinchartl> if we use USERPTR that shouldn't be a big issue
11:29 #v4l2codecs: < slomo> kdebski: a new codec context would be a possible solution but that requires support for multiple contexts by the hardware
11:29 #v4l2codecs: < pinchartl> you can replace the userspace buffer associated with a V4L2 buffer at runtime
11:29 #v4l2codecs: < sailus> slomo: Can you always know what kind of resolution does the buffer have when you push it to the device for decoding?
11:30 #v4l2codecs: < pinchartl> there's a cost to that though, so it shouldn't be done every time you queue a buffer
11:30 #v4l2codecs: < slomo> pinchartl: sounds good but doesn't this fail if the hardware needs special memory that needs to be allocated in a special way?
11:31 #v4l2codecs: <@kdebski> pinchartl: the problem is the hardware. in our SoC the number of buffers and their addresses are fixed when initializing decodng.
11:31 #v4l2codecs: < slomo> sailus: with some effort, sure
11:31 #v4l2codecs: < pinchartl> slomo: in that case it can fail, yes
11:31 #v4l2codecs: < sailus> Is this something that you might want to do when queueing a new buffer to find out whether it has a different resolution?
11:31 #v4l2codecs: < pinchartl> kdebski: ok
11:31 #v4l2codecs: < slomo> pinchartl: so that's not really a generic solution unfortunately
11:32 #v4l2codecs: <@kdebski> after the resolution change you can setup a new set of buffer, but when streaming with one resolution then the pool of buffers is fixed.
11:32 #v4l2codecs: <@kdebski> (set of buffes)
11:32 #v4l2codecs: <@kdebski> (sorry, I am bad in typing: set of buffers)
11:33 #v4l2codecs: < sailus> Well, or, you could just return an error in that case to the user space.
11:34 #v4l2codecs: < sailus> Then the correct format could be set and the decoding could continue normally.
11:34 #v4l2codecs: < sailus> This might involve allocating new buffers.
11:34 #v4l2codecs: < sailus> Depending on the required buffer size of the new buffesr.
11:35 #v4l2codecs: < sailus> kdebski: The buffers can have a different resolution as long as the buffer is large enough to contain the data.
11:35 #v4l2codecs: < sailus> kdebski: Ignore that. :-)
11:36 #v4l2codecs: <@kdebski> You mean that the buffers are fixed at init and we use USERPTR, but when the user supplies a buffer that has not been setup we return an error. Am I getting it right?
11:36 #v4l2codecs: < slomo> how would that help? you will still need to be able to pass new buffers when the resolution changes?
11:36 #v4l2codecs: < sailus> kdebski: When the user queues an encoded buffer the resolution of which is different from what is set up to the device, an error is returned.
11:37 #v4l2codecs: < sailus> slomo: It helps so that you can know the resolution has changed and you can set up new buffers for the new resolution if needed.
11:37 #v4l2codecs: < sailus> slomo: And also change the resolution for the device.
11:38 #v4l2codecs: < slomo> sailus: would that error be different from other errors, i.e. some kind of settings-changed "error"?
11:38 #v4l2codecs: < sailus> I think it would have to be.
11:39 #v4l2codecs: < slomo> ok, then it's useful... sure
11:39 #v4l2codecs: < sailus> It would tell that "your format is wrong".
11:39 #v4l2codecs: <@kdebski> How can we distinguish it from a usual error? Now I am detecting it by passing an capture  buffer (with decoded frame drom the decoder) with no error but with data size set to 0.
11:40 #v4l2codecs: < sailus> slomo, kdebski: A different error code?
11:40 #v4l2codecs: < pinchartl> sailus: or a buffer flag ?
11:41 #v4l2codecs: <@kdebski> yes, a buffer flag could be good.
11:41 #v4l2codecs: < sailus> pinchartl: What would the buffer flag tell? The decoding has not been possible since the format of the device is not correct.
11:41 #v4l2codecs: < slomo> imho a new error code would be more intuitive... but that's really an implementation detail
11:42 #v4l2codecs: < sailus> Or should the new format be automatically set on the device?
11:42 #v4l2codecs: < sailus> I mean, if the new format can be figured out of the decoded stream.
11:43 #v4l2codecs: < slomo> you still need to be able to tell the application that something has changed (and maybe new buffers must be allocated)
11:43 #linaro-multimedia: < benjiG> ibiris: I'm block by an issue in lava-tool, I can register myself because lava-tool doesn't handle correctly corporate proxy
11:43 #v4l2codecs: <@kdebski> The MFC driver gets the infromation about new format from the stream.
11:43 #v4l2codecs: < sailus> kdebski: MFC?
11:43 #v4l2codecs: < pinchartl> sailus: yes it's an implementation detail. if we can find a proper error code that should be ok as well
11:44 #linaro-multimedia: < benjiG> ibiris: I have log a bug for that: https://bugs.launchpad.net/lava-tool/+bug/898174 and zyag is taking care of it
11:44 #v4l2codecs: <@kdebski> s5p-mfc - the doced driver for Multi Format Codec module on our SoC
11:44 #linaro-multimedia: < ibiris> benjiG: thanks!
11:44 #v4l2codecs: <@kdebski> s/doced/codec/
11:45 #v4l2codecs: < sailus> The buffer flag has the upside that QBUF won't have to wait to figure out whether the buffer decoding will not fail because of wrong resolution.
11:45 #v4l2codecs: < sailus> It may take a while before that happens, and QBUF must sleep during that time, if we go with the error code.
11:47 #v4l2codecs: < sailus> V4L2_BUF_FLAG_ERROR | V4L2_BUF_FLAG_WRONGFORMAT?
11:48 #v4l2codecs: < sailus> We do have flags for different kinds of frames, so the approach seems relatively sound to me.
11:48 #v4l2codecs: < sailus> What do you think?
11:49 #v4l2codecs: <@kdebski> After the resolution change the application has to unmap the current buffers, reqbufs(0) to free then, then reqbufs with new size and number. If we need the old buffer to be kept a new context could be setup.
11:49 #v4l2codecs: < slomo> sailus: so you would return a 0-byte buffer with this flag? or how is this going to work?
11:49 #v4l2codecs: <@kdebski> Also - to setup a new context, we need to know which compressed buffer with 
11:49 #v4l2codecs: < sailus> kdebski: only if the new size is bigger, reallocation has to be made.
11:50 #v4l2codecs: <@kdebski> has caused the resolution change, as it contains the header with new stream formats.
11:50 #v4l2codecs: < sailus> slomo: You'd get the two flags on DQBUF if the resolution has changed.
11:50 #v4l2codecs: < sailus> slomo: How would that sound like?
11:51 #v4l2codecs: <@kdebski> ok, but which side? is it the capture buffer (wich decoded frame), or the output buffer ( wich the encoded frame that caused the resolution change)
11:51 #v4l2codecs: < sailus> kdebski: Could it be both?
11:52 #v4l2codecs: < sailus> The new capture resolution could be set automatically.
11:53 #v4l2codecs: <@kdebski> yes, I think this could work. This way the application would know both - the encoded stream buffer that has caused the resolution change and which is the first buffer that does not fit.
11:53 #v4l2codecs: < pinchartl> kdebski: I would say on the capture side. if my understanding is correct there's no need to reallocate buffers on the encoded side, right ?
11:53 #v4l2codecs: < sailus> There might be alignment requirements that the user might want to impose, so it might not be a good idea to set the resolution automatically and perform the decoding even if the buffer is large enough.
11:54 #v4l2codecs: <@kdebski> sailus:  in case the resolution is decreased then how the app should now about this? just V4L2_BUF_FLAG_WRONGFORMAT without the error flag? 
11:54 #v4l2codecs: < sailus> kdebski: Should we allow the device to come up with a new format?
11:54 #v4l2codecs: < sailus> kdebski: I could imagine the user might want to have certain alignment for bytesperline.
11:55 #v4l2codecs: < sailus> kdebski: The device driver can't know that.
11:55 #v4l2codecs: <@kdebski> sailus: you need to tell the app that the resolution has changed so it can change he scaling for  example
11:55 #v4l2codecs: <@kdebski> the device will know the resolution
11:56 #v4l2codecs: < pinchartl> kdebski: I would still return both the error and the wrong format flag, until the application reconfigures the capture device with the new format
11:56 #v4l2codecs: < sailus> pinchartl: I agree.
11:56 #v4l2codecs: < slomo> agreed too
11:56 #v4l2codecs: <@kdebski> pinchartl: yes, you're right
11:58 #v4l2codecs: <@kdebski> pinchartl: in codecs the format is set by the device so after the resolution change the application will run G_FMT to get the new format and that's it
11:58 #v4l2codecs: <@kdebski> pinchartl: no need to setup the format, I think
11:59 #v4l2codecs: < sailus> kdebski: Except if the user has an alignment requirement.
11:59 #v4l2codecs: < sailus> Say, the next hardware block which is used to process the image could have an alignment requirement of 64 whereas the decoder could only have 16.
11:59 #v4l2codecs: < pinchartl> kdebski: right, but the application still needs to acknowledge that somehow
12:00 #v4l2codecs: < sailus> kdebski: Line alignment.
12:00 #v4l2codecs: <@kdebski> sailus: in our HW you have no chance to change the codec alignment etc. it is the part that has no possibility of format adjustment
12:01 #v4l2codecs: <@kdebski> sailus: I agree that there can be hw taht allows this
12:01 #v4l2codecs: <@kdebski> then, how would you see this in the API?
12:01 #v4l2codecs: < sailus> kdebski: For example the OMAP 3 ISP does require such alignment to be done and also the capture buffer alignment can be configured.
12:02 #v4l2codecs: < sailus> kdebski: you do S_FMT with bytesperline that is aligned correctly. Otherwise the format is the same.
12:02 #v4l2codecs: <@kdebski> ok, so you say that first do a G_FMT and then S_FMT with new bytesperline ?
12:02 #v4l2codecs: < sailus> Yes.
12:03 #v4l2codecs: <@kdebski> that could be done, no problem
12:03 #v4l2codecs: < sailus> If you don't have special requirements, you don't need to do the S_FMT.
12:04 #v4l2codecs: <@kdebski> the other issue I see here - in case when the resolution is increased. How could we keep the old buffesr?
12:04 #v4l2codecs: <@kdebski> in my implementation, when the resolution is changed alll old buffers are unmapped and freed
12:04 #v4l2codecs: < sailus> You have to CREATE_BUFS new buffers.
12:05 #v4l2codecs: < sailus> And queue them.
12:05 #v4l2codecs: <@kdebski> the solution I see is to setup a new codec context and then discard the old ones after the plugin/aplpication uses all of them
12:05 #v4l2codecs: < sailus> You could later free the old buffers but we'd need implementing DESTROY_BUFS for that.
12:05 #v4l2codecs: <@kdebski> ok, is there a way to remove old buffers?
12:06 #v4l2codecs: < pinchartl> sailus: maybe we should still mandata S_FMT. if the existing buffers are good enough, we need the driver to signal the hardware that it took the new format into account.
12:06 #v4l2codecs: < pinchartl> s/driver/application/ and s/hardware/driver/
12:06 #v4l2codecs: < sailus> pinchartl: Wouldn't that be done automatically?
12:07 #v4l2codecs: < sailus> The buffers have no format.
12:07 #v4l2codecs: < pinchartl> sailus: when the format changes the driver will return ERROR | WRONGFORMAT until the application signals that it knows about the new format
12:07 #v4l2codecs: < sailus> pinchartl: Until?
12:07 #v4l2codecs: < pinchartl> sailus: not until ? :-)
12:07 #v4l2codecs: < sailus> pinchartl: mem2mem devices process only one buffer at a time, don't they?
12:08 #v4l2codecs: <@kdebski> CREATE_BUFS to add new buffers and DESTROY_BUFS(not implemented yet) to remove the old ones. After resolution change a new set of buffers would be set in HW, and when old ones are used then return an error.
12:08 #v4l2codecs: <@kdebski> CREATE_BUFS can allocate a single buffer only?
12:09 #v4l2codecs: < sailus> kdebski: CREATE_BUFS takes the number of buffers to create.
12:09 #v4l2codecs: <@kdebski> sailus: good
12:09 #v4l2codecs: < pinchartl> kdebski: but what if the existing buffers are fine ? applications are not required to reallocate new buffers in that case, right ?
12:10 #v4l2codecs: < sailus> kdebski: USERPTR buffers (and future generic multimedia buffers) are allocated at first PREPARE_BUF or QBUF.
12:10 #v4l2codecs: < sailus> pinchartl: I agree.
12:10 #v4l2codecs: <@kdebski> sailus: I cannot use USERPTR as the buffer have crazy memory requirements.
12:11 #v4l2codecs: < sailus> pinchartl: It's a policy question whether you want to destroy your old and create new if you need smaller buffers than what you already have.
12:11 #v4l2codecs: < sailus> kdebski: Then you use MMAP buffers.
12:12 #v4l2codecs: < pinchartl> sailus: exactly, it's a policy question. if you decide not to allocate new buffers, how do you tell the driver so that it stops setting ERROR|WRONGFORMAT and returns decoded frames in the new resolution ?
12:12 #v4l2codecs: <@kdebski> I am not sure does the application has to notify the device that it has accepted the new format
12:13 #v4l2codecs: <@kdebski> when it gets a ERROR|WRONGFORMAT, then it know that it has to check the new format with G_FMT and adjust it with S_FMT (if needed, and possible in hw)
12:13 #v4l2codecs: < sailus> If the format changes, I assume that no buffers are used by the codec over the resolution change. I.e. the buffers of former resolution are not needed to decode the buffers of the new resolution.
12:14 #v4l2codecs: <@kdebski> yes
12:14 #v4l2codecs: < pinchartl> sailus: I'm talking about the capture side
12:14 #v4l2codecs: < pinchartl> all of a sudden the driver starts returning ERROR | WRONGFORMAT
12:14 #v4l2codecs: < pinchartl> the application needs to issue G_FMT
12:14 #v4l2codecs: < pinchartl> it then finds out that the buffer it uses are good enough, and decides not to reallocate them
12:15 #v4l2codecs: < pinchartl> how does it tell the driver to decode the new format to those buffers and stop returning ERROR | WRONGFORMAT ?
12:15 #v4l2codecs: < sailus> pinchartl: Would it be enough to issue G_FMT?
12:15 #v4l2codecs: < sailus> pinchartl: Wouldn't it need to requeue those buffers?
12:16 #v4l2codecs: < pinchartl> sailus: G_FMT is a possibility, but I'd rather avoid that. any other process/thread can issue G_FMT at any time, so it shouldn't have side effects
12:16 #v4l2codecs: < pinchartl> it would need to requeue the buffers, yes
12:16 #v4l2codecs: < pinchartl> so QBUF could be considered as an acknowledgement of the new format
12:16 #v4l2codecs: < sailus> pinchartl: Should we stop streaming in that case? I think it might be the most straightforward thing to do.
12:17 #v4l2codecs: < sailus> That would flush all the buffers from the queue.
12:17 #v4l2codecs: < pinchartl> wouldn't you likely lose decoded frames then ?
12:17 #v4l2codecs: < sailus> pinchartl: Why?
12:18 #v4l2codecs: <@kdebski> pinchartl: m2m devices are context specific, ao if you didn't share the filehandle with another process then their G_FMT means nothing to other contexts
12:18 #v4l2codecs: < sailus> I think we also should use the WRONGFORMAT flag in the OUTPUT queue so that the user would know which buffers need to be requeued at streaming restart.
12:18 #v4l2codecs: < sailus> Or this could be a different flag.
12:19 #v4l2codecs: <@kdebski> at the time when you got the WRONGFORMAT on the capture queue you have already dequeued all the buffer with the old resolution
12:19 #v4l2codecs: <@kdebski> sailus: totally agree
12:19 #v4l2codecs: < pinchartl> kdebski: another thread in the same process could still issue G_FMT. I'd rather avoid side-effects for GET ioctls
12:20 #v4l2codecs: < pinchartl> kdebski: right. and the codec engine hasn't started writing to the buffers with the new resolution
12:20 #v4l2codecs: <@kdebski> hm... yes, I see your point. GET should not change anything...
12:21 #v4l2codecs: < pinchartl> I'm not sure if QBUF is a safe way to ack the format change though
12:21 #v4l2codecs: < sailus> Once the buffers have finished with ERROR | WRONGFORMAT, the underlying OUTPUT buffers still have to be requeued to get decoded, right?
12:21 #v4l2codecs: < pinchartl> and application might use two threads, one that dequeues buffers and one that queues buffers
12:21 #v4l2codecs: < pinchartl> sailus: do they ?
12:21 #v4l2codecs: <@kdebski> on the other hand, shouldn't it be up to the application to read the new format? I mean we signal WRONGFORMAT once and the application should then read the new format
12:21 #v4l2codecs: < sailus> pinchartl: That's what I though. :-)
12:22 #v4l2codecs: < sailus> pinchartl: The device would just wait before the user prepares a new set of buffers for it during streaming?
12:22 #v4l2codecs: < sailus> pinchartl: Is this what you mean?
12:22 #v4l2codecs: < pinchartl> kdebski: in multi-threaded cases (think about gstreamer) it might be quite difficult to avoid race conditions if a single WRONGFORMAT needs to stop everything on userspace side. I think it would be better to explictly ack it
12:23 #v4l2codecs: < pinchartl> sailus: I'm not sure to follow you
12:23 #v4l2codecs: < pinchartl> on which side ?
12:23 #v4l2codecs: < sailus> On capture side.
12:23 #v4l2codecs: < sailus> I'm also trying to understand how you see this. :-)
12:24 #v4l2codecs: <@kdebski> pinchartl: so you recommend that the S_FMT would ack the change?
12:24 #v4l2codecs: < pinchartl> kdebski: I think so
12:24 #v4l2codecs: < pinchartl> sailus: on the capture side the application starts getting ERROR | WRONGFORMAT at some point
12:24 #v4l2codecs: < pinchartl> it then decides whether to allocate new buffers or keep the existing ones
12:25 #v4l2codecs: < pinchartl> it first reads the new format with G_FMT
12:25 #v4l2codecs: < pinchartl> then either frees the buffers, allocates the new ones and queues them
12:25 #v4l2codecs: < pinchartl> or keeps the existing buffers
12:26 #v4l2codecs: < pinchartl> the driver needs to be informed of when to stop issuing ERROR | WRONGFORMAT and resume decoding
12:26 #v4l2codecs: < sailus> pinchartl: Should the driver return just one such buffer?
12:26 #v4l2codecs: < sailus> If there are more, the format might change again.
12:26 #v4l2codecs: <@kdebski> pinchartl: I get it
12:27 #v4l2codecs: <@kdebski> sailus: the application might want to decide what to do if the resolution/number of required buffer has been decreased
12:27 #v4l2codecs: <@kdebski> if the policy is to use as little memory as possible then it might choose to allocate new smaller buffers
12:27 #v4l2codecs: < sailus> kdebski: But the second buffer might change the format again. Which one the driver should return, unless the format of the first buffer which caused WRONGFORMAT flag tobe set?
12:28 #v4l2codecs: < sailus> I think that if the application wishes to flush the buffer queue we could just require it to stop streaming altogether.
12:29 #v4l2codecs: < sailus> It does not change the interface a bit, as far as I see this.
12:29 #v4l2codecs: < pinchartl> sailus: but the application might not want to flush the queue
12:29 #v4l2codecs: <@kdebski> no, if the decoding process pauses when the resolution change request is received then only after you ack the resolution change you could get another resolution change request
12:29 #v4l2codecs: < sailus> Then it can proceed as you described above.
12:29 #v4l2codecs: < pinchartl> in that case it needs to tell the driver "I don't want to flush the queue, use the existing buffers and stop reporting ERROR | WRONGFORMAT"
12:29 #v4l2codecs: < sailus> One just needs to know which buffers need to be requeued at the OUTPUT queue.
12:30 #v4l2codecs: < pinchartl> sailus: I don't think you need to requeue anything on the OUTPUT queue
12:30 #v4l2codecs: < sailus> pinchartl: Even if you stop streaming?
12:30 #v4l2codecs: < pinchartl> sailus: even if you stop streaming on the capture side
12:30 #v4l2codecs: < sailus> pinchartl: I'm fine that with that S_FMT is used to tell the device it can proceed decoding.
12:30 #v4l2codecs: < pinchartl> I could be wrong though
12:31 #v4l2codecs: <@kdebski> usually the buffer queued at the OUTPUT contains both - the new header with new resolution and the first frame
12:31 #v4l2codecs: <@kdebski> so somehow it needs to be processed by the hardware again
12:32 #v4l2codecs: <@kdebski> currently I did it such that the buffer on the OUTPUT is not dequeued until it hasbeen fully processed
12:32 #v4l2codecs: < pinchartl> kdebski: I think that's a proper way to handle that situation. the buffer hasn't been fully processed it, so it can't be dequeued
12:32 #v4l2codecs: <@kdebski> sorry,skip my previous line
12:33 #v4l2codecs: <@kdebski> pinchartl: the problem that I had with this was that STREAMOFF was run
12:33 #v4l2codecs: <@kdebski> to change the buffers
12:33 #v4l2codecs: <@kdebski> but with the CREATE_BUFS/DESTROY_BUFS I think we could do it that way
12:34 #v4l2codecs: < sailus> pinchartl: I agree no streamoff is needed on OUTPUT queue in any case.
12:34 #v4l2codecs: < pinchartl> kdebski: streamoff would only occur on the capture side, right ?
12:34 #v4l2codecs: < sailus> But would it be just easier to force streamoff in CAPTURE queue when the format changes?
12:35 #v4l2codecs: < sailus> The hardware won't do anything until the user has acknowledged the new format anyway.
12:35 #v4l2codecs: < sailus> Stopping and starting streaming could be used to signal this.
12:35 #v4l2codecs: < sailus> At the same time there would be a convenient time to deal with the buffers if necessary.
12:35 #v4l2codecs: < sailus> What do you think?
12:36 #v4l2codecs: < sailus> (I might still choose to return an error code at DQBUF in the CAPTURE queue.)
12:36 #v4l2codecs: < sailus> ERANGE. :-)
12:36 #v4l2codecs: <@kdebski> yes... You're right - no need to touch the output side (it was only a problem if I wanted to keep the old buffers)
12:36 #v4l2codecs: < pinchartl> sailus: that looks good at first sight
12:37 #v4l2codecs: <@kdebski> yes, stopping streaming is a good mean to signal this.
12:40 #v4l2codecs: < sailus> Uh, are we now missing anything else than an RFC? :-) :-)
12:42 #v4l2codecs: <@kdebski> Ok, I'll try to sum up our chat and send an email to the linux-media list
12:42 #v4l2codecs: <@kdebski> then we could discuss it further (if necessary)
12:44 #v4l2codecs: < sailus> kdebski: Thanks in advance.
12:44 #v4l2codecs: < sailus> I guess we're done then, right?
12:45 #v4l2codecs: <@kdebski> one more thing we were discussing here - the maximum number of buffer in v4l2
12:45 #v4l2codecs: <@kdebski> isn;t it 32 ?
12:45 #v4l2codecs: < sailus> kdebski: That's in V4L1.
12:45 #v4l2codecs: < sailus> The V4L2 does not specify that.
12:46 #v4l2codecs: < sailus> videobuf2 implementation is limited to 32, I think, but that could easily be increased when necessary.
12:46 #v4l2codecs: < sailus> The maximum number of buffers is not visible to the user space.
12:46 #v4l2codecs: <@kdebski> yeah, that's the thing we were talking about
12:47 #v4l2codecs: < sailus> I think there's definitely some work in there once we implement DESTROY_BUFS.
12:47 #v4l2codecs: <@kdebski> yes.
12:48 #v4l2codecs: < sailus> We need to support sparse buffer ranges probably.
12:49 #v4l2codecs: <@kdebski> Yes it might be necessary.
12:50 #v4l2codecs: <@kdebski> Ok, so we're more less done. Thank you everyone for participation and comments. There should be a follow-up of this chat on the mailing list soon (liunx-media).
12:50 #v4l2codecs: < sailus> Thanks to everyone on my behalf as well!
12:52 #v4l2codecs: < pinchartl> you're welcome