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

[Farkas Levente]

anybody, any comment?

Farkas Levente wrote:
> 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!"