use scaletempo2 by default

[532910]

Manpage says:

If --audio-pitch-correction (on by default) is used, playing with a speed higher than normal automatically inserts the scaletempo audio filter.

and if playback speed will be changed (with default [ ] { } controls for example) scaletempo will be used. But scaletempo2 sounds significant better. Is there something that prevents using scaletempo2 instead of scaletempo by default?

mpv 0.33.0 from Christian's repository (deb-multimedia), debian sid

[Hrxn]

I don't think so, but scaletempo2 (which is based on pitch correction taken from the Chromium repo, as far as I know) hasn't been merged that long ago, I think that's why.

[adisib]

I've been running a patch to auto-insert scaletempo2 since it was added, and have experienced no issues at all with it. In case that adds any confidence towards making this change.

[v-fox]

I've been running a patch to auto-insert scaletempo2 since it was added, and have experienced no issues at all with it. In case that adds any confidence towards making this change.

Could you link or post that patch here, please ? Or just forcing autoload by default with af-add=scaletempo2 in config would prevent it being auto-replaced with scaletempo ?

[jeeb]

Opened a PR to do this since the documentation notes scaletempo2 as being superior to scaletempo. Original scaletempo will at least for the short-term future stick around, but if we do not see any larger issues we'll start removing the original scaletempo filter.

Brief testing by a volunteer showed one issue being that apparently speeds below 0.25x silence the audio. Which does not block initial switch-over of the automatic filter logic.

[MerkaST]

Muting below 0.25x and above 8x speed is default behaviour and can be changed via filter options. There does seem to be a bug related to exceeding 8x when the maximum is set higher (which also has an open pull request in which I see you just posted as well).

[delthas]

Muting below 0.25x and above 8x speed is default behaviour and can be changed via filter options.

FWIW this is:

mpv --af=scaletempo2=min-speed=0.0 file.mp4

[lcksk]

I apologize if there might have been some noise. Compared to scaletempo, it appears that scaletempo2 lacks internal support for the af_format_s16 format, which is nearly ubiquitous in the Android platform for OMX or C2 audio decoders, whether they are software or hardware-based. Consequently, on the Android platform, a conversion is necessary from the decoder to scaletempo2, where the s16 format must be converted to floatp. If I remember correctly, in the audio output (AO) section, when writing data to the audiotrack, it must be converted back from floatp to s16. This format conversion seems to be quite CPU-intensive, potentially causing scaletempo2 to use nearly 10% more CPU resources than scaletempo, especially noticeable with 5.1 or 7.1 surround sound channels where the load increase is more pronounced. Therefore, as a default , is there a way to support s16 internally like scaletempo does, or would it require significant modifications that might be nearly impossible to implement?

[ruihe774]

I apologize if there might have been some noise. Compared to scaletempo, it appears that scaletempo2 lacks internal support for the af_format_s16 format, which is nearly ubiquitous in the Android platform for OMX or C2 audio decoders, whether they are software or hardware-based. Consequently, on the Android platform, a conversion is necessary from the decoder to scaletempo2, where the s16 format must be converted to floatp. If I remember correctly, in the audio output (AO) section, when writing data to the audiotrack, it must be converted back from floatp to s16. This format conversion seems to be quite CPU-intensive, potentially causing scaletempo2 to use nearly 10% more CPU resources than scaletempo, especially noticeable with 5.1 or 7.1 surround sound channels where the load increase is more pronounced. Therefore, as a default , is there a way to support s16 internally like scaletempo does, or would it require significant modifications that might be nearly impossible to implement?

You can try --audiotrack-pcm-float to avoid the conversion back to s16.

[lcksk]

@ruihe774
Thanks, this is meaningful to me. However, it still does not address the first half of the issue. The data in s16 format obtained from the Android C2 decoder must go through a converter to be transformed into floatp before it can be used with scaletempo2. Although this conversion is automatic, there is still a significant performance cost.

[ruihe774]

@ruihe774 Thanks, this is meaningful to me. However, it still does not address the first half of the issue. The data in s16 format obtained from the Android C2 decoder must go through a converter to be transformed into floatp before it can be used with scaletempo2. Although this conversion is automatic, there is still a significant performance cost.

I don't think the performance cost is mainly due to format conversion. Scaletempo2 is a much more complex algorithm than scaletempo. Did you try floatp input without format conversion for comparison?