search

roleoroleo / yi-hack-Allwinner

Custom firmware for Yi 1080p camera based on Allwinner platform
MIT License
445 stars 66 forks source link

Upgraded from 2.2 to 2.4 - now rRTSPServer does not work #277

Closed tunerooster closed 5 months ago

tunerooster commented 3 years ago

I just updated my 9FUSY31GA2N6SB200319 camera with YI 8.2.0.0A_202007211802 firmware from 0.2.2 to 0.2.4 using the Online FW upgradeweb interface.

The rRTSPServer is now failing (i.e., if no longer plays in Home Assistant). I just get a blank screen in the more-info popup. I reverted rRTSPServer to the 0.2.2 version I had saved and it is now working again.

When I run it with lib555ProxyServer I get the error message:

H264or5VideoStreamDiscreteFramer error: MPEG 'start code' seen in the input

which repeats continuously.

I have a few questions:

  1. Is it possible that the MFG firmware failure issue is the source of the rRTSPServer problem?
  2. How can I (or should I) update the Yi MFG firmware? They say they have "fixed and optimized several features". Or is it updated?

I have not tried any additional debugging with the failing rRTSPServer 2.4 version since I want to rule out the issue above first, but if the problem persists, I can run any tests you suggest.

...been loving your software! I have a few Yi Outdoor cams running yi-hack-v4 and it is nowhere near as stable as Allwinner (especially the rtsp). It is so bad I am planning to buy outdoor housings for indoor cameras and replace the outdoor cams with the Allwinner compatible indoor cams. It is a real shame too because the Yi Outdoor cams have a much higher quality outdoor sealed enclosure. I only wish Allwinner could run on them!

roleoroleo commented 3 years ago

There is a bug in this version. Read this issue: https://github.com/roleoroleo/yi-hack-Allwinner/issues/270

About fw version you can ignore the android app. This is because the hack is already based on the new version but I don't know where the original yi fw stores the info about the version installed. This is not a problem.

Tale a look here: https://github.com/alienatedsec/yi-hack-v5

tunerooster commented 3 years ago

Wow that is great news (Yi-Hack-V5)!

I will try out the bug fix release mentioned in #270 tomorrow and let you know.

So you are saying that the 0.2.4 release incorporates the Yi MFG firmware? Are you saying I should never try to update Yi MFG firmware, even though it says they have a new release and the Yi-hack web page says I am running the old release? (I was misled in my first post and have updated it.)

Thank you so much for your help!

roleoroleo commented 3 years ago

When a new version is release I upgrade the hack. So, it contains the last yi version.

But no problem if you want to upgrade it with the app (if it works). Unhack the cam, upgrade the sw and hack it again.

tunerooster commented 3 years ago

Nah... That's too much work. I will rely on your updates!

However, Yi says the latest update for this camera is: 8.2.0.0A_202012041528.

You show the firmware for the 0.2.4 update to be: 8.2.0.0A_202007211802.

The camera serial number is: 9FUSY31GA2N6SB200319.

tunerooster commented 3 years ago

I have installed the bugfix release from #270 as you suggested. I used the one under the comment:

I improved the log:
rRTSPServer.gz

The md5sum is: 31c4c6eee963858b1e92eb5401beb262 rRTSPServer

Regretfully it did not fix the issue...

What happens is:

Note that when I revert to the 0.2.2 rRSTPServer (dated 12-13-2020), it all works properly. I experience none of the issues listed above. Md5sum:

55a75d5ea50445b5247f46dcd45252a1  rRTSPServer-0.2.2-12-13-2020

I am willing to provide any support you would like to help.

Always a thankful user! :)

roleoroleo commented 3 years ago

Nah... That's too much work. I will rely on your updates!

However, Yi says the latest update for this camera is: 8.2.0.0A_202012041528.

You show the firmware for the 0.2.4 update to be: 8.2.0.0A_202007211802.

The camera serial number is: 9FUSY31GA2N6SB200319.

The file system is updated. Only the version file is old. I will fix this problem.

roleoroleo commented 3 years ago

I recently changed RTSP server to decrease resource usage. This added some bugs that I'm trying to fix but I would not go back unless necessary.

H264or5VideoStreamDiscreteFramer error: MPEG 'start code' seen in the input

I know this error and I solved it many weeks ago. To be sure, please try this binary: rRTSPServer.gz

If the error is not fixed, try to run the program manually and post the log:

. /home/yi-hack/script/env.sh
killall wd_rtsp.sh
killall rRTPSServer
RRTSP_RES=both RRTSP_AUDIO=no RRTSP_STI=0 RRTSP_DEBUG=3 ./rRTSPServer
tunerooster commented 3 years ago

I installed the above provided rRTSPServer release...

Here is what happened:

  1. ffplay rtsp://garage/ch0_0.h264 (direct play from camera over UDP) Plays but with severe (artifacts) and continuous error messages like: 
    [h264 @ 0x7f622809cff0] error while decoding MB 10 24, bytestream -6
[h264 @ 0x7f622809cff0] concealing 5319 DC, 5319 AC, 5319 MV errors in I frame
[swscaler @ 0x7f622c19e3d0] deprecated pixel format used, make sure you did set range correctly
[rtsp @ 0x7f6228000b90] max delay reached. need to consume packet   
[rtsp @ 0x7f6228000b90] RTP: missed 26 packets
  2. ffplay -rtsp_transport tcp rtsp://garage/ch0_0.h264 (direct play over TCP) No problem for 30-90 seconds, then: 
    
[h264 @ 0x7f5d249d9df0] error while decoding MB 105 11, bytestream -5
[h264 @ 0x7f5d249d9df0] concealing 6784 DC, 6784 AC, 6784 MV errors in I frame
[h264 @ 0x7f5d24021ff0] concealing 826 DC, 826 AC, 826 MV errors in P frame
[h264 @ 0x7f5d24022e20] concealing 732 DC, 732 AC, 732 MV errors in P frame
[h264 @ 0x7f5d249d9df0] concealing 447 DC, 447 AC, 447 MV errors in P frame
[h264 @ 0x7f5d24022e20] Invalid NAL unit 8, skipping.
[h264 @ 0x7f5d24021ff0] concealing 837 DC, 837 AC, 837 MV errors in P frame
[h264 @ 0x7f5d24022e20] concealing 817 DC, 817 AC, 817 MV errors in P frame
[h264 @ 0x7f5d24021ff0] concealing 799 DC, 799 AC, 799 MV errors in P frame
[h264 @ 0x7f5d24022e20] concealing 800 DC, 800 AC, 800 MV errors in P frame
[h264 @ 0x7f5d24022e20] concealing 835 DC, 835 AC, 835 MV errors in P frame
[h264 @ 0x7f5d249d9df0] concealing 788 DC, 788 AC, 788 MV errors in P frame
[h264 @ 0x7f5d24021ff0] concealing 834 DC, 834 AC, 834 MV errors in P frame
[h264 @ 0x7f5d24022e20] concealing 434 DC, 434 AC, 434 MV errors in P frame
[h264 @ 0x7f5d249d9df0] left block unavailable for requested intra mode
[h264 @ 0x7f5d249d9df0] error while decoding MB 0 7, bytestream 1262
[h264 @ 0x7f5d249d9df0] concealing 689 DC, 689 AC, 689 MV errors in P frame
[h264 @ 0x7f5d24021ff0] concealing 774 DC, 774 AC, 774 MV errors in P frame
[h264 @ 0x7f5d24022e20] concealing 608 DC, 608 AC, 608 MV errors in P frame
[h264 @ 0x7f5d249d9df0] concealing 857 DC, 857 AC, 857 MV errors in P frame
[h264 @ 0x7f5d24022e20] error while decoding MB 7 14, bytestream -6
[h264 @ 0x7f5d24022e20] concealing 402 DC, 402 AC, 402 MV errors in P frame
3. `ffplay rtsp://homeassistant/garage` (Play through live555 proxy) (UDP transport reading camera via live555, *and* UDP transport reading live555 stream)  Starts (but slowly) and plays OK for a while (30-90 seconds or so) then ffplay starts continuously emitting:

[h264 @ 0x7f5b500438d0] cabac decode of qscale diff failed at 109 12 [h264 @ 0x7f5b500438d0] error while decoding MB 109 12, bytestream 41911 [h264 @ 0x7f5b500438d0] concealing 6660 DC, 6660 AC, 6660 MV errors in I frame

4. `ffplay rtsp://homeassistant/garage`  (TCP transport reading camera via live555, *and* UDP transport reading live555 stream)  Starts (quickly), but after a while, get a few of the following errors, but not as many:

[h264 @ 0x7fd358a0c500] cabac decode of qscale diff failed at 86 60 [h264 @ 0x7fd358a0c500] error while decoding MB 86 60, bytestream 917 [h264 @ 0x7fd358a0c500] concealing 923 DC, 923 AC, 923 MV errors in I frame [h264 @ 0x7fd3580438d0] concealing 7924 DC, 7924 AC, 7924 MV errors in P frame

From the live555 log of 4., after a while, get continuous stream of:

RTCPInstance error: Hit limit when reading incoming packet over TCP. (fNumBytesAlreadyRead (1438) >= maxRTCPPacketSize (1438)). The remote endpoint is using a buggy implementation of RTP/RTCP-over-TCP. Please upgrade it!



Which of the above do you want me to run the log on?
It seems that the first priority would be to get the "direct camera stream" working, then see if that fixes the live555 issues.  Also, UDP can cause problems if my wifi is not strong, so maybe I should run the TCP direct camera feed log?  Please advise...

Thanks!
roleoroleo commented 3 years ago

TCP direct cam is ok. Remove audio when you test it. Thanks.

roleoroleo commented 3 years ago

After many hours of test I fixed another bug (already existing in the previous version). @tunerooster Please try this new binary: rRTSPServer.gz

tunerooster commented 3 years ago

Great! I will test it tomorrow. I am tied up today. I will let you know, and if it fails send you the log.

Best regards!

Arkady23 commented 3 years ago

@roleoroleo thank you very much. I thought the camera was broken. It was just a weak signal. I still have RTSP from 0.2.4. RTSP did not show it during the day, but with switching to night mode, I began to show it. I'll install your latest version now. During the day I will observe, I will inform you...

tunerooster commented 3 years ago

I installed the latest debug version from above: rRTSPServer-0.2.4-2021-04-10 with md5:

b549390245ab76a6d03a5ff949fb2446  rRTSPServer

I am still getting continuous errors as follows: (which do not occur with the 0.2.2 version)

[rtsp @ 0x7fa964000b90] max delay reached. need to consume packet   
[rtsp @ 0x7fa964000b90] RTP: missed 2 packets
[h264 @ 0x7fa964043680] error while decoding MB 25 65, bytestream -13
[h264 @ 0x7fa964043680] concealing 384 DC, 384 AC, 384 MV errors in I frame
[rtsp @ 0x7fa964000b90] max delay reached. need to consume packet   
[rtsp @ 0x7fa964000b90] RTP: missed 2 packets
[h264 @ 0x7fa964042860] error while decoding MB 60 65, bytestream -11
[h264 @ 0x7fa964042860] concealing 349 DC, 349 AC, 349 MV errors in I frame

This is as reported from ffplay (i.e., the ffmpeg player).

I have attached the log file. Thanks for your hard work! rRTSPServer-0.2.4-2021-04-10.log.gz

tunerooster commented 3 years ago

I forgot to use the TCP option when I ran the above! So this was with UDP. As I understand it, UDP can experience lost packets due to poor network (wifi) signal strength. Although is says on your http config page that the signal strength is 70%, the errors could still be with this.

I have rerun the test with TCP and have not seen any errors yet, so unless you see anything in the log pointing to a bug, there may not be a problem.

However, the 0.2.2 version did not show these errors. Ffplay and Home Assistant default to UDP. There is no way to change that in Home Assistant, at least for the streaming video feature.

roleoroleo commented 3 years ago

I don't know what type of camera are you using in ha but I think you can set tcp transport in the extra arguments.

tunerooster commented 3 years ago

You can, but it does not apply to the streaming (i.e., more-info on a picture entity) which does not use ffmpeg. It uses some kind of "blob" technology which I have not been able to track down, so I guess I am only assuming it is reading the rtsp port via UDP.

I do use extra-args: tcp on the things that call ffmpeg...

The question remaining, is why the problem does not occur in the 0.2.2 release. If you want, I can retest that?

PS, the camera is: Yi 1080p indoor 9FUSY31GA2N6SB200319

tunerooster commented 3 years ago

I'm not seeing any artifacts in the HA video stream! So maybe it isn't a problem. I can, however, retest 0.2.2 with UDP if you are curious...

Either way, just let me know when the final release is available. I want to stay up to date.

Thanks!

roleoroleo commented 3 years ago

Yesterday I tested in depth the last version adding a redirection to a file before to send the frames to the library (to avoid problems related to my wifi connection). I executed the program for about one hour. I copied the resulting file to a pc and I processed it with ffmpeg. The result is "no error". Why didn't the error occur in the old version? I don't know. I changed the method for sending frames to the library. From Source object to FramedSource object. To avoid rescanning the stream one more time looking for nalu, and save cpu/memory resources. Maybe this part of the library (FramedSource) is not ok?

Please, if you can, retest the 0.2.2.

Arkady23 commented 3 years ago

I checked this morning. I have a situation like this. The HD (high) stream does not show if the camera is on the loggia. On the old version 0.2.3 showed, but sometimes there were distortions of the image. If I switch to the SD stream in the settings (low), it shows when the camera is on the loggia. The WiFi level is 60-70%. If I bring the camera into the hall, then everything shows perfectly, HD or SD. If you test the old and new versions, then first of all I would check the traffic volume. It is interesting to find out if there is a difference in the volume of traffic.

Arkady23 commented 3 years ago

I see a solution to the problem by entering an option in the RTSP settings: Frame rate. Which would take values from 5 to 20. Or a choice of 5,10,15 or all. Or another option, such as the traffic transfer rate. Which would take the percentages of 25, 50, 75, and 100. And can divide by 2, 3 or 4 then 25, 33, 50 and 100%.

roleoroleo commented 3 years ago

Mmmmmh About frame rate, another thing comes to mind. I made another change in rRTSPServer: https://github.com/roleoroleo/yi-hack-Allwinner/commit/a4ab311b723c6686218963bdcfd1691ef1447eeb I'm overwriting the SPS with a new header that contains timing info. If you play the stream now you can see 20 fps. I thik is not a problem, but a test should be made. Please start manually rRTSPServer adding option RRTSP_STI=0. This will remove the new feature (sps_timing_info = no).

Arkady23 commented 3 years ago

@roleoroleo Nothing has changed, HD vlc does not show. The WiFi level is 65%. Changed the bash string:

...
if [[ $(get_config RTSP) == "yes" ]] ; then
    RRTSP_RES=$(get_config RTSP_STREAM) RRTSP_AUDIO=$(get_config RTSP_AUDIO) RRTSP_PORT=$RTSP_PORT RRTSP_USER=$USERNAME RRTSP_PWD=$PASSWORD RRTSP_STI=0 rRTSPServer &
...

Is it possible to broadcast for example 50%, i.e. 10 frames per second? I think it would be useful to be able to broadcast 5 frames per second also.

roleoroleo commented 3 years ago

Sorry, I can't control h264 encoding.

Arkady23 commented 3 years ago

I also added the same thing to the script wd_rtsp.sh. I think the situation got a little better after that. HD began to show through vlc, although with terrible brakes, but still shows.

Arkady23 commented 3 years ago

Although I'm not sure if it's from your parameter. Already with this parameter, it stopped showing.

Arkady23 commented 3 years ago

Sorry, I can't control h264 encoding.

Then you need to have a good WiFi level or use SD (low).

roleoroleo commented 3 years ago

What about using tcp transport?

github-actions[bot] commented 7 months ago

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.