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

[Michael Niedermayer]

On Wed, Jan 02, 2008 at 12:49:24PM +0100, Vitor Sessak wrote:
> Hi all,
> 
> I've spotted a problem with the ffmpeg.c integration using the command
> 
> ffmpeg -vfilters fps=1 -i input.avi output.avi
> 
> In the way the integration is done in ffmpeg.c (my fault, I know), the 
> filter infrastructure expects one input frame for every output frame. 
> But that is not right for all filters. FFplay is also affected by this 
> problem (although it's harder to reproduce, I didn't found a test case), 
> it has a video queue and a filter will not work properly if the queue is 
> empty.
> 
> The root of the problem is that in the way libavfilter is designed, 
> libavfilter must ask ffmpeg.c/ffplay.c every time it wants a frame, no 
> matter how (if any) frame was outputted by the filter chain.
> 
> 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

[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Many that live deserve death. And some that die deserve life. Can you give
it to them? Then do not be too eager to deal out death in judgement. For
even the very wise cannot see all ends. -- Gandalf
-------------- 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/ad9f926c/attachment.pgp>