Multithreaded ffmpeg decode with DXVA2 hangs

[IMarshal]

I posted this at ​http://ffmpeg.zeranoe.com/forum/viewtopic.php?f=23&t=267, but it's probably more appropriate here.

First, I'd like to say how awesome ffmpeg is. We love it, love it, love it.

Anyway, we're seeing a hang attempting to decode H264 video using DXVA2 (aka pixel format PIX_FMT_DXVA2_VLD). This is in the recently released Plex Media Center (​http://www.plexapp.com). The only workaround we've found is to use a single thread when decoding.

It would be great if you could help us diagnose the issue. We suspect an ffmpeg bug, but it's possible that we're doing something wrong as well.

In our repro case, we call avcodec_thread_init with 8 threads, then avcodec_open, then obviously avcodec_decode_video. If we don't call avcodec_thread_init and we leave the context's default of 1 thread, then no hang occurs and decoding proceeds smoothly.

The hang itself occurs on the second or third call to avcodec_decode_video. Unfortunately, because of the difficulty of debugging ffmpeg code on Windows, I don't have good stack traces to provide. All I can see is avcodec waiting on what appear to be pthreads condition variables. None of our related threads are hung, and avcodec_decode_video is not returning, so my guess would be a deadlock in ffmpeg.

Here's a sample thread in cdb - not very useful, obviously:

24 Id: 3bc8.15e4 Suspend: 1 Teb: fff50000 Unfrozen
ChildEBP RetAddr
1681f728 76eb0bdd ntdll_779a0000NtWaitForMultipleObjects+0x15
1681f7c4 75f71a2c KERNELBASEWaitForMultipleObjectsEx+0x100
1681f80c 75f74208 KERNEL32WaitForMultipleObjectsExImplementation+0xe0
1681f828 6e0c5173 KERNEL32WaitForMultipleObjects+0x18
WARNING: Stack unwind information not available. Following frames may be wrong.
1681f858 6e0c5582 libpthread_2!pthreadCancelableTimedWait+0x47
1681f8d8 6e0c66c3 libpthread_2!sem_timedwait+0x15e
1681f928 661a1740 libpthread_2!pthread_cond_wait+0xeb
1681f974 6e0c5121 avcodec_53!av_parser_close+0x71ac
1681f9a4 76861287 libpthread_2!pthread_exit+0xf5
1681f9dc 76861328 msvcrt!_endthreadex+0x44
1681f9e4 75f7339a msvcrt!_endthreadex+0xce
1681f9f0 779d9ed2 KERNEL32BaseThreadInitThunk+0xe
1681fa30 779d9ea5 ntdll_779a0000__RtlUserThreadStart+0x70
1681fa48 00000000 ntdll_779a0000!_RtlUserThreadStart+0x1b

More context: we're using ffmpeg library bits built from current ffmpeg sources, using MSYS/MinGW. We have some customizations, but they are relatively minor and unrelated to this area.

The following is our configure command line:

$ cat configure-windows.sh
./configure --disable-static --disable-debug --enable-runtime-cpudetect --disable-mmx --disable-mmx2 --arch=i386 --disable-muxers --enable-muxer=spdif --enable-muxer=adts --disable-encoders --enable-encoder=ac3 --enable-encoder=aac --disable-libvorbis --disable-devices --disable-ffplay --disable-ffserver --disable-ffmpeg --enable-shared --disable-decoder=mpeg_xvmc --enable-postproc --enable-gpl --enable-protocol=http --enable-pthreads --enable-runtime-cpudetect --enable-memalign-hack --enable-dxva2 --enable-decoder=h264_dxva2 --enable-hwaccel=h264_dxva2 --extra-cflags=-Isysinc

Is there any other data I can provide that might help to debug this?

Thanks!

[Carl Eugen Hoyos]

Replying to IMarshal:

This is in the recently released Plex Media Center

I couldn't easily find the sources, can you help me?

[IMarshal]

You can find the sources for the ffmpeg bits we built at ​https://github.com/elan/plex-ffmpeg.

Or were you looking for the PMC sources? You can find those at ​https://github.com/elan/plex/tree/laika

[reimar]

It is a bit unclear what exactly you consider the problem.
Multithreaded decoding makes no sense to combine with hardware decode, so it is not supported.
So the answer to you problem would be "just don't do that then".
Now, I know that e.g. VideoLan has issues with this because they really want to decide on whether to use hardware decode or not after opening the decoder.
This is supposed to work by the decoder automatically disabling threads when a hardware PIX_FMT is chosen.
However that seems to be buggy, patches very much welcome. Since this kind of thing needs hardware _and_ an application other that FFmpeg to test it is rather a pain and the probability of any of the FFmpeg core developers fixing it on their own is a bit low I think.

[IMarshal]

reimar:

Thanks for your reply.

I agree that multithreaded decoding and DXVA don't really make sense together. Our problem however is similar to VideoLan, in that we decide on the pixel format well after opening the decoder. So by the time we know that we really wanted one thread, it's already too late.

It would be fantastic if ffmpeg would gracefully revert to using a single thread under these scenarios. Hanging is clearly suboptimal. :-) So I think we agree on that as well.

Unfortunately, I find debugging ffmpeg on Windows pretty challenging, given that mingw builds don't have symbolic information as per what the standard platform tools expect. Do you have any tips or hints on how best to debug this?

If any of the ffmpeg core developers were to attack this problem, I've be overjoyed to help in terms of providing help with repro cases, builds of Plex and so forth. I'm sure we're not the only user of ffmpeg hitting this issue, so it would be great to get it fixed for everyone.

Thanks again.

[Carl Eugen Hoyos]

Replying to IMarshal:

Unfortunately, I find debugging ffmpeg on Windows pretty challenging, given that mingw builds don't have symbolic information as per what the standard platform tools expect. Do you have any tips or hints on how best to debug this?

gdb works fine on Windows.

If any of the ffmpeg core developers were to attack this problem, I've be overjoyed to help in terms of providing help with repro cases, builds of Plex and so forth. I'm sure we're not the only user of ffmpeg hitting this issue, so it would be great to get it fixed for everyone.

I am still surprised that this problem does not hit vlc users.
(mplayer -vc ffh264vdpau -lavdopts threads=8 also works fine.)

Carl Eugen

[reimar]

I am still surprised that this problem does not hit vlc users.

VLC developers have experienced the problem, I talked about it at the VLC dev conference.
I think some fixes were made, but I am not sure it fixed everything (I assume you are using latest git to test?).

mplayer -vc ffh264vdpau -lavdopts threads=8 also works fine.

VDPAU uses a separate codec that ignores threads from the start. The problem is disabling threading once the PIX_FMT is selected.
In addition I expect it is only an issue with frame multithreading, otherwise you might be able to test with mplayer XvMC...

[Carl Eugen Hoyos]

Replying to reimar:

I am still surprised that this problem does not hit vlc users.

VLC developers have experienced the problem, I talked about it at the VLC dev conference.

Thank you for clarifying!

[IMarshal]

Stack traces with symbols with hung process using debug ffmpeg.

[IMarshal]

I've attached the legible parts of a 'thread apply all bt full' in gdb using a debug ffmpeg.

Honestly, there isn't a ton to go on here. Any chance I could get someone with a better eye for the code to repro? Again, I'd be happy to provide repro steps, builds, etc.

Thanks!

[compn]

there is a patch that adds a dxva2 decoder wrapper.
see thread [FFmpeg-devel] [PATCH] libavcodec:add dxva2 decoder for h264, mpeg2, vc1.wmv3

i wonder if you used this instead, are the same hangs observed?