Abstract
This is a client-side improvement for the issue of OMC_TRANS camera klog#36311.
Although it's not impossible, I understood that drastic structural changes are required for server-side improvements about this issue.
In other words, it will likely be a very long-term task.
So I made a client-side improvement as a quick-aid.
How to use
Now /kagra/camera_client.py can take a snapshot with -p/--photo option as
controls@k1grd0:~$ /kagra/camera_client.py -c OMC_TRANS -p
or as a python module like as
controls@k1grd0:~$ python3
>>> import sys
>>> sys.path.append('/kagra/apps/camera/bin')
>>> import camera_client as cc
>>> cc.camera_client('OMC_TRANS', Photo=True)
pipeline_str = udpsrc multicast-group=239.192.0.47 port=65000 ! application/x-rtp,payload=96,clock-rate=90000 ! rtpjitterbuffer latency=200 ! rtph264depay ! avdec_h264 ! videoconvert ! video/x-raw,format=RGB ! appsink name=sink emit-signals=true max-buffers=1 drop=true
Waiting for first keyframe...
Saved /kagra/camera/images/OMC_TRANS_2026-02-16-22-49-39.tiff
>>>
without a limitation of the interval.
Details
One major?/minor? change is to remove overlay text as shown in Fig.1. Camera name is show in normal as a left image, but it's not for OMC_TRANS now as shown in a right image. Overlay text is merged to original camera image on the camera-server application. So what we can do as a client-side improvement is only to remove overlay text completely by using the server settings ('overlay_scilence = true'). I'm not sure an importance of the overlay text for commissioners, so I'd like to know it's okey or not. If the mode analysis code isn't affected by the overlay text, it may be restorable. If it's affected and the overlay text is necessary, we may need to give up the client-side improvement.
If it's acceptable, I'll update OMC_LSC guardian again to use this function. At this time, I plan to update drastically also another functions such as get_latest_file() which is used without any check about return value in spite of returning an indeterminate type (str or None) etc.
This function is probably required only by OMC_LSC guardian, so "take snap" on MEDM screens are still a server-side shooting with an interval limitation. An advantage of shooting on the server-side is that it can be executed simply via EPICS. On the other hand, an advantage on the client-side is that it's easy to separate directory structure. The server application provides figure files in /kagra/camera/images/%Y/%m/%d/figure_files. So the CPU cost of finding image files and removing used files by OMC_LSC guardian will be increased in time. camera_client.py can provide image files also in /kagra/camera/images/, so finding and removing image files can be always done with minimum cost.
Memo
In the case of x-rtp protocol via udpsrc, pre-defined sink element which can be used in one-liner command cannot catch the first packet of each frame. Because of this gst-launch and/or ffmpeg commands cannot convert streaming video to the image file stably (rarely success, mostly fail). For this reason, the sink element which has a function to start caputuring with the first packet of frames as a trigger was prepared as a python function. And also, rtph264depay as a streaming receiver was not stable, so the rtpjitterbuffer element was inserted. Though it seems work fine now, it may be better to adjust buffer latency size more precisely (depending on bitrate, network situation, etc.?).
.png)
.png){kind=link}
