El problema también es el software que muchas veces está programado en lenguajes de alto nivel (con muchas capas de abstracción por debajo) ineficiente y lento, desaprovechando el hardware. Tanto en Android como en las Smart TV.latencia y buffer
hazlo, graba un video con un zapping instantaneo conectado por fibra y a ver el resultado,
ahí me lo creeré y te daré la razón
Por ejemplo Freetube está programado en javascript.
Kodi en Java para android tampoco es algo eficiente que vaya directamente a máquina, además de usar sus componentes internos para addons etc.
Algo eficiente y rápido sería OMXPlayer en una raspberry pi (en c++, pasando directamente el contenido de video al decodificador de video y de ahí a la pantalla)
Por otro lado, para empezar a recibir contenido con HLS es necesario 2 conexiones TCP que hay que establecer (con sus respectivos handshakes etc, se suma la latencia en cada dirección, 2 veces).
La forma más rápida y eficiente sería recibir por UDP los primeros frames enteros con una raspberry pi y pasarlo con Omxplayer al monitor directamente. Ahí el retardo debería ser de pocas decenas de milisegundos. Y luego ya se podría cambiar a HLS o lo que se quiera.
La prueba de cómo de lento puede ser el software/hardware y afectar al streaming, es simplemente probar a cambiar la reproducción de un video .mp4 local, el retardo que tenga en eso, no se va a poder mejorar en streaming con otra app similar.
En una raspberry con omxplayer es cero, pero en una android box barata con apps en lenguajes de alto nivel no es cero.