mirror of
https://gitlab.freedesktop.org/gstreamer/gstreamer.git
synced 2024-09-08 13:18:52 +00:00
268 lines
12 KiB
Text
268 lines
12 KiB
Text
|
|
|
|
Properties:
|
|
|
|
"template_caps"
|
|
The union of all possible caps that a pad might have in any
|
|
condition. Is a class property, and doesn't change over the
|
|
life of an object. Set by the element during class init.
|
|
|
|
"internal_caps"
|
|
The caps that the element will allow on a pad, given its current
|
|
state and the external_caps of all the other pads of the element.
|
|
Set by the element.
|
|
|
|
"external_caps"
|
|
The caps representing what the core will allow on a pad. This is
|
|
a combination of the peer's allowed caps, and filtering caps, and
|
|
any in-process negotiation restrictions. Set by the core.
|
|
|
|
"negotiated_caps"
|
|
The format that the element will use. Set by the core.
|
|
|
|
"filter_caps"
|
|
The caps intersected with everything else during negotiation. Set
|
|
by the application.
|
|
|
|
"negotiable"
|
|
A boolean that indicates that the pad is ready to negotiate. Set
|
|
by the element.
|
|
|
|
|
|
|
|
Negotiation steps, from the element perspective:
|
|
|
|
- During object initialization, an element must set template_caps
|
|
and allowed_caps for each pad.
|
|
|
|
- In response to changes in the internal state of the element or in
|
|
the peer_allowed_caps of any other pad owned by the element, the
|
|
element should update allowed_caps of a pad.
|
|
|
|
- Pads are initially created with negotiable as FALSE. When an
|
|
element wants to indicate that negotiation is allowable, it should
|
|
set negotiable to TRUE.
|
|
|
|
- In response to a negotiate signal, an element should copy the caps
|
|
in "allowed_caps" to "negotiated_caps", and extract any information
|
|
needed to handle the format. At this point, "allowed_caps" is
|
|
guaranteed to be fixed.
|
|
|
|
|
|
Negotiation steps, from the core perspective:
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
<ds> I'd like to split it up into manageable "projects"
|
|
<ds> hopefully some of which we can recruit others to do
|
|
<Company> i'd like a decision about if we drop threads
|
|
<ds> in what sense?
|
|
<ds> threads being not required?
|
|
<Company> threads being not part of the API
|
|
<ds> or threads being not used
|
|
<Company> so no thread safety considerations
|
|
<ds> I would like threads to not be part of the API
|
|
<ds> requiring apps/plugins to be written thread-safely is insane
|
|
<Company> the question is this: If someone calls gst_element_set_state (element, state), does he have to marshal it into the correct thread himself or not?
|
|
<ds> no
|
|
<ds> reason being: we already have to deal with subthreads
|
|
<ds> we == the core
|
|
<Company> then you'll have a lot of problems
|
|
<Company> i'd like to just drop subthreads and be done with it
|
|
--> StyXman (~mdione@200.59.114.71) has joined #gstreamer
|
|
<ds> and run everything in one thread?
|
|
<Company> yes
|
|
<Company> schedulers are free to use threads though
|
|
<ds> this is obviously a retreat
|
|
<Company> right
|
|
<ds> but perhaps a strategic one
|
|
<Company> otherwise you have to guarantee that you get no races
|
|
<ds> I've seen this as a viable option for some time
|
|
<Company> there's stuff that just does not work as is currently
|
|
<ds> it always seemed difficult to convince other people that it's the right thing to do
|
|
<ds> for example, wtay
|
|
<Company> like setting xwindow ids, changing states or app-events
|
|
<Company> like seeks
|
|
<-- iain has quit ("leaving")
|
|
<Company> all of this has the typical thread issues currently: it sometimes works and sometimes crashes the app
|
|
<Company> and that's not acceptable to me
|
|
<ds> let's do it
|
|
<Company> if you look at my 0.10 code, I've tried to have GstObjects belong to a "context"
|
|
<ds> this all fits into the idea that I think we should be a lot more like gtk architecturally
|
|
<ds> for example, gtk doesn't have anything like caps negotiation, where elements call each other recursively
|
|
<Company> and have functions ensure they're in the right context or otherwise marshal
|
|
<Company> yes it does
|
|
<ds> ?
|
|
<Company> size requests and allocations
|
|
<ds> but that's more like how I want it -- setting a property and firing a signal telling others that it's updated
|
|
<ds> as i understand it
|
|
<Company> though gtk has the bonus of being a tree which we don't have, we have a directed, maybe cyclic graph
|
|
<Company> and for caps, the graph isn't even directed
|
|
<Company> gtk is far too simple for gst
|
|
<ds> true
|
|
<Company> i can't even come up with an analogy to a video transcoder
|
|
<ds> but we do some relatively simple stuff in a complicated way
|
|
<-- StyXman (~mdione@200.59.114.71) has left #gstreamer
|
|
<Company> like?
|
|
<ds> caps negotiation
|
|
<Company> that's not simple
|
|
<ds> passing around the data should be
|
|
<ds> was it you or thomasvs that wanted to split core headers into app headers and plugin headers?
|
|
<Company> I definitely wanted that
|
|
<Company> app/plugin/registry to be exact
|
|
<ds> registry?
|
|
<ds> for functions that access "internal" stuff?
|
|
<Company> stuff an app normally doesn't touch
|
|
<Company> so we can do something like declare the "app" stuff supported for a longer time
|
|
<ds> oooh, good call
|
|
<ds> I'm sold
|
|
<Company> so, now that threads are gone, what are the biggies I want in 0.10?
|
|
<Company> 1) non-blocking main-loop integrated processing
|
|
<ds> that's rather important if you don't have threads :)
|
|
<Company> right
|
|
<Company> but it works in my gst-01.0 stuff already
|
|
<Company> minus the elements that need to be ported of cause
|
|
<Company> which aren't that many fortunately
|
|
<Company> though some are hard (like gnomevfs), because they have no non-blocking API
|
|
<ds> a subclass of GstElement that fires up a helper thread?
|
|
<ds> (dirty, but it works)
|
|
<Company> probably
|
|
<ds> - autopluggers would be easier to write if there was a core method
|
|
<ds> to do what plugidentities do.
|
|
<Company> no clue how to implement that
|
|
<ds> there's also a note about bins being more involved with negotiation
|
|
<Company> that's the next biggie: 2) fix the negotiation process to allow good autoplugging
|
|
<ds> that was something I thought about last time around
|
|
<Company> bins?
|
|
<ds> that sounds like something I'd work on
|
|
<ds> GstBin
|
|
<Company> the only reason bhins still exist for me is to group elements
|
|
<ds> so that a bin subclass could override how its children are negotiated
|
|
<ds> much like GtkBin, actually
|
|
<ds> and allocation
|
|
<Company> hum
|
|
<Company> how do you solve that issue with links that are only partly inside the bin and partly inside another one?
|
|
<ds> that would be up to the parent (grandparent?)
|
|
<Company> so all links must be in the same toplevel bin?
|
|
<ds> yes
|
|
<ds> isn't that the case currently?
|
|
<ds> probably not checked
|
|
<Company> pfff
|
|
<Company> currently you can do anything
|
|
<ds> heh
|
|
<ds> what about state changes?
|
|
<Company> dunno
|
|
<Company> it's not really important for me
|
|
<Company> apart from the EOS stuff
|
|
<ds> I'd like states to be split into "what state does the app want me to be in" and "what state am I in"
|
|
<ds> with the latter being under control of the element
|
|
<Company> yeah, that'd be nice
|
|
<ds> that way, you don't have multiple people trying to control the state
|
|
<Company> we definitely need to fix EOS
|
|
<Company> i'm not sure how we should handle errors
|
|
<ds> element errors?
|
|
<Company> yeah, if we want to explicitly unset errors or not
|
|
<Company> currently on error the element goes to paused
|
|
<ds> it's easier with actual_state
|
|
<Company> in theory i just set it to PLAYING again and continue?
|
|
<ds> the actual_state goes to PAUSED and fires a signal
|
|
<Company> dunno, maybe actual_state should go to ERROR
|
|
<ds> yeah
|
|
<Company> that'd require gst_element_unset_error though
|
|
<ds> with actual_state, we can add states without thinking too hard
|
|
<Company> but if you can just unset it, why not just do it and continue
|
|
<ds> the app may want to be involved
|
|
<ds> especially to get the error message
|
|
<ds> do we want a separate api section for autopluggers?
|
|
<Company> why would we want that?
|
|
<ds> or make it part of registry
|
|
<Company> maybe s/registry/internal/ or some other name
|
|
<ds> because autopluggers may want to access internal information that we wouldn't expose to apps or plugins
|
|
<ds> could you add gst/gstcompat.c to your arch repo?
|
|
<Company> hm
|
|
<Company> what internal info would an autoplugger need
|
|
<ds> depends
|
|
<ds> whatever replaces plugidentities
|
|
<Company> a simple one (decoder) just needs caps and ranks
|
|
<ds> I meant for negotiation information
|
|
<Company> hm
|
|
<Company> no, i don't want a seperate section for it
|
|
<Company> just put it in "internal", "extended" or whatever
|
|
<ds> ok
|
|
<ds> do we want to plan for the app api to be ABI compatible past 0.10?
|
|
<ds> er, that's silly
|
|
<ds> er, kinda silly
|
|
<Company> API compat
|
|
<Company> you could achieve ABI compat if you expose all objects just as typedefs
|
|
<Company> lemme reboot into linux so i can add gstcompat.c
|
|
<Company> brb
|
|
<-- Company has quit (Read error: 104 (Connection reset by peer))
|
|
--> Company (~Company@pD95D53D9.dip.t-dialin.net) has joined #gstreamer
|
|
--> ploum (~ploum@21-4.CampusNet.ucl.ac.be) has joined #gstreamer
|
|
<-- marv has quit (Read error: 104 (Connection reset by peer))
|
|
<ds> so do you still support caps registration?
|
|
<-- ploum has quit (Client Quit)
|
|
<ds> registering media types, fields, descriptions, and default fixate functions?
|
|
<ds> and validation
|
|
<Company> yes
|
|
<Company> that's an important thing we need
|
|
<Company> otherwise people mess up by either carelessly doing stuff wrong or not understanding what they're supposed to do
|
|
<ds> whose responsibility is it to register these?
|
|
<ds> libgstplugins?
|
|
<ds> a plugin?
|
|
<ds> do we want this info in the registry so that a plugin can automatically be loaded to provide registration for video/x-raw-rgb?
|
|
<Company> haven't really thought about that part yet
|
|
<ds> it's somewhat similar to typefind functions
|
|
<Company> yeah
|
|
--> ultrafunk (~pd@eth779.vic.adsl.internode.on.net) has joined #gstreamer
|
|
<Company> i'd probably have a seperate Factory for caps info
|
|
<Company> and have the system load them when you use the caps info stuff
|
|
<ds> should caps info be manditory?
|
|
<ds> have you synced your repo?
|
|
<Company> i'm trying to, but some commit was interrupted last time...
|
|
<ds> how does one sync a local repository to fd.o?
|
|
<ds> rsync?
|
|
<Company> tla archive-mirror
|
|
<ds> ah
|
|
<Company> see rhythmbox.org => developers for how it works
|
|
<Company> and _never_ press ctrl-c in arch
|
|
<-- Misirlou has quit (Remote closed the connection)
|
|
--> Misirlou (~asdf@c-24-125-118-27.va.client2.attbi.com) has joined #gstreamer
|
|
<ds> is there a reason why a pad might know (and set) allowed_caps, but not be ready to negotiate?
|
|
<Company> i don't know a good one
|
|
<ds> know a bad one?
|
|
<Company> "arch-mirror: unable to acquire revision lock (internal error in archive-pfs.c(pfs_lock_revision))"
|
|
<Company> stupidly ordered code
|
|
<Company> no, don't know one
|
|
<ds> here's a good question:
|
|
<ds> should the core negotiate links in a pipeline that are negotiatable, even though some other links are not negotiatable?
|
|
<ds> this ends up making us negotiate some things multiple times
|
|
<ds> filesrc ! mad ! audioconvert ! audioscale ! osssink
|
|
<Company> the core doesn't know if links are negotiable
|
|
<ds> it will in the future :)
|
|
<Company> sinesrc ! identity ! osssink
|
|
<Company> how does it know if sinesrc ! identity is negotiable?
|
|
<ds> because the allowed_caps on the two pads intersect
|
|
--> marv (~ilovekimm@host-216-76-232-134.hsv.bellsouth.net) has joined #gstreamer
|
|
<ds> I'm pretty sure that I don't want gst_pad_link() to return negotiation errors
|
|
<ds> ever
|
|
<Company> you can't avoid that
|
|
<ds> I want to separate "linkable" from "negotiable"
|
|
<Company> ah, gst_pad_link
|
|
<ds> so you can link videotestsrc ! identity ! osssink
|
|
<Company> i confused it with GstPadLink
|
|
<Company> yeah, i was thinking about that, too
|
|
<ds> vts ! osssink won't link, since the pad templates don't intersect
|
|
<Company> http://web.ics.purdue.edu/~kuliniew/wp/archives/2004/08/07/error-handling/
|
|
<Company> :)
|
|
<ds> right now the vts ! id ! osssink pipeline fails to link
|
|
<Company> yeah
|
|
<Company> and goom ! xvimagesink only fails when xvimagesink is at least READY
|
|
<Company> (assuming your xv can't do RGB)
|
|
|
|
|
|
|