According to the suggestions for v4, I have posted the patch set v5. It is confirmed that the decoder with v5 passes all the conformance testing defined in ISO/IEC 15444-4.
Best, Osamu > On Jul 31, 2024, at 6:39, Michael Niedermayer <mich...@niedermayer.cc> wrote: > > On Tue, Jul 30, 2024 at 10:22:37PM +0200, Tomas Hardin 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 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. >>> >>> 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. > _______________________________________________ > 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".
