Дешевое и не своим трудом — это сюда: www.streacom.com/products/fc8-evo-fanless-chassis/ + www.streacom.com/products/nano150-psu/. Собственно, это чудо сейчас стоит у меня в квартире. Используется с материнской платой Gigabyte GA-H87N-WIFI, процессором Intel Core i7 4770S, 16 GB RAM, 512 GB SSD (OCZ Vector). Самый шумный элемент компьютера — это монитор Dell U2410 (слегка гудит чем-то в своей левой части).
Спецификации утверждают, что данный корпус можно применять с Mini-ITX-платами и с процессорами с TDP до 95W. Реально же процессор Intel Core i7 4770S (65W TDP) при нагрузке cpuburn'ом нагревается до 86 градусов, после чего замедляется до 2.8 GHz и продолжает работать при такой температуре. Ну и блок питания на 150W с таким процессором выдерживает не все бенчмарки (выдерживает 8x cpuburn, но мгновенно выключается при запуске LinX в 8 потоков), т.е. мне надо было или искать более мощный блок питания, или процессор поэкономичнее.
То, что продается без системы или с linux на борту, чаще всего ущербно по другим параметрам (например, мало памяти). И еще надо преодолевать нежелание или неспособность магазинов распространять ноутбуки с системой, отличной от Windows. Например, некоторое время назад я искал в магазинах Dell XPS 13 Developer Edition (который с Ubuntu) — его просто не было, а были только варианты с Windows. В одном магазине мне сказали: «мы, конечно, можем заказать его из Москвы специально для Вас, но так как это штучный заказ, то и оплачивать его пересылку придется как штучный заказ, т.е. выйдет 90 тыс. руб. (что вдвое выше „номинальной“ цены)».
Функция utf8_wctomb скопирована из каких-то линуксовых библиотек. А там wchar_t — 4 байта, и функция должна остаться работоспособной даже при таком условии. Так что я расцениваю описанное в статье предупреждение как ложное срабатывание.
Что-то мне говорит, что проблема не решена и может повториться в любой момент.
Я с такой «опечаточной» порчей данных сталкивался, когда была битая память. Но в вашем случае на битый модуль памяти тоже не похоже, т.к. ошибки каждый раз более чем в одном бите.
А кстати — разве блокировки транзитного траффика не являются, с точки зрения IANA, поводом для отзыва выделенных провайдеру ресурсов, таких как IP-адреса и AS-номера?
А никакие. Это не имеет смысла, поскольку траффик в конечном итоге все равно пойдет через Ростелеком, который нарисует свою заглушку поверх веб-страницы, которую хороший провайдер так тщательно старался не заблокировать.
У меня доска находится слева от экрана и в любом случае попадает в исходный кадр. Если лектор что-то там напишет — камера это запишет. Можно будет пост-фактум сделать крупный план, см. пример в моем видео около 14:40. Проблема с шумом (яркий экран для презентаций рядом с плохо освещенной доской) действительно есть, но не очень серьезная, фильтры справляются. А если бы не справлялись — то и студенты бы ничего не увидели :)
Если предполагается делать только SD-видео для веба (640x480), то при наличии 4K- или в некоторых случаях даже FullHD-камкордера с низким уровнем шумов матрицы оператор и не нужен. Можно просто поставить камеру, чтобы записывала широкое поле зрения, в которое попадает вся доска, на которой пишет лектор (т.е. заведомо больше, чем нужно). В ходе лекции камеру не трогать — пусть пишет все с максимальным качеством. После того, как вся лекция будет отснята, за счет имеющегося запаса по разрешению и полю зрения можно в видеоредакторе выполнить панорамирование, зум и выравнивание яркости и контрастности — т.е. по сути выполнить операторскую работу пост-фактум. Затем добавить слайды и/или скринкаст. Под Linux с таким простым редактированием справляется и Cinelerra.
Вот это видео (как и все предыдущие в этой серии лекций) снято на одну статически установленную FullHD-камеру параллельно со скринкастом и обработано мной в Cinelerra: habrahabr.ru/company/ideco/blog/147086/. Как видно, при наличии времени (в том числе машинного) и при статичных слайдах можно исправить даже тот факт, что лектор ходит на фоне экрана со слайдами (пример см. начиная с 29:30).
Ну тогда это вообще замечательно! Достаточно потребовать, чтобы ухудшение качества изображения на кадрах, попадающих в защищаемую группу, при декодировании, начиная с указанного кадра, укладывалось в таблицу 1 из этого ГОСТа, согласно заявленному классу кодека по этому же ГОСТу. Для систем, использующих ключевые кадры в смысле «возможность декодирования его и всех последующих», это требование выполняется тривиальным образом, если указать непосредственно предшествующий ключевой кадр. А для систем без ключевых кадров получено полезное обобщение.
А по поводу пригодности такого неточного декодирования для целей криминалистики — думаю, что новых проблем это не создаст, т.к. неспецифицированная потеря качества по сравнению с оригинальной сценой есть и в штатном режиме декодирования, особенно если камеру настроили на низкий битрейт. Попытка требовать от lossy-кодека восстановление кадра, на 100% идентичное тому, которое бы получилось при декодировании потока с самого начала, мне кажется, аналогична попытке быть святее папы римского. А вот указание, на сколько кадров назад надо отмотать для получения качества, хорошего с точки зрения автора кодека, IMHO, помешать не может. Если такая неопределенность не нравится, можно еще продублировать флаг exact_match_flag. Тогда при использовании ключевых кадров можно его смело выставлять и подписывать.
По поводу формулировки «достаточно точное восстановление изображения» — я пытался сделать так, чтобы семантика SEI recovery point (только в виде ссылки в обратную сторону) подходила. А там есть только требование приблизительно корректного декодирования, «acceptable pictures for display», и даже флаг «после указанного в другом поле числа кадров возможно точное декодирование», который может быть снят. См. пункт D.2.7 стандарта ITU H264.
When exact_match_flag is equal to 0, the quality of the approximation at the recovery point is chosen by the encoding process and is not specified by this Recommendation | International Standard.
Т.е. точность восстановления изображения по сути отдается на откуп авторам реализации кодека.
3. Определение опорного кадра в стандарте отличается от общепринятого — так и задумано? Существенное изменение картинки вовсе не обязательно. Некоторые камеры расставляют опорные кадры (в понимании стандарта H.264) просто периодически. IMHO, если такое отличие не задумано, лучше будет делегировать определение опорного кадра стандарту на используемый видеокодек.
Никакого скрытого смысла нет, поэтому предложите Ваше определение, обсудим здесь и включим в следующую редакцию.
4. «Номер последнего опорного кадра для сжатых кадров» — что туда полагается писать, если речь идет о потоке без опорных кадров (H.264 такое допускает — ошибки «самозалечиваются» при декодировании с любого кадра)? Или следует признать, что такие потоки не могут быть защищены по уровню защиты I?
Ситуация, когда все кадры опорные, допустима и даже является обычным делом в случае использования, например, MJPEG. В таком случае номер последнего опорного кадра будет равен просто номеру текущего блока и никаких препятствий для сертификации по уровню защиты I нет.
По поводу пункта 3 — правильное определение зависит от используемого видеокодека, т.е. нельзя написать ничего лучше, чем «кадр, помеченный видеокодеком как опорный в его понимании». В большинстве случаев такие кадры имеют свойство: начав декодирование с этого кадра, можно успешно декодировать его и все без исключения последующие. В нашем случае важен на самом деле факт успешного декодирования кадров, входящих в рассматриваемую группу.
По поводу 4 — Вы меня неправильно поняли. Имеется в виду не ситуация, когда все кадры опорные (тут действительно нет ничего сложного), а когда ни одного опорного кадра нет вообще, а поток декодировать таки возможно с любой точки (с искажениями или пропущенными кадрами в начале). Да, такое бывает — см. низ permalink.gmane.org/gmane.comp.video.ffmpeg.user/43075, где на эту тему высказывается один из разработчиков ffmpeg'а. Например, возможна ситуация, когда, начав декодирование с кадра 4321, можно получить неискаженную картинку, начиная с кадра 4330 (но невозможно восстановить кадр 4329), но получить неискаженную картинку в кадре 4330, начав декодирование позже кадра 4321, невозможно.
Предлагается использование понятия «опорный кадр» убрать и заменить 5.5.1.3.в на следующий текст:
наибольший номер кадра, начав декодирование с которого, можно получить достаточно точное восстановление изображения на всех кадрах, входящих в защищаемую группу
Спецификации утверждают, что данный корпус можно применять с Mini-ITX-платами и с процессорами с TDP до 95W. Реально же процессор Intel Core i7 4770S (65W TDP) при нагрузке cpuburn'ом нагревается до 86 градусов, после чего замедляется до 2.8 GHz и продолжает работать при такой температуре. Ну и блок питания на 150W с таким процессором выдерживает не все бенчмарки (выдерживает 8x cpuburn, но мгновенно выключается при запуске LinX в 8 потоков), т.е. мне надо было или искать более мощный блок питания, или процессор поэкономичнее.
Функция utf8_wctomb скопирована из каких-то линуксовых библиотек. А там wchar_t — 4 байта, и функция должна остаться работоспособной даже при таком условии. Так что я расцениваю описанное в статье предупреждение как ложное срабатывание.
Я с такой «опечаточной» порчей данных сталкивался, когда была битая память. Но в вашем случае на битый модуль памяти тоже не похоже, т.к. ошибки каждый раз более чем в одном бите.
Вот это видео (как и все предыдущие в этой серии лекций) снято на одну статически установленную FullHD-камеру параллельно со скринкастом и обработано мной в Cinelerra: habrahabr.ru/company/ideco/blog/147086/. Как видно, при наличии времени (в том числе машинного) и при статичных слайдах можно исправить даже тот факт, что лектор ходит на фоне экрана со слайдами (пример см. начиная с 29:30).
Т.е. точность восстановления изображения по сути отдается на откуп авторам реализации кодека.
Формально правильно, но боюсь, не то, что нужно.
Кадр 1: построен без учета других кадров
Кадр 2: построен с учетом кадра 1
Кадр 3: построен без учета других кадров
Кадр 4: построен с учетом кадра 1
Формально, кадр 3 является ключевым, но, если начать декодирование с него, то кадр 4 декодировать невозможно.
Думаю, тут уместен такой же подход, как и к смене ключа, который Вы уже описали, отвечая на пункт 5.
По поводу пункта 3 — правильное определение зависит от используемого видеокодека, т.е. нельзя написать ничего лучше, чем «кадр, помеченный видеокодеком как опорный в его понимании». В большинстве случаев такие кадры имеют свойство: начав декодирование с этого кадра, можно успешно декодировать его и все без исключения последующие. В нашем случае важен на самом деле факт успешного декодирования кадров, входящих в рассматриваемую группу.
По поводу 4 — Вы меня неправильно поняли. Имеется в виду не ситуация, когда все кадры опорные (тут действительно нет ничего сложного), а когда ни одного опорного кадра нет вообще, а поток декодировать таки возможно с любой точки (с искажениями или пропущенными кадрами в начале). Да, такое бывает — см. низ permalink.gmane.org/gmane.comp.video.ffmpeg.user/43075, где на эту тему высказывается один из разработчиков ffmpeg'а. Например, возможна ситуация, когда, начав декодирование с кадра 4321, можно получить неискаженную картинку, начиная с кадра 4330 (но невозможно восстановить кадр 4329), но получить неискаженную картинку в кадре 4330, начав декодирование позже кадра 4321, невозможно.
Предлагается использование понятия «опорный кадр» убрать и заменить 5.5.1.3.в на следующий текст: