On Sat, Jul 20, 2024 at 5:12 PM Tomas Härdin <g...@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 <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. > > 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. > > > > 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. > > Well yeah, users can choose to handle errors any way they see fit. We > could return AVERROR_INVALIDDATA but also set *got_frame to signal > "this frame is probably broken but here you go anyway" > > /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".
