Closed hinxx closed 2 years ago
cjj25
commented
2 years ago What's the model of the camera you're using? There are many different methods of extracting the H264 stream using the rts libs.
If a stream has already been initialised, I don't believe it can hook back into it. I'll have to play around with the tool again but I do remember getting it to function, it would save the frames to an mp4(?) file.
I'd make sure no other process is accessing the camera.
cjj25
commented
2 years ago Here's the output of a camera that had a stream started but the main process killed.
Filename: /tmp/frame.h264
Output:
dbg_isp log: Current fmt is : NV12 1920x1080
dbg_isp log: Current fps is : 1/20
dbg_isp log: ++++++++++++++++++++++++++++++++
dbg_isp log: H264EncInit#
dbg_isp log: streamType : 1070386381
dbg_isp log: viewMode : 10
dbg_isp log: level : 40
dbg_isp log: refFrameAmount : 1
dbg_isp log: width : 1920
dbg_isp log: height : 1080
dbg_isp log: frameRateNum : 20
dbg_isp log: frameRateDenom : 1
dbg_isp log: scaledWidth : 0
dbg_isp log: scaledHeight : 0
dbg_isp log: H264EncSetCodingCtrl#
dbg_isp log: sliceSize : 0
dbg_isp log: seiMessages : 0
dbg_isp log: videoFullRange : 0
dbg_isp log: constrainedIntraPrediction : 0
dbg_isp log: disableDeblockingFilter : 0
dbg_isp log: sampleAspectRatioWidth : 0
dbg_isp log: sampleAspectRatioHeight : 0
dbg_isp log: enableCabac : 1
dbg_isp log: cabacInitIdc : 0
dbg_isp log: transform8x8Mode : 2
dbg_isp log: quarterPixelMv : 2
dbg_isp log: cirStart : 0
dbg_isp log: cirInterval : 0
dbg_isp log: intraSliceMap1 : 0
dbg_isp log: intraSliceMap2 : 0
dbg_isp log: intraSliceMap3 : 0
dbg_isp log: intraArea.enable : 0
dbg_isp log: intraArea.top : 68
dbg_isp log: intraArea.bottom : 68
dbg_isp log: intraArea.left : 120
dbg_isp log: intraArea.right : 120
dbg_isp log: roi1Area.enable : 0
dbg_isp log: roi1Area.top : 68
dbg_isp log: roi1Area.bottom : 68
dbg_isp log: roi1Area.left : 120
dbg_isp log: roi1Area.right : 120
dbg_isp log: roi2Area.enable : 0
dbg_isp log: roi2Area.top : 68
dbg_isp log: roi2Area.bottom : 68
dbg_isp log: roi2Area.left : 120
dbg_isp log: roi2Area.right : 120
dbg_isp log: roi1DeltaQp : 0
dbg_isp log: roi2DeltaQp : 0
dbg_isp log: adaptiveRoi : 0
dbg_isp log: adaptiveRoiColor : 0
dbg_isp log: fieldOrder : 0
dbg_isp log: gdrDuration : 0
dbg_isp log: H264EncSetRateCtrl#
dbg_isp log: pictureRc : 1
dbg_isp log: mbRc : 0
dbg_isp log: pictureSkip : 0
dbg_isp log: qpHdr : -1
dbg_isp log: qpMin : 10
dbg_isp log: qpMax : 42
dbg_isp log: bitPerSecond : 2097152
dbg_isp log: gopLen : 30
dbg_isp log: hrd : 0
dbg_isp log: hrdCpbSize : 0
dbg_isp log: intraQpDelta : 0
dbg_isp log: fixedIntraQp : 0
dbg_isp log: mbQpAdjustment : 0
dbg_isp log: longTermPicRate : 15
dbg_isp log: mbQpAutoBoost : 0
dbg_isp log: H264EncSetPreProcessing#
dbg_isp log: origWidth : 1920
dbg_isp log: origHeight : 1080
dbg_isp log: xOffset : 0
dbg_isp log: yOffset : 0
dbg_isp log: inputType : 1
dbg_isp log: rotation : 0
dbg_isp log: videoStabilization : 0
dbg_isp log: colorConversion.type : 1
dbg_isp log: colorConversion.coeffA : 13933
dbg_isp log: colorConversion.coeffB : 46871
dbg_isp log: colorConversion.coeffC : 4732
dbg_isp log: colorConversion.coeffE : 35317
dbg_isp log: colorConversion.coeffF : 41615
dbg_isp log: scaledOutput : 0
dbg_isp log: interlacedFrame : 0
dbg_isp log: --------------------------------
dbg_isp log: init_buffers
dbg_isp log: reqbufs, count = 2
dbg_isp log: buffer count = 2
dbg_isp log: stream on
dbg_isp log: Get frame at [1445682422, 331057]
dbg_isp log: H264EncStrmEncode#
dbg_isp log: busLuma : 0
dbg_isp log: busChromaU : 0
dbg_isp log: busChromaV : 0
dbg_isp log: timeIncrement : 0
dbg_isp log: pOutBuf : 0x0
dbg_isp log: busOutBuf : 0
dbg_isp log: outBufSize : 0
dbg_isp log: codingType : 0
dbg_isp log: busLumaStab : 0
dbg_isp log: ipf : 0
dbg_isp log: ltrf : 0
dbg_isp log: --------------------------------
dbg_isp log: Get frame at [1445682422, 381242]
dbg_isp log: Get frame at [1445682422, 431463]
dbg_isp log: Get frame at [1445682422, 481689]
dbg_isp log: Get frame at [1445682422, 531908]
dbg_isp log: Get frame at [1445682422, 582130]
dbg_isp log: release_bufs
dbg_isp log: Cmd (preview) success. Use time:713
hinxx
commented
2 years ago Thanks!
What's the model of the camera you're using?
The camera is Tenvis T3801D.
I'd make sure no other process is accessing the camera.
The main app is not running, nor has it been started at boot as it does by default. The only thing that happened was that camera/sensor firmware was loaded through /sys file.
Here's the output of a camera that had a stream started but the main process killed.
I might want to try to start/kill the main app to let is initialize "stuff", and the nrun dbg_isp to see if it makes any difference. If that does not help I need to look into the dbg_isp to see what is the failure all about.
hinxx
commented
2 years ago Starting/killing the app and then running the dbg_isp made things worse:
./dbg_isp --preview --max 5 --number 5 --save /tmp/ --show --h264
dbg_isp log: Current fmt is : NV12 1920x1080
dbg_isp log: Current fps is : 1/15
dbg_isp error: alloc output buffer failed
dbg_isp error: init h264 env fail
dbg_isp log: init_buffers
dbg_isp log: reqbufs, count = 2
dbg_isp log: buffer count = 2
dbg_isp log: stream on
dbg_isp log: Get frame at [1633953082, 738889]
dbg_isp log: Get frame at [1633953082, 905328]
dbg_isp log: Get frame at [1633953083, 077346]
dbg_isp log: Get frame at [1633953083, 253584]
^^^^^^ HANG ^^^^^^There's an extra error line there, too.
cjj25
commented
2 years ago I've spent many hours on this SoC, it's certainly a good bit of fun! I ended up soldering up a removable SPI flash chip mount so I can flash/reflash on the fly in the event of a brick.
The core RTS log functions all point to /var/log/media.log - maybe this will give you a clue as to what is failing.
What's your point of entry, are you using UART or telnet?
dbg_isp error: alloc output buffer failed is usually memory related OR because the main application has initialised the buffers and not gracefully released them when killed. Even though it complained about creating the buffers, it still grabbed the frame.. did you get a /tmp/frame.h264 file?
How much memory does this device have? What's the output of free and df?
If you take a look at my RTSPServer project, specifically the stream.c, I created all the bootstrapping required to communicate with the driver using the official libraries.
Here is the output of a successful dbg_isp request in /var/log/media.log
Oct 24 10:24:07 (none) local5.info rtstream[439]: audio resample chn : 100
Oct 24 10:24:07 (none) local5.info rtstream[439]: audio mixer chn : 101
Oct 24 10:24:07 (none) local5.info rtstream[439]: rts av run
Oct 24 10:24:08 (none) local5.info rtstream[439]: audio playback chn : 102
Oct 24 10:24:08 (none) local5.info rtstream[439]: audio resample chn : 103
Oct 24 10:24:08 (none) local5.info rtstream[439]: audio capture chn : 104
Oct 24 10:24:08 (none) local5.info rtstream[439]: audio aec chn : 105
Oct 24 10:24:08 (none) local5.info rtstream[439]: audio resample chn : 106
Oct 24 10:24:08 (none) local5.info rtstream[439]: encode chn : 107
Oct 24 10:24:08 (none) local5.info rtstream[439]: amix check:1,run:1,do run:1,keep active:1,send:0,trig:0,poll:0;9
Oct 24 10:24:08 (none) local5.info rtstream[439]: aupl check:1,run:1,do run:1,keep active:1,send:0,trig:0,poll:1;7
Oct 24 10:24:08 (none) local5.info rtstream[439]: arsm check:0,run:0,do run:0,keep active:0,send:0,trig:0,poll:0;9
Oct 24 10:24:08 (none) local5.info rtstream[439]: aec check:0,run:0,do run:0,keep active:1,send:0,trig:0,poll:0;5
Oct 24 10:24:08 (none) local5.info rtstream[439]: arsm check:0,run:0,do run:0,keep active:1,send:0,trig:0,poll:0;6
Oct 24 10:24:08 (none) local5.info rtstream[439]: aenc check:0,run:0,do run:0,keep active:1,send:0,trig:0,poll:0;5
Oct 24 10:24:08 (none) local5.warn rtstream[439]: <__do_run_task, 654>unit(aec) run spend 52 ms, ret = 0
Oct 24 10:24:09 (none) local5.warn rtstream[439]: <__do_run_task, 654>unit(aenc) run spend 44 ms, ret = 0
Oct 24 10:24:09 (none) local5.warn rtstream[439]: <__do_run_task, 654>unit(aec) run spend 43 ms, ret = 0
Oct 24 10:24:09 (none) local5.warn rtstream[439]: <__do_run_task, 654>unit(auca) run spend 137 ms, ret = 0
Oct 24 10:24:09 (none) local5.warn rtstream[439]: <__recycle_audio_buffer, 60>Audio buffer use 63ms
Oct 24 10:24:09 (none) local5.warn rtstream[439]: <__do_run_task, 654>unit(aec) run spend 103 ms, ret = 0
Oct 24 10:24:09 (none) local5.warn rtstream[439]: <__do_run_task, 654>unit(aec) run spend 70 ms, ret = 0
Oct 24 10:24:09 (none) local5.warn rtstream[439]: <__recycle_audio_buffer, 60>Audio buffer use 68ms
Oct 24 10:24:09 (none) local5.warn rtstream[439]: <__do_run_task, 654>unit(aec) run spend 98 ms, ret = 0
Oct 24 10:24:09 (none) local5.warn rtstream[439]: <__do_run_task, 654>unit(aec) run spend 51 ms, ret = 0
Oct 24 10:24:09 (none) local5.warn rtstream[439]: <__do_run_task, 654>unit(aec) run spend 102 ms, ret = 0
Oct 24 10:24:09 (none) local5.warn rtstream[439]: <__do_run_task, 654>unit(aec) run spend 46 ms, ret = 0
Oct 24 10:24:09 (none) local5.warn rtstream[439]: <__do_run_task, 654>unit(aec) run spend 59 ms, ret = 0
Oct 24 10:24:09 (none) local5.warn rtstream[439]: <__do_run_task, 654>unit(arsm) run spend 0 ms, ret = -23
Oct 24 10:24:10 (none) local5.info rtstream[439]: arsm check:45,run:35,do run:35,keep active:98,send:30,trig:30,poll:0;1531
Oct 24 10:24:16 (none) local5.info rtstream[439]: arsm check:31,run:31,do run:31,keep active:668,send:30,trig:30,poll:0;7933
Oct 24 10:24:16 (none) local5.info rtstream[439]: amix check:727,run:610,do run:610,keep active:668,send:59,trig:33,poll:0;7933
Oct 24 10:24:16 (none) local5.info rtstream[439]: aupl check:63,run:63,do run:63,keep active:668,send:30,trig:30,poll:33;7934
Oct 24 10:24:16 (none) local5.info rtstream[439]: wait auca finish
Oct 24 10:24:16 (none) local5.info rtstream[439]: auca check:679,run:250,do run:248,keep active:669,send:0,trig:0,poll:10;7950
Oct 24 10:24:16 (none) local5.info rtstream[439]: aec check:668,run:647,do run:647,keep active:668,send:0,trig:0,poll:0;7939
Oct 24 10:24:16 (none) local5.info rtstream[439]: arsm check:27,run:27,do run:27,keep active:668,send:26,trig:26,poll:0;7940
Oct 24 10:24:16 (none) local5.info rtstream[439]: aenc check:677,run:26,do run:21,keep active:668,send:31,trig:25,poll:0;7940
Oct 24 10:24:16 (none) local5.info rtstream[439]: delete unit : arsm, 0x4bd698
Oct 24 10:24:16 (none) local5.info rtstream[439]: delete unit : arsm, 0x4bb838
Oct 24 10:24:16 (none) local5.info rtstream[439]: delete unit : aupl, 0x4bcdf8
Oct 24 10:24:16 (none) local5.info rtstream[439]: delete unit : amix, 0x4bc618
Oct 24 10:24:16 (none) local5.info rtstream[439]: delete unit : auca, 0x4bddf8
Oct 24 10:24:16 (none) local5.info rtstream[439]: delete unit : aec, 0x4c7998
Oct 24 10:24:16 (none) local5.info rtstream[439]: delete unit : arsm, 0x4c7f68
Oct 24 10:24:16 (none) local5.info rtstream[439]: delete unit : aenc, 0x4c8638
Oct 24 10:24:16 (none) local5.info rtstream[439]: rts av done
cjj25
commented
2 years ago Is this your device: https://fccid.io/2ADGP-TVS200/Internal-Photos/INT-PHO-4753551
Could you provide me with a firmware dump of this camera? It doesn't appear to be YI based?
echo "############## Starting Firmware Dump ##############"
mkdir -p /tmp/backup
cat /proc/mtd > /tmp/backup/mtd.txt
dd if=/dev/mtdblock0 of=/tmp/backup/mtdblock0.bin
dd if=/dev/mtdblock1 of=/tmp/backup/mtdblock1.bin
dd if=/dev/mtdblock2 of=/tmp/backup/mtdblock2.bin
dd if=/dev/mtdblock3 of=/tmp/backup/mtdblock3.bin
dd if=/dev/mtdblock4 of=/tmp/backup/mtdblock4.bin
dd if=/dev/mtdblock5 of=/tmp/backup/mtdblock5.bin
dd if=/dev/mtdblock6 of=/tmp/backup/mtdblock6.bin
dd if=/dev/mtdblock7 of=/tmp/backup/mtdblock7.bin
Then download the files using HTTP server from the tools (cd into folder) and use ./darkhttpd /tmp/backup then you'll be able to download the files via access the IP camera via HTTP.
I'd love to see how this vendor has implemented their logic. I'm halfway there on developing a more universal way of extracting the video feed without having to tamper with any of the stock configuration regardless of the vendor.
hinxx
commented
2 years ago I've spent many hours on this SoC, it's certainly a good bit of fun!
:) Same here. I love looking into these type of things and see how they work.
I ended up soldering up a removable SPI flash chip mount so I can flash/reflash on the fly in the event of a brick.
I've been lifting couple of SPI chip pins two times already, hehe, and then using a slow SPI reader. I got a hold of the flash dump that way as the serial UART is not routed to any PCB pins I could find). I did brick it once, but luckily had the initial flash dump and managed to recover it. Whooa. I like you approach and might do that myself if I need to tinker with the SPI chip one more time.
The core RTS log functions all point to /var/log/media.log - maybe this will give you a clue as to what is failing.
No file in my case. Looking at the dbg_isp disassembly it would route printf()s to a filename specified in env variable RTS_DBG_LOG_FILENAME, but I'm not setting that.
What's your point of entry, are you using UART or telnet?
Telnet. I enabled the telnetd daemon, created modded rootfs and flashed it.
.. it still grabbed the frame.. did you get a /tmp/frame.h264 file?
I looks like the frames are being captured, yes. But no /tmp/frame.h264, just /tmp/{1..5}.yuv files. Seems to default to raw data if compression is not available?!.
How much memory does this device have? What's the output of free and df?
Looks like 40 Mb of RAM if I'm reading this right, with about half of it used.
If you take a look at my RTSPServer project, specifically the stream.c, I created all the bootstrapping required to communicate with the driver using the official libraries.
Yes, I've seen that. Great job! It is where I started before looking into dbg_isp. For the RTSPServer you made, I had to use FPS denominator of 15 (instead of 20) in stream.c and then it started OK. I tried streaming frames, but the rts_av_poll() would always return -18 (RTS_E_EMPTY) and no frames are sent out. The dbg_isp seems to get the frames at least; so that is a step forward. Will definitely look into stream.c as soon as I figure out what is the deal with h264 errors.
I've tracked down the code used in the original app that deals with the stream setup as you've done in stream.c. It is > 90% the same, with one or two parameters differing, and some rts API calls ordering a bit different. Mine also sets up OSD channel and some other extra stuff which I think I can safely ignore for the time being.
Seems like you have the same sensor on that cam as I do (SC2230). Mine does not not have the /dev/cpld_periph, but there are some GPIO accesses being made through rts API. I'll need to find the way to read the ADC for night mode later on.
Could you provide me with a firmware dump of this camera? It doesn't appear to be YI based?
Yeah, that is the device.
FW is here: https://github.com/iotexproject/ucam-firmware/tags. I found that after I did my slow SPI chip kung-fu, doh. There is a bit of a header in the linux.bin (256 bytes) plus some meta data in front of the three images it holds (kernel, 2x rootfs), but nothing that binwalk can not help you with. IIRC, in tapo c100 u-boot sources file cmd_update.c you can find how / where the images start / end exactly. There is no uboot included in these updates, though. I'm running the latest fw version here. If you need the device dump I can put it somewhere; let me know.
cjj25
commented
2 years ago It's very odd that you're not getting any output in the /var/log/media.log as this is cooked into the actual Realtek libraries AND driver, and it can also be accessed via RTS_LOG for developers.
Don't worry too much about the /dev/cpld_periph this specific to Yi based cameras, each YI camera holds a blob of data into the flash. It's passed to this driver so it can handle pan/tilt and IR cut.
For your ADC, see if you have access to the below and find your channel (these should be a numerical value based on how light/dark)
cat /sys/devices/platform/rts_saradc.0/in0_inputcat /sys/devices/platform/rts_saradc.0/in1_inputcat /sys/devices/platform/rts_saradc.0/in2_inputcat /sys/devices/platform/rts_saradc.0/in3_inputI think it would be useful to have a dump of your device if you're willing to provide it, just makes the reverse engineering process a little easier.
Again, it's a bit strange you can't get more FPS. I know there are some kernel optimisations in the YI boot sequence, try below and see if you can get a higher FPS.
echo 2048 > /proc/sys/vm/min_free_kbytes
echo 100 > /proc/sys/vm/extfrag_threshold
echo 1 > /proc/sys/vm/compact_memory
What is the full init scipt for loading the driver modules in your firmware? Here is a snippet of the YI sequence (notice the hx280enc.so)
insmod /home/rt/ko/rlx_dma.ko
insmod /home/rt/ko/rlx_i2s.ko
insmod /home/rt/ko/rlx_codec.ko
insmod /home/rt/ko/rlx_snd_intern.ko
insmod /backup/8188fu.ko
insmod /home/rt/ko/rtsx-icr.ko
insmod /home/rt/ko/rts_cam.ko
insmod /home/rt/ko/rts_cam_mem.ko
insmod /home/rt/ko/rts_cam_lock.ko
insmod /home/rt/ko/rts_camera_soc.ko
insmod /home/rt/ko/rts_camera_hx280enc.ko
insmod /home/rt/ko/rts_camera_jpgenc.ko
insmod /home/rt/ko/rts_camera_osd2.ko
insmod /home/rt/ko/rtstream.koI think it would be useful to have a dump of your device if you're willing to provide it, just makes the reverse engineering process a little easier.
Sure here you go https://e.pcloud.link/publink/show?code=XZsMM5Z3AB9aCTKLXurwfOKAL381hrETQf7.
These are original dumps, no mods.
Note that I have not included the last mtd partition (mtd7) as it holds some config files that the stock app uses to talk to cloud etc. This one is r/w as it uses JFFS2 FS. There might be some info in those files that could be sensitive for sharing; one of the reasons I'm trying to get rid of that piece of sw. If you really want it I can try to reset the cam to factory settings and then dump it.
Thanks for the ADC pointers ; that should cut down RE effort on my part! I have all of those entries in /sys/devices/platform/rts_saradc.0/:
/ # cat /sys/devices/platform/rts_saradc.0/in0_input
168
/ # cat /sys/devices/platform/rts_saradc.0/in1_input
274
/ # cat /sys/devices/platform/rts_saradc.0/in2_input
271
/ # cat /sys/devices/platform/rts_saradc.0/in3_input
316try below and see if you can get a higher FPS
/ # echo 2048 > /proc/sys/vm/min_free_kbytes
/ # echo 100 > /proc/sys/vm/extfrag_threshold
/bin/sh: can't create /proc/sys/vm/extfrag_threshold: nonexistent directory
/ # echo 1 > /proc/sys/vm/compact_memory
/bin/sh: can't create /proc/sys/vm/compact_memory: nonexistent directoryStill same error when trying to set higher FPS:
./dbg_isp --get-fps
dbg_isp log: Current fps is : 1/15
dbg_isp log: Cmd (get-fps) success. Use time:1
./dbg_isp --set-fps 1 20
dbg_isp error: set fps (1/20) failed : -29
dbg_isp error: Cmd (set-fps) fail. Use time:1What is the full init scipt for loading the driver modules in your firmware?
The part that loads these kernel modules is split into three file, but essentially does exactly the same as you posted; rts_camera_hx280enc.ko is there. You can find the complete init in the rootfs bins in the above link.
BTW, not sure where to find the media.log references, but I get none in rts libs and bins you have.
RTS3903N-Tools $ strings * | grep media.log
strings: Warning: 'libs' is a directory
strings: Warning: 'Realtek Specific' is a directory
RTS3903N-Tools $ cd libs/
RTS3903N-Tools/libs $ strings * | grep media.log
RTS3903N-Tools/libs $ cd ../Realtek\ Specific/
RTS3903N-Tools/Realtek Specific $ strings * | grep media.logThanks, interestingly the bit I hoped you would post is missing. There's some interesting product capabilities in the dgiot binary.
conf.telnet and NetWork.RTSP that appear to come from /etc/conf/product.cof and/or /mnt/mmc/mmc1/product.cof
What do your files contain: /etc/conf/Config/Json, /etc/conf/product.cof, /etc/conf/custom/CustomConfig2, /etc/conf/deviceinfo
I don't think I was very clear about the RTS_LOG functionality, basically it gets pushed to the syslog but there is a config that maps it to /var/log/media.log and your FW does have it setup correctly see /etc/syslog.conf
Your FW doesn't appear to load all the driver modules that Yi does - see /etc/preinit/07_init_video
Yi Camera:
insmod /home/rt/ko/rlx_dma.ko
insmod /home/rt/ko/rlx_i2s.ko
insmod /home/rt/ko/rlx_codec.ko
insmod /home/rt/ko/rlx_snd_intern.ko
insmod /backup/8188fu.ko
insmod /home/rt/ko/rtsx-icr.ko
insmod /home/rt/ko/rts_cam.ko
insmod /home/rt/ko/rts_cam_mem.ko
insmod /home/rt/ko/rts_cam_lock.ko
insmod /home/rt/ko/rts_camera_soc.ko
insmod /home/rt/ko/rts_camera_hx280enc.ko
insmod /home/rt/ko/rts_camera_jpgenc.ko
insmod /home/rt/ko/rts_camera_osd2.ko
insmod /home/rt/ko/rtstream.koYour Camera:
#!/bin/sh
#this is automatically generated
#please ensure rts_cam.ko is inserted at first
insmod /usr/lib/modules/rts_cam.ko
insmod /usr/lib/modules/rts_cam_mem.ko
insmod /usr/lib/modules/rts_cam_lock.ko
insmod /usr/lib/modules/rts_camera_soc.ko
insmod /usr/lib/modules/rts_camera_hx280enc.ko
insmod /usr/lib/modules/rts_camera_jpgenc.ko
insmod /usr/lib/modules/rts_camera_osd2.ko
insmod /usr/lib/modules/rtstream.ko
What's the output of ps and ./busybox netstat -an (use the tools folder)
cjj25
commented
2 years ago I can also see that the dgiot is statically built binary, all the libraries are bundled in.
The dbg_isp requires the shared libraries which I can't find in your firmware? Are you using LD_LIBRARY_PATH and pointing at the libs in this repo?
0x00000001 (NEEDED) Shared library: [libpthread.so.0]
0x00000001 (NEEDED) Shared library: [libh1encoder.so.1]
0x00000001 (NEEDED) Shared library: [librtsisp.so.1]
0x00000001 (NEEDED) Shared library: [librtsutils.so.1]
0x00000001 (NEEDED) Shared library: [librtsv4l2.so.1]
0x00000001 (NEEDED) Shared library: [librtsjpeg.so.1]
0x00000001 (NEEDED) Shared library: [librtsbmp.so.1]
0x00000001 (NEEDED) Shared library: [librtscamkit.so.1]
0x00000001 (NEEDED) Shared library: [libgcc_s.so.1]
0x00000001 (NEEDED) Shared library: [libc.so.0]
Here is what is currently on the cam.
/ # cat /etc/conf/product.cof
[CONST_PARAM]
ptz_opposite_run=0
ircut_flip=0
[DEFAULT_SETTING]
telnet=0
language=1000These are gzip'ed config files that just hold some silly settings like volume and motor positions. The TUTK holds my device UID Account/Password used to login into cloud.
/ # ls -al /etc/conf/Config/Json
drwxr-xr-x 2 0 root 0 Oct 11 2021 .
drwxr-xr-x 3 0 root 0 Oct 11 2021 ..
-rw-r--r-- 1 0 root 31 Oct 8 2021 AUDIO
-rw-r--r-- 1 0 root 32 Oct 8 2021 AUDIO.second
-rw-r--r-- 1 0 root 43 Oct 11 2021 PTZRESUMEPOS
-rw-r--r-- 1 0 root 110 Oct 8 2021 TUTKFolder /etc/conf/custom/CustomConfig2 is empty.
I have extracted all the default config parameters from the binary I could. See https://e.pcloud.link/publink/show?code=XZWwM5ZRzrakLh99ASeigYzvoH2OYDdVEby.
The /mnt/mmc/mmc1/product.cof could be supplied to amend the default config. But looking at the app code it is very limited in settings; just a handful. Majority of config is in JSON files, gzipped in /etc/conf/Config/Json These get updated as user configures the device AFAICT.
The telnet config param does not do anything useful, as far as I could dig into the app. My best guess is that it is likely a relic of another product from which this one is based on. I tried setting the telnet to 1 but nothing changed; no ports were additionally opened on the device after boot. Also there is no other ports opened in stock configuration. The communication to the cloud is done using UDP packets through TUTK IOTC platform. As you can see in /etc/init.d/rcS lots of "useful" stuff is commented out and disabled. The app also manages the network connection (obtaining the IPs etc.); when I initially left out the start of the dgiot from the startup I could not get telnet access at all as the network did not initialize. In my modded fw I un-commented the network and telnet startup.
your FW does have it setup correctly see /etc/syslog.conf
Right, I see that now. I have the enabled syslogd but only couple of files appear in the /var/log, and they are pretty empty:
/ # ls /var/log/
kern.log mdev.log messagesIt could be that the devs disabled every possible logging for production. I had to patch the dgiot app to not set log level to minimum, only then did i start seeing some printfs() to appear (ones related to their product code). The rts API I found yesterday and patched it to, now I'm swamped in messages like these:
rtstream : [--]__run_task
rtstream : [++]__push_back_output_buffer_lk
rtstream : [+] __push_back_output_buffer_lk 1
rtstream : [-] __push_back_output_buffer_lk 0
rtstream : [--]__push_back_output_buffer_lk
rtstream : [++]__free_task_lk
rtstream : [+] __free_task_lk 1
rtstream : [-] __free_task_lk 0
rtstream : [--]__free_task_lk
rtstream : [++]__run_task
rtstream : [+] __run_task 1
rtstream : [-] __run_task 0
I need to silence these .. otherwise it is MB of worthless text :).
Your FW doesn't appear to load all the driver modules that Yi does
There two other files next to the /etc/preinit/07_init_video:
/etc/preinit/03_init_audio
/etc/preinit/03_init_sdhcand they all get loaded from /etc/init.d/rcS when /etc/preinit is looked at.
The modules are loaded:
/ # lsmod
Module Size Used by Tainted: G
8188fu 1472016 0
rtstream 3248 0
rts_camera_osd2 3200 0
rts_camera_jpgenc 4192 0
rts_camera_hx280enc 4448 1
rts_camera_soc 43296 1
rts_cam_lock 4112 0
rts_cam_mem 21776 2 rts_camera_soc
rts_cam 31600 10 rtstream,rts_camera_osd2,rts_camera_jpgenc,rts_camera_hx280enc,rts_camera_soc,rts_cam_lock,rts_cam_mem
rtsx_icr 24304 0
rlx_snd_intern 1664 0
rlx_codec 24928 1
rlx_i2s 7184 1
rlx_dma 6832 1
The dbg_isp requires the shared libraries which I can't find in your firmware? Are you using LD_LIBRARY_PATH and pointing at the libs in this repo?
Yes, dgiot is statically built not other libs anywhere.
I use the LD_LIBRARY_PATH, as you correctly assume, pointing to SD card folder where they are stored.
I noticed you just committed something about the uClibc and LD_PRELOAD; I haven't had a chance to check that out nor how it works. For now LD_LIBRARY_PATH works, but I did add other uClibc libs from the toolchain that you haven't included in libs to be able to run your tools (otherwise there would be missing symbols errors reported).
ps / netstat
This is on modded fw of course.. still very boring.
/var/tmp # ps
PID USER VSZ STAT COMMAND
1 0 1244 S init
2 0 0 SW [kthreadd]
3 0 0 SW [ksoftirqd/0]
4 0 0 SW [kworker/0:0]
5 0 0 SW< [kworker/0:0H]
6 0 0 SW [kworker/u2:0]
7 0 0 SW [rcu_preempt]
8 0 0 SW [rcu_bh]
9 0 0 SW [rcu_sched]
10 0 0 SW< [khelper]
11 0 0 SW< [writeback]
12 0 0 SW< [bioset]
13 0 0 SW< [kblockd]
14 0 0 SW [khubd]
15 0 0 SW [kworker/0:1]
16 0 0 SW< [cfg80211]
17 0 0 SW [kswapd0]
18 0 0 SW [fsnotify_mark]
19 0 0 SW< [crypto]
28 0 0 DW [enable_swp_task]
29 0 0 SW< [dwc_otg]
30 0 0 SW< [deferwq]
31 0 0 SW [kworker/u2:1]
32 0 0 SW< [kworker/0:1H]
394 0 1240 S udhcpc -b -i eth0 -s /usr/share/udhcpc/default.script
396 0 1240 S syslogd
398 0 1232 S klogd
401 0 1248 R telnetd -l /bin/sh
403 0 0 SWN [jffs2_gcd_mtd7]
423 0 1240 S /bin/getty -L ttyS1 57600 vt100
425 0 1252 S /bin/sh
449 0 0 SW [mmcqd/0]
477 0 1244 S /bin/sh
481 0 1252 S /bin/sh
493 0 1240 R ps
/var/tmp # ./busybox netstat -an
Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address Foreign Address State
tcp 0 0 0.0.0.0:23 0.0.0.0:* LISTEN
tcp 0 0 192.168.11.52:23 192.168.11.2:45144 ESTABLISHED
tcp 0 0 192.168.11.52:23 192.168.0.2:35574 ESTABLISHED
tcp 0 0 192.168.11.52:23 192.168.0.2:35914 ESTABLISHED
Active UNIX domain sockets (servers and established)
Proto RefCnt Flags Type State I-Node Path
unix 3 [ ] DGRAM 656 /dev/log
unix 2 [ ] DGRAM 689 This is a very interesting bit of firmware, I've not seen any Realtek based camera like it! It appears the core is based of the dgiot framework.
I'd try getting syslog running before anything else, the binaries might be checking this on boot to set a flag.
In your configs under the NetWork section, try changing the server entity of the RTSP address from 0x00000000 to your local IP. This 0x00000000 could be 0.0.0.0 or null.... maybe if it had an IP it would start listening.
You can use the strace tool to watch and trace all the sys calls from any of the binaries, it's worth giving that a shot against dgiot
The uClibc library I've compiled is VERY useful. You can overwrite any shared library call with your own.. for example. Let's say you've created an application that uses a shared library file, in this library file is a function .. such as random() and it returns a random number. Using LD_PRELOAD, you can make sure your library that has the matching function signature of random() get's called. You can then manipulate the result of random.
The most interesting areas for you to explore for the P2P protocol (gets called in dgiot)
avServStart3 avServStartEx in libAVAPIs.so
IOTC_Listen in libP2PTunnelAPIs.so
What's the end goal for this device? To expose an RTSP server?
It appears there maybe a "dashboard" (http gui) according to the dgiot git repo.
cjj25
commented
2 years ago If you want to make your own trampoline function, this looks very promising: TUTK SDK
Edit: Corrected broken link
hinxx
commented
2 years ago I can see how your uClibc might be a good thing! Will definitely look into it.
The cam is a bit different than all other Chinese cams out there, but not too different if looking closer. There are traces of reused design in hw/fw/sw aspects from other Tenvis products with a pinch of blockchain spice if you ask me.
I started all this because the damn thing would reboot about once a day play the "I'm alive" sound; not nice. Then there would be motion events sent out for no reason because sw/fw determined that something moved. In fact what was happening was night/day mode was flipping back and forth while the ambient light was not changing at all. This might not be strictly related to the security features mentioned below, but might be due to other various reasons (faulty hw for ADC, sw lockup -> watchdog resets device, OOM, CPU lockup, whatever).
This cam is supposed to overcome the issues with usernames/passwords and use blockchain (IOTEX) to replace the account management all together - https://ucam.iotex.io/. It sounds great, but it might not be all that tight and secure etc. as they want to present it. This is something I noticed while digging through the binaries on the camera and looking at the traffic. For example you can find the magic string mentioned here that is used to "scramble" the UDP payload between the device/server/client of TUTK. The iotex features are introduced on top of the TUTK and they do allow (AES) encrypted video stream to be used and no regular camera account/password is used. The client (ios/android) gets some data from iotex backend servers and then does TUTK IOTC platform communication (IMHO, as any other TUTK product would). With this comms no encryption is used. AES key for video encryption is sent over TUTK protocol, TUTK platform credentials and device UID is sent back and forth nilly willy. My wifi SSID/passowrd is sent to the TUTK platform for some reason all the time (if using wifi, not with wired connection). That makes me feel kinda uneasy. There is also this, and it does not seem like this cam is actually doing anything advanced that would make it not vulnerable to mitm attacks.
To be honest I'm kind of not really interested in TUTK and the original app at the moment, but would like to see if I can just make it stream the video over RTSP and see how it behaves (does light detecting ADC work OK?, would it reboot all of a sudden?..). I'm thinking of using some open source framework instead in the long run.
There's a newer version of the the TUTK SDK docs on the web.
Not sure if dgiot app it is related to the dgiot framework you found; maybe you see something I don't, feel free to report any findings.
To me, that project looks like it is about similar things (IoT) but so far I have not noticed anything that would make me think it is related to this cam. (Un)fortunate use of name only on some part? What I think is that this cam runs on Realtek API + TUTK (core and AV API only). No TUTK P2P found, where you could find telnet/ssh tunneling etc. There is a huge IOCTL like handling function that deals with data received over avRecvIOCtrl() and that is the core of it in terms of cloud comms with the clients. The iotex layer is bolted in through these IOCTL calls (setting encryption key, ..).
cjj25
commented
2 years ago The reason I connected the dots for the dgiot and the Github repo is simply down to its name. It's such a random name to use for a daemon, we could look at the strings and calls in that binary but if you're interested in scrapping it completely then I don't see it a as a benefit.
I can see why you want to ditch that FW, sounds like an unnecessary overhead!
Coming back to the original RTSPServer that I put together you mentioned:
the rts_av_poll() would always return -18 (RTS_E_EMPTY) and no frames are sent out.
I wonder if this has something to do with the h264 encoding issue you're having.
Did you use the library files I included in that repo (RTSPServer) or the ones you collected to make the dbg_isp function? I know there are slight differences in the SDK version and the streaming element doesn't work when mix and matching those libraries.
While running the RTSPServer, see if you end up with the RTS_LOG in /var/log/media.log as this might give you some clues (I left the output on).
I believe the ffmpeg binary included in this repo has the h264 decoder for Realtek cooked in too, but it does rely on the shared libraries.
If you're wanting to completely dispose of the original FW, I managed to compile the 'stock' Realtek 'turnkey' firmware that all the example web gui, RTSP etc built in. I had to recompile UBOOT but it worked well. However, I wanted to continue my path around hooking existing firmware as not everyone is willing or has the ability to remove the SPI chip when you bad flash UBOOT.
hinxx
commented
2 years ago Does the h264 output with dbg_isp work for you if you use NV16 format? Earlier you reported h264 working for you with NV12 format.
I noticed I get alloc output buffer failed only for NV12 format, and not for NV16.
For NV16 one error is reported:
dbg_isp error: init h264 env failFor NV12 two errors are reported:
dbg_isp error: alloc output buffer failed
dbg_isp error: init h264 env failNV16 always hangs for me. What's your default mode when you boot? ./dbg_isp --get-fmt -d /dev/video51
/var/tmp/sd/RTS3903N-Tools/Realtek Specific # ./dbg_isp --list-stream
dbg_isp log: ----format-[0]-SEMIPLANAR YCBCR 4:2:0----
dbg_isp log: [Resolution:]min_w = 80, max_w = 1920, step_w = 2, min_h = 60, max_h = 1080, step_h = 2
dbg_isp log: 1/20
dbg_isp log: 1/19
dbg_isp log: 1/18
dbg_isp log: 1/17
dbg_isp log: 1/16
dbg_isp log: 1/15
dbg_isp log: 1/14
dbg_isp log: 1/13
dbg_isp log: 1/12
dbg_isp log: 1/11
dbg_isp log: 1/10
dbg_isp log: 1/9
dbg_isp log: 1/8
dbg_isp log: 1/7
dbg_isp log: 1/6
dbg_isp log: 1/5
dbg_isp log: 1/4
dbg_isp log: 1/3
dbg_isp log: 1/2
dbg_isp log: 1/1
dbg_isp log: ----format-[1]-SEMIPLANAR YCBCR 4:2:2----
dbg_isp log: [Resolution:]min_w = 80, max_w = 1920, step_w = 2, min_h = 60, max_h = 1080, step_h = 2
dbg_isp log: 1/20
dbg_isp log: 1/19
dbg_isp log: 1/18
dbg_isp log: 1/17
dbg_isp log: 1/16
dbg_isp log: 1/15
dbg_isp log: 1/14
dbg_isp log: 1/13
dbg_isp log: 1/12
dbg_isp log: 1/11
dbg_isp log: 1/10
dbg_isp log: 1/9
dbg_isp log: 1/8
dbg_isp log: 1/7
dbg_isp log: 1/6
dbg_isp log: 1/5
dbg_isp log: 1/4
dbg_isp log: 1/3
dbg_isp log: 1/2
dbg_isp log: 1/1
dbg_isp log: Cmd (list-stream) success. Use time:7/var/tmp/sd/RTS3903N-Tools/Realtek Specific # ./dbg_isp --get-fmt -d /dev/video51
dbg_isp log: Current fmt is : NV12 1920x1080
dbg_isp log: Cmd (get-fmt) success. Use time:0
/var/tmp/sd/RTS3903N-Tools/Realtek Specific # ./dbg_isp --set-fmt 1 1920 1080 -d /dev/video51
dbg_isp log: set fmt (NV16 1920x1080) success
dbg_isp log: Cmd (set-fmt) success. Use time:0/var/tmp/sd/RTS3903N-Tools/Realtek Specific # ./dbg_isp --preview --max 5 --number 5 --save /tmp/ --show --h264
dbg_isp log: Current fmt is : NV16 1920x1080
dbg_isp log: Current fps is : 1/20
dbg_isp error: init h264 env fail
dbg_isp log: init_buffers
dbg_isp log: reqbufs, count = 2
dbg_isp log: buffer count = 2
dbg_isp log: stream on
dbg_isp log: Get frame at [1445706176, 334841]
dbg_isp log: Get frame at [1445706176, 554898]
dbg_isp log: Get frame at [1445706176, 774992]
dbg_isp log: Get frame at [1445706177, 000397]
dbg_isp log: Get frame at [1445706177, 230143]
^^^^ HANG ^^^^the rts_av_poll() would always return -18 (RTS_E_EMPTY) and no frames are sent out. I wonder if this has something to do with the h264 encoding issue you're having.
Yeah, not sure. My goal was to find something that works and dbg_isp looks like it is closest to what I can get my hands on from the Realtek. Since I had to play around with the stream.c changes I thought it would be nice to have a baseline of what it works/does not work so that I can tailor my expectations accordingly when tweaking your stream.c further if I need to.
There are no errors reported all the way to the calls to rts_av_poll() AFAICT.
FWIW, dgiot sets h264_attr.bps=0x200000 and h264_attr.videostab=0; did not try to use that with stream.c yet as I diverged to looking at dbg_isp this morning and here I am.
Did you use the library files I included in that repo (RTSPServer) or the ones you collected to make the dbg_isp function? I know there are slight differences in the SDK version and the streaming element doesn't work when mix and matching those libraries.
I'm using all the libs you are providing; remember my fw comes with none of these guys. And I found that the rsdk-4.8.5-5281-EL-3.10-u0.9.33-m32fut-161202 toolchain is closest to what the existing fw has. Again, I did include this toolchain's basic libs, too, for RTSPServer/stream; modified CMakeLists.txt:
COMMAND cp ${CMAKE_SYSROOT}/lib/libc.so.0 ${OUTPUT_DIR}/lib/
COMMAND cp ${CMAKE_SYSROOT}/lib/libuClibc-0.9.33.so ${OUTPUT_DIR}/lib/
COMMAND cp ${CMAKE_SYSROOT}/lib/libpthread.so.0 ${OUTPUT_DIR}/lib/
COMMAND cp ${CMAKE_SYSROOT}/lib/libm.so.0 ${OUTPUT_DIR}/lib/
COMMAND cp ${CMAKE_SYSROOT}/lib/libgcc_s.so.1 ${OUTPUT_DIR}/lib/
COMMAND cp ${CMAKE_SYSROOT}/lib/libdl.so.0 ${OUTPUT_DIR}/lib/
COMMAND cp ${CMAKE_SYSROOT}/lib/librt.so.0 ${OUTPUT_DIR}/lib/
COMMAND cp ${CMAKE_SYSROOT}/lib/libubacktrace.so.0 ${OUTPUT_DIR}/lib/I know there are slight differences in the SDK version and the streaming element doesn't work when mix and matching those libraries.
I agree. This might be fragile. I'll try to do this in more control way. Checking which libs are loaded at dbg_isp invocation as you already mentioned! For example, while running dbg_isp I'm sure it is using some fw libs from /lib (i.e. libuClibc-0.9.33.so). Need to fix this..
While running the RTSPServer, see if you end up with the RTS_LOG in /var/log/media.log as this might give you some clues (I left the output on).
Will check.
These are the default values after reboot for me. Looks like they are similar; NV12 is used in both, yours being able to produce more FPS.
./dbg_isp --list-stream
dbg_isp log: ----format-[0]-SEMIPLANAR YCBCR 4:2:0----
dbg_isp log: [Resolution:]min_w = 80, max_w = 1920, step_w = 2, min_h = 60, max_h = 1080, step_h = 2
dbg_isp log: 1/15
dbg_isp log: 1/14
dbg_isp log: 1/13
dbg_isp log: 1/12
dbg_isp log: 1/11
dbg_isp log: 1/10
dbg_isp log: 1/9
dbg_isp log: 1/8
dbg_isp log: 1/7
dbg_isp log: 1/6
dbg_isp log: 1/5
dbg_isp log: 1/4
dbg_isp log: 1/3
dbg_isp log: 1/2
dbg_isp log: 1/1
dbg_isp log: ----format-[1]-SEMIPLANAR YCBCR 4:2:2----
dbg_isp log: [Resolution:]min_w = 80, max_w = 1920, step_w = 2, min_h = 60, max_h = 1080, step_h = 2
dbg_isp log: 1/15
dbg_isp log: 1/14
dbg_isp log: 1/13
dbg_isp log: 1/12
dbg_isp log: 1/11
dbg_isp log: 1/10
dbg_isp log: 1/9
dbg_isp log: 1/8
dbg_isp log: 1/7
dbg_isp log: 1/6
dbg_isp log: 1/5
dbg_isp log: 1/4
dbg_isp log: 1/3
dbg_isp log: 1/2
dbg_isp log: 1/1
dbg_isp log: Cmd (list-stream) success. Use time:9
./dbg_isp --get-fmt
dbg_isp log: Current fmt is : NV12 1920x1080
dbg_isp log: Cmd (get-fmt) success. Use time:0I'm running dbg_isp under gdb and can see that rts_isp_alloc_dma() returns -21 == RTS_E_INVALID_ARG. This is while using NV12 format.
cjj25
commented
2 years ago Try copying all the library files listed in the RTSPServer repo and then do something like
export LD_LIBRARY_PATH=/path/to/downloaded/libs/
See if your dbg_isp commands function any better, there MIGHT be a slight difference in the libs on this repo to those on the RTSPServer.
Your FW for the SC2230 is different to all of the dumps I have, I've attached the versions I've got (I don't know the differences between them)...
Your version:
➤ md5sum SC2230.bin
a6ac7bc72a7907687d193d2a06776fe2 SC2230.binMy versions:
➤ md5sum *
41483e0c40d11fd642b2eff88c4c5edd isp_jin.fw
98047911966645023e77ec5dce790e8a isp_lang.fw
cc576ff30e014722382ee97f774ccc19 isp_mipi.fwMy firmware loads echo -n "/home/lib/sc2230/isp_jin.fw" > /sys/devices/platform/rts_soc_camera/loadfw
Update: Attached files firmware.tar.gz
hinxx
commented
2 years ago I've figured out what the deal is with the h264 not working for me.
Long story short, the dbg_isp function init_h264enc_eniv() that tries to initialize some data buffer fails because the length parameter / value it passes to the rts_isp_alloc_dma() is 0. The reason it is zero is because an earlier call to H264EncGetPreProcessing() that fills in a structure with data (from the driver?) overwrites part of stack that it should not.
Once if force fed the correct register value in the right place / time in dbg_isp with GDB I got my frame out:
/var/tmp # ./gdbserver :1234 ./dbg_isp --preview --max 5 --number 5 --save /tmp/ --show --h264
warning: Found custom handler for signal 32 (Unknown signal 32) preinstalled.
warning: Found custom handler for signal 33 (Unknown signal 33) preinstalled.
Some signal dispositions inherited from the environment (SIG_DFL/SIG_IGN)
won't be propagated to spawned programs.
Process /mnt/mmc/mmc1/RTS3903N-Tools/RealtekSpecific/dbg_isp created; pid = 553
Listening on port 1234
Remote debugging from host 192.168.0.2, port 41434
dbg_isp log: Current fmt is : NV12 1920x1080
dbg_isp log: Current fps is : 1/15
dbg_isp log: ++++++++++++++++++++++++++++++++
dbg_isp log: H264EncInit#
dbg_isp log: streamType : 1070386381
dbg_isp log: viewMode : 10
dbg_isp log: level : 0
dbg_isp log: refFrameAmount : 0
dbg_isp log: width : 0
dbg_isp log: height : 0
dbg_isp log: frameRateNum : 0
dbg_isp log: frameRateDenom : 0
dbg_isp log: scaledWidth : 0
dbg_isp log: scaledHeight : 0
dbg_isp log: H264EncSetCodingCtrl#
dbg_isp log: sliceSize : 0
dbg_isp log: seiMessages : 0
dbg_isp log: videoFullRange : 0
dbg_isp log: constrainedIntraPrediction : 0
dbg_isp log: disableDeblockingFilter : 0
dbg_isp log: sampleAspectRatioWidth : 0
dbg_isp log: sampleAspectRatioHeight : 0
dbg_isp log: enableCabac : 1
dbg_isp log: cabacInitIdc : 0
dbg_isp log: transform8x8Mode : 2
dbg_isp log: quarterPixelMv : 2
dbg_isp log: cirStart : 0
dbg_isp log: cirInterval : 0
dbg_isp log: intraSliceMap1 : 0
dbg_isp log: intraSliceMap2 : 0
dbg_isp log: intraSliceMap3 : 0
dbg_isp log: intraArea.enable : 0
dbg_isp log: intraArea.top : 68
dbg_isp log: intraArea.bottom : 68
dbg_isp log: intraArea.left : 120
dbg_isp log: intraArea.right : 120
dbg_isp log: roi1Area.enable : 0
dbg_isp log: roi1Area.top : 68
dbg_isp log: roi1Area.bottom : 68
dbg_isp log: roi1Area.left : 120
dbg_isp log: roi1Area.right : 120
dbg_isp log: roi2Area.enable : 0
dbg_isp log: roi2Area.top : 68
dbg_isp log: roi2Area.bottom : 68
dbg_isp log: roi2Area.left : 120
dbg_isp log: roi2Area.right : 120
dbg_isp log: roi1DeltaQp : 0
dbg_isp log: roi2DeltaQp : 0
dbg_isp log: adaptiveRoi : 0
dbg_isp log: adaptiveRoiColor : 0
dbg_isp log: fieldOrder : 0
dbg_isp log: gdrDuration : 0
dbg_isp log: H264EncSetRateCtrl#
dbg_isp log: pictureRc : 1
dbg_isp log: mbRc : 0
dbg_isp log: pictureSkip : 0
dbg_isp log: qpHdr : -1
dbg_isp log: qpMin : 10
dbg_isp log: qpMax : 42
dbg_isp log: bitPerSecond : 2097152
dbg_isp log: gopLen : 30
dbg_isp log: hrd : 0
dbg_isp log: hrdCpbSize : 0
dbg_isp log: intraQpDelta : 0
dbg_isp log: fixedIntraQp : 0
dbg_isp log: mbQpAdjustment : 0
dbg_isp log: longTermPicRate : 15
dbg_isp log: mbQpAutoBoost : 0
dbg_isp log: H264EncSetPreProcessing#
dbg_isp log: origWidth : 1920
dbg_isp log: origHeight : 1080
dbg_isp log: xOffset : 0
dbg_isp log: yOffset : 0
dbg_isp log: inputType : 1
dbg_isp log: rotation : 0
dbg_isp log: videoStabilization : 0
dbg_isp log: colorConversion.type : 1
dbg_isp log: colorConversion.coeffA : 13933
dbg_isp log: colorConversion.coeffB : 46871
dbg_isp log: colorConversion.coeffC : 4732
dbg_isp log: colorConversion.coeffE : 35317
dbg_isp log: colorConversion.coeffF : 41615
dbg_isp log: scaledOutput : 0
dbg_isp log: interlacedFrame : 0
dbg_isp log: --------------------------------
dbg_isp log: init_buffers
dbg_isp log: reqbufs, count = 2
dbg_isp log: buffer count = 2
dbg_isp log: stream on
dbg_isp log: Get frame at [1445708528, 993148]
dbg_isp log: H264EncStrmEncode#
dbg_isp log: busLuma : 0
dbg_isp log: busChromaU : 0
dbg_isp log: busChromaV : 0
dbg_isp log: timeIncrement : 0
dbg_isp log: pOutBuf : 0x0
dbg_isp log: busOutBuf : 0
dbg_isp log: outBufSize : 0
dbg_isp log: codingType : 0
dbg_isp log: busLumaStab : 0
dbg_isp log: ipf : 0
dbg_isp log: ltrf : 0
dbg_isp log: --------------------------------
dbg_isp log: Get frame at [1445708529, 060097]
dbg_isp log: Get frame at [1445708529, 127052]
dbg_isp log: Get frame at [1445708529, 194014]
dbg_isp log: Get frame at [1445708529, 260985]
dbg_isp log: Get frame at [1445708529, 327943]
dbg_isp log: release_bufs
dbg_isp log: Cmd (preview) success. Use time:4668376
Child exited with status 0
/var/tmp # ls -al /tmp/frames.h264
-rw-r--r-- 1 0 root 262167 Oct 24 17:42 /tmp/frames.h264
I do not know for sure why is the stack overwritten in the first place. One of the reasons I can come up with is that the size of struct H264EncRateCtrl as used in libh1encoder.so is not what dbg_isp expects. The amount of (stack) memory written to by the H264EncGetRateCtrl() that populates struct H264EncRateCtrl.
cjj25
commented
2 years ago Great find!
If you do lsmod what do you see?
My output:
Module Size Used by Tainted: G
rtstream 3248 0
rts_camera_osd2 3056 0
rts_camera_jpgenc 4064 0
rts_camera_hx280enc 4336 0
rts_camera_soc 40448 0
rts_cam_lock 4112 0
rts_cam_mem 21584 1 rts_camera_soc
rts_cam 31616 7 rtstream,rts_camera_osd2,rts_camera_jpgenc,rts_camera_hx280enc,rts_camera_soc,rts_cam_lock,rts_cam_mem
rtsx_icr 23232 0
8188fu 918288 0
rlx_snd_intern 1632 0
rlx_codec 22528 1
rlx_i2s 7184 1
rlx_dma 6832 1 I wonder if you need the rlx_dma?
insmod /home/rt/ko/rlx_dma.ko
insmod /home/rt/ko/rlx_i2s.ko
insmod /home/rt/ko/rlx_codec.ko
insmod /home/rt/ko/rlx_snd_intern.koScrap that idea - I can see it's loaded in /etc/preinit/03_init_audio
as used in libh1encoder.so is not what dbg_isp expects.
I've attached some new libraries for you to try, these are different to what are on both my RTSPServer AND this repo.
My two repos appear to have identical libraries, however my firmware on the camera has different libs. Maybe you've spotted something!
26022a6343e863939b72fd33e71e32f6 ld-uClibc-0.9.33.so
fadbcc7e8d2c795c5c1d3cc8ba5bfe90 libaacenc.so
08788ce2ca13760f12f960794f8eee30 libasound.so
67369318af6276cf92de976810ce85b8 libatomic.so.1
36820a002995fe8176a0e80d4dba9027 libh1encoder.so
331300e718ab4c308dfe3457ee64585d libopencore-amrnb.so.0
608afaf880d0780b002f00244d4ab813 libopus.so
62c7b60efb868f5a24fe988006c67e27 librtsaec.so
c26baa7c77545225cb24c4dbf0422ee2 librtsbmp.so
24fded75a8367745668eaf8b9bbe5216 librtscamkit.so
8b2ee60011e396e00f10dc0455cb1a9a librtscrypt.so
20a7eac004f4c863edaeb754f79d7ae8 librtsgeom.so
8b084776d6ddc337d2e1b34d793302a5 librtsio.so
780834960111aa262b004e5f37c67285 librtsisp.so
d1c483023dbe4d8758d4750e95727073 librtsjpeg.so
2b8c803968f65159afc3a78d1c0bcb5c librtsmp3.so
8b9d0de9b7de058b9147c3c5a306b73a librtsnm.so
cbb714278e164820dae1915210e5e56a librtsosd2.so
43d02b16e905dd314a3eb352b9188aca librtsosd.so
ce62fe7b87a4145db9075b1c74f0f287 librtstream.so
c15db6414fe64338030d59506d15f492 librtsutils.so
9e2ed61659bf2d1036d52c47f14dd4f6 librtsv4l2.so
8d799430f1574e5ac4b99bbec528db7e libsbc.so
020a9b6f08c6e2fb6f22bc679cb6c30c libstdc++.so.6
aaf6a1b3c1cd6dc1b724db02eec9d878 libv4l2.so.0
5c859af243ad63007bdae75253722d16 libv4lconvert.so.0YI Camera Libs
6178fc95e7ccb38587180c43eb19f559 libaacenc.so
19c0512920361f9dd4659035d9a84295 libasound.so
19c0512920361f9dd4659035d9a84295 libasound.so.2
19c0512920361f9dd4659035d9a84295 libasound.so.2.0.0
95686c1eea1888764f1354c0d3785e3c libfdk-aac.so
95686c1eea1888764f1354c0d3785e3c libfdk-aac.so.1
95686c1eea1888764f1354c0d3785e3c libfdk-aac.so.1.0.0
46591703890c9ad9a5881b4926344f2a libh1encoder.so
46591703890c9ad9a5881b4926344f2a libh1encoder.so.1
46591703890c9ad9a5881b4926344f2a libh1encoder.so.1.203.3c6164
29ba7eccfa63ceb1aae7503034cdcca2 librtsaec.so
f8f0b467a5667e8459a1c20a9a34be63 librtsbmp.so
f8f0b467a5667e8459a1c20a9a34be63 librtsbmp.so.1
f8f0b467a5667e8459a1c20a9a34be63 librtsbmp.so.1.203.4b2128
794219213fd97d5692fb925817cad4c9 librtscamkit.so
794219213fd97d5692fb925817cad4c9 librtscamkit.so.1
794219213fd97d5692fb925817cad4c9 librtscamkit.so.1.203.4b2128
6ea051a3e765438405152f2a74be4a0d librtsgeom.so
6ea051a3e765438405152f2a74be4a0d librtsgeom.so.1
6ea051a3e765438405152f2a74be4a0d librtsgeom.so.1.203.4b2128
87fdf718ad9e508209b3eb96896cf13a librtsisp.so
87fdf718ad9e508209b3eb96896cf13a librtsisp.so.1
87fdf718ad9e508209b3eb96896cf13a librtsisp.so.1.203.9ee4b6
f9b22f937db6d1920e2f4ca129f528d0 librtsjpeg.so
f9b22f937db6d1920e2f4ca129f528d0 librtsjpeg.so.1
f9b22f937db6d1920e2f4ca129f528d0 librtsjpeg.so.1.203.9ee4b6
6e8dbcf66d07a46eac5102f8c3e73bc8 librtsmask.so
6e8dbcf66d07a46eac5102f8c3e73bc8 librtsmask.so.1
6e8dbcf66d07a46eac5102f8c3e73bc8 librtsmask.so.1.203.9ee4b6
76ebae234d4ef1f718a6b07f5c559443 librtsmd.so
76ebae234d4ef1f718a6b07f5c559443 librtsmd.so.1
76ebae234d4ef1f718a6b07f5c559443 librtsmd.so.1.203.9ee4b6
c2fa43d985112bfe130e52ff6b70229c librtsosd2.so
c2fa43d985112bfe130e52ff6b70229c librtsosd2.so.0
c2fa43d985112bfe130e52ff6b70229c librtsosd2.so.0.203.9ee4b6
33d6534641b78b30becd8b51951949fa librtstream.so
33d6534641b78b30becd8b51951949fa librtstream.so.2
33d6534641b78b30becd8b51951949fa librtstream.so.2.203.9ee4b6
0e82ecfd6e08be6d943f1b8091a6f3b0 librtsutils.so
0e82ecfd6e08be6d943f1b8091a6f3b0 librtsutils.so.1
0e82ecfd6e08be6d943f1b8091a6f3b0 librtsutils.so.1.203.9ee4b6
41c3eb5d67df945e6da7122c5436b638 librtsv4l2.so
41c3eb5d67df945e6da7122c5436b638 librtsv4l2.so.1
41c3eb5d67df945e6da7122c5436b638 librtsv4l2.so.1.203.4b2128Thanks!
I gave it a run, but it results in:
./dbg_isp --preview --max 5 --show --h264
dbg_isp log: Current fmt is : NV12 1920x1080
^^^^^^^^^^^ HANG ^^^^^^^^^^^^^The other frame/image acquisitions work just fine, just h264 is locking up the device; I need to reboot it..
I also tried your camera firmware isp_jin.fw from yesterday. I see that now the dbg_isp --list-stream reports 20 FPS as max value. Nevertheless, the h264 frame acquisition fails in the same way as it does for my camera firmware; either I see the error (with libs from this repo) or the device hangs (with libs from bundled.tar.gz).
Looking at the guts of the libh1encoder.so.1.203.3c6164, at a glance, it better fits the h264encapi.h header you've got in the RTSPServer repo; the size of the struct H264EncRateCtrl matches. Will run dbg_isp with more combinations of these libs..
cjj25
commented
2 years ago You're making some progress! Slowly but surely :)
I've attached the dbg_isp (and more goodies) that 100% have matching .ko and .so files. These are generated from the firmware I compiled myself.
extracted.tar.gz
In your /etc/init.d/rcS, I can see the syslogd and klogd are disabled. I'd enable them, all my FW has it this end. I wonder if that'll activate your RTS_LOG function for /var/log/media.log
Uncomment:
#if [ -x /bin/syslogd ]; then
# syslogd
#fi
#if [ -x /bin/klogd ]; then
# klogd
#fiIt's also worth noting that you have some kernel optimisations which again, none of my FW this end has. I wonder if the min_free_kbytes and others are causing issues the rtx buffer for the encoder. It's worth disabling/commenting them out as you're no longer running the vendors binaries / bloat.
echo "set min_free_kbytes 2048"
echo 2048 > /proc/sys/vm/min_free_kbytes
echo "set vfs_cache_pressure 150"
echo 150 > /proc/sys/vm/vfs_cache_pressure
echo "set overcommit_memory 1"
echo 1 > /proc/sys/vm/overcommit_memory
echo "set support_uhs 0"
echo 0 > /sys/kernel/debug/mmc0/rts3903-sdhc/support_uhs
#echo "set dirty_writeback_centisecs 200"
#echo 200 > /proc/sys/vm/dirty_writeback_centisecs
#echo "set dirty_expire_centisecs 1500"
#echo 1500 > /proc/sys/vm/dirty_expire_centisecs
I've also noticed that all my FW use the /bin/mdev while yours does something slightly different... (specifically the /media and its log... later)
Your FW
#echo "start mdev ..."
#mount -t tmpfs -o size=64k,mode=0755 tmpfs /media
echo /bin/mdev > /proc/sys/kernel/hotplug
mdev -s
...
#echo "rm mdev.log ..."
rm /var/log/mdev.log -rf
My FWs (no rm -rf /var/log/mdev.log)
#echo "start mdev ..."
mount -t tmpfs -o size=64k,mode=0755 tmpfs /media
echo /bin/mdev > /proc/sys/kernel/hotplug
mdev -sI've attached the YI and stock Realtek versions of /etc/init.d/rcS
I'm interested to know how you get on with these :)
cjj25
commented
2 years ago Actually, mdev might not really be all that useful. It appears to be related to the hotplug and sdcard... although the log file in /var/log/mdev.log could be useful to you.
Here's my /var/log/ folder (camera running 24+)
hinxx
commented
2 years ago I was about to ask if might be able to share your *.ko files as well :) Thanks!
Experimenting with the new libs from today I can see /var/log/media.log appear:
/var/tmp # cat /var/log/media.log
Oct 24 10:26:50 (none) local5.warn [rts camera][449]: <__read_reg, 131>(h264) preg is NULL, reg(0x0)
Oct 24 10:26:50 (none) local5.err [rts camera][449]: <__read_reg, 132>reg isn't mmap
Oct 24 10:27:36 (none) local5.warn [rts camera][453]: <__read_reg, 131>(h264) preg is NULL, reg(0x0)
Oct 24 10:27:36 (none) local5.err [rts camera][453]: <__read_reg, 132>reg isn't mmapThis is when I used the libh1encoder.so.1.203.3c6164 and replaced the libh1encoder.so,1 from this repo, then running dbg_isp. The error dbg_isp error: H264EncInit failed appears, and the log entries above are made. In this case the dbg_isp does not hang, but just captures raw frames. Changing the camera fw has no effect; I'm thinking kernel module(s) for camera might not fit the userspace tools.
I have the syslogd and klogd running in my fw at the moment with some other minor changes to the /etc/init.d/rcS startup exclusively. Everything else was intentionally left as-is.. I might need to introduce more intrusive changes, though.
We are getting to the point where I'll soon have all of the bits and pieces of your custom fw build, haha. Maybe I should try your complete fw build and be done with it ; what do you think?
cjj25
commented
2 years ago Maybe I should try your complete fw build and be done with it ; what do you think?
It depends on how comfortable you are with potentially de-soldering the SPI flash on a bad flash (which will happen) due to getting the Uboot parameters incorrect. You'll also need to hook up to UART to ensure you can see where the Uboot fails.
I highly recommend you give the extracted.tar.gz a shot. If you've got read/write then simply modify the /etc/preinit/07_init_video (comment and copy) to point to the ones included in the package.
If you don't have read/write access, a really hackish approach but works well is
rmmod $(lsmod | grep rt) (careful you don't unload the WiFi)
lsmod if you still rts_ entries then rmmod them one-by-one, ideally creating a script to do it for later usermmod $(lsmod | grep rts_) and rmmod $(lsmod | grep rt) multiple times eventually clears them lsmodmount --bind /path/to/new/lib/modules/ko_files/ /usr/lib/modules/ ./etc/preinit/07_init_video You can then do LD_PRELOAD_PATH=/path/to/new/lib/ dbg_isp --commands... or use the mount bind method above to bind all of /lib... If any of the above fails (on a read only mount) then a reboot will restore.
hinxx
commented
2 years ago I removed and inserted the modules manually, used LD_LIBRARY_PATH and the dbg_isp from the last archive. The result is success!
/mnt/mmc/mmc1/split/bin # ./dbg_isp --preview --max 5 --number 5 --save /tmp/ --show --h264
dbg_isp log: Current fmt is : NV12 1920x1080
dbg_isp log: Current fps is : 1/15
dbg_isp log: ++++++++++++++++++++++++++++++++
dbg_isp log: H264EncInit#
dbg_isp log: streamType : 0
dbg_isp log: viewMode : 1
dbg_isp log: level : 40
dbg_isp log: refFrameAmount : 1
dbg_isp log: width : 1920
dbg_isp log: height : 1080
dbg_isp log: frameRateNum : 15
dbg_isp log: frameRateDenom : 1
dbg_isp log: scaledWidth : 0
dbg_isp log: scaledHeight : 0
dbg_isp log: H264EncSetCodingCtrl#
dbg_isp log: sliceSize : 0
dbg_isp log: seiMessages : 0
dbg_isp log: videoFullRange : 0
dbg_isp log: constrainedIntraPrediction : 0
dbg_isp log: disableDeblockingFilter : 0
dbg_isp log: sampleAspectRatioWidth : 0
dbg_isp log: sampleAspectRatioHeight : 0
dbg_isp log: enableCabac : 1
dbg_isp log: cabacInitIdc : 0
dbg_isp log: transform8x8Mode : 2
dbg_isp log: quarterPixelMv : 2
dbg_isp log: cirStart : 0
dbg_isp log: cirInterval : 0
dbg_isp log: intraSliceMap1 : 0
dbg_isp log: intraSliceMap2 : 0
dbg_isp log: intraSliceMap3 : 0
dbg_isp log: intraArea.enable : 0
dbg_isp log: intraArea.top : 68
dbg_isp log: intraArea.bottom : 68
dbg_isp log: intraArea.left : 120
dbg_isp log: intraArea.right : 120
dbg_isp log: roi1Area.enable : 0
dbg_isp log: roi1Area.top : 68
dbg_isp log: roi1Area.bottom : 68
dbg_isp log: roi1Area.left : 120
dbg_isp log: roi1Area.right : 120
dbg_isp log: roi2Area.enable : 0
dbg_isp log: roi2Area.top : 68
dbg_isp log: roi2Area.bottom : 68
dbg_isp log: roi2Area.left : 120
dbg_isp log: roi2Area.right : 120
dbg_isp log: roi1DeltaQp : 0
dbg_isp log: roi2DeltaQp : 0
dbg_isp log: adaptiveRoi : 0
dbg_isp log: adaptiveRoiColor : 0
dbg_isp log: fieldOrder : 0
dbg_isp log: gdrDuration : 0
dbg_isp log: H264EncSetRateCtrl#
dbg_isp log: pictureRc : 1
dbg_isp log: mbRc : 0
dbg_isp log: pictureSkip : 0
dbg_isp log: qpHdr : -1
dbg_isp log: qpMin : 10
dbg_isp log: qpMax : 42
dbg_isp log: bitPerSecond : 2097152
dbg_isp log: gopLen : 30
dbg_isp log: hrd : 0
dbg_isp log: hrdCpbSize : 0
dbg_isp log: intraQpDelta : 0
dbg_isp log: fixedIntraQp : 0
dbg_isp log: mbQpAdjustment : 0
dbg_isp log: longTermPicRate : 15
dbg_isp log: mbQpAutoBoost : 0
dbg_isp log: H264EncSetPreProcessing#
dbg_isp log: origWidth : 1920
dbg_isp log: origHeight : 1080
dbg_isp log: xOffset : 0
dbg_isp log: yOffset : 0
dbg_isp log: inputType : 1
dbg_isp log: rotation : 0
dbg_isp log: videoStabilization : 0
dbg_isp log: colorConversion.type : 1
dbg_isp log: colorConversion.coeffA : 13933
dbg_isp log: colorConversion.coeffB : 46871
dbg_isp log: colorConversion.coeffC : 4732
dbg_isp log: colorConversion.coeffE : 35317
dbg_isp log: colorConversion.coeffF : 41615
dbg_isp log: scaledOutput : 0
dbg_isp log: interlacedFrame : 0
dbg_isp log: --------------------------------
dbg_isp log: init_buffers
dbg_isp log: reqbufs, count = 2
dbg_isp log: buffer count = 2
dbg_isp log: stream on
dbg_isp log: Get frame at [1445685951, 463502]
dbg_isp log: H264EncStrmEncode#
dbg_isp log: busLuma : 0
dbg_isp log: busChromaU : 0
dbg_isp log: busChromaV : 0
dbg_isp log: timeIncrement : 0
dbg_isp log: pOutBuf : 0x0
dbg_isp log: busOutBuf : 0
dbg_isp log: outBufSize : 0
dbg_isp log: codingType : 0
dbg_isp log: busLumaStab : 0
dbg_isp log: ipf : 0
dbg_isp log: ltrf : 0
dbg_isp log: --------------------------------
dbg_isp log: Get frame at [1445685951, 530450]
dbg_isp log: Get frame at [1445685951, 597413]
dbg_isp log: Get frame at [1445685951, 664379]
dbg_isp log: Get frame at [1445685951, 731340]
dbg_isp log: Get frame at [1445685951, 798303]
dbg_isp log: release_bufs
dbg_isp log: Cmd (preview) success. Use time:874I guess the kernel modules/userspace libs were not in-sync earlier.
It depends on how comfortable you are with potentially de-soldering the SPI flash on a bad flash (which will happen) due to getting the Uboot parameters incorrect. You'll also need to hook up to UART to ensure you can see where the Uboot fails.
Yeah, I might just go with updating the rootfs I have with these libs/modules, tweak the /etc if needed and use that. This way I can keep using existing u-boot/kernel with little fuss.
Next step for me is compiling stream.c with the libs you just provided and see if that gets me frames, too.
GREAT JOB, MAN. THANKS FOR THE HELP!!!
cjj25
commented
2 years ago I wonder if it's just the modules that aren't compatible, I'd try just swapping out the modules and then using the original libs.. see if my binary release on the RTSPServer runs (or dbg_isp)...
Re: helping
My absolute pleasure, I've hacked six of these cameras now and spent many hours researching/playing around with the SDK and the different variations of FW. I was very surprised to see this fw you're using! I've still not managed to get my hands on a Tuya FW yet.
I'll be continuing my 'universal' type stream exactor when I get a bit of time. I don't think it'll benefit you as it's designed to run along side the existing FW and just expose an RTSPServer.
Let me know how you get on with the above.
cjj25
commented
2 years ago Out of curiosity what's the output of df -h, I'd like to know how it's allocated :)
If you wouldn't mind, could you provide a full dump (including the /etc/ user parts) as I often load the different FWs into QEMU or directly onto my dev cam to try and find exploits/weaknesses in the stock FW binaries. I understand if you don't want to share it though :)
hinxx
commented
2 years ago I will surely play around with the combos of libs/modules to see what happens, too.
I'll be continuing my 'universal' type stream exactor when I get a bit of time. I don't think it'll benefit you as it's designed to run along side the existing FW and just expose an RTSPServer.
I'll see how far I can get with not doing complete overhaul of the fw on this camera as I mentioned the other day. I can see now that by just not starting dgiot app I'm pretty much all set to run what ever I want; IOW, if I can get the RTSPServer going with the existing fw that is fine with me, too. We'll see how it goes.
You mentioned 'turnkey SDK' couple of times. Is this it: https://github.com/MyEmbSolution/Rts3901 ? Also, you have some nifty rts_ libs and tools? Are you building those from source or are they from a cam you have?
I understand if you don't want to share it though :)
I think I can do that , let me just check what it is actually there in that last partition. OTOH, I can factory reset the thing and then dump the flash, and give you everything; is that fine with you?
cjj25
commented
2 years ago I think I can do that , let me just check what it is actually there in that last partition. OTOH, I can factory reset the thing and then dump the flash, and give you everything; is that fine with you?
That'll be perfect :)
The RTS3901 SDK (I have) isn't really ideal for the RTS3903, I pulled my SDK from TP Link camera if I remember correctly!
hinxx
commented
2 years ago Here is the flash dump I pulled of the device. It should be complete an functional as I've re-flashed it after I had a mishap with overwriting the uboot once.
Enjoy! Let me know if you need anything else.
cjj25
commented
2 years ago Thanks for the flash dump! I'll add it to my collection for later inspection. You can expire/delete the uploads from the internet now (if you're worried).
I look forward to hearing how you get on with the RTSPServer build. If you star/watch my repos, you'll get a notification as soon as I've created my more universal approach :)
McPrapor
commented
1 year ago I've spent many hours on this SoC, it's certainly a good bit of fun! I ended up soldering up a removable SPI flash chip mount so I can flash/reflash on the fly in the event of a brick.
The core RTS log functions all point to
/var/log/media.log- maybe this will give you a clue as to what is failing. What's your point of entry, are you using UART or telnet?
dbg_isp error: alloc output buffer failedis usually memory related OR because the main application has initialised the buffers and not gracefully released them when killed. Even though it complained about creating the buffers, it still grabbed the frame.. did you get a/tmp/frame.h264file?How much memory does this device have? What's the output of
freeanddf?If you take a look at my RTSPServer project, specifically the stream.c, I created all the bootstrapping required to communicate with the driver using the official libraries.
Here is the output of a successful dbg_isp request in
/var/log/media.logOct 24 10:24:07 (none) local5.info rtstream[439]: audio resample chn : 100 Oct 24 10:24:07 (none) local5.info rtstream[439]: audio mixer chn : 101 Oct 24 10:24:07 (none) local5.info rtstream[439]: rts av run Oct 24 10:24:08 (none) local5.info rtstream[439]: audio playback chn : 102 Oct 24 10:24:08 (none) local5.info rtstream[439]: audio resample chn : 103 Oct 24 10:24:08 (none) local5.info rtstream[439]: audio capture chn : 104 Oct 24 10:24:08 (none) local5.info rtstream[439]: audio aec chn : 105 Oct 24 10:24:08 (none) local5.info rtstream[439]: audio resample chn : 106 Oct 24 10:24:08 (none) local5.info rtstream[439]: encode chn : 107 Oct 24 10:24:08 (none) local5.info rtstream[439]: amix check:1,run:1,do run:1,keep active:1,send:0,trig:0,poll:0;9 Oct 24 10:24:08 (none) local5.info rtstream[439]: aupl check:1,run:1,do run:1,keep active:1,send:0,trig:0,poll:1;7 Oct 24 10:24:08 (none) local5.info rtstream[439]: arsm check:0,run:0,do run:0,keep active:0,send:0,trig:0,poll:0;9 Oct 24 10:24:08 (none) local5.info rtstream[439]: aec check:0,run:0,do run:0,keep active:1,send:0,trig:0,poll:0;5 Oct 24 10:24:08 (none) local5.info rtstream[439]: arsm check:0,run:0,do run:0,keep active:1,send:0,trig:0,poll:0;6 Oct 24 10:24:08 (none) local5.info rtstream[439]: aenc check:0,run:0,do run:0,keep active:1,send:0,trig:0,poll:0;5 Oct 24 10:24:08 (none) local5.warn rtstream[439]: <__do_run_task, 654>unit(aec) run spend 52 ms, ret = 0 Oct 24 10:24:09 (none) local5.warn rtstream[439]: <__do_run_task, 654>unit(aenc) run spend 44 ms, ret = 0 Oct 24 10:24:09 (none) local5.warn rtstream[439]: <__do_run_task, 654>unit(aec) run spend 43 ms, ret = 0 Oct 24 10:24:09 (none) local5.warn rtstream[439]: <__do_run_task, 654>unit(auca) run spend 137 ms, ret = 0 Oct 24 10:24:09 (none) local5.warn rtstream[439]: <__recycle_audio_buffer, 60>Audio buffer use 63ms Oct 24 10:24:09 (none) local5.warn rtstream[439]: <__do_run_task, 654>unit(aec) run spend 103 ms, ret = 0 Oct 24 10:24:09 (none) local5.warn rtstream[439]: <__do_run_task, 654>unit(aec) run spend 70 ms, ret = 0 Oct 24 10:24:09 (none) local5.warn rtstream[439]: <__recycle_audio_buffer, 60>Audio buffer use 68ms Oct 24 10:24:09 (none) local5.warn rtstream[439]: <__do_run_task, 654>unit(aec) run spend 98 ms, ret = 0 Oct 24 10:24:09 (none) local5.warn rtstream[439]: <__do_run_task, 654>unit(aec) run spend 51 ms, ret = 0 Oct 24 10:24:09 (none) local5.warn rtstream[439]: <__do_run_task, 654>unit(aec) run spend 102 ms, ret = 0 Oct 24 10:24:09 (none) local5.warn rtstream[439]: <__do_run_task, 654>unit(aec) run spend 46 ms, ret = 0 Oct 24 10:24:09 (none) local5.warn rtstream[439]: <__do_run_task, 654>unit(aec) run spend 59 ms, ret = 0 Oct 24 10:24:09 (none) local5.warn rtstream[439]: <__do_run_task, 654>unit(arsm) run spend 0 ms, ret = -23 Oct 24 10:24:10 (none) local5.info rtstream[439]: arsm check:45,run:35,do run:35,keep active:98,send:30,trig:30,poll:0;1531 Oct 24 10:24:16 (none) local5.info rtstream[439]: arsm check:31,run:31,do run:31,keep active:668,send:30,trig:30,poll:0;7933 Oct 24 10:24:16 (none) local5.info rtstream[439]: amix check:727,run:610,do run:610,keep active:668,send:59,trig:33,poll:0;7933 Oct 24 10:24:16 (none) local5.info rtstream[439]: aupl check:63,run:63,do run:63,keep active:668,send:30,trig:30,poll:33;7934 Oct 24 10:24:16 (none) local5.info rtstream[439]: wait auca finish Oct 24 10:24:16 (none) local5.info rtstream[439]: auca check:679,run:250,do run:248,keep active:669,send:0,trig:0,poll:10;7950 Oct 24 10:24:16 (none) local5.info rtstream[439]: aec check:668,run:647,do run:647,keep active:668,send:0,trig:0,poll:0;7939 Oct 24 10:24:16 (none) local5.info rtstream[439]: arsm check:27,run:27,do run:27,keep active:668,send:26,trig:26,poll:0;7940 Oct 24 10:24:16 (none) local5.info rtstream[439]: aenc check:677,run:26,do run:21,keep active:668,send:31,trig:25,poll:0;7940 Oct 24 10:24:16 (none) local5.info rtstream[439]: delete unit : arsm, 0x4bd698 Oct 24 10:24:16 (none) local5.info rtstream[439]: delete unit : arsm, 0x4bb838 Oct 24 10:24:16 (none) local5.info rtstream[439]: delete unit : aupl, 0x4bcdf8 Oct 24 10:24:16 (none) local5.info rtstream[439]: delete unit : amix, 0x4bc618 Oct 24 10:24:16 (none) local5.info rtstream[439]: delete unit : auca, 0x4bddf8 Oct 24 10:24:16 (none) local5.info rtstream[439]: delete unit : aec, 0x4c7998 Oct 24 10:24:16 (none) local5.info rtstream[439]: delete unit : arsm, 0x4c7f68 Oct 24 10:24:16 (none) local5.info rtstream[439]: delete unit : aenc, 0x4c8638 Oct 24 10:24:16 (none) local5.info rtstream[439]: rts av done
I have similar board, could you please tell me more about jtag pins? I see blue and white wires in same place, where I'm trying to get serial output on mine, but without any luck. What contacts are you using? It's little bit unclear.
cjj25
commented
1 year ago The blue and white are indeed serial outputs.
However, most vendors disable UART and reuse these as GPIOs after boot - leaving you with no output. I patched the bootloader to enable UART and that's how I figured out what was happening.
Is it the exact same board? I'll try find my pinout map I created and upload it for you - if I remember correctly I think the default uart pins are 15 and 16.
Take a look at my other repo (closed tickets) for layouts of other boards with the same SOC.
Nice work with the tools and the RTSP server !!
I'm trying them out on a camera that has the RTS3903N SoC and I can get the tool to work with raw (?) and jpeg images, but not with h264 compressed.
This is how I use it:
The
dbg_isp error: init h264 env failmakes me think something is not OK.FWIW, the camera uses SC2230 sensor, support only two video frame formats (NV12 and NV16), and up to 15 FPS. Vendor states that H.264 compression is supported (and I've seen stock binary code use rts API for h264). Looking at the jpg image I can tell that the
dbg_ispcapture works. Using different video formats produces different yuv file sizes, too. Some of the otherdbg_ispfunctions also seem to be working fine (i.e. query/set/get ctrl), OTOH I have not tried of them yet.Any ideas what might be going wrong with h264?