On Tue, Jan 20, 2009 at 11:47:59PM +0000, [email protected] wrote: > From: David Flynn <[email protected]> > > This is a set of api changes which significantly reduces the burden on > users of the schroedinger library. > > I have another set of changes which depends upon this for tagging, but > ~20 patches ought to be enough for today. > > Please do not commit any of this, i need to cast a final eye over it > tomorrow and add some extra comments in some places.
I'm not sure I like the direction of this. It is my observation that the best place to put the division between media framework and decoder is at the picture level. That is, the media framework (say, the gst plugins) provide a bunch of bits that it thinks is a picture, and the decoder either decodes it, or returns an error. There are many reasons for this, including proper error handling and especially timestamp handling. (Please note that schro doesn't do any of this right currently.) In more detail regarding timestamp handling, the media framework generally has a bunch of buffers with timestamps on some of them. If it sorts these buffers into pictures itself, it can assign the timestamps to the pictures as it deems correct. If it passes these buffers verbatim to the decoder, then a) the decoder has to take care of the timestamps (and/or who knows what other metadata) and b) assign them to pictures using rules it doesn't necessarily know. As for error handling, I believe that errors at the picture level are much easier to describe: a) decodes, b) does not decode. At the bit/buffer level, it needs to be much more complicated, including a) You just gave me 7000 pictures, b) you just gave me complete garbage, c) you just gave me complete garbage combined with 7000 pictures. It is, of course, important to provide code that makes it easy to use the library. However, I think it's better to provide generic parsing code and say "please modify this as fits your framework" rather than provide a parsing API that might not fit. dave... ------------------------------------------------------------------------------ This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword _______________________________________________ Schrodinger-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/schrodinger-devel
