On Fri, 02 Feb 2007 17:46:52 +0530 "Robrek V." <[EMAIL PROTECTED]> wrote:
> Yes. If the frame_buffer_t - which from my initial understanding is the > basis for Audio/Video Access unit Storage: Kinda of. We're not so satisfied of such structur and I'm not satisfied at all of our framebuffer handling. > This structure could have various attributes filled up based upon the > processing stage the frame is in? Yes, depending of filters but also core is allowed to change some values. > For example - Clock information,derived from container format could be > added to the frame_buffer_t . This tagged information would be retained > through the post/pre/encoding and be used in AV sync activities in the > final stage. > How is Av sync achieved currently? There is a few methods - and that already isn't optimal - (see -M option), the default anyway is less or more ``get frames in decoded order and hope for best''. > I, Makes any sense? Your proposal makes definitively sense, but require some heavy core changes, and most important a better (well, in fact just `a') demuxing layer. > > - proper frame marking (based on above) > pray elaborate? transcode aims to support most formats as possible for I/O; some of them can't have notion of timestamping at all (group of images, plain YUV streams, maybe YUV4MPEG2 too IIRC), so a more general kind of `virtual' timestamping is needed. > > - dealing with missing/skipped/corrupted frames on source > > > could this be handled by having video Stream as the Master clock? Yes, AFAIK yes. Bests, -- Francesco Romani - Ikitt ['people always complain, no matther what you do'] IM contact : (email first, Antispam default deny!) icq://27-83-87-867 tiny homepage : http://fromani.exit1.org (see IDEAS if you want send code!) known bugs : http://tcfoundry.hostme.it/mantis (EXPERIMENTAL)
