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 302B24B7B4 for ; Thu, 13 Jun 2024 09:56:14 +0000 (UTC) Received: from [127.0.1.1] (localhost [127.0.0.1]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTP id 9D3FC68D9C0; Thu, 13 Jun 2024 12:56:11 +0300 (EEST) Received: from relay7-d.mail.gandi.net (relay7-d.mail.gandi.net [217.70.183.200]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTPS id 4EF5168D7FF for ; Thu, 13 Jun 2024 12:56:05 +0300 (EEST) Received: by mail.gandi.net (Postfix) with ESMTPSA id 7DB9320002 for ; Thu, 13 Jun 2024 09:56:04 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=niedermayer.cc; s=gm1; t=1718272564; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=XADg97inNDZZyKInBBtcVub4rZ/NCwD5f6x/oV0UhQ4=; b=X/Ct8mp3cfx1PzRRF2NmBz7tKXmNvZOyKnX/pxEcwHiWWxeBEw8Dz4myJIfPiMd3EA6DeF 8wG4kjl2mcsWsr4KtlHK5gA8UyuHX2U1P8g3/t41c9J1SnHk+NBKt3fPuUA2Qq14wq9Ejq 0GcZb46BO01u4cHxbAew2cAuxaq93y4+VvChk/aJzaiOYjU2+9B73YYMA6fFFGfBlcFsJq YJY0DSpx/0K1BoFmcVb3G1eArWIOGy8to3SJjFTZxybZIjG14D/kXkV+T5Fw7JQsrgkfAJ KfyevM5YXWuUP1AKDLnjUMSi+aIFwbcI6EDPBwFRbMRzlUPYbRsax5jUC8U7Zg== Date: Thu, 13 Jun 2024 11:56:03 +0200 From: Michael Niedermayer To: FFmpeg development discussions and patches Message-ID: <20240613095603.GE2821752@pb2> References: <20240613082325.GD2821752@pb2> MIME-Version: 1.0 In-Reply-To: X-GND-Sasl: michael@niedermayer.cc Subject: Re: [FFmpeg-devel] [PATCH 12/57] avcodec/mpegutils: Don't use MB_TYPE_L[01] for mpegvideo 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="===============2712961772960229255==" Errors-To: ffmpeg-devel-bounces@ffmpeg.org Sender: "ffmpeg-devel" Archived-At: List-Archive: List-Post: --===============2712961772960229255== Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="ZCG4XpTbnXMe2jC6" Content-Disposition: inline --ZCG4XpTbnXMe2jC6 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Jun 13, 2024 at 10:49:15AM +0200, Andreas Rheinhardt wrote: > Michael Niedermayer: > > On Wed, Jun 12, 2024 at 03:48:08PM +0200, Andreas Rheinhardt wrote: > >> MB_TYPE_L[01] is based upon H.264 terminology (it stands for > >> list); yet the mpegvideo based decoders don't have lists > >> of reference frames, they have at most one forward and one > >> backward reference. So use terminology based upon this. > >> > >> This also has a second advantage: MB_TYPE_L[01] is actually > >> an OR of two flags (which are set independently for H.264, > >> but aren't for mpegvideo). Switching to different flags > >> makes the flags fit into an int16_t, which will be useful > >> in future commits. > >> > >> The only downside to this is a very small amount of code > >> in error_resilience.c and mpegutils.c (the only code shared > >> between the H.264 decoder and mpegvideo). > >=20 > > Cant you just call the flags differently but leave them nummerically > > the same, if you dont like L0L1 terminology ? > >=20 > > Having each codec be different does not seem to me to be a good thing > > It adds burden to every bit of common code. It may be thats error_resil= ience > > ATM, but there are other things people may want to add, like an univers= al > > encoder for all the block based transform + MC formats >=20 > 1. The terminology is only one part of this: Using the same flags > currently adds a burden to the mpegvideo-decoders, because their > mb_types don't fit into an int16_t, so that they can't use symbols > tables. See the following patches for this. > 2. Furthermore, it is not "each codec" that has its own system of > defines; it is only H.264 vs. the rest. And even these two systems are > mostly the same. > 3. If you create a universal encoder, then you'd be better off to use > your own MB_TYPE_ defines for it and not to reuse this system here. In > fact, mpegvideoenc does not really use it (it uses its > CANDIDATE_MB_TYPE_* system). > 4. And I don't think that a "universal" encoder is even a desirable > idea. An in-tree H.264 encoder would be very complex and all encoders > would benefit if it were not tied to the other encoders. Apart from > that, x264 is a thing. iam not talking about h.264, I do think though that extending the concept of our mpegvideo encoder which happily encodes from mjpeg, h.261, RV10, RV20 mpeg-1, mpeg-2, mpeg-4, h.263 to WMV1 and WMV2 to some more generic universal encoder that covers the more modern formats does make sense and is desirable That said, i guess it doesnt matter if you change the flags, you are probab= ly correct that they wont be too usefull as they are either ... thx [...] --=20 Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB You can kill me, but you cannot change the truth. --ZCG4XpTbnXMe2jC6 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iF0EABEKAB0WIQSf8hKLFH72cwut8TNhHseHBAsPqwUCZmrCMAAKCRBhHseHBAsP qzDCAJ9F+jeKCc4hKmQ1gmd/mS0bIDetAACeNIzl0NWWsvh79f1ant6CI0eIQKU= =DjY/ -----END PGP SIGNATURE----- --ZCG4XpTbnXMe2jC6-- --===============2712961772960229255== 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". --===============2712961772960229255==--