>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.

I think the problem in both these cases is that transcode always looks at
frames in relation to where they are in the input stream; hence there must
always be exactly one (possibly dropped or cloned) frame at every stage of
processing for each input frame: (forgive the crude ASCII graphics)

                (Frames)          (**: dropped frame)
                   I0                     I0'
    +--------+     I1     +--------+     *I1'*     +--------+
    | Import | ==> I2 ==> | Filter | ==>  I2'  ==> | Export |
    +--------+     I3     +--------+     *I3'*     +--------+
                   I4                     I4'
                   ...                    ...

If one adds in the demux and mux stages from NMS, things get even more
confusing, so I left them out for this example. (:  What we should be
doing, on the other hand, is treating the streams independently, so each
stage receives a stream and outputs a (completely separate) stream:

                   I0
    +--------+     I1     +--------+     F0     +--------+
    | Import | ==> I2 ==> | Filter | ==> F1 ==> | Export |
    +--------+     I3     +--------+     F2     +--------+
                   I4                    ...
                   ...

In other words, each stage generates its own frame numbers, which are
only used to order frames for the following stage.

If we were to take this approach, the major design change I think we'd
have to worry about is how to dispose of frames at each stage, since we
could no longer rely on seeing a frame come back to know when the
corresponding input frame can be disposed of.  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.  This would mean we can't do zero copy processing,
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?

  --Andrew Church
    achu...@achurch.org
    http://achurch.org/

Reply via email to