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 <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.
Yeah, figures that's the case. Can you suggest how one would work 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.
./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.
- 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".
_______________________________________________
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".
