Re: [FFmpeg-devel] [PATCH 3/3] avformat/movenc: Add support for AVIF muxing

[James Almer <jamrial@gmail.com>]

On 3/3/2022 4:20 PM, Vignesh Venkatasubramanian wrote:
> On Thu, Mar 3, 2022 at 7:36 AM James Almer <jamrial@gmail.com> wrote:
>>
>> On 2/22/2022 6:43 PM, Vignesh Venkatasubramanian wrote:
>>> Add an AVIF muxer by re-using the existing the mov/mp4 muxer.
>>>
>>> AVIF Specifiation: https://aomediacodec.github.io/av1-avif
>>>
>>> Sample usage for still image:
>>> ffmpeg -i image.png -c:v libaom-av1 -avif-image 1 image.avif
>>>
>>> Sample usage for animated AVIF image:
>>> ffmpeg -i video.mp4 animated.avif
>>>
>>> We can re-use any of the AV1 encoding options that will make
>>> sense for image encoding (like bitrate, tiles, encoding speed,
>>> etc).
>>>
>>> The files generated by this muxer has been verified to be valid
>>> AVIF files by the following:
>>> 1) Displays on Chrome (both still and animated images).
>>> 2) Displays on Firefox (only still images, firefox does not support
>>>      animated AVIF yet).
>>> 3) Verfied to be valid by Compliance Warden:
>>>      https://github.com/gpac/ComplianceWarden
>>>
>>> Fixes the encoder/muxer part of Trac Ticket #7621
>>>
>>> Signed-off-by: Vignesh Venkatasubramanian <vigneshv@google.com>
>>> ---
>>>    configure                |   1 +
>>>    libavformat/allformats.c |   1 +
>>>    libavformat/movenc.c     | 300 +++++++++++++++++++++++++++++++++++----
>>>    libavformat/movenc.h     |   5 +
>>>    4 files changed, 282 insertions(+), 25 deletions(-)
>>
>> With a single frame i get no errors in that compliance tool, but when i
>> encode an animated AVIF i get the following:
>>
>> [heif][Rule #12] Error: CodingConstraintsBox ('ccst') shall be present once
>> [heif][Rule #28] Error: Wrong arity for boxes { ccst } in parents { avc1
>> avc2 avc3 avc4 hev1 hev2 hvc1 hvc2 av01 }: expected in range [1-1], found 0
>> [heif][Rule #31] Error: 'msf1' brand: this file shall conform to HEIF
>> (section 7.2)
>> [heif][Rule #31] Error: 'msf1' brand: 'iso8' shall be present among the
>> compatible brands array
>> [heif][Rule #32] Error: 'mif1' brand: this file shall conform to HEIF
>> section 6, check the other errors for details
>> [heif][Rule #33] Error: 'msf1' brand: this file shall conform to HEIF
>> section 7, check the other errors for details
>>
>> All but one of these should be solved by writing a ccst box after the
>> av1C box in the sample entry. The missing one should be solved by
>> writing the iso8 compatible brand.
>>
>> The ccst box looks like it would need some bitstream information, so
>> either you parse the packets to get it, or just hardcode sane defaults,
>> considering it's used as a hint and it's not required for demuxing.
> 
> I recently fixed these errors in libavif [1][2] (the reference AVIF
> encoder). I was hoping to have a follow-up patch since i already
> uploaded the existing patches. Since you have pointed this out now, i
> have included the fix in this patch itself. The new patch will now
> write the iso8 compatible brand and the ccst box with sane default
> values. The file produced is now identical to the file produced by
> libavif in terms of box structure.
> 
> Also, notice that the compliance tool still shows the following error
> for animated avif:
> 
> [avif][Rule #3] Warning: [ItemId=1] still_picture flag set to 0
> [avif][Rule #4] Warning: [ItemId=1] reduced_still_picture_header flag set to 0
> 
> I believe these are incorrect since it does not make sense to set
> these flag to 0 for animated avif sequences. These warnings also show
> up with files produced by libavif. So it is okay to ignore them. I
> will file an issue with the compliance tool separately.

The compliance tool uses the 1.0.0 revision of the spec, and what you 
mentioned was removed in the current unfinished draft: 
https://github.com/AOMediaCodec/av1-avif/pull/112

I assume the tool will be updated once a new revision is released, so 
yes, we can ignore them.

> 
> Please take another look, thanks!

I noticed that using -still-picture 1 and passing more than one frame to 
the libaom encoder will succeed, despite you setting enccfg.g_limit to 
1, and encode every frame as key frames.
I'd expect the encoder would error out if you try to feed it more 
frames. Is it a libaom bug?

> 
> [1] https://github.com/AOMediaCodec/libavif/pull/855
> [2] https://github.com/AOMediaCodec/libavif/pull/856
>> _______________________________________________
>> 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".
> 
> 
> 
_______________________________________________
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".