Opened 2 years ago

Closed 3 weeks ago

Last modified 2 weeks ago

#6891 closed defect (fixed)

FFplay: WASAPI can't initialize audio client (zeranoe's FFmpeg 3.4 MS Windows binaries)

Reported by: unknown Owned by:
Priority: normal Component: ffplay
Version: git-master Keywords: win
Cc: cus Blocked By:
Blocking: Reproduced by developer: no
Analyzed by developer: no

Description

Summary of the bug:
When I try to play an audio file with ffplay, it fails with errors such as this one:

SDL_OpenAudio (1 channels, 48000 Hz): WASAPI can't initialize audio client: No se ha llamado a CoInitialize.

How to reproduce:

C:\Users\Public\Documents>ffplay.exe C:\Users\Public\Documents\test.mp3
ffplay version 3.4 Copyright (c) 2003-2017 the FFmpeg developers
  built with gcc 7.2.0 (GCC)
  configuration: --disable-static --enable-shared --enable-gpl --enable-version3 --enable-sdl2 --enable-bzlib --enable-fontconfig --enable-gnutls --enable-iconv --enable-libass --enable-libbluray --enable-libfreetype --enable-libmp3lame --enable-libopenjpeg --enable-libopus --enable-libshine --enable-libsnappy --enable-libsoxr --enable-libtheora --enable-libtwolame --enable-libvpx --enable-libwavpack --enable-libwebp --enable-libx264 --enable-libx265 --enable-libxml2 --enable-libzimg --enable-lzma --enable-zlib --enable-gmp --enable-libvidstab --enable-libvorbis --enable-cuda --enable-cuvid --enable-d3d11va --enable-nvenc --enable-dxva2 --enable-avisynth --enable-libmfx
  libavutil      55. 78.100 / 55. 78.100
  libavcodec     57.107.100 / 57.107.100
  libavformat    57. 83.100 / 57. 83.100
  libavdevice    57. 10.100 / 57. 10.100
  libavfilter     6.107.100 /  6.107.100
  libswscale      4.  8.100 /  4.  8.100
  libswresample   2.  9.100 /  2.  9.100
  libpostproc    54.  7.100 / 54.  7.100
Input #0, mp3, from 'C:\Users\Public\Documents\test.mp3':  0B f=0/0
  Metadata:
    encoder         : Lavf53.32.100
  Duration: 01:00:00.26, start: 0.000000, bitrate: 128 kb/s
    Stream #0:0: Audio: mp3, 48000 Hz, stereo, s16p, 128 kb/s
SDL_OpenAudio (2 channels, 48000 Hz): WASAPI can't initialize audio client: No se ha llamado a CoInitialize.

SDL_OpenAudio (1 channels, 48000 Hz): WASAPI can't initialize audio client: No se ha llamado a CoInitialize.

SDL_OpenAudio (2 channels, 44100 Hz): WASAPI can't initialize audio client: No se ha llamado a CoInitialize.

SDL_OpenAudio (1 channels, 44100 Hz): WASAPI can't initialize audio client: No se ha llamado a CoInitialize.

No more combinations to try, audio open failed
Failed to open file 'C:\Users\Public\Documents\test.mp3' or configure filtergraph
    nan    :  0.000 fd=   0 aq=    0KB vq=    0KB sq=    0B f=0/0

Last working version: ffplay from ffmpeg-20170921-183fd30-win32-shared

There is a workaround to this issue, according to this question at stackoverflow:

A workaround is to specify an alternate output driver.
Set SDL_AUDIODRIVER environment variable value to the
driver you want to use. Under windows 7, directsound
and winmm both solved my issue.

And there is a proposed fix to this issue at ffmpeg.zeranoe.com forum:

Re: I can't run ffplay because of errors of SDL_OpenAudio

Post by jackyxinli » Wed Nov 29, 2017 2:43 am 

I find a new method to resolve this problem, the ffplay
not call CoInitialize according to error message. So,
add code to call CoInitialize, ffplay can work. And the
same time, I checked SDL2's source code, the WASAPI
module doesn't set member ProvidesOwnCallbackThread, so
SDL2 should call CoInitialize before open audio device.
But no idea why ffplay gives us this error message.

here is my modification look like.

#ifdef _WIN32
#include <windows.h>
#endif

static int audio_open(void *opaque, int64_t wanted_channel_layout, int wanted_nb_channels, int wanted_sample_rate, struct AudioParams *audio_hw_params)
{
......
#ifdef _WIN32
CoInitialize(NULL);
#endif
while (!(audio_dev = SDL_OpenAudioDevice(NULL, 0, &wanted_spec, &spec, SDL_AUDIO_ALLOW_FREQUENCY_CHANGE | SDL_AUDIO_ALLOW_CHANNELS_CHANGE))) {
......
}

Attachments (1)

ffplay_win32_call_coinitialize_before_opening_audio_device.patch (856 bytes) - added by unknown 2 years ago.
FFplay: win32: call CoInitialize? before opening audio device

Download all attachments as: .zip

Change History (17)

comment:1 Changed 2 years ago by unknown

  • Keywords sdl added
  • Version changed from unspecified to 3.4

Error message (in english language):

SDL_OpenAudio (1 channels, 48000 Hz): WASAPI can't initialize audio client: CoInitialize has not been called.

comment:2 follow-up: Changed 2 years ago by cehoyos

  • Keywords win added; ffplay windows win32 sdl sdl_openaudio wasapi coinitialize removed

Does it also fail with current FFmpeg?

comment:3 in reply to: ↑ 2 Changed 2 years ago by unknown

Replying to cehoyos:

Does it also fail with current FFmpeg?

Yes, this error happens also with current FFmpeg git (tested with zeranoe's FFmpeg build ffmpeg-20171204-71421f3-win32-shared)

comment:4 Changed 2 years ago by cehoyos

  • Version changed from 3.4 to git-master

Changed 2 years ago by unknown

FFplay: win32: call CoInitialize? before opening audio device

comment:5 Changed 23 months ago by cus

  • Cc cus added

This seems like an issue which should be fixed in SDL instead of ffplay, no?

comment:6 Changed 23 months ago by mrchangkun

any update?? ffmpeg-20180113-c51301d-win64-shared still error with wasapi cant initialize audio client.

comment:7 Changed 23 months ago by cehoyos

Did you already report the issue to SDL?

comment:8 Changed 19 months ago by t.rapp

Found something related which has been posted to SDL here:
https://discourse.libsdl.org/t/sdl-openaudio-wasapi-can-t-initialize-audio-client-coinitialize-has-not-been-called/23437
but seems like there is no response yet.

comment:9 Changed 19 months ago by t.rapp

Another SDL post related to the issue:
https://discourse.libsdl.org/t/ffplay-not-work-with-sdl/23542

When looking up the implementation of WIN_CoInitialize() in SDL code some comment can be found:

If you need multi-threaded mode, call CoInitializeEx?() before SDL_Init()

So possibly this needs to be fixed on FFmpeg side by adding a call CoInitializeEx(NULL, COINIT_MULTITHREADED) at ffplay start-up. (Unfortunately my dev environment doesn't contain SDL2 for cross-compilation to Windows so I cannot test this).

comment:10 Changed 19 months ago by Gyan

Can you post a mbox patch against master? I can test it here. At present, I set a env variable before running ffplay.

comment:11 follow-up: Changed 19 months ago by CoRoNe

Could this be an issue with SDL 2.0.7? SDL 2.0.8 was released on the 1st of march this year and has "Implemented WASAPI support on Windows UWP" in the changelog.
Zeranoe's latest build (as well as mine) is built with SDL 2.0.8, so you could give it a try.

comment:12 in reply to: ↑ 11 Changed 19 months ago by Gyan

Replying to CoRoNe:

Could this be an issue with SDL 2.0.7? SDL 2.0.8 was released on the 1st of march this year and has "Implemented WASAPI support on Windows UWP" in the changelog.
Zeranoe's latest build (as well as mine) is built with SDL 2.0.8, so you could give it a try.

No, same behaviour with Zeranoe's build.

comment:13 Changed 19 months ago by cus

Try to get some feedback from SDL about this. Also it would be good to know which fix should be used if any:

CoInitializeEx(NULL, COINIT_MULTITHREADED)

or simply

CoInitialize(NULL);

They seem to do different things...

comment:14 follow-up: Changed 3 weeks ago by Balling

  • Resolution set to fixed
  • Status changed from new to closed

comment:15 in reply to: ↑ 14 ; follow-up: Changed 2 weeks ago by Kdmeizk

Replying to Balling:

Obviously fixed. http://git.videolan.org/?p=ffmpeg.git;a=commitdiff;h=d68a557df4937b695a5f6a14877d92647be95aaa also see #6721

ffmpeg-20191101-53c21c2

The problem is not fixed on Windows 7.

comment:16 in reply to: ↑ 15 Changed 2 weeks ago by Balling

Replying to Kdmeizk:

Replying to Balling:

Obviously fixed. http://git.videolan.org/?p=ffmpeg.git;a=commitdiff;h=d68a557df4937b695a5f6a14877d92647be95aaa also see #6721

ffmpeg-20191101-53c21c2

The problem is not fixed on Windows 7.

Windows 7 is End of Life. So we should not support it anymore anyway, I suppose. And it is the problem of Microsoft, in particular why they did not port the fix to 7.

Note: See TracTickets for help on using tickets.