Closed gtxaspec closed 2 years ago
@gtxaspec , Thanks for the info. I will consider it.
FYI, There was a bug in audio_callback.c. Due to the time difference between sending and receiving audio packets, the PCM buffer may become full in rare cases. At this time, the load on iCamera_app increases by looping retries in tinyalsa until the buffer is empty. However, once this happens, the next packet will soon arrive and the load will remain increased. For this reason, I have added a process to discard packets when the buffer is running low on available space.
https://github.com/mnakada/atomcam_tools/commit/3d96364cd0ef06f716de8ede75672e80a573c5fd
ah, thank you for the information! I will study and apply your fix.
@gtxaspec , I connected ch1 of video_capture to v4l2rtspserver.
When I get the JPEG from ch1, it is 640x360pix, so I think it is the same as Waze, but I can't play it in VLC.
It seems that the SPS/PPS of h264 is not coming, so the various elements of video are unknown, and it is not able to play.
Maybe there is something different in the iCamera_app settings.
i see. @mnakada, if you try libcallback from here, https://github.com/gtxaspec/wz_mini_hacks/blob/master/src/libcallback_wz_mod/libcallback.so is there any change?
turn on both channels with cmd video on
and cmd video on1
just to try.
@gtxaspec , Unfortunately, it's the same phenomenon. When I access /dev/video2 with v4l2rtspserver and access it with VLC, I keep getting the following message.
warning h264: waiting for SPS/PPS
warning h264: waiting for SPS/PPS
warning h264: waiting for SPS/PPS
warning h264: waiting for SPS/PPS
warning h264: waiting for SPS/PPS
I see that WAZE is 640x320px. Atomcam was 640x360px.
very strange...actually, the resolution, that is a mistake on my part, they are both the same resolution ...thank you for mentioning it.
CHANNEL 1 640x 360 START H264
@mnakada If i understand correctly, you have this error even with single channel CH1? or only when simultaneous
Yes, it is also occurring in single channel CH1.
Apparently, CH1 is missing NAL(sps,pps). I will check inside the H.264 packet some more.
@gtxaspec, I analyzed the NAL of the CH1 video stream packet. This stream was H265(HEVC) 640x360px 20fps.
The atomcam linux kernel does not support HEVC, so I am considering a patch to fix this.
@mnakada very interesting! I have read the SDK and it mentions H265, but this is the first time I have seen these camera's using H265.
@gtxaspec , Ver. 1.4.0 supports AVC1080P and HEVC360P simultaneous output.
@mnakada,
i have implemented a feature i call "night drop" which prevents the camera from dropping the frame rate to 15 fps at night, I prefer the smooth video at night
https://github.com/gtxaspec/wz_mini_hacks/blob/master/src/libcallback_wz_mod/night_drop.c
maybe its useful!
@gtxaspec , Thanks. I will check this one too.
@mnakada, I have a fork of libcallback, that I have added the following features to (there are still more modifications I plan to attempt, but there are setbacks):
support simultaneous output of both streams of the camera, 1080 and 360, output to two different v4l devices (video_callback.c) support both audio streams of the camera (audio_callback.c) support tuning of the image signal processor variables (imp_control.c)
I would like to share, in case you have not seen yet, https://github.com/gtxaspec/wz_mini_hacks/tree/master/src/libcallback_wz_mod
If you want to think about implementing these in atomcam_tools, perhaps you or your atomcam users could benefit from these modifications, especially if they are used in conjunction with the RTSP server, it supports multiple video devices.
thank you again for your work with the atomcam_tools project.