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

[Michael Niedermayer]

On Wed, Jan 02, 2008 at 02:27:43PM +0000, Robert Swain wrote:
> 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?

no opinion, as ive not investigated the effects of the proposed change
fully ...


[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Republics decline into democracies and democracies degenerate into
despotisms. -- Aristotle
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-soc/attachments/20080102/34489805/attachment.pgp>