[ONEM-32729] : Duration API failed for progressive MP3 content

[suresh-khurdiya-epam]

gst duration API is failed for progressive MP3 content and also seeing seek operation is failed for progressive Audio playback. Issue was seen on those lightning apps: Deezer, Radioline and Radio paradise. Issue is not seen on audio only MSE apps (eg. BBC Sounds).

Root cause is gst_element_query_duration API is not giving correct value.

As a fix, we have addded MpegAudioParse plugin with ths fix is added by playbin before BrcmAudioFilter. The similar patch was already integrated in WPE 2.22 earlier https://github.com/WebPlatformForEmbedded/WPEWebKit/pull/957/files

Reproduction steps for radio line application

1. Run Radioline
2. Play any podcast (e.g from "Popular Podcast" section on Home page) Expected: Total duration time should be displayed correctly, and progress bar should follow current timestamp Actual Total duration is not displayed correctly and progress bar is broken

[modeveci]

@suresh-khurdiya-epam Is this a PR for RDK image? I have seen the code being using BCM_NEXUS flag which is for broadcom video sink, and RDK images use Westeros sink. Can you provide the image configuration of RDK for this PR?

[suresh-khurdiya-epam]

@modeveci , We are using both sinks(westeros and broadcom video sink) and issue is related only Audio based progressive content. And same code was there in upstream WPE-2.22 code as well which we ported with WPE 2.38. Please check below code link on WPE 2.22 repo.

https://github.com/WebPlatformForEmbedded/WPEWebKit/blob/wpe-2.22/Source/WebCore/platform/graphics/gstreamer/MediaPlayerPrivateGStreamer.cpp#L2869

[modeveci]

Thank you for clarification @suresh-khurdiya-epam. @eocanha can you look at this PR? as it has been merged earlier by you for 2.22.

[eocanha]

Maybe there's some internal bug in the Broadcom plugins or even in Nexus, and they don't support unparsed mpeg as good as they should, so this workaround to force a parser before the plugins looks like a good compromise to me. It has green light from my side.

I've been talking to @vivienne-w and we've agreed that they will take care of porting this patch to WebKit upstream and to bring it back to wpe-2.38. We try to do this with all the possible patches on 2.38 and above in order to minimize the differences with upstream and to have the patch on the next wpe release "for free".

[vivienne-w]

This PR is tracked upstream as: https://bugs.webkit.org/show_bug.cgi?id=268559 and https://github.com/WebKit/WebKit/pull/23674. It landed as https://github.com/WebKit/WebKit/commit/41a2e3c52030abb358f9726edd6e78a30756d94d, and was backported to 2.38 as https://github.com/WebPlatformForEmbedded/WPEWebKit/commit/d0d31dc2cdfe99fef71818b7acbd6e84ced559d5. For 2.42, it has been added to https://github.com/WebPlatformForEmbedded/WPEWebKit/commits/calvaris/wpe-2.42/upstream, which should be merged soon, as https://github.com/WebPlatformForEmbedded/WPEWebKit/commit/e84ed85f47a0ade18b2660627421ebb632d0c860.