V4L2 decoder failed in resolution change during decoding

[Hsia-Jun Li]

Hello Nicolas

We meet a bug from  !4437, if the video have multiple sequences or we 
could simple call it would lead to resolution change many times.

How this bug happens is below, I believe the driver follows 
Memory-to-Memory Stateful Video Decoder Interface.

1. seq 1 last frame N

and frame N is in its display order

2. hardware begin to process next input buffer

3. hardware found a new seq

4. driver send out V4L2_EVENT_SRC_CH_RESOLUTION event

5. driver dequeue a buffer which bytesued = 0 in all its planes and 
V4L2_BUF_FLAG_LAST flag.

If gst_v4l2_video_dec_loop() dequeue the CAPTURE pool in both step 4 and 5.

It would pause the srcpad thread while the self->output_flow would be 
GST_V4L2_FLOW_LAST_BUFFER (GST_FLOW_CUSTOM_SUCCESS). That would cause 
the gst_v4l2_video_dec_handle_frame() all reminded buffer.


In my  !3456, this won't  happen. If you could confirm this bug, I would 
create an issue(or update #1149) in the gitlab.

Besides, there are several things I would like to improve v4l2dec, like 
#2023, #2024 and !3537.

All those related to the v4l2 caps probing, if that is ok I would begin 
my work on writing this.

Also I think the way we handle the buffer from MMAP allocator is not 
good, it would lead to memory copy as always. Some downstream could 
accept DMA buffer even they don't support the DMA buffer allocator, in 
performance evaluation, we would use a component like fakesink, even the 
buffer can't be read through memory mapping is not a matter, fakesink 
would not read it at all.

Could I change this buffer mechanism? If it is possible, I would like to 
do that after my proposal for v4l2 pix and buffer ext APIs.


Sincerely

-- 
Hsia-Jun(Randy) Li