Bug 297116 – [GStreamer] Audio is distorted in Kaltura videos

• Status: RESOLVED
• Resolution: FIXED
• Component: WebKitGTK

[Michael Catanzaro]

Created attachment 476307 [details]
gst.log

Play this video in Epiphany Tech Preview: https://videos.kaltura.com/media/Kaltura+MediaSpace+walkthrough/1_m7jjxnni

All audio is heavily distorted. The woman speaking sounds like Darth Vader.

Notably, this bug only occurs in Tech Preview (WebKitGTK 2.49.4 with GStreamer 1.26.4) and not in my jhbuild environment.

Debug log is attached.

[Philippe Normand]

Can you check if mpg123dec is also used in your jhbuild? (add audiodec*:6 to the GST_DEBUG)

Which gst version do you have in jhbuild?

[Michael Catanzaro]

(In reply to Philippe Normand from comment #1)
> Can you check if mpg123dec is also used in your jhbuild? (add audiodec*:6 to
> the GST_DEBUG)

Using GST_DEBUG=audiodec*:6, I don't see mpg123dec anywhere in the debug log. I see a bunch of fdkaacdec0.

> Which gst version do you have in jhbuild?

I didn't build it myself, so it's system GStreamer: gstreamer1-1.26.3-1.fc42.

Oddly, although I can play the video perfectly fine with my jhbuild Epiphany, I'm no longer able to reproduce the original problem in Tech Preview because the video playback now fails altogether:

{"embedUrl":"https://videos.kaltura.com/media/Kaltura+MediaSpace+walkthrough/1_m7jjxnni","userAgent":"Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/60.5 Safari/605.1.15","referrer":"","targetId":"kplayer","playerVersion":"3.17.53","partnerId":"811441","playlistId":"","plugins":["kava","playkit-js-moderation","floating","kaltura-live","vr","playlist","navigation","ivq","playkit-js-hotspots","dualscreen","qna","uiManagers","timeline","kalturaCuepoints"],"localStorage":{"@playkit-js/kaltura-player-js_muted":"false"},"log":"8/8/2025, 12:46:42 PM [Error] Category:7 | Code:7003 | playkit-transcript \n8/8/2025, 12:46:42 PM [Error] Category:7 | Code:7003 | playkit-js-document-player \n8/8/2025, 12:46:43 PM [Error] Category:7 | Code:7002 | {\"severity\":2,\"category\":1,\"code\":1006,\"data\":{\"url\":\"https://www.kaltura.com/api_v3/service/multirequest\",\"headers\":[\"x-kaltura: cached-dispatcher,cache_v3-56a8657ab1bdcfacc643d4c633f4372b,0.00136399269104\\r\",\"x-me: nvp1-fapi-h9ckw\\r\"],\"results\":[{\"hasError\":true,\"error\":{\"code\":\"INVALID_KS\",\"message\":\"Invalid KS \\\"EXCEEDED_RESTRICTED_IP\\\", Error \\\"-1,INVALID_STR\\\"\"}},{\"hasError\":true,\"error\":{\"code\":\"INVALID_KS\",\"message\":\"Invalid KS \\\"EXCEEDED_RESTRICTED_IP\\\", Error \\\"-1,INVALID_STR\\\"\"}},{\"hasError\":true,\"error\":{\"code\":\"INVALID_KS\",\"message\":\"Invalid KS \\\"EXCEEDED_RESTRICTED_IP\\\", Error \\\"-1,INVALID_STR\\\"\"}}]}} \n"}

(I'm not sure what EXCEEDED_RESTRICTED_IP means. It's clearly not an IP address ban, since my jhbuild Epiphany works.)

[Philippe Normand]

Here if I run:

flatpak run --user --command=/usr/libexec/webkitgtk-6.0/MiniBrowser --filesystem=home --env=GST_DEBUG="3,webkit*:6,audiodec*:6" --env=GST_DEBUG_FILE=$HOME/tmp/gst.log --env=WEBKIT_DISABLE_SANDBOX_THIS_IS_DANGEROUS=1 org.gnome.Epiphany.Devel "https://videos.kaltura.com/media/Kaltura+MediaSpace+walkthrough/1_m7jjxnni"

I get:

1. ** (WebKitWebProcess:25): WARNING **: 10:04:33.864: The GStreamer FDK AAC plugin is missing, AAC playback is unlikely to work.
2. avdec_aac used for playback and it's known to be broken...

You should really add fdkaac in your SDK.

[Philippe Normand]

Heh. https://gitlab.com/freedesktop-sdk/freedesktop-sdk/-/commit/eb5f79dd1430d6f47394766509bfd0335345bb45

I'll close this, as playback works when fdkaacdec is in the runtime. This is a SDK issue.

[Michael Catanzaro]

I've chatted with freedesktop-sdk devs and it looks like they don't want to bring back fdkaac. Maybe we need a bug report against avdec_aac instead?

If you really need fdkaac resurrected, then please ask in #freedesktop-sdk:matrix.org.

This library misses countless fixes from upstream including all kind of overflow fixes found by fuzzing over several years. Trusting it for decode random content over the web is IMO highly questionable from security POV. If you must use it then please bundle it into epiphany. I don't think that runtime should take responsibility for exposing this library for all flatpak users.

https://github.com/mstorsjo/fdk-aac/compare/v2.0.0...v2.0.3

Created attachment 476354 [details]
gst-play from gnome nightly log

This is bit confusing though.

I grabbed video from link above and played it on gnome nightly runtime with both ffplay and gst-play and audio is perfectly fine (no difference from playing it in firefox).

You may check attached gst log that avdec_aac is used.

Tested with: flatpak run --socket=wayland --socket=pulseaudio --device=dri --env=GST_DEBUG=audiodec"*:6" --env=GST_DEBUG_FILE=/tmp/gst-play.log --command=gst-play-1.0 --filesystem=host org.gnome.Platform//master <path-to-videofile>

So it looks like avdec_aac is innocent here but something in epiphany may be broken instead.

[Philippe Normand]

(In reply to Michael Catanzaro from comment #5)
> Maybe we need a bug report against avdec_aac instead?
 
The issue was reported 6 years ago:
https://ffmpeg.org/pipermail/ffmpeg-devel/2019-July/247063.html

(In reply to Erick555555 from comment #6)
> This library misses countless fixes from upstream including all kind of
> overflow fixes found by fuzzing over several years. 

That's Wim's fork, right? If so, yes it makes sense to stop shipping it if it's not updated anymore.

OTOH distros relying on the upstream fdk-aac repo shouldn't be affected. Debian for instance seems to do that.

(In reply to Erick555555 from comment #7)
> I grabbed video from link above 

Grabbed how?

> OTOH distros relying on the upstream fdk-aac repo shouldn't be affected. Debian for instance seems to do that.

yes, but it has non-free license. I don't think freedeskop-sdk is going to ship non-foss code.

> Grabbed how?

In firefox, I opened "View source page" and found link to .mp4 file. I don't know how to do that in epiphany. I can post this link here if you want.

[Philippe Normand]

MSE is used for playback, not that twitter:player:stream http URL. The audio streams are encoded in AAC on both cases, but the codec_data differs (1210 for the mp4 file vs 2a120800 in MSE case).

Ok, I see you reported bug to ffmpeg but I tested this webpage playback on firefox and chromium from flathub and there were no issues with audio. AFAIK they use aac decoder from ffmpeg.

Why only epiphany is affected then? It it because it uses gst plugin instead of ffmpeg directly? If so then maybe the plugin can be fixed.

[Michael Catanzaro]

Timely: https://www.openwall.com/lists/oss-security/2025/08/13/9

It looks like this project is just not healthy. The upstream fdk-aac is rejected by Debian, Ubuntu, and Fedora. The "free" fork is clearly abandoned and removing it from freedesktop-sdk looks like it was surely the right call. I will start the process of removing it from Fedora now.

My suggestion is to reopen this issue and consider how to make things work without fdk-aac, unless it's *really* important to keep. If so, somebody will need to take over maintaining and rebasing it on the upstream version.

[Philippe Normand]

(In reply to Michael Catanzaro from comment #12)
> The upstream fdk-aac is rejected by Debian

I don't know how you came to that conclusion.

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=981285 was about moving the fdk-aac-non-free to main, but its licensing being incompatible with the GPL, the request was denied. So fdk-aac remains in non-free and afaics is maintained.

[Philippe Normand]

(In reply to Erick555555 from comment #11)
> Ok, I see you reported bug to ffmpeg but I tested this webpage playback on
> firefox and chromium from flathub and there were no issues with audio. AFAIK
> they use aac decoder from ffmpeg.
> 
> Why only epiphany is affected then? It it because it uses gst plugin instead
> of ffmpeg directly? If so then maybe the plugin can be fixed.

I checked again with ffplay and playback is also garbled.
Here's how I did it:

1. Capture the muxed mp4 using GST_TRACERS="pcap-writer(target-factory=identity)"
2. Find the pcap file in pcap_tracers, it's likely named append-pipeline-audio-mp4-0\>identity0\>src.pcap
3. Depayload the pcap file into an mp4 file, gst-launch-1.0 filesrc location=$PWD/tracer_pcaps/append-pipeline-audio-mp4-0\>identity0\>src.pcap ! pcapparse ! "video/quicktime,variant=mse-bytestream" ! filesink location=$HOME/tmp/test.mp4
4. ffplay ~/tmp/test.mp4

It's true that chromium uses the ffmpeg decoders, but they also have custom parsers for mp4 and aac... so what they feed to the decoder might not be exactly the same bitstream that the upstream ffmpeg demuxer/parser generates.

[Philippe Normand]

Anyway, let's reopen this, I'll try to debug this further when I have some spare cycles...

[Philippe Normand]

Seems like a workaround is to force stream-format=adts on aacparse.

[Philippe Normand]

Pull request: https://github.com/WebKit/WebKit/pull/49814

[Michael Catanzaro]

Wim has updated Fedora's fork of fdk-aac, so lack of security updates shouldn't be a problem anymore.

This may be too optimistic take as even the updated version refers to AOSP repo from 2023.

AOSP doesn't do tags and fdk-aac project on github (which doesn't provide any security support on its own) didn't make any tag since late 2023. So while it's true that now you can found updated fdk-aac-free fork in fedora rawhide, saying security updates aren't problem is bit premature. There are too many middlemen here.

[EWS]

Committed 299318@main (b87a52fd5788): <https://commits.webkit.org/299318@main>

Reviewed commits have been landed. Closing PR #49814 and removing active labels.

[Alicia Boya García]

Unfortunately, I have found today that https://github.com/WebKit/WebKit/commit/b87a52fd5788fcd275446bb61c2ca49b8f85430a introduces significant overhead in append performance.

This corresponds to a 66% regression in performance on top of the append performance for audio in 2.46 (which already suffers an unrelated and not included 50% peformance regression from 2.38).

The regression is not going to be noticeable in desktop (15ms -> 25ms for 2.5MiB of AAC audio), but it is likely to be noticeable for constrained devices.

This overhead is not too surprising given that the landed approach has to repackage every AAC frame into a more forgiving format to deal with badly muxed content. I can think of two possible solutions:

a) Instead of reformatting audio as ADTS, parse the codec data and change it to use implicit signalling in situations where ADTS would converge to implicit signalling.

b) Reformat AAC in the playback pipeline instead of the append pipeline. This is feasible because PTS, DTS and duration are not expected to change in the process. While this would not reduce the overhead of reformatting AAC, it would allow it to be done in the background without blocking appends, and therefore result in faster canplaythrough times.