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 <jamr...@gmail.com> >>>>>>> --- >>>>>>> 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. >> >> - 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. - 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-requ...@ffmpeg.org with subject "unsubscribe".
