я не думаю что растояние важно… скорее без контактная зарядка… пусть будет провод с магнитиком
ну а то что надо помнить про росыпь гаджетов…
нестрашно…
их еще и потерять можно, тоже помнить надо…
с без проводными наушниками — никаких проблем :-) летал по 16-18 часов…
у меня в довесок акумулятор… так я его иногда даже забываю достать… :-)
если предположить что за безпроводными интерфейсами будущее
— связь или WiFi (в том же самолете во время полета) или сотовая
— звук Bluetooth
— заряд
то следущим шагом будет не перевод iPhone на USB-C
а полный отказ от каких либо физическим конекторов :-)
e-Sim только довершает картину :-)
смею предположить, что преполагают использование без проводных наушников в полете… если это AirPod то отлучившись в туалет за 15 минут от их родного кэйса зарядятся на еще 3 часа: о) (сам еше не проверял но верю) а мои over ear с шумодавом еще ни разу за полет не разряжались… как в прочем и телефон в режиме прослушивания музыки… из 9ти часов… около 5-6 использования… мало того… как то умудрился фильм посмотреть… и тоже заряда хватило… в самолетном режиме разряжается заметно медленнее!
Наверное я не знаю всех фитчь моих IDE… (сарказм) но из тех что знаю пользуюсь 80%…
разные конфиги для языков… прекрасно работает в IDE
минимальная поддержка синтаксиса для экзотики настраиваеться в 2 клика мышкой…
мультиязычные проэкты прекрасно подерживаються…
я пользуюсь в основном eclipse и VSCode…
работа без мышки… абсолютное дело вкуса… и привычки…
немного умею работать в VIM… и согласен с предыдушей статьей про режимы… именно из них вытекают все особенности VIMa
а в IDE для меня киллер фитча это дебагирование… задал конфигурацию, нажал кнопку мыши и все сразу на экране…
и код и переменные и логи… и терминал если надо…
и если забыл скомпилировать то все за тебя сделали…
и если забыл за аплоадить то тоже
и все из коробки…
При этом, в файле записи mp4 мы имеем чудесные фреймы разного размера, точнее сначала последовательность одного размера 640x480, потом другого 320x240, и т.д. Такие фокусы замечательно отыгрывает например VLC
из этого вашего описания я сделал вывод, что один и тот же записаный файл проигрывает-ся offilne с помощью VLC без зеленых областей, а тот же файл переданный по сети да с зелеными…
из этого следует что в файле несколько потоков.
это может быть в 2х вариантах:
1) 2 независимых паралельных H.264 потока, можно посмотреть в МП4 и дампить оба по отдельности в 2 МП4 файла
2) 1 поток no SVC
Насколько нам известно, WebRTC в данный момент не поддерживает SVC, по крайней мере для кодека H.264.
зависит от конкретной имплиментации WebRTC сервера
да, point2point между Chrome броузером нет подежки
но если сервер, то все прекрасно поддерживаеться
Ну и SVC имеет слабое отношение к записи стримов и воспроизведению VOD в данном контексте.
в данном контексте, конечно…
но SVC не ограничен использованием в видео конференциях, это всего лишь набор инструментов кодирования, а как их использовать дело часное
А вот не факт. В WebRTC, Sender динамически меняет разрешение потока, основываясь на RTCP фидбеках. См. график. Сначала разрешение, при стриминге с iOS приложения, было 640x480, потом упало до 320x240.
конечно RTCP играет тут контрольную роль… НО если клиент по SDP не разрешил опускать разрешение то сервер не должен.
правильно составить SDP еще та проблема.
по умолчанию предполагаеться что если клиент готов принять определенный формат, то это максимальный, а значит все что меньше разрешено.
надо отдельно указать что только и только его…
в конечно итоге дело ваше как вы расходуете ресурсы… хотите транскодировать, кстати что ухудшает качество… и вам кажеться так проше, ваше право
это называеться «Scalable Video». К WebRTC обычно еще преполагаеться SDP — Session Description protocol, в котором и можно указать какие потоки клиент готов принимать…
если клиент сообщяет что готов к 2м потокам, как в вашем случае, подрозумеваеться
что клиент будет скейлить на весь экран сам, если сервер решит переслать меньшую резолюцию. Или же клиент сообщает что готов принимать только одну, в вашем случае 640х480, то сервер пришлет только ее!
Scalable Video родилось что бы сэкономить транскодинг на сервере
ну а то что надо помнить про росыпь гаджетов…
нестрашно…
их еще и потерять можно, тоже помнить надо…
у меня в довесок акумулятор… так я его иногда даже забываю достать… :-)
если предположить что за безпроводными интерфейсами будущее
— связь или WiFi (в том же самолете во время полета) или сотовая
— звук Bluetooth
— заряд
то следущим шагом будет не перевод iPhone на USB-C
а полный отказ от каких либо физическим конекторов :-)
e-Sim только довершает картину :-)
разные конфиги для языков… прекрасно работает в IDE
минимальная поддержка синтаксиса для экзотики настраиваеться в 2 клика мышкой…
мультиязычные проэкты прекрасно подерживаються…
я пользуюсь в основном eclipse и VSCode…
работа без мышки… абсолютное дело вкуса… и привычки…
немного умею работать в VIM… и согласен с предыдушей статьей про режимы… именно из них вытекают все особенности VIMa
а в IDE для меня киллер фитча это дебагирование… задал конфигурацию, нажал кнопку мыши и все сразу на экране…
и код и переменные и логи… и терминал если надо…
и если забыл скомпилировать то все за тебя сделали…
и если забыл за аплоадить то тоже
и все из коробки…
из этого вашего описания я сделал вывод, что один и тот же записаный файл проигрывает-ся offilne с помощью VLC без зеленых областей, а тот же файл переданный по сети да с зелеными…
из этого следует что в файле несколько потоков.
это может быть в 2х вариантах:
1) 2 независимых паралельных H.264 потока, можно посмотреть в МП4 и дампить оба по отдельности в 2 МП4 файла
2) 1 поток no SVC
зависит от конкретной имплиментации WebRTC сервера
да, point2point между Chrome броузером нет подежки
но если сервер, то все прекрасно поддерживаеться
в данном контексте, конечно…
но SVC не ограничен использованием в видео конференциях, это всего лишь набор инструментов кодирования, а как их использовать дело часное
конечно RTCP играет тут контрольную роль… НО если клиент по SDP не разрешил опускать разрешение то сервер не должен.
правильно составить SDP еще та проблема.
по умолчанию предполагаеться что если клиент готов принять определенный формат, то это максимальный, а значит все что меньше разрешено.
надо отдельно указать что только и только его…
в конечно итоге дело ваше как вы расходуете ресурсы… хотите транскодировать, кстати что ухудшает качество… и вам кажеться так проше, ваше право
если клиент сообщяет что готов к 2м потокам, как в вашем случае, подрозумеваеться
что клиент будет скейлить на весь экран сам, если сервер решит переслать меньшую резолюцию. Или же клиент сообщает что готов принимать только одну, в вашем случае 640х480, то сервер пришлет только ее!
Scalable Video родилось что бы сэкономить транскодинг на сервере