found these somewhere

Original commit message from CVS:
found these somewhere
This commit is contained in:
David Schleef 2004-05-14 20:06:49 +00:00
parent 9fa85fa424
commit 3785cdbea4
3 changed files with 161 additions and 0 deletions

View file

@ -0,0 +1,30 @@
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)

81
docs/random/ds/caps Normal file
View file

@ -0,0 +1,81 @@
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.

50
docs/random/ds/categories Normal file
View file

@ -0,0 +1,50 @@
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