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.
_______________________________________________
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".
