On Sun, 02. Feb 12:30, Mark Thompson wrote:
> On 02/02/2020 01:33, Andriy Gelman wrote:
> > On Sat, 01. Feb 22:38, Mark Thompson wrote:
> >> On 19/01/2020 19:54, Andriy Gelman wrote:
> >>> From: Andriy Gelman <andriy.gel...@gmail.com>
> >>>
> >>> Hard coded parameters for qmin and qmax are currently used to initialize
> >>> v4l2_m2m device. This commit uses values from avctx->{qmin,qmax} if they
> >>> are set.
> >>>
> >>> Signed-off-by: Andriy Gelman <andriy.gel...@gmail.com>
> >>> ---
> >>> libavcodec/v4l2_m2m_enc.c | 33 +++++++++++++++++++++++++++++++--
> >>> 1 file changed, 31 insertions(+), 2 deletions(-)
> >>>
> >>> diff --git a/libavcodec/v4l2_m2m_enc.c b/libavcodec/v4l2_m2m_enc.c
> >>> index 8059e3bb48f..318be0d3379 100644
> >>> --- a/libavcodec/v4l2_m2m_enc.c
> >>> +++ b/libavcodec/v4l2_m2m_enc.c
> >>> @@ -31,10 +31,25 @@
> >>> #include "v4l2_context.h"
> >>> #include "v4l2_m2m.h"
> >>> #include "v4l2_fmt.h"
> >>> +#include "internal.h"
> >>>
> >>> #define MPEG_CID(x) V4L2_CID_MPEG_VIDEO_##x
> >>> #define MPEG_VIDEO(x) V4L2_MPEG_VIDEO_##x
> >>>
> >>> +#define CLIP_MIN_MAX(in, min_val, max_val, name, logctx) \
> >>> + do { \
> >>> + if ((in) < (min_val)) { \
> >>> + av_log((logctx), AV_LOG_WARNING, \
> >>> + "Adjusted: " name " (%d)\n", (min_val)); \
> >>> + in = min_val; \
> >>> + } \
> >>> + if ((in) > (max_val)) { \
> >>> + av_log((logctx), AV_LOG_WARNING, \
> >>> + "Adjusted: " name " (%d)\n", (max_val)); \
> >>> + (in) = (max_val); \
> >>> + } \
> >>> + } while (0)
> >>> +
> >>> static inline void v4l2_set_timeperframe(V4L2m2mContext *s, unsigned int
> >>> num, unsigned int den)
> >>> {
> >>> struct v4l2_streamparm parm = { 0 };
> >>> @@ -232,8 +247,15 @@ static int v4l2_prepare_encoder(V4L2m2mContext *s)
> >>> return 0;
> >>> }
> >>>
> >>> - if (qmin != avctx->qmin || qmax != avctx->qmax)
> >>> - av_log(avctx, AV_LOG_WARNING, "Encoder adjusted: qmin (%d), qmax
> >>> (%d)\n", qmin, qmax);
> >>> + if (avctx->qmin >= 0) {
> >>> + CLIP_MIN_MAX(avctx->qmin, qmin, qmax, "qmin", avctx);
> >>> + qmin = avctx->qmin;
> >>> + }
> >>> +
> >>> + if (avctx->qmax >= 0) {
> >>> + CLIP_MIN_MAX(avctx->qmax, qmin, qmax, "qmax", avctx);
> >>> + qmax = avctx->qmax;
> >>> + }
> >>>
> >>> v4l2_set_ext_ctrl(s, qmin_cid, qmin, "minimum video quantizer
> >>> scale");
> >>> v4l2_set_ext_ctrl(s, qmax_cid, qmax, "maximum video quantizer
> >>> scale");
> >>> @@ -349,6 +371,12 @@ static const AVOption options[] = {
> >>> { NULL },
> >>> };
> >>>
> >>> +static const AVCodecDefault v4l2_m2m_defaults[] = {
> >>> + { "qmin", "-1" },
> >>> + { "qmax", "-1" },
> >>> + { NULL },
> >>> +};
> >>> +
> >>> #define M2MENC_CLASS(NAME) \
> >>> static const AVClass v4l2_m2m_ ## NAME ## _enc_class = { \
> >>> .class_name = #NAME "_v4l2m2m_encoder", \
> >>> @@ -370,6 +398,7 @@ static const AVOption options[] = {
> >>> .send_frame = v4l2_send_frame, \
> >>> .receive_packet = v4l2_receive_packet, \
> >>> .close = v4l2_encode_close, \
> >>> + .defaults = v4l2_m2m_defaults, \
> >>> .capabilities = AV_CODEC_CAP_HARDWARE | AV_CODEC_CAP_DELAY, \
> >>> .wrapper_name = "v4l2m2m", \
> >>> };
> >>>
> >
> >>
> >> Can we avoid some of the clumsiness around clipping twice in different
> >> ways by querying the quantiser values from the encode device here?
> >>
> >
> > thanks, I'll investigate.
> >
> >> E.g. on s5p-mfc (exynos) I can see:
> >>
> >> h264_minimum_qp_value 0x00990a61 (int) : min=0 max=51 step=1
> >> default=1 value=1
> >> h264_maximum_qp_value 0x00990a62 (int) : min=0 max=51 step=1
> >> default=51 value=51
> >>
> >> which matches the expected values for 8-bit H.264, but then for VP8 there
> >> is:
> >>
> >> vpx_minimum_qp_value 0x00990afb (int) : min=0 max=11 step=1
> >> default=0 value=0
> >> vpx_maximum_qp_value 0x00990afc (int) : min=0 max=127 step=1
> >> default=127 value=127
> >>
> >> which is going to pretty much entirely stop qmin from doing anything
> >> useful, and it would be nice to diagnose that.
> >
> > The max for vpx_maximum_qp_value has been bothering me. The usual qp range
> > for vp8/9 is [0,63].
>
> Ha, this is a fun subject.
>
> Quant range for VP8 is a 7-bit value, so [0..127].
> (<https://tools.ietf.org/html/rfc6386#section-9.6>.)
>
> Quant range for VP9/AV1 is an 8-bit value, so [0..255]. (VP9, see §6.2.9;
> AV1, see §5.9.12.)
>
> The libvpx/libaom software encoders present an external interface which
> compresses the range to 6 bits [0..63] (I think purely so that it looks more
> like libx264), but then immediately remap to the actual codec range before
> doing anything with the result. Other encoders may or may not have followed
> that and used the compressed range, so you're pretty much stuck with trying
> it or looking at the source code of a given encoder to find out which one
> they used.
>
> For V4L2 I can't find any official definition of which one is being used, and
> there are multiple different encoders behind it.
>
> Of the three drivers in mainline Linux, two (s5p-mfc and venus) advertise
> that they use the codec range:
>
> <https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/drivers/media/platform/qcom/venus/venc_ctrls.c?h=v5.4.17#n339>
> <https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/drivers/media/platform/s5p-mfc/s5p_mfc_enc.c?h=v5.4.17#n650>
>
> while the other (mtk-vcodec) doesn't support any quantiser controls at all (I
> guess it only does bitrate targets).
thanks Mark, that's very interesting.
>
> > I checked today with a dev on #v4l and he told me that only 6 bits are used
> > in
> > the driver so it's probably a bug. I'll look into this further.
>
> If the s5p-mfc driver actually uses the libvpx range rather than the codec
> range, they should probably talk to the venus people to get agreement on what
> range the controls are using. If venus does use the codec range but the
> s5p-mfc firmware blob wants the libvpx range then they would be better off
> putting a remapping table in their driver than changing their range to not
> match.
>
> > On a related note, I actually haven't been able to play a stream that's been
> > compressed with vp8/9 on the s5p-mfc (odroid xu4 for me). Have you had any
> > luck?
>
> I haven't seen it make a valid stream, but I've only ever done token testing
> with it to observe that. I assume it does work on venus, since that was what
> the Linaro people were originally testing on.
I'll try to get hold of a venus board to test.
--
Andriy
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
