summaryrefslogtreecommitdiffstats
path: root/audio/filter/af_rubberband.c
Commit message (Collapse)AuthorAgeFilesLines
* af_rubberband: actually fix deadlockMartin Herkt2015-02-121-1/+1
| | | | 371e5d0 missed this one
* af_rubberband: fix filter error deadlockwm42015-02-121-2/+2
| | | | | | | | | | | | rubberband_available() can return a negative value, which we assigned to a size_t variable, leading to the frame allocation to fail. This could spam "Error filtering frame.". (That it spams this instead of exiting should probably also be considered a bug.) At least in the realtime mode and in our case, a negative return value should not have any different meaning from a 0 return value, in particular because we call rubberband_get_samples_required() or set the "final" parameter for rubberband_process() to continue/stop processing.
* af_rubberband: change defaultsMartin Herkt2015-02-121-9/+6
| | | | | | | | | After some testing, I am fairly convinced that these defaults sound better than the previous settings. This also eliminates some issue with random crackling and noise. Also remove the `stretch` option since it has no effect in realtime mode.
* af_rubberband: fix breakagewm42015-02-111-1/+3
| | | | | | | | | The previous commit on this filter accidentally removed the RubberBandOptionProcessRealTime option. Without it, the lib prints a warning and passes the audio through. Also add the RubberBandOptionSmoothingOn option back. Though for some reason the output sounds still very wrong.
* af_rubberband: make all librubberband options configurablewm42015-02-111-4/+43
| | | | | | | librubberband exports a big load of options. Normally, the default settings (whether they're librubberband defaults or our defaults) should be sufficient, but since I'm not so sure about this, making it configurable allows others to figure it out for me.
* af_rubberband: attempt to fix audio position calculationwm42015-02-111-4/+17
| | | | | | | | | | | The problem here is that librubberband can buffer an arbitrary amount of data, but at the same time doesn't provide a way to query how much data is buffered. So we keep track of this manually, assuming that librubberband tries to reach the requested time ratio for input and output (which is probably true). The disadvantage is that rounding errors could accumulate over time. (Maybe it should try to round towards keeping the time ratio.)
* af_rubberband: always calculate and set delaywm42015-02-111-12/+11
| | | | Basically, add an if and reindent the block instead of exiting early.
* af_rubberband: improve EOF handlingwm42015-02-111-5/+11
| | | | | | In theory it could happen that draining on EOF happens incrementally, and then the unconditional reset could have dropped the remaining buffered audio.
* af_rubberband: pitch correction with librubberbandwm42015-02-111-0/+169
If "--af=rubberband" is used, librubberband will be used to speed up or slow down audio with pitch correction. This still has some problems: the audio delay is not calculated correctly, so the audio position jitters around by a few milliseconds. This will probably ruin video timing.