ao: proper end_time calulation & ao_read_frame()

[ruihe774]

This PR fixes the calculation of ao->buffer_state->end_time_ns when pad_silence == false and partial data is returned for pull-based AO. Previously, end_time_ns was calculated by driver delay plus the duration of requested sample count. It was not accurate if pad_silence == false giving the number of returned samples can vary. To fix this issue, this PR introduces an API change that ao_read_data() and ao_read_data_converted() now accepts start_time_ns, which is the the expected delay until the first sample reaches the speakers, instead of out_time_ns. ao_read_data() then updates ao->buffer_state->end_time_ns using start_time_ns and the actual sample count got from the buffer.

This PR also introduces a new API ao_read_frame() for pull-based AO. Now pull-based AO can directly get mp_aframe. For AO that can handle data with variable size, this new API bypass the copying of audio data from audio frames into data buffer in read_buffer(). A zero-copy ao_avfoundation that utilizes ao_read_frame() is included in this PR.

This PR depends on #13967. Before it is merged, I think I'd better keep this PR a draft, though my work is done already.

[github-actions[bot]]

Download the artifacts for this pull request:

Windows

• mpv-i686-w64-mingw32
• mpv-x86_64-w64-mingw32

macOS

• mpv-macos-14-arm
• mpv-macos-13-intel
• mpv-macos-12-intel

[ruihe774]

TBH I just forgot this for some while :)

I rebased this and added some extra commits, including:

• A rewritten playing_audio_pts() which reports pts properly during playback speed changes; this allows more accurate AV compensation in video-sync=display-*.
• A new option --avfoundation-buffer.

@sfan5 could you plz review this?

BTW, @sfan5 I'm not very satisfied with current implementation of AV compensation of video-sync=audio:

https://github.com/mpv-player/mpv/blob/3e499ff3bc3cdd668efc41974c8cdd64d9a99178/player/video.c#L621

When buffered_audio and delay is large (2 second when using ao_avfoundation), changing the video_speed is bound to cause a jump in time_frame. As the result, the video gets stalled (video_pts stops advancing) while audio continues; it is the root cause of many desync cases in ao_avfoundation.