Cam v2 quirks

[mwhdc]

This is great, I was hoping for a successor to WyzeHacks and just noticed your project has been making huge strides.

I have v2 and v3 cams (as well as Pan v1 which I would love to help support), and started testing on a spare v2. Because the v2 apparently has different stream mount points in /dev, the v2 multi-stream RTSP URLs are:

rtsp://login:password@IP_ADDRESS:8554/video6_unicast
rtsp://login:password@IP_ADDRESS:8554/video7_unicast

Whether I enable one or two streams, I can only view the substream (video7) in VLC and IINA. video6 connects but hangs in both apps. It looks like the server waits a while and then shifts to TCP transport, which also hangs.

handleCmd_SETUP:SETUP rtsp://10.0.0.168:8554/video6_unicast/track1 RTSP/1.0
CSeq: 5
Authorization: Digest username="view", realm="LIVE555 Streaming Media", nonce="40fa438f0c90ecae3b10d24d31e83b00", uri="rtsp://10.0.0.168:8554/video6_unicast/", response="43417fb5d47a67a1ff2fbb52de792431"
User-Agent: LibVLC/3.0.17.3 (LIVE555 Streaming Media v2016.11.28)
Transport: RTP/AVP;unicast;client_port=52306-52307

handleCmd_SETUP:SETUP rtsp://10.0.0.168:8554/video6_unicast/track1 RTSP/1.0
CSeq: 5
Authorization: Digest username="view", realm="LIVE555 Streaming Media", nonce="c76582c66b8623b17b45856b23d38710", uri="rtsp://10.0.0.168:8554/video6_unicast/", response="548f485995d86eef220d763e7c38287b"
User-Agent: LibVLC/3.0.17.3 (LIVE555 Streaming Media v2016.11.28)
Transport: RTP/AVP/TCP;unicast;interleaved=0-1

Also, when enabling two streams, some complaints about ioctl are logged during the setup of each stream. This doesn't happen when invoking v4l2rtspserver with just one stream.

[NOTICE] /root/CLEAN/v4l2rtspserver/v4l2wrapper/src/V4l2MmapDevice.cpp:49
    Device /dev/video6
[NOTICE] /root/CLEAN/v4l2rtspserver/v4l2wrapper/src/V4l2MmapDevice.cpp:73
    Device /dev/video6 nb buffer:2
[NOTICE] /root/CLEAN/v4l2rtspserver/v4l2wrapper/src/V4l2MmapDevice.cpp:49
    VIDIOC_REQBUFS: Inappropriate ioctl for device
Device video6
[NOTICE] /root/CLEAN/v4l2rtspserver/v4l2wrapper/src/V4l2MmapDevice.cpp:141
    VIDIOC_STREAMOFF: Inappropriate ioctl for device
VIDIOC_REQBUFS: Inappropriate ioctl for device

I haven't tweaked any RTSP params in wz_mini.conf and left audio disabled on both streams.

Let me know if I can provide any more info. Thanks for publishing this.

[gtxaspec]

what firmware version are you running on the V2? I can confirm on >.1002 both streams are working fine...also do you still have WyzeHacks installed? there may be some conflict when running both.

You can also check logread | grep injection a few minutes after freshly booting the camera,

you should see something like (example from v3):

May 13 13:22:38 iCamera: enc func injection save video_encode_cb=0x48b8b4
May 13 13:22:38 iCamera: enc func injection save video_encode_cb=0x48cf08
May 13 13:22:38 iCamera: enc func injection CH0 save audio_pcm_cb=0x48d0a8
May 13 13:22:39 iCamera: enc func injection CH1 save audio_pcm_cb=0x48cdd8

if you don't see any video injects, that may be why the stream is failing.

[gtxaspec]

Regarding the pan V1, do you have ssh access to it? Some logs would be helpful in testing, I don't have a V1 :(

[mwhdc]

what firmware version are you running on the V2? I can confirm on >.1002 both streams are working fine...also do you still have WyzeHacks installed? there may be some conflict when running both.

Firmware is 4.9.8.1002 downloaded and modded by your script. SD card was clean. I might have had the Dafang bootloader on the camera, would yours replace it during the initial flash?

You can also check logread | grep injection a few minutes after freshly booting the camera,

Looks OK. Two log entries for video and one for audio as configured.

Feb 20 02:19:30 iCamera: enc func injection save video_encode_cb=0x55d4c0
Feb 20 02:19:30 iCamera: enc func injection save video_encode_cb=0x40badc
Feb 20 02:19:30 iCamera: enc func injection CH0 save audio_pcm_cb=0x55e760
Feb 20 02:19:36 iCamera: enc func injection CH0 second callback for V2 save audio_pcm_cb=0x418f80

Regarding the pan V1, do you have ssh access to it? Some logs would be helpful in testing, I don't have a V1 :(

I have 3 currently running stock, but I can put Dafang on one to get a shell. Let me know what you need!

[gtxaspec]

i can confirm, this. Some sort of regression, let me take a look to see whats wrong.

[gtxaspec]

see if this works for you, @mwhdc: in wz_user.sh inside /opt/wz_mini/etc/init.d

change the sleep on line 542 from 5, to 10:

if [[ "$RTSP_LOW_RES_ENABLED" == "true" ]] || [[ "$RTSP_HI_RES_ENABLED" == "true" ]]; then
        echo "delay RTSP for iCamera"
        #This delay is required. Sometimes, if you start the rtsp server too soon, live view will break on the app.
        sleep 10

let me know if that works for you!

[mwhdc]

let me know if that works for you!

Didn't work, but I think you're onto something. I have both RTSP streams enabled. I can view video7 but not video6. This behavior is mirrored in the Wyze app - Wyze's servers can pull the 360p stream from the camera, but not the HD stream, or SD which I assume is downsampled from HD. So something is borking the video6 feed in general when it's enabled for RTSP streaming.

[gtxaspec]

@mwhdc, really weird, can you:

dmesg | grep mtd

[mwhdc]

[    0.000000] Kernel command line: console=ttyS1,115200n8 mem=104M@0x0 ispmem=8M@0x6800000 rmem=16M@0x7000000 init=/init mtdparts=jz_sfc:256k(boot),2048k(kernel),3392k(root),640k(driver),4736k(appfs),2048k(backupk),640k(backupd),2048k(backupa),256k(config),256k(para),-(flag)

[gtxaspec]

@mwhdc I can't seem to reproduce your problem reliably. Increasing the sleep time seems to have fixed any issues that I was experiencing.

On my end, on two different camera's, everything works properly. I would suggest formatting the memory card, and do a fresh install of wz_mini, and see if that works. If it doesn't, the only other variable I see being different is the bootloader...

[mwhdc]

I erased and reflashed /dev/mtd0 with the stock uboot.bin - not sure if it made a difference.

Currently I can get the HD stream via both RTSP (/unicast) and the Wyze app if it's the only stream enabled. With both streams enabled, I get the 360p stream but only audio on the HD stream.

I'll continue to experiment and try other v2 units. Thanks for looking into the issue.

Also let me know if can do anything to help get your code running on the Pan v1.

[gtxaspec]

@mwhdc for the pan v1, if would be to kind to get a dmesg log from the stock firmware, I need to analyze that to start it off

also let me know if you can test on other v2s you have, and if it works out or not!

[gtxaspec]

@mwhdc if you have time, try the latest release on the V2 and see if it fixes the HD stream

[gtxaspec]

i've also confirmed a bug in v4l2rtspserver which caused the ioctl errors with the maintainer, so hopefully that will also increase stability soon.

[mwhdc]

@mwhdc if you have time, try the latest release on the V2 and see if it fixes the HD stream

Thanks for digging into that. tl;dr no change for me between last week's code and today's, except the single stream URL changed from /unicast to /video6_unicast.

Yesterday I installed the previous rev of code onto 3 more V2 cams, so I had 4 total running a single HD stream with audio, reliably available via RTSP at /unicast and via the Wyze app. Enabling the 360p stream would make it accessible at /video7_unicast but knock out video on the HD stream, making only audio available at /video6_unicast and preventing the Wyze app from displaying HD or SD streams. This behavior was consistent across all the V2 cams with wz_mini installed. (V3 cam is running great under all configs.)

Today I did a fresh clone of your repo, formatted a new SD card, and copied over the contents of SD_ROOT plus my config file and authorized_keys. Result was the same as yesterday, except the single HD stream moved from /unicast to /video6_unicast. I didn't try 360p alone but assume it would similarly move to /video7_unicast. Still getting just audio on video6 when both streams are enabled.

I assumed I caused those ioctl errors by killing your v4l2rtspserver process and starting my own without loopback on either stream. If I pointed you toward an actual bug, glad to hear it...

[gtxaspec]

alright, still trying to chase this down... latest release has an updated rtsp server and script. the url should return to the way it was before. if you can test, lets see if that fixes it...and if the hd stream still doesn't work, could you run gather_logs.sh and share the archive here?

[mwhdc]

Single stream URL returned to /unicast but same behavior with both streams. Two log archives attached, one with just HD enabled and the other with both streams.

log_gather_1stream.tar.gz log_gather_2streams.tar.gz

[gtxaspec]

ok, found the problem. Somehow, when you have both streams enabled, the encoder mode for channel 0 (hd) is being set to an invalid value(rcAttr->rcMode->rcMode = 15(0xf) offset:size = 0:4 (supposed to only be 1,2,4 or 8) when you run impdbg --enc_info), though i'm not certain how since it looks like that wasn't specified.

I've added logic to the wz_user script to make sure this value is within the proper range in the config file, in case theres a typo or something else.

Still working on fixing this...

[gtxaspec]

OK, looks like different registers were being over-written by each other when we were setting them, try the latest release.

[mwhdc]

OK, looks like different registers were being over-written by each other when we were setting them, try the latest release.

Both streams are working well now. Thanks for tracking that down!

[gtxaspec]

OK, looks like different registers were being over-written by each other when we were setting them, try the latest release.

Both streams are working well now. Thanks for tracking that down!

great to hear! enjoy

[gtxaspec]

solved!

[mwhdc]

@gtxaspec Putting this here instead of opening a new bug...

I read about the new v2 kernel in your changelog and ran compile_image.sh to make an updated demo.bin (before I noticed you took care of reflashing the kernel in your upgrade script). The resulting demo.bin doesn't seem to be valid - the camera ignores it and just boots normally.

[gtxaspec]

thanks for the feedback, I'll take a look

[gtxaspec]

It may be due to the release having changed the way the init scripts work, rename v3_init.sh to wz_init.sh in etc/init.d and it should work. I'll update the notes.

[mwhdc]

It may be due to the release having changed the way the init scripts work, rename v3_init.sh to wz_init.sh in etc/init.d and it should work. I'll update the notes.

Sorry, my description of the issue wasn't clear - the camera won't flash the demo.bin the current v2_install resources create. It ignores the reset button being held down and does a normal boot.

I see what you meant, though - the pre 6/16 kernel is looking for init scripts that were renamed in the 6/16 release. I'll rename that script to boot once and run the onboard upgrade.

[mwhdc]

I copied /wz_mini/etc/init.d/wz_init.sh to v3_init.sh and wz_mini started up.

It looks like the kernel v2 flash during upgrade-run.sh might not be working either. I ran the upgrade script on a camera running pre 6/16 code, and it upgraded the SD file system contents, but then didn't start wz_mini - so I'm guessing it still has the older kernel.