List: linux-video
Subject: LinuxBroadway: multi-card management question...
From: "D. Huseby" < huseby () u ! washington ! edu>
Date: 1999-02-22 4:37:43
Hey v4ler's
I've got a question to ask of all of you. I'm fast at work adding
new code to the LinuxBroadway driver and I've decided that it's high time
that I added the multi-card ability to the driver. There is one problem
that I'm not sure about how to solve. Here's a breakdown of what's going
on. The broadway MPEG card has the ability to capture I frames
(uncompressed) to memory, capture IBP (MPEG1 compressed video) to memory,
output video from I frames in memory, output video from IBP frames in
memory, decompress IBP frames from memory into I frames in memory, and
compress I frames from memory into IBP frames in memory. What I want to
do is give an app like a non-linear video editing app the ability to
capture, output, and compress/decompress data in parallel if the user has
more than one board. Of course there are DMA/bus limitations that may
make this possible with only two maybe three operations at a time. I
envision a user with two cards using one to capture from video and the
other to transmit the edited video out to tape/TV. It doesn't have to
happed at the same time in real time, just so that there is a separate
input channel and output channel. Got it? My problem is that there are
many control calls (ioctl) that must be made to a board to use its full
capability (i.e. turn overlay on/off, init IBP cap, init I cap, init out
video IBP, etc...) In a situation where there are more than one board the
driver has to have the ability to distinguish which board the app wants
the ioctl to control. Here's my idea:
when the app makes an open call it checks for free boards and grabs the
next one if there are any else return -BW_NO_FREE_CARDS
then initilize a "public" board status struct and put the board index in
it plus the mode (IBPcap, Icap, IBPout, Iout, IBPtoI, etc...) as well as
the board state (idle, busy, error, etc) and an optional error string
and/or frame count.
then copy_to_user(*file->private_data, &board_status) and use the
*private_data pointer in the file struct as the communication channel.
the app would have to declare a volitile board_status struct pointed to by
the *private_data pointer.
This way, whenever an ioctl call was made the driver just checks the board
index field in the board_status struct to figure out which board the app
wants.
My Problem: Is this the best way to go about this? Is this too much
policy or is there a better way? Suggestions? I figure that this is what
the *private_data pointer is for but I thought I would ask since many
heads are better than one, plus this is my first "major" driver.
Dave
P.S. --READ THE FOLLOWING ONLY IF YOU WANNA HEAR SOME COOL USES FOR THE
ABOVE THAT I'M COOKING UP--
Ok, most of these ideas require some fast hardware (100MHz bus and PII 350
or better with LOTS of ram but these are cool ideas.
-(2 BW cards) realtime capture I-frames from card 1 apply fairly
simplistic, not too CPU intensive filters (text overlay, color twisting,
video texturing 3D objects), and either output video through card 2 or use
it to compress the filtered frames into an MPEG stream and netcast it all
in real time. The in/out lag could theorectically be minutes or hours as
long as the CPU can produce frames fast enough that massive buffering
isn't needed.
-(3 BW cards) realtime capture I-frames from all three cards and do cool
stuff with the video before saving to disk. A few ideas would be use a
rotating 3D cube animation and map each of the 3 video streams onto each
of the 3 showing faces as it rotates (I really don't think this is
possible but hell, I've got the hardware why not try?) You could also use
dynamic transparency maps to cut out unwanted portions of each stream and
do a layering affect in real time like talking heads in space or your
girlfriends head on the body of your favorite porn star's body :-) Can
you say "Wag the Dog"? The last idea you could use two input streams and
the third for the output stream.
Hey, let your imagination go and see what you can come up with. Send me
email if you come with anything good, and I mean useful when I say good.
As soon as the driver goes alpha I'm going to launch the first non-linear
video editing package project for Linux as well as start in on the V-Tech
MPEG2 card driver (I think that is the maker's name). My boss is going to
buy a few from the video chip manufacturer along with the Windows and
Solaris SDK's for me to play with. He wants me to use what I learned with
Broadway to produce a Linux driver for it. The MPEG2 cards do real time
MPEG2 capture at full D1 (broadcast quality) resolution and only for
about $800 a card! Anyway, that's my core dump for tonight.
Dave
P.S.S. oh yeah, in response to some emails about me taking too long, I
just want to say I won't release an alpha until I can capture both I frame
and IBP frame. Sorry, but I don't have the time to just put out the bare
essentials and get into the add/test cycle. I'm doing that on my own on
several different machines and when I think it's a stable on my systems
then I'll release it. Let's just say I'm really close to that time, so be
patient.
--
To unsubscribe: mail video4linux-list-request@redhat.com with
"unsubscribe" as the Subject.
List: linux-video
Subject: Re: LinuxBroadway: multi-card management question...
From: Bill Dirks < dirks () rendition ! com>
Date: 1999-02-22 19:30:22
If you follow the Video for Linux Two API
(http://millennium.diads.com/bdirks/v4l2.htm), then you assign a
different minor number for each function of each board. The board can be
a capture device, a codec device (memory-to-memory conversions), or an
output device, so for each physical board you would export three
'devices': capture, codec & output. The application will open the
appropriate 'device' for what it wants to do.
If you have three boards, then you have three capture devices, three
codecs and three output devices. If, say, one of the boards is opened as
a capture device, then the codec and output devices associated to that
physical board will be unavailable (busy).
The way it's done is in your driver you have a struct v4l2_device for
each device, and you register them with v4l2_register_device(). The
system admin person creates /dev nodes for each, and when an application
opens one of the devices, your driver is called with a pointer to the
right struct v4l2_device for that device.
Since you are exporting multiple device functions for each physical
device, you will probably want a single data structure for each physical
board for board-global data, and the struct v4l2_device objects will
have a pointer to the board-global data. You'll need an array of
board-global structures so you have a separate one for each physical
board in the system.
Bill.
"D. Huseby" wrote:
>
> Hey v4ler's
> on. The broadway MPEG card has the ability to capture I frames
> (uncompressed) to memory, capture IBP (MPEG1 compressed video) to memory,
> output video from I frames in memory, output video from IBP frames in
> memory, decompress IBP frames from memory into I frames in memory, and
> compress I frames from memory into IBP frames in memory. What I want to
> do is give an app like a non-linear video editing app the ability to
> capture, output, and compress/decompress data in parallel if the user has
> more than one board. Of course there are DMA/bus limitations that may
--
To unsubscribe: mail video4linux-list-request@redhat.com with
"unsubscribe" as the Subject.
List: linux-video
Subject: Re: LinuxBroadway: multi-card management question...
From: "D. Huseby" < huseby () u ! washington ! edu>
Date: 1999-02-22 21:45:57
On Mon, 22 Feb 1999, Bill Dirks wrote:
> If you follow the Video for Linux Two API
Which one should I be using? the videodev in kernel 2.2.x uses v4l and I
thought v4l2 was still in a state of flux. I don't want to release two
versions of the driver because of policy issues (one for v4l and one for
v4l2). The driver is at a stage right now that can go either way, and it
has to go one way or another but not both. Maybe I could post what I have
and let somebody else do a v4l implementation and I'll work on the v4l2
driver which I'm assuming will be the long term solution rather than the
quick fix (v4l).
Dave
--
To unsubscribe: mail video4linux-list-request@redhat.com with
"unsubscribe" as the Subject.