Не соглашусь, все зависит от величины проекта. При правильном подходе к решению, сам дизайн представляется как нудная работа день за днём, а дебаг уже будет казаться развлечением. И потом, когда наконец полностью соберешь дизайн и тестовое окружение остаётся буквально несколько недель на такое. А вот если постоянно менять первое и второе, то это бесконечная морока.
Если вы просто написали код это только 20%, хотя иногда и больше, все зависит от сложности пректа. Нужны тесты, нужно окружение, нужна работа с кодом для генерации тестов. Всё это выливается в дебаг тестов и только после этого дебаг проекта. Вы собрали свою часть и формально подсоединили к верхнему уровню - добро пожаловать на тестирование системы в целом. И вот тут мы приходим к тому, что не весь менеджмент понимает слова и иногда нужны правила.
Цель то одна, но работы ведутся в параллели. И если одни делают как и дизайн, так и верификацию, то работа других для них выглядит только как поиск проблем в их коде. Поэтому мне кажется ошибочным первоначальное разделение на одних и других, пусть каждый поработает на месте других.
Первоначально, когда тестирование не вылизано, проскакивает та или иная ошибка, и после пары ECO спится к финалу не всегда хорошо. Как бы я и сделал максимум, но когда ревизия из-за тебя вылетает в мусорку, то никто не покажет лично на тебя, но все знают какая тима, потом привыкаешь ... баги есть всегда, это лишь повод чтобы улучшить тестирование на следующий проект.
А в конце понимаешь, что же за хрень была в первоначальных релизах.
Работа в том или ином направлении "ломает мозг" в а плане подхода к работе. В итоге если сильно уйти в дизайн потом трудно заниматься тестированием , в свою очередь после тестирования трудно найти золотую середину в дизайне.
Интересно, а тестировщик хорошо спит после релиза или также вздрагивает при каждом bug report-e, как бывает у разработчика поначалу ?
Не хочу умалять ничьей работы, но написав, что поддерживает то или иное сжатие это просто сделан GUI для командной строки ffmpeg, который в свою очередь сделал вызов к уже готовой библиотеке, сделанной кем-то другим.
Это скорее из серии бесполезных работ. Но сейчас все идёт к применению AI который рисует кадр, вот этого добра вскоре появится много и их уже можно будет отнести к собственным кодекам, которые никому не нужны.
Поддерживать сможете, оно на базовом уровне мало отличается от того же ffmpeg. А вот затащить, как вариант, объединиться с кем то ещё, тема реализуема, хоть и с трудом.
В статье под кодеками понимается конкретная имплементация/реализация энкодера. Стандарт в котором они работают одинаков, однако вопрос как реализовано предсказание и процесс кодирования, и они различны для каждой из компаний. Но в итоге, любое устройство, соответствующее стандарту может воспроизводить это видео. Т.е. это не проприетарный кодек, а свой путь реализации одного и того же стандарта.
Нет никаких проприетарных кодеков (уже нет). Даже Гугл один не потянет сегодня сделать такое.
К сведению, сейчас заканчивается стандартизации последнего из классических (без применения нейронных сетей), одну из основных ролей там как раз играет Гугл, но также и Apple, Netflix, Intel и много других. Я имею ввиду AVM/AV2, так там сложность только декодера повысилась в несколько раз, а энкодера более десяти (на порядок сложнее) и при этом битрейт снизили "всего лишь" на 25%.
Не думали над аппаратными решениями, на FPGA или заказать на аутсорс полностью свое ядро ?
Понятно что 2й вариант стоит бесконечное количество денег, а еще и знающих команд нет, но на FPGA можно обкатать на будущее и энергии это будет потреблять гораздо меньше и быстрее работать.
Любой дизайн делается под определённую технологию и частоты. Изначально определена производительность устройста и под это делается весь дизайн для худшего случая. Просто так делать запас по характеристикам стоит денег, иногда довольно больших и на это никто не идёт. Т.е. устройство проверят на соответствия ТЗ, всё что получилось выше - ваше.
Зачем изобретать "новое", когда есть JpegXS. Тот-же wavelet на весь кадр, упрощенное энтропийное кодирование, возможности предсказания из прошлого фрейма, правда возникают вопросы о стоимости лицензии.
Свобода? Зачем тогда платить за использование этих же сетей которые были тренированы на ваших же данных. Т.е. без вас их бы не было и вы же ещё платите за них, т.е. вас же дважды использовали.
Не соглашусь, все зависит от величины проекта. При правильном подходе к решению, сам дизайн представляется как нудная работа день за днём, а дебаг уже будет казаться развлечением. И потом, когда наконец полностью соберешь дизайн и тестовое окружение остаётся буквально несколько недель на такое. А вот если постоянно менять первое и второе, то это бесконечная морока.
Если вы просто написали код это только 20%, хотя иногда и больше, все зависит от сложности пректа. Нужны тесты, нужно окружение, нужна работа с кодом для генерации тестов. Всё это выливается в дебаг тестов и только после этого дебаг проекта. Вы собрали свою часть и формально подсоединили к верхнему уровню - добро пожаловать на тестирование системы в целом. И вот тут мы приходим к тому, что не весь менеджмент понимает слова и иногда нужны правила.
Понравилось про правило Парето 20/80, практически применимо на любом уровне иерархии проекта, смотря с какой стороны смотреть.
Цель то одна, но работы ведутся в параллели. И если одни делают как и дизайн, так и верификацию, то работа других для них выглядит только как поиск проблем в их коде. Поэтому мне кажется ошибочным первоначальное разделение на одних и других, пусть каждый поработает на месте других.
Первоначально, когда тестирование не вылизано, проскакивает та или иная ошибка, и после пары ECO спится к финалу не всегда хорошо. Как бы я и сделал максимум, но когда ревизия из-за тебя вылетает в мусорку, то никто не покажет лично на тебя, но все знают какая тима, потом привыкаешь ... баги есть всегда, это лишь повод чтобы улучшить тестирование на следующий проект.
А в конце понимаешь, что же за хрень была в первоначальных релизах.
Работа в том или ином направлении "ломает мозг" в а плане подхода к работе. В итоге если сильно уйти в дизайн потом трудно заниматься тестированием , в свою очередь после тестирования трудно найти золотую середину в дизайне.
Интересно, а тестировщик хорошо спит после релиза или также вздрагивает при каждом bug report-e, как бывает у разработчика поначалу ?
Не хочу умалять ничьей работы, но написав, что поддерживает то или иное сжатие это просто сделан GUI для командной строки ffmpeg, который в свою очередь сделал вызов к уже готовой библиотеке, сделанной кем-то другим.
Хвастаться нехорошо, откуда так много слов "непонятных" знаете ?
Это скорее из серии бесполезных работ. Но сейчас все идёт к применению AI который рисует кадр, вот этого добра вскоре появится много и их уже можно будет отнести к собственным кодекам, которые никому не нужны.
Возможно, в теории китайцы могут сделать у себя, а тут заложить как какой-нибудь грант от государства. В Европах тоже не всё сами делают,.
Поддерживать сможете, оно на базовом уровне мало отличается от того же ffmpeg. А вот затащить, как вариант, объединиться с кем то ещё, тема реализуема, хоть и с трудом.
Не совсем корректно написано.
В статье под кодеками понимается конкретная имплементация/реализация энкодера. Стандарт в котором они работают одинаков, однако вопрос как реализовано предсказание и процесс кодирования, и они различны для каждой из компаний. Но в итоге, любое устройство, соответствующее стандарту может воспроизводить это видео. Т.е. это не проприетарный кодек, а свой путь реализации одного и того же стандарта.
Нет никаких проприетарных кодеков (уже нет). Даже Гугл один не потянет сегодня сделать такое.
К сведению, сейчас заканчивается стандартизации последнего из классических (без применения нейронных сетей), одну из основных ролей там как раз играет Гугл, но также и Apple, Netflix, Intel и много других. Я имею ввиду AVM/AV2, так там сложность только декодера повысилась в несколько раз, а энкодера более десяти (на порядок сложнее) и при этом битрейт снизили "всего лишь" на 25%.
Не думали над аппаратными решениями, на FPGA или заказать на аутсорс полностью свое ядро ?
Понятно что 2й вариант стоит бесконечное количество денег, а еще и знающих команд нет, но на FPGA можно обкатать на будущее и энергии это будет потреблять гораздо меньше и быстрее работать.
Извиняюсь если не прав, но очень смахивает на генерацию текста, поскольку это выглядит как очередной мануал по пользованию ffmpeg.
Любой дизайн делается под определённую технологию и частоты. Изначально определена производительность устройста и под это делается весь дизайн для худшего случая. Просто так делать запас по характеристикам стоит денег, иногда довольно больших и на это никто не идёт. Т.е. устройство проверят на соответствия ТЗ, всё что получилось выше - ваше.
Год назад они увеличили колличество уровней английского, так что "игру" надо проходить гораздо дольше.
Зачем изобретать "новое", когда есть JpegXS. Тот-же wavelet на весь кадр, упрощенное энтропийное кодирование, возможности предсказания из прошлого фрейма, правда возникают вопросы о стоимости лицензии.
Они с этого имеют прибыль, и все это коммерческие компании, которые планируют с этого получать, хоть и горизонт этого события в несколько лет.
У вас сейчас за копейки купят и потом вам же продадут за рубли.
Свобода? Зачем тогда платить за использование этих же сетей которые были тренированы на ваших же данных. Т.е. без вас их бы не было и вы же ещё платите за них, т.е. вас же дважды использовали.
Тема так и не раскрыта, почему авторы позволяют бесплатно использовать свой труд, и даже так, они дают на это согласие через меню.