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 C55BE4649A for ; Fri, 19 May 2023 10:31:57 +0000 (UTC) Received: from [127.0.1.1] (localhost [127.0.0.1]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTP id 6EEC768C17F; Fri, 19 May 2023 13:31:55 +0300 (EEST) Received: from mailout2.w1.samsung.com (mailout2.w1.samsung.com [210.118.77.12]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTPS id D647168BEDD for ; Fri, 19 May 2023 13:31:48 +0300 (EEST) Received: from eucas1p1.samsung.com (unknown [182.198.249.206]) by mailout2.w1.samsung.com (KnoxPortal) with ESMTP id 20230519103145euoutp02a412fa7998f92f8e7f802ca2f2d035da~ghNOumtRP0966109661euoutp02J for ; Fri, 19 May 2023 10:31:45 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 mailout2.w1.samsung.com 20230519103145euoutp02a412fa7998f92f8e7f802ca2f2d035da~ghNOumtRP0966109661euoutp02J DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=samsung.com; s=mail20170921; t=1684492305; bh=q51AxZLjp2aKUCQkcym3mf3ko/AwEYCWzU7g9VpOsQ0=; h=From:To:In-Reply-To:Subject:Date:References:From; b=V8Mh5VmgJ/fVJfCVlafbfEsm3QJKmGuKrnCoIwn553lYq8MQZKeUUxhikfA/Hx+5M /Col/7fwpRtijyin2ui7qJukXDv08UPJiv6eJ9RAPmYe911yfsWKkUfQqhMpvbSbVW mL8MpRkLJ7mdIPGXRit30FUgbV7fqNlO2umMn2Xo= Received: from eusmges3new.samsung.com (unknown [203.254.199.245]) by eucas1p1.samsung.com (KnoxPortal) with ESMTP id 20230519103145eucas1p16e8ec56b5b86061915dc4ad0fbccd2fb~ghNOomqP-1517515175eucas1p1N for ; Fri, 19 May 2023 10:31:45 +0000 (GMT) Received: from eucas1p1.samsung.com ( [182.198.249.206]) by eusmges3new.samsung.com (EUCPMTA) with SMTP id D0.A4.37758.11057646; Fri, 19 May 2023 11:31:45 +0100 (BST) Received: from eusmtrp2.samsung.com (unknown [182.198.249.139]) by eucas1p1.samsung.com (KnoxPortal) with ESMTPA id 20230519103144eucas1p129d76d6d513c38aee29c07fe3593f741~ghNOObgXT1517515175eucas1p1M for ; Fri, 19 May 2023 10:31:44 +0000 (GMT) Received: from eusmgms2.samsung.com (unknown [182.198.249.180]) by eusmtrp2.samsung.com (KnoxPortal) with ESMTP id 20230519103144eusmtrp2274cf03d3eec02ae1f44e94a327b59ac~ghNON74a31364013640eusmtrp2u for ; Fri, 19 May 2023 10:31:44 +0000 (GMT) X-AuditID: cbfec7f5-7ffff7000002937e-18-64675011c238 Received: from eusmtip1.samsung.com ( [203.254.199.221]) by eusmgms2.samsung.com (EUCPMTA) with SMTP id 13.AB.14344.01057646; Fri, 19 May 2023 11:31:44 +0100 (BST) Received: from AMDN5164 (unknown [106.210.132.171]) by eusmtip1.samsung.com (KnoxPortal) with ESMTPA id 20230519103144eusmtip1a8f39d2048b7c7593368b8b8546daf88~ghNOBMJFY0836108361eusmtip1M for ; Fri, 19 May 2023 10:31:44 +0000 (GMT) From: "Dawid Kozinski/Multimedia \(PLT\) /SRPOL/Staff Engineer/Samsung Electronics" To: "'FFmpeg development discussions and patches'" In-Reply-To: <8e7891de-b73b-0a67-4127-3525ecd2a3f4@gmail.com> Date: Fri, 19 May 2023 12:31:44 +0200 Message-ID: <021401d98a3d$1bacd510$53067f30$@samsung.com> MIME-Version: 1.0 X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQHCnP7kmTLnCzBaO975VYwBhpH/6wIu9pEHAhhhaDyvbQRgMA== Content-Language: pl X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrBIsWRmVeSWpSXmKPExsWy7djPc7qCAekpBnf/sVt8+3SG2YHR48+i zSwBjFFcNimpOZllqUX6dglcGUvvcRVstq5Yd3cZUwPjfcsuRg4OCQETiXNL07oYuTiEBFYw Spy9fJcRwpnEJPH80gwWCGcikHPnAZDDCdZxpXEzVGI5o8T6lk1gCSGBNiaJg2siQGw2gTyJ x5/XMoPYIgI+Et3r17OC2JwCthLHL59nArGFgWo2Pr3ABmKzCKhKbNs6F6yeV8BSYt/kdhYI W1Di5MwnYDazgJ7Es1OzoGxtiWULXzNDHKQg8fPpMlaIXU4S+9pAXgCpEZG48agF7B0JgV4O ibYHpxkhGlwkLm5dBdUsLPHq+BZ2CFtG4v/O+UyQcCmWONTvAGHWSBz6kQ5RYS3xtvE41BRH iQ8TV7BBlPBJ3HgrCLGVT2LStunMEGFeiY42IQhTRaKvUwyiUUri6bI5zBMYlWYheXEWkhdn IXlxFpJXFjCyrGIUTy0tzk1PLTbOSy3XK07MLS7NS9dLzs/dxAhMDKf/Hf+6g3HFq496hxiZ OBgPMUpwMCuJ8Ab2JacI8aYkVlalFuXHF5XmpBYfYpTmYFES59W2PZksJJCeWJKanZpakFoE k2Xi4JRqYEpzNAwVjlgqlyWffVN2+vLf+zI2Xfy7Rej2vGtvY1bfZhff9626U1JP4QPfC44e V7cp/sFXJLQ2ahX56/NFnvsjYnRFMyvxlOfUMx+ZmjZ41Mv0cNTPzdi6vvD0gqkz80o/Bl3z r3DS/ds9tXvljQV/FpyRf1+XtFfyKkN3ptnf+CdCW1SDlL/k1D++LnxGaleB2CGNCxHfp8dU Ttrf7pAQsDSRb+bNGROnV7S+iXY6487f9LHAViPZNKKaY2X8mf7U/YrPf/yRaZ9vvthAuTGz 65bDmqiaspJgn6nXQgyc2MTO9EdWs6Xv0m7ZlLHSL4LzB2tOHt+qtIkKi3+vfFu73lnBzj5C vI+5XsZNiaU4I9FQi7moOBEADqPjUnsDAAA= X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrPLMWRmVeSWpSXmKPExsVy+t/xu7oCAekpBm8u6Vp8+3SG2YHR48+i zSwBjFF6NkX5pSWpChn5xSW2StGGFkZ6hpYWekYmlnqGxuaxVkamSvp2NimpOZllqUX6dgl6 GdsOVRac0KyY9OcCWwPjZMUuRk4OCQETiSuNm1m6GLk4hASWMkp829XOCJGQkli6dBGULSzx 51oXG0RRC5PEz3U/WEASbAI5EmtnT2QCsUUEfCS6169nhSjayygxafUHZpAEp4CtxPHL58GK hIEa7n88BtbMIqAqsW3rXLAaXgFLiX2T21kgbEGJkzOfgNnMAgYSSxb+YoKwtSWWLXzNDHGR gsTPp8tYIRY7Sexru8sIUSMiceNRC+MERqFZSEbNQjJqFpJRs5C0LGBkWcUoklpanJueW2yk V5yYW1yal66XnJ+7iREYE9uO/dyyg3Hlq496hxiZOBgPMUpwMCuJ8Ab2JacI8aYkVlalFuXH F5XmpBYfYjQF+m0is5Rocj4wKvNK4g3NDEwNTcwsDUwtzYyVxHk9CzoShQTSE0tSs1NTC1KL YPqYODilGpi6D3Y+TGQtEZ50UejHoq2GB1dZ2GmYKrRtm36QQ/fsy1LfHTcPeTdLeLqYZHa9 8pq6mZG5+viBuJizzdE3j/ewhuZu4spS57w1YZEul+HWuakOgbai+/e2yeT7WhbuEa+Tnc2z TFPd4rDStXf1nHckNPQfe/mqiYr/2RGevGu/Y/tyxbPTvD6J2jcpTr0Ytr3gpOvOcxFts0MV z+3U2xYy59/dmJ1RRQf5Xqps9rly8Ct39EupWd4z174q8/gbs5n3vozQ7ZSlsxeyt6eGmLxk qD86sfzqTPXL7Io953erTzuXHR92yPDdmgke/r926OXf3JGhlt57cQ7rPPG46WzzeLdqmjIY PtkxtWJZtIQSS3FGoqEWc1FxIgCCx3bCEgMAAA== X-CMS-MailID: 20230519103144eucas1p129d76d6d513c38aee29c07fe3593f741 X-Msg-Generator: CA X-RootMTR: 20230427120256eucas1p2bfa746850f5d2446b501dcd149a6ee8e X-EPHeader: CA CMS-TYPE: 201P X-CMS-RootMailID: 20230427120256eucas1p2bfa746850f5d2446b501dcd149a6ee8e References: <20230427120245.1151-1-d.kozinski@samsung.com> <8e7891de-b73b-0a67-4127-3525ecd2a3f4@gmail.com> Subject: Re: [FFmpeg-devel] [PATCH v22 02/10] avcodec/evc_parser: Added parser implementation for EVC format 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 Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable Errors-To: ffmpeg-devel-bounces@ffmpeg.org Sender: "ffmpeg-devel" Archived-At: List-Archive: List-Post: > -----Original Message----- > From: ffmpeg-devel On Behalf Of James > Almer > Sent: =B6roda, 10 maja 2023 22:21 > To: ffmpeg-devel@ffmpeg.org > Subject: Re: [FFmpeg-devel] [PATCH v22 02/10] avcodec/evc_parser: Added > parser implementation for EVC format > = > On 4/27/2023 9:02 AM, Dawid Kozinski wrote: > > - Added constants definitions for EVC parser > > - Provided NAL units parsing following ISO_IEC_23094-1 > > - EVC parser registration > > > > Signed-off-by: Dawid Kozinski > > --- > > libavcodec/Makefile | 1 + > > libavcodec/evc.h | 155 ++++ > > libavcodec/evc_parser.c | 1497 > +++++++++++++++++++++++++++++++++++++++ > > libavcodec/parsers.c | 1 + > > 4 files changed, 1654 insertions(+) > > create mode 100644 libavcodec/evc.h > > create mode 100644 libavcodec/evc_parser.c > = > There seems to have been a regression in this version compared to v20. > Try to compile with the libxevd decoder disabled and open a raw file (not mp4). > = > Whereas with v20 i was getting > = > > Input #0, evc, from 'akiyo_cif.evc': > > Duration: N/A, bitrate: N/A > > Stream #0:0: Video: evc (Baseline), none, 352x288, 25 fps, 25 tbr, > > 1200k tbn > = > I'm now getting > = > > Input #0, evc, from 'akiyo_cif.evc': > > Duration: N/A, bitrate: N/A > > Stream #0:0: Video: evc (Baseline), none, 555902582x0, 25 fps, 25 > > tbr, 1200k tbn > = > It seems that the problem showed up because you moved the parameter sets to > stack to skip allocating them, and you no longer check if they exist or were > parsed by looking at slice_pic_parameter_set_id and such. > = > That aside, i looked at the EVC spec and noticed that the "raw" format in Annex- > B is unlike that of H.26{4,5,6}: There's no start code, and instead there's a NAL > size prefix, which sounds like the isobmff way of encapsulating NALUs. > I also noticed that the syntax for nal_unit() contains an > emulation_prevention_three_byte element, but there's no explanation for it in > the semantics section. Its existence in H.26* is to prevent parsers from > misinterpreting a sequence of two or more zeroes as a potential start code, but > that's clearly not the case here, so why is it defined and present at all? > = > What this means is that the parser can't be made to assemble an AU. If you feed > it data starting from the middle of a NAL, it will not be able to sync to the start > of the next NAL because all it looks for is a four byte size value and will accept > the very first four bytes its fed as one. > Since i doubt the spec can be changed at this point to amend this oversight, the > AU assembling will have to occur in the evc demuxer, much like we do with AV1 > (both raw obu and Annex-B formats as defined in the corresponding spec), and > the parser be limited to parse fully assembled NALs with parse_nal_units(). According to your last EVC review: We have re-implemented the EVC demuxer to assemble Access Units (AUs) and pass them further, while the EVC parser is limited to parsing complete NAL units provided in consecutive AUs. However, before we create a new patchset, we would like to discuss some things because we believe this solution is not optimal. According to the EVC documentation, "Each access unit contains a set of VCL NAL units that together compose a primary coded picture." This means that to find the boundaries of an AU, we need to identify all the NAL units that contain data for a single encoded picture. In our case, to determine whether the next VCL NAL unit contains data for the same picture as the previous VCL NAL unit or for a different encoded picture, we need information contained in the NAL units. We need to extract certain data from NAL units like SPS and PPS, as well as from the Slice Headers of VCL NAL units. In other words, this implies that parsing NAL units is required for this purpose. It may not be as extensive parsing as in the EVC parser, but still, there is a significant amount of parsing involved, which adds some overhead. Another question is whether the demuxer is the appropriate place for parsing NAL units? I guess it's not. Perhaps it would be better if the demuxer prepared complete NAL units instead of complete AUs. The EVC parser would then receive complete NAL units, and since it already parses them, we have the necessary information for preparing complete AUs at no extra cost. Preparing complete NAL units is definitely simpler than preparing complete AUs. It only requires finding the length of the NAL unit and putting that amount of data from the input into the AVPacket. Please let me know your thoughts on this. > _______________________________________________ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > https://protect2.fireeye.com/v1/url?k=3Decf2ce2f-8d79db0f-ecf34560- > 74fe485fb347-2d1651bc168e08a9&q=3D1&e=3D5d9c25e1-dfe9-4e94-af2d- > a9f88fe66d4f&u=3Dhttps%3A%2F%2Fffmpeg.org%2Fmailman%2Flistinfo%2Fffmpe > g-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".