[FFmpeg-devel] [PATCH] Frame rate emulation

Michael Niedermayer michaelni
Wed Jun 20 13:12:20 CEST 2007


On Wed, Jun 20, 2007 at 09:20:21AM +0200, Luca Abeni wrote:
> >> But if I am wrong, let me know how v4l2.c should behave, and I'll try to 
> >> fix it.
> > 
> > there should be a way to prevent demuxers & protocols from blocking if
> > no data is aviailable ...
> I agree. As I wrote in a previous email, I think the "really correct" 
> solution from a conceptual point of view would be to provide some kind 
> of "select like functionality". So, ffmpeg (or a program using 
> libavformat) can sleep until one of the selected inputs can provide a 
> packet.

this doesnt sound like it would be easy to implement ...

> > an example where this might be fatal is a low fps webcam or rtp and a normal
> > tv capture at the same time, think of no rtp packets for a second or 2 and
> > v4l(2) having to buffer 50 frames or so
> I see the point (a better example would be capturing video with v4l and 
> audio with an OSS driver... Video frames risk to be dropped for this 
> reason :).
> If I understand the current ffmpeg.c code, ffmpeg is trying to 
> understand which input will be able to provide a packet first, and then 
> to read from such input (so, ffmpeg is prepared to "blocking input 
> formats"... If it is able to correctly guess which one unblocks first, 
> then there is no problem).

well what about x11 which can provide a frame at any time but this still is
not what is wanted

also some sort of priority should be given to audio if full rate capture
of all streams becomes impossibl, droping 1 video frames is hardly noticeable
loosing 1 audio frame is very noticeable

> If we switch AVFormats to a non-blocking behaviour, we will have to 
> properly update ffmpeg.c too (and we will probably have to increase some 
> version number).

we could add a flag which enables non blockng behavior

Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

No great genius has ever existed without some touch of madness. -- Aristotle
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20070620/a46c15c5/attachment.pgp>

More information about the ffmpeg-devel mailing list