--- /dev/null
+
+
+Buffers should have readlocks and writelocks to enforce
+GST_BUFFER_DONTKEEP and relax the restriction that buffers with
+multiple refcounts are read-only.
+
+
+
+Example:
+
+ videotestsrc ! ximagesink
+
+ videotestsrc requests a buffer from its src pad
+
+ ximagesink creates a buffer (refcount:1 readlock:0 writelock:0)
+
+ videotestsrc writelocks it (refcount:1 readlock:0 writelock:1)
+
+ videotestsrc writes to the buffer
+
+ videotestsrc un-writelocks it (refcount:1 readlock:0 writelock:0)
+
+ ximagesink readlocks it (refcount:1 readlock:1 writelock:0)
+
+ ximagesink writes it to the screen
+
+ ximagesink un-readlocks it (refcount:1 readlock:0 writelock:0)
+
+
+
--- /dev/null
+
+
+Problem #1:
+
+ How does the core allow the application to choose appropriate
+ caps in the following cases:
+
+ videotestsrc ! xvimagesink
+
+ videotestsrc ! identity ! xvimagesink
+
+ videotestsrc ! videoscale ! xvimagesink
+
+ Goals:
+
+ - Give the application a clear overview of the formats available
+ and the elements involved.
+
+ - Provide reasonable defaults in as many cases as possible.
+
+ - Allow specialized elements to suggest reasonable defaults.
+
+
+
+Problem #2:
+
+ How does the API express to an autoplugger what an element does?
+
+ Currently, "colorspace" and "videoscale" have approximately the
+ same pad template caps. Until the autoplugger plugs and looks,
+ it has no way to determine that colorspace changes format, and
+ videoscale changes size.
+
+
+
+Problem #3:
+
+ How do we properly handle codec metadata?
+
+ Solution #3a:
+
+ Stream initialization event. This event would be held by all
+ src pads, and pushed to sink pads upon connection, and would
+ flow downstream.
+
+ Solution #3b:
+
+ Put a buffer in the caps.
+
+
+Problem #4:
+
+ (Related to #1) How does one specify that a converter should limit
+ it's conversion? I.e., audioconvert to not change number of channels,
+ or audioscale upsample by 20%. Basically, this means caps based on
+ other caps.
+
+ Solution #4a:
+
+ One can put a converter element into a special bin:
+
+ specialbin.( specialidentity ! converter ! specialidentity )
+
+ Specialbin can then interfere with caps negotiation all it wants.
+
+
+Problem #5:
+
+ (Related to #3) How do we specify stream format information that
+ is non-critical and optional, such as pixel aspect ratio on raw
+ video?
+
+Problem #6:
+
+ How do we specify the difference between nominal values and actual
+ values, such as video frame rate? The actual frame rate may not
+ correspond to the nominal frame rate in the caps, and often a guess
+ is listed.
+
+
+
--- /dev/null
+
+Element Categories:
+-------------------
+
+
+Decoder:
+
+
+Encoder:
+
+
+Converter:
+ A converter has one or more source pads and one or more sink pads.
+ Converter pads may have different caps templates. Converters are
+ expected
+
+
+Filter:
+ A filter has one source and one sink pad. These pads have the same
+ caps and (thus) the same caps template.
+
+ Filters generally do not handle events.
+
+ Filters may have interfaces.
+
+ Filters are generally not autoplugged unless they have interfaces.
+
+
+Source:
+ A source has one source pad and no sink pads.
+
+ Sources usually handle events.
+
+ Sources may have interfaces.
+
+ Sources are not autoplugged.
+
+Sink:
+ A sink has one sink pad and no source pads.
+
+ Sources usually handle events.
+
+ Sources may have interfaces.
+
+ Sinks are not autoplugged.
+
+
+
+Converter/Colorspace
+