Skip to content
GitLab
Projects Groups Snippets
  • /
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in / Register
  • gstreamer gstreamer
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
  • Issues 936
    • Issues 936
    • List
    • Boards
    • Service Desk
    • Milestones
  • Merge requests 440
    • Merge requests 440
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Schedules
  • Deployments
    • Deployments
    • Environments
    • Releases
  • Packages and registries
    • Packages and registries
    • Container Registry
  • Monitor
    • Monitor
    • Incidents
  • Analytics
    • Analytics
    • Value stream
    • CI/CD
    • Repository
  • Snippets
    • Snippets
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • GStreamerGStreamer
  • gstreamergstreamer
  • Issues
  • #471
Closed
Open
Issue created Dec 02, 2019 by Thibault Saunier@thiblahute🌵Maintainer

Deprecate gst_pad_[sg]et_element_private ?

As discussed many times and as recent patches have shown, the use of that API is not MT safe (see !191 (merged) for example). Generally it is better to go and subclass GstPad for those cases, even if it involves some boilerplate code (though it is not that much now that we have G_DECLARE_ marcos).

Alternatively we could try to add another safe in the same spirit, but tbh I feel that this API is basically a hack to avoid subclassing GstPad :-)

Assignee
Assign to
Time tracking