[Support request] Yi Pro 2K Home YFUS 12.0.51

[b-a-9-0]

Hi, I have a Yi Pro 2K Home

• Serial YFUS....
• Base Version 12.0.51.01_202303091901

For curiosity I tried to apply the hack with y623. It kind of works (Web Interface, SSH, ...) but I have some problems with the RTSP streams. Low quality stream sometimes works, but not very stable, the high res stream does not work at all. Is there any advice what I can try to get this model running? Thanks for this great work!

[lolorc]

when glitches happen ffplay says : [h264 @ 0x7cd99003c900] concealing 4170 DC, 4170 AC, 4170 MV errors in I frame [h264 @ 0x7cd990090a40] error while decoding MB 142 67, bytestream -8 [h264 @ 0x7cd990090a40] concealing 1923 DC, 1923 AC, 1923 MV errors in I frame [h264 @ 0x7cd99018e480] error while decoding MB 137 78, bytestream -15 [h264 @ 0x7cd99018e480] concealing 344 DC, 344 AC, 344 MV errors in I frame [h264 @ 0x7cd99016c040] error while decoding MB 81 76, bytestream -5 [h264 @ 0x7cd99016c040] concealing 688 DC, 688 AC, 688 MV errors in I frame [h264 @ 0x7cd99018e480] error while decoding MB 124 80, bytestream -10 [h264 @ 0x7cd99018e480] concealing 69 DC, 69 AC, 69 MV errors in I frame

4-5 glitches in 2minutes.

ffplay doesn't complain as much when playing the video recorded with h264grabber but I just only made a quick test, I will test again later this week.

[roleoroleo]

ffplay doesn't complain as much when playing the video recorded with h264grabber but I just only made a quick test, I will test again later this week.

Let me know. And try to run rRTSPServer with the maximum log (d=15).

[lolorc]

here are rRTSPServer logs with -d 15, obtained from another host with ssh root@yicam "rRTSPServer -m y623 -r high -a no -p 554 -d15 2>&1" | ts > /tmp/log

yicam-02.nosound8.txt

and the record from ffmpeg -t 60 -rtsp_transport tcp -v verbose -i rtsp://yicam/ch0_0.h264 -c copy -f mp4 /tmp/mp4 https://github.com/roleoroleo/yi-hack-Allwinner-v2/assets/10393822/d9594e24-6add-4c2e-a264-8f7be37a671c

mplayer prints errors, mpv displays them more :-) glitches always occurs on the bottom half of the picture, using -s to rRTSPServer doesn't make it better. yicam and linux host are time synchronised from the same local ntp srv, hopefuly it should help finding relevant logs messages.

[lolorc]

"h264grabber -m y623 -r high > file.h264" looks ok, I haven't been able to reproduce an issue this evening with this method, but that doesn't involve streaming.

"h264grabber -m y623 -r high -f" + "rtsp_server_yi -r high -C h264 -a no" doesn't work, it's doesn't produce a "readable" rtsp stream.

at the moment I'm testing go2rtc (needs swap) with a basic exec stream "exec:h264grabber -m y623 -r high" it works without audio, the rtsp stream is ok, I'm yet to see a glitch.

I guess I could also give a try to mediamtx but that would require running mediamtx + h264grabber + ffmpeg, it's probably not worth it.

[roleoroleo]

The log yicam-02.nosound8.txt is ok:

• no errors
• no lost frames
• no buffer size problems

Both the grabber and the sinker. It's perfect.

Are you sure that the network is ok? Could you take a network capture between the cam and the rtsp client?

[lolorc]

I'll give it a look, but as I said I'm now running go2rtc instead of rRTSPServer, it's been working flawlessly since my last message. (no sound tho)

edit: I just gave a try with iperf3: no issue whatsoever, 21Mbps tcp stream from yicam to router without a single retransmit. no retransmit either when running "ffmpeg -i rtsp://yicam -f null /dev/null" from router.

ssh root@yicam "h264grabber -m y623 -r high" | mpv - also works flawlessly

[roleoroleo]

I'm really curious to understand what happens. Please, send me a dump of the network traffic. You can download tcpdump from here: https://github.com/roleoroleo/yi-hack-utils/tree/main/Allwinner-v2

[lolorc]

pcap, mp4 and logs are there https://gist.github.com/lolorc/7bc8168a19c83b941115a61d2792df1d

[roleoroleo]

The log is ok apart from 1 detail:

Apr 22 19:03:26 1713805406074: VideoFramedMemorySource - doGetNextFrame() start - fMaxSize 393216 - fLimitNumBytesToStream 0 - fPreferredFrameSize 0
Apr 22 19:03:26 1713805406074: VideoFramedMemorySource - doGetNextFrame() whole frame - fFrameSize 24 - counter 51525 - fMaxSize 393216 - fLimitNumBytesToStream 0
Apr 22 19:03:26 1713805406074: VideoFramedMemorySource - doGetNextFrame() whole frame completed
Apr 22 19:03:26 1713805406074: VideoFramedMemorySource - doGetNextFrame() start - fMaxSize 393216 - fLimitNumBytesToStream 0 - fPreferredFrameSize 0
Apr 22 19:03:26 1713805406075: VideoFramedMemorySource - doGetNextFrame() whole frame - fFrameSize 4 - counter 51526 - fMaxSize 393216 - fLimitNumBytesToStream 0
Apr 22 19:03:26 1713805406075: VideoFramedMemorySource - doGetNextFrame() whole frame completed
Apr 22 19:03:26 1713805406075: VideoFramedMemorySource - doGetNextFrame() start - fMaxSize 393216 - fLimitNumBytesToStream 0 - fPreferredFrameSize 0
Apr 22 19:03:26 1713805406075: VideoFramedMemorySource - doGetNextFrame() read_index == write_index
Apr 22 19:03:26 1713805406090: h26x in - frame detected - frame_len: 174406 - frame_counter: 51527 - frame_counter_last_valid: 51526 - resolution: 1080
Apr 22 19:03:26 1713805406090: h264/aac in - frame_len: 174406 - cb_current->size: 393216
Apr 22 19:03:26 1713805406091: h264/aac in - frame_len: 174406 - frame_counter: 51527 - resolution: 1080
Apr 22 19:03:26 1713805406091: h264/aac in - frame_write_index: 2/42
Apr 22 19:03:26 1713805406096: VideoFramedMemorySource - doGetNextFrame() 1st start
Apr 22 19:03:26 1713805406096: VideoFramedMemorySource - doGetNextFrame() start - fMaxSize 393216 - fLimitNumBytesToStream 0 - fPreferredFrameSize 0
Apr 22 19:03:26 1713805406096: VideoFramedMemorySource - doGetNextFrame() read_index == write_index
Apr 22 19:03:26 1713805406109: VideoFramedMemorySource - doGetNextFrame() start - fMaxSize 393216 - fLimitNumBytesToStream 0 - fPreferredFrameSize 0
Apr 22 19:03:26 1713805406109: VideoFramedMemorySource - doGetNextFrame() read_index == write_index
Apr 22 19:03:26 1713805406122: VideoFramedMemorySource - doGetNextFrame() start - fMaxSize 393216 - fLimitNumBytesToStream 0 - fPreferredFrameSize 0
Apr 22 19:03:26 1713805406122: VideoFramedMemorySource - doGetNextFrame() read_index == write_index
Apr 22 19:03:26 1713805406135: VideoFramedMemorySource - doGetNextFrame() start - fMaxSize 393216 - fLimitNumBytesToStream 0 - fPreferredFrameSize 0
Apr 22 19:03:26 1713805406135: VideoFramedMemorySource - doGetNextFrame() read_index == write_index
Apr 22 19:03:26 1713805406141: capture - ! n > 1
Apr 22 19:03:26 1713805406147: VideoFramedMemorySource - doGetNextFrame() start - fMaxSize 393216 - fLimitNumBytesToStream 0 - fPreferredFrameSize 0
Apr 22 19:03:26 1713805406147: VideoFramedMemorySource - doGetNextFrame() read_index == write_index
Apr 22 19:03:26 1713805406152: h26x in - frame detected - frame_len: 1556 - frame_counter: 51528 - frame_counter_last_valid: 51527 - resolution: 1080
Apr 22 19:03:26 1713805406152: h264/aac in - frame_len: 1556 - cb_current->size: 393216
Apr 22 19:03:26 1713805406152: h264/aac in - frame_len: 1556 - frame_counter: 51528 - resolution: 1080
Apr 22 19:03:26 1713805406152: h264/aac in - frame_write_index: 3/42
Apr 22 19:03:26 1713805406160: VideoFramedMemorySource - doGetNextFrame() start - fMaxSize 393216 - fLimitNumBytesToStream 0 - fPreferredFrameSize 0
Apr 22 19:03:26 1713805406160: VideoFramedMemorySource - doGetNextFrame() whole frame - fFrameSize 1552 - counter 51528 - fMaxSize 393216 - fLimitNumBytesToStream 0
Apr 22 19:03:26 1713805406160: VideoFramedMemorySource - doGetNextFrame() whole frame completed

Frame 51527 is missing. In particular, it's correctly acquired from the frame buffer file Apr 22 19:03:26 1713805406090: h26x in - frame detected - frame_len: 174406 - frame_counter: 51527 - frame_counter_last_valid: 51526 - resolution: 1080 but it's not delivered. There are no error in the log but I have to investigate some records, example: Apr 22 19:03:26 1713805406096: VideoFramedMemorySource - doGetNextFrame() 1st start

[roleoroleo]

The line: Apr 22 19:03:26 1713805406096: VideoFramedMemorySource - doGetNextFrame() 1st start means that the server received a stop request. And after a while it starts again to stream. But no stop requests are logged in the tcp dump. I think it depends on the live555 library, somewhere in the code.

About the pcap file. After 10 seconds, a new session starts (describe, setup and play) and another client plays the stream. I don't know if this can cause a problem with the constrained resources. But, there are no strange behaviors. Some TCP retransmission or TCP dup ACK, but nothing serious. The mystery deepens...

[github-actions[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[lolorc]

still using go2rtc without any issue, i'm just killing rRTSPServer and wd_rtsp.sh, activate swap, and run go2rtc with this go2rtc.yaml :

streams:
  ch0_0.h264:
    - exec:h264grabber -m y623 -r high
    - exec:h264grabber -m y623 -r NONE -a

api:
  listen: ""

webrtc:
  listen: ""

rtsp:
  listen: ":554"
``

it only works with h264grabber from 0.3.2+

[pierpippo]

Hi everyone, I would like to install the alternative firmware on my yi 2k pro to make it work with Home Assistant. I downloaded the y623_0.3.0.tar.gz file but I'm not clear how to install it on the webcam. Could someone help me please? Thx so much :)

[Suxsem]

I just bought 4 of these cameras, work great except of the pixel issue. Every few seconds a frame is completely corrupted. I'm running the latest firmware, any help?

[pierpippo]

I just bought 4 of these cameras, work great except of the pixel issue. Every few seconds a frame is completely corrupted. I'm running the latest firmware, any help?

Hi can you tell me how have you upgraded cam's firmware please?

[Suxsem]

Just following the instructions in the home page

[Suxsem]

@roleoroleo high-res-debug.txt this is the output of rRTSPServer -m y623 -r high -p 554 -d 15, i stopped the process just as the error occurred so the relevant log should be at the end of the file.

If go2rtc works fine i think the problem is in rRTSPServer, not in the h264grabber

Thank you, I'm deciding if returning the 4 pack of the cameras to amazon but beside this issue they are perfect so it's a shame. But i must be fix the issue otherwise my nvr (frigate) would detect these artifacts as movements.

[Suxsem]

@lolorc can you please elaborate on how you installed go2rtc and if you manually execute all commands after the camera starts or if you found a way to automatically start go2rtc on boot? thank you

[Suxsem]

@roleoroleo I discovered something strange: i tried running rRTSPServer with the -s option (don't overwrite SPS timing info (default overwrite)) and the issue is gone, no more missing frames. But with the -s option, movements in the image are blurry...

any help?

edit: could be something related to the FPS? I found that this camera users 30FPS instead of usual 20FPS, but in the -s option code I found a comment referring to 20fps:

https://github.com/roleoroleo/yi-hack-Allwinner-v2/blob/a896c7896d5b9faf53ff295cacd8e90b75e767df/src/rRTSPServer/src/rRTSPServer.cpp#L752

edit 2: ok I confirm there is something wrong with the FPS: this is from rRTSPServer WITH the -s option:

and this is WITHOUT the -s option:

I think that time information TI arrays for 2K in rRTSPServer.cpp are wrong, but I don't know how to generate the correct ones

[pierpippo]

I managed to install the 0.3.0 firmware but if I remove the SD card I can no longer see the rstp stream. But then am I forced to leave the SD card in the webcam?

[Suxsem]

I managed to install the 0.3.0 firmware but if I remove the SD card I can no longer see the rstp stream. But then am I forced to leave the SD card in the webcam?

yes this is also stated in the home page. please don't use this thread for unrelated issues...

[Suxsem]

I have tried to mess around with the SPS and recompile the firmware but I managed to get 21fps, not 30fps. I'm really no expert of h264 and I don't know how to properly change the SPS to obtain 30fps, I'm stuck, help is needed :)

[Suxsem]

after extensive testing also the -s option does not fix the glitching issue. I ended up using go2rtc as suggested, this is my fork with go2rtc bundled in and service and watchdog modified accordingly: https://github.com/Suxsem/yi-hack-Allwinner-v2 You have to check "use alternative rtsp server" to use go2rtc.

Sill, the ghosting effect remains, especially in low light conditions. @lolorc are you experiencing the same ghost effect when there are movements in the image?

[floronxt]

@roleoroleo Would it be possible to include go2rtc as an optional setting, please?

@Suxsem I also started go2rtc for testing and now the high stream is finally working. Thank you so much for taking the time.

[roleoroleo]

Sorry for the late reply. @Suxsem The log you posted is ok, no errors, no frame lost, no other problems. So I'm not able to understand the problem. Are you sure that your network is properly working?

Maybe you could take a capture with wireshare/tcpdump and share it with me. About fps, checking the log you can see that the mean interval between 2 frames is 50 ms, so the frame rate is 20 fps.

Normally. the capture procedure adds timing info inside the SPS structure, so the client is able to understand the frame rate. If you use "-s" option the procedure doesn't add this info and the client tries to guess the fps. When you read 29,97 it's not true. As you already tested, "-s" option is doesn't fix your problem.

I don't understand why h264grabber + go2rtc works and rRTSPServer no, because they share the same capture function. What protocol are you using with go2rtc?

And finally, about the ghosting effect, probably it's a problem of the Yi codec. Check if you have the same problem with the original app.

[roleoroleo]

@roleoroleo Would it be possible to include go2rtc as an optional setting, please?

I will try to add it, I need time...

[lenisko]

@Suxsem since you already did 80% of work, maybe create a PR. From what I saw it needs:

• frontend change to bring select list with Default, Alternative, Experimental rtsp servers, compatible with old config
• everything else you provided

[Suxsem]

hi @roleoroleo thank you for your reply. I'm confident in my network setup, camera is about 2 meters from the AP and I'm using industry standard network equipment. I'm running go2rtc since my last post without any issue, I'm pretty sure the issue is in rRTSPServer. go2rtc runs with exec:h264grabber -m y623 -r high and I connect to the camera through rtsp from my frigate instance.

I would like to use rRTSPServer instead of go2rtc to avoid swap on sdcard, please tell me if I can do anything to help you investigate the issue. I'm an italian software engineer maybe we could talk directly.

[setterlee]

@Suxsem Im having issues with my Yi Pro 2k Home YFUS cameras and frigate too, could you please share and example of you frigate and go2rtc config to test it? in my case I have the detect working well with the low res output but the record at hi res output is recorded without video (only audio) and in some cases the record process on frigate crash living the event withou record

[roleoroleo]

I would like to use rRTSPServer instead of go2rtc to avoid swap on sdcard, please tell me if I can do anything to help you investigate the issue. I'm an italian software engineer maybe we could talk directly.

Send me an email.

[roleoroleo]

@lolorc Does audio work with go2rtc and your configuration?

[Suxsem]

Update regarding the ghosting effect, I checked with the original app/firmware and the issue is there, so it's a problem of the Yi codec. The app notified me about a firmware update. Should I do it (maybe they fixed the ghosting effect?) or I may risk to not be able to run the hack after the firmware update? Thank you

edit: updated to the latest firmware (12.0.51.08_202403081746), the ghosting effect is still there so I doubt it can be fixed. Good news is that the hack still works on this new firmware, with the same glitch if I use rRTSPServer instead of go2rtc

[roleoroleo]

About ghosting effect, maybe you can try to change the codec from h264 to hevc. https://github.com/roleoroleo/yi-hack-Allwinner-v2/issues/484#issuecomment-1235411673 Make a backup copy of mtd7 before the change.

And check that the output of this command matches, before the change:

root@yi-hack:/# hexdump -C /dev/mtdblock7 | grep 00000300
00000300  64 00 00 00 01 00 00 00  64 00 00 00 01 00 00 00  |d.......d.......|

[lolorc]

@lolorc can you please elaborate on how you installed go2rtc and if you manually execute all commands after the camera starts or if you found a way to automatically start go2rtc on boot? thank you

sorry for late response, for now I'm killing the wd_rtsp.sh and rRTSPServer by hand, swap has to be enabled, go2rtc_linux_arm (v1.8.5) downloaded from go2rtc github page.

I've just had to redo it because the camera was unplugged, I guess I'm going to script this so it starts automatically.

[lolorc]

Sill, the ghosting effect remains, especially in low light conditions. @lolorc are you experiencing the same ghost effect when there are movements in the image?

with go2rtc ? not that I know of.

[lolorc]

@lolorc Does audio work with go2rtc and your configuration?

yep, but as I said h264grabber needs to be from a recent firmware (audio only fix you resolved earlier this year, https://github.com/roleoroleo/yi-hack-Allwinner-v2/commit/a9f80fc25fb66e67be4a15a696a0396350c733f5 )

swap also needs to be enable for go2rtc to start

[Suxsem]

@lolorc when using the -a flag I get streams: exec/pipe: EOF\nBoth video and audio are not supported with output to stdout\nUse fifo or run two processes\ how did you configured go2rtc to work with h264grabber -a ?

[dark-nico]

Hi, You need to separate the stream in two (one for the video, one for the audio). See : https://github.com/roleoroleo/yi-hack-Allwinner-v2/issues/753#issuecomment-2301983703 streams: ch0_0.h264:

• exec:h264grabber -m y623 -r high
• exec:h264grabber -m y623 -r NONE -a

I'm using go2rtc too for the same reason as the other. Got the crazy ghosting as well, hope we can find a solution for that.

[Suxsem]

It works, thank you!

I noticed that the ghosting effect is also present in the original xiaomi app, so I think that it cannot be resolved by us...

[roleoroleo]

Next release: https://github.com/roleoroleo/yi-hack-Allwinner-v2/commit/6d4a56418dc2e75c8c375df8656b9b38b45af5e5

[Suxsem]

@roleoroleo did you find any potential problem in rRTSPServer? go2rtc is a good alternative but it would be better to avoid it to avoid swap on sd

[roleoroleo]

No, but I know that y623 has problems. Could you try to run rRTSPServer manually in debug mode? rRTSPServer -m y623 -r both -d 15 Maybe there is an error in the log.

[Suxsem]

I think you already took a look at the log (https://github.com/roleoroleo/yi-hack-Allwinner-v2/issues/753#issuecomment-2329442110), but found nothing interesting.

[roleoroleo]

You are right sorry. Please, try this version: rRTSPServer.gz

[Suxsem]

@roleoroleo Thank you, just uploaded to the camera, I will review the footage tomorrow to see if the glitch is fixed.

Just to be sure, this version tries to fix the glitch, not the ghosting effect that is present also in the original app, right? Just to understand what to test. Thank you.

[Suxsem]

Unfortunately still glitch every 5 minutes or so

[roleoroleo]

Just to be sure... Is the glitch present in the stream, when you use the app?

[Suxsem]

What do you mean, in the original xiaomi app? No. Neither is present when using go2rtc.

[lenisko]

@roleoroleo since go2rtc is currently performing better, could you tick a release with changes above?

[roleoroleo]

I already added go2rtc to the hack. But I'm not able to make audio working. Please, test this beta: FILE REMOVED