[libcamera-devel] [PATCH] py: cam: Network renderer

Tomi Valkeinen tomi.valkeinen at ideasonboard.com
Sun Mar 19 16:49:46 CET 2023


Hi Laurent,

On 19/03/2023 15:05, Laurent Pinchart wrote:
> Hi Tomi,
> 
> Thank you for the patch.
> 
> On Sun, Mar 19, 2023 at 01:30:13PM +0200, Tomi Valkeinen via libcamera-devel wrote:
>> Here's something I have found useful a few times.
>>
>> This adds a "tx" renderer to cam.py, which sends the frames over the
>> network to a receiver.
>>
>> It also adds a "cam-rx" tool (non-libcamera based) which receives the
>> frames and uses PyQt to show them on the screen, usually ran on a PC.
>>
>> This is obviously not super efficient, but on the PC side it doesn't
>> matter. On the TX side, at least RPi4 seemed to work without noticeable
>> lag, but my old 32-bit TI DRA76, when sending three camera streams, the
>> performance dropped to ~5fps. Still, I find that more than enough for
>> most development work.
>>
>> This could be extended to also transmit the metadata.
> 
> What's the advantage of this approach compared to using GStreamer for
> network streaming ? It feels to me that we're reinventing the wheel a
> bit here.

Well, these may not matter to other people, but for me:

- This doesn't need gstreamer
- This works, whereas I have a lot of trouble getting gstreamer working. 
I did manage the get a few formats rendering locally, but I couldn't get 
anything over a tcp sink.
- The code is short and trivial, and I have the same TX code working on 
my v4l2 python test app.
- With this, I have a trivial way to get the raw frames and metadata (to 
be implemented =) on my PC and process and study them with python & numpy.
- This could be used for the "py: cam.py: Provide live graph of request 
metadata"

I should have emphasized that this is a development/testing helper, not 
"streaming support".

Also, doesn't your point apply to any rendering done by cam?

  Tomi



More information about the libcamera-devel mailing list