On Tue, Jun 9, 2009 at 7:56 AM, Michael Niedermayer <[email protected]>wrote:
> On Mon, Jun 08, 2009 at 10:17:51PM +0200, Vitor Sessak wrote: > > @Michael: If you are going to complain of having start_buffer() for audio > > and start_frame() for video, this it the best time for it. > > well, iam not sure if its the best time ... > best time would be if theres a description of the planed design on the > table > or if theres enough code to infer from it the planned design. > > As is its hard to comment, because i simply dont yet see where this is > heading toward > > in video we have single frames at a time or single slices at a time that > are > passed around, the functions are designed to handle these > frame start slice0 slice1 ... sliceN frame end > > in audio we have samples, handling a single sample at a time is not > practical. And samples are not truly bundled in clear frames ... > I didn't use a clear-cut naming convention up to this point, and agree that my choice of variables is a bit schizophrenic. I can standardize them to be in line with that description. > > request_frame() possibly should be extended by a int sample_count argument > draw_slice() seems useful with y & height representing > start sample and count > I added something like that in the commit I pushed last night. Buffer size should be able to be adjusted by the user. > > one big question is about the buffer layout and the awnser would > likely affect the API that makes sense to it. > > there have been old discussions on mplayer-dev with rich and > possibly ivan about audio filters and buffering ... > > Goals would certainly be > * filters should be simple > * core should be simple > * no or few memcpy/memmove > > Things to keep in mind > * many filters do need multiple input samples for an output sample > -> thus the filter core must be able to do some buffering magic > giving a filter a little future and past context if needed, the > amount of that would be requested by the filter > * audio data can be stored packed and planar, both must be supported > there also where some disscussions on how to fit this in > data & linesize > > [...] > Yes, I've considered these things in thinking about designing the system. memcpy/memmove would be detrimental to the speed of the system. As for the design of the filters, I currently have them set up much like the video filters. Namely, they have a linked list of input and output pads, and init/end function hooks. As I see it being done in the video filters, the actual functions that perform manipulation of the data are hooked into the AVFilterPad structure (like start_frame, end_frame, draw_slice), and I have begun to replicate these functions to handle the audio equivelent of AVFilterPic, which I called AVFilterSamples As for core, I dont anticipate much change from what is currently in place. The biggest part of modifying the core will be in negotiating audio format conversions, if necessary. E.g, a filter A puts out fl32 to filter B, which is expecting sl16. I'm planning on avoiding memcpy's by having a pointer to the buffer be passed to each sequential filter, so the memory doesnt have to move. My plan is to put about 2-3 hours in a night, hopefully by the end of the week we'll have something that people can seriously criticize :-) -- Kevin DuBois [email protected] PGP fingerprint 80CF 7C1D 0A1C BE03 2203 95B6 1515 C3DC B6BE 7E88 _______________________________________________ FFmpeg-soc mailing list [email protected] https://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-soc
