Dear ffmpeg team & users, I'm using the MonoGame framework for development. It uses ffmpeg to ADPCM encode wave files. Playback is done using xaudio. Problem is that ffmpeg always uses a blocksize auf 1024. xaudio only supports block sizes of up to 512. It would be good to make the blocksize configurable to make it compatible. Someone else from the MonoGame community already created an issue for this: https://trac.ffmpeg.org/ticket/6585 Do you think someone will build a fix for this in the near future? Any suggestions for a workarround? Best, Martin
2018-01-02 11:31 GMT+01:00 Martin Wahnschaffe <wahnschaffe@gmail.com>:
Problem is that ffmpeg always uses a blocksize auf 1024. xaudio only supports block sizes of up to 512.
What is xaudio? (Patch welcome.) Carl Eugen
xaudio (more precisely XAudio2) is Microsofts replacement for DirectAudio - the audio component of DirectX. Carl Eugen Hoyos <ceffmpeg@gmail.com> schrieb am Di., 2. Jan. 2018, 13:09:
2018-01-02 11:31 GMT+01:00 Martin Wahnschaffe <wahnschaffe@gmail.com>:
Problem is that ffmpeg always uses a blocksize auf 1024. xaudio only supports block sizes of up to 512.
What is xaudio?
(Patch welcome.)
Carl Eugen _______________________________________________ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-user
To unsubscribe, visit link above, or email ffmpeg-user-request@ffmpeg.org with subject "unsubscribe".
2018-01-02 17:12 GMT+01:00 Martin (Imagine Earth) <martin@imagineearth.info>:
xaudio (more precisely XAudio2) is Microsofts replacement for DirectAudio - the audio component of DirectX.
So the files work with old Windows but not with Windows X? Please do not top-post here, Carl Eugen
It means the Adpcm files generated by ffmpeg aren't usable with XAudio2. XAudio2 is a low-level audio API provided by microsoft and part of windows since Windows 7. Current version is XAudio2.9 in windows 10. What does top-post mean? Carl Eugen Hoyos <ceffmpeg@gmail.com> schrieb am Di., 2. Jan. 2018 um 22:06 Uhr:
2018-01-02 17:12 GMT+01:00 Martin (Imagine Earth) < martin@imagineearth.info>:
xaudio (more precisely XAudio2) is Microsofts replacement for DirectAudio - the audio component of DirectX.
So the files work with old Windows but not with Windows X?
Please do not top-post here, Carl Eugen _______________________________________________ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-user
To unsubscribe, visit link above, or email ffmpeg-user-request@ffmpeg.org with subject "unsubscribe".
On Wed, Jan 3, 2018, at 1:19 AM, Martin (Imagine Earth) wrote:
What does top-post mean?
I'm confident you could have found multiple answers with a simple search, but our Mailing List FAQ has a link to an explanation: <https://ffmpeg.org/mailing-list-faq.html#What-is-top_002dposting_003f-1>
On Wed, Jan 03, 2018 at 10:19:47 +0000, Martin (Imagine Earth) wrote:
What does top-post mean?
Lou kindly pointed you to Google and other docs, and I may add: A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing in e-mail? Moritz
On Tue, Jan 02, 2018 at 10:31:48 +0000, Martin Wahnschaffe wrote:
Problem is that ffmpeg always uses a blocksize auf 1024. xaudio only supports block sizes of up to 512. It would be good to make the blocksize configurable to make it compatible.
Have you tried the MS-ADPCM output of sox? I haven't gotten around to checking what it does, and have a hard time unterstanding the meaning of block size in the ADPCM context, and interpreting ffprobe's output. How could I test with Xaudio2, assuming I have access to Windows?
Do you think someone will build a fix for this in the near future? Any suggestions for a workarround?
Perhaps it's just a matter of changing the BLKSIZE macro in libavcodec/adpcm.h, if you only want to use it for adpcm_ms. I haven't figured out whether that's the right approach. (If so, it could be made a configurable variable, and made to default to something appropiate for adpcm_ms.) Moritz
Moritz Barsnick <barsnick@gmx.net> schrieb am Do., 4. Jan. 2018 um 00:09 Uhr:
Have you tried the MS-ADPCM output of sox? I haven't gotten around to checking what it does, and have a hard time unterstanding the meaning of block size in the ADPCM context, and interpreting ffprobe's output.
How could I test with Xaudio2, assuming I have access to Windows?
I have had a test with SoX now. It also doesn't work. I have put together all the needed files for a test based on the directx sdk basic sound sample ( https://github.com/walbourn/directx-sdk-samples/tree/master/XAudio2). You can find all the needed files here: https://www.dropbox.com/sh/7h0pzevzyon1499/AABkY1k7PQ7kjIGKMm6MTZlca?dl=0 The Wavs folder contains an original wave file and the versions converted with ffmpeg, sox and AdpcmEncode (a tool provided by microsoft). These are the used commands: AdpcmEncode original.wav adpcmencode.wav ffmpeg -y -i original.wav -c:a adpcm_ms ffmpeg.wav I think the blocksize is also relevant for the file length. The ffmpeg encoded file is longer than the original one. I expect that a shorter block size would change this (while having a worse compression). My understanding is that adpcmencode.exe uses a blocksize that leads to the best compromise between duration error and compression. file | audacity | ffprobe original.wav | 0.789s | 0.79s adpcmencode.wav | 0.789s | 0.86s ffmpeg.wav | 0.831s | 0.83s sox.wav | 0.831s | 0.79s I don't know why ffprobe gets a different length for adpcmencode.wav then it really is. XAudio2BasicSound.exe ist the compiled version of the contained code (compiled with visual studio 2017 community). It will first play original.wav, then adpcmencode.wav and finally ffmpeg.wav. The last one failes with hresult 0x88960001 when calling pXaudio2->CreateSourceVoice. Hope I got the email formatting correct this time. Martin _______________________________________________
ffmpeg-user mailing list ffmpeg-user@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-user
To unsubscribe, visit link above, or email ffmpeg-user-request@ffmpeg.org with subject "unsubscribe".
2018-01-02 11:31 GMT+01:00 Martin Wahnschaffe <wahnschaffe@gmail.com>:
Problem is that ffmpeg always uses a blocksize auf 1024.
Did you actually verify this? If you change the value for BLKSIZE in libavcodec/adpcm.h does this fix the issue? Thank you, Carl Eugen
Did you actually verify this? If you change the value for BLKSIZE in libavcodec/adpcm.h does this fix the issue?
Sorry for the late reply, Can someone change BLKSIZE to 512 and send the ffmpeg.exe? I'd try and see if it works with that.
2018-01-18 17:55 GMT+01:00 Martin Wahnschaffe <wahnschaffe@gmail.com>:
Did you actually verify this? If you change the value for BLKSIZE in libavcodec/adpcm.h does this fix the issue?
Sorry for the late reply, Can someone change BLKSIZE to 512 and send the ffmpeg.exe? I'd try and see if it works with that.
Can't you install msys and test yourself? Carl Eugen
Can't you install msys and test yourself?
I expected there would be problems, so I tried to avoid it. I'm giving it a try now. Using this guide: https://trac.ffmpeg.org/wiki/CompilationGuide/MinGW (with mingw-get-setup). master branch, commit 4f6b34f1f803a103f321330bc5f9e4a01f788925 - Configure failed with "nasm/yasm not found or too old", so I used "./configure --disable-x86asm". - Received the "WARNING: pkg-config not found, library detection may fail." - make failed with "ffbuild/common.mak:174: *** missing separator. Stop."
2018-01-19 8:35 GMT+01:00 Martin Wahnschaffe <wahnschaffe@gmail.com>:
Can't you install msys and test yourself?
I expected there would be problems, so I tried to avoid it.
Many people are doing it.. (I haven't compiled on Windows for some time.)
I'm giving it a try now.
Using this guide: https://trac.ffmpeg.org/wiki/CompilationGuide/MinGW (with mingw-get-setup).
master branch, commit 4f6b34f1f803a103f321330bc5f9e4a01f788925
- Configure failed with "nasm/yasm not found or too old", so I used "./configure --disable-x86asm".
This is expected if you did not install yasm (or nasm) as explained in the wiki. It should not be needed for this test though.
- Received the "WARNING: pkg-config not found, library detection may fail."
This is expected, don't worry about it.
- make failed with "ffbuild/common.mak:174: *** missing separator. Stop."
What does "make -v" show? I suspect at least 3.81 is needed. Carl Eugen
What does "make -v" show? I suspect at least 3.81 is needed.
It's GNU Make 3.18 "This program built for i686-ps-msys".
2018-01-20 15:13 GMT+01:00 Martin Wahnschaffe <wahnschaffe@gmail.com>:
What does "make -v" show? I suspect at least 3.81 is needed.
It's GNU Make 3.18 "This program built for i686-ps-msys".
I didn't find this version / doesn't sound like a legitimate make.
Sorry, I misspelled it. It's 3.81 - the one you mentioned
You could try to build a newer make (takes only a few minutes) or install one of the other build environments. Sorry, Carl Eugen
Took a bit more than a few minutes, but I managed to compile using MSYS2. It means that some dependencies aren't included, but for testing it's ok. I changed the BLKSIZE constant to 512 and it still didn't work with XAudio. So I took a closer look at the code. Turns out that the BLKSIZE constant is actually used to set the block_align value. Microsoft measues the size of a block in samples ( https://msdn.microsoft.com/de-de/library/windows/desktop/ee415711(v=vs.85).a...). This seems to be different from the block_align used in adpcmenc.c. My impression is that frame_size is instead what has to be between 32 and 512. I tested this by setting BLKSIZE to 70. With my mono wave file this resulted in a frame_size of 128 = (BLKSIZE - 7 * avctx->channels) * 2 / avctx->channels + 2. The resulting compressed file is working with XAudio. I am very unsure if this is the right thing to do.
2018-01-27 15:08 GMT+01:00 Martin Wahnschaffe <wahnschaffe@gmail.com>:
I changed the BLKSIZE constant to 512 and it still didn't work with XAudio.
Good that you tested this! (Sorry if I already asked:) Is the issue also reproducible with WMP or only with "XAudio"? Thank you, Carl Eugen
Is the issue also reproducible with WMP or only with "XAudio"?
No, only with XAudio. WMP plays all of them properly.
Took a bit more than a few minutes, but I managed to compile using MSYS2. It means that some dependencies aren't included, but for testing it's ok.
I changed the BLKSIZE constant to 512 and it still didn't work with XAudio.
So I took a closer look at the code. Turns out that the BLKSIZE constant is actually used to set the block_align value. Microsoft measues the size of a block in samples ( https://msdn.microsoft.com/de-de/library/windows/desktop/ee415711(v=vs.85).a...). This seems to be different from the block_align used in adpcmenc.c. My impression is that frame_size is instead what has to be between 32 and 512.
I tested this by setting BLKSIZE to 70. With my mono wave file this resulted in a frame_size of 128 = (BLKSIZE - 7 * avctx->channels) * 2 / avctx->channels + 2.
The resulting compressed file is working with XAudio.
I am very unsure if this is the right thing to do.
So what should we do about this? Any chance to introduce ADPCM XAudio compatibility into ffmpeg? There is a lot of games that could profit from this.
2018-02-08 8:02 GMT+01:00 Martin Wahnschaffe <wahnschaffe@gmail.com>:
I changed the BLKSIZE constant to 512 and it still didn't work with XAudio.
So I took a closer look at the code. Turns out that the BLKSIZE constant is actually used to set the block_align value. Microsoft measues the size of a block in samples ( https://msdn.microsoft.com/de-de/library/windows/desktop/ee415711(v=vs.85).a...). This seems to be different from the block_align used in adpcmenc.c. My impression is that frame_size is instead what has to be between 32 and 512.
I tested this by setting BLKSIZE to 70. With my mono wave file this resulted in a frame_size of 128 = (BLKSIZE - 7 * avctx->channels) * 2 / avctx->channels + 2.
The resulting compressed file is working with XAudio.
I am very unsure if this is the right thing to do.
So what should we do about this? Any chance to introduce ADPCM XAudio compatibility into ffmpeg?
What's wrong with a parameter for blksize (with frame_size value)?
There is a lot of games that could profit from this.
Could you elaborate? I think I don't understand... Carl Eugen
participants (5)
-
Carl Eugen Hoyos -
Lou Logan -
Martin (Imagine Earth) -
Martin Wahnschaffe -
Moritz Barsnick