Мы с вами определенно пользовались разными скриптами.
Не удивительно, ведь идея лежала не поверхности. Удивительно именно то, как долго не закрывали внешний доступ к ftp. В случае скрипта, о котором я говорю, phproxy использовался именно для возможности скачивания с rapidshare / megaupload и т.п. без лишних телодвижений как со стороны юзера, так и со стороны создателя скрипта. Ибо простой копипастой ссылки на файл там было не обойтись.
20 * 1024 / 128 = 160 секунд. 30 * 1024 / 128 = 240 секунд. Речь про 128 кило БАЙТ, не кило БИТ. Столько лет прошло, а после этой заметки эта магическая цифра всплыла в памяти. Плюс, по вышеуказанной причине не было смысла усложнять скрипт до поддержки списка закачек, ибо это не принесло бы существенной пользы. Поэтому список закачек при необходимости реализовывался как список открытых табов браузера, т.к. скрипт был просто модификацией скрипта phproxy с патчами совместимости с популярными тогда файлопомойками и с прикрученной заливкой на ftp и кривым, но рабочим прогрессбаром процесса заливки. Хотя, возможно, были и другие скрипты в параллельной вселенной, но я знаю только об одном. З.Ы. почему-то мне помнится, они так и не отключили этот ftp до момента прихода безлимитов в 2009 году, когда YOTA вынудила провайдеров уйти от подсчёта трафика.
Что особенно удивительно, учитывая что канал на тот самый FTP был один на всех и ширина его была что-то на уровне 128 Кбайт/с. И при активной утилизации этого канала кучей пользователей должны бы были заметить куда как быстрее.
Туда им дорога. Даже обычные офисные мембранки разучились делать, никакого сравнения с 15 летними KB-06x, которые до сих пор как новые если их отмыть. Теперь-же просто ватные нажатия кнопок (как и почти на всех мембранках на рынке) и к стойкости краски нет никакого доверия. Зато A4-Tech в ножничной KV-300H теперь что-то поменяла в мембране либо в механизме ножниц при апгрейде на функцию мульмедиа клавиш с год назад, печатать одно удовольствие теперь. Явно заметна разница с прошлой ревизией, в лучшую сторону. Вот бы ещё сделали русскую раскладку другого цвета и корпус просто чёрным, без серебрянки.... Эх, мечты мечты...
При чём здесь компилирование из консоли, если эти директивы компилятора для range check указываются прямо в коде для участков кода, где их требуется применять (либо для всего модуля целиком)? Это и просто и наглядно.
В любом случае, это ещё один момент, который можно записать в плюсы Паскаля как языка для обучения программированию: простые директивы, которым можно (и нужно) обучать мимоходом, как само собой разумеющемуся. Не углубляясь в дебри ключей компиляции Cи-компиляторов.
Так а где не будет? В C/C++? Паскаль хотя бы от указателей позволяет абстрагироваться в параметрах функции человеческим методом с помощью var, и объявления/разыменования указателя используют один и тот-же символ ^. Вот от мешанины * и & у новичков в С/С++ явно льются слёзы в три ручья. А уход счётчика за рамки лучше отловить на стадии ошибок в рантайме, чем в итоге так и не понять, почему программа делает не то, что от неё предполагалось. В конце-концов Паскаль позволяет индексировать массивы от нуля, что и стоит прививать ученикам изначально, чтобы они потом не страдали при переключении между языками. А сама необходимость объявлять переменные и типы в отдельных секциях лишний раз заставляет начать продумывать алгоритм на начальных стадиях и оптимизировать количество переменных.
Там далеко не $1000 в год на обслуживание. Там скорее штука за один выезд специалиста, если он провозился более 30 минут. Более подробная инфа, включая расценки на работы, есть в видео на ютубе «The REAL Reason McDonalds Ice Cream Machines Are Always Broken». Ну и не забываем про потерю денег рестораном, когда машины простаивают.
Вот это расследование Из которого я, правда, так и не понял, почему-же у Wendy's проблем с простоем машин не наблюдается, хотя и упоминается, что они тоже используют Taylor.
Ещё-бы ожидать от тебе я другой рекомендации ;) Да запоздал ты чутка, никто уже не прочитает. Пили свою статью о граблях, я тут выше уже коммент накатал на половину оной.
Теперь баллы дают и за эконом. Именно баллы, а не скидку. Которые потом можно потратить на поездку. Так вот возможно именно из-за этой ранее активной подписки у них бага в коде. Случайная или намеренная. А, возможно, просто оценивают по другим критериям «лояльности» с кого можно взять больше.
Дело может быть в том числе и в т.н. автофреймрейте. В случае с компом воспроизведение контента в 24 идёт с частотой 60 Гц, т.е. получаем конвертацию на лету по принципу 3:2 pulldown, в случае-же воспроизведения силами самого телевизора телевизор пытается подстроить частоту обновления панели под частоту контента. Для 24 FPS это обычно 24Гц, для 25 и 30 FPS — 50 и 60 Гц соответственно.
Вот как раз последний случай восстановления мозгов случился после подобной магии: контроллер отказывался жить бок о бок с каким либо другим диском, кроме своего первого напарника. Который начал активно сыпаться. В итоге, если не ошибаюсь, после нескольких перетыканий контроллер отказался работать даже с тем единственным. Но тут могу и ошибаться. В любом случае, именно процедура восстановления полностью решила проблему. Хотя сама прошивка и до этого была последняя.
У моего контроллер окирпичивался минимум дважды. Оба раза был успешно восстановлен чисто софтовым способом. Последний раз года полтора назад. С тех пор я опять активно использую, минимум раз в неделю, проблемы доставляет разве что его качелька вместо полноценных кнопок. Если бокс всё ещё на руках, пишите, пороюсь в закромах на предмет названия утилиты и способа восстановления.
А на предмет поддержки DDC телевизор не щупали? В случае с мониторами всё работает из коробки. Есть как готовые утилиты, так и способы прямой подачи команд через API Windows. В случае поддержки со стороны телевизора способ не потребует никаких адаптеров.
С Андроидом ситуация не просто печальней, а абсолютно никудышная. Вплотную интересовался я этой ситуацией ровно год назад, из-за непредвиденных обстоятельств пришлось отложить эти хотелки в долгий ящик, а там и энтузиазм пропал. В итоге по памяти на данный момент могу восстановить следующую картину, сложенную тогда по результатам экспериментов, просмотра обзоров и обсуждений:
1. Несмотря на то, что Camera2 API на бумаге даёт возможность очень гибко управлять параметрами съёмки, конечные устройства вольны поддерживать или не поддерживать отдельные фичи и отдельные вариации этих фич.
2. Со стороны разработчика (а в конечном счёте и пользователя) наивно верить тому, что рапортует устройство по поводу поддержки фич и текущих параметрах съёмки. Далее поясню на примерах.
Zenfone 4 рапортует о поддержке аж 512 точек тоновых кривых, которыми можно скорректировать гамму на первичных этапах конвейера ещё до того как картинка преобразуется в YUV и будет доступна нам для дальнейших манипуляций, и в итоге получить некое подобие LOG-профилей с сохранением максимально возможного динамического диапазона (именно таким образом работают эти профили в Filmic с осени 2018 года). Но при этом никакими ухищрениями заставить Zenfone 4 начать реально применять эти тоновые кривые не получилось. В итоге эти профили не работают ни в Filmic, ни в OpenCamera.
Оптическая стабилизация в Zenfone 4 работает только если мы инициализируемся в режиме ручной экспозиции, но при автоматической экспозиции операционка нам будет так-же будет рапортовать о том, что с OIS у нас всё ок, но глазами мы видим обратное. Ручной фокус якобы поддерживается, но не работает.
Ок, скажем мы, это-же какой-то там никому не нужный Zenfone. Но когда я попытался сравнить разницу 4k между ним и Galaxy s10e, то выяснилось, что картинка с galaxy выглядит резче только лишь за счёт того, что Samsung решил сделать «резкость» (EDGE MODE) неотключаемой. В деталях разницы нет (текст, ветки вдалеке), а в итоге картинку с Zenfone 4 при отключенном шумодаве и резкости вполне можно принять за съёмку недорогой беззеркалкой или хотя бы компактом, когда в случае с флагманской моделью Samsung мы сразу видим, что снимали на мобилу.
При этом имеет место быть обратная ситуация: практически все устройства занижают рапортуемые максимальные битрейты в сравнении с тем, что они реально могут вытянуть. Zenfone 4 соглашался писать в 300 или в 350 Мбит, выдавая ошибку при попытке запросить больше. При этом рапортовал о верхнем пороге в 150. У s10e нащупать верхний порог не получилось, но по факту видео начинает спотыкаться об скорость записи на накопитель уже при битрейтах в 500 Мбит.
3. Опять эти вездесущие грабли с Full range vs Limited range. Zenfone 4 отдаёт видео в Full range, чего старый Filmic с шейдерной реализацией log-профилей никак не ожидал. В недрах кода происходило преобразование из limited в full, в итоге в шейдеры поступали данные, выходящие за пределы допустимого диапазона. В тенях логарифм log-профилей начинал выгибать тени в обратную сторону, беря логарифмы от отрицательных чисел, а света просто резались по верхней отсечке после пересчёта.
4. Camera2 API позволяет использовать два подхода к кодированию и записи видео. Первый, который использует OpenCamera: полностью отдаём всю работу на откуп системе, выступая дирижёром этого оркестра. Второй, который использует Filmic: получем полусырые данные и имеем возможность более гибко манипулировать как данными, так и этапами кодировки и сохранения потока. Но это накладывает необходимость выстраивать весь конвеер самостоятельно, следить за равномерностью поступления и сохранения данных и костыля кучу костылей по дороге, чтоб везде работало и нигде не падало. При этом по состоянию на начало 2019 года системный муксер, применяемый для сохранения сжатых аудио и видео потоков в файл имел забавный баг на большинстве устройств: он падал с ошибкой превышения допустимого размера файла после отметки в 4Гб даже если файловая система не накладывала таких ограничений. При этом в недрах либы предусмотрена возможность заранее указать следущий файловой дескриптор для бесшовного сохранения видео, но эта фича не реализована в API напрямую. В итоге бедный фильмик кромсает это всё кусками как у него получается, и не факт что нет дропов кадров и синхронизация видео с аудио не идёт в разнос. С битрейтами в 200 Мбит/с видео будет кусковаться по 171 секунде. При этом подход OpenCamera лишён этого недостатка, но упирается в лимит аудиобитрейта, который чаще всего установлен в 96 кбит/с. Так-же этот подход не лишён проблем боттлнеков, на которые в этом случае нет возможности не только повлиять, но даже и задетектировать выпавшие кадры.
5. Выпадение кадров. По моим наблюдениям на тот период страдали все, включая Huawei P30 Pro, изначально позиционируемый как телефон для съёмки видео. Выпадения случаются как на стоковых камерах, так и в OpenCamera. Фильмик же, особенно последних версий, своей прожорливостью только усугублял ситуацию, никак не предупреждая пользователя о дропах. Узнать о них косвенно можно по заниженному итоговому фреймрейту, но лучше полюбоваться на график в утилите QCTools.
6. Многие телефоны при записи видео активно используют всяческие улучшайзеры. И если на Zenfone 4 мне процессинг даже нравится, то Xiaomi поголовно вплоть до их последних новинок всё душила ужасным шумодавом. При этом в теории это должно решаться выбором в качестве источника аудио Unprocessed, но очень редкие приложения позволяют это сделать (Из Filmic было выпилено год назад, в OpenCamera доступны все источники).
7. «Но вот CameraAPI2 нормального не завезли, как и поддержки доп камер для сторонних приложений.» — а вот и завезли поддержку доп камер, скорее всего. Мной была найдена ещё одна недокументированная фича: на чуть ли не половине девайсов к камерам можно получить доступ, если просто пытаться его получить. Т.е. просто игнорим рапортуемый список камер и перебираем вплоть до 50го сенсора. Ибо на некоторых Xiaomi допники идут под id 20 и 21.
А теперь, внимание, вопрос: на каких форумах и в каких обзорах можно почерпнуть эту информацию по девайсу, который предполагается активно использовать для съёмки видео?
P.S. комментарий тянет на мини статью, но «Взялся за гуж — не говори, что не дюж» :) Нужно было это всё где-то подытожить. И отдельное спасибо за приложение для yongnuo yn-360, их китайское поделие реально убого.
Не удивительно, ведь идея лежала не поверхности. Удивительно именно то, как долго не закрывали внешний доступ к ftp. В случае скрипта, о котором я говорю, phproxy использовался именно для возможности скачивания с rapidshare / megaupload и т.п. без лишних телодвижений как со стороны юзера, так и со стороны создателя скрипта. Ибо простой копипастой ссылки на файл там было не обойтись.
20 * 1024 / 128 = 160 секунд. 30 * 1024 / 128 = 240 секунд. Речь про 128 кило БАЙТ, не кило БИТ. Столько лет прошло, а после этой заметки эта магическая цифра всплыла в памяти. Плюс, по вышеуказанной причине не было смысла усложнять скрипт до поддержки списка закачек, ибо это не принесло бы существенной пользы. Поэтому список закачек при необходимости реализовывался как список открытых табов браузера, т.к. скрипт был просто модификацией скрипта phproxy с патчами совместимости с популярными тогда файлопомойками и с прикрученной заливкой на ftp и кривым, но рабочим прогрессбаром процесса заливки. Хотя, возможно, были и другие скрипты в параллельной вселенной, но я знаю только об одном. З.Ы. почему-то мне помнится, они так и не отключили этот ftp до момента прихода безлимитов в 2009 году, когда YOTA вынудила провайдеров уйти от подсчёта трафика.
Что особенно удивительно, учитывая что канал на тот самый FTP был один на всех и ширина его была что-то на уровне 128 Кбайт/с. И при активной утилизации этого канала кучей пользователей должны бы были заметить куда как быстрее.
Туда им дорога. Даже обычные офисные мембранки разучились делать, никакого сравнения с 15 летними KB-06x, которые до сих пор как новые если их отмыть. Теперь-же просто ватные нажатия кнопок (как и почти на всех мембранках на рынке) и к стойкости краски нет никакого доверия. Зато A4-Tech в ножничной KV-300H теперь что-то поменяла в мембране либо в механизме ножниц при апгрейде на функцию мульмедиа клавиш с год назад, печатать одно удовольствие теперь. Явно заметна разница с прошлой ревизией, в лучшую сторону. Вот бы ещё сделали русскую раскладку другого цвета и корпус просто чёрным, без серебрянки.... Эх, мечты мечты...
При чём здесь компилирование из консоли, если эти директивы компилятора для range check указываются прямо в коде для участков кода, где их требуется применять (либо для всего модуля целиком)? Это и просто и наглядно.
В любом случае, это ещё один момент, который можно записать в плюсы Паскаля как языка для обучения программированию: простые директивы, которым можно (и нужно) обучать мимоходом, как само собой разумеющемуся. Не углубляясь в дебри ключей компиляции Cи-компиляторов.
Так а где не будет? В C/C++? Паскаль хотя бы от указателей позволяет абстрагироваться в параметрах функции человеческим методом с помощью var, и объявления/разыменования указателя используют один и тот-же символ ^. Вот от мешанины * и & у новичков в С/С++ явно льются слёзы в три ручья. А уход счётчика за рамки лучше отловить на стадии ошибок в рантайме, чем в итоге так и не понять, почему программа делает не то, что от неё предполагалось. В конце-концов Паскаль позволяет индексировать массивы от нуля, что и стоит прививать ученикам изначально, чтобы они потом не страдали при переключении между языками. А сама необходимость объявлять переменные и типы в отдельных секциях лишний раз заставляет начать продумывать алгоритм на начальных стадиях и оптимизировать количество переменных.
Включая LG G2. Который лечили утюгом. Так что может это и к лучшему, что LG в итоге сдались и сворачивают мобильное подразделение.
1. Несмотря на то, что Camera2 API на бумаге даёт возможность очень гибко управлять параметрами съёмки, конечные устройства вольны поддерживать или не поддерживать отдельные фичи и отдельные вариации этих фич.
2. Со стороны разработчика (а в конечном счёте и пользователя) наивно верить тому, что рапортует устройство по поводу поддержки фич и текущих параметрах съёмки. Далее поясню на примерах.
Zenfone 4 рапортует о поддержке аж 512 точек тоновых кривых, которыми можно скорректировать гамму на первичных этапах конвейера ещё до того как картинка преобразуется в YUV и будет доступна нам для дальнейших манипуляций, и в итоге получить некое подобие LOG-профилей с сохранением максимально возможного динамического диапазона (именно таким образом работают эти профили в Filmic с осени 2018 года). Но при этом никакими ухищрениями заставить Zenfone 4 начать реально применять эти тоновые кривые не получилось. В итоге эти профили не работают ни в Filmic, ни в OpenCamera.
Оптическая стабилизация в Zenfone 4 работает только если мы инициализируемся в режиме ручной экспозиции, но при автоматической экспозиции операционка нам будет так-же будет рапортовать о том, что с OIS у нас всё ок, но глазами мы видим обратное. Ручной фокус якобы поддерживается, но не работает.
Ок, скажем мы, это-же какой-то там никому не нужный Zenfone. Но когда я попытался сравнить разницу 4k между ним и Galaxy s10e, то выяснилось, что картинка с galaxy выглядит резче только лишь за счёт того, что Samsung решил сделать «резкость» (EDGE MODE) неотключаемой. В деталях разницы нет (текст, ветки вдалеке), а в итоге картинку с Zenfone 4 при отключенном шумодаве и резкости вполне можно принять за съёмку недорогой беззеркалкой или хотя бы компактом, когда в случае с флагманской моделью Samsung мы сразу видим, что снимали на мобилу.
При этом имеет место быть обратная ситуация: практически все устройства занижают рапортуемые максимальные битрейты в сравнении с тем, что они реально могут вытянуть. Zenfone 4 соглашался писать в 300 или в 350 Мбит, выдавая ошибку при попытке запросить больше. При этом рапортовал о верхнем пороге в 150. У s10e нащупать верхний порог не получилось, но по факту видео начинает спотыкаться об скорость записи на накопитель уже при битрейтах в 500 Мбит.
3. Опять эти вездесущие грабли с Full range vs Limited range. Zenfone 4 отдаёт видео в Full range, чего старый Filmic с шейдерной реализацией log-профилей никак не ожидал. В недрах кода происходило преобразование из limited в full, в итоге в шейдеры поступали данные, выходящие за пределы допустимого диапазона. В тенях логарифм log-профилей начинал выгибать тени в обратную сторону, беря логарифмы от отрицательных чисел, а света просто резались по верхней отсечке после пересчёта.
4. Camera2 API позволяет использовать два подхода к кодированию и записи видео. Первый, который использует OpenCamera: полностью отдаём всю работу на откуп системе, выступая дирижёром этого оркестра. Второй, который использует Filmic: получем полусырые данные и имеем возможность более гибко манипулировать как данными, так и этапами кодировки и сохранения потока. Но это накладывает необходимость выстраивать весь конвеер самостоятельно, следить за равномерностью поступления и сохранения данных и костыля кучу костылей по дороге, чтоб везде работало и нигде не падало. При этом по состоянию на начало 2019 года системный муксер, применяемый для сохранения сжатых аудио и видео потоков в файл имел забавный баг на большинстве устройств: он падал с ошибкой превышения допустимого размера файла после отметки в 4Гб даже если файловая система не накладывала таких ограничений. При этом в недрах либы предусмотрена возможность заранее указать следущий файловой дескриптор для бесшовного сохранения видео, но эта фича не реализована в API напрямую. В итоге бедный фильмик кромсает это всё кусками как у него получается, и не факт что нет дропов кадров и синхронизация видео с аудио не идёт в разнос. С битрейтами в 200 Мбит/с видео будет кусковаться по 171 секунде. При этом подход OpenCamera лишён этого недостатка, но упирается в лимит аудиобитрейта, который чаще всего установлен в 96 кбит/с. Так-же этот подход не лишён проблем боттлнеков, на которые в этом случае нет возможности не только повлиять, но даже и задетектировать выпавшие кадры.
5. Выпадение кадров. По моим наблюдениям на тот период страдали все, включая Huawei P30 Pro, изначально позиционируемый как телефон для съёмки видео. Выпадения случаются как на стоковых камерах, так и в OpenCamera. Фильмик же, особенно последних версий, своей прожорливостью только усугублял ситуацию, никак не предупреждая пользователя о дропах. Узнать о них косвенно можно по заниженному итоговому фреймрейту, но лучше полюбоваться на график в утилите QCTools.
6. Многие телефоны при записи видео активно используют всяческие улучшайзеры. И если на Zenfone 4 мне процессинг даже нравится, то Xiaomi поголовно вплоть до их последних новинок всё душила ужасным шумодавом. При этом в теории это должно решаться выбором в качестве источника аудио Unprocessed, но очень редкие приложения позволяют это сделать (Из Filmic было выпилено год назад, в OpenCamera доступны все источники).
7. «Но вот CameraAPI2 нормального не завезли, как и поддержки доп камер для сторонних приложений.» — а вот и завезли поддержку доп камер, скорее всего. Мной была найдена ещё одна недокументированная фича: на чуть ли не половине девайсов к камерам можно получить доступ, если просто пытаться его получить. Т.е. просто игнорим рапортуемый список камер и перебираем вплоть до 50го сенсора. Ибо на некоторых Xiaomi допники идут под id 20 и 21.
А теперь, внимание, вопрос: на каких форумах и в каких обзорах можно почерпнуть эту информацию по девайсу, который предполагается активно использовать для съёмки видео?
P.S. комментарий тянет на мини статью, но «Взялся за гуж — не говори, что не дюж» :) Нужно было это всё где-то подытожить. И отдельное спасибо за приложение для yongnuo yn-360, их китайское поделие реально убого.