WebKit Bugzilla
New
Browse
Log In
×
Sign in with GitHub
or
Remember my login
Create Account
·
Forgot Password
Forgotten password account recovery
RESOLVED FIXED
211718
Introduce a RealtimeMediaSource video sample observer
https://bugs.webkit.org/show_bug.cgi?id=211718
Summary
Introduce a RealtimeMediaSource video sample observer
youenn fablet
Reported
2020-05-11 03:10:19 PDT
Introduce a RealtimeMediaSource video sample observer
Attachments
Patch
(49.62 KB, patch)
2020-05-11 03:17 PDT
,
youenn fablet
no flags
Details
Formatted Diff
Diff
Patch
(54.78 KB, patch)
2020-05-11 07:22 PDT
,
youenn fablet
no flags
Details
Formatted Diff
Diff
Patch for landing
(54.98 KB, patch)
2020-05-12 02:30 PDT
,
youenn fablet
no flags
Details
Formatted Diff
Diff
Show Obsolete
(2)
View All
Add attachment
proposed patch, testcase, etc.
youenn fablet
Comment 1
2020-05-11 03:17:32 PDT
Created
attachment 399008
[details]
Patch
youenn fablet
Comment 2
2020-05-11 07:22:42 PDT
Created
attachment 399017
[details]
Patch
Eric Carlson
Comment 3
2020-05-11 09:24:20 PDT
Comment on
attachment 399017
[details]
Patch View in context:
https://bugs.webkit.org/attachment.cgi?id=399017&action=review
> Source/WebCore/platform/mediarecorder/MediaRecorderPrivate.h:107 > if (m_audioSource) > m_audioSource->removeAudioSampleObserver(*this); > + if (m_videoSource) > + m_videoSource->removeVideoSampleObserver(*this);
Maybe add a FIXME about removing these, since they should never be necessary?
> Source/WebCore/platform/mediastream/RealtimeMediaSource.cpp:210 > + auto locker = holdLock(m_videoSampleObserversLock); > + for (auto* observer : m_videoSampleObservers) > + observer->videoSampleAvailable(mediaSample);
Clients may perform an arbitrary amount of processing during a callback, so holding the lock for the duration of this loop might be asking for trouble.
Philippe Normand
Comment 4
2020-05-11 10:33:48 PDT
Thanks for keeping the GStreamer bits compiling!
youenn fablet
Comment 5
2020-05-11 10:49:26 PDT
(In reply to Philippe Normand from
comment #4
)
> Thanks for keeping the GStreamer bits compiling!
np, note that the following step might be to call videoSampleAvailable from a background thread. While this may not break compilation, this might require some GTK changes.
youenn fablet
Comment 6
2020-05-11 10:55:47 PDT
(In reply to Eric Carlson from
comment #3
)
> Comment on
attachment 399017
[details]
> Patch > > View in context: >
https://bugs.webkit.org/attachment.cgi?id=399017&action=review
> > > Source/WebCore/platform/mediarecorder/MediaRecorderPrivate.h:107 > > if (m_audioSource) > > m_audioSource->removeAudioSampleObserver(*this); > > + if (m_videoSource) > > + m_videoSource->removeVideoSampleObserver(*this); > > Maybe add a FIXME about removing these, since they should never be necessary?
I added them as a just-in-case, maybe we should just keep the ASSERT. The child class should really do it since otherwise, a half-destructed object might still receive samples.
> > Source/WebCore/platform/mediastream/RealtimeMediaSource.cpp:210 > > + auto locker = holdLock(m_videoSampleObserversLock); > > + for (auto* observer : m_videoSampleObservers) > > + observer->videoSampleAvailable(mediaSample); > > Clients may perform an arbitrary amount of processing during a callback, so > holding the lock for the duration of this loop might be asking for trouble.
This is the same design as for audio samples. I think it is fine like it is since receiving video samples should not trigger adding/removing observers, and hopefully these actions will be in different threads.
youenn fablet
Comment 7
2020-05-11 11:36:15 PDT
Comment on
attachment 399017
[details]
Patch View in context:
https://bugs.webkit.org/attachment.cgi?id=399017&action=review
>>> Source/WebCore/platform/mediarecorder/MediaRecorderPrivate.h:107 >>> + m_videoSource->removeVideoSampleObserver(*this); >> >> Maybe add a FIXME about removing these, since they should never be necessary? > > I added them as a just-in-case, maybe we should just keep the ASSERT. > The child class should really do it since otherwise, a half-destructed object might still receive samples.
The child class destructor should do that early on otherwise, the object, while half destructed, might receive samples to process. I'll add a comment.
>>> Source/WebCore/platform/mediastream/RealtimeMediaSource.cpp:210 >>> + observer->videoSampleAvailable(mediaSample); >> >> Clients may perform an arbitrary amount of processing during a callback, so holding the lock for the duration of this loop might be asking for trouble. > > This is the same design as for audio samples. > I think it is fine like it is since receiving video samples should not trigger adding/removing observers, and hopefully these actions will be in different threads.
This lock is locked in add/remove observers which should happen in the main thread while this one should happen in a background thread. Normally, videoSampleAvailable should never synchronously add/remove observers.
Víctor M. Jáquez L.
Comment 8
2020-05-12 00:22:22 PDT
(In reply to youenn fablet from
comment #5
)
> (In reply to Philippe Normand from
comment #4
) > > Thanks for keeping the GStreamer bits compiling! > > np, note that the following step might be to call videoSampleAvailable from > a background thread. > While this may not break compilation, this might require some GTK changes.
Indeed, thanks. I'll look this patch today.
youenn fablet
Comment 9
2020-05-12 02:30:10 PDT
Created
attachment 399111
[details]
Patch for landing
EWS
Comment 10
2020-05-12 04:45:30 PDT
Committed
r261553
: <
https://trac.webkit.org/changeset/261553
> All reviewed patches have been landed. Closing bug and clearing flags on
attachment 399111
[details]
.
Radar WebKit Bug Importer
Comment 11
2020-05-12 04:46:16 PDT
<
rdar://problem/63131874
>
Note
You need to
log in
before you can comment on or make changes to this bug.
Top of Page
Format For Printing
XML
Clone This Bug