Add support for AC4 audio codec and filter usac codec support#1641
Add support for AC4 audio codec and filter usac codec support#1641asurdej-comcast wants to merge 4 commits intoWebPlatformForEmbedded:wpe-2.46from
Conversation
Report AC4 support based on GST elements capabilites audio/x-ac4 Note wildcards used - all levels and profils are now supported ac-4*
ThunderDecryptor can now be used with encrypted ac4 audio
Add parseAc4LevelAndProfile() which validates AC-4 codec strings: - bare "ac-4" (no dots) is accepted as generic/unconstrained - "ac-4.XX.01.NN" with mdcompat NN in 0-3 is accepted - incomplete strings (< 4 dot-separated components) are rejected - presentation_version != 1 (e.g. IMS value 2) is rejected - mdcompat levels 4-7 are rejected The check is wired into isCodecSupported() as an early-reject guard before the generic codec-map lookup, so valid ac-4 strings still resolve through the existing "ac-4*" entry in the decoder map.
Add isUSACCodecSupported() to gate mp4a.40.42 codec strings behind an explicit GStreamer capability query rather than letting them fall through to the generic mp4a* codec map entry. Use below CAPS to probe Decoder/Sink support: audio/mpeg, mpegversion=4, stream-format=usac A new areCapsSupported(ElementFactories::Type, caps, hw) overload is added so the lookup can target AudioDecoder/AudioEncoder factories directly; the existing Configuration-based overload now delegates to it.
|
Maybe I will add a bit of explanation of that PR. We received test/cert app from Dolby that verifies AC-4 support by the browser. Wth current impl it's all beeing rejected as ac-4 is not listed as supported codec. This covers JS support query funcs like isTypeSupported but also direct MSE playback - AppndPipeline checks if qtdemux out codec is supported inside tryCreateTrackFromPad/parseDemuxerSrcPadCaps. Progressive playback may work still unless platform sink doesn't support ac4 caps. So listing ac4 caps in GST registry scanner allows to play AC-4 audio through MSE. AC-4 is not free codec and requires licensing but that should be handled by the platform itself (and gst elements) so I think it's safe to expose ac-4 in webkit if platform sink supports it. Regarding AC-4 parsing, that's also something that test app expects and the expectations seems reasonable to reject certain, non-standard, bitstreams and levels |
2 participants
Report that audio codec ac-4 is supported when audio/x-ac4 decoder is available (MS.isTypeSupported, video.canPlayType(), MediaCapabilities). Validate ac-4 codec string to reject non-standard configurations.
Add AC4 to webkit thunder decrypter and parser so GST can use them to decrypt encrypted ac-4 stream
Filter support for USAC (Unified Speech and Audio Coding) audio codec also known xHE-AAC. It comes with codecs="mp4a.40.42" codec string. Webkit uses wildcard "mp4a* to announce support for all configurations possible.
Our audio sinks reports stream-format=usac to distinguish usac codec but I'm not sure if all audio sink does that. The same stream seems to play on x86 webkit GTK with pulsesink (that doens't list usac stream-format) and doesn't report usac stream at all:
On Amlogic STB the caps are:
Maybe that depends on qtdemux impl
d4dd451