[FFmpeg-devel] [PATCH] avformat/mov: Add support for demuxing still HEIC images

[Vignesh Venkat]

On Thu, Oct 5, 2023 at 10:58 AM Andreas Rheinhardt
<andreas.rheinhardt at outlook.com> wrote:
>
> Vignesh Venkat via ffmpeg-devel:
> > On Tue, Oct 3, 2023 at 9:40 PM Vittorio Giovara
> > <vittorio.giovara at gmail.com> wrote:
> >>
> >>
> >>
> >> On Wed, Oct 4, 2023 at 12:02 AM Vignesh Venkat via ffmpeg-devel <ffmpeg-devel at ffmpeg.org> wrote:
> >>>
> >>> On Tue, Oct 3, 2023 at 6:32 PM Vittorio Giovara
> >>> <vittorio.giovara at gmail.com> wrote:
> >>>>
> >>>> On Tue, Oct 3, 2023 at 8:30 PM Steven Liu <lingjiujianke at gmail.com> wrote:
> >>>>
> >>>>>>> 2.42.0.515.g380fc7ccd1-goog
> >>>>>>>
> >>>>>>
> >>>>>> Any comments/objections on merging this?
> >>>>>
> >>>>>
> >>>>> Can this patch support tiled hevc coded or sequence heif？=
> >>>>>
> >>>>
> >>>> I believe that will be possible only after AVStreamGroup is implemented.
> >>>>
> >>>
> >>> Yes, this patch only supports still HEIC images that don't have alpha
> >>> and grids (tiles).
> >>>
> >>> Tiles and Alpha support will be possible only after AVStreamGroup is
> >>> implemented. I will look into HEIC sequences in a follow-up.
> >>>
> >>>> Vignesh is there a sample available? Could we add a test?
> >>>
> >>> I tested it from the files in
> >>> https://github.com/nokiatech/heif/tree/gh-pages/content/images. I am
> >>> not sure about HEVC licensing and if we are allowed to copy some of
> >>> those files in the ffmpeg fate server. Would generating a random image
> >>> with ffmpeg and encoding it as HEIC be good enough?
> >>
> >>
> >> I would prefer a real world example and FATE has a bunch of conformance samples already.
> >> Adding the ones from https://github.com/nokiatech/heif_conformance shouldn't be a problem.
> >> Ideally the sample test should be added to this same patch.
> >
> > Great, i have added two samples. Can you please upload C002.heic and
> > C003.heic from the heif_conformance repository to the fate server
> > under the "heif-conformance" sub-directory. I have also attached those
> > two files in this email for reference. I will update the patch with
> > the fate tests.
> >
>
> Why are you intend to add so big files when the linked repo contains
> smaller files? All five multilayer files are below 20KB each;
> multilayer005.heic is even only 4.5KB. MIAF002.heic (8.6KB) and
> MIAF003.heic (13.5KB) are also quite small. C025.heic (19.4KB) and
> C053.heic (14.2KB) are also quite small and there are also other samples
> in the 50KB-60KB range (C017.heic, C018.heic, C019.heic, C020.heic,
> C041.heic). Besides taking up less diskspace, smaller files will likely
> be faster to decode (which is particularly advantageous for people like
> me who run FATE a lot).
>

There is an excel sheet in the samples github repository that explains
the features of each of those files. I picked the files with the
simplest features (single item and multi-item) since those are the
only two files that I know for certain the current ffmpeg parser can
parse as-is. The multi-layer files that you mention may work, but i am
not sure if we are handling those layers the right way. So adding
something that I am not sure if it has the right behavior or not to a
fate test didn't seem right.

Also, the fate test only demuxes the files (using -c copy) and does
not do any decoding since it tests the parser and not the hevc
decoder. So decoding time is not a concern. I do understand the
concern about disk-space though. I can probably make a random file
that is smaller, but I also thought it was better to use files from an
existing conformance repository.

Please let me know if that is reasonable.

> - Andreas
>
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel at ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-request at ffmpeg.org with subject "unsubscribe".



-- 
Vignesh