[Elphel-support] Viewfinder / preview considerations

Tue Nov 9 06:50:40 PST 2010

Which sensors do you mean?

The Kodak 11 or 16 MP sensors that are used in Elphel 363 can only
deliver up to 5 fps.

The current Elphel 353 is at the maximum of its throughput
(~80Mpix/s), with next generation Elphel 373 Andrey had set his target
to achieve 300Mpix/s if I remember correctly.

Regards Sebastian

On Tue, Nov 9, 2010 at 15:44, François Demange
<francois.demange at ubicast.eu> wrote:
> Hi,
> I see there are other sensors with higher MP counts.
> Can we attain higher resolutions using these, while keeping the camera
> at 25 fps, or will we still be limited by the processing power ?
>
> 2010/11/9, Cinema Project | Sebastian Pichelhofer <cinema at elphel.com>:
>> On Mon, Nov 8, 2010 at 23:54, François Demange
>> <francois.demange at ubicast.eu> wrote:
>>> Hi all,
>>> I confirm we used a 40ms, 25 fps setting w/ JP4.
>>>
>>> I am rather new to the elphel and development worlds, and I hope you
>>>
>>> Basically, we are trying achieve the highest possible horizontal
>>> resolution for custom pan and scan within the frame, while keeping a
>>> decent frame rate.
>>> Since we're going to run some detection within the frame, the pan and
>>> scan cannot be done dynamically within the sensor, which would have
>>> yielded better results...
>>>
>>> In any case, i truly believe pushing the sensor's limits that way
>>> could be of interest to fiction guys looking for a cheap way to make
>>> special effects, like post production panning, judder correction and
>>> what not.
>>>
>>> On another subject, the dual stream LAN/SATA is an interesting
>>> feature, if one could dump both, the downsampled stream could be used
>>> for a quick edit and conform job within an NLE system.
>>> Such proxying features are done internally by some hard drives such as
>>> the firestore line from Focus Enhancements, which also enables live
>>> logging of clips through a web interface over wifi, and that gets
>>> really handy when on set !
>>>
>>> Exactly how much hardware/software hacking would be required for us to
>>> get the camera to dump to SATA ? Wouldn't that be be more expensive
>>> than just to buy a new sample ?
>>
>> http://www3.elphel.com/price_list
>> 10369         IO board: CF/IDE/SATA, RS232, GPIO, ...         $500
>>
>> Replacing the board inside the enclosure is easily possible on your
>> own if you are careful.
>>
>> No software hacking is required to do that, its a quite comon standard
>> feature.
>>
>> Regards Sebastian
>>
>>>
>>>
>>>
>>> 2010/11/8, Alexandre Poltorak <alexandre at elphel.com>:
>>>> Hi guys,
>>>>
>>>> This is an interesting discussion and it would be nice to CC this kind of
>>>> stuff to Elphel's ML...  many not cinema related customers may benefit
>>>> from
>>>> better JP4 support.
>>>>
>>>> First about NFS, camogm support QoS for IDE/SATA/CF over network stream,
>>>> but
>>>> of course it is not possible with NFS.
>>>>
>>>> Ubicast have a very old dev version of NC353L with 10349 board. It was my
>>>> dev camera for a while. To replace it by 10369 it also need a new camera
>>>> case and some hacking to fix everything since it was not the latest 10353
>>>> release. If we take the last camera case, probably we will also have to
>>>> change the metal parts of the sensor front-end. 1,8" ZIF HDD scotched to
>>>> the
>>>> camera case can do the job for testing with what you already have, but it
>>>> may require some manual hacking as the 10349 board is not released /
>>>> supported and so not auto-detected / configured.
>>>>
>>>> VLC, GStreamer and MPlayer all support live stream with as small as
>>>> possible
>>>> latency. Gstreamer's rtspsrc have latency parameter.
>>>> gst-launch rtspsrc location=rtsp://192.168.0.9:554 latency=20 ...
>>>>
>>>> Flowty: 40ms is 25 FPS ;) and it must be JP4 mode as Sebastian suggested.
>>>>
>>>> Best regards,
>>>> Alexandre
>>>>
>>>> On Mon, Nov 8, 2010 at 9:26 PM, Cinema Project | Sebastian Pichelhofer <
>>>> cinema at elphel.com> wrote:
>>>>
>>>>> On Mon, Nov 8, 2010 at 21:15, Florent Thiery <florent.thiery at ubicast.eu>
>>>>> wrote:
>>>>> > Hello,
>>>>> >
>>>>> >> So far I had no time to test video streaming from the camera though,
>>>>> >> also since it is based on an ARM CPU I need cross compiled software
>>>>> >> all the time which for me is a certain barrier.
>>>>> >
>>>>> > Well, openembedded/Angström works with the TouchBook out of the box so
>>>>> > i
>>>>> > guess this is possible with reasonably low effort.
>>>>>
>>>>> I will give it another try once I got my replacement battery pack :)
>>>>>
>>>>> >>
>>>>> >> In ElphelVision I recently switched from mplayer to VLC because you
>>>>> >> can get very low latency with VLC (almost realtime) that simply was
>>>>> >> not possible with mplayer or gstreamer before.
>>>>> >
>>>>> > Really ? Did you play with rtspsrc's latency property (e.g. to 30) ?
>>>>> > You
>>>>> can
>>>>> > get very very low latency on gstreamer, at least from our tests it's
>>>>> very,
>>>>> > very fast.
>>>>>
>>>>> TBH I can't remember what exactly I did try and what the improvements
>>>>> or troubles were but I know that I am very happy with VLC now ;)
>>>>>
>>>>> Latency depends on datarate but can be as low as 20ms which is already
>>>>> pretty much the lowest you can go considering monitor refresh rates.
>>>>>
>>>>> >
>>>>> >>
>>>>> >> Did you make sure that exposure time was short enough to allow 30
>>>>> >> fps?
>>>>> >
>>>>> > Are you referring to the variable on the Automatic Exposure Daemon max
>>>>> > exposure (which in JP46 i cannot change) or to the first parameter in
>>>>> > the
>>>>> > home control interface (along with RGB etc...) ? We set it to 40,
>>>>> > maybe
>>>>> not
>>>>> > 33 i'll double check.
>>>>>
>>>>> I would just turn off autoexposure and set it manually, unless you
>>>>> need auto brightness for your application....
>>>>>
>>>>>
>>>>>
>>>>> >
>>>>> >>
>>>>> >> In camvc the correct option is "jp4" (option 5)
>>>>> >> JP46 (option 3) does not have the performance gain.
>>>>> >
>>>>> > Thanks
>>>>> >>
>>>>> >> If you have the 10369 board you should have both SATA and USB, USB is
>>>>> >> 1.1 correct so connecting an USB-HDD is really not an option I am
>>>>> >> afraid.
>>>>> >
>>>>> > I have an ooold 353 donated by Elphel (thanks elphel!) with a serial
>>>>> > port
>>>>> > and usb, i guess this is an older board revision...
>>>>>
>>>>> I see, well then you are already using all possible options, unless
>>>>> you want to purchase a newer 10369 replacement board (~500$)
>>>>>
>>>>> >>
>>>>> >> NFS should work fine, though you need to set that up manually over
>>>>> >> the
>>>>> >> commandline.
>>>>> >
>>>>> > I'm just afraid of the conflict between live stream grabbing and nfs
>>>>>
>>>>> well yes bandwidth will definitely become an issue here. so dumping
>>>>> the stream with the software that displays it (gstreamer, etc.) might
>>>>> be the better option.
>>>>>
>>>>> > writes...
>>>>> > Cheers
>>>>> > Florent
>>>>>
>>>>
>>>
>>> --
>>> Envoyé avec mon mobile
>>>
>>
>
> --
> Envoyé avec mon mobile
>