#11283 closed defect (fixed)
"aloop" filter somehow gave misalignment in 48 KHz Stereo WAV
Reported by: | Danny Weijermans | Owned by: | |
---|---|---|---|
Priority: | normal | Component: | avfilter |
Version: | git-master | Keywords: | aloop |
Cc: | Marton Balint, MasterQuestionable | Blocked By: | |
Blocking: | Reproduced by developer: | no | |
Analyzed by developer: | no |
Description
when using the aloop audio filter in ffmpeg
to produce a looped audio section,
it works sample accurate in 44.1kHz mono or stereo,
and in 48kHz mono.
But for some strange reason,
it's off (probably by 1?) when using a 48kHz stereo file.
I didn't test other sample-rates yet..
I'm including a 48kHz stereo wav file containing a pure 480Hz sine,
so you can test yourself.
I'm using for testing:
ffmpeg -y -i /Users/disjt/Desktop/s.wav -filter_complex "aloop=loop=4:start=48000:size=48000" s.wav
Attachments (1)
Change History (24)
by , 3 months ago
comment:1 by , 3 months ago
Keywords: | seek seeking added |
---|---|
Resolution: | → duplicate |
Status: | new → closed |
Summary: | ffmpeg aloop audio filter not working correctly in 48khz stereo wav → "aloop" filter somehow gave misalignment in 48 KHz Stereo WAV |
͏----
͏ https://ffmpeg.org/ffmpeg-filters.html#aloop
͏ Caveat: Your sample file is of 192,001 samples.
͏ Also reproducible with:
͏ ffmpeg -y -v debug -hide_banner -nostdin -nostats -f lavfi -i "sine=480:0:48000:d=4,volume=+18.063 dB" -af "aloop=4:start=48000:size=48000" "!.wav"
͏ Glitch at Sample #96768 (2.016 s), #144000 (3 s), #192000 (4 s), #240000 (5 s), #288000 (6 s).
͏ Output message of interest:
͏ "Non-monotonic DTS; previous: 96128, current: 96000; changing to 96128. This may result in incorrect timestamps in the output file."
comment:2 by , 3 months ago
Cc: | added |
---|---|
Component: | undetermined → avfilter |
Keywords: | aloop added; seek seeking removed |
Resolution: | duplicate |
Status: | closed → reopened |
Version: | unspecified → git-master |
No, this is a totally different issue, it has nothing to do with seeking. I will send a patch to fix this soon.
comment:4 by , 3 months ago
thanks Marton!
are there anymore combinations of sample-rates and channel-counts to be tested?
I wouldn't expect this to behave different with a certain combination of S/R and channel-count..
comment:5 by , 3 months ago
Cc: | added |
---|
͏ I guess Mono alone would suffice. (doesn't seem Channel# related)
͏ I think it might be essentially seeking issue:
͏ So probably just try changing the loop start point..?
comment:6 by , 3 months ago
I will investigate further, because I need it for some of my own code..
@Marton : you found the bug? ('I will send a patch to fix this soon.')
comment:7 by , 3 months ago
comment:10 by , 3 months ago
thanks so much, Marton!
Would it be possible to also shine your light
on my other ticket:
https://trac.ffmpeg.org/ticket/11281
would be great if you can find that 'bug' too..
comment:11 by , 3 months ago
Resolution: | → fixed |
---|---|
Status: | reopened → closed |
comment:14 by , 2 months ago
would this also be automatically updated in ffplay? or is this the same code?
comment:15 by , 2 months ago
͏ Likely the same bundle?
͏ (unsure MacOS's distribution handling)
͏ FF-series tools share significant portion of common codes.
comment:16 by , 2 months ago
updated ffmpeg,
and bug is gone: THANKS a lot!!
but I think ffplay is not updated yet on OSX..
and it could be used with a filter to realtime-play seemless loops ;)
let me know when this will be updated in ffplay as well..
thanks again for all your work!
regards, Danny
comment:17 by , 7 weeks ago
Dear Marton,
ffmpeg is working correct now.
I waited a while, but it's still not updated correctly in ffplay
(same filter can be used there as well..)
could you verify this?
thanks in advance!
regards,
Danny Weijermans
comment:18 by , 7 weeks ago
The issue fixed was in the libavfilter library. FFmpeg and FFplay are both using this library, so unless you use a static build of ffmpeg/ffplay or some OSX magic so different binaries somehow use different version of libraries, I don't see how that can happen.
I'd start with comparing the versions reported by the ffmpeg and ffplay command.
comment:19 by , 7 weeks ago
Hmmm,
ffmpeg = 7.1.3
ffplay = 7.1
would this be the problem?
how to upgrade ffplay?
isn't that part of the ffmpeg upgrade scheme?
I use 'brew ffmpeg upgrade' in Terminal..
comment:21 by , 7 weeks ago
yes, tried that, but doesn't work:
Unknown command..
even tried a reinstall of ffmpeg to no avail..
how to update ffplay correctly on osx??
comment:22 by , 7 weeks ago
͏ Probably something peculiar with the distribution...
͏ Ask the packages manager?
comment:23 by , 7 weeks ago
My bad:
I now upgraded to the latest ffmpeg
using: brew install ffmpeg --HEAD
(and removing any old installs)
and this also upgraded ffplay correctly
and now is working correctly as it should!
Yeah!!
pure 480Hz Sinewave 16bits 48kHz stereo wav file