V4L2 also provides for non-blocking streaming captures and reads by supporting
select(), which will indicate the file descriptor has stuff to read either if a
streaming buffer is available to be dequeued, or (if streaming is off), if a
frame is available to be read with read(). This is something I really miss in
V4L.

I'm not sure if read() is working in bttv (it's not in the version I have - I
use mmap()), but I believe it is in bttv2.

Ben

Justin Schoeman wrote:

> Ragga Muffin wrote:
> >
> > Hello all,
> >
> > Could someone briefly explain (or point to up-to-date info) what is
> > the status of the v4l and v4l2 apis, as well as the
> > bttv/bttv2 driver ?
> >
> > Background:
> > Last year I wrote a small and simple video capture to disk program
> > using the v4l api. (bt848 board, NTSC)
> > Now however, the app needs to be rewritten for *much* better
> > performance (frame rate etc..) and configurability (capture depth and size
> > etc..).
> >
> > Can someone recommend me a way to go api and driverwise ?
> >
> > Many TIA for any insights,
> >
> >      Ragga
>
> 1) bttv has been around a lot longer, and is pretty heavily tested - it
> is likely to have less problems than bttv2.
> 2) bttv2 has completely rewritten capture core that gets rid of a lot of
> historical cruft that bttv has/had (NOTE:  I have not had an in depth
> look at bttv for a long time.  When I first started bttv2, bttv had a
> number of very bad races and lockups).
> 3) From a capture point of view, the v4l2 API has the following
> advantages over v4l (in my opinion):
>   - Multi-buffering:  You can choose how many capture buffers you want
> (for short captures you can do a ramdisk type thing, where you allocate
> enough buffers for your capture, capture to these buffers and write to
> disk later).  In normal use, this also allows you to absorb a lot of I/O
> latency.
>   - Timestamped capture.  Each buffer is timestamped and sequence
> numbered, as it is captured.  This allows you to detect drops, and also
> synchronise audio capture.
> 4) In terms of configurability, v4l and v4l2 are basically the same,
> except that v4l2 allows you to do field capture as well.
>
> I'm not sure if there are any disadvantages (except for the fact that
> bttv2 is relatively untested).
>
> Also, take note that I/O bandwidth can often be the determining factor
> for frame rate.  v4l2 does allow you to use a lot of buffers, so you can
> get closer to the average throughput of your I/O device, but it cannot
> (obviously) increase your I/O bandwidth.
>
> -justin
>
> _______________________________________________
> Video4linux-list mailing list
> [EMAIL PROTECTED]
> https://listman.redhat.com/mailman/listinfo/video4linux-list



_______________________________________________
Video4linux-list mailing list
[EMAIL PROTECTED]
https://listman.redhat.com/mailman/listinfo/video4linux-list

Reply via email to