From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from ffbox0-bg.mplayerhq.hu (ffbox0-bg.ffmpeg.org [79.124.17.100]) by master.gitmailbox.com (Postfix) with ESMTP id 7CA9C4AD08 for ; Wed, 19 Jun 2024 05:51:40 +0000 (UTC) Received: from [127.0.1.1] (localhost [127.0.0.1]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTP id 03CD268D6ED; Wed, 19 Jun 2024 08:51:37 +0300 (EEST) Received: from JPN01-OS0-obe.outbound.protection.outlook.com (mail-os0jpn01on2098.outbound.protection.outlook.com [40.107.113.98]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTPS id 5D8C668D641 for ; Wed, 19 Jun 2024 08:51:28 +0300 (EEST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=bv/cr0dIpNHya/Sj3L1ad2i0/YPVWxy/0j1W27m5J8K3zRYY/DdBSP5T3BvNMY4ibY4IKNIFJ3gh35bTl6UYkihpxqwDCwjlOpn+cwdQPx64Ro4YOd5B1uE8EMvSkbU5Seg+ti6LKa24flmgiO+6MsiP1xCoCxptcwzlKeaB/UnLkQVw8zNF1tSgxtJA+O1+DacUVdR3kZ0SLIay/33r9jrekk0Mzg5y754JFbN92lpgbQxAW95dMdlQpHP9OkRs/49WNYakCKha55dMKGt4442q/FN4oWiMNaRm7cPz1IIvBI04uiS27l0EpLdwp770xsvpoD/RCQJLZU2Qo+rkkA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=i1LHm6NZ/F3d73hSKV++qmMFZv35/x1+/0PERyJVF/A=; b=OKC2Vm6vhV+I0Qdsb/eHLgN7nvtGE7hGwrd6LjgBEoN98I+SvchXDtlFRqfVHt9o8BqkEzshhxHO7/dljjnf70kIxu7g40uwD6qAHk9VuHc3Xj4MyBfi1NFl25d0toGJ5NNixhEZQD1Sj+3rX7vmm8siBKRcjOheiGRTGsK0BCj7/T4nEhRXRrh9nhOs+m1AKTJKzwZuCfNwKPN3rQ8IIJC3yePwbmZrjJPaq67A+cbYKdBckrvga7tvwV/+y/559wH5P3K4U2OQVSEFeVF16nUwgNeRu/gTJCakmADsxwMv0APzG4raLr36v4rm3O0FBqNZICcuRWQGiU7RSAkMzw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=es.takushoku-u.ac.jp; dmarc=pass action=none header.from=es.takushoku-u.ac.jp; dkim=pass header.d=es.takushoku-u.ac.jp; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=takushoku.onmicrosoft.com; s=selector2-takushoku-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=i1LHm6NZ/F3d73hSKV++qmMFZv35/x1+/0PERyJVF/A=; b=fp2Khcg0jJrxntvDfBim0WhXjuua/HwdEGPDyKwgOApZfIXZUwshHrkWIhrZHlZo22ydFFUnEWM/k3QdT4S7oU+XObKphiAR8P1GGGroiuKvkhOPi1UyoEhOdr56lyWvUsAli+Uj6su21W16iuxveXMdTNH3k58dV4l/6yVzG70= Received: from OS0PR01MB6001.jpnprd01.prod.outlook.com (2603:1096:604:b7::12) by TYCPR01MB11227.jpnprd01.prod.outlook.com (2603:1096:400:3c4::9) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7698.19; Wed, 19 Jun 2024 05:51:23 +0000 Received: from OS0PR01MB6001.jpnprd01.prod.outlook.com ([fe80::181c:c1f4:9b58:f6cc]) by OS0PR01MB6001.jpnprd01.prod.outlook.com ([fe80::181c:c1f4:9b58:f6cc%6]) with mapi id 15.20.7698.017; Wed, 19 Jun 2024 05:51:23 +0000 From: WATANABE Osamu To: FFmpeg development discussions and patches Thread-Topic: [FFmpeg-devel] [PATCH v2] avcodec/jpeg2000dec: Add support for placeholder passes, CAP, and CPF markers Thread-Index: AQHawGr201/9J9Uul0+1PjO8EtvF2rHNlJUAgAED9gA= Date: Wed, 19 Jun 2024 05:51:22 +0000 Message-ID: <2F5DC492-B51B-4E93-9F45-CFCD813A6CBE@es.takushoku-u.ac.jp> References: <20240617040056.407824-1-owatanab@es.takushoku-u.ac.jp> In-Reply-To: Accept-Language: en-US, ja-JP Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=es.takushoku-u.ac.jp; x-ms-publictraffictype: Email x-ms-traffictypediagnostic: OS0PR01MB6001:EE_|TYCPR01MB11227:EE_ x-ms-office365-filtering-correlation-id: 7e845a7a-6219-4601-6afc-08dc9023d9b2 x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; ARA:13230037|366013|376011|1800799021|41320700010|4022899006|38070700015; x-microsoft-antispam-message-info: =?iso-2022-jp?B?ZmdzNktPSS9scUlsODk3RXppM1pKdlVzaDVoZ3BDQVRRQ1BCWlpmME1z?= =?iso-2022-jp?B?ZFowQlh4RURneGNkczBVSExEUlA4NHFYOXV0dnpNZFgwWWhoTXc1V0dO?= =?iso-2022-jp?B?NlR1NFJKY0pVUlZIUFlSd0REOGNkVHJsdXVMWm80QVRrN2tYd2h6L1V4?= =?iso-2022-jp?B?UzZ4cFdLbW54U2FCWHgybGZlYkZ0bzMwR2RmQkdOWWpoOGZqeko4Vmhi?= =?iso-2022-jp?B?M29VYWdwQmQzR0M3TlZYcHlqeTRmRHdIWjJIZGxJQ1BlcUJGUjJrZWVL?= =?iso-2022-jp?B?dno2N3N4TDBrWlNSVzViQ1dqZWM4RE41R2FDSkZrUWt3VVkzNUVtUy9z?= =?iso-2022-jp?B?QWdQdEtsc3dSQmk5UzVNSnhGbzBDS3ZYaFNNQzRZN3NDSnJ3SWVXampK?= =?iso-2022-jp?B?aG5VZzMwZVRNS3Fac1hXd3FiNWVhWGRGWStuK3Yvd28xaTJtTlprQUxy?= =?iso-2022-jp?B?dFZRMTRNMkh6Y2NEUE1lekFPQklqNmFXUEtqdzExTVN5Rmk4aFIycUMw?= =?iso-2022-jp?B?WWsrZGdTUDFvR1FKWWY5MHFxdzErSnF3V3pSQ0t4WkxSS281UHFiZWRl?= =?iso-2022-jp?B?OVQyNEJaUHczd2FMWVVMaWU3VDV6N0kyRHV3ZnJJdEY5UnlFQjBiWmpu?= =?iso-2022-jp?B?T3pFWndWenAxd2ZBellNd05mVHVwSFdQempmMmxmN2JXdkZ3cmZES0VW?= =?iso-2022-jp?B?cTZzcTI4ZHJjck5JUVFzTTNvd0lYaWgrdlhEd1dRaittT3Rhd1lJMER3?= =?iso-2022-jp?B?QVZaTnNOeDFweWJHbk83T2krTzhPK2tUcTlnY1RKbi9KSlNPRUYxUmtU?= =?iso-2022-jp?B?N2FqM3ptSmwxalQ5bFZOTnJkUVhESFVFTlcwNHVhclFkaytodXcwdGtH?= =?iso-2022-jp?B?bGZhZHRMWitEdUpFU3RwSFhITW1aODhDUjJtL1doekFuK0NiRkd1aUR0?= =?iso-2022-jp?B?ak5jWG1Vb3NVSWhqVm8zakQ1L1dwdCtvd3ZrT1JrV0ovSDZuTE5ReXNW?= =?iso-2022-jp?B?RjhmaGtmWWordFBPa2lYTC8rZW14Nm9RRGNBWkEvS1BJUWZjc3lZK0dR?= =?iso-2022-jp?B?alp3NlJlbEFJY1d1WXBhRlExdjJvS3pQT0VqUGU5V1haTHhyZlNOM3Nh?= =?iso-2022-jp?B?NGtvZ2xvc3ljZm1Gckt5NmxKUXVVazAyRE5DNzJkdkgzWi85YkdMSFJx?= =?iso-2022-jp?B?aUthblIxVklsbXd6TjFYdHM5c2lsMVQ0dlZCaEVSSjQyb2dCaXRvWkM4?= =?iso-2022-jp?B?am96ZGYxTzZ4ZFN2U2JtRDZwSWtaa0RkeDYvdEVqa1dMemxwTlcwSi81?= =?iso-2022-jp?B?YXFyQ1hEMHNlcmdGRE1EaWNwUG5xSFBJbTlOaUVqcHRjWEZYbVJJUXEr?= =?iso-2022-jp?B?NWN1NUhpSlpvb1pQTS9KT3pxcWJ3eWNMVEMrYzB3ZUFtVkNtTnhITGR2?= =?iso-2022-jp?B?V0pmSzBMd1pEK1VyTWFHaHprODhpckJhZlVBNm1uSVlhWnpRTUs3OVMx?= =?iso-2022-jp?B?Nml6THFxclFXS0ZnNkUvekgrYVkwSzZzQkxTRDNSWlBhYlZiVFVUSHpS?= =?iso-2022-jp?B?WUVadVk5VHJXWXcveExXYy93U2t1QkhBYXdCaER3U1NWQW9iZUduRThD?= =?iso-2022-jp?B?RDdtd0ZNcE1RaDgyczAya1JzMFBzNFFSd0YyaTBzQWQrMG5UVEpSNEVo?= =?iso-2022-jp?B?c08rYUh5Zm1oWDVxbElxVU9KMFF4NDM5VWllWlZtQit2dXlSSUovR0la?= =?iso-2022-jp?B?czA3clBhY3c3eDVtN1hIelhWK1cxVWlmTWZyS1hoa2RXS1BmRWY4cWVI?= =?iso-2022-jp?B?T3hkb2c1bk5Wb2lWMkVDQ21FNTVhNGJnY05EcHNIMm1lMmp0QStydVVk?= =?iso-2022-jp?B?bzMrSjhDc25XWE1aTC90UkFWWkd1N05qWVNiNzZEb1lMNDF0K1Nwcm5Z?= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:OS0PR01MB6001.jpnprd01.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230037)(366013)(376011)(1800799021)(41320700010)(4022899006)(38070700015); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?iso-2022-jp?B?aEFHV2VqZ1RHY1UxQ1lNQlluZkh6a3NMUllUd3N4ZXovM0dQMmkzV3Bw?= =?iso-2022-jp?B?K0tXeGJ4Z0M0ZWZEa0gwaEYxajF5Z2pHQlFuSXh0VXRXNEFVdWliaVp6?= =?iso-2022-jp?B?ajVrK0RsVExFY1VWMUR4bWRKSVA3Yjk2dG9aU2dNWDhWR21JQnN0WUpn?= =?iso-2022-jp?B?Qk9ROVRGamxGV3NLWEdFWVg5aUpPcXN1cGVNeWV5S0FNQnBKTlRyVnBT?= =?iso-2022-jp?B?YkMxaUxBemJsM01LOU5MSGJ1Q1h4YmNHWlBYNnlPZTlURHFZZi9JUnIx?= =?iso-2022-jp?B?OC94TGZXWXNmOXIvQ01neFIwK0J4dkJyNzVGUkcwVDdFRS9xL0RkeDRk?= =?iso-2022-jp?B?bFlodnhWd1pvN1FxSTU2c3JTandscVp1WnVTVDdXUmpiWHBTUmxCMGxu?= =?iso-2022-jp?B?bHkyMjdVK1VHcFFTT3NYbFdkRDdzS3dWNUVhQSs1MzI0OStEdytsam54?= =?iso-2022-jp?B?Skk4QUxoejZOdGpST0JCTXhMNGRESEtKenlLKzRKRTQ4UTk5NDNIYlY5?= =?iso-2022-jp?B?NlB6eWgyd3hDdE90aURlc05MMnJUV2x4c21aZjM2WDl6Q3g3eTBGVFVm?= =?iso-2022-jp?B?bURUR2FraWRzSUdpMk5GOEprUnBaQ2dmK1FQVHlocUJJWFVMdEJmbXc2?= =?iso-2022-jp?B?SGtBTVhCVUQ0VXJ0dFlzRzdwbTFxSVRXZk1nSmJ5VERPM0ZYUyt1bEtm?= =?iso-2022-jp?B?dFZNcWNvRHhVWkIvaDdESnJnZk9sK3laSHRZQkFWVVphb1JkMUN5emd4?= =?iso-2022-jp?B?VzV2VFNFUEVmVXBHZEltcHpwN01WelZRb2d3aU42QUM1MFZBMUhVMmo2?= =?iso-2022-jp?B?d05aVHZFRlMzRzN5ZGdYZUNDOExNVFl4OUZvdlNSWEl5c3llZDgzMTBR?= =?iso-2022-jp?B?N3M2NGRsUjZsd1pMZy9nYUhlRitmUDBTcVJySDRQWExEdGFrOFN2bE16?= =?iso-2022-jp?B?WTNpSXJMT0lCTmllUWY2S2tZbHFFWmh3dHFab2hYMXg5R1k1bU9zNEFy?= =?iso-2022-jp?B?Qm83STZlTmZ0L3NmSzV2WDczWWk3cWNyOHA2STRWcUIzamxwaEdTWXJ3?= =?iso-2022-jp?B?QXFjUEs1RERjbnJ6bGtCM0VXS2pBZkJGWWJ4dDFLcEVMcWVOeDFtOVND?= =?iso-2022-jp?B?ZkNDcXBacWk3cXcrOVVaUnJtenlJM0NtcmxJUE1YMXFSTG9Ea2ZjL0dU?= =?iso-2022-jp?B?T0QzNUZaWmI4WUJ2azV2L1Z1d21GbXR5T01oVVgxbGxxL1JmOUMzaGZL?= =?iso-2022-jp?B?dE5jZ1U1SFZxZU1ENzV1UjlxVUR6SEs2YzBaMUJVdEhybVhSQWkvK3lP?= =?iso-2022-jp?B?YmtPT2F3V1E1WDEweTJ2R1owL1p0bHFObXU5Tjc0MXZnODk2UmZJWWUr?= =?iso-2022-jp?B?ai9IU3E5Zkx5ak5HempmYjdyM2VscEExbDAxRGtTb0ZWQUtqeVRTQW5w?= =?iso-2022-jp?B?Wm9aMm9WWXo1cjg0Y0VIMDNOdzFyNG9QTFNobHRiVEtoNW9KWkZQN0VB?= =?iso-2022-jp?B?TndTU1FoQmcxaVZjRnlYYUwwcHYxZU5HbGFjdkVQNFJRNzFrZ3FESnRW?= =?iso-2022-jp?B?NGc1SVZ4MEFYam5CZ0E0QlFjNVBkVW55amRGL1AyRWVKZkE4NTM5UWNI?= =?iso-2022-jp?B?WEw0TU82NDdtcmhFeEVRSDdYTmJLRFJiMmZNdHJBREkxenBhOTVtTkw5?= =?iso-2022-jp?B?UkhmVEJ0dXNzT09FWDY1YVY5Z0NQMFBTMzNLemxCb0QwOCtyZEQyK1dR?= =?iso-2022-jp?B?ckpGODRVS2NpTjBGZkVaWGlzQTBmVzJmZUdQbUw5d2pZbERhZWZiUEM2?= =?iso-2022-jp?B?Ti91QUR2WWpZY1poL0kyQ1lBcE9uWThpa0VZTkN3WUN2SFlRcy9PSmtr?= =?iso-2022-jp?B?Sjl3SlRHYmVYanJhNDd1cFpWYjIyWTBJYjZydFJqdGUvdnltSldZd0V0?= =?iso-2022-jp?B?OEE3Z3BjanhIZktDeHpEN1pEZGpZK2RzdWIySmQ5Q2lza1hMb1VZNnBp?= =?iso-2022-jp?B?c2dvKzFvWDBMcy85bWxIbWpoOU5nVCt1Q2JWNUlSVms2eGhFVWNlNzY0?= =?iso-2022-jp?B?QXZYZ1VjOXFkZlFiam5ackttS0cvT0FjYzUvRE56dUpESlluYlRFZDdj?= =?iso-2022-jp?B?ODFVTFl0QjRVcXVmby8yUXNlak9JaHNPWmROZnNYQzU3QnJqSkY1Wlho?= =?iso-2022-jp?B?ait0WnAwMW5pa3JSTDF4MzR5UEh2SjlGVVZMa2ZnWEF3YmV0S1JQWlRx?= =?iso-2022-jp?B?cHJpenB1cDBUL2hyQTV4aFUzTWlCTzZ1bk82MkdybUFqeklwd1ZXSzcr?= =?iso-2022-jp?B?RTNXc3g0RUs1ME5QK2V4a1ZrUE1MM2xWWTdpZUtJWUplbzlJTXY1WTc3?= =?iso-2022-jp?B?b0Y0cWc9?= Content-ID: <48C9C4F57D0564468F0294563D8D269F@jpnprd01.prod.outlook.com> MIME-Version: 1.0 X-OriginatorOrg: es.takushoku-u.ac.jp X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: OS0PR01MB6001.jpnprd01.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 7e845a7a-6219-4601-6afc-08dc9023d9b2 X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Jun 2024 05:51:22.9778 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 853333e5-13b1-4738-ae04-bfb589cf2665 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: VuVBXfbn+TisIVuFJ923vOugiG9EKK4Q26K7JhPkUR2h5iyXgxcLfvcYohLNr8yJsfWfwKAuTqyPjQ5M4wxdbc7S/ZAucY+KZebxkDDfUrc= X-MS-Exchange-Transport-CrossTenantHeadersStamped: TYCPR01MB11227 Subject: Re: [FFmpeg-devel] [PATCH v2] avcodec/jpeg2000dec: Add support for placeholder passes, CAP, and CPF markers X-BeenThere: ffmpeg-devel@ffmpeg.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: FFmpeg development discussions and patches List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: FFmpeg development discussions and patches Cc: Pierre-Anthony Lemieux Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: ffmpeg-devel-bounces@ffmpeg.org Sender: "ffmpeg-devel" Archived-At: List-Archive: List-Post: First of all, I appreciate your kind review. I'm writing to discuss the changes and would like to hear your feedback on these. > On Jun 18, 2024, at 23:20, Tomas Hardin wrote: > > > It seems this patch combines a lot of things that might be better to > split into separate patches for easier review Agree. I will split this patch into several patches. For example, the set of patches includes changes: - only for HTJ2K (JPEG 2000 Part 15) - only for J2K (JPEG 2000 Part 1) - for both J2K and HTJ2K. Do you think it makes sense? > >> @@ -382,6 +391,9 @@ static int get_siz(Jpeg2000DecoderContext *s) >> } else if (ncomponents == 1 && s->precision == 8) { >> s->avctx->pix_fmt = AV_PIX_FMT_GRAY8; >> i = 0; >> + } else if (ncomponents == 1 && s->precision == 12) { >> + s->avctx->pix_fmt = AV_PIX_FMT_GRAY16LE; >> + i = 0; > > Could we handle 9 <= precision <= 16 while we're at it? > Yes. The native J2K decoder for both lossless and lossy J2K/HTJ2K codestreams can handle bpp from 9 to 16. This change is required to produce the decoded images for the ISO test codestreams defined in Part 4 (Conformance testing). >> @@ -408,6 +420,73 @@ static int get_siz(Jpeg2000DecoderContext *s) >> s->avctx->bits_per_raw_sample = s->precision; >> return 0; >> } >> +/* get extended capabilities (CAP) marker segment */ >> +static int get_cap(Jpeg2000DecoderContext *s, Jpeg2000CodingStyle >> *c) >> +{ >> + uint32_t Pcap; >> + uint16_t Ccap_i[32] = { 0 }; >> + uint16_t Ccap_15; >> + uint8_t P; >> + >> + if (bytestream2_get_bytes_left(&s->g) < 6) { >> + av_log(s->avctx, AV_LOG_ERROR, "Insufficient space for >> CAP\n"); >> + return AVERROR_INVALIDDATA; >> + } >> + >> + Pcap = bytestream2_get_be32u(&s->g); >> + s->isHT = (Pcap >> (31 - (15 - 1))) & 1; >> + for (int i = 0; i < 32; i++) { >> + if ((Pcap >> (31 - i)) & 1) >> + Ccap_i[i] = bytestream2_get_be16u(&s->g); >> + } >> + Ccap_15 = Ccap_i[14]; >> + if (s->isHT == 1) { >> + av_log(s->avctx, AV_LOG_INFO, "This is an HTJ2K codestream.\n"); >> + // Bits 14-15 >> + switch ((Ccap_15 >> 14) & 0x3) { > > Missing indentation > >> + case 0x3: >> + s->Ccap15_b14_15 = HTJ2K_MIXED; >> + break; >> + case 0x1: >> + s->Ccap15_b14_15 = HTJ2K_HTDECLARED; >> + break; >> + case 0x0: >> + s->Ccap15_b14_15 = HTJ2K_HTONLY; >> + break; >> + default: >> + av_log(s->avctx, AV_LOG_ERROR, "Unknown CCap >> value.\n"); >> + return AVERROR(EINVAL); >> + break; >> + } >> + // Bit 13 >> + if ((Ccap_15 >> 13) & 1) { >> + av_log(s->avctx, AV_LOG_ERROR, "MULTIHT set is not >> supported.\n"); >> + return AVERROR_PATCHWELCOME; >> + } >> + // Bit 12 >> + s->Ccap15_b12 = (Ccap_15 >> 12) & 1; >> + // Bit 11 >> + s->Ccap15_b11 = (Ccap_15 >> 11) & 1; >> + // Bit 5 >> + s->Ccap15_b05 = (Ccap_15 >> 5) & 1; >> + // Bit 0-4 >> + P = Ccap_15 & 0x1F; >> + if (!P) >> + s->HT_MAGB = 8; >> + else if (P < 20) >> + s->HT_MAGB = P + 8; >> + else if (P < 31) >> + s->HT_MAGB = 4 * (P - 19) + 27; >> + else >> + s->HT_MAGB = 74; >> + >> + if (s->HT_MAGB > 31) { >> + av_log(s->avctx, AV_LOG_ERROR, "Available internal >> precision is exceeded (MAGB> 31).\n"); >> + return AVERROR_PATCHWELCOME; >> + } >> + } > > Weird indentation > Thank you for catching these. I will fix them in the patch set. >> @@ -802,6 +881,15 @@ static int read_crg(Jpeg2000DecoderContext *s, >> int n) >> bytestream2_skip(&s->g, n - 2); >> return 0; >> } >> + >> +static int read_cpf(Jpeg2000DecoderContext *s, int n) >> +{ >> + if (bytestream2_get_bytes_left(&s->g) < (n - 2)) >> + return AVERROR_INVALIDDATA; >> + bytestream2_skip(&s->g, n - 2); >> + return 0; >> +} > > Don't we already have code for skipping markers we don't care about? > The `read_cpf()` function was added for consistency with the `read_crg()` function. We already have `bytestream2_skip(GetByteContext *g, unsigned int size)` that skips `size` bytes from the compressed data. Do you think it is better to replace those functions (= `read_cpf()` and `read_crg()`) with `bytestream2_skip()`? >> + >> /* Tile-part lengths: see ISO 15444-1:2002, section A.7.1 >> * Used to know the number of tile parts and lengths. >> * There may be multiple TLMs in the header. >> @@ -965,6 +1053,10 @@ static int init_tile(Jpeg2000DecoderContext *s, >> int tileno) >> comp->roi_shift = s->roi_shift[compno]; >> if (!codsty->init) >> return AVERROR_INVALIDDATA; >> + if (s->isHT && (!s->Ccap15_b05) && (!codsty->transform)) >> + av_log(s->avctx, AV_LOG_WARNING, "Transformation = 0 >> (lossy DWT) is found in HTREV HT set\n"); >> + if (s->isHT && s->Ccap15_b14_15 != (codsty->cblk_style >> 6) >> && s->Ccap15_b14_15 != HTJ2K_HTONLY) >> + av_log(s->avctx, AV_LOG_WARNING, "SPcod/SPcoc value does >> not match bit 14-15 values of Ccap15\n"); > > Do you have samples demonstrating the need to accept such broken files? > If not then we should probably error out Does `error out` mean that - Should we exit decoding here? - or should we replace AV_LOG_WARNING with AV_LOG_ERROR? > >> @@ -1704,7 +1989,7 @@ static int decode_cblk(const >> Jpeg2000DecoderContext *s, Jpeg2000CodingStyle *cod >> Jpeg2000T1Context *t1, Jpeg2000Cblk *cblk, >> int width, int height, int bandpos, uint8_t >> roi_shift) >> { >> - int passno = cblk->npasses, pass_t = 2, bpno = cblk->nonzerobits >> - 1 + roi_shift; >> + int passno = cblk->npasses, pass_t = 2, bpno = cblk->nonzerobits >> - 1; > > Won't this break files with ROI? I see there's some ROI stuff further > down so maybe not It won't break ROI decoding, and this change is mandatory when handling codestreams with placeholder passes. > >> @@ -2187,22 +2472,42 @@ static int >> jpeg2000_read_main_headers(Jpeg2000DecoderContext *s) >> if (!s->tile) >> s->numXtiles = s->numYtiles = 0; >> break; >> + case JPEG2000_CAP: >> + if (!s->ncomponents) { >> + av_log(s->avctx, AV_LOG_WARNING, "CAP marker segment >> shall come after SIZ\n"); > > SHALL -> we should be able to safely reject. Similarly with the other > errors. Unless we know of an encoder that produces broken files then > there's no reason to be lenient. And if such a broken encoder exists we > could try to get it fixed Does `safely reject` mean that we should replace AV_LOG_WARNING with AV_LOG_ERROR? or we should stop decoding here? > >> @@ -112,6 +112,13 @@ typedef struct Jpeg2000DecoderContext { >> Jpeg2000Tile *tile; >> Jpeg2000DSPContext dsp; >> >> + uint8_t isHT; // HTJ2K? > > Isn't it possible to mix Part 1 and HT in the same file? I know HTONLY > exists also It is possible to mix Part 1 and HT in the same tile-component. This mode is defined as MIXED in the spec of Part 15. There are three types of HT codestreams: - HTONLY - HTDECLARED - MIXED The spec says - "The HTONLY set is the set of HTJ2K codestreams where all code-blocks are HT code-blocks. The HTDECLARED set is the set of HTJ2K codestreams where all code-blocks within a given tile-component are either a) HT code-blocks, or b) code-blocks as specified in Rec. ITU-T T.800 | ISO/IEC 15444-1. The MIXED set is the set of all HTJ2K codestreams that are not in the HTDECLARED set." > >> @@ -406,6 +420,7 @@ static void recover_mag_sgn(StateVars *mag_sgn, >> uint8_t pos, uint16_t q, int32_t >> E[n] = 32 - ff_clz(v[pos][i] | 1); >> mu_n[n] = (v[pos][i] >> 1) + 1; >> mu_n[n] <<= pLSB; >> + mu_n[n] |= (1 << (pLSB - 1)); // Add 0.5 (reconstruction >> parameter = 1/2) > > Aren't there conformance files to catch these kinds of errors? I > remember looked at J2K a while back, and I think we should add such > files to FATE > Do you mean "errors" are the difference in pixel values between uncompressed and lossy compressed images? There are no specific conformance files to catch the difference in reconstruction parameter values. The value of the reconstruction parameter r is not limited to 1/2. We can use other values. However, the spec of Part 4 says the use of reconstruction parameter r = 1/2 will typically increase the ease of passing. Looking forward to seeing your thoughts. Best, Osamu > /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-request@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-request@ffmpeg.org with subject "unsubscribe".