mirror of
https://gitlab.freedesktop.org/gstreamer/gstreamer.git
synced 2024-11-23 02:01:12 +00:00
found these somewhere
Original commit message from CVS: found these somewhere
This commit is contained in:
parent
9fa85fa424
commit
3785cdbea4
3 changed files with 161 additions and 0 deletions
30
docs/random/ds/buffer_locking
Normal file
30
docs/random/ds/buffer_locking
Normal 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
81
docs/random/ds/caps
Normal 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
50
docs/random/ds/categories
Normal 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
|
||||
|
Loading…
Reference in a new issue