Deadlock in VTDecompressionSessionDecodeFrame when application goes to background

Originator:floriandenis
Number:rdar://25828950 Date Originated:04/20/2016
Status:Open Resolved:
Product:iOS SDK Product Version:
Classification: Reproducible:100%
 
Summary:
There is a 100% reproducible deadlock in VideoToolbox when suspending the app to background. VTDecompressionSessionDecodeFrame hangs forever waiting on a condition  variable.

We provide a sample project reproducing the issue. It depends on ffmpeg for demuxing, whose libraries we provide pre-compiled for arm64 and armv7.
Use of the VideotoolBox API can be found in sxplayer/decoder_vt.c  The overall architecture of the module is descrived in sxplayer/README.md. 


A few additional information: 

 - This happens only when decodeFlags is set to  kVTDecodeFrame_EnableAsynchronousDecompression and we are not epxlicitely calling VTDecompressionSessionWaitForAsynchronousFrames after the call to VTDecompressionSessionDecodeFrame

- Limiting the internal queue to less than 10 packets does not affect the outcome. 

- Invalidating the session (via VTDecompressionSessionInvalidate) while the call is hanging does not resolve the issue either

- After 10 seconds, there does seem to have a timeout mechanism entering into effect, and our decode callback is called for as much time as there is packets in the queue. However, the previous points still apply

Steps to Reproduce:
1. Create a VTDecompressionSession
2. Setup a callback to consume output frames
3. Push packets via VTDecompressionSessionDecodeFrame in async mode 
4. While pushing packets, put the app in `inactive` state (either by pressing the home button to the homescreen, or by pressing the lock button to the lock screen)


Expected Results:
5. The call to VTDecompressionSessionDecodeFrame eitherfails with a sensible error or succeeds when the app is back in active state


Actual Results:
5. The call to VTDecompressionSessionDecodeFrame hangs forever, regardless of whether or not the application goes back to active state


Version:
iOS 9.0 and above

Notes:
You can simply reproduce the issue by launching our test project, waiting a few seconds for decode to happen, and pressing the lock button. By pausing the program in the debugger, you should notice the deadlock

Note: The chromium team does seem to have stumbled upon the same problem: https://bugs.chromium.org/p/webrtc/issues/detail?id=5464

Configuration:
All iPhone models from the 5 up

Comments


Please note: Reports posted here will not necessarily be seen by Apple. All problems should be submitted at bugreport.apple.com before they are posted here. Please only post information for Radars that you have filed yourself, and please do not include Apple confidential information in your posts. Thank you!