<ndufresne>
have you notice AdapterMemPalloc(nMemSizeC*2);
<ndufresne>
that code is...well
<jernej>
yeah, there's many weird things
<jernej>
anyway, I think you're right
<jernej>
it doesn't make sense to have last row halved
<ndufresne>
in gst I convert to number of tiles, I think its less error prone, or perhaps its just my way to think
<ndufresne>
btw, I apparenlty never finished interlaced support
<ndufresne>
split field interlacing more precisely
<jernej>
I noticed the orher day :)
<jernej>
*other
<jernej>
I forgot to mention
<ndufresne>
so now I at least got the code so that first field is held in the vb queue
<ndufresne>
but I see lots of artifact, so working on that now
<ndufresne>
I think ffmpeg still requeue
<ndufresne>
79/135, so gained 3, but also removed a lot of decode errors (now it's bad checksum)
<jernej>
note that you always mark reference as "frame"
<jernej>
for interlaced frames, you have to correctly mark as top/bottom
<jernej>
in reference lists 0 and 1
<ndufresne>
not surprising, considering this was never implemented, that's my obvious next step
<ndufresne>
fixing paramters is way easier then fixing queue/hold issues
<jernej>
true, that's why we took easy approach for ffmpeg - I expect a lot of work making it more async
<ndufresne>
I'm kind of happy to finally finish this, I knew h264 was incomplete, and never had time to finish that properly
<ndufresne>
my worry about the hold flag, is that I don't know how to "un-hold" it, e.g. in live streaming, we could loose a field over the network
<jernej>
hold flag is just an optimization
<jernej>
it worked fine before it with requeueing capture buffer
<ndufresne>
but as gst implement render delays, I really need it
<jernej>
but that disables async optimizations
<jernej>
or not
<jernej>
can be same buffer queued multiple times?
<ndufresne>
you can queue the second field before you have dequeued the decoded picture for the first field
<ndufresne>
* you can't
<jernej>
I guess that would work if it is DMA-BUF
<ndufresne>
so without hold flag, you operate in lock step
<ndufresne>
yeah, if you have dmabuf import path (which I don't have implemented here, in fact I would not know were to allocate the dmabuf from
<jernej>
ffmpeg holds hw context
<jernej>
in our case, handle to drm device, which can allocate dumb buffers
<ndufresne>
yeah, you can cheat the dumb allocator to respect v4l2 sizeimage (for padding needs)
<ndufresne>
drivers need not to be buggy and include MV and other HW specific buffer size into sizeimage of course
<ndufresne>
as discussed with ez, this has not be validated on any of the drivers yet, we wanted to make a PoC with dmabuf-heap, which would have allowed testing this
<jernej>
can't you get required sizeimage for dma-buf imported buffers?
<ndufresne>
in gst, we use the dumb allocation with width=1, height=sizeimage ;-D
<ndufresne>
its the other way around, you have to tell your allocate the sizeimage needed by your importer
<ndufresne>
the dmabuf is pre-allocated (unlike some other OS were you get a handle from the exporter, but it get lazily allocated by an importer trigger)
<ndufresne>
that basically forces driver to be explicit
<jernej>
let me check something
<jernej>
if you call VIDIOC_REQBUFS with V4L2_MEMORY_DMABUF type, you actually get "empty" capture buffers with properly set sizeimage, right?
<jernej>
you assign dma-buf handle to a capture buffer when you enqueue it, right?
<jernej>
so, imo, you could first allocate V4L2_MEMORY_DMABUF capture buffers, read buffer info to get sizeimage and then allocate DRM dumb buffers according to sizeimage
<jernej>
and just before you enqueue it, you set dma-buf fd into buffer structure
<ndufresne>
jernej: well, sizeimage is returned by VIDIOC_S_FMT
<jernej>
ah, true
<jernej>
even easier
<ndufresne>
so you simply do S_FMT, and then allocate dump, and then REQBUF for dmabuf import and import them
<ndufresne>
it's straight forward imho, just not implemented by anyone apparently
<ndufresne>
dumb or dmabuf-head (second one seems cleaner approach)
<ndufresne>
I think Khodi could be a nice candidate for that
<ndufresne>
ok, so in the latest gst DPB, the picture are duplicate per field, so that when they make it to ref list, we know if we refer to TOP or Bottom, now I just need to translate GstH264PictureField in the v4l2 equivalent
<ndufresne>
the DPB filling does not look quite right either ... but after lunch
<jernej>
well, if there is no reason to allocate buffers manually, why do it?
<jernej>
btw, Cedrus has an issue on 32-bit kernels with vmalloc space, especially when decoding 4k videos
<jernej>
I guess adding DMA_ATTR_NO_KERNEL_MAPPING flag to both queues would help