Bug 210840 - [GStreamer][MediaStream] fast/mediastream/play-newly-added-audio-track.html is failing since added in r260380
Summary: [GStreamer][MediaStream] fast/mediastream/play-newly-added-audio-track.html i...
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: WebKitGTK (show other bugs)
Version: WebKit Nightly Build
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: Philippe Normand
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2020-04-21 20:01 PDT by Lauro Moura
Modified: 2021-04-19 03:14 PDT (History)
15 users (show)

See Also:


Attachments
Patch (42.42 KB, patch)
2021-04-16 03:05 PDT, Philippe Normand
no flags Details | Formatted Diff | Diff
Patch (44.96 KB, patch)
2021-04-17 03:22 PDT, Philippe Normand
ews-feeder: commit-queue-
Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Lauro Moura 2020-04-21 20:01:14 PDT
It is also flaky crashing with a similar backtrace to bug210498.

Diff:

--- /home/slave/webkitgtk/gtk-linux-64-release-tests/build/layout-test-results/fast/mediastream/play-newly-added-audio-track-expected.txt
+++ /home/slave/webkitgtk/gtk-linux-64-release-tests/build/layout-test-results/fast/mediastream/play-newly-added-audio-track-actual.txt
@@ -1,5 +1,5 @@
 
 
-PASS Add an audio track while playing video 
-PASS Add an audio track while playing audio 
+FAIL Add an audio track while playing video promise_test: Unhandled rejection with value: object "TypeError: Argument 1 ('track') to Internals.shouldAudioTrackPlay must be an instance of AudioTrack"
+FAIL Add an audio track while playing audio promise_test: Unhandled rejection with value: object "TypeError: Argument 1 ('track') to Internals.shouldAudioTrackPlay must be an instance of AudioTrack"
Comment 1 Víctor M. Jáquez L. 2020-04-22 09:48:32 PDT
This is a new test from r260380
Comment 2 Lauro Moura 2021-03-23 21:36:17 PDT
Flaky timing out since r273754 (first timeout).
Comment 3 Philippe Normand 2021-04-16 03:05:50 PDT
Created attachment 426203 [details]
Patch
Comment 4 Xabier Rodríguez Calvar 2021-04-16 07:59:06 PDT
Comment on attachment 426203 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=426203&action=review

> Source/WebCore/platform/graphics/gstreamer/MediaPlayerPrivateGStreamer.cpp:1660
> +        webkitMediaStreamSrcConfigureAudioTracks(WEBKIT_MEDIA_STREAM_SRC(m_source.get()), volume(), isMuted(), !m_isPaused);

Can't we _CAST here?

> Source/WebCore/platform/mediastream/gstreamer/GStreamerMediaStreamSource.cpp:125
> +    InternalSource(GstElement* parent, MediaStreamTrackPrivate& track, String padName)

You can take a const String& here and let assignment to the attribute do the copy.

> Source/WebCore/platform/mediastream/gstreamer/GStreamerMediaStreamSource.cpp:482
> +        GST_OBJECT_UNLOCK(self);
> +        return;
> +    }
> +
> +    auto upstreamId = priv->stream ? priv->stream->id() : createCanonicalUUIDString();
> +    priv->streamCollection = adoptGRef(gst_stream_collection_new(upstreamId.ascii().data()));
> +    for (auto& track : priv->tracks) {
> +        if (!track->isActive())
> +            continue;
> +        gst_stream_collection_add_stream(priv->streamCollection.get(), webkitMediaStreamNew(track.get()));
> +    }
> +
> +    GST_OBJECT_UNLOCK(self);

For these cases I would like to use ScopeExit on Scope.h. That way you could create the ScopeExit to run the GST_OBJECT_UNLOCK and forget to UNLOCK in the first place. In case you need to add more early returns, you're covered.

The problem is that ScopeExit does not have a runEarlyAndRelease method yet that you would need for the second UNLOCK. If you feel like adding it, you have my blessing. The patter would be similar to the unlockEarly of the LockHolder.

> Source/WebCore/platform/mediastream/gstreamer/GStreamerMediaStreamSource.cpp:523
> +    const String& padName;

ProbeData is most probably not going to outlive the InternalSource but it would be safer to not have const String& and just a String here. We just make a copy of the String object, the StringImpl does the refcounting and everybody is happier.
Comment 5 Philippe Normand 2021-04-17 02:54:11 PDT
Comment on attachment 426203 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=426203&action=review

>> Source/WebCore/platform/graphics/gstreamer/MediaPlayerPrivateGStreamer.cpp:1660
>> +        webkitMediaStreamSrcConfigureAudioTracks(WEBKIT_MEDIA_STREAM_SRC(m_source.get()), volume(), isMuted(), !m_isPaused);
> 
> Can't we _CAST here?

We had no such variant, until now. I'm adding it.

>> Source/WebCore/platform/mediastream/gstreamer/GStreamerMediaStreamSource.cpp:482
>> +    GST_OBJECT_UNLOCK(self);
> 
> For these cases I would like to use ScopeExit on Scope.h. That way you could create the ScopeExit to run the GST_OBJECT_UNLOCK and forget to UNLOCK in the first place. In case you need to add more early returns, you're covered.
> 
> The problem is that ScopeExit does not have a runEarlyAndRelease method yet that you would need for the second UNLOCK. If you feel like adding it, you have my blessing. The patter would be similar to the unlockEarly of the LockHolder.

I agree improving ScopeExit would be nice but for this code it wouldn't be useful anyway. The runEarlyAndRelease() would need to be called before gst_element_post_message() to avoid a deadlock, so that defeats the purpose of using ScopeExit here :)
Comment 6 Philippe Normand 2021-04-17 03:22:53 PDT
Created attachment 426328 [details]
Patch
Comment 7 Philippe Normand 2021-04-17 04:23:33 PDT
Committed r276197 (236679@main): <https://commits.webkit.org/236679@main>
Comment 8 Xabier Rodríguez Calvar 2021-04-19 03:14:53 PDT
(In reply to Philippe Normand from comment #5)
> > The problem is that ScopeExit does not have a runEarlyAndRelease method yet that you would need for the second UNLOCK. If you feel like adding it, you have my blessing. The patter would be similar to the unlockEarly of the LockHolder.
> 
> I agree improving ScopeExit would be nice but for this code it wouldn't be
> useful anyway. The runEarlyAndRelease() would need to be called before
> gst_element_post_message() to avoid a deadlock, so that defeats the purpose
> of using ScopeExit here :)

It's true that it defeats the purpose "in this case", but GStreamer codes is used to having structure of early return that force you to release resources before returning, either locks, buffers or objects. This is an easy case with one lock, release close to the end and one early return. If I prefer the ScopeExit is because it prevents errors in case you add another early return if you happen to forget to release the lock. Am I overprotective, won't deny it either :)