А в начале захватывал в AVI. Видео со звуком всегда расходилось при этом, причём, насколько помню каждый раз по-разному. Даже скрипт для корректировки расхождения на пайтоне написал исходя из предположения о линейной зависимости, пока не пришёл к описанному выше варианту.
Да, я тоже пробовал аналогично корректировать рассинхрон, но такой линейный подход работал не всегда. В конце концов выяснил, что рассинхрон вызывали две независимые причины: (1) разные частоты аудио и видео; (2) дропы кадров, когда видеопоток прерывался
И если с (1) линейная подгонка работала хорошо, то с (2) вообще никак не помогала.
Я как-то лет 10 назад, когда учился в универе, занялся оцифровкой домашнего архива VHS
Денег у студентов конечно же нет, поэтому был выбран бюджетный вариант: куплена самая стандартная карта захвата (вроде бы от beholder), использовался её же софт для захвата видео (без компрессии), VHS магнитофон взят из дома (panasonic из 90х)
Самой большой проблемой была десинхронизация аудио и видео при захвате, получилось её побороть захватом в ASF контейнер, который сохраняет синхронизацию за счет поддержки variable frame rate VFR (метод был прочитан на каком-то форуме). Потом VFRASF перегонялся в CFRAVI (25 кадров в секунду) через mencoder.
Минимальная обработка (убрать шумы, обрезать мусор по краям и т д) делалась через avisynth. Цель: убрать неразличимые глазом шумы, чтобы снизить размер сжатого файла, минимально улучшить картинку.
Деинтерлейсинг я в итоге не стал делать, так как ни один доступный мне тогда деинтерлейсер не показал достойное качество, все мазали картинку. Решено было сохранить оригинальную чересстрочную картинку. Её было комфортно и так смотреть, а при необходимости деинтерлейсинг всегда можно включить непосредственно в плеере
Конечный результат кодировался в x264 и сохранялся в MKV. Аудио тривиально кодировалось из несжатого CFRAVI в m4a используя ffmpeg и тоже добавлялось в MKV
Весь пайплайн был автоматизирован скриптом и выглядел как-то так: VFR ASF -> mencoder -> CFR AVI -> avisynth -> x264 -> MKV.
Запись одной кассеты занимала часа 3, последующая конвертация еще часов 10. Можно было параллелить это и одновременно записывать на одном компе и конвертировать на другом. Исходный несжатый ASF файл для трехчасовой кассеты занимал 90GB, финальный MKV 4-7 GB. Качество получалось идентично тому, что видно на экране в лайве, артефакты компрессии глазу не видны совсем.
Получился в итоге довольно интересный студенческий проект на лето, было интересно поэкспериментировать с технологиями видеозаписи и видеокомпрессии.
Вот да, на ревью таких коллег сразу начинаешь тратить слишком много времени, и отношение закономерно портится
Ещё ии очень любит всякие классические алгоритмы имплементировать полностью, хоть для них и есть готовые решения в библиотеках (так как ии обучался на leetcode/codeforces, а код там и код в проде – разные вещи). Теперь отдельное "удовольствие" во время ревью – это искать нужнуе библиотечные функции для замены кучи сгенеренного кода
А в чем преимущества этого решения по сравнению о обычным локальным зашифрованным хранилищем паролей? (тот же опенсорсный KeePassXC хранит пароли в локальном kdbx файле)
Синхронизировать можно руками или через облака. Если хочется доп безопасности при синхронизации через облака, то можно файл "портить" перед загрузкой в облако или разделять на части по разным облачным провайдерам, для этого вроде тоже есть около стандартные решения
Последний график с изменением ожидаемой продолжительности жизни за последние 250 лет очень красивый. Но он показывает продолжительность жизни с момента рождения (live expectancy at birth). Насколько мне известно, детская смертность была очень высокой вплоть до 20-го века и сильно занижала общую продолжительность жизни (что мы и видим на этом графике).
Есть ли где-то аналогичный график, но про ожидаемую продолжительность жизни начиная с 15, 20, 30 лет? Я сходу не смог найти
Похожим образом также обходится фича, когда отправитель запрещает скачивать/пересылать файл
То есть файл ты видишь, но скачать не можешь, скриншоты телега тоже в этот момент отключает.
Но в момент отображения файл сохраняется в локальное хранилище/кэш .../Android/data/org.telegram.messenger/files/... и его потом можно оттуда скачать, даже рут не нужен
По сути эти фракталы на графике говорят нам о необычности распределения разностей между нулями Зета функции
Можно почитать разные научные статьи, которые исследуют это, скорее всего где-то там найдётся ответ.
Например, работа 1987-го года "On the Distribution of Spacings Between Zeros of the Zeta Function" by A. M. Odlyzko [pdf] исследует это распределение (но несколько другими методами) и связывает аномалии с распределением простых чисел:
The peaks of $f(x)$ occur near $x = 2(\log N)^{-1} \log q$, where $q$ is a prime power, and the spikes in Figure 13 are due to 2, 3, 4, 5, 7, 8, 9, 11, 13, 16. 17, and 19, in that order, with proper prime powers having smaller peaks than primes. The explanation for this behavior of the spectrum of the $\delta_n$ lies in the formulas that connect zeros of the zeta function and prime numbers.
Да, я тоже пробовал аналогично корректировать рассинхрон, но такой линейный подход работал не всегда. В конце концов выяснил, что рассинхрон вызывали две независимые причины: (1) разные частоты аудио и видео; (2) дропы кадров, когда видеопоток прерывался
И если с (1) линейная подгонка работала хорошо, то с (2) вообще никак не помогала.
Я как-то лет 10 назад, когда учился в универе, занялся оцифровкой домашнего архива VHS
Денег у студентов конечно же нет, поэтому был выбран бюджетный вариант: куплена самая стандартная карта захвата (вроде бы от beholder), использовался её же софт для захвата видео (без компрессии), VHS магнитофон взят из дома (panasonic из 90х)
Самой большой проблемой была десинхронизация аудио и видео при захвате, получилось её побороть захватом в
ASFконтейнер, который сохраняет синхронизацию за счет поддержки variable frame rateVFR(метод был прочитан на каком-то форуме). ПотомVFRASFперегонялся вCFRAVI(25 кадров в секунду) черезmencoder.Минимальная обработка (убрать шумы, обрезать мусор по краям и т д) делалась через
avisynth. Цель: убрать неразличимые глазом шумы, чтобы снизить размер сжатого файла, минимально улучшить картинку.Деинтерлейсинг я в итоге не стал делать, так как ни один доступный мне тогда деинтерлейсер не показал достойное качество, все мазали картинку. Решено было сохранить оригинальную чересстрочную картинку. Её было комфортно и так смотреть, а при необходимости деинтерлейсинг всегда можно включить непосредственно в плеере
Конечный результат кодировался в
x264и сохранялся вMKV. Аудио тривиально кодировалось из несжатогоCFRAVIвm4aиспользуяffmpegи тоже добавлялось вMKVВесь пайплайн был автоматизирован скриптом и выглядел как-то так: VFR ASF -> mencoder -> CFR AVI -> avisynth -> x264 -> MKV.
Запись одной кассеты занимала часа 3, последующая конвертация еще часов 10. Можно было параллелить это и одновременно записывать на одном компе и конвертировать на другом. Исходный несжатый
ASFфайл для трехчасовой кассеты занимал 90GB, финальныйMKV4-7 GB. Качество получалось идентично тому, что видно на экране в лайве, артефакты компрессии глазу не видны совсем.Получился в итоге довольно интересный студенческий проект на лето, было интересно поэкспериментировать с технологиями видеозаписи и видеокомпрессии.
Вот да, на ревью таких коллег сразу начинаешь тратить слишком много времени, и отношение закономерно портится
Ещё ии очень любит всякие классические алгоритмы имплементировать полностью, хоть для них и есть готовые решения в библиотеках (так как ии обучался на leetcode/codeforces, а код там и код в проде – разные вещи). Теперь отдельное "удовольствие" во время ревью – это искать нужнуе библиотечные функции для замены кучи сгенеренного кода
Да, если нужен шеринг паролей с другими пользователяси и контроль доступов, то такое решение выглядит действительно оправданным
А в чем преимущества этого решения по сравнению о обычным локальным зашифрованным хранилищем паролей? (тот же опенсорсный KeePassXC хранит пароли в локальном kdbx файле)
Синхронизировать можно руками или через облака. Если хочется доп безопасности при синхронизации через облака, то можно файл "портить" перед загрузкой в облако или разделять на части по разным облачным провайдерам, для этого вроде тоже есть около стандартные решения
Учитывая капитал Сергея Брина, для него нанять домохозяйку на фуллтайм значительно дешевле, чем обычному человеку купить стакан кофе
Последний график с изменением ожидаемой продолжительности жизни за последние 250 лет очень красивый. Но он показывает продолжительность жизни с момента рождения (live expectancy at birth). Насколько мне известно, детская смертность была очень высокой вплоть до 20-го века и сильно занижала общую продолжительность жизни (что мы и видим на этом графике).
Есть ли где-то аналогичный график, но про ожидаемую продолжительность жизни начиная с 15, 20, 30 лет? Я сходу не смог найти
Похожим образом также обходится фича, когда отправитель запрещает скачивать/пересылать файл
То есть файл ты видишь, но скачать не можешь, скриншоты телега тоже в этот момент отключает.
Но в момент отображения файл сохраняется в локальное хранилище/кэш
.../Android/data/org.telegram.messenger/files/...и его потом можно оттуда скачать, даже рут не нуженПо сути эти фракталы на графике говорят нам о необычности распределения разностей между нулями Зета функции
Можно почитать разные научные статьи, которые исследуют это, скорее всего где-то там найдётся ответ.
Например, работа 1987-го года "On the Distribution of Spacings Between Zeros of the Zeta Function" by A. M. Odlyzko [pdf] исследует это распределение (но несколько другими методами) и связывает аномалии с распределением простых чисел: