[GStreamer] Auto-detect USAC support via GStreamer registry#1654
[GStreamer] Auto-detect USAC support via GStreamer registry#1654asurdej-comcast wants to merge 1 commit intoWebPlatformForEmbedded:wpe-2.46from
Conversation
|
@ntrrgc Follow up on #1641 |
Add a fallback check for USAC (xHE-AAC) codec support by probing the GStreamer registry for a decoder matching "audio/mpeg, mpegversion=(int)4, stream-format=(string)usac". The stream-format=usac caps field is not part of the standard GStreamer audio/mpeg caps definition, but some custom audio sinks advertise it, so it can be used as an indicator of USAC decoding capability. The WEBKIT_GST_CAN_PLAY_USAC environment variable still takes precedence as a manual override.
asurdej-comcast
force-pushed
the
usac_fallback
branch
from
8944013 to
d8522c2
Compare
asurdej-comcast
changed the title
| bool canPlayUsac = value && (!g_strcmp0(value, "true") || !g_strcmp0(value, "1")); | ||
| if (!value) { | ||
| // Env is not set. Fall back to gst elements query | ||
| canPlayUsac = factories.hasElementForMediaType(ElementFactories::Type::AudioDecoder, "audio/mpeg, mpegversion=(int)4, stream-format=(string)usac"_s).isSupported; |
There was a problem hiding this comment.
What element is this?
I think a change like this can be upstreamed, but given the unusual -- and likely problematic -- value for stream-format, I think it's best if we leave a comment mentioning it by name, so that next time we know why this check is there and don't accidentally remove it.
I also noticed that in previous messages, and in the commit message you said "audio sinks" but the check is for an audio decoder. Was that a mistake or does the element in question happen to be both a decoder a sink element (which is possible, depending how the hardware platform API works)?
There was a problem hiding this comment.
This is Amlogic "amlhalasink" element that is both decoder and sink. The commit message is misleading indeed
amlhalasink: Long-name AmlHalAsink
amlhalasink: Klass Decoder/Sink/Audio
...
amlhalasink: Pad Templates:
amlhalasink: SINK template: 'sink'
amlhalasink: Availability: Always
amlhalasink: Capabilities:
...
amlhalasink: audio/x-ac4
amlhalasink: audio/mpeg
amlhalasink: mpegversion: 4
amlhalasink: stream-format: { (string)loas, (string)usac }
There was a problem hiding this comment.
the same with MediaTek audio sink "mtkaudiosink" which is also decoder and sink at once
There was a problem hiding this comment.
the same with MediaTek
So both amlhalasink and mtkaudiosink report support for stream-format=usac?
There was a problem hiding this comment.
yes, they both do that actually but it's not a coincidence because mtk had been adjusted for our needs based on amlogic version kind of. So possibly that's why they use the same approach
2 participants
Add a fallback check for USAC (xHE-AAC) codec support by probing the GStreamer registry for a decoder matching
"audio/mpeg, mpegversion=(int)4, stream-format=(string)usac".
The stream-format=usac caps field is not part of the standard GStreamer audio/mpeg caps definition, but some custom audio sinks advertise it, so it can be used as an indicator of USAC decoding capability.
The WEBKIT_GST_CAN_PLAY_USAC environment variable still takes precedence as a manual override.
d8522c2