From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from ffbox0-bg.ffmpeg.org (ffbox0-bg.ffmpeg.org [79.124.17.100]) by master.gitmailbox.com (Postfix) with ESMTPS id CE2234F254 for ; Sat, 17 May 2025 23:39:05 +0000 (UTC) Received: from [127.0.1.1] (localhost [127.0.0.1]) by ffbox0-bg.ffmpeg.org (Postfix) with ESMTP id 3A6D968D0B3; Sun, 18 May 2025 02:39:01 +0300 (EEST) Received: from relay7-d.mail.gandi.net (relay7-d.mail.gandi.net [217.70.183.200]) by ffbox0-bg.ffmpeg.org (Postfix) with ESMTPS id 9385B68CDCE for ; Sun, 18 May 2025 02:38:54 +0300 (EEST) Received: by mail.gandi.net (Postfix) with ESMTPSA id E977843225 for ; Sat, 17 May 2025 23:38:53 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=niedermayer.cc; s=gm1; t=1747525134; 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=BpfzoLvFVPjaT76wMorkXk+TUBozF9tf0RlBJruM60I=; b=g6cTRfvor8q5lsvyeACRMjfmZj5yAgcRJAwKXoy0wb3MLwJ2c8wKDA1E1fk+w4zm3iF3QN KGmLUQDvOkhIYM6DfrOtyiIDJkf8mE11m9t3zGDYBfRAFKAFhArJxsRom4ePsgJZZZhXEF qm5jiE9pW7KEq6M2dNZQIDEz7skVOoSoPxKUNmlS6s55BG55YW0siB5/3bLS3N7j9wMszP tUw23R97BHBL907v2MFg18+HuCeNPDSHqhD67vG9rxNmb7Sga5lfzFi+G0RWgqFG3trKqY hDGVBBNXuOvvWQYu7ouN6Ibgml044ltIt4u3KzUa8fYvgBfxeETxaMg5PgBDiw== Date: Sun, 18 May 2025 01:38:52 +0200 From: Michael Niedermayer To: FFmpeg development discussions and patches Message-ID: <20250517233852.GE29660@pb2> References: <543f3645-82b9-4a74-8f2e-ece2fcf3a4be@rothenpieler.org> <62fa0c57-7bf3-4c5e-9173-f837aef7faef@rothenpieler.org> MIME-Version: 1.0 In-Reply-To: X-GND-State: clean X-GND-Score: -90 X-GND-Cause: gggruggvucftvghtrhhoucdtuddrgeefvddrtddtgdefudeileejucetufdoteggodetrfdotffvucfrrhhofhhilhgvmecuifetpfffkfdpucggtfgfnhhsuhgsshgtrhhisggvnecuuegrihhlohhuthemuceftddunecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenfghrlhcuvffnffculddutddmnecujfgurhepfffhvffukfhfgggtuggjsehgtderredttdejnecuhfhrohhmpefoihgthhgrvghlucfpihgvuggvrhhmrgihvghruceomhhitghhrggvlhesnhhivgguvghrmhgrhigvrhdrtggtqeenucggtffrrghtthgvrhhnpefgteegleffhfffieektdfgteetudejgeejfefhjeekgfehheegvdekkeejudfgkeenucffohhmrghinhepghhithhhuhgsrdgtohhmpdhmihgtrhhoshhofhhtrdgtohhmpdifihhkihhpvgguihgrrdhorhhgnecukfhppeeguddrieeirdeijedruddufeenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepihhnvghtpeeguddrieeirdeijedruddufedphhgvlhhopehlohgtrghlhhhoshhtpdhmrghilhhfrhhomhepmhhitghhrggvlhesnhhivgguvghrmhgrhigvrhdrtggtpdhnsggprhgtphhtthhopedupdhrtghpthhtohepfhhfmhhpvghgqdguvghvvghlsehffhhmphgvghdrohhrgh X-GND-Sasl: michael@niedermayer.cc Subject: Re: [FFmpeg-devel] [PATCH] avformat/flvenc: Specify codec tag with MKTAG 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="===============8784877130720375827==" Errors-To: ffmpeg-devel-bounces@ffmpeg.org Sender: "ffmpeg-devel" Archived-At: List-Archive: List-Post: --===============8784877130720375827== Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="T7nyQ/KeiTWBaOH9" Content-Disposition: inline --T7nyQ/KeiTWBaOH9 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi Zhao Zhili On Sat, May 17, 2025 at 10:05:34PM +0800, Zhao Zhili wrote: >=20 >=20 > > On May 17, 2025, at 19:14, Timo Rothenpieler wr= ote: > >=20 > > On 17.05.2025 06:35, Zhao Zhili wrote: > >>> =E5=9C=A8 2025=E5=B9=B45=E6=9C=8817=E6=97=A5=EF=BC=8C=E4=B8=8A=E5=8D= =881:39=EF=BC=8CTimo Rothenpieler =E5=86=99=E9=81= =93=EF=BC=9A > >>>=20 > >>> =EF=BB=BFOn 16.05.2025 19:24, Zhao Zhili wrote: > >>>>>> On May 17, 2025, at 01:10, Zhao Zhili wrote: > >>>>>=20 > >>>>>=20 > >>>>>=20 > >>>>>> On May 17, 2025, at 00:27, Timo Rothenpieler wrote: > >>>>>>=20 > >>>>>> On 16.05.2025 17:59, Zhao Zhili wrote: > >>>>>>>> On May 16, 2025, at 22:52, Timo Rothenpieler wrote: > >>>>>>>>=20 > >>>>>>>> On 16/05/2025 16:24, Zhao Zhili wrote: > >>>>>>>>> From: Zhao Zhili > > >>>>>>>>> ffmpeg -i input.mp4 -c copy -tag:v av01 output.flv > >>>>>>>>> [flv @ 0x143204080] Tag av01 incompatible with output codec id = '225' (10va) > >>>>>>>>=20 > >>>>>>>> I don't quite understand what causes this. > >>>>>>>> Is this an issue when running on big endian architectures? > >>>>>>>> I'm pretty sure I tested all combinations of codecs with muxing = and demuxing, and never ran into that error. > >>>>>>> The key point is when specify tag via command line, e.g., -tag:v = av01, it=E2=80=99s > >>>>>>> passed to AVCodecParameters codec_tag in little endian. > >>>>>>> You didn=E2=80=99t see the error because without specify the tag = explicitly, codec_tag is copied > >>>>>>> from AVOutputFormat codec_tag to AVCodecParameters codec_tag, so = they are > >>>>>>> the same. > >>>>>>> Another example is codec_mp4_tags. > >>>>>>=20 > >>>>>> This still irks me as wrong. > >>>>>> There is _a lot_ of places all over flvenv.c, in all kinds of func= tions, that hard-depend on the values in par->codec_tag being from the _cod= ec_ids tables at the top of the file. > >>>>>> Like, they contain flv specific audio and video codec IDs for the = pre-ext-flv codecs, those would all also break. > >>>>>>=20 > >>>>>> So there seems to be a deeper issue there if those values can be o= verridden from the commandline. The encoder clearly does not expect that. > >>>>>>=20 > >>>>>> Looking at the code this error comes from: > >>>>>> https://github.com/FFmpeg/FFmpeg/blob/master/libavformat/mux.c#L314 > >>>>>>=20 > >>>>>> It looks to to me like it's working exactly as intended and requir= ed by flvenc, protecting it from invalid tags. > >>>>>>=20 > >>>>>> So, when the user provides a custom tag that is invalid, isn't tha= t kinda on the user? > >>>>>> The check you're running into does what it's supposed to: > >>>>>> It detects that the provided tag is invalid for this codec in this= container. > >>>>>>=20 > >>>>>> Why do you want to override it anyway? There is only exactly one v= alid tag for each codec. > >>>>>=20 > >>>>> A user shows the error message to me. Because he know there are -ta= g option for mp4, and > >>>>> enhanced-rtmp use fourcc for extended codecs, so he thought it shou= ld work. > >>>>>=20 > >>>>> The -tag:v av01 is redundant, it should be a NOP, not trigger error= =2E The strings =E2=80=9Cav01=E2=80=9D > >>>>> is the right order of fourcc in spec. The endian issue should be li= mited to the internal. > >>>>> Current error message is confusing, because it shows 10va instead o= f av01. > >>>> Doc from Microsoft shows fourcc use small endian > >>>> https://learn.microsoft.com/en-us/windows/win32/directshow/fourcc-co= des > >>>> While wiki and enhanced rtmp spec says it=E2=80=99s big endian > >>>> https://en.wikipedia.org/wiki/FourCC > >>>> It=E2=80=99s clear in av_fourcc_make_string > >>>> that we use small endian. > >>>> For normal codec id in flv, e.g, 7 for H.264, it=E2=80=99s not a big= issue, since they=E2=80=99re not fourcc. > >>>=20 > >>> This patch just fixes it for a very small subset of codecs in flv tho= ugh. > >>> There's nothing indicating that -tag:v is needed or sensibly supporte= d in flvenc. > >>> If you'd want to pass h264 or aac as fourcc, it'd be flat out impossi= ble, and no easy fix is available. > >>>=20 > >>> I'd rather not complicate flvenc, even if just a little bit, just to = swap around the endianness of the few codecs that do use a fourcc based tag. > >>>=20 > >>> flvenv should probably just completely ignore -tag:v, since the optio= n makes no sense for it anyway. > >> I can remove setting tag list to AVOutputFormat, does that works for y= ou? > >=20 > > Won't that break even more things? > > The code heavily relies on the tags being what they are, and passing th= e tag list to AVOutputFormat would remove avformat enforcing that, with sai= d error when trying to override it with something invalid. >=20 > The enforcing logic has a precondition, that codec_tag is in little endia= n. > flv_video_codec_ids and flv_audio_codec_ids don=E2=80=99t match this requ= irement. >=20 > >=20 > > I honestly don't think anything needs to be changed at all. > > Passing custom tags is simply not something flv sensibly supports. >=20 > AVOutputFormat codec_tag is API exported to users. Even if users > are not supposed to pass codec_tag to flvenc, the exported information > should match the tradition, that codec_tag is in little endian according = to > the code in av_fourcc_make_string, mov, matroska, and so on. You are correct but the code did use the opposit endianness for a long time. Changing this would need a api version bump, should be documented in APIChanges we would have to make sure nothing breaks In the end iam not sure the work is worth given this seems not really affecting anything except an error message for a case that isnt really usefull. That said, codec_tag is container specific, but it also often has large numbers of values shared between containers. If for example mov had a codec_tag that would match one in flv then having endianness matching between the 2 would be nice OTOH if flv is its own universe, iam not sure the work to change endianness is worth the work. But if someone wants to do that "cleanup" work, iam not against it, assuming we dont cause others some headaches with it thx [...] --=20 Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB The real ebay dictionary, page 2 "100% positive feedback" - "All either got their money back or didnt compla= in" "Best seller ever, very honest" - "Seller refunded buyer after failed scam" --T7nyQ/KeiTWBaOH9 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iF0EABEKAB0WIQSf8hKLFH72cwut8TNhHseHBAsPqwUCaCkeCAAKCRBhHseHBAsP q14nAJ48+PGByFtDL/hm49yn/TVrlI/L6wCgiHPAco52bTYZeJEq62f3bKN0DHc= =IAaa -----END PGP SIGNATURE----- --T7nyQ/KeiTWBaOH9-- --===============8784877130720375827== 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". --===============8784877130720375827==--