Обновить
24
0
Илья@7313

Штатный шаман

Отправить сообщение
Если государство решило помогать, то все станет только хуже — пойдут распилы, липовые спецы со стотысячными окладами, обучение кучи будущих торговых агентов по IT специальностям за гос средства, очковтирательство и т.д. А скромным грамотным компьютерщикам в этом мире бабла вообще места не останется.
Дело пойдет на лад если государство наконец поймет, что все что нужно это просто не мешать, чуть-чуть снизить налоги, прекратить принимать по 252 закона в день по IT тематике и перестать пытаться руководить и регулировать.
А вот интересно кто-нибудь всерьез тестировал на совместимость расширенный юникод в котором 32 чемодана символов? )
например
☯ ☭ ☣ ☀ ⚽ ⏰ ✔ ✠ ✌ ☕
Ну возможно я тестировал на каких-то неправильных .svg… нужно повторить и виноват тогда
Да — именно без SVG :)
Возьмем, например, форум и кучу мелких иконок вокруг каждого сообщения. Мои личные наблюдения показывают, что если .svg элементов на одной страничке больше 20, то браузер при прокрутке начинает жестоко тормозить при любой скорости процессора. Если же все иконки заменить на .svg, то в половине случаев страничка перестает открываться в десктопном фаерфоксе и начинает жесточайше тормозить в гуглохромах с периодическими зависаниями. Отсюда вопрос — чем заменить растр в случае если переход к одноцветным шрифтовым иконкам это «не вариант» по мнению заказчика, который всегда прав?
Плюс ко всему где взять дизайнера, который может толково рисовать что-то в векторе и насколько это будет дороже? :)
А есть какая-нибудь вменяемая альтернатива многоцветным иконкам с тенями?
Фотографии красивые :) Но почему именно uleFone? Или имеется какой-либо положительный опыт по длительно-безглючному использовании этой модели? Или она чем-то выделяется из остальных двух десятков подозрительно незнакомых марок китайских фаблетов?
странно что все совместимые катриджи свалены в одну кучу. Там же даже среди разных моделей одного производителя качество отличается как небо и земля. Т.е. в одном конкретном случае какой-нибудь кактус ведет себя очень и очень прилично, а в другом типе принтеров тот же кактус вполне может засыпать все внутренности толстым слоем тонера. Так что табличка по производителям/моделям была бы очень в тему :)
а я через AviSynth и x264 :) Поэтому 2 файла.
Первый — mkv-source.avs:
FFVideoSource("D:\Video\test4\Avatar.Remux.1080p.enc.stress-test-sample4.mkv")

и второй — x264-fast.cmd:
"D:\x264\x264.exe" "D:\Video\test4\mkv-source.avs" --force-cfr --crf 19 --crf-max 24  --level 4.1 --ref 1 --me dia --subme 2 --analyse none --bframes 1 --no-b-adapt --no-chroma-me --output "D:\Video\test4\video_fast.mkv"
pause
Хм… 3.3 сек не получилось, но у меня и процессор попроще. Быстрее 7.3 сек не смог, но так думаю что x264 на Ксеноне с параметрами
--ref 2 --me dia --subme 2 --analyse none --bframes 1 --no-b-adapt --no-chroma-me
будет быстрее 5 сек
Вот мой семисекундный лог
x264 [info]: profile High, level 4.1
x264 [info]: frame I:8     Avg QP:18.30  size:202347
x264 [info]: frame P:264   Avg QP:20.06  size:130896
x264 [info]: frame B:260   Avg QP:21.64  size: 65315
x264 [info]: consecutive B-frames:  2.3% 97.7%
x264 [info]: mb I  I16..4:  5.5% 55.4% 39.1%
x264 [info]: mb P  I16..4: 35.8%  0.0%  0.0%  P16..4: 63.3%  0.0%  0.0%  0.0%  0.0%    skip: 0.9%
x264 [info]: mb B  I16..4: 14.6%  0.0%  0.0%  B16..8: 41.0%  0.0%  0.0%  direct:
30.0%  skip:14.4%  L0:28.9% L1:31.1% BI:39.9%
x264 [info]: 8x8 transform intra:3.2% inter:64.3%
x264 [info]: coded y,uvDC,uvAC intra: 84.6% 79.8% 30.4% inter: 69.2% 52.3% 6.3%
x264 [info]: i16 v,h,dc,p: 13% 43% 29% 15%
x264 [info]: i8 v,h,dc,ddl,ddr,vr,hd,vl,hu: 10% 30% 27%  3%  5%  3%  5%  4% 13%
x264 [info]: i4 v,h,dc,ddl,ddr,vr,hd,vl,hu: 15% 20% 12%  9% 10%  8%  9%  7% 10%
x264 [info]: i8c dc,h,v,p: 48% 32% 16%  4%
x264 [info]: Weighted P-Frames: Y:0.4% UV:0.0%
x264 [info]: kb/s:19165.41

encoded 532 frames, 73.38 fps, 19165.69 kb/s
И сравнение скриншотов, из которого видно что x264 оставляет намного больше деталей и дает намного меньше мыла
screenshotcomparison.com/comparison/82905
И даже если сжать битрейт в 2 раза x264 все еще выглядит сравнимо
screenshotcomparison.com/comparison/82908

Так что в результате можно сказать что Quick Sync с битрейтом на 70% выше обеспечивает качество сравнимое с x264 при выигрыше во времени кодирования от 70 до 150%

PS. Файлы с результатами быстрого кодирования с помощью x264 вот тут
yadi.sk/i/YKJY-0c_WKh5B
yadi.sk/d/Cgmin8rNWKh9o
А сколько времени заняло кодирование отрывка из Аватара в Quick Sync? Попытаюсь набросать командную строчку для x264 со сравнимым качеством за сравнимое время.
И дался вам этот ffmpeg :) Он в 264 кодировал всегда по принципу побыстрее-посмешнее. И в замыленности как раз все и дело — в результате пропадает большая часть мелких деталей.
Спасибо и теперь можно посравнивать :) В принципе все как я и думал — качество Quick Sync сравнимо с самым быстрым пресетом софтверного x264 и еще не факт кто из них окажется быстрее :)
Для иллюстрации сравнение скриншотов — Quick Sync 20 Мб/c с медленным x264 битрейтом в 2 раза ниже. Вот с этим
yadi.sk/i/SDQIG2dXWHhrC
Очевидно что у x264 в 2 раза меньшего размера качество заметно выше
screenshotcomparison.com/comparison/82845
И до кучи сравнение с исходником
screenshotcomparison.com/comparison/82846
В таком случае теряется смысл объективных тестов :) «исходник» сам по себе замыленный и с кучей артефактов. Т.е. суть статьи сводится ко фразе «на глаз вроде бы ничего так» :)
А для настоящих тестов лучше было бы воспользоваться уже ставшим стандартным 22-х секундным отрывком брызги-дерево-туман из Автара. Там бы сразу стало ясно по скриншотам что из себя представляет какой-либо из типов кодирования.
Если интересно, то вот этот отрывок на яндекс диске (40Мб)
yadi.sk/i/lcSv-PTMWGeTf
А почему у закодированного фрагмента размер почти в 2 раза больше чем у исходника? В чем физический смысл кодирования с таким задранным битрейтом? :)
так выложили бы и исходный файл? :) чтобы было с чем сравнивать
Я же говорю что заминусуют, начнут навязывать и говорить что значки четверки в 100 раз лучше :)
А ведь я не говорил что они хуже — я просто сказал что мне они не нравятся :)
А расход батарейки в покое измеряю в PowerTutor за ночь и отнимаю от общей цифры расход самого PowerTutor
Заминусуют конечно, но меня вот 4-й андроид просто злит внешне. Не могу себя заставить привыкнуть к этом идиотским иконкам, а нормального лаунчера похожего внешне на 2.3 найти пока не удается. Терплю, но злит… К тому же на старом каптивейте мне жуткими ухищрениями удавалось заставить 2.3 потреблять 34 mW в режиме ожидания. А с четверкой на этом же телефоне так и не получилось снизить ниже 85 mW. Это при том, что для этого телефона стоковая 2.3 потребляла 480 mW, а стоковая 4 — 290 mW
Главное в жизни веб девелопера не знание спецификаций. Их тоже конечно нужно знать, но без здравого смысла и умения выражать свои мысли все будет намного печальней. Вы внимательно перечитайте свои сообщения и поставьте себя на место начинающего разработчика — он же застрелится от бессилия в попытках вникнуть в поток сознания в разговорах типа нашего с вами? :)
Так я не же не говорил что это «неправильно» :) По-моему урл, который видит пользователь (чаще всего видит) должен быть коротким, читаемым и в идеале вбиваемым вручную.

PS А фразу «то, что не изменяет данные, передается гетом» это как следует понимать? :) post изменяет данные во время передачи, гетом нужно передавать только то, что никогда не изменяется (зачем только тогда это передавать непонятно) или о чем это вообще?
Пусть бы лучше новички совершали эту ошибку почаще чем оставляли все как есть…
И кстати по-моему что-то кроме цифр передавать через гет просто некрасиво :)
кстати да — торможу насчет crf и виноват — давно не кодировал и все позабылось…

Информация

В рейтинге
6 260-й
Откуда
Самара, Самарская обл., Россия
Дата рождения
Зарегистрирован
Активность