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

[Michael Niedermayer]

On Tue, Jul 30, 2024 at 10:22:37PM +0200, Tomas Härdin wrote:
> fre 2024-07-26 klockan 23:29 +0200 skrev Michael Niedermayer:
> > On Thu, Jul 25, 2024 at 05:06:04PM -0700, Pierre-Anthony Lemieux
> > wrote:
> > > On Thu, Jul 25, 2024 at 2:17 AM Tomas Härdin <git at haerdin.se>
> > > wrote:
> > > > 
> > > > sön 2024-07-21 klockan 14:07 +0900 skrev Pierre-Anthony Lemieux:
> > > > > On Sat, Jul 20, 2024 at 5:12 PM Tomas Härdin <git at haerdin.se>
> > > > > wrote:
> > > > > > 
> > > > > > tor 2024-07-18 klockan 23:10 +0900 skrev 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.
> > > > > > 
> > > > > > So it is actually perfectly legal? Then it seems this patch
> > > > > > is
> > > > > > wrong
> > > > > 
> > > > > What is not "illegal": the HOMOGENEOUS flag being equal to true
> > > > > *and*
> > > > > having COD marker segments in tile-parts.
> > > > > 
> > > > > This is what the patch detects.
> > > > > 
> > > > > FFMPEG can decode such illegal codestream. Other decoders might
> > > > > not.
> > > > > 
> > > > > The question is: what should FFMPEG do? Should FFMPEG exit or
> > > > > warn
> > > > > and continue.
> > > > 
> > > > If the spec allows it but it's perhaps unadviced then warning
> > > > about it
> > > > seems reasonable
> > > 
> > > (I totally messed up my double negative. Repeat below. Sorry for
> > > the confusion.)
> > > 
> > > What is "illegal": the HOMOGENEOUS flag being equal to true *and*
> > > having COD marker segments in tile-parts.
> > > 
> > > This is what the patch detects.
> > > 
> > > FFMPEG can decode such illegal codestream. Other decoders might
> > > not.
> > > 
> > > The question is: what should FFMPEG do? Should FFMPEG exit or warn
> > > and continue.
> > 
> > Does such a codestream actually exist ? I mean is this just a
> > hypothetical case
> > or something existing ?
> 
> This is more to stem the stream before anything happens because we were
> lax with parsing

If such files dont exist then being picky makes sense

thx

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

You can kill me, but you cannot change the truth.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 195 bytes
Desc: not available
URL: <https://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20240730/7fe22e14/attachment.sig>