[FFmpeg-soc] Libavfilter RFC: problem with ffmpeg.c/ffplay.c integration

[Robert Swain]

Hello,

On 02/01/2008, Michael Niedermayer <michaelni at gmx.at> wrote:
> On Wed, Jan 02, 2008 at 12:49:24PM +0100, Vitor Sessak wrote:
> > I've thought in a few solutions:
> >
> > Solution 1 (the closest to the actual code):
> >
> > In the patch in soc svn, a input filter is defined in ffmpeg.c. A
> > solution would be to move the call to av_read_frame and
> > avcodec_decode_video to the request_frame method of the input filter, so
> > it'll decode a video frame from the file each time the filter asks for one.
> >
> > Problem: Messy, ugly to handle audio and -vcodec copy, makes ffmpeg.c
> > even more complex than it is already, scare people away of using
> > libavfilter in other applications.
>
> APIs aside, theres an additional problem
> the source can be from the network or a v4l card and av_read_frame() could
> just tell you "i dont have a frame yet, go and do something else usefull" aka
> EAGAIN (current ffmpeg.c doesnt support it but i think we shouldnt ignore it
> in the design ...)
>
> also its possible to have more than 1 video stream in a file and av_read_frame
> might return stuff for the "wrong" stream when asked for the next frame ...
>
>
> >
> > Solution 2 (threading and queuing):
> >
> > Make ffmpeg.c have a thread for audio decoding, another one for video
> > and another for filtering. The video thread will add frames to a video
> > queue and the filtering thread will sleep and wait for frames is the
> > video queue is empty.
> >
> > Problem: May introduce bugs, big patch, gives the impression that it is
> > impossible to use libavfilter in a single-threaded application. There
> > may also be corner cases where the queues gets too big and uses gigs of ram.
>
> id like to keep threads optional, not mandatory if possible for core
> functionality

Is solution 3 not an option or do you just have no opinion on that at
the moment?

Regards,
Rob