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

[Michael Niedermayer]

On Mon, Apr 10, 2023 at 12:09:59PM +0800, AlexGuo1998 wrote:
> 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

well, there are places left, 

if its worth the effort, iam not sure

For example the huffman coder has a EOB code and a 16 zeros code
In blocks with more than 16 zeros left at the end teh 16 zero code
can be placed before teh EOB. A working decoder needs to support both
the 16 zero and EOB codes so this should not break anything, its just
a less efficient way to store a block.
There are other places like at the end of frames where decoder may
or may not have an issue with some extra chunk

Thats more a [RFC] than a request to do this.
Is there anything that can be used to distingish what ffmpeg generated
previously (well currently) and what the official software did create?

If not i guess this is not worth it as we already have indistingishable
cases then


> an AVOption to restore the old (possibly incorrect) behavior?

does the old encoder output look better with the old decoder ?

thx

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Opposition brings concord. Out of discord comes the fairest harmony.
-- Heraclitus
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 195 bytes
Desc: not available
URL: <https://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20230410/2271b7be/attachment.sig>