| 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. | |