List: linux-video
Subject: Grabbing frame off of capturing video
From: "Richard Eppes" <rich_43 () hotmail ! com>
Date: 2000-06-14 15:00:14
Does anyone know where I could start looking for a way to grab a single
video frame while the capture card is already in use by another program
(which, unfortunately, I don't have the source code to)? The only way I've
found to do this is to actually re-write the capture driver to allow a
single frame to be pulled out, but I've had trouble getting this to work
without a good solid core dump. I have experimented with V4L2, but can't
get it to grab a frame while capturing either. Has anyone experimented with
this or know any good places to start looking?
Thanks!
Richard.
rich_43@hotmail.com
________________________________________________________________________
Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com
--
To unsubscribe: mail video4linux-list-request@redhat.com with
"unsubscribe" as the Subject.
List: linux-video
Subject: Re: Grabbing frame off of capturing video
From: kraxel () goldbach ! in-berlin ! de (Gerd Knorr)
Date: 2000-06-14 22:19:59
Richard Eppes wrote:
> Does anyone know where I could start looking for a way to grab a single
> video frame while the capture card is already in use by another program
> (which, unfortunately, I don't have the source code to)?
No. videodev.o allows only one process to open the device. Any chance
that this can be changed? Alan? I'm thinking about allowing multiple
opens on bttv, but this needs quite a few changes in videodev.o. Most
serious problem is that I need some way to keep per filedescriptor data
to get this right.
Even if this limitation is removed there is still no sane way to allow
multiple processes to use capture in parallel. Use video overlay and
capture in parallel would work throuth...
Gerd
--
To unsubscribe: mail video4linux-list-request@redhat.com with
"unsubscribe" as the Subject.
List: linux-video
Subject: Re: Grabbing frame off of capturing video
From: Alan Cox <alan () redhat ! com>
Date: 2000-06-14 23:35:37
> No. videodev.o allows only one process to open the device. Any chance
> that this can be changed? Alan? I'm thinking about allowing multiple
> opens on bttv, but this needs quite a few changes in videodev.o. Most
> serious problem is that I need some way to keep per filedescriptor data
> to get this right.
Change it but keep a flag so the videode enforces it for legacy drivers for 2.4
> Even if this limitation is removed there is still no sane way to allow
> multiple processes to use capture in parallel. Use video overlay and
> capture in parallel would work throuth...
Most boards cant capture and overlay together
--
To unsubscribe: mail video4linux-list-request@redhat.com with
"unsubscribe" as the Subject.
List: linux-video
Subject: Re: Grabbing frame off of capturing video
From: kraxel () goldbach ! in-berlin ! de (Gerd Knorr)
Date: 2000-06-16 21:41:44
Alan Cox wrote:
> > No. videodev.o allows only one process to open the device. Any chance
> > [ ... ]
> Change it but keep a flag so the videode enforces it for legacy drivers for 2.4
My plan is to simply pass down the struct file* instead of struct
video_device* (except for open). The driver can simply hook per
filedescriptor data into file->private_data then (or just the driver data
if it doesn't want allow multiple opens and therefore doesn't need per-fd
data). This requires changes of the driver callbacks, i.e. we need a second
set of hooks (called open2/close2/... for example), depending on the flag
the old/new ones are called by videodev.c.
Right now there is...
| int (*open)(struct video_device *, int mode);
Needs a additional struct file*.
| void (*close)(struct video_device *);
| int (*ioctl)(struct video_device *, unsigned int , void *);
| int (*mmap)(struct video_device *, const char *, unsigned long);
Replace struct video_device* with struct file*.
| long (*read)(struct video_device *, char *, unsigned long, int noblock);
| long (*write)(struct video_device *, const char *, unsigned long, int noblock);
Replace struct video_device* with struct file*, remove noblock (the driver
can check file->flags). Maybe check out kiobuf (havn't looked at it yet),
let videodev.c allocate kiobufs and pass them down to the driver.
| unsigned int (*poll)(struct video_device *, struct file *, poll_table *);
This could stay as-is, althrouth the struct video_device isn't required
any more...
Another minor problem is that allowing multiple opens implies some minor
API changes. Right now a application can do anything once it has opened
(i.e. allocated) the device. With multiple opens allowed only a few ioctls
(basically VIDIOG*) work all the time, other ones might return -EBUSY if
another application uses the driver in parallel. Should I care? Maybe
allow apps to open the driver with O_EXCL like the floppy driver does?
Gerd
--
Protecting the children is a good way to get a lot of adults who cant
stand up for themselves. -- seen in some sig on /.
--
To unsubscribe: mail video4linux-list-request@redhat.com with
"unsubscribe" as the Subject.
List: linux-video
Subject: Re: Grabbing frame off of capturing video
From: Bill Dirks <bdirks () micron ! com>
Date: 2000-06-16 23:54:51
V4L2 has multiple opens per device, and it doesn't require passing
file*s to drivers. That lets drivers remain decoupled from struct file
(which they shouldn't care about anyway), and it lets file->private_data
remain available for use by videodev.o. It's good design, and gives you
more control over the v4l system.
If you want to keep both so existing drivers still work, then you just
need to add new versions of video_register_device() and struct
video_device (and appropriate code to all the video_xxxx() functions in
videodev.c supporting both interfaces).
Bill.
Gerd Knorr wrote:
>
> Alan Cox wrote:
> > > No. videodev.o allows only one process to open the device. Any chance
> > > [ ... ]
> > Change it but keep a flag so the videode enforces it for legacy drivers for 2.4
>
> My plan is to simply pass down the struct file* instead of struct
> video_device* (except for open). The driver can simply hook per
> filedescriptor data into file->private_data then (or just the driver data
> if it doesn't want allow multiple opens and therefore doesn't need per-fd
> data). This requires changes of the driver callbacks, i.e. we need a second
> set of hooks (called open2/close2/... for example), depending on the flag
> the old/new ones are called by videodev.c.
>
> Right now there is...
>
> | int (*open)(struct video_device *, int mode);
>
> Needs a additional struct file*.
>
> | void (*close)(struct video_device *);
> | int (*ioctl)(struct video_device *, unsigned int , void *);
> | int (*mmap)(struct video_device *, const char *, unsigned long);
>
> Replace struct video_device* with struct file*.
>
> | long (*read)(struct video_device *, char *, unsigned long, int noblock);
> | long (*write)(struct video_device *, const char *, unsigned long, int noblock);
>
> Replace struct video_device* with struct file*, remove noblock (the driver
> can check file->flags). Maybe check out kiobuf (havn't looked at it yet),
> let videodev.c allocate kiobufs and pass them down to the driver.
>
> | unsigned int (*poll)(struct video_device *, struct file *, poll_table *);
>
> This could stay as-is, althrouth the struct video_device isn't required
> any more...
>
> Another minor problem is that allowing multiple opens implies some minor
> API changes. Right now a application can do anything once it has opened
> (i.e. allocated) the device. With multiple opens allowed only a few ioctls
> (basically VIDIOG*) work all the time, other ones might return -EBUSY if
> another application uses the driver in parallel. Should I care? Maybe
> allow apps to open the driver with O_EXCL like the floppy driver does?
>
> Gerd
>
> --
> Protecting the children is a good way to get a lot of adults who cant
> stand up for themselves. -- seen in some sig on /.
>
> --
> To unsubscribe: mail video4linux-list-request@redhat.com with
> "unsubscribe" as the Subject.
--
To unsubscribe: mail video4linux-list-request@redhat.com with
"unsubscribe" as the Subject.
List: linux-video
Subject: Re: Grabbing frame off of capturing video
From: kraxel () goldbach ! in-berlin ! de (Gerd Knorr)
Date: 2000-06-17 11:20:54
Bill Dirks wrote:
> V4L2 has multiple opens per device, and it doesn't require passing
> file*s to drivers.
I've checked how v4l2 does it.
> That lets drivers remain decoupled from struct file
> (which they shouldn't care about anyway), and it lets file->private_data
> remain available for use by videodev.o.
Ah, that's why. I've wondered why it is done this way because right now
videodev2 does not use file->private_data itself but simply passes it down.
But this way it can be changed later without breaking the drivers. Ok,
I can see the point.
Gerd
--
To unsubscribe: mail video4linux-list-request@redhat.com with
"unsubscribe" as the Subject.