Re: [FFmpeg-devel] [PATCH] avformat/flvenc: Specify codec tag with MKTAG

[Timo Rothenpieler <timo@rothenpieler.org>]

On 16.05.2025 19:24, Zhao Zhili wrote:
> 
> 
>> On May 17, 2025, at 01:10, Zhao Zhili <quinkblack-at-foxmail.com@ffmpeg.org> wrote:
>>
>>
>>
>>> On May 17, 2025, at 00:27, Timo Rothenpieler <timo@rothenpieler.org> wrote:
>>>
>>> On 16.05.2025 17:59, Zhao Zhili wrote:
>>>>> On May 16, 2025, at 22:52, Timo Rothenpieler <timo@rothenpieler.org> wrote:
>>>>>
>>>>> On 16/05/2025 16:24, Zhao Zhili wrote:
>>>>>> From: Zhao Zhili <zhilizhao@tencent.com <mailto:zhilizhao@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.
And maybe print a warning when it's used only.
_______________________________________________
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".