Opened 3 months ago

Closed 3 months ago

Last modified 7 weeks ago

#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)

s.wav (750.2 KB ) - added by Danny Weijermans 3 months ago.
pure 480Hz Sinewave 16bits 48kHz stereo wav file

Download all attachments as: .zip

Change History (24)

by Danny Weijermans, 3 months ago

Attachment: s.wav added

pure 480Hz Sinewave 16bits 48kHz stereo wav file

comment:1 by MasterQuestionable, 3 months ago

Keywords: seek seeking added
Resolution: duplicate
Status: newclosed
Summary: ffmpeg aloop audio filter not working correctly in 48khz stereo wav"aloop" filter somehow gave misalignment in 48 KHz Stereo WAV

#11060

͏----

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

Last edited 3 months ago by MasterQuestionable (previous) (diff)

comment:2 by Marton Balint, 3 months ago

Cc: Marton Balint added
Component: undeterminedavfilter
Keywords: aloop added; seek seeking removed
Resolution: duplicate
Status: closedreopened
Version: unspecifiedgit-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:3 by MasterQuestionable, 3 months ago

͏    Looks somehow similar, nevertheless.

comment:4 by Danny Weijermans, 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 MasterQuestionable, 3 months ago

Cc: MasterQuestionable 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 Danny Weijermans, 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:8 by Danny Weijermans, 3 months ago

W O W !!!

comment:9 by Danny Weijermans, 3 months ago

How will I know when it has been 'patched' ?

comment:10 by Danny Weijermans, 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 Marton Balint, 3 months ago

Resolution: fixed
Status: reopenedclosed

comment:12 by Danny Weijermans, 3 months ago

thanks a lot, Marton!!

comment:13 by Danny Weijermans, 3 months ago

is the fixed version distributed already?

comment:14 by Danny Weijermans, 2 months ago

would this also be automatically updated in ffplay? or is this the same code?

comment:15 by MasterQuestionable, 2 months ago

͏    Likely the same bundle?
͏    (unsure MacOS's distribution handling)

͏    FF-series tools share significant portion of common codes.

comment:16 by Danny Weijermans, 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 Danny Weijermans, 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 Marton Balint, 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 Danny Weijermans, 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:20 by MasterQuestionable, 7 weeks ago

͏    Seems it was separate packages in MacOS.
͏    Try: brew ffplay upgrade

comment:21 by Danny Weijermans, 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 MasterQuestionable, 7 weeks ago

͏    Probably something peculiar with the distribution...
͏    Ask the packages manager?

comment:23 by Danny Weijermans, 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!!

Note: See TracTickets for help on using tickets.