On Tue, 2009-01-06 at 19:37 +0000, Andrew Church wrote: > >Problem #1: Skipped Frames/holes into frame ID sequence. > >-------------------------------------------------------- > >Problem #2: The handling of cloned frames. > >------------------------------------------ > > I just grabbed those and threw them together because I think they're two > sides of the same coin, so to speak, and it makes more sense to me to > consider them together rather than trying to solve them separately.
Yes they are correlated. The underneath issue seems to be "altering the sequence of frame IDs". [...] > In other words, each stage generates its own frame numbers, which are > only used to order frames for the following stage. So far, fine for me. [...] > What I think we can do is > have the wrapper for each module's process function return the frame > buffer to the free pool after the function returns, e.g.: > > tc_filter_process(ptr); > framebuffer_free(ptr); > > and have each module allocate a new frame buffer for each frame in the > stream it outputs. If I understood correctly, you're worried about the need to do a full copy of a frame when it's cloned, given this new model, am I right? Can't see any other practical problem right now given your proposal and given how code is right now. > This would mean we can't do zero copy processing, Well, we can avoid (to some extent) it using refcounting+CopyOnWrite, as you pointed out. (BTW, memcpy hunt and an effort towards zery-copyiness was one of the objectives that I'm starting to see on my horizon) > but for a first implementation I don't think we should try and stretch > that far. (And it wouldn't be that hard to implement anyway; it'd > probably suffice to add a reference counter to each frame buffer and let > the filter call framebuffer_ref(ptr) if it wants to reuse the same > buffer.) > > Thoughts? It's viable and maybe the cleanest solution. I was also thinking about frame reference, COW and stuff from a while. What I like most about this proposal is that looks to be the more orthogonal on the field. Improving modularity and composability is always nice. Bests, -- Francesco Romani // Ikitt http://fromani.exit1.org ::: transcode homepage http://tcforge.berlios.de ::: transcode experimental forge
