Re: Re: An apology about the mass subscription to media-api list - and the reasons why .....
Enrico Weigelt <[email protected]>
| Newsgroups | gmane.comp.multimedia.media-api |
|---|---|
| Message-ID | <[email protected]> |
* Steve Lhomme <[email protected]> [2004-01-06 20:41:28 +0100]: <snip> > Is there any multimedia system with plugins that doesn't use threads ? > That sounds very strange (and inefficient) to me. What kind of system > doesn't have multithreads ? mplayer ? <snip> > >3. We should not limit to one fixed internal encoding/resolution. > > Better let all devices tell their supported formats and additional > > metric information for them. > > Yeah, I chose this to make it easier to handle. And as it's audio-only. > If video is used that's more complicated. Well, we have to keep in mind, that we may also have multiple audio and video streams. Also much hardware has support for several encodings and formats - we should be able to use this as optimal as possible. (same w/ mm protocols) <snip> > >4. How should speed modification work together w/ timestamps ? > > Are they also stretched ? How does the buffer management work then ? > > The time-stretcher handles the timestamp tweaking to fit the output. > Also the timestamp is in samples (IIRC). Coupled with a sampling freq it > could be converted to time when muxed with video... IMO that's much > better to keep samples for audio and frames for video along the process. hmm. well, if we have a virtually continous stream between the codecs and they also support precise seeking, we could use frame ids as a kind of timestamp. getlatency() returns the amount of frames which the codec requires to be buffered. seeking in long streams is quite tricky. if all codecs allow seeking by frame ids (timestamps), it helps a lot, but which component should make the first when seeking ? <snip> > >3. How could we implement frame skipping (like mplayer's -framedrop) ? > > Could be a plugin that also tweak timestamps. how can we do this ? framedrop should start in the first decoder (or perhaps also in others?) it has a decision when to skip a frame. in this case it simply passes an empty frame to its output (gap frame -> tells the component behind, that evrything remains the same) > >4. How to handle seeking ? > > I think I described it in the ODJ page. It's done from the source > "filter" and goes downstream as new data are processed. (using messages) who is the source ? the demux ? or the first codec ? cu -- --------------------------------------------------------------------- Enrico Weigelt == metux IT services phone: +49 36207 519931 www: http://www.metux.de/ fax: +49 36207 519932 email: [email protected] cellphone: +49 174 7066481 --------------------------------------------------------------------- Diese Mail wurde mit UUCP versandt. http://www.metux.de/uucp/