> @Osamu Watanabe Can you update the patch to make FFMPEG exit when > encountering an illegal codestream, even if FFMPEG can theoretically > decode it?
I will update the patch in a few days. > On Jul 27, 2024, at 6:11, Pierre-Anthony Lemieux <p...@sandflow.com> wrote: > > On Fri, Jul 26, 2024 at 1:04?AM Tomas Hardin <g...@haerdin.se> wrote: >> >> tor 2024-07-25 klockan 17:06 -0700 skrev Pierre-Anthony Lemieux: >>> On Thu, Jul 25, 2024 at 2:17?AM Tomas Hardin <g...@haerdin.se> wrote: >>>> >>>> son 2024-07-21 klockan 14:07 +0900 skrev Pierre-Anthony Lemieux: >>>>> On Sat, Jul 20, 2024 at 5:12?PM Tomas Hardin <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 Hardin >>>>>>> <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 Hardin >>>>>>>>> <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. >>>> >>>> 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. >> >> Since it's illegal then we should complain and bail out. Users that >> *really* want it to keep going can change the code. > > @Osamu Watanabe Can you update the patch to make FFMPEG exit when > encountering an illegal codestream, even if FFMPEG can theoretically > decode it? > >> >> /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".
