-
Notifications
You must be signed in to change notification settings - Fork 63
gstreamer: Decouple ownership of the GstPlay/AppSrc from signal callbacks #456
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
gstreamer: Decouple ownership of the GstPlay/AppSrc from signal callbacks #456
Conversation
|
@jdm < Please take a look |
|
There is crash under heavy testing scenario, so please postpone review |
Instead of going this way, you might want to use the |
…acks The associated signal callbacks shouldn't capture strong or weak references of a owner `GstPlay` object with which they are interact otherwise it leads to leaked underlying media resources. Note that upgrading the captured weak reference for a `GstPlay` object on another thread (the `GstPlay` streaming thread) is not safely because a `GstPlay` object could be destroyed on that thread after signal callback handling with mutex panic on the `gst_play_finalize`. To solve the `GstPlay` ownership issue between client and Gstreamer was introduced the player shared state with minimal required states (`metadata`, `pending playback rate`, `play state`, ...). Anyway the captured `GstPlay` weak reference will be used on sync `source` setup stage which is locking the client thread until a source will be ready. For `GstAppSrc` and associated `seek_data` callback a capture of a weak reference will be used with explicit set `empty` callbacks on a player destruction. Fixes: servo#455 Signed-off-by: Andrei Volykhin <andrei.volykhin@gmail.com>
cb36475 to
32098e8
Compare
|
@jdm < Please take a look |
The associated signal callbacks shouldn't capture strong or weak references of a owner
GstPlayobject with which they are interact otherwise it leads to leaked underlying media resources.Note that upgrading the captured weak reference for a
GstPlayobject on another thread (theGstPlaystreaming thread) is not safely because aGstPlayobject could be destroyed on that thread after signal callback handling with mutex panic on thegst_play_finalize.To solve the
GstPlayownership issue between client and Gstreamer was introduced the player shared state with minimal required states (metadata,pending playback rate,play state, ...).Anyway the captured
GstPlayweak reference will be used on syncsourcesetup stage which is locking the client thread until a source will be ready.For
GstAppSrcand associatedseek_datacallback a capture of a weak reference will be used with explicit setemptycallbacks on a player destruction.Testing: Manually testing with the following WPT test
GST_DEBUG=3,gst-play*:7 ./mach test-wpt html/semantics/embedded-content/the-video-element/intrinsic_sizes.htm -rFixes (partially): #455