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

[David McPike]

Thanks, Andrey.  Can you direct me to documentation or provide some
additional pointers regarding the adjustments necessary to achieve multiple
compression parameters on a single sensor?  I'd like to get a better idea
in mind before deciding which route we'll go.

Best,
David


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

> 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 <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 <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 <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/20170726/ae13d095/attachment.html>