Большое спасибо за комментарии про termination и про снижение полезной утилизации — внёс правки. Шлю вам лучи добра за внимательность и уделенное время, благодаря вам хороший материал стал ещё лучше.
я бы предположил, что ответ будет скорее у нейробиологов :) Хотя можно поразмыслить вслух и сказать, что нейронная сеть в вашем мозге имела очень внушительный датасет, что и позволило ей в итоге работать так быстро и качественно. Возможно, вы давно начали очень внимательно наблюдать за людьми в реальной жизни и за персонажами в кино и театре.
Конкретно в этом случае – да, есть проблемы, мы с дизайнерами и фронтами соглашаемся с вами. Line height у подписей великоват, да и в целом по оси Y перегрузка.
Однако вырванная из контекста одна форма – сама по себе не кошмар. Даже с текущими проблемами она хорошо решает свою задачу. Но мы не берем этот факт как оправдание, чтобы ничего не делать :) Наоборот, впереди еще будут правки, продукт будет улучшаться.
Про реалтайм было невнято написано – спасибо, исправил.
Наконец, рабочая группа WebRTC тоже смотрит в сторону QUIC (плюс см. QUIC API), так что в обозримом будущем реалтайм видео/аудио будет ходить по QUIC вместо RTP/RTCP.
Про производительность железа – хороший вопрос. Думаю, что ответ будет «это зависит от оптимизации этих самых софтверных балансировщиков». Например, упомянутый Katran называет себя высокопроизводительным.
ну почему сразу «треш»? Если читатель никогда не работал со звуком, то из статьи можно почерпнуть полезного на эту тему. То есть у этой истории есть польза. При этом вы правы, матрица действительно странная. Как и размер искомого датасета.
если взять «просто облако в ваккууме», то оно скорее всего будет справляться с возложенными задачами до определенного момента, пока не понадобится нарастить вычислительные мощности. То есть либо задуматься о развертывании доп.инстансов, либо часть нагрузки отдать на свою инфраструктуру, и т.д.
Serverless подход снимает эту и другие головные боли. Под ваши вычисления динамически выделяется столько мощностей, сколько нужно. То есть бизнес, который пользуется serverless-платформой, не озадачивается вопросом масштабирования инфраструктуры, за него это делает платформа.
ссылка ведет на ту часть статьи, где указана расшифровка аббревиатуры:
Communications platform as a service (CPaaS)
A CPaaS is a cloud-based platform that enables developers to add real-time communications features (voice, video, and messaging) in their own applications without needing to build backend infrastructure and interfaces.
Our testing shows AV1 surpasses its stated goal of 30% better compression than VP9, and achieves gains of 50.3%, 46.2% and 34.0%, compared to x264 main profile, x264 high profile and libvpx-vp9, respectively.
То есть была задана планка – достигнуть/превысить 30% по сжатию и AV1 преодолел ее. Внесли правки, благодарю.
вряд ли AV1 более/менее чувствителен к потере key frames, но сам факт того, что в нем имплементировано продвинутое внутрикадровое прогнозирование, дает уменьшение размера как key frames, так и промежуточных кадров. Разузнать подробности про борьбу с потерями – звучит как интересная идея, взяли на заметку.
Строго говоря, вы конечно правы, т.к. формально у всех есть рантайм)) Имелось в виду скорее то, что GO не требует тяжеловесный рантайм (привет java и python), он скомпилирован статически, минимум зависимостей от ОС.
На этапе разработки – возникали :) поэтому постили мэйнтэйнерам баги, получали ответы. Мы бы не стали выкатывать в прод решение, которое портит данные.
Потому что PHP не справлялся с объемами. А при в общем равной скорости обработки листов JAVA и GO, контейнеры на GO весят раз в 10 меньше, чем JAVA; с учетом, что мы планируем в дальнейшем использовать Kubernetes Engine, это вполне оправданный выбор. По этой же причине сделали в формате микросервиса.
Взяли максимум, прогнали в очередной раз – xlsx размером 300.000 строк читается и обходится за 18 секунд.
P.S. прошу прощения, что не смог ответить в понедельник.
Однако вырванная из контекста одна форма – сама по себе не кошмар. Даже с текущими проблемами она хорошо решает свою задачу. Но мы не берем этот факт как оправдание, чтобы ничего не делать :) Наоборот, впереди еще будут правки, продукт будет улучшаться.
Спасибо за фидбэк, это всегда ценно.
Про реалтайм было невнято написано – спасибо, исправил.
Про производительность железа – хороший вопрос. Думаю, что ответ будет «это зависит от оптимизации этих самых софтверных балансировщиков». Например, упомянутый Katran называет себя высокопроизводительным.
Serverless подход снимает эту и другие головные боли. Под ваши вычисления динамически выделяется столько мощностей, сколько нужно. То есть бизнес, который пользуется serverless-платформой, не озадачивается вопросом масштабирования инфраструктуры, за него это делает платформа.
Похоже, что Android Police немного вырвали слова из контекста:
https://code.fb.com/video-engineering/av1-beats-x264-and-libvpx-vp9-in-practical-use-case/
Our testing shows AV1 surpasses its stated goal of 30% better compression than VP9, and achieves gains of 50.3%, 46.2% and 34.0%, compared to x264 main profile, x264 high profile and libvpx-vp9, respectively.То есть была задана планка – достигнуть/превысить 30% по сжатию и AV1 преодолел ее. Внесли правки, благодарю.
«Поспешишь – людей насмешишь», как говорится :) Спасибо, вернули «ц» на место.
P.S. рады, что вы одобрили наш выбор.
P.S. прошу прощения, что не смог ответить в понедельник.