snjoetw / py-synology

Python API for Synology Surveillance Station
MIT License
30 stars 15 forks source link

Live stream video not working #9

Open w1ll1am23 opened 5 years ago

w1ll1am23 commented 5 years ago

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


Remove following methods
• SYNO.SurveillanceStation.AudioStream
◦ Stream
◦ Query
◦ Open
◦ Close
• SYNO.SurveillanceStation.VideoStream
◦ Stream
◦ Query
• SYNO.SurveillanceStation.Device
◦ ListVS
◦ ListCMS
◦ GetServiceSetting
• SYNO.SurveillanceStation.Streaming
◦ LiveStream
◦ EventStream
`
pergolafabio commented 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)

snjoetw commented 5 years ago

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

snjoetw commented 5 years ago

Ok ya it's broken with 8.2.3 :( I'll see if I can fix this but probably over the weekend

pergolafabio commented 5 years ago

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

pergolafabio commented 5 years ago

Ok, Synology replied again, they changed from did to cookie...

https://community.synology.com/forum/3/post/123094?reply=397574

arsaboo commented 5 years ago

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).

pergolafabio commented 5 years ago

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

arsaboo commented 5 years ago

Ok...hopefully, we can figure that out and start using it.

pergolafabio commented 5 years ago

@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

alekslyse commented 5 years ago

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

pergolafabio commented 5 years ago

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 ?

alekslyse commented 5 years ago

I see another component solved it lie this

` async def handle_async_mjpeg_stream(self, request): """Return an MJPEG stream."""

The snapshot implementation is handled by the parent class

    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

pergolafabio commented 5 years ago

Stream directly from camera? Not all cameras can do that, I have some cheap foscams too, they don't have mpjeg stream...

alekslyse commented 5 years ago

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?

pergolafabio commented 5 years ago

Ahh ok, my bad... Well, I am not that technical ;) Sorry

alekslyse commented 5 years ago

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

alekslyse commented 5 years ago

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.

alekslyse commented 5 years ago

@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

synology.zip

joshtbernstein commented 5 years ago

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

AZDane commented 5 years ago

@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.

pergolafabio commented 5 years ago

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?

alekslyse commented 5 years ago

Try this two options:

  1. This custom gives ffmpeg 10 seconds to analyse: https://raw.githubusercontent.com/alekslyse/home-assistant/f88b7d28877e21d79a0c70e87854145e6e4ad604/homeassistant/components/camera/synology.py

  2. 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.

pergolafabio commented 5 years ago

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

alekslyse commented 5 years ago

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

pergolafabio commented 5 years ago

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 :)

alekslyse commented 5 years ago

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

pergolafabio commented 5 years ago

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?

alekslyse commented 5 years ago

@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

pergolafabio commented 5 years ago

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

joshtbernstein commented 5 years ago

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.

alekslyse commented 5 years ago

Did you try the latest version?

alekslyse commented 5 years ago

Are you guys running ha on a pi?

alekslyse commented 5 years ago

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

pergolafabio commented 5 years ago

I am running HassOS on esxi server

alekslyse commented 5 years ago

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

pergolafabio commented 5 years ago

Gonna try that experiment idea later

joshtbernstein commented 5 years ago

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.

AZDane commented 5 years ago

@alekslyse Changing the live view to pull directly from the camera did the trick. Now it works!!

AZDane commented 5 years ago

@alekslyse Spoke too soon. Still get the occasional Timeout while waiting of FFmpeg, but less frequent.

AZDane commented 5 years ago

@alekslyse Mine works 95% of the time now and I actually like the stream better than the old version. Thanks!

pergolafabio commented 5 years ago

so what version are you using 1 , 2 or 3 ?

pergolafabio commented 5 years ago

and also with stream directly from camera?

AZDane commented 5 years ago

@pergolafabio after I changed to direct from camera, all the versions work.

pergolafabio commented 5 years ago

hmm, not in my case, but maybe its because i dont have cameras that support mpeg ?

AZDane commented 5 years ago

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 :)

pergolafabio commented 5 years ago

yeah, i also tried onvif before, was indeed crap , so not sure

pergolafabio commented 5 years ago

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 .. :)

AZDane commented 5 years ago

@pergolafabio Mine stayed at forever. Just went back an checked.

joshtbernstein commented 5 years ago

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)

pergolafabio commented 5 years ago

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