Почти на 100% уверен, что столь частые остановки из-за нехватки мощности для обработки изображений. Если бы там, условно, была пара 2080ti, то он мог бы 30 раз в секунду фотографировать и обрабатывать изображение.
Но там не очень хорошие условия, мало электрической мощности, потенциально большое количество всяких высокоэнергетических лучей и т.д., так что марсоход с COTS видеокартами для решения задачи фото-одометрии мы увидим ещё не скоро.
В общем случае эта функция не идемпотентная, т.к. при ряде запросов на добавление строк они могут начать дублироваться. Например, если вы используете автоинкремент для колонки первичного ключа.
Когда пользователи будут пребывать на одной и той же веб-странице или окне приложения несколько секунд или даже минут, и поэтому они так или иначе будут видеть устаревшие данные.
Пользователи иногда умеют рефрешить страницу и делиться ссылками, при этом они ожидают, что со страницы ничего не будет пропадать, а только добавляться новые новости/статьи. Так что тут пример более узкий — это лента фейсбука/вк, когда пользователь заранее не знает, что там будет, и готов к тому, что она поменяется после рефреша.
Когда пользователи обновляют лишь некие свои приватные данные.
Когда пользователи вообще не обновляют данные, а только дополняют новыми (append).
Когда бизнес-логика не определяет необходимость некоего порядка выполнения транзакций.
В этих случаях вы, вообще говоря, хотите консистентности от БД. Вы не хотите линейной истории, потому что вам не важен порядок транзакций, и в ряде случаев можно говорить о eventual consistency, если потеря данных допустима.
Я бы сказал так: вы можете достаточно смело отказаться от консистентности в том случае, когда пользователь системы не может доподлинно проверить её поведение. Например, счётчик лайков для видеоролика на ютубе: лайк каждого из пользователей анонимен, видят все только сумму, и знают про антифрод, который эти лайки может срезать.
В долби снимается уже довольно много контента. А дальше уже каждый стриминговый сервис должен у себя поддержать, но тут эпл вроде тоже давненько уже поддерживает.
По поводу покрытия NTSC — это же замкнутый круг, большинство сцен охватывается этим цветовым пространством потому, что их (сцены) строят и освещают таким образом, чтобы они хорошо выглядели в телеке.
Посмотрите своими глазами на 2 телевизора, HDR и SDR, на котором крутится один и тот же контент, который снят в HDR, и покрашен в HDR и SDR соответственно.
Именно так и происходит, когда вы будете пытаться смотреть HDR контент с динамическими метаданными DolbyVision на SDR экране. Собственно, все плевались на последний сезон Игры Престолов, что там ничего не видно — а в HDR версии видно как раз было. Потому что в кадре были одновременно и яркие, и тёмные места, а глаз смотрит в одну часть кадра только, и подстраивает "экспозицию" в ней.
В зелёных цветах сильно лучше стало, футбол в HDR смотреть годно. Да и в целом картинка выглядит лучше, особенно если есть возможность сравнить (2 телефона рядом, например).
Авторы статьи забыли об одной "небольшой мелочи": для HDR видео надо цветокоррекцию 2 раза делать, под HDR 1000 нит (или 400 нит — таких телеков больше), а так же под SDR отдельно цветокоррекцию делать.
А в случае прямых трансляций, часть телекомпаний решили, что проще иметь два комплекта камер, чем на лету пытаться сделать адекватный SDR из HDR.
Один наш коллега приходил в офис часов в 6 вечера, у него примерно такой распорядок дня был:
пришёл, покушал, в пинг-понг там сыграл
почитал почту
ближе к ночи начинал кодить, и кодил до 4..6 утра
когда уже все сваливали из офиса — практиковался играть на трубе
на следующий день вставал часа в 2, занимался всякими своими делами, типа занятий по той же игре на трубе и т.д.
То есть его рабочий день был смещён сильно в ночь. Это не очень эффективно, когда нужны какие-то обсуждения, но в целом норм.
Да не просят сложные алгоритмы придумывать, во всяком случае в нормальных конторах. Это реально что-то типа экзамена в автошколе, причём даже не в городе, а на площадке: покажи, что ты в принципе умеешь код писать (машину водить) — понимаешь, что такое алгоритм, что такое цикл, и в состоянии написать несколько строк кода на том языке, который сам же назвал своим основным языком. Типичный пример подобной задачки: написать бинарный поиск в отсортированном массиве. И довольно приличный процент синьёров-помидоров такой тест реально проваливает.
Вообще, это далеко не самый лучший вариант проверки, т.к. ICMP во-первых может терминироваться не тем же железом, что TCP, а во-вторых, может иметь иной приоритет как в сети провайдера, так и на стороне сети/серверов, где пингуемый айпишник располагается.
Если же целью для пингов является именно сетевое оборудование, то там вообще не стоит говорить о какой-либо достоверности при таком методе измерения: ответы на ICMP поднимаются на cpu, тогда как основной трафик остаётся в чипе/линейных картах.
Если уж хочется что-то проверять, то лучше запрашивать какую-то очень маленькую http страничку, или, хотя бы, udp-пакетами проверять.
С другой стороны, ваши графики на 100% лучше, чем ничего.
https://www.youtube.com/watch?v=86QU7_SF16Q — нейросеть, которая восстанавливает удалённое на видео, в том числе может дорисовать то, что было за границами кадра, причём делает это консистентно по времени. Задача примерно такая же, как описывается в этой статье, но для видео.
+1 про крестолёт простейший, для отработки моторики. Для ремонта рекомендую использовать клей uhu-por для потолочки, офигенно клеит и при этом остаётся эластичным при высыхании.
Для посадки на траву складной винт не особо нужен, и с обычным отлично садится, если моторама не совсем уж хлипкая. Посадочная скорость небольшая, травинки упругие, нагрузки на винт почти не создают. Про то, что стоит сначала без шасси поддерживаю, имхо шасси на фотографиях годится только для асфальта, даже на грунтовых утоптанных дорогах оторвёт нафиг.
Но в современных одноразовых ракетах, у которых запас по прочности порядка 10-30% всего (т.е. реально особо негде уже экономить) масса топлива составляет порядка 85% от массы всей ракеты. И снизить эти 15% до 10%, скажем — принципиально сложно, если вообще возможно, при современном уровне развития технологий и материаловедения.
Так и с приложениями бывают косяки, так что для конечного пользователя (условно — вашей бабушки) лучше сделать видео в прогрессиве, чтобы у неё точно показывало хорошо.
Сильную долю в аудио-треке оно само распознаёт как-то? Или надо как-то дорожку разметить, и оно потом будет помогать склейки расставлять по этой разметке?
Желающим оцифровывать я бы предложил такой пайплайн:
Зарипать видео с кассеты, выход сохранить в interlaced режиме в ProRES или DNxHD, накрайняк h264 с высоким битрейтом (не меньше пары десятков мегабит в секунду), если при этом исходик не в YUV420 — то писать в YUV444. При этом следить за цветовых пространством (PAL/NTSC), и за частотой кадров (50i для PAL, 59.94i для NTSC) — всё должно быть как в исходнике. Звук — aac 256 кбит/с. Исходники не удалять, по крайней мере сразу.
Намонтировать всё это в нормальные ролики, сделать деинтерлейс (в 25/29.97 кадров в секунду соответственно), цветокоррекцию, перевести в цветовое пространство BT.709. Всё сразу можно в Davinci Resolve, например.
Выгнать в h264/h265 с битрейтом не менее 5/4 мбит/с, с двухпроходным кодированием. Звук aac с битрейтом не менее 196 кбит/с. Результат уже куда угодно заливать.
В вебе, считайте, деинтерлейс отсутствует как класс. На ютубе довольно много видео, которое было залито интерлейсным, а затем с компа смотришь его уже как-бы как прогрессив, но с гребёнками.
Обратите внимание на потребление CO2 сенсоров, устройство на батарейке сделать вряд ли получится.
Почти на 100% уверен, что столь частые остановки из-за нехватки мощности для обработки изображений. Если бы там, условно, была пара 2080ti, то он мог бы 30 раз в секунду фотографировать и обрабатывать изображение.
Но там не очень хорошие условия, мало электрической мощности, потенциально большое количество всяких высокоэнергетических лучей и т.д., так что марсоход с COTS видеокартами для решения задачи фото-одометрии мы увидим ещё не скоро.
В общем случае эта функция не идемпотентная, т.к. при ряде запросов на добавление строк они могут начать дублироваться. Например, если вы используете автоинкремент для колонки первичного ключа.
Пользователи иногда умеют рефрешить страницу и делиться ссылками, при этом они ожидают, что со страницы ничего не будет пропадать, а только добавляться новые новости/статьи. Так что тут пример более узкий — это лента фейсбука/вк, когда пользователь заранее не знает, что там будет, и готов к тому, что она поменяется после рефреша.
В этих случаях вы, вообще говоря, хотите консистентности от БД. Вы не хотите линейной истории, потому что вам не важен порядок транзакций, и в ряде случаев можно говорить о eventual consistency, если потеря данных допустима.
Я бы сказал так: вы можете достаточно смело отказаться от консистентности в том случае, когда пользователь системы не может доподлинно проверить её поведение. Например, счётчик лайков для видеоролика на ютубе: лайк каждого из пользователей анонимен, видят все только сумму, и знают про антифрод, который эти лайки может срезать.
В долби снимается уже довольно много контента. А дальше уже каждый стриминговый сервис должен у себя поддержать, но тут эпл вроде тоже давненько уже поддерживает.
По поводу покрытия NTSC — это же замкнутый круг, большинство сцен охватывается этим цветовым пространством потому, что их (сцены) строят и освещают таким образом, чтобы они хорошо выглядели в телеке.
Может! HDR матрицы физически способны отображать больше цветов, в этом весь смысл расширенного диапазона цветов.
Вот, в статье же есть цветовые треугольники: https://habrastorage.org/getpro/habr/post_images/463/dbf/e33/463dbfe332ca056d15e131fd6312593b.png
Посмотрите своими глазами на 2 телевизора, HDR и SDR, на котором крутится один и тот же контент, который снят в HDR, и покрашен в HDR и SDR соответственно.
Именно так и происходит, когда вы будете пытаться смотреть HDR контент с динамическими метаданными DolbyVision на SDR экране. Собственно, все плевались на последний сезон Игры Престолов, что там ничего не видно — а в HDR версии видно как раз было. Потому что в кадре были одновременно и яркие, и тёмные места, а глаз смотрит в одну часть кадра только, и подстраивает "экспозицию" в ней.
В зелёных цветах сильно лучше стало, футбол в HDR смотреть годно. Да и в целом картинка выглядит лучше, особенно если есть возможность сравнить (2 телефона рядом, например).
Авторы статьи забыли об одной "небольшой мелочи": для HDR видео надо цветокоррекцию 2 раза делать, под HDR 1000 нит (или 400 нит — таких телеков больше), а так же под SDR отдельно цветокоррекцию делать.
А в случае прямых трансляций, часть телекомпаний решили, что проще иметь два комплекта камер, чем на лету пытаться сделать адекватный SDR из HDR.
Положим, делают они что-то или не делают в выходные — зависит от того, как качественно они свой сервис делают в рабочее время.
Один наш коллега приходил в офис часов в 6 вечера, у него примерно такой распорядок дня был:
пришёл, покушал, в пинг-понг там сыграл
почитал почту
ближе к ночи начинал кодить, и кодил до 4..6 утра
когда уже все сваливали из офиса — практиковался играть на трубе
на следующий день вставал часа в 2, занимался всякими своими делами, типа занятий по той же игре на трубе и т.д.
То есть его рабочий день был смещён сильно в ночь. Это не очень эффективно, когда нужны какие-то обсуждения, но в целом норм.
Да не просят сложные алгоритмы придумывать, во всяком случае в нормальных конторах. Это реально что-то типа экзамена в автошколе, причём даже не в городе, а на площадке: покажи, что ты в принципе умеешь код писать (машину водить) — понимаешь, что такое алгоритм, что такое цикл, и в состоянии написать несколько строк кода на том языке, который сам же назвал своим основным языком. Типичный пример подобной задачки: написать бинарный поиск в отсортированном массиве. И довольно приличный процент синьёров-помидоров такой тест реально проваливает.
Вообще, это далеко не самый лучший вариант проверки, т.к. ICMP во-первых может терминироваться не тем же железом, что TCP, а во-вторых, может иметь иной приоритет как в сети провайдера, так и на стороне сети/серверов, где пингуемый айпишник располагается.
Если же целью для пингов является именно сетевое оборудование, то там вообще не стоит говорить о какой-либо достоверности при таком методе измерения: ответы на ICMP поднимаются на cpu, тогда как основной трафик остаётся в чипе/линейных картах.
Если уж хочется что-то проверять, то лучше запрашивать какую-то очень маленькую http страничку, или, хотя бы, udp-пакетами проверять.
С другой стороны, ваши графики на 100% лучше, чем ничего.
https://www.youtube.com/watch?v=86QU7_SF16Q — нейросеть, которая восстанавливает удалённое на видео, в том числе может дорисовать то, что было за границами кадра, причём делает это консистентно по времени. Задача примерно такая же, как описывается в этой статье, но для видео.
https://www.youtube.com/watch?v=2pWK0arWAmU — нейросетка, которая выделяет из видео людей и позволяет смонтировать видео иначе. Вообще чума!
С википедии:
То есть объём чуть больше 13.5 кубометров, должна отлично плавать.
+1 про крестолёт простейший, для отработки моторики. Для ремонта рекомендую использовать клей uhu-por для потолочки, офигенно клеит и при этом остаётся эластичным при высыхании.
Для посадки на траву складной винт не особо нужен, и с обычным отлично садится, если моторама не совсем уж хлипкая. Посадочная скорость небольшая, травинки упругие, нагрузки на винт почти не создают. Про то, что стоит сначала без шасси поддерживаю, имхо шасси на фотографиях годится только для асфальта, даже на грунтовых утоптанных дорогах оторвёт нафиг.
На первой фотке как будто бы вечер, а на часах час дня :) И на последней фотке такая же история.
Но в современных одноразовых ракетах, у которых запас по прочности порядка 10-30% всего (т.е. реально особо негде уже экономить) масса топлива составляет порядка 85% от массы всей ракеты. И снизить эти 15% до 10%, скажем — принципиально сложно, если вообще возможно, при современном уровне развития технологий и материаловедения.
Так и с приложениями бывают косяки, так что для конечного пользователя (условно — вашей бабушки) лучше сделать видео в прогрессиве, чтобы у неё точно показывало хорошо.
Сильную долю в аудио-треке оно само распознаёт как-то? Или надо как-то дорожку разметить, и оно потом будет помогать склейки расставлять по этой разметке?
Желающим оцифровывать я бы предложил такой пайплайн:
В вебе, считайте, деинтерлейс отсутствует как класс. На ютубе довольно много видео, которое было залито интерлейсным, а затем с компа смотришь его уже как-бы как прогрессив, но с гребёнками.