After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 774149 - nlecomposition: De-duplicate seek events based on their sequence number
nlecomposition: De-duplicate seek events based on their sequence number
Status: RESOLVED FIXED
Product: GStreamer
Classification: Platform
Component: gst-editing-services
unspecified
Other All
: Normal normal
: 1.10.1
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2016-11-09 15:15 UTC by Sebastian Dröge (slomo)
Modified: 2016-11-12 08:43 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
nlecomposition: De-duplicate seek events based on their sequence number (3.42 KB, patch)
2016-11-09 15:15 UTC, Sebastian Dröge (slomo)
committed Details | Review
nlecomposition: Fix small remaining race in previous commit (2.92 KB, patch)
2016-11-10 13:20 UTC, Sebastian Dröge (slomo)
committed Details | Review

Description Sebastian Dröge (slomo) 2016-11-09 15:15:05 UTC
See commit message
Comment 1 Sebastian Dröge (slomo) 2016-11-09 15:15:09 UTC
Created attachment 339400 [details] [review]
nlecomposition: De-duplicate seek events based on their sequence number

If there are e.g. multiple video sinks, we would get the same seek event
multiple times. But we only want to handle it once.
Comment 2 Thibault Saunier 2016-11-09 15:25:23 UTC
Review of attachment 339400 [details] [review]:

Looks good.
Comment 3 Sebastian Dröge (slomo) 2016-11-09 16:09:32 UTC
Attachment 339400 [details] pushed as ff6dc38 - nlecomposition: De-duplicate seek events based on their sequence number
Comment 4 Sebastian Dröge (slomo) 2016-11-10 13:20:16 UTC
Created attachment 339482 [details] [review]
nlecomposition: Fix small remaining race in previous commit

The seek action might currently be handled (in which case it is not in
the actions list and the action lock is not locked), but not actually
handled completely yet (the seqnum is not stored yet).

To prevent this, we remember what the current action is that is being
handled, and also compare to that.
Comment 5 Thibault Saunier 2016-11-10 13:37:27 UTC
Review of attachment 339482 [details] [review]:

Would't it make sense to remove the action from the lisyt only when it is done instead of adding that code?
Comment 6 Sebastian Dröge (slomo) 2016-11-10 15:11:38 UTC
I've not done that to make it more explicit that this very action can't be stopped anymore. If you call remove_actions_to_type() for example and it would remove that action, that would result in a weird situation.

Once the action is "current_action", you can observe it but not change it anymore.
Comment 7 Thibault Saunier 2016-11-10 15:47:54 UTC
(In reply to Sebastian Dröge (slomo) from comment #6)
> I've not done that to make it more explicit that this very action can't be
> stopped anymore. If you call remove_actions_to_type() for example and it
> would remove that action, that would result in a weird situation.
> 
> Once the action is "current_action", you can observe it but not change it
> anymore.

Well a field on the Action closure would be enough for that, I suspect special casing here is not necessary.
Comment 8 Sebastian Dröge (slomo) 2016-11-10 15:51:02 UTC
It seemed cleaner to me this way, but that also works. An additional field that would have to be handled by all functions that currently go over that list

Should I change it accordingly?
Comment 9 Thibault Saunier 2016-11-10 19:54:12 UTC
Yeah, right I guess it is good like that too, go ahead.
Comment 10 Sebastian Dröge (slomo) 2016-11-11 05:44:44 UTC
Comment on attachment 339482 [details] [review]
nlecomposition: Fix small remaining race in previous commit

Attachment 339482 [details] pushed as acfa0e9 - nlecomposition: Fix small remaining race in previous commit