>General guidelines: I'd like to avoid module operation explosion
>and to add corner-case methods *if possible*. Of course, if
>avoiding to add more operations renders code clumsy or bad looking,
>the way to go it's just to add a new operation.
I certainly agree here.
>I see mainly a few ways:
>
>- adding a general flush() method. That could be useful also
> for multiplexors, but api lacks a clear fit. Encoders needs
> to return buffered data, while multiplexors needs not.
>
> int (*flush)(TCModuleInstance *self, frame_list_t *outdata);
>
> one more problem: should we use a generic pointer? (looks unclean)
> adding flush_video and flush_audio looks even worse.
One thing I'm hoping we can do once NMS is in place is get rid of
frame_list_t entirely, so this isn't an approach I'd want to take.
>- adding encode_last_frame() or something like it. Definitively
> a corner case (how many encoders needs this?), that's the way
> I like less.
The real problem is that audio codecs (except PCM, of course) don't
support an arbitrary number of samples per data block, and I suspect all
audio encoders will have to deal with this in one way or another. We could
always say that any partial audio frames at the end of the stream get
discarded, and if you want video-frame-accurate audio use PCM, but I don't
think that would go over too well. ;) So I'd say there's justification for
adding an operation like this.
As to the implementation, I'm still wavering between adding a new
method and overlaying encode_audio(). On one hand, I agree with you in
wanting to keep the number of methods down to a minimum; on the other hand,
there's no real clean way to do it within encode_audio().
Actually, on second thought, we could pass a normal aframe_list_t with
an audio_len of zero, and then codecs that didn't have to flush could just
handle it like an ordinary audio frame. So the last step of encoding
(after the encoder runs out of input data) would look something like:
aframe_list_t dummy_in, flush_out; // pretend they're initted
dummy_in.audio_len = 0;
encode_audio(&dummy_in, &flush_out);
if (flush_out.audio_len > 0)
multiplex(NULL, &flush_out); // no video, just the flushed audio
How does that look to you?
>- modify close() to return buffered data lead to problems like
> flush() ones (generic pointer? vframe_list_t? aframe_list_t?),
> so doesn't look good.
That reminds me, did we ever figure out what we were going to do with
open() and close()? I took a quick look at tcmodule*.h, but it doesn't
look like they're in the structures yet. Actually, since we already have a
stop(), it might be simpler to let stop() handle file closing and add a
start() method for file opening--that way we can also redefine configure()
so that it's only for configuring and doesn't act like a start() as well.
--Andrew Church
[EMAIL PROTECTED]
http://achurch.org/
