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

[WATANABE Osamu]

I found that the subject for this v5 set of patches was wrong.
I have posted the v6 with the correction.

> On Aug 1, 2024, at 10:58, WATANABE Osamu <owatanab at es.takushoku-u.ac.jp> wrote:
> 
> 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 <michael at 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 <git at 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 <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 Hardin
>>>>>>>>> <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 Hardin
>>>>>>>>>>> <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.
>> _______________________________________________
>> ffmpeg-devel mailing list
>> ffmpeg-devel at ffmpeg.org
>> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>> 
>> To unsubscribe, visit link above, or email
>> ffmpeg-devel-request at ffmpeg.org with subject "unsubscribe".
> 
> 
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel at ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> 
> To unsubscribe, visit link above, or email
> ffmpeg-devel-request at ffmpeg.org with subject "unsubscribe".