Open w1ll1am23 opened 5 years ago
i created a thread on synology forum, verry interesting reply today seems they indeed removed the documentation, but the API should still work...
they have a new stream path now, so the HA code should be changed, but who can do that?? synology forum :
https://community.synology.com/forum/3/post/123094?reply=397361
reply :
@pergola_fabio0183 These APIs are still alive there in SS8.2.3. They are just removed from the document and are not recommended to use due to many aspects including efficiency consideration. And since they are still work, we didn't mention them in the release note. However, you can still use them for 3rd-party integration, but we will not maintain them since they are only used by really older version of DS cam.
If you get any problem using these APIs, you can check the usage flow or check the error code for more specific reason.
The recommended alternative for live view is first using GetLiveViewPath method, and then play the returned rtsp/http path. (You can use 3rd-party player, such as VLC, to test the path)
Based on the discussion it sounds like the streaming should still work in 8.2.3? Is it not working for you?
I'm doing upgrade now, let's see if mine works or not
Ok ya it's broken with 8.2.3 :( I'll see if I can fix this but probably over the weekend
Yes , on forum they say nothing changed, just removed the documentation... But it doesn't work I deed... But I think an Synology employee did that reply... It's safe anyway to use the new api
Ok, Synology replied again, they changed from did to cookie...
https://community.synology.com/forum/3/post/123094?reply=397574
I tried the sid
method listed on the Synology forums and was able to obtain the URLs, but none of those worked in VLC for me (maybe it is something simple that I am missing).
sid is not possible anymore with 8.2.3 it seems, you need cookies now but according to the synology person , who also replied on synology forum, we need to step away from videostream, and use the new method instead, thats also documented in the api
Ok...hopefully, we can figure that out and start using it.
@alekslyse , maybe we can discuss it here
to summarize, videostream was indeed removed from API, i also created a thread on synology forum, see link above eventually, someone from synology was also replying, he told the community, that the documentation was just removed from API, to force users to use new the API it should still work in 8.2.3 , he told us, but seems it was a bug after all, and should be fixed in 8.2.4 but then again, he also told us, that videostream will eventually go away
another approach is indeed rtsp, but according to @balloob its not ready yet , still in prototype :
https://github.com/home-assistant/home-assistant/issues/20595#issuecomment-459226551
Well as you did read on the thread what we CAN do while waiting is run a snapshot ever second to make a "fake" stream.
I tested with extracting the URL as the API uses and yeah its not working so nothing we can do if its a synology bug unless we rewrite the synology component (or add another one) to use ffmpeg. Since they use different inheritance components im not sure if the best thing would be to decide to throw the original implementation and go all in on ffmpeg, make an option to choose what method to use or create a seperate platform for each.
Things also depends a lot of what get approved by HA, and if the developer of the synology component is actually working on it, then it would be no point for me to start doing this.
Unless someone can show the correct API url for getting the old stream somehow I see no other option than what I mentioned above.
I dont maintain this repo nor the synology component so I have no idea what the developers are planning for the future
ok , clear, but maybe to fix this "issue" its best to use the GetLiveViewPath method ? i think thats for now to best to fix this platform, then HA als works like before, and this issue can be closed anway dont you think , @snjoetw ?
I see another component solved it lie this
` async def handle_async_mjpeg_stream(self, request): """Return an MJPEG stream."""
if self._stream_source == STREAM_SOURCE_LIST['snapshot']:
return await super().handle_async_mjpeg_stream(request)
if self._stream_source == STREAM_SOURCE_LIST['mjpeg']:
# stream an MJPEG image stream directly from the camera
websession = async_get_clientsession(self.hass)
streaming_url = self._camera.mjpeg_url(typeno=self._resolution)
stream_coro = websession.get(
streaming_url, auth=self._token, timeout=TIMEOUT)
return await async_aiohttp_proxy_web(
self.hass, request, stream_coro)
# streaming via ffmpeg
from haffmpeg import CameraMjpeg
streaming_url = self._camera.rtsp_url(typeno=self._resolution)
stream = CameraMjpeg(self._ffmpeg.binary, loop=self.hass.loop)
await stream.open_camera(
streaming_url, extra_cmd=self._ffmpeg_arguments)
try:
return await async_aiohttp_proxy_stream(
self.hass, request, stream,
'multipart/x-mixed-replace;boundary=ffserver')
finally:
await stream.close()
`
I cant not update the synology component with this before the someone fast make a new api point here to get the rtsp-over-http and rtsp enpoints
Stream directly from camera? Not all cameras can do that, I have some cheap foscams too, they don't have mpjeg stream...
Stream directly from camera? Not all cameras can do that, I have some cheap foscams too, they don't have mpjeg stream...
Well we are talking about streaming from synology here so the camera is less important?
Ahh ok, my bad... Well, I am not that technical ;) Sorry
Ok I will take a look this weekend, but we need to fix the api endpoints here first or it won’t be accepted in home assistant
Have sent in a pull request to use the stream synology wants us to use. I dont have time to make multiple functions so someone feel free to make another function for backward compatible, but as of now the old method doesnt work anyway.
I have fixed the synology component of ha to support this (much faster streaming), but cant push that before I know if this get pulled or not.
@pergolafabio Could you try this custom component synology (custom_components/synology/camera.py) - this will pull a test build of this git with support for live streaming
Remember to set your cameras to never expire session: Surveilance station -> ip camera -> right click on camera -> share stream path -> set to never expire and save. Do this on all the cameras
I thought I'd give this a try too. The thumbnail loads fine, but the larger view still doesn't. I get the following in my logs: WARNING (MainThread) [haffmpeg.core] Timeout while waiting of FFmpeg
@alekslyse I tried the custom component and it worked for me most of the time. Occasionally I will also get the "Timeout while waiting of FFmpeg". I have 4 cameras that update fine, but one camera opens a big picture, but doesn't update. Everything is configured the same, so a little strange. The 4 cameras that work will occasionally only show a still as well and throw the error.
Ok, I try testing this evening... But why do we need to set the rtsp stream to forever? This was not needed before?
Those streams are needed to for other systems , because every stream strarts with a "syno" user and for every cam a different password... How is this now related to this new .py update?
Try this two options:
This custom gives ffmpeg 10 seconds to analyse: https://raw.githubusercontent.com/alekslyse/home-assistant/f88b7d28877e21d79a0c70e87854145e6e4ad604/homeassistant/components/camera/synology.py
This option give ffmeg 2,5 seconds to analyse: https://raw.githubusercontent.com/alekslyse/home-assistant/c9516ecd70bbaf4567a98db5163f0e55f25c765d/homeassistant/components/camera/synology.py
So try both and see if any of them helps the issue
@pergolafabio the stream itself is not forever, just the session. That way we dont have to regenerate a new session on every close.
ok, tried them both, seems also home_mode is present here :)
anyway, tried the first one, if i click on a camera, i even had a videostream now, this i never saw before, on the older component, the quality is not great, but i had a actual stream, the clicked on another camera, no stream, clicked it again, and there was stream
then tried the second one, but i seems less stable, needed to click a few times on the camera to get an stream
then loaded back the first one, but it was also not that stable at first... so i am sure witch one is better ... both editions gave me those warnings : 2019-03-09 15:39:02 WARNING (MainThread) [haffmpeg.core] Timeout while waiting of FFmpeg
Yeah the warning is about ffmpeg is not responding fast enough. Maybe need a bit investigation to make the stream a bit more seamless, but this seem like a home assistant timeout and not ffmpeg timeout
ok, tried it again, still dont know witch one is better between those 2 what should i see as a difference anyway ? i also notice , clicking between cameras is not a good idea :)
the difference is just what time I give ffmpeg to analyze the content. I was hoping setting it to 2,5 it will just send the stream into hass as hass waits for 5 seconds then gives up by standard. Sometimes it would take a bit more time to start a camera stream so trying to see how I can speed it up
ok, well, at first sight, i dont notice any difference, lets see what other are saying :) but i am already glad we are back in business :) will this merge with the current PR with home mode?
@pergolafabio Try this: https://raw.githubusercontent.com/alekslyse/home-assistant/synology/homeassistant/components/camera/synology.py
I gave it just 10 ms to autodetect and on local test it was very fast. Hopefully it could solve the timeout issue
hmm, in my case its worse :( it doesnt sometimes load the view now also saw this now WARNING (MainThread) [haffmpeg.core] FFmpeg isn't running!
strange, but i have to click the camera a few times now, and 1 out of 10 i see the feed
previous versions were better in my case
For me, the 2.5 second version would show the stream for a bit, but then it would just stop. The stream never loaded with the 10 second version. The latest version doesn’t seem to work correctly. It only shows a still and I get FFmpeg isn’t running!
in my logs.
Did you try the latest version?
Are you guys running ha on a pi?
Just for the experiment try this: Surveilance station -> ip camera -> right click -> edit -> live view settings on the left bar -> change the liew view to "high quality" , then select advanced and select live view "from camera" - reload hass and try that camera it will show unprocessed
I am running HassOS on esxi server
I am running HassOS on esxi server
That is so strange. I run it on an i3 nuc and I get the stream instantly in 1080p, but I set my cameras to 10fps as its no point with higher for security
Gonna try that experiment idea later
Yes I tried all three versions from today (2.5, 10, 10ms). I’m running on a VM on an Intel NUC. I’ll make that change and report back.
@alekslyse Changing the live view to pull directly from the camera did the trick. Now it works!!
@alekslyse Spoke too soon. Still get the occasional Timeout while waiting of FFmpeg, but less frequent.
@alekslyse Mine works 95% of the time now and I actually like the stream better than the old version. Thanks!
so what version are you using 1 , 2 or 3 ?
and also with stream directly from camera?
@pergolafabio after I changed to direct from camera, all the versions work.
hmm, not in my case, but maybe its because i dont have cameras that support mpeg ?
It's actually surprising to me that it works with direct from camera because if I pull the cameras directly from withing HA by using the ONVIF platform instead of Synology it works like crap. But maybe thats not strange at all, just me not understanding why probably :)
yeah, i also tried onvif before, was indeed crap , so not sure
be carefull, if you change the source (camera/surveillance) seems the rtsp stream resets to 1 hour, instead of forever ... so if you use those stream paths for other software , like me .. :)
@pergolafabio Mine stayed at forever. Just went back an checked.
Going direct from the camera didn't work for me. This is using the most recent code above. Then again my camera has a poor wifi connection so that could be the issue there.
Actually I see the following errors:
Error handling message: {'type': 'camera_thumbnail', 'entity_id': 'camera.door_bell', 'id': 26} 11:22 AM deps/lib/python3.7/site-packages/synology/api.py (ERROR)
Error handling message: {'type': 'camera_thumbnail', 'entity_id': 'camera.door_bell', 'id': 24} 11:22 AM deps/lib/python3.7/site-packages/synology/api.py (ERROR)
FFmpeg isn't running! 11:21 AM custom_components/camera/synology.py (WARNING)
for me the same, first and second version was working , not always, but better then 3th version changing to camera feed directly, didnt make any improvemt for me
After looking at the most up-to-date doc on the API https://global.download.synology.com/download/Document/DeveloperGuide/Surveillance_Station_Web_API_v2.8.pdf
I think the Video and Audio stream that was being used was removed? Maybe it was replaced with something else, but I am not familiar with their API.
This is was is called out in the linked doc