18.01.2022 05:43, Nicolas Dufresne пишет: > 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. Could you please give a direct reference to the spec? (chapter / page or provide quote) I'm vaguely recalling that x264 encoder was able to generate such frames.
