RTSP - high/low/both - with/without audio

[roleoroleo]

I need to shed some light on how the RTSP stream works in the latest version of the fw, due to the fact that there seem to be differences in behavior depending on the version of the camera (h201c, y203c, y25, etc...).

If you test 0.3.3, please leave a feedback here with the following info (example):

Camera suffix	Fw version	RTSP both	RTSP high	RTSP low	RTSP with audio	RTSP client
y203c	0.3.3	no (doesn't work)	yes (works)	not tested	no (blank screen)	vlc windows

And some details about your configuration:	Cloud	Onvif	mqtt
disable	enable	enable

Copy and paste this table:

|  Camera suffix | Fw version | RTSP both | RTSP high | RTSP low | RTSP with audio | RTSP client |
| --- | --- | --- | --- | --- | --- | --- |
| x | x | x | x | x | x | x |

| Cloud | Onvif | mqtt |
| --- | --- | --- |
| x | x | x |

[majkers]

Camera suffix	Fw version	RTSP both	RTSP high	RTSP low	RTSP with audio	RTSP client
y203c	0.3.3	no	yes	no	no	HomeAssistant

Cloud	Onvif	mqtt
enable	enable	enable

In this config with Yi 1080p Home everything is working just fine.

Camera suffix	Fw version	RTSP both	RTSP high	RTSP low	RTSP with audio	RTSP client
h201c	0.3.3	no	yes	no	no	HomeAssistant

Cloud	Onvif	mqtt
disable	enable	enable

In this config with Yi 1080p Dome I have some issues. It works slower than obove and sometimes I have to restart camera to get it working. More over when cloud is disabled sometimes recording without cloud is not working. Then I have to clear all records and restart camera to make it work again. It works even worse when time sync is disabled (once I forgot to turn it on...)

To sum up. Both my cameras are connected to Home Assistant and I see that it works faster with Yi Home's RTSP. I once mentioned that Dome camera's stream is really messy in one of issues but later on after restarting my router it begun to work again.

[bonuzzz]

camera y203c 0.3.3 client vlc (macos) cloud enable onvif enable mqtt enable

high -- yes high with audio -- after restart no, process crashed. after idle about 5 min - yes low -- yes low with audio -- no both -- no

[roleoroleo]

@majkers No means that doesn't work or that you didn't test it? If you tested it, please update the table you already entered. I need to know how the different possible configurations work on the different models. Thanks.

[majkers]

It means I didn't test it.

[roleoroleo]

Ok, thanks.

[twinstef]

Camera : Yi Dome 1080p

I have 2 Identicals Cameras, i have problems with the first one.

I made several tests:

Base Version: 4.6.0.0A_201908271549 cam1 : BFUSY1EEBV11R3200311 cam2 : BFUSY1EEEWUWBB191126

Suffix	Cloud	Onvif	mqtt	ssh	telnet	ftp
h201c	enable	disable	enable	enable	disable	disable

Cam 2 Tests: (BFUSY1EEEW)

Version	Rtsp	Audio	Flux	comment
0.3.2	H	H	ch0_0 => OK with audio
0.3.2	L	L	ch0_1 => OK with audio
0.3.2	B	H	ch0_0 => OK with audio
0.3.2	B	L	ch0_1 => OK with audio
0.3.3	H	H	ch0_0 => OK with audio
0.3.3	L	L	ch0_1 => OK with audio
0.3.3	B	H	ch0_0 => OK with audio
0.3.3	B	L	ch0_1 => OK with audio

Cam 1 Tests: (BFUSY1EEBV)

Rem: not able to upgrade firmare by web from 0.3.1 to 0.3.3 . done via scp

Version	Rtsp	Audio	Flux	comment
0.3.3	H	H	ch0_0 => OK with audio *
0.3.3	L	L	ch0_1 => OK with audio *
0.3.3	B	H	ch0_0 => OK with audio ch0_1 => OK
0.3.3	B	L	ch0_1 => OK *
0.3.2	H	H	ch0_0 => OK with audio *
0.3.2	L	L	ch0_1 => OK with audio *
0.3.2	B	H	ch0_0 => OK with audio ch0_1 => OK
0.3.2	B	L	ch0_1 => OK *

(*) frequent audio and video signal loose and sometime impossible to connect or reconnect to rtsp.

REM: cam1 if more distant from the wifi rooter than cam2 but has no stability problem with 0.3.1 firmware.

[roleoroleo]

@twinstef If you disable audio on cam 1, does it work better?

[twinstef]

@roleoroleo from memory, I had to start by doing this (no audio). and i test with rRTSPServer process from 0.3.1 on 0.3.3 firmwar and i had the sames problems. Anyway i will do some more test again but i need to put both cams on the same place to exclude connection problems. But for my needs, version v0.3.1 is anyway a great one ! Thanks for that.

[roleoroleo]

I'm working on a new version with audio support but with the same code of the 0.3.1 when audio is disabled. If I send you, could you test it?

[torcuat]

Camera suffix	Fw version	RTSP both	RTSP high	RTSP low	RTSP with audio	RTSP client
y25	0.3.3	Yes	Yes	Yes	No	VLC PC and several android apps

Cloud	Onvif	mqtt
disabled	enabled	disabled

[twinstef]

@roleoroleo Ready to test the version you speak about.

[roleoroleo]

@torcuat What kind of problem do you have with rtsp w audio? No stream, artifacts, other?

[bonuzzz]

Seems rtsp starts working when cam has some uptime about 5-10 min and more

[roleoroleo]

What a strange thing...

[bonuzzz]

yes. I have all profiles working, but needs to wait some time after reboot. 2-3 minutes is enough. even audio profiles are working too

[roleoroleo]

Maybe a problem during rmm startup. Could you try to dump /dev/fshare_frame_buf immediately after the boot? Only the first 16 bytes:

hexdump -C -n 16 /dev/fshare_frame_buf

If they are 0 we found the problem.

[PieVo]

Hi, First of all I think it is a good move to merge the grabber and the rtsp server. As it is very new, its probably a bit rough on the edges... No doubt all will be stable soon.

The following report is after dumped some data from the audio fifo (cat / ctrl c). That allows rmm to continue and initialize the video streams.

Camera model: 6FUS

Camera suffix	Fw version	RTSP both	RTSP high	RTSP low	RTSP with audio	RTSP client
y203c	0.3.3	No / Segfaults after undefined amount of minutes (with/without audio)	yes	yes	yes	VLC windows

Cloud	Onvif	mqtt
x	x	x

When I'm done with my audio related branches I will try to debug this segfault also.

[torcuat]

@torcuat What kind of problem do you have with rtsp w audio? No stream, artifacts, other?

No stream.

[bonuzzz]

hexdump -C -n 16 /dev/fshare_frame_buf

no, it is not null

[roleoroleo]

Ok, try to increment the sleep after rmm command in system.sh.

[bonuzzz]

Hm.. I thought I added yesterday. Later I had nulled buffer but I have working stream with audio at same time And now after 9 hours uptime I have filled buffer but not working stream About sleep, I had already 2 seconds there, added 5 more. Now nulled buffer and not working stream. High res with audio profile. Process doesn't crashed Same config. Just rebooted. Rtsp works, buffer filled.

Changed profile to low res with audio. Nulled buffer, stream doesn't work. Rebooted again and stream start working and buffer filled. I don't know what happened but after 3 hours stream is working. Buffer is filled.

[mihir8786]

Camera suffix	Fw version	RTSP both	RTSP high	RTSP low	RTSP with audio	RTSP client
y203c	0.3.3	No	Yes	No	No	BlueIris

Cloud	Onvif	mqtt
No	No	No

As many have described, the RTSP feed works fine for a while with audio and then stops. To get it working again, I always had to disable audio, restart camera, and then re-add in Blue Iris. It was a long process so I just stopped the audio feed altogether now. I didn't try rooboting twice as someone suggested.

I have two cameras and they both did this. Interestingly, even with audio off, I still randomly see one of my camera lose RTSP feed and the reboot doesn't fix it. I have to reboot and re-inspect in Blue Iris. Another one of my camera shows random artifacts (pretty much green screen) at times. Both my cameras are on 0.3.3 and both are on y203c.

On a positive side: when the audio worked, it was great! Very clear and loud. Thank you for all your work on this!

[PieVo]

@roleoroleo : This opening / dumping of data from the audio pipe causes unwanted dependencies/complications.. I'll try to prevent that from within tinyalsa, but it will not be nice though. E.g. kicking of a thread that shortly opens for reading and dies again.

Works like a charm: https://github.com/PieVo/yi-hack-MStar/commit/f32fd771e43d78df011784c4bcedf061659cb74f

https://github.com/PieVo/yi-hack-MStar/blob/audiopipe_auto_continue/src/tinyalsa/Yihack_tinyalsa.patch

[roleoroleo]

I ask you to test these beta versions, if possible. The goal is to achieve the stability of version 0.3.1 about RTSP. Audio remains an experimental feature at the moment.

h201c https://drive.google.com/open?id=14DpA6rTEpWklbBuhkkp201CU4H3u3zfE

y23c https://drive.google.com/open?id=1CvEwd2S9edUwkA-K75uIZVYFwUeCmRsP

y25c https://drive.google.com/open?id=1we27gqNMUf87QSfYY6scB4j2hgKEonTu

y203c https://drive.google.com/open?id=1gu0dklbjOgsuUL6MeZRAfI9pOI-ujkWf

[roleoroleo]

@PieVo I will integrate as soon as possible. In this beta version I lowered audio to 8 KHz, only for testing purpose.

[mihir8786]

@roleoroleo tried with y203c beta. Camera goes to the green artifact screen in Blue Iris but snapshot works on web ui. This is with RTSP audio off and RSTP on high stream. ONVIF, cloud, mqtt OFF.

[bonuzzz]

on tested fw high stream works. starts after 2 min after reboot. low stream stopped working after 20-30 sec after stating stream in vlc. in blueiris i don't have any artefacts. probably it depends on used hw acceleration. I tested only high, high with audio and low profiles.

Added today morning testing camera to blueiris (high profile without audio) and noticed now that picture freeze. In vlc stream is available now, so probably stream just dropped before.

[mihir8786]

@roleoroleo with the latest one you sent this morning, RTSP stops precisely at around 52 minutes. Stops both in BlueIris and VLC. Snapshot still works. This is withOUT the audio. Here's my settings with the latest beta you sent on 22 May. No artifacts, stream just dies it seems. Rebooting the camera fixes it for another 52 minutes.

Camera suffix	Fw version	RTSP both	RTSP high	RTSP low	RTSP with audio	RTSP client
y203c	0.3.3 (beta)	No	Yes	No	No	BlueIris (also tested with VLC)

Cloud	Onvif	mqtt
No	No	No

[roleoroleo]

The last beta, I hope. Restored the rRTSPServer from version 0.3.1 and changed the start procedure. Added https://github.com/PieVo/yi-hack-MStar/commit/f32fd771e43d78df011784c4bcedf061659cb74f

h201c: https://drive.google.com/open?id=1OBbOThwPzoDaRLTNPGNv_O5Gb-OHCSu3

y23: https://drive.google.com/open?id=1vOrlDcj7aJcWDkRR8qQMrkRfk6oOAQ7A

y25: https://drive.google.com/open?id=1MGGjqut3tzZ4rR7RrzXkIpsFB5Kilgyg

y203c: https://drive.google.com/open?id=1N_pBPQgvkqKZG706yq7VmJ4KOpAaTGbz

[torcuat]

For the first time, with your last beta, I get a working RTSP stream w/ audio enabled on my y25. Great, thank you!

[mihir8786]

RTSP has been stable for over 12 hours without audio. Will try now with audio. This is for y203c.

On Sat, May 23, 2020 at 4:49 PM roleo notifications@github.com wrote:

The last beta, I hope. Restored the rRTSPServer at versione 0.3.1 and changed the start procedure. Added PieVo@f32fd77 https://github.com/PieVo/yi-hack-MStar/commit/f32fd771e43d78df011784c4bcedf061659cb74f

h201c: https://drive.google.com/open?id=1OBbOThwPzoDaRLTNPGNv_O5Gb-OHCSu3

y23: https://drive.google.com/open?id=1vOrlDcj7aJcWDkRR8qQMrkRfk6oOAQ7A

y25: https://drive.google.com/open?id=1MGGjqut3tzZ4rR7RrzXkIpsFB5Kilgyg

y203c: https://drive.google.com/open?id=1N_pBPQgvkqKZG706yq7VmJ4KOpAaTGbz

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/roleoroleo/yi-hack-MStar/issues/183#issuecomment-633137489, or unsubscribe https://github.com/notifications/unsubscribe-auth/AKF6ROUXLW6DEGOECEDCXZDRTAZEVANCNFSM4NDZOJNQ .

[PieVo]

y203c here too: Audio enabled for high Both streams active

Streaming from both streams for >1:48hrs to VLC. Audio still present at the end.

(The first time I started the high and then connected the low, both streams disappeared. Not sure it was only rRTSP of the entire camera rebooted. It took a while before both came back up. I tried the same sequence 4 times but could not reproduce it. So, not sure what that was)

[mihir8786]

Stable RTSP for over 16hrs with audio!

On y203c. RTSP high only with audio. Cloud, Mqtt, and onvif off. Using on blue iris. Recording without cloud on.

Will try on my second camera now but looks good so far. Great work!!

On Sun, May 24, 2020 at 2:21 PM PieVo notifications@github.com wrote:

y203c here too: Audio enabled for high Both streams active

Streaming from both streams for >1:48hrs to VLC. Audio still present at the end.

(The first time I started the high and then connected the low, both streams disappeared. Not sure it was only rRTSP of the entire camera rebooted. It took a while before both came back up. I tried the same sequence 4 times but could not reproduce it. So, not sure what that was)

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/roleoroleo/yi-hack-MStar/issues/183#issuecomment-633271495, or unsubscribe https://github.com/notifications/unsubscribe-auth/AKF6ROSDSED6BZOQ7RYRKHDRTFQSXANCNFSM4NDZOJNQ .

[bonuzzz]

unfortunately both fw are unstable for me on y203c. stream dies after several hours in vlc and blueiris. high res profile without audio.

[roleoroleo]

@bonuzzz Which is the last working version for you?

[bonuzzz]

if you mean 0.3.3 variants, so the public build and the first test build were stable on high res without audio.Probably I need to reset camera to defaults and test again.

[roleoroleo]

And what about the previous released builds?

[bonuzzz]

Rest cameras are working on 0.3.1 without issues. I will reset test camera to defaults and try last build again

[roleoroleo]

Ok. Because the last beta contains the code used in the 0.3.1.

[mihir8786]

An update:

On y203c, with the latest beta, stable RTSP (high) with audio (high) for 48 hours. No reboots required. Cloud, MQTT, ONVIF off.

Looks stable. Thank you for all your work!

On Tue, May 26, 2020 at 6:42 AM roleo notifications@github.com wrote:

Ok. Because the last beta contains the code used in the 0.3.1.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/roleoroleo/yi-hack-MStar/issues/183#issuecomment-633948783, or unsubscribe https://github.com/notifications/unsubscribe-auth/AKF6ROTBMWPS6RF6KLZITA3RTOMKNANCNFSM4NDZOJNQ .

[bonuzzz]

resetted test camera yesterday and dirty flashed on one more camera latest build, seems to be stable, at least on blue iris. Tested only high res with audio profile.

[roleoroleo]

@roleoroleo : This opening / dumping of data from the audio pipe causes unwanted dependencies/complications.. I'll try to prevent that from within tinyalsa, but it will not be nice though. E.g. kicking of a thread that shortly opens for reading and dies again.

Works like a charm: PieVo@f32fd77

https://github.com/PieVo/yi-hack-MStar/blob/audiopipe_auto_continue/src/tinyalsa/Yihack_tinyalsa.patch

@PieVo I have a couple of questions about the patch. When you create the thread, it opens the fifo in read only mode and the main thread opens it in write mode. But the new thread doesn't read, only opens and closes. Is it enough? Second question: is there a race condition between the two threads? Who opens FIFO first?

[bonuzzz]

stream on both cameras died after about 15 hours. They are both accessable through yi home app, but stream doesn't work. high res with audio on one camera, without -on second. if it helps, i have it on dmesg: https://gist.github.com/bonuzzz/c115da46622f22d5c91ca366b805cb8b

[roleoroleo]

The log shows a lot of error, but all errors are about the yi processes. Is rRTSPServer running? Is rmm running?

[bonuzzz]

I had to reboot camera with profile without audio, but the second one is still working. rrtspserver_audio process is working, but i think it has been rebooted by watchdog. it has 0:34 uptime. rmm process has 7h18. camera's uptime is 19 hours rmm has 30-36% cpu activity. rrtsp - 0.2

[PieVo]

@roleoroleo : This opening / dumping of data from the audio pipe causes unwanted dependencies/complications.. I'll try to prevent that from within tinyalsa, but it will not be nice though. E.g. kicking of a thread that shortly opens for reading and dies again. Works like a charm: PieVo@f32fd77 https://github.com/PieVo/yi-hack-MStar/blob/audiopipe_auto_continue/src/tinyalsa/Yihack_tinyalsa.patch

@PieVo I have a couple of questions about the patch. When you create the thread, it opens the fifo in read only mode and the main thread opens it in write mode. But the new thread doesn't read, only opens and closes. Is it enough? Second question: is there a race condition between the two threads? Who opens FIFO first?

A "feature" of the fifo is that, for synchronization purposes, the open() call of the fifo blocks until a reader opens the other end of the fifo. (Even with O_NONBLOCK).

Just before the fifo is opened for writing the thread is started, which opens the fifos read end.

If the write end is opened first, it blocks until the read end is openened. If the read end is opened first, is opened for 250ms to allow the write end to open. (Could use a mutex for that).

After the write end is opened, there is no blocking anymore when writing to the fifo. When nobody is listening the write just fails.

[bonuzzz]

Reverted both cameras to 0.3.1 and after a day I don't have any issues, stream is stable. If you have debug build or may be I can help you with anything else?

[roleoroleo]

I found a segfault on live555 library. It probably depends on how I read the bytes from the circular buffer. I tried to solve it but I can not make it. I will restore the chain h264grabber -> rRTSPServer from 0.3.1 version. Sorry for the breaking change: I need to modify again the rtsp port for the sub stream.

[bonuzzz]

No problem. Don't worry

[PieVo]

Been there... Frustrating and takes lots of time.. The live555 code is pretty complex. I noticed there were some sleeps in functions that should not block (aftergetting), could that be it? Did you see the development audio source with a separate grabber thread?

On the other hand this is a hack, not perse the prettiest or best solution. So stability and function are in my opinion more important..

Be sure to store your work in a branch, who knows, maybe it’s just a small thing.

How about a single h264grabber instance that can grab both streams and writes it to 2 fifos like the audio? (Instead of stdout)? Would still be pretty clean if we feed all data into rRTSP via fifos.

Op za 30 mei 2020 om 15:01 schreef roleo notifications@github.com

I found a segfault on live555 library. It probably depends on how I read the bytes from the circular buffer. I tried to solve it but I can not make it. I will restore the chain h264grabber -> rRTSPServer from 0.3.1 version. Sorry for the breaking change: I need to modify again the rtsp port for the sub stream.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/roleoroleo/yi-hack-MStar/issues/183#issuecomment-636327931, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABNA2O26XBUYFSPIQ6HTKL3RUD7TPANCNFSM4NDZOJNQ .