JDK-8240694 : [macos 10.15] JavaFX Media hangs on some video files on Catalina
The Version table provides details related to the release that this issue/RFE will be addressed.
Unresolved : Release in which this issue/RFE will be addressed. Resolved: Release in which this issue/RFE has been resolved. Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.
This is intermittent hang and does not reproduces with all mp4 media files. Hang occurred when we read currentTime from AVPlayer on audio tap thread (ProcessAudioTap). Hang happens in both cases if we reading currentTime at same time from other threads or not.
Potential solution 1 (Originally implemented as JDK-8236832, but did not worked and was reverted as part of this fix): Waiting for audio processing thread to process at least one audio buffer reduced hang frequency, but did not solve problem completely. Also, subsequent attempt to fix issue by waiting for at least one video and one audio buffer did not fixed issue. For example if we delivered one video frame and ProcessAudioTap processed one audio frame hang will still happen. So, conclusion was that we cannot reliable call currentTime from ProcessAudioTap in any case if we just starting playback or we already playing media for some time.
Potential solution 2: Calculate audio timestamp for audio spectrum event based on audio data being processed. This did not work well enough due to timestamp in mp4 might not always start with 0 and increment sequentially, so making such assumption is not reliable way to provide timestamps and it is always better to ask AVPlayer for time. ProcessAudioTap does not have any indication if stream was stop and restarted or if we playing in loop, so calculating timestamp ourself will be complicated due to loop, stop/play, start and stop time.
Proposed solution 3: This is what is implemented with this fix. Requesting currentTime from independent thread did fix issue and no hang was observed. It did add minor delay to actual timestamp, but since we do not provide "true" timestamp for spectrum event anyway, such approach should not cause any issues with provided timestamp. We used to have: calculate spectrum -> request timestamp (it is already asked after spectrum was calculated which is not exact timestamp of audio buffer we did spectrum for) -> send event to event loop thread -> send event to application. Now: calculate spectrum -> send event to event loop thread -> request timestamp -> send event to application.