Le mercredi 12 janvier 2022 à 22:04 +0300, Dmitry Osipenko a écrit : > > If so, I may suggest to drop this fallback, and propose an amendment to the > > spec, we can require flagging KEYFRAME/PFRAME/BFRAME on the OUTPUT buffer, > > this > > won't break any drivers/userland on other HW, and will benefit possibly > > other HW > > in the future. I can volunteer to patch GStreamer and LibreELEC ffmpeg if we > > agree to this. Not sure how it works for Chromium, or if it actually make > > sense > > to support here. > > > > (expecting feedback from Hans and Ezequiel here) > > Amending the spec will be great, although it's not clear how to flag > frame that consists of slices having different types. As per spec, all slices of a frame must be of the same type. In short, there is no problem, adding new flags to the decode_params.flags is fine, and is backward compatible. I had a second thought that I'd probably prefer this over using the v4l2_buffer flags, but either way seems backward compatible. In H264, but also other CODEC, slices are have two types of parameters, some of the parameters are invariant between slices, but still duplicated so you can decode some of the frame, even if the very first slice is lost. We tried our best to place all the slice invariant parameters in decode_params to keep the slice_params as small as we could. regards, Nicolas
