[11:50] <svarbanov> hverkuil, Could you take a look at https://patchwork.linuxtv.org/project/linux-media/list/?series=5331
[12:01] <hverkuil> svarbanov: done
[12:14] <hverkuil> svarbanov: also reviewed intra-refresh control series
[12:20] <svarbanov> hverkuil, Thanks!
[17:33] <mriesch> pinchartl: hello. i am seeing frequent "Dropping payload (out of sync)" debug messages when my custom UVC device is streaming. apparently there are USB packets but the struct uvc_buffer *buf is NULL. does this mean the host application is too slow or something along those lines?
[17:35] <mriesch> in principle, the custom uvc device works fine. the messages seem to appear when the data to be transferred is large, but this is rather a feeling
[17:43] <pinchartl> mriesch: it means that the packet received from the device has an incorrect FID
[17:43] <pinchartl> the FID is supposed to toggle for each frame
[17:44] <pinchartl> if the driver receives a packet with the previous FID after completing the current buffer, it drops it
[18:23] <_ds_> Just got an August DVB-T210. The driver recognises it as “MyGica Mini DVB-(T/T2/C) USB Stick T230C v2”  -  from the linuxtv wiki, was expecting T230 instead.
[18:25] <mriesch> pinchartl: OK...i'll check that once more. does this cause the buf variable to be null?
[18:26] <mriesch> because i added a counter and the "missing" packages are exactly those that have been dropped due to buf being null
[18:53] <pinchartl> mriesch: I can't rule out a bug that would cause a synchronization to be incorrectly flagged when a buffer is missing
[18:53] <pinchartl> actually it likely happens
[18:53] <pinchartl> if a buffer is missing, the FID of the packet is recorded
[18:54] <pinchartl> and I think the driver then waits for the FID to toggle when a new buffer is available
[18:54] <pinchartl> otherwise the buffer would be filled with the end of the previous image
[18:54] <pinchartl> it's possibly why it happens
[18:54] <pinchartl> but I haven't looked at that code for a long time, so don't trust me blindly on this :-)
[19:09] <mriesch> pinchartl: but how can a buffer be missing? i could imagine that v4l2 provides empty buffers and lets the uvc code fill them. but i am pretty new to this
[19:17] <ndufresne> hverkuil: just dropping the idea, we started drafting an AV1 stateless decoder API, and to minimally test our stuff, we aimed at writing a stub driver, with more discussion, we believe stubs drivers are possible for stateless decoder (no reordering, just need perhaps a TPG for the result) and it would allow quite a lot of testing, notably testing
[19:17] <ndufresne> crossvm integration in chromeos and later on virtio-video implementation
[19:18] <ndufresne> It would be like vcodec, but stateless (with a topology) and would produce output disregarding input bytes
[19:18] <mriesch> pinchartl: maybe increasing the buffer queue is worth a shot?
[19:48] <pinchartl> mriesch: buffers will be missing if the application doesn't provide them :-)
[19:48] <pinchartl> how many buffers does your application use ?
[20:08] <hverkuil> ndufresne: sounds interesting.
[20:10] <ndufresne> I think I'll let Daniel give it a try directly implementing that stub in vicodec, as it's already a stateless decoder, it should be faster, and we'll see how it looks like, and then it should be straighforward to add VP8, H264, and other upcoming things
[20:23] <hverkuil> ndufresne: It's not a good idea to put this in vicodec. It doesn't belong there. It's a driver in its own right. vistateless perhaps?
[20:24] <ndufresne> isn't it going to be very very similar to vicodec ?
[20:24] <ndufresne> except that it's a stub ( the resulting images have no meaning)
[20:25] <ndufresne> I was thinking that since vicodec already support FWHT in stateless mode (I think ?) it would be much smaller work to just add more formats
[20:25] <ndufresne> but I haven't looked at the code really
[20:26] <ndufresne> hverkuil: we can make a new driver too, vislcodec (sl for stateless) ?
[20:26] <ndufresne> or perhaps something with "decode" in it, since it will only ever support decoding
[20:29] <hverkuil> vicodec is really for FWHT, adding stub stateless decoders to that makes it quite messy since FWHT is a fully implemented codec and the others are just stubs. Rather weird and unexpected.
[20:29] <ndufresne> poor name is it then vicodec, too generic ;-D
[20:30] <ndufresne> but ok, we'll make a new driver
[20:30] <hverkuil> Since the stub driver will ignore the input it can be a lot simpler as well.
[20:31] <hverkuil> Feel free to copy whatever you need from vicodec :-)
[20:31] <ndufresne> the processing will be very simple, we just need to collect the buffers and the request and complete them
[20:31] <ndufresne> well, perhaps pass the capture buffer through a TPG if we want some fancyness there
[20:32] <ndufresne> or at least clear them out so they don't contain random data
[20:32] <hverkuil> TPG would be nice, esp. since you can add 'OSD' text to it, very helpful. I certainly recommend doing that.
[20:32] <ndufresne> we still need to implement the relatively generic handling of the "header" control, which is used to determin the default capture format
[20:32] <ndufresne> oh, OSD would be amazing, I'd place the cooki (timestamp) in
[20:33] <hverkuil> It's what vivid does. It's pretty easy.
[20:33] <ndufresne> some testing feature, i would add lookup and warning for reference frames (e.g. warn if a reference frame is missing)