ойтишники есть?
88
16
как осуществляется передача потокового видео? передача изображения в фхд занимает канал практически на 45-50 мбит/с, если не использовать сжатие и тд, причем фреймрейт будет порядка нескольких кадров. понятно, что используется предсказание Фурье, поэтому передаются только те фрагменты, которые изменены(передача всей картинки условно говоря происходит только при первом подключении, а дальше приходят лишь "кусочки" обновлений).
вопрос в том, как это реализовано на серверной части? там просто высокие вычислительные мощности? тогда как осуществляется стрим с домашнего пк? есть кто-нибудь, кто шарит за эту тему?
для всяких "умников" - камера фхд разрешением обычно имеет фреймрейт порядка 20 кадров / с. причем обработка данного изображения является достаточно трудоемкой для проца, поэтому истории про то, что потоковое(!) видео в реалтайме по сети передавать легко - полный бред и не обсуждается.
апд. чекнул "народные" процы для стриминга. я могу понять райзен с 12 потоками. а вот интел с 6 не будет ли мягко говоря малопоточным?
Salovar сказал(а):↑как осуществляется передача потокового видео? передача изображения в фхд занимает канал практически на 45-50 мбит/с, если не использовать сжатие и тд, причем фреймрейт будет порядка нескольких кадров. понятно, что используется предсказание Фурье, поэтому передаются только те фрагменты, которые изменены(передача всей картинки условно говоря происходит только при первом подключении, а дальше приходят лишь "кусочки" обновлений).
вопрос в том, как это реализовано на серверной части? там просто высокие вычислительные мощности? тогда как осуществляется стрим с домашнего пк? есть кто-нибудь, кто шарит за эту тему?
для всяких "умников" - камера фхд разрешением обычно имеет фреймрейт порядка 20 кадров / с. причем обработка данного изображения является достаточно трудоемкой для проца, поэтому истории про то, что потоковое(!) видео в реалтайме по сети передавать легко - полный бред и не обсуждается.
апд. чекнул "народные" процы для стриминга. я могу понять райзен с 12 потоками. а вот интел с 6 не будет ли мягко говоря малопоточным?
Нажмите, чтобы раскрыть...Никто не обрабатывает изображения на проце. Ты от картинки 480р фурье будешь брать за время порядка 10^-1 (то есть доли секунды), что уж говорить про фхд 60 фпс. Все пободные вычисления (да и вообще все трудоёмкие вычисления) делают на специально предназначенном оборудовании - на видеокартах. Потому что именно они заточены исключительно под вычисления с плавающей точкой (бтв фурье, а мы говорим про БПФ, это относительно быстрая операция - nlogn)
Условно говоря, видеокарта - это узконаправленный математик, который идеально делает свою работу, а ЦП это умник, который делает все подряд, но все посредственно
TheTrueBibika сказал(а):↑Никто не обрабатывает изображения на проце. Ты от картинки 480р фурье будешь брать за время порядка 10^-1 (то есть доли секунды), что уж говорить про фхд 60 фпс. Все пободные вычисления (да и вообще все трудоёмкие вычисления) делают на специально предназначенном оборудовании - на видеокартах. Потому что именно они заточены исключительно под вычисления с плавающей точкой (бтв фурье, а мы говорим про БПФ, это относительно быстрая операция - nlogn)
Условно говоря, видеокарта - это узконаправленный математик, который идеально делает свою работу, а ЦП это умник, который делает все подряд, но все посредственно
Нажмите, чтобы раскрыть...ты путаешь фиолетовое с теплым(или я недостаточно понятно выразился, так как ночь не спал). есть рабочий стол. на него картинку выводит карточка, никто не спорит. а мне надо рабочий стол передать на другой пк. я ж не могу перехватить видеопоток? или могу?
Salovar сказал(а):↑как осуществляется передача потокового видео?
Нажмите, чтобы раскрыть...Video socket
Юзер запрашивает доступ к видео, ты отправляешь первый пакет, если пришёл успешно - устанавливается соединение и с бека тебе приходят пакеты, что кладутся у тебя в буфере до заполнения, там всё гораздо проще, чем кажется
Salovar сказал(а):↑передача изображения в фхд занимает канал практически на 45-50 мбит/с
Нажмите, чтобы раскрыть...Нет, fullhd даже на твиче занимает от силы 5 мбит/с
cryptomagnat322 сказал(а):↑интел i7 8 потоков стримил в 2.5 к разрешении 60фпс без особых проблем, не знаю какие там проблемы с производительностью могут быть
Нажмите, чтобы раскрыть...я сейчас паралелю обработку картинки в 12 потоков, тем не менее у меня не выходит даже близко 60 фпс. я нигде не вижу описания алгоритма, что используют для этого. единственное объяснение - видео буферизируется, таким образом получается вся нагрузка ложится на проц, а в сеть падает уже сжатый поток. так получается?
Александр сказал(а):↑Video socket
Юзер запрашивает доступ к видео, ты отправляешь первый пакет, если пришёл успешно - устанавливается соединение и с бека тебе приходят пакеты, что кладутся у тебя в буфере до заполнения, там всё гораздо проще, чем кажется
Нет, fullhd даже на твиче занимает от силы 5 мбит/с
Нажмите, чтобы раскрыть...это ты про rdp говоришь? судя по описанию он передает что угодно, кроме изображения. про видео сокет погуглю, сыпыс
Salovar сказал(а):↑ты путаешь фиолетовое с теплым(или я недостаточно понятно выразился, так как ночь не спал). есть рабочий стол. на него картинку выводит карточка, никто не спорит. а мне надо рабочий стол передать на другой пк. я ж не могу перехватить видеопоток? или могу?
Нажмите, чтобы раскрыть...Почему не можешь? Берёшь картинку своего экрана и передаёшь как условный буфер, если соединение разорвалось - отправляешь полный кадр заново
Я хз, я не умею объяснять
Александр сказал(а):↑Нет, fullhd даже на твиче занимает от силы 5 мбит/с
Нажмите, чтобы раскрыть...читай внимательно. речь за необработанное сырое видео. там будет ОЧЕНЬ много
Александр сказал(а):↑Почему не можешь? Берёшь картинку своего экрана и передаёшь как условный буфер, если соединение разорвалось - отправляешь полный кадр заново
Я хз, я не умею объяснять
Нажмите, чтобы раскрыть...ну воспользуйся калькулятором. картинка 1920х1080 по 3 байта на пиксель(классический ргб). получается 1 кадр почти 6 Мб. не бит, а байт. буферизация иначе устроена.
Александр сказал(а):↑Video socket
Юзер запрашивает доступ к видео, ты отправляешь первый пакет, если пришёл успешно - устанавливается соединение и с бека тебе приходят пакеты, что кладутся у тебя в буфере до заполнения, там всё гораздо проще, чем кажется
Нет, fullhd даже на твиче занимает от силы 5 мбит/с
Нажмите, чтобы раскрыть...а к чему ты написал про видео сокет? я не вижу в сети никакой информации на эту тему.
Salovar сказал(а):↑ты путаешь фиолетовое с теплым(или я недостаточно понятно выразился, так как ночь не спал). есть рабочий стол. на него картинку выводит карточка, никто не спорит. а мне надо рабочий стол передать на другой пк. я ж не могу перехватить видеопоток? или могу?
Нажмите, чтобы раскрыть...А ты думаешь, ты передашь матрицу пикселей (картинку напрямую)? Или после захвата, перед непосредственно передачей, её как-то обрабатывают, и передают не в прямом виде?
А после принятия, соответственно, её обратно надо превратить в картинку. Кто это делает?
Так что насчёт фиолетового не согласен - я отвечал по теме. Просто сам вопрос у тебя очень неконкретный и размытый, общий. А как известно, без ТЗ - получается ХЗ
TheTrueBibika сказал(а):↑А ты думаешь, ты передашь матрицу пикселей (картинку напрямую)? Или после захвата, перед непосредственно передачей, её как-то обрабатывают, и передают не в прямом виде?
А после принятия, соответственно, её обратно надо превратить в картинку. Кто это делает?
Так что насчёт фиолетового не согласен - я отвечал по теме. Просто сам вопрос у тебя очень неконкретный и размытый, общий. А как известно, без ТЗ - получается ХЗ
Нажмите, чтобы раскрыть...с тобой все в порядке? я могу передавать картинку как угодно. я спрашиваю конкретно про алгоритмы, которые реально используются.
TheTrueBibika сказал(а):↑А ты думаешь, ты передашь матрицу пикселей (картинку напрямую)? Или после захвата, перед непосредственно передачей, её как-то обрабатывают, и передают не в прямом виде?
А после принятия, соответственно, её обратно надо превратить в картинку. Кто это делает?
Так что насчёт фиолетового не согласен - я отвечал по теме. Просто сам вопрос у тебя очень неконкретный и размытый, общий. А как известно, без ТЗ - получается ХЗ
Нажмите, чтобы раскрыть...все, что ты описываешь очень сильно влияет на скорость. если сжимать, разжимать теряется качество + фреймрейт. мне кажется, что там что-то другое.
Salovar сказал(а):↑читай внимательно. речь за необработанное сырое видео. там будет ОЧЕНЬ много
Нажмите, чтобы раскрыть...Ок
Salovar сказал(а):↑ну воспользуйся калькулятором. картинка 1920х1080 по 3 байта на пиксель(классический ргб). получается 1 кадр почти 6 Мб. не бит, а байт. буферизация иначе устроена.
Нажмите, чтобы раскрыть...Ок
Salovar сказал(а):↑а к чему ты написал про видео сокет? я не вижу в сети никакой информации на эту тему.
Нажмите, чтобы раскрыть...Так ты писал, как это сделать, а не то, как передать rawfullhd в первозданном виде. В принципе твой пост как раз об этом, а предсказывать мысли не умею
Обычный сокет, это может быть как дефолт сокет, так и флеш сокет, да насрать вообще, выбирай, что тебе по душе. Видео сокет - основное понятие, как должно вести себя сокет соединение
Первый пакет - коннект - получаешь, разрыв - первый пакет - коннект, получаешь
Александр сказал(а):↑Ок
Ок
Так ты писал, как это сделать, а не то, как передать rawfullhd в первозданном виде. В принципе твой пост как раз об этом, а предсказывать мысли не умею
Обычный сокет, это может быть как дефолт сокет, так и флеш сокет, да насрать вообще, выбирай, что тебе по душе. Видео сокет - основное понятие, как должно вести себя сокет соединение
Первый пакет - коннект - получаешь, разрыв - первый пакет - коннект, получаешь
Нажмите, чтобы раскрыть...я понимаю о чем ты говоришь, когда пишешь про разрыв. в моем случае это не нужно реализовывать. там немного другая структура в принципе. про сокеты так и не понял. если я пишу на условном qt, сам передаю посылки и определяю их формат, то каким образом можно сделать какое-то деление на дефолт, флеш и тд? у меня ощущение, что ты какими-то вебовскими терминами оперируешь, где в каком-то фреймворке что-то такое реализовано для каких-то решений. по крайней мере у меня это гораздо ближе к абстракции, чем то, о чем ты пишешь.
получается, если делать по уму, то самый оптимальный вариант:
скриншот экрана в потоках разбивается на секции, каждый поток перекидывает изменение изображения относительно предыдущего, клиент обновляет блочками изображения, при этом подтягивается курсор из апи системы. или я что-то пропустил?
есть ли смысл заморачиваться с рескейлом? потому что такие вещи на слабых пк(относительно низкая частота + небольшое количество потоков) должно сильно загружать систему.
Salovar сказал(а):↑я понимаю о чем ты говоришь, когда пишешь про разрыв. в моем случае это не нужно реализовывать. там немного другая структура в принципе. про сокеты так и не понял. если я пишу на условном qt, сам передаю посылки и определяю их формат, то каким образом можно сделать какое-то деление на дефолт, флеш и тд? у меня ощущение, что ты какими-то вебовскими терминами оперируешь, где в каком-то фреймворке что-то такое реализовано для каких-то решений. по крайней мере у меня это гораздо ближе к абстракции, чем то, о чем ты пишешь.
получается, если делать по уму, то самый оптимальный вариант:
скриншот экрана в потоках разбивается на секции, каждый поток перекидывает изменение изображения относительно предыдущего, клиент обновляет блочками изображения, при этом подтягивается курсор из апи системы. или я что-то пропустил?
есть ли смысл заморачиваться с рескейлом? потому что такие вещи на слабых пк(относительно низкая частота + небольшое количество потоков) должно сильно загружать систему.
Нажмите, чтобы раскрыть...Делал года 4 назад решение по клауд геймингу, не думаю, что в сфере много поменялось. У тебя плюс минус есть такие ветки выбора решения:
1) Если видео риал-тайм, но допустима задержка со стороны получателя (например, твич), то тебе надо через ffmpeg нарезать под протокол HLS на сервере и дальше отдать мета файл в браузер клиента и встроенную читалку HLS.2) Если видео жесткий риал-тайм, например надо стримить кс го и ждать инпута движения от клиента и быстро реагировать, то можешь взять вот это решение https://github.com/moonlight-stream. Это открытый протокол от NVIDIA. Там уже встроен хардварный энкодинг и декодинг, битрейт настраиваемый. Если надо будет это стримить в браузер, то мы использовали WebRTC, но там много геморра, зато честный P2P
Emulebest сказал(а):↑Делал года 4 назад решение по клауд геймингу, не думаю, что в сфере много поменялось. У тебя плюс минус есть такие ветки выбора решения:
1) Если видео риал-тайм, но допустима задержка со стороны получателя (например, твич), то тебе надо через ffmpeg нарезать под протокол HLS на сервере и дальше отдать мета файл в браузер клиента и встроенную читалку HLS.2) Если видео жесткий риал-тайм, например надо стримить кс го и ждать инпута движения от клиента и быстро реагировать, то можешь взять вот это решение https://github.com/moonlight-stream. Это открытый протокол от NVIDIA. Там уже встроен хардварный энкодинг и декодинг, битрейт настраиваемый. Если надо будет это стримить в браузер, то мы использовали WebRTC, но там много геморра, зато честный P2P
Нажмите, чтобы раскрыть...большое спасибо
Тема закрыта
-
ЗаголовокОтветов ПросмотровПоследнее сообщение
-
Сообщений:2
Просмотров:1
-
Сообщений:10
Просмотров:13
-
Сообщений:10
Просмотров:12
-
Взгляд_на2000ммр 17 Jun 2024 в 16:23Сообщений: 14 17 Jun 2024 в 16:23
Сообщений:14
Просмотров:17
-
Сообщений:1
Просмотров:0