blob: bc011d060249001bbc95cf19d31bc1786952127e [file] [log] [blame]
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
- 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
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.