[Fwd: [gst-devel] RFC: multi channel frame grabber card support]

[Fwd: [gst-devel] RFC: multi channel frame grabber card support]

[Farkas Levente]

hi,
a few weeks ago i send this mail to gstreamer-devel but it seems nobody 
reply to it. i'd like to know the v4l people's opinion's about it. or 
may be we've to modify the v4l or v4l2 interface in the bellow case to 
give us more device?
i'd like to know your opinion.
thanks in advance.
yours.

-------- Original Message --------
Subject: [gst-devel] RFC: multi channel frame grabber card support
Date: Fri, 11 Apr 2008 14:51:23 +0200
From: Farkas Levente <lfarkas@bppiac.hu>
To: Gstreamer <gstreamer-devel@lists.sourceforge.net>

hi,
as i wrote earlier we'd like to add support for multi channel frame
grabber cards in gstreamer. what's the problem:
currently there are the only hardware video input supported by gstreamer
is the v4l or v4l2 compatible video sources. there are good for common
hardware like ip camera, tv card (with tunner) or other hardware like
s-video input etc. but there are many kind of card which has more
(4,8,16,24) input channel (usually analog input). there card can give
raw or encoded video sources. but these usually has one physical devices
ie. one /dev/videoX devices (in this case we've got n composite input).
we'd like to build in this case n pipeline for the n input channel. one
of the simple example IVC-100 card which has one bt878 chip and 4
composite input and one 4 channel multiplexer.
http://www.iei.com.tw/en/product_IPC.asp?model=IVC-100G
in this case we can use v4l and choose one of the channel but we'd like
to build 4 pipeline and set different parameters on the different
pipeline's source properties (like frame rate, resolution etc). what's
more we'd like to modify the source element properties during it's
running eg. i'd like to modify the 2nd channel frame rate while wouldn't
like to stop the other 4 pipeline!!! and it's an important feature.
what we can do?
- we can create a new source element with 4 output pads,
- or create a new source element with one output pad, but we'd like to
create 4 such source element which can parallel use the same device's
different input channel.
the first would be the easier, but in this case we can't modify one of
the input channel's parameter without stop the other pipelines:-( or can
i do it somehow? and in this case all of the pipeline has to be run in
the same process.
in the second case we can start and stop the pipeline independently
what's more use them in different process, but we probably have to
create some kind of master/controller process which control the access
of the source elements to the device.
what do you think about it?
what do you suggest about it?
what's your comments?
thanks in advance.
yours.

-- 
    Levente                               "Si vis pacem para bellum!"

-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
Don't miss this year's exciting event. There's still time to save $100.
Use priority code J8TL2D2.
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
_______________________________________________
gstreamer-devel mailing list
gstreamer-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/gstreamer-devel

-- 
   Levente                               "Si vis pacem para bellum!"

--
video4linux-list mailing list
Unsubscribe mailto:video4linux-list-request@redhat.com?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/video4linux-list

Re: [Fwd: [gst-devel] RFC: multi channel frame grabber card support]

[Daniel Glöckner]

On Wed, Apr 30, 2008 at 01:48:41PM +0200, Farkas Levente wrote:
> we'd like to build in this case n pipeline for the n input channel. one
> of the simple example IVC-100 card which has one bt878 chip and 4
> composite input and one 4 channel multiplexer.

Are you familiar with the capabilities of the bt878?
If not, here is the datasheet:
http://conexant.com/servlets/DownloadServlet/DSH-200115-001.pdf?docid=116&revid=1

You can only capture from one channel at a time.
So you will get only 6.25 full size PAL frames per second on each
channel if you use all four channels AND THE CHANNELS ARE SYNCHRONIZED.
This synchronization can only be done with some cameras.
If you can't synchronize your framerate will drop even more.
I don't know if there are additional resynchronization delays if the
bt878 doesn't detect vertical sync when it is expected.

The card's driver would have to change all parameters on IRQ.
Can we guarantee that the interrupt is handled in Linux before the next
frame starts?
The "white crush" adaptive algorithm of the chip will result in bad
pictures if the inputs have completely different white levels. It should
be disabled.

If this is to be done, I propose that struct v4l2_buffer should be
extended to point to the parameters that should be used for the picture.

How these parameters should be stored is another question..

  Daniel

--
video4linux-list mailing list
Unsubscribe mailto:video4linux-list-request@redhat.com?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/video4linux-list

Re: [Fwd: [gst-devel] RFC: multi channel frame grabber card support]

[Farkas Levente]

Daniel Glöckner wrote:
> On Wed, Apr 30, 2008 at 01:48:41PM +0200, Farkas Levente wrote:
>> we'd like to build in this case n pipeline for the n input channel. one
>> of the simple example IVC-100 card which has one bt878 chip and 4
>> composite input and one 4 channel multiplexer.
> 
> Are you familiar with the capabilities of the bt878?
> If not, here is the datasheet:
> http://conexant.com/servlets/DownloadServlet/DSH-200115-001.pdf?docid=116&revid=1

yes.

> You can only capture from one channel at a time.
> So you will get only 6.25 full size PAL frames per second on each
> channel if you use all four channels AND THE CHANNELS ARE SYNCHRONIZED.
> This synchronization can only be done with some cameras.
> If you can't synchronize your framerate will drop even more.
> I don't know if there are additional resynchronization delays if the
> bt878 doesn't detect vertical sync when it is expected.
> 
> The card's driver would have to change all parameters on IRQ.
> Can we guarantee that the interrupt is handled in Linux before the next
> frame starts?
> The "white crush" adaptive algorithm of the chip will result in bad
> pictures if the inputs have completely different white levels. It should
> be disabled.
> 
> If this is to be done, I propose that struct v4l2_buffer should be
> extended to point to the parameters that should be used for the picture.
> 
> How these parameters should be stored is another question..

the bt878 was just one example. but this is one of the basic (and 
cheapest) card. of course there are other card which has more "power" 
but the problem remain the same in all case.
- should we have to create such a kernel driver for _one_ card which has 
_more_ logical/user space device or as the current case _one_ user space 
device?
- if we've _one_ user space device with multiple (4, 8, 16, 24) input 
channel then we should have to create one gstreamer source element with 
multiple pads or one element with one pad, but we can create more such 
elements and they are somehow use the same hardware device?

-- 
   Levente                               "Si vis pacem para bellum!"

--
video4linux-list mailing list
Unsubscribe mailto:video4linux-list-request@redhat.com?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/video4linux-list