С# - потоковая передача экрана RTP

Я пытаюсь создать приложение для удаленного рабочего стола, в котором пользователь управляет своим компьютером из веб-приложения (как в logmein). Я добился этого с помощью C# для настольной части и NodeJS для веб-приложения, связь осуществлялась с помощью Socket.IO.

Моя первая попытка заключалась в том, чтобы сделать снимок экрана (всего 5 кадров в секунду), затем сравнить его с предыдущим снимком экрана и отправить только разницу в 8-битном цвете изображения, что привело к виртуальному рабочему столу с разрешением 800 * 600 - к первому изображению размером 100 КБ, затем от 5кб до 60кб в зависимости от изменений на экране.

С моей локальной машиной, управляющей виртуальным боксом, все было идеально, но когда я разместил веб-приложение онлайн, результат был катастрофическим, имело место невероятное отставание.

После нескольких исследований выяснилось, что такого рода приложение невозможно создать моим способом, и что мне приходится использовать протокол реального времени и вести прямую трансляцию с экрана клиента.

Мои вопросы:

  • Существуют ли готовые к использованию бесплатные RTP-библиотеки с открытым исходным кодом?

  • Как бы я передал прямую трансляцию из настольного приложения в веб-приложение, поскольку оно исходит со стороны клиента, у которого нет открытого порта? Я думал о другом настольном приложении, которое будет работать на сервере (размещающем веб-приложение), а затем снова будет транслировать тот же контент, а затем веб-приложение может просто отображать контент, подключившись к локальному IP-адресу с портом RTP, но это не решает загадку передачи прямой трансляции с клиента на сервер?


person Soufiane Touil    schedule 09.12.2017    source источник


Ответы (1)


Существуют ли готовые к использованию бесплатные RTP-библиотеки с открытым исходным кодом?

Как бы я передал прямую трансляцию из настольного приложения в веб-приложение, поскольку оно исходит со стороны клиента, у которого нет открытого порта? Я думал о другом настольном приложении, которое будет работать на сервере (размещая веб-приложение), а затем снова будет передавать тот же контент, а затем веб-приложение может просто отображать контент, подключаясь к локальному IP-адресу с портом RTP, но это не решает загадку передачи прямой трансляции с клиента на сервер?

Это было бы непросто. Все вышеперечисленные библиотеки следуют строгой спецификации RTSP/RTP, которая требует открытия порта прослушивания на стороне вашего хоста, который, несомненно, будет находиться за адресом nat. Я бы придерживался того, чтобы каждый конец был клиентом и доходил до вашего веб-сервиса. Вам также необходимо гарантировать доставку ваших кадров (поскольку вы доставляете инкрементные дельты), поэтому RTP (который традиционно используется вместо UDP) будет затруднительным.

Некоторые мысли

В конце концов, RTP — это просто стандартизированный 12-байтовый заголовок и правила пакетирования для сжатых носителей. Это не поможет с задержкой. Настоящим преимуществом будет возможность подключения к конечной точке в соответствии со стандартами, например, с помощью клиента VLC. .

Вы можете настроить свои сокеты, и это немного поможет, но, честно говоря, я бы сосредоточился на эффективности сжатия и захвата экрана. Какое сжатие изображения вы используете? VNC традиционно использовал zlib и некоторые другие файлы с потерями, такие как jpeg. Чем меньше вы получите эти кадры, тем лучше.

Еще одна мысль, которая может помочь: у Microsoft есть API для получения «грязных областей экрана». Он называется API дублирования рабочего стола и работает невероятно быстро. Однако это Win8 и выше.

Всего наилучшего в вашем начинании!

person Ken Forsythe    schedule 10.12.2017
comment
Большое спасибо за ваш ответ, но у меня есть несколько вопросов, когда вы сказали, что я бы придерживался того, чтобы каждый конец был клиентом и достигал «вверх» вашего веб-сервиса. , вы имеете в виду клиента, который захват скриншотов, достигающих веб-сервиса? Значит, нет RTP? И, основываясь на вашей второй части комментария, RTP не очень полезен, в задержке нет ничего особенного, верно? Так что я мог бы просто придерживаться моего текущего метода и сосредоточиться на сжатии/скриншотах? (следует) - person Soufiane Touil; 10.12.2017
comment
В настоящее время я делаю скриншоты вручную, так как я прочитал, что DPA не поддерживает Win7, и я не использую никаких методов сжатия, потому что я попробовал zlib, и сжатие заняло слишком много времени, и я попробовал lz4net, который был супер быстро, но результат меня не очень удовлетворил (изображение из 60 КБ становится 50 КБ), что вы думаете? - person Soufiane Touil; 10.12.2017
comment
Я забыл упомянуть, что мое текущее время выполнения снимка экрана составляет ~ 0,05 с. слишком много я верю, я попробую DDA - person Soufiane Touil; 10.12.2017
comment
Я имею в виду, что каждый конец вашего приложения (отправитель и зритель) может подключаться к какой-либо службе, работающей на общедоступном сервере. В этом нет необходимости, это была просто мысль, чтобы не беспокоиться об открытии прослушивающего сокета и беспокоиться о вашей публичной адресации. Вы можете остаться точь-в-точь, но адрес вашего сервера должен быть хорошо известен и доступен. - person Ken Forsythe; 10.12.2017
comment
zlib медленный, но он должен дать вам не менее 10 кадров в секунду, а может и больше, в зависимости от размера регионов. Сжатие JPEG будет намного быстрее и меньше. Например, VNC использует zlib и jpeg. - person Ken Forsythe; 10.12.2017
comment
На самом деле есть еще одна проблема: при использовании DDA требуется 0,23 с для захвата моего рабочего стола, на котором используются обои Full HD с разрешением 1920 * 1080 (3,5 МБ). Есть ли способ изменить обои или что-то еще, чтобы избежать этой проблемы? - person Soufiane Touil; 11.12.2017
comment
На самом деле, сжатие JPEG потрясающее: O Я только что попробовал, и оно уменьшает размер моего рабочего стола (с уровнем качества 10%) до 70 КБ, а с помощью lz4net - до 46 КБ за время 0,02 с. - person Soufiane Touil; 11.12.2017
comment
Да, это действительно так. И не все компрессоры JPEG одинаковы. На сегодняшний день самым быстрым из протестированных мной является libjpeg-turbo: libjpeg-turbo.org/About/TurboJPEG. - person Ken Forsythe; 11.12.2017