From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from ffbox0-bg.mplayerhq.hu (ffbox0-bg.ffmpeg.org [79.124.17.100]) by master.gitmailbox.com (Postfix) with ESMTP id E83CE45DA1 for ; Mon, 10 Apr 2023 14:17:54 +0000 (UTC) Received: from [127.0.1.1] (localhost [127.0.0.1]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTP id C23EB68BDDD; Mon, 10 Apr 2023 17:17:50 +0300 (EEST) Received: from relay5-d.mail.gandi.net (relay5-d.mail.gandi.net [217.70.183.197]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTPS id 4C481689F8C for ; Mon, 10 Apr 2023 17:17:44 +0300 (EEST) Received: (Authenticated sender: michael@niedermayer.cc) by mail.gandi.net (Postfix) with ESMTPSA id 67F311C0003 for ; Mon, 10 Apr 2023 14:17:42 +0000 (UTC) Date: Mon, 10 Apr 2023 16:17:42 +0200 From: Michael Niedermayer To: FFmpeg development discussions and patches Message-ID: <20230410141742.GH1164690@pb2> References: <20230409234256.GG1164690@pb2> MIME-Version: 1.0 In-Reply-To: Subject: Re: [FFmpeg-devel] [PATCH] avcodec/amv: use correct quantize tables X-BeenThere: ffmpeg-devel@ffmpeg.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: FFmpeg development discussions and patches List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: FFmpeg development discussions and patches Content-Type: multipart/mixed; boundary="===============6294889735915557012==" Errors-To: ffmpeg-devel-bounces@ffmpeg.org Sender: "ffmpeg-devel" Archived-At: List-Archive: List-Post: --===============6294889735915557012== Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="u9wPhCK/rM6+CG+h" Content-Disposition: inline --u9wPhCK/rM6+CG+h Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Apr 10, 2023 at 12:09:59PM +0800, AlexGuo1998 wrote: > On Mon, Apr 10, 2023 at 7:43=E2=80=AFAM 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 enco= der > > > 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 >=20 > I'll do that later. >=20 > > 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 >=20 > 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. >=20 > The container is a AVI like container, with some fields intentionally > zeroed. Some player won't play when those fields are set correctly. >=20 > The video stream is a nonstandard "mjpeg like" data stream, with > compressed data stream directly after SOI marker. >=20 > Those left us with nowhere for additional metadata. Should I introduce well, there are places left,=20 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 [...] --=20 Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Opposition brings concord. Out of discord comes the fairest harmony. -- Heraclitus --u9wPhCK/rM6+CG+h Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iF0EABEIAB0WIQSf8hKLFH72cwut8TNhHseHBAsPqwUCZDQaggAKCRBhHseHBAsP q17MAJ9+4ulIXOZaqhebe0i+6MoglEiOAACfRbqwxxvjrkB0gfD/FhKu5pK6jIk= =gspG -----END PGP SIGNATURE----- --u9wPhCK/rM6+CG+h-- --===============6294889735915557012== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe". --===============6294889735915557012==--