[FFmpeg-devel] [PATCH] avcodec/amv: use correct quantize tables

[AlexGuo1998]

On Mon, Apr 10, 2023 at 7:43 AM Michael Niedermayer wrote:
>
> On Sun, Apr 09, 2023 at 04:37:49PM +0800, AlexGuo1998 wrote:
> > So sorry that gmail trashed the patch. Re-sent as an attachment.
>
> > From 14910cef473a2858d5cf5e3bf855730762456de1 Mon Sep 17 00:00:00 2001
> > From: AlexGuo1998 <AlexGuo1998 at 163.com>
> > Date: Sun, 9 Apr 2023 15:57:05 +0800
> > Subject: [PATCH] avcodec/amv: use correct quantize tables
> >
> > The official encoder has a mode to generate mjpeg AVI files, which
> > embeds the correct quantize table. Change the table we use (both encoder
> > and decoder) to match that.
> >
> > Signed-off-by: AlexGuo1998 <AlexGuo1998 at 163.com>
> > ---
> >  libavcodec/mpegvideo_enc.c | 16 +++++++---------
> >  libavcodec/sp5x.h          | 21 +++++++++++++++++++++
> >  libavcodec/sp5xdec.c       |  9 +++++++--
> >  3 files changed, 35 insertions(+), 11 deletions(-)
>
> decoder and encoder changes should be in seperate patches

I'll do that later.

> and the version should be increased for encoder changes so
> any software reading a file can from a bitstream version metadata
> indentify it. For this to work of course the version first needs to be
> stored. So one should check LIBAVCODEC_IDENT is stored
>
> This would then also allow the decoder to match the encoder optimally

I'd like to, but unsure if it is possible. As noted in commit a2fea0f4,
"AMV is a hard-coded (and broken) subset of AVI", it's intended to be
played on a function limited hardware device.

The container is a AVI like container, with some fields intentionally
zeroed. Some player won't play when those fields are set correctly.

The video stream is a nonstandard "mjpeg like" data stream, with
compressed data stream directly after SOI marker.

Those left us with nowhere for additional metadata. Should I introduce
an AVOption to restore the old (possibly incorrect) behavior?