VEA unittest's keyframe validation is ambiguous with V4L2 |
|||
Issue descriptionThe VEA unittest checks whether keyframes are produced as expected by the encoder: - On one side, the VEA unittest considers that a frame is a keyframe is a NAL of type IDR is encountered. - On the other side, the V4L2 VEA considers a keyframe is produced if the buffer returned by DQBUF has the V4L2_BUF_FLAG_KEYFRAME flag set. But according the V4L2's documentation, "It may be set by video capture devices when the buffer contains a compressed image which is a key frame (or field), i. e. can be decompressed on its own. Also known as an I-frame." This creates a situation where the V4L2 VEA can receive a non-IDR I-frame which it will consider as a keyframe. But the VEA unittest will consider this same frame as non-keyframe, making the test fail. We can fix this by making the VEA unittest consider all I-frames to be keyframes, but this may not be the desired result if Chrome's definition of a keyframe is a frame we can seek to. Another way to fix this is to request V4L2 drivers to always produce IDR I-frames.
,
Jul 31
Clarified what we want with Pawel: A V4L2 keyframe should be an IDR frame (i.e. no previous frame data is required to decode the stream from here). But changing the V4L2 definition to that may break existing programs, and will leave us without a way to signal non-IDR iframes. Here are the current frame flags: /* Image is a keyframe (I-frame) */ #define V4L2_BUF_FLAG_KEYFRAME 0x00000008 /* Image is a P-frame */ #define V4L2_BUF_FLAG_PFRAME 0x00000010 /* Image is a B-frame */ #define V4L2_BUF_FLAG_BFRAME 0x00000020 So for compatibility, we may want to keep the KEYFRAME == IFRAME meaning, and add a new flag for IDR frames which Chromium would test against instead of the current KEYFRAME.
,
Aug 1
,
Aug 1
It sounds like we indeed should have a flag for IDRFRAME, especially since V4L2_BUF_FLAG_KEYFRAME is explicitly said to be for I-frames in the documentation. However, I'm not sure if existing hardware can distinguish between both (neither s5p-mfc nor mtk-vcodec seem to be able to do so), so we might still need to live with reporting both I and IDR as V4L2_BUF_FLAG_KEYFRAME by some encoders. |
|||
►
Sign in to add a comment |
|||
Comment 1 by acourbot@chromium.org
, Jul 30