[FFmpeg-devel] [PATCH v4 1/3] avcodec/jpeg2000dec: Add support for CAP and CPF markers

[Pierre-Anthony Lemieux]

On Mon, Jul 15, 2024 at 10:33 PM Tomas Härdin <git at haerdin.se> wrote:
>
> fre 2024-07-12 klockan 12:51 -0700 skrev Pierre-Anthony Lemieux:
> > On Thu, Jul 11, 2024 at 10:28 PM Tomas Härdin <git at haerdin.se> wrote:
> > >
> > > > +            if (s->in_tile_headers == 1 && s->isHT && (!s-
> > > > > Ccap15_b11))
> > > > +                av_log(s->avctx, AV_LOG_WARNING, "COD marker is
> > > > found in HOMOGENEOUS HT set\n");
> > >
> > > How bad is this and the other markers being present in this case?
> >
> > At the very least, it means that signaling is inconsistent within the
> > codestream since the standard states that:
> > """
> > The HOMOGENEOUS set is the set of HTJ2K codestreams where:
> > • none of the functional marker segments, e.g., COD, COC, RGN, QCD,
> > QCC, and POC, are present in any
> > tile-part header; and
> > • no PPT marker segment is present.
> > """
> >
> > The point of signalling that a codestream is "HOMOGENEOUS" is to
> > allow
> > decoders to configure themselves solely based on information
> > retrieved
> > entirely from the main header.
> >
> > Since, AFAIK, FFMPEG does not rely on the HOMOGENEOUS to short-
> > circuit
> > configuration, incorrect HOMOGENEOUS signalling will likely not
> > impact
> > FFMPEG.
>
> It could happen that information in tile headers contradict information
> in the main header, right? In such a case it sounds like we can't be
> sure which decode is the correct one.

Per the spec, the decoder uses the COD information in tile-parts over
the COD information in the header.

The issue here is that a decoder, upon seeing HOMOGENEOUS, simply does
not bother with looking for COD information in tile-parts, thereby
missing critical information.

>
> Much like with broken MXF files I think we should error out because of
> the potential ambiguity, to discourage broken encoders from
> proliferating. Else we'll have to deal with them perpetually

I agree. I also think that, in this particular case, exiting decoding
seems extreme since the error does not cause an inconsistent state
within the FFMPEG decoder. An application could always choose to
interpret all FFMPEG warnings as fatal errors.

Any other  opinions?

>
> /Tomas
> _______________________________________________
> 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".