[Elphel-support] Viewfinder / preview considerations

Tue Nov 9 06:56:05 PST 2010

Thank you for your reply.
Do we have an ETA on the 373 ? :)

2010/11/9, Cinema Project | Sebastian Pichelhofer <cinema at elphel.com>:
> 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
>>
>

-- 
Envoyé avec mon mobile