Live stream video not working

[w1ll1am23]

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]

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]

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]

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

[pergolafabio]

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]

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

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

[arsaboo]

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]

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]

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

[pergolafabio]

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

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]

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]

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]

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

[alekslyse]

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]

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

[alekslyse]

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]

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]

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

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]

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

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]

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]

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]

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]

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]

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]

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]

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

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]

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.