On 2009-01-21, David Schleef <d...@entropywave.com> wrote: > On Tue, Jan 20, 2009 at 11:47:59PM +0000, davidf+n...@woaf.net wrote: >> From: David Flynn <dav...@rd.bbc.co.uk> >> >> 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.)
I don't see that this changes any of that, you are still at liberty to build a buffer per picture, tag it with whatever metadata you want and feed them in one at a time. The only bit that i've changed is that you don't get notified of a parse error. But then, i don't think that is very useful to the media framework -- what can you realistically do with such an error, i don't think its realistic to rerequest the data for instance. > 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. Disagree, i think its very simple: - Usually some demuxer has produced a buffer with an associated set of time stamp metadata. This will usually follow the encapsulation rules, which universally are that ``time stamps apply to the first picture data unit to commence after the timestamp'' This is justas true of things like MPEG2 and MPEG2TS. So i think you can just pass them on. - The rule i've used in the tagging patch set is that the timestamp applies to the next picture unit to commence from the start of buffer the timestamp is tagged. - NB, i use 'timestamp' loosely here. For decoding they are essentially (void*) because as a decoder, we don't care. Now if that model isn't quite what the application needs, and it has to futz with the buffers, it can -- nothing stops it doing so and it will then behave as intened (and as you suggest). > As for error handling, I believe that errors at the picture level > are much easier to describe: a) decodes, b) does not decode. At This is true, but also unhelpful. > 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. Again, until someone can provide a useful usecase for decoder reporting errors at parse time, i don't think it should block any of this. NB, while it would be possible to insert 7000 pictures into the decoder thats not what the api requires. What would be useful is for the transport to be able to signal that an there is an error in the buffer. eg, a dropped TS packet, IP packet, etc., On the subject of errors, it may be useful to have an indication that the decoder has been able to synchronise and sucessfuly parse something. That handles nicely the case where `it isn't a dirac stream'. > 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. Indeed; however, again i am quite against dolling out all the parsing framework for people to implement blindly. It is complicated to get it absoloutly right and dealing with it in the library seems appropriate. NB, if low level access to the decoder is still required (which could return parse faults), that would be trivial and appropriate. ..david ------------------------------------------------------------------------------ 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 Schrodinger-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/schrodinger-devel
