Uncle Vёder

Во всей вазовской классике одинаково стрёмная посадка, одинаково неудобные педали, одинаково руль упирается в левую ногу (потому что стоит не по центру относительно сиденья), а правую ногу одинаково подпирает кочерга КПП. Если в тебе много роста/веса и хочется более-менее удобно сидеть - только Калина и её разновидности.

http://habrahabr.ru/post/265283/ Просто так на семёрке отсидеться не получится.

Ну насколько я узнал из информации с различных форумов, уже при попытке распараллелить процесс на большое количество CPU-потоков, например на 16, начинаются потери качества на выходе. Вот например инфа из официального описания параметров x264 от разработчика: Связано это со спецификой самого алгоритма. При попытке распараллелить процесс на тысячи ядер потери качества становятся судя по всему ещё больше, и алгоритм приходится ставить в гораздо более мягкие условия, что в итоге сказывается на размере выходного файла. По сути единственый серьёзный H.264 GPGPU энкодер на рынке - MainConcept. И при попытке поискать его сравнение с x264 натыкаешься на примерно вот такую картину: Видимо, по этой причине разработчики x264 и не стали акцентироваться на GPGPU.

О, только новой инкарнации "Криминальной России" нам и не хватало... Впрочем, трешачок и тазы это всегда лойс.

Внезапно Шура Каретный возвращается, теперь на ютубе. https://www.youtube.com/channel/UClyNjI7f_mWIVUPLjFfJCew

Это издание чисто для внутреннего рынка, откуда там взяться русским субтитрам?

Переиздание будет в 1080p. Вопрос в том - какого качества.

Мало того, эти 4 ссаных ролика по 15 секунд ещё и доступны для просмотра только с японских IP. Да ещё и защита хитроумная сделана, чтобы файлы с видео никак не вытащить было. Японцы упоротые.

Вроде где-то был. А тебе нафига?

Это значит на MX100 неправильная цена. Не может у него такой разрыв с MX200 быть.За эталон цен можно брать CU: http://www.computeruniverse.ru/(цены в местной рознице ессно будут выше, но можно хотя бы прослеживать их отклонения от нормальности) При желании там же можно и покупать, правда по одной железке это не выгодно из-за стоимости доставки.

Гайд по выбору SSD для чайников (лето 2015): 1. Если хочется очень крутых показателей и не жалко денег - Samsung 850 Pro 2. Чуть попроще - Crucial MX200, Crucial M550, SanDisk Extreme Pro 3. Ещё чуть проще и дешевле - Crucial MX100, SanDisk Ultra II Можно смотреть и другие модели/фирмы, но это только если в наличии ничего из вышеперечисленного нет, или цена неадекватная оказалась.

Если взять 240-256ГБ - его будет вполне хватать для системы, набора рабочего софта, и нескольких актуальных игр, которые нужны в конкретный момент времени. Быстрее игры работать не будут. Но они будут быстрее загружаться, в том числе всякие загрузки между уровнями и подгрузки контента. Это очень приятно. Ещё стоит помнить, что в силу специфики SSD, модели большего объёма так же будут и более скоростными. Но тут уже каждый конкретный случай стоит отдельно рассматривать.

Сам спрашивал, сам и отвечаю. Тут всё на самом деле очень просто. Как уже сказал Даниэль, компьютеры являются глупыми машинами, которые понятия не имеют о том, что именно они обрабатывают. Для того, чтобы управлять качеством и размером выходного файла, приходится вручную определять тот предел, когда алгоритм будет прекращать итерации и записывать выходной результат. Варианты тут следующие: CBR (constant bitrate, постоянный битрейт). Здесь всё просто. Соотношение допустимого объёма ко времени видео устанавливается жёстко в виде "верхнего предела". Алгоритм будет всегда стремится к этому пределу и заканчивать обработку, когда предел достигнут. Таким образом можно точно спрогнозировать размер выходного файла. VBR (variable bitrate, переменный битрейт). Здесь параметров уже задаётся три штуки: минимальный битрейт, максимальный, и средний. Алгоритм кодирования видео в таком случае при анализе кадров оценивает их "сложность" (с помощью некой математической метрики) и либо понижает битрейт относительно среднего, либо наоборот повышает. При этом собирается статистика по уже обработанным фрагментам видео, чтобы удержать среднее значение битрейта в заданных рамках. Такой подход даёт более высокое качество картинки, чем CBR, и при этом размер файла на выходе всё так же легко прогнозируется, поскольку прямо зависит от заданного значения среднего битрейта. Можно как-то улучшить эту систему? Да, особенно в случае с VBR. Если сначала произвести грубый анализ исходного видеопотока, можно заранее определить приблизительную сложность отдельных фрагментов, что позволит более гибко управлять работой алгоритма. Это и есть многопроходное кодирование. Первый проход - грубый, оценочный. Второй проход уже позволяет обработать фрагменты более эффективно, на основе данных из первого прохода. Для перфекционистов есть третий проход, который использует уже полную информацию о видеопотоке, полученную на втором проходе. Использование больше трёх проходов лишено смысла чисто математически, т.к. новой информации алгоритм уже получить не сможет. Многопроходное кодирование позволяет получить максимально возможное качество видео, когда нам нужно, чтобы результирующий размер файла вписывался в определённыё рамки. Но собственно зачем это может быть нужно? Как правило, раньше стандартный DVDrip весил 600-700МБ, чтобы влезать на CD-болванку. Для длинных фильмов или более качественных версий рипы разбивали уже на два таких куска. Когда в массы пошло HD-видео, стали популярны варианты рипов, соответствующие объёмам дисков DVD5 или DVD9. Но у нас-то на дворе 2015 год. Использование оптических носителей давно потеряло актуальность. Поэтому и точный размер файла на выходе не так важен. Достаточно ограничить его некими "рамками приличия", а там пусть уже алгоритм сам решает, как ему лучше поступить. Для объективной математической оценки качества в алгоритмах кодирования видео в любом случае используется метрика PSNR, но меняется способ, которым она задаётся. В случае с CBR/VBR параметры PSNR являются переменными и алгоритм должен вычислять их на ходу, постоянно пытаясь вписаться в заданные рамки битрейта, и по сути не зная "что будет дальше". Поэтому для достижения нормальных показателей качества требуется обработка в несколько проходов для более точной оценки, и по этой же причине потоковое видео всегда будет хуже качеством при тех же границах битрейта. CQP (constant quantization parameter) - это просто константа, которой мы изначально и определяем PSNR. Алгоритму теперь не нужно заниматься предсказаниями, он просто выполняет фиксированное количество квантований, достигая требуемого соотношения сигнал/шум. Таким образом можно спрогнозировать выходное качество, а для кодирования требуется только один проход. Всё это хорошо, но можно сделать ещё лучше. Всё дело в том, как человеческий мозг воспринимает видео. Визуально человек различает больше деталей в неподвижных объектах, чем в движущихся. Вот тут и появляется CRF (constant ratefactor), о котором так много уже сказал Даниэль. Если в случае с CBR/VBR параметр QP динамически меняется, чтобы вписаться в битрейт, а в CQP он фиксированный, то в CRF он изменяется в зависимости от того, насколько много в сцене движения (для этого используются отдельные алгоритмы). Мы так же задаём базовую константу для PSNR, но кодек теперь может увеличивать количество квантований (и соответственно степень сжатия), если считает это нужным. В результате визуально видео будет неотличимо от закодированного с CQP, но будет занимать меньше места. Да, CRF это "фишка" энкодеров x264 и x265. Другой софт, насколько мне известно, такую методику не поддерживает. Краткие выводы: 1. Нет решительно никаких причин использовать CBR в любом виде, это прошлый век. 2. Если нужно получить на выходе файл строго заданного размера, стоит использовать VBR в несколько проходов. Это будет долго, но качественно. 3. Если жёстких требований к размеру выходного файла нет, нужно использовать QP. Так гораздо проще спрогнозировать выходное качество, и для кодирования нужен только один проход. 4. Степень сжатия можно улучшить, если использовать CRF вместо CQP в энкодерах x264/x265. Ответ на второй вопрос плавно вытекает из первого. Да, GPGPU позволяет хорошо распараллелить процесс кодирования отдельных фрагментов. Но при разбиении видео на огромное число маленьких кусочков снижается эффективност сжатия, т.к. не получится так же хорошо выделять все типы кадров (а в том же H.264 их аж три типа: B, I, P, да каждый ещё и с разновидностями). Кроме того, опять же из-за слишком сильного распараллеливания невозможно применить многопроходное кодирование, поскольку процесс-то во многом последовательный. Короче, кодирование на GPGPU действительно очень быстрое, но чтобы получить схожее качество с традиционным CPU кодированием, придётся очень сильно жертвовать размером выходного файла. С другой стороны, отдельные операции таки можно параллелить без ущерба. Тот же x264 умеет местами использовать OpenCL и даже получать от этого какой-то (хоть и небольшой) профит.

Вполне себе живой конфиг.Но это смотря какую игру взять. Far Cry 4 или GTA V например пойдут замечательно на средних настройках, а какой-нибудь Assassin's Creed будет лагать во все поля. Вряд ли из 6930 можно выжать что-то, что сильно поменяло бы её возможности.

Щито поделать, граммар-наци в команду не завезли.

Хроника ЕнЕ. Выпуск №25

Повинуясь ностальгическому порыву (вспомнились те светлые времена, когда я активно увлекался аниме и получал от этого удовольствие), решил пересмотреть. Всё-таки главное преимущество Soul Eater - это стиль. SE невероятно стильный, и особенно хорошо это чувствуется в начале. Вроде бы мы имеем типичную такую основу про обычных японских школьников и борьбу бобра с ослом. Но вот загвоздка - школьники то не японские. И не обычные. И школа странная. И акцент на сам процесс обучения делается изредка, да скорее с целью "чисто поржать". А главный адепт добра - Смерть. И вот нетипичные неяпонские школьники из неяпонской школы рубят на куски врага и звонят отчитываться начальству по номеру 42-42-564 (смерть, смерть, убийство), сохраняя абсолютное спокойствие. А Смерть их приветствует фразой "Ну что, как делишки?". Всё это, плюс внешний вид. Плюс интересная музычка на фоне. Получается настолько круто, что словами не описать. Каждый персонаж не только имеет свой уникальный стиль и хорошо проработан, а вдобавок ещё является и отсылкой к каким-то другим произведениям культуры или существующим ИРЛ явлениям. Рисовка и анимация на высоте (всё-таки это Bones, одна из лучших студий). Сюжет тоже подаётся очень хорошо, и тоже является элементом стиля. Получается так, что первые серий 20 (а может и больше) ты смотришь это с блаженной улыбкой от уха до уха. Если честно, я не могу припомнить что-то близкое к SE по уровню "стильности". Разве что Durarara... Нет, явно не дотягивает. Так что же с соулитером не так? Ответ очевиден. Это типичная ситуация для аниме-индустрии, когда сериал уже снимается, а первоисточник ещё далёк от завершения. Bones стоило распилить SE на два (или три) сезона, но они посчитали, что хватит и одного. Вот и пришлось городить отсебятину. Я не знаю, почему так всегда получается, но креативщикам из аниме-студий почему-то не удаётся взять уровень оригинала. И в случае с SE они не то что плохо старались, а наоборот - пытались прыгнуть выше головы. Получился треш. Серьёзные расхождения с мангой начинаются примерно с 35 серии. Не сказать, что после этого всё становится плохо. Вообще, сюжет в каких-то моментах продолжает повторять события из манги, но в несколько другой интерпретации. А вот ближе к самому концу сериала начинается адский ад. Дальше под спойлером В общем, если пережить финал, то SE остаётся невероятно крутой штукой, котору я всё равно рекомендовал бы любому для просмотра. А я пойду мангу почитаю. Интересно же узнать, как всё было "на самом деле".

Это связано с особенностью игровых движков тех времён. Они использовали frame-based анимацию (все современные движки - time-based). Так что в некоторых видах хардкорного киберспорта (тот же Q3 Defrag, в котором вообще всё на точность движений завязано) и 100 FPS были не лишними, а то и 125.

Там даже на CUDA производительность так себе. Возьмём стандартную серию аниме. 25 минут, 30FPS. Это 45000 кадров. Допустим у нас есть хорошее железо, на котором чистая производительность алгоритма для апскейла будет 0.5FPS. Получается 90000 секунд только на преобразование. Это 25 часов. При этом что-то мне подсказывает, что там и 0.5FPS не будет, а более реальный результат - около 0.2, или даже 0.1. Плюс накладные расходы софта, который будет производить раскадровку. Плюс видеокодек, который придётся запускать с очень жёсткими параметрами. Итого несколько дней на одну серию. При том что качество до полноценного FullHD всё равно не будет дотягивать, т.к. всё равно будет много изначально мыльных и шумных кадров. Не вариант. Всерьёз для обработки видео это можно рассматривать только если производительность удастся дотянуть хотя бы до 1-2FPS. Прикольный фильтр, но делает не совсем то.

Короче кинули мне тут ссылочку, и я немного прифигел. http://waifu2x.udp.jp/ Waifu2x - узскоспециализированный алгоритм для шумоподавления и апскейла изображений, основанный на нейронных сетях. Узкая его специализация, как можно догадаться из названия - 2д картинки с рисованными тян (или схожий по содержанию контент). Работает эта штука просто потрясающе. Если у объектов на исходной картинке довольно чёткие грани и нет шумов (или их мало) - результ апскейла до 2х реально выглядит как хайрез-версия. Если шумов много, апскейлить больше чем 2х или грани нечёткие - уже начинает подмыливать, но всё равно это гораздо круче чем тот же привычный фильтр Lanczoz. Шумодав без апскейла тоже работает отлично и убирает большинство артефактов сжатия. По ссылке выше - ограниченная по функционалу демка, но для рядового применения вполне пригодная. Желающие же копнуть глубже могут посмотреть следующие материалы: Исходники алгоритма (реализация под Linux с использованием CUDA): https://github.com/nagadomi/waifu2x Тред на VideoHelp с кучей реализаций (в том числе под винду с вариантами для CPU и CUDA, и даже в виде плагина для AviSynth): http://forum.videohelp.com/threads/372157-New-upscaling-algorithm-waifu2x Тред на Reddit с обуждением: https://www.reddit.com/r/anime/comments/3b0mqs/found_this_waifu2x_an_amazing_neural_networkbased/ Единственный реальный минус - высокая вычислительная сложность. Даже на CUDA преобразования занимают приличное время, а на CPU процесс вообще может занять несколько минут. Так что для риалтайм апскейла видеопотока аниме штука не подходит (та же реализация для AviSynth показывает 0.02FPS на Core i5), а ведь очень заманчиво...

Ещё одна статья про вин10 и сбор информации. На этот раз слегка более научно. http://habrahabr.ru/company/pt/blog/264763/

А самих сообщений об ошибках нет?У меня бывает экран гаснет, потом включается, а потом лезет сообщение что закрашился драйвер, но умная винда его снова подняла. Правда, у меня радеон с его кривым софтом. Да и то случается это крайне редко.

Поэтому и нужно для начала исключить внешние факторы.

1. Проверить внешние факторы. Причиной обвала таблицы разделов вполне могут оказаться некачественный шлейф, проблемы с питанием или ошибки в оперативной памяти. 2. Какая-то из софтин Акрониса (уже не помню точно ADD или ATI, а может вообще обе) имеет функцию восстановления таблицы разделов. Аналогичный софт как правило тоже это умеет. По сути это умеет даже штатный инсталлятор винды. Не знаю, правда, насколько это актуально для SSD, но на HDD мне в своё время это удавалось без каких-либо потерь. 3. В плохом случае это может означать, что SSD сдох. Возможно, не повезло. Что за модель? Проблема явно не в мышке, а в софте, который с мышкой поставляется.