[Elphel-support] Record full res and stream compressed at the same time?

Sun Jul 23 19:31:11 PDT 2017

David, 

gstreamer seems to have the lowest latency - https://blog.elphel.com/2017/07/current-video-stream-latency-and-a-way-to-reduce-it , it is probably easy to add pixel reordering after JPEG decoder. Adding it to chrome may be trickier. Javascript http://community.elphel.com/jp4viewer/ may be not fast enough.

Image size for the same quality is about the same, JP4 just preserves more "raw" data and does not introduce de-Bayer artifacts that are difficult to undo.

2 compressors use 2 different circbuf devices, sure - circbuf data is after the compressor, so different quality would result ion different data

Andrey

---- On Sun, 23 Jul 2017 19:07:12 -0700 David McPike<davidmcpike at gmail.com> wrote ---- 

I will need to setup my dev environment (Ubuntu) again.  I haven't built Elphel firmware for a long time.  If we setup two compressors, does that mean we would have two circbuf devices as well?

We will have different network characteristics this time around, so I don't have an exact answer on our bandwidth limits just yet.  The bigger concerns are ease of use and latency.  I am interested in adding functionality to the OpenROV project and using it for our piloting and telemetry platform on the surface.  The server and video feeds will be accessed via Chrome, making it very easy to use, and most users will be running Windows.  I would be a bit concerned about trying to use Gstreamer and get it running nicely inside an HTML5 app in a browser, or running Gstreamer separately outside of the telemetry and control applications.  I don't suppose you know of a Chrome extension that supports decoding JP4 images?  Can you tell me some average file sizes of JP4 compressed images compared to, say, 80% quality JPEGs?

We usually use an ACK'd layer 2 protocol like Homeplug AV, which already adds a bit of delay for every frame.  In the past, we have run our piloting camera at 1/4 resolution to minimize transmission latency.  I'm happy to keep more sensor information in a higher resolution frame with bigger compression to keep latency lower.

Thanks!
David

On Sun, Jul 23, 2017 at 8:47 PM Elphel Support <support-list at support.elphel.com> wrote:

David,

That will need modification of the drivers -  ( https://git.elphel.com/Elphel/linux-elphel ), because while in FPGA sensor and compressor channels can be paired in any combination, driver currently has them one-to-one.

Do you have Eclipse-based development environment installed and set up? All the header files responsible for communication with the FPGA are missing in the git repository - they are generated/updated from the Verilog source files.

And what i your bottleneck? What is the bandwidth of the cable? Maybe you can stream JP4 and decode it on the fly with gstreamer? 

Andrey

---- On Sun, 23 Jul 2017 17:44:50 -0700 David McPike <davidmcpike at gmail.com> wrote ---- 

Andrey, can you give me some advice or point me to documentation on how I would accomplish the following:

- Run two compressors
- The compressor used by camogm would write JP4 raw or 100% JPEG quality MJPEG images to disk
- Imgsrv would serve images at various JPEG qualities as we set them

Do I need to read circbuf frame metadata to figure this out?  What's the right way?  Running multiple sensors in each camera isn't achievable at this time.

Thanks!
David

On Sat, Jul 22, 2017 at 10:12 PM David McPike <davidmcpike at gmail.com> wrote:

Hi Andrey,

Our use case would be one sensor per camera, running around 10-12fps, recording video on local disk, and surface ROV pilot viewing streamed images.  I would like to maximize image quality stored on disk, while minimizing latency for images delivered to the surface on a limited bandwidth network path.  Using a single fps is totally fine.

I can't recall our typical resoluition.  I don't feel like we ran the camera at full resolution in the past, so I'll keep your input in mind and try to finalize our requirements.

Thanks much!

On Sat, Jul 22, 2017 at 9:53 PM Elphel Support <support-list at support.elphel.com> wrote:

David,

Do you mean resolution or JPEG quality?

Different JPEG quality can be achieved with the same FPGA code, but different software if you use less that all 4 channels - run 2 compressors from the same sensor channel.

Different resolution simultaneously can only be achieved if the sensor runs at full resolution, and FPGA reduces resolution. That mode is not implemented as it is limited to the same (lowest of 2) frame rate, defined by the sensor. So it is not possible to combine low fps/high resolution and high fps/low resolution from the same sensor, only what can be done is similarly to 353 - short interruptions of the stream to get full resolution images (simple application can record them to the ssd).

Probably the most practical solution (having 4 sensor channels on the same camera - dedicate one sensor for streaming, others - for high-res recording.

Andrey

---- On Sat, 22 Jul 2017 18:45:23 -0700 David McPike <davidmcpike at gmail.com> wrote ---- 

Hi All,

I can't seem to find a clear explanation on this.  We are still primarily using the 353 cameras.  Is there a way to locally record high quality images via camogm and at the same time retrieve JPEG images with higher compression via imgsrv?

Thanks much,
David

 _______________________________________________ 
Support-list mailing list 
Support-list at support.elphel.com 
http://support.elphel.com/mailman/listinfo/support-list_support.elphel.com 

 _______________________________________________ 
Support-list mailing list 
Support-list at support.elphel.com 
http://support.elphel.com/mailman/listinfo/support-list_support.elphel.com 

 _______________________________________________ 
Support-list mailing list 
Support-list at support.elphel.com 
http://support.elphel.com/mailman/listinfo/support-list_support.elphel.com 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://support.elphel.com/pipermail/support-list_support.elphel.com/attachments/20170723/094f367a/attachment.html>