[FFmpeg-devel] [RFC] libavfilter audio API and related issues

[Stefano Sabatini]

On date Wednesday 2010-04-28 07:07:54 +0000, S.N. Hemanth Meenakshisundaram encoded:
> Stefano Sabatini <stefano.sabatini-lala <at> poste.it> writes:
> > Follow some notes about a possible design for the audio support in
> > libavfilter.
> > 
> > AVFilterSamples struct 
> > ======================
> > 
> > (Already defined in afilters, but renamed AVFilterBuffer at some
> > point.)
> > 
> > Follows a possible definition (with some differences whit respect to
> > that currently implemented in afilters):
> > 
> [...]
> > 
> > Audio/video synchronization
> > ===========================
> > 
> > Some design work has to be done for understanding how request_samples()
> > and request_frame() can work togheter.
> > 
> > I'm only considering ffplay for now, as it looks simpler than ffmpeg.
> > 
> > Currently audio and video follows two separate paths, audio is
> > processed by the SDL thread thorugh the sdl_audio_callback function,
> > while the video thread reads from the video queue whenever there are
> > video packets available and process them.
> > 
> 
> Currently, the sdl audio callback gets a decoded audio buffer via the
> audio_decode_frame call and then seems to be doing AV sync via the
> synchronize_audio call.
> 
> I was thinking about replacing this with the audio_request_samples function
> suggested above. This is similar to what happens in video. The request_samples
> would then propagate backwards through the audio filter chain until the input
> audio filter (src filter) calls the audio_decode_frame to get decoded audio
> samples and then passes them up the filter chain for processing.

Yes something of the kind get_filtered_audio_samples().

Note also that the filterchain initialization is currently done in
video_thread(), that should be moved somewhere else.

> Does this sound ok? Since the sdl_audio_callback will be making a
> synchronize_audio call only after this, any additional delay introduced by
> filtering would also get adjusted for.

Looks (sounds?) fine, a more general solution may require a
synchronization filter, but I suspect this would require a significant
revamp of the API.

Regards.
-- 
FFmpeg = Free and Fabulous Murdering Plastic Ecstatic Geisha