On Mon, Jul 15, 2024 at 10:33 PM Tomas Härdin <g...@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 <g...@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@ffmpeg.org > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > To unsubscribe, visit link above, or email > ffmpeg-devel-requ...@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-requ...@ffmpeg.org with subject "unsubscribe".
