Отписался в личку ... но для всех озвучу "мысль" ... В действительности данный пров дает 4K в h.264 в HTTP Live Streaming 2nd Edition with floating-point EXTINF duration values, при этом, как я понимаю, маленько некорректно выписан master-playlist.m3u8 (RFC 8216 - HTTP Live Streaming), и, как следствие, на наших ULTIMO 4K это не работает ни в одном из плееров (exteplayer3 игнорит эту ошибку, но не работает на Ultimo4K c UHD , а GstPlayer тупо ждет master-playlist, а получает ts-сегменты ) ... но данная "нечисть" натолкнула меня на мыслишку наваять элементарный проксик из 10-ка строк на питоне .... Некий отдельный сервис который будет "крутиться" на ресе и все плейлисты запрашивать не напрямую у прова, а у данного проксика ... Он будет "прозрачно" ретранслировать запрос на прова, а ответы (сегменты потока) - прогонять через на ffmpeg и и отдавать плееру уже транскодированный поток в нужном и понятном виде ... Я это уже делал , например тут - HTTPAceProxy/acehttp.py at master · pepsik-kiev/HTTPAceProxy · GitHub 
Вопрос только по "ресам-дохликам" ... они "на лету" могут не потянуть транскодирование , а вот на arm или arm64 все должно работать ну если не перегонять 1080 в UHD на лету ))))