matroska team member
Group: Moderators
Posts: 151
Member No.: 1353
Joined: 15-December 02
|
There was some discussion going on withUCI about how extensive the API should be, and how it should be implemented. (For those that don't know, UCI is supposed to be a crossplatform codec interface.)
This post is mainly for Avery, as he has been battling with vfw for longer than pretty much everyone else, and probably has a pretty big wishlist for how a multimedia API should work. That being said, comments by everyone are welcome and would be greatly appreciated.
There were three basic ideas we had. The following is assuming that UCI would be built with an interface for the application, codec, and container, and that all three would have 2 way communication.
In the first idea, the application is the hub. It communicates with the codecs and containers using a transport layer named UCI. The application can make requests to the codec and container. And the codec and container can make requests to the application. But, the application would be the master, and any information would pass through it. The purpose of UCI would be a set of commands that would be used for communication between everything. Most of the commands would be shared between the codec and container, simplifying the development greatly. It would also allow the easy development of another universal API for things like filters. Again, the commands wouldn't need to vary much between the API's, and UCI would basically be a defined way to transmit information between the application and everything else. The benefit of this is that the development time would be relatively short. Only the transport system and a set of commands would have to be developed, but it would require a little more support from players for things like overlaying the rendered subtitle stream. Gldm prefers this way.
In the second idea, UCI is the hub. The container, codec, and application are all equal in this, and all information passes through UCI. Any node could call another node directly. For instance, the codec could call the container directly, or vice versa, if it needs some information. When a video frame has been decompressed, and a subtitle frame rendered, UCI could handle the alpha overlay internally and the resulting frame could be passed to the application. This is a much more complex messaging system as each data packet would need to be equipped with a timecode, track, source, and destination. UCI would also need to be smarter and 'aware' of what kind of data it was transmitting. A filter layer could also be developed, but I doubt that it would fit right, and would probably be best left to be handled by the application. The benefit of this method is that things become much less complex for the application as most things would be handled within UCI. But development would be much more complex as UCI would have to be able to handle and understand so much more. I prefer this idea, and Blacksun seemed to like it as it would make application development much easier, and apparently it is closer to what DShow can do.
The third idea is to daisy chain everything. Again, UCI is just a transport mechanism. Everything, container, application, codec, and even filters would all be lined up in a loop. Data is passed around the loop, and if it is something the item can process, it is processed and passed on. The closest thing I can think of would be like using AVISynth, everything is processed through a chain. If an item in the chain can't process the data, the item just ignores it and passes it on. The benefit to this is it is very easy to set up and you could stick almost anything in the chain. But this isn't very flexible otherwise, and one item breaking, destroys the chain. Also, it is slower than other methods. This probably isn't the preferred method.
Let me just define what things are in these ideas to avoid any confusion.
Application = Either a player or an encoder. It is basically the user interface, and the way that information is displayed.
Codec = A compressor/decompressor. Uncompressed frames goes into the codec, and come out as compressed blocks of data. When compressed blocks of data go back into the codec, they come out as uncompressed frames, hopefully as close to the originals as possible.
Container = Someplace to store data. Usually compressed blocks are stored, but uncompressed frames can also be stored. The container also stores information about when the blocks or frames should be played, and if/how they should be decoded.
Filter = Something that alters an uncompressed frame. An uncompressed frame goes into the filter, and it comes out as an uncompressed frame, altered in some way.
--------------------
Please take anything I say with many many grains of salt. I can't tell the difference between my AVI and a hole in the ground. |
