RTC Stream on Amazon Fire Tablets via Fully Kiosk

[dpthomas83]

Hi,

Ive read on various forums that Fire HD's will support Web RTC, although there might be some upgrading of the base Fire OS to ensure webview is up to date.

For the life of me i cant get the stream to web if i set them to RTC in the custom component.

I have this configured in a dashboard as an example

- type: custom:layout-card
            style:
              left: 40%
              top: 68%
              width: 35%
            cards:
              - type: custom:webrtc-camera
                url: rtsp://xxx:xxx@some_super_secret_ipaddress/stream1
                show_name: false
                show_state: false
                muted: true
                mode: mse

This plays the stream fine, but its not very reliable, and will basically break at somepoint between 60 seconds and 10 minutes. If i set it to webrtc, it just doesnt load the stream on the Fire Tablet ( latest gen 8 ones, only bought a couple of days ago, as i was convinced the one i was running it on, which is 2 years old was the problem ), however the stream does load perfectly fine on the PC via Chrome.

Camera's are TP Tapo's C320's.

I guess a couple of questions, specifically when considering Fire tablets, and Fully Kiosk ( although really its the base Web View im guessing that really causes trouble )

Are there any tips for making the MSE streams more reliable, or what am i missing to make WebRTC working on it.

This thing is soooo nearly perfect for a super cost effective dashboard, but i wold really want the realtime video feed to work, it (a) it would be boring without it, and (b) its kind of no good if its got a 10-20 second delay using the historic picture-card method.

Apologies if ive missed useful debug info, ill happily provide if its helpful at this stage.

Thanks a million

[claytonium13]

Maybe try MSE instead? MSE works on my Lenovo Smart Clock 2 dashboards but WebRTC does not. Like this:

type: 'custom:webrtc-camera'
url: 'rtsp://rtsp:12345678@192.168.1.123:554/av_stream/ch0'
mode: mse

[EHLO1]

I ran into similar issues, as I have a 2020 FireHD 8, which is mildly less capable, seeing as the version of WebView/Android is older on the older model. This was a very challenging problem to solve, as I kept running to various issues from the WebRTC stream working for the FireHD, but not iOS devices (or vice versa). There were issues with increased latency, intermittent drops of streaming, and more. What it came down to is the camera I am using has a dual stream, and the primary (main) stream resolution was too high to be displayed consistently on the FireHD. I combed AlexxIT's GitHub and looked at all open and closed issues, seeing if I could piece together what other people were doing until I finally found something that worked.

A few disclaimers:

1. I am using a Reolink E1 Zoom
2. I am very sure that my configuration is not optimized and I am working to improve it
3. AlexxIT + the Contributors have made some crazy upgrades and added new features that I'm just now looking through
4. I chose the "Basic users" option to have the WebRTC HACS addon manage go2rtc for me

I'm not sure if you've accessed the go2rtc web interface, but it's incredibly useful for both configuration and troubleshooting. For me, the secret of "scaling" the main RTSP stream resolution down was to use the integrated ffpmeg module. This did add about a second of latency, but overall, the total latency is about 2 seconds, which is pretty good!

In the go2rtc console, this is my example configuration:

api:
  password: superpass
  username: ausername
  origin: "*"
rtsp:
  password: superpass
  username: ausername
  listen: ":8554"
webrtc:
  listen: ":8555"
  candidates:
    - 192.168.1.2:8555
    - 127.0.0.1:8555
    - localhost:8555
streams:
  hank_cam: 
    - rtsp://ausername:superpass@192.168.1.250:554/h265Preview_01_main
    - ffmpeg:hank_cam#audio=opus
  hank_cam2: 
    - rtsp://ausername:superpass@192.168.1.250:554/h264Preview_01_sub
    - ffmpeg:hank_cam#audio=opus
  hank_cam3: 
    - ffmpeg:rtsp://ausername:superpass@192.168.1.250:554/h264Preview_01_main#raw=-vf "fps=20,scale=-1:1080"#video=h264#audio=opus

You can ignore hank_cam and hank_cam2 under the streams section, as I use those for testing. If you look at the hank_cam3 item, you see this crazy setup that basically forces the RTSP stream to be processed by ffpmeg, where ffpmeg then scales the stream down to 1080p at 20 fps, uses h264 for video and opus for audio. There are other options, and you should definitely review all available documentation in the repo plus the go2rtc repo.

In the HASS card, I opted for pinch-to-zoom for the whole dang dashboard over running kiosk mode. I had issues with kiosk mode and I just couldn't be bothered to set that up, BUT, my card configuration relies on pinch-to-zoom being enabled in the Home Assistance Companion app settings, the "layout-card" HACS addon, and the "card-mod" HACS addon. My goal was to fit the stream into a single card that would take up the whole dashboard, without a scroll bar.

This is my configuration for the dashboard tab: View type: Grid (layout-card)

grid-rows: auto
grid-template-columns: 5% 90% 5%
grid-template-areas: |
  "c1 c2 c3"

This is the configuration for the card containing the stream:

type: custom:layout-card
layout_type: custom:grid-layout
cards:
  - type: custom:webrtc-camera
    url: hank_cam3
    background: true
    mode: webrtc
layout: {}
view_layout:
  grid-area: c2

Doing it this way allowed me to force WebRTC for all devices, and contain it easily within the card/tab without having a scroll bar because the card size was bigger than the display area.

Last thing I want to say is that there are a lot of ports involved here, so don't forget to make sure they're configured on your host correctly so you can access them. Your specific RTSP stream URL format will likely differ from mine.

I hope that helps point you in a better direction! Remember that I am currently working on updating my config based on the new features that have been added, so there may be a much easier way!

[dpthomas83]

EHLO1 - wow, thanks for such a detailed response, truly appreciated.

Im going to have a play with this today, and see where i land. I actually did start to go down a bit of a path of lowering the source stream resolution ( the Tapo's offer a SD stream and an HD stream ). I thought that had cracked it initially, as it seemed more stable, but alas, eventually it returned to the normal state of freezing after a while.

Ive actually gone back to just using the picture element card for the moment, as this is proving 100% stable, and the delay which im sure i remember being about 5-6 seconds, actually wasnt too bad at about 3 seconds, but im prepared to do the work, testing to get that delay down using this project.

[AlexxIT]

I have no Fire devices and no recommendations on how to make the stream work well on these devices