[FFmpeg-devel] [PATCH] Frame rate emulation
Wed Jul 4 22:26:21 CEST 2007
On Thu, Jun 28, 2007 at 11:40:47AM +0200, Luca Abeni wrote:
> Luca Abeni wrote:
> >>>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
> >Yes, I like this idea. I'll work on it as soon as I find some time, and
> >I submit a patch introducing the new avformat flag, and updating v4l2.c
> Here is a first try... I've not been able to test the patch, but I think
> it should not break anything ;-)
> The patch introduces a new AVFMT_FLAG_NONBLOCK flag, and updates v4l2.c
> to support it (I did not split it in two patches, because the first one
> would be really trivial... If needed, I'll split the patch for committing).
> I think the other "blocking input formats" can be updated in a second time.
> I assume that VIDIOC_DQBUF can return EAGAIN only if the device is
> opened in non-blocking mode, so AVFMT_FLAG_NONBLOCK is not tested before
> returning AVERROR(EAGAIN). If this assumption is wrong (but from the
> v4l2 documentation I think it is not), I have a second version of the
> patch which always tests AVFMT_FLAG_NONBLOCK...
> Finally, I am returning AVERROR(EAGAIN), but... Is this the correct
> thing to do? Looking at audio.c, it seems that when the driver would
> block the packet size is set to 0 and 0 is returned... To be safe, I
> also set pkt->size to 0, but I do not know if this is really needed. Let
> me know, and I'll fix the patch in the proper way.
iam ok with the patch
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
Complexity theory is the science of finding the exact solution to an
approximation. Benchmarking OTOH is finding an approximation of the exact
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: not available
More information about the ffmpeg-devel