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 > > > 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 > > > --- > > > 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