[Elphel-support] Viewfinder / preview considerations

[François Demange]

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