I'm currently attempting to integrate a custom audio filter on a video player handling both HLS and raw MP4 files. I'm having little to no issue integrating it on Chrome and Firefox - Safari on the other hand is not behaving accordingly. I've stumbled upon an inconsistency in the way safari routes the audio from a createMediaElementSource call.
I've created a small demo to illustrate the problem (Safari ONLY for native HLS support), I've expressedly left out any audio filter code as it has little relevance concerning the main issue :
https://codepen.io/edvincandonus/pen/ZEGVbPG
In the demo, once the audioContext is instantiated and "unlocked" via a user gesture, I create the MediaElementAudioSourceNode via audioCtx.createMediaElementSource(video) and leave it dangling (as in unconnected). As a consequence, the HTMLMediaElement will be re-routed into the processing graph of the AudioContext, and as no connections were made to the audioCtx.destination, audio playback should be missing when video playback starts.
This is the behaviour on Firefox. Chrome goes even further and blocks video playback if the MediaElementAudioSourceNode has no final destination node (try playing the MP4 from the demo on chrome)
As for Safari : this expectation is only met when the video source is a raw MP4 file - But when switched to an m3u8/hls stream, the HTMLMediaElement's audio is not correctly routed to the AudioContext as you can clearly hear the video's sound.
Is this a known safari limitation ? If not, would anyone have any workarounds to correctly access and route the audio from an HLS stream using Safari's native support for this protocol?
I've stumbled upon old stackoverflow answers indicating createMediaElementSource had always been buggy on Safari, but I figure they would have fixed it by now.