> On May 17, 2025, at 19:14, Timo Rothenpieler <t...@rothenpieler.org> wrote: > > On 17.05.2025 06:35, Zhao Zhili wrote: >>> 在 2025年5月17日，上午1:39，Timo Rothenpieler <t...@rothenpieler.org> 写道： >>> >>> On 16.05.2025 19:24, Zhao Zhili wrote: >>>>>> On May 17, 2025, at 01:10, Zhao Zhili >>>>>> <quinkblack-at-foxmail....@ffmpeg.org> wrote: >>>>> >>>>> >>>>> >>>>>> On May 17, 2025, at 00:27, Timo Rothenpieler <t...@rothenpieler.org> >>>>>> wrote: >>>>>> >>>>>> On 16.05.2025 17:59, Zhao Zhili wrote: >>>>>>>> On May 16, 2025, at 22:52, Timo Rothenpieler <t...@rothenpieler.org> >>>>>>>> wrote: >>>>>>>> >>>>>>>> On 16/05/2025 16:24, Zhao Zhili wrote: >>>>>>>>> From: Zhao Zhili <zhiliz...@tencent.com >>>>>>>>> <mailto:zhiliz...@tencent.com>> >>>>>>>>> ffmpeg -i input.mp4 -c copy -tag:v av01 output.flv >>>>>>>>> [flv @ 0x143204080] Tag av01 incompatible with output codec id '225' >>>>>>>>> (10va) >>>>>>>> >>>>>>>> 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’s >>>>>>> passed to AVCodecParameters codec_tag in little endian. >>>>>>> You didn’t 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. >>>>>> >>>>>> This still irks me as wrong. >>>>>> There is _a lot_ of places all over flvenv.c, in all kinds of functions, >>>>>> that hard-depend on the values in par->codec_tag being from the >>>>>> _codec_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. >>>>>> >>>>>> So there seems to be a deeper issue there if those values can be >>>>>> overridden from the commandline. The encoder clearly does not expect >>>>>> that. >>>>>> >>>>>> Looking at the code this error comes from: >>>>>> https://github.com/FFmpeg/FFmpeg/blob/master/libavformat/mux.c#L314 >>>>>> >>>>>> It looks to to me like it's working exactly as intended and required by >>>>>> flvenc, protecting it from invalid tags. >>>>>> >>>>>> So, when the user provides a custom tag that is invalid, isn't that >>>>>> 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. >>>>>> >>>>>> Why do you want to override it anyway? There is only exactly one valid >>>>>> tag for each codec. >>>>> >>>>> A user shows the error message to me. Because he know there are -tag >>>>> option for mp4, and >>>>> enhanced-rtmp use fourcc for extended codecs, so he thought it should >>>>> work. >>>>> >>>>> The -tag:v av01 is redundant, it should be a NOP, not trigger error. The >>>>> strings “av01” >>>>> is the right order of fourcc in spec. The endian issue should be limited >>>>> to the internal. >>>>> Current error message is confusing, because it shows 10va instead of av01. >>>> Doc from Microsoft shows fourcc use small endian >>>> https://learn.microsoft.com/en-us/windows/win32/directshow/fourcc-codes >>>> While wiki and enhanced rtmp spec says it’s big endian >>>> https://en.wikipedia.org/wiki/FourCC >>>> It’s clear in av_fourcc_make_string >>>> that we use small endian. >>>> For normal codec id in flv, e.g, 7 for H.264, it’s not a big issue, since >>>> they’re not fourcc. >>> >>> This patch just fixes it for a very small subset of codecs in flv though. >>> There's nothing indicating that -tag:v is needed or sensibly supported in >>> flvenc. >>> If you'd want to pass h264 or aac as fourcc, it'd be flat out impossible, >>> and no easy fix is available. >>> >>> 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. >>> >>> flvenv should probably just completely ignore -tag:v, since the option >>> makes no sense for it anyway. >> I can remove setting tag list to AVOutputFormat, does that works for you? > > Won't that break even more things? > The code heavily relies on the tags being what they are, and passing the tag > list to AVOutputFormat would remove avformat enforcing that, with said error > when trying to override it with something invalid.
The enforcing logic has a precondition, that codec_tag is in little endian. flv_video_codec_ids and flv_audio_codec_ids don’t match this requirement. > > I honestly don't think anything needs to be changed at all. > Passing custom tags is simply not something flv sensibly supports. 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. There is no explicit documentation on the endian issue of codec_tag. I hope developers familiar with the history can share insights on this topic. Cc Michael. > _______________________________________________ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > To unsubscribe, visit link above, or email > ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe". _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
