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 B70B943BE1 for ; Fri, 22 Jul 2022 15:37:48 +0000 (UTC) Received: from [127.0.1.1] (localhost [127.0.0.1]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTP id 8BC8F68AE86; Fri, 22 Jul 2022 18:37:45 +0300 (EEST) Received: from mail-oa1-f42.google.com (mail-oa1-f42.google.com [209.85.160.42]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTPS id 5F0F3688197 for ; Fri, 22 Jul 2022 18:37:43 +0300 (EEST) Received: by mail-oa1-f42.google.com with SMTP id 586e51a60fabf-10d6ddda695so6799982fac.0 for ; Fri, 22 Jul 2022 08:37:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=message-id:date:mime-version:user-agent:subject:content-language:to :references:from:in-reply-to:content-transfer-encoding; bh=oRlQNQufKBweyzzVWCmF7by4AsmdUoalKaBETODg62o=; b=EMe2PsbHwou7F/tlTERQ8lfnhjAuBttH3qqH0nQ5xlQOK3mqIh3kUl6CAqfzMSKDGg T1FbA1wre/QI9NfhyIxJXr0tCbO4lQvzPcrXitA2TrP7osm+6ZGfw8nNUkcwkATkr68k WlLXFWdP0Hd0udYm05DnAvuOuHxgaMK/gVVsmQl1iymB8rjWZ/2Wp0UHDUw0MbZl6GIw pQIPyWuxF43dPjYNJ+3DoRDeJmAVkvpEknJKHp2aj2wtjj/BoGWDoB95FMFldQGTgFm5 7HXohE9uNexRaidw0EmvVII89J2SbPzA0CPediFuXTMv85eKsbM2Et+GFQeWKscbggxn Qujw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent:subject :content-language:to:references:from:in-reply-to :content-transfer-encoding; bh=oRlQNQufKBweyzzVWCmF7by4AsmdUoalKaBETODg62o=; b=Mvl7K8QClnzwzTuzYPWCQMZI0tA96K1Je4iPSvJOM9/8BkRm5kz+KElxN1vvi+ta4F ZpGYcvnTcVHhrv4hsgPL7R4QYDYNA3b9eq4MEehjUchb8HRotbrGy3RnqkidFSEaBmL6 E3hpT4TvaB5QVxFYSUrc7sJ774/pTWJkvV9l5vNgmoqIvn8vsp2ZkcdnAm9mg5GjgJvB jfaMaxo/ZPYEKF5Cabk9SPkw+PdHb7MDgSLNS9hTIPu8T2lensEQYl6JPqAdDg+NktjB UBV08mVBi8hAIXd0QJmOSPkB1wtsS6kUzpLc+1Gm0RicKapFiVBPzSZC3t7UoVVlIJii 3xkA== X-Gm-Message-State: AJIora9lTKB88ZmBFWkeSN9MqG1qNqwmv5kyfzrTu6xwIUIMxcqeBt47 wikEpY45AiLtBCSbEjnkJcwaTjWfDPdFxA== X-Google-Smtp-Source: AGRyM1sRUKmE8HkbbOwYBmU7fgoYFBpIq+dwtvKk6GuQE/nhFEW/rMtIk5ywum6EhmvQZZHn8aj2SA== X-Received: by 2002:a05:6870:61cc:b0:10d:8a9e:4ebc with SMTP id b12-20020a05687061cc00b0010d8a9e4ebcmr6835905oah.155.1658504261616; Fri, 22 Jul 2022 08:37:41 -0700 (PDT) Received: from [192.168.0.11] ([186.136.131.204]) by smtp.gmail.com with ESMTPSA id w19-20020a056830111300b0061c514a3b7bsm2095054otq.10.2022.07.22.08.37.40 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 22 Jul 2022 08:37:40 -0700 (PDT) Message-ID: <2d7edac4-e974-ddec-3f9e-9f131d56ee96@gmail.com> Date: Fri, 22 Jul 2022 12:37:41 -0300 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.11.0 Content-Language: en-US To: ffmpeg-devel@ffmpeg.org References: <20220713175948.1955-1-jamrial@gmail.com> <8b484a4e-ba96-d54e-a4b5-84e1ee5e53f9@gmail.com> <3dfc3a5b-6b08-e36c-44e7-40cdf062cb3c@gmail.com> <970d0900-7e9c-5dcc-b306-aee15a84c2b6@gmail.com> From: James Almer In-Reply-To: Subject: Re: [FFmpeg-devel] [PATCH] avcodec/aacdec: don't force HE-AACv2 profile if no PS info is present 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-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Errors-To: ffmpeg-devel-bounces@ffmpeg.org Sender: "ffmpeg-devel" Archived-At: List-Archive: List-Post: On 7/22/2022 12:14 PM, Andreas Rheinhardt wrote: > James Almer: >> On 7/22/2022 11:56 AM, Andreas Rheinhardt wrote: >>> James Almer: >>>> On 7/22/2022 11:23 AM, Andreas Rheinhardt wrote: >>>>> James Almer: >>>>>> On 7/18/2022 10:57 AM, Andreas Rheinhardt wrote: >>>>>>> James Almer: >>>>>>>> On 7/14/2022 9:10 AM, Andreas Rheinhardt wrote: >>>>>>>>> James Almer: >>>>>>>>>> Should fix ticket #3361 >>>>>>>>>> >>>>>>>>>> Signed-off-by: James Almer >>>>>>>>>> --- >>>>>>>>>> This also needs an update to some fate ref samples i'll upload >>>>>>>>>> before >>>>>>>>>> pushing >>>>>>>>>> (fate-aac-al_sbr_ps_04_ur and fate-aac-al_sbr_ps_06_ur which >>>>>>>>>> are now >>>>>>>>>> decoded >>>>>>>>>> properly as he_aac mono, so the .s16 files need to be replaced). >>>>>>>>>> >>>>>>>>> >>>>>>>>> We have both a fixed-point AAC as well as a floating point AAC >>>>>>>>> decoder. >>>>>>>>> Is there actually a test that tests that the output they produce is >>>>>>>>> reasonably close? If not, could we make the test so that the same >>>>>>>>> file >>>>>>>>> is decoded once with the fixed-point and once with the >>>>>>>>> floating-point >>>>>>>>> decoder and then compared? >>>>>>>> >>>>>>>> That wouldn't help much, i think. Almost all changes to *_template.c >>>>>>>> files are going to affect both decoders, so a breakage would not be >>>>>>>> detected if you compare their output with each other as they would >>>>>>>> both >>>>>>>> exhibit it. >>>>>>>> >>>>>>> >>>>>>> I actually thought that the aac_fixed tests used checksums instead of >>>>>>> ref files; then changes and breakages would be visible by changes to >>>>>>> these files. Apparently I was wrong about that and the ref files are >>>>>>> used for both aac and aac_fixed. But a test like the one outlined >>>>>>> above >>>>>>> would nevertheless obviate the need for a new ref file. >>>>>> >>>>>> Judging by >>>>>> https://git.videolan.org/?p=ffmpeg.git;a=blob;f=tests/fate/aac.mak;h=1743428f544fad8946dba11dd4ecec0630eb70a6;hb=HEAD#l117 >>>>>> >>>>>> >>>>>> it seems at least for these samples the fixed decoder does not >>>>>> generate >>>>>> a decoded stream comparable to the float one, so I'll just upload a >>>>>> new >>>>>> raw pcm file. >>>>> >>>>> When I decode both of these streams with git master, the left >>>>> channel is >>>>> pretty much identical, yet the right channel of the fixed-point decoder >>>>> is silent and the right channel of the floating point decoder is not. >>>>> With this patch applied, the result are two mono streams that are >>>>> pretty >>>>> much identical: The test sample created by the floating-point decoder >>>>> works with the fixed-point decoder test (if one uncomments and modifies >>>>> the latter). So the issue with aac-al_sbr_ps_06_ur is not a reason to >>>>> upload new samples. >>>> >>>> Ok, can you suggest how to add a test that decodes with the fixed point >>>> decoder then compares that with the output of the float decoder? Is >>>> there a helper in fate.sh already for this? >>>> >>> >>> There is currently no helper in fate-run.sh for this. >> >> Yeah, figures that's the case. Can you suggest how one would work for this? >> > > A new function in fate-run.sh seems to be necessary. Given that a > similar situation exists for AC-3 we should not hardcode aac; instead it > should have two parameters for the float and the fixed decoder. Then it > should decode the input file twice and do the same comparison that the > current tests use (they use the oneoff method, which results in > do_tiny_psnr with MAXDIFF being called). > I think the tests for the fixed-point decoder (with checksums) should be > separate, so that one can test this without the floating-point decoder > being present. > >>> >>>>> >>>>> - Andreas >>>>> >>>>> PS: libfdk-aac produces a file that looks pretty much like the floating >>>>> point decoder from git master. Are you sure your patch is correct? >>>> >>>> Yes, they duplicate the single channel in the stream and output it as >>>> stereo, something that should be done by a filter if that's what the >>>> user wants. Decoding a mono sample should generate a mono stream. >>> >>> Not really. The channels are different. >> >> ./ffmpeg -c:a libfdk_aac -i ../samples/aac/al_sbr_ps_04_new.mp4 -af >> channelmap=channel_layout=mono:map=0 -f md5 - >> >> has the same result as >> >> ./ffmpeg -c:a libfdk_aac -i ../samples/aac/al_sbr_ps_04_new.mp4 -af >> channelmap=channel_layout=mono:map=1 -f md5 - >> >> Same with the samples in the ticket. >> > > This seems to be true for al_sbr_ps_04_new.mp4; but it is not true for > al_sbr_ps_06_new.mp4. So looks like nearly a hundred samples into al_sbr_ps_06_new.mp4 frames start containing PS info. With this patch the decoder properly decodes the first hundred as mono, but since the decoder is locked, it will keep decoding the stereo samples as mono. If i do > diff --git a/libavcodec/aacdec_template.c b/libavcodec/aacdec_template.c > index 4a0fa70ebc..9fd57043d6 100644 > --- a/libavcodec/aacdec_template.c > +++ b/libavcodec/aacdec_template.c > @@ -2576,8 +2576,8 @@ static int decode_extension_payload(AACContext *ac, GetBitContext *gb, int cnt, > ac->avctx->profile = FF_PROFILE_AAC_HE; > } > res = AAC_RENAME(ff_decode_sbr_extension)(ac, &che->sbr, gb, crc_flag, cnt, elem_type); > - if (ac->oc[1].m4ac.ps == 1 && ac->oc[1].status < OC_LOCKED && > - ac->avctx->ch_layout.nb_channels == 1) { > + if (ac->oc[1].m4ac.ps == 1 && ac->avctx->ch_layout.nb_channels == 1) { > + push_output_configuration(ac); > output_configure(ac, ac->oc[1].layout_map, ac->oc[1].layout_map_tags, > ac->oc[1].status, 1); > } Then it will properly start decoding the rest as stereo, but since ffmpeg.c already went with mono during configuration, it autoinserts a resample filter to keep outputting mono. Fun. > > - Andreas > _______________________________________________ > 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".