Hi,
[adding Stanimir for some insight, venus also has a decoder h.264 level
control]
On Mon, 2020-07-20 at 12:09 -0400, Nicolas Dufresne wrote:
> Le vendredi 17 juillet 2020 à 09:48 +0200, Philipp Zabel a écrit :
> > Hi Ezequiel, Nicolas,
> >
> > On Fri, 2020-07-17 at 00:49 -0300, Ezequiel Garcia wrote:
> > > From: Nicolas Dufresne <nicolas.dufresne@xxxxxxxxxxxxx>
> > >
> > > This add H264 level 4.1, 4.2 and 5.0 to the list of supported formats.
> > > While the hardware does not fully support these levels, it do support
> > > most of them.
> >
> > Could you clarify this? As far as I understand the hardware supports
> > maximum frame size requirement for up to level 4.2 (8704 macroblocks),
> > but not 5.0, and at least the implementation on i.MX6 does not support
> > the max encoding speed requirements for levels 4.1 and higher.
[...]
>
> So do you have an opinion on the way forward ? Personally I like the
> idea of giving the list of level_idc that won't cause the parser to
> reject it, and leave it to the user to validate the
> Resolution/Framerate seperatly, we have the V4L2 API for that. Let me
> know, as we'll use that for V2.
My opinion was that for decoders the possible values of the
V4L2_CID_MPEG_VIDEO_H264_LEVEL control should reflect the h.264 levels
that the decoder can actually decode in real-time. Otherwise we are
effectively ignoring the MaxMBPS and MaxBR properties of the level,
which makes the control useless for negotiation.
But I am beginning to think that I am wrong. The level control is set to
the level of the stream after parsing the stream header, so arguably it
must be possible to set it to anything that can be decoded at all, real-
time or not.
Further, the documentation says nothing about this. It doesn't even
mention decoders:
``V4L2_CID_MPEG_VIDEO_H264_LEVEL``
(enum)
enum v4l2_mpeg_video_h264_level -
The level information for the H264 video elementary stream.
Applicable to the H264 encoder. Possible values are:
[...]
So at the moment I would tend towards expanding the list of supported
formats to 4.2, even though we can't decoder > 4.0 in real-time on
i.MX6.
Should we add a note to the V4L2_CID_MPEG_VIDEO_H264_LEVEL documentation
that this is applicable to H264 decoders as well, set by the decoder
after parsing the SPS, and that the list of levels this control can be
set to does not guarantee real-time capability at each level?
regards
Philipp
