[FFmpeg-user] astreamsync freezes?

Nicolas George nicolas.george at normalesup.org
Tue Sep 4 18:37:12 CEST 2012


Le quartidi 14 fructidor, an CCXX, Roger Pack a écrit :
> I believe I do.
> It may be useful for a filter I'm trying to implement that does audio
> cancelling (speex).
> 
> Basically if the input could be guaranteed to receive the "send"
> timestamped audio before "receive" timestamped audio then it I could
> simplify its internal logic.
> 
> My original goal was to do something like
> 
> $ ffmpeg -i stream1 -i stream2 -filter_complex "[0] asetnsamples=n=100
> [a]; [1] asetnsamples=n=100 [b]; [a] [b] astreamsync [a2] [b2]; [a2]
> [b2] aechocancel"
> 
> So that I could have lots of small'ish audio packets sent into the
> audio cancel filters, but in approximately the right order (small
> packet from a, then small packet from b, interleaved).  This might
> allow the echo cancel filter to more simply be able to operate on
> "small packets" instead of having to do its own internal buffering,
> etc. which may allow it to use a smaller "internal buffer" which,
> according to the speex docu, is supposedly more effective (and save
> cpu, etc.)
> 
> If that makes any sense at all.

It does indeed make sense. This is not the preferred design at this time,
though: currently, filters with several inputs are expected to work by
themselves to ensure proper sync. Actually, "preferred" is a bit of a
stretch, there are currently only three filters with that kind of features:
overlay, amerge (work like that) and alphamerge (requires frame-exactness,
fix in TODO list).

Of course, it can be discussed, but I am affraid that an API to do that kind
of thing automatically with additional filters would be very hard to design,
especially if it must be nimble enough to allow various combinations.

I believe that having queues inside the private context of the filters and a
set of well-thought helper functions to handle the various cases is a
simpler and more robust approach.

Regards,

-- 
  Nicolas George
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://ffmpeg.org/pipermail/ffmpeg-user/attachments/20120904/96701fe7/attachment.asc>


More information about the ffmpeg-user mailing list