Новий реліз LIVR для JS/TS (2.12)
⚡ LIVR тепер найшвидший серед популярних JS-валідаторів (графіки в коментарях)
Раніше LIVR лідирував лише на динамічних правилах. Тепер він випереджає інші валадітори й на статичних. На динамічних правилах (холодний старт, новий валідатор на кожен виклик) він швидший за Zod у 86 разів, а за Ajv у 949 разів. Отже, фаза компіляції для швидкого валідатора не потрібна. Продуктивність не падає, коли правила формуються в рантаймі: зберігаються в базі, відрізняються для кожного клієнта чи приходять з іншого джерела.І безпекою жертвувати теж не треба, як це робить fastest-validator: він генерує JavaScript-код зі схеми, я вже заводив баг про RCE-вразливість.
🧠 Новий рушій статичної типізації
✅Strict-режим: TypeScript ще під час компіляції перевіряє, що кожне правило в схемі існує. Опечатка в назві правила стає помилкою компіляції.
✅Покращене виведення типів: type User = InferFromSchema<typeof userSchema> дає максимально вузькі типи.
✅Простіший синтаксис оголошення типів для власних правил, як простих, так і складних.
declare module 'livr/types/inference' {
interface RuleTypes {
// As\<T>: правило перевіряє значення і не губить точніший тип попередніх правил
starts_with: As\<string>;
}
}
🌐 Окремий сайт для JS-версії - https://js.livr-spec.org та повністю оновлений https://livr-spec.org з вбудованим плейграундом.
💡 Чому LIVR:
✅ Правила валідації - це просто дані. Їх можна зберегти, сформувати динамічно, сконвертувати, передати мережею або просто описати в коді.
✅ Продуктивність. Найшвидший у бенчмарках, навіть із динамічними правилами.
✅ Розширюваність. Ядро мінімальне, усе інше реалізовано через правила. Навіть вкладені структури - це лише ще одне метаправило. Кожен проєкт може мати власну бібліотеку правил.
✅ Правила валідації це не просто опис валідації, а pipeline для обробки поля, який може валідувати й модифікувати значення. Наприклад, ['trim', 'required', 'email', 'toLc'].
✅ Автоматичне виведення типів зі схеми. Щоб отримати тип зі схеми, навіть не обов'язково використовувати сам валідатор.
✅ Нуль залежностей.
✅ Аліаси. Складні правила можна оформити як аліаси з власними кодами помилок.
✅ У продакшені з 2013 року і постійно розвивається.
БІЛЬШЕ ПРО АРХІТЕКТУРНІ РІШЕННЯ: http://github.com/koorchik/js-validator-livr/blob/master/docs/DESIGN.md#table-of-contents
Як вам апдейт?
NoTeleport - щоб навігатор не телепортував вас до Перу під час повітряної тривоги.
Створив додаток для Android, який рятує мене під час повітряних тривог і дозволяє навігації працювати коректно.
Що важливо:
✅Нічого нікуди не надсилає. У додатка взагалі немає доступу до інтернету.
✅Нічого про вас не збирає. Місцезнаходження обробляється лише на вашому телефоні.
✅Без реклами й аналітики. У додатку немає рекламних і сторонніх модулів, які щось про вас дізнаються.
✅Без реєстрації. Не потрібні ні обліковий запис, ні номер телефону.
🤓У телефоні є точне (GPS) та приблизне геопозиціонування (точки Wi-Fi та вишки мобільних операторів). Під час тривог через підміну координат GPS телепортує вас до Перу, тому я хотів змусити навігатори спиратися на приблизне геопозиціонування. Я вирішив створити додаток, який можна обрати в налаштуваннях розробника Android як додаток для фіктивних місцезнаходжень (Mock location app). Він мав би відстежувати факт GPS-спуфінгу та видавати натомість приблизні координати.
Я почав реалізовувати цей функціонал, але виявилося, що Google Maps, Waze та OsmAnd і так вміють це робити, якщо GPS недоступний (просто з GPS спуфінгом це не працює). Тобто моєму додатку було достатньо просто під час GPS-спуфінгу змусити телефон повірити, що сигнал GPS зараз відсутній.
Як поводяться різні додатки для навігації.
Почнемо з того, що в Android є три основні провайдери/API для геолокації:
📡 GPS Provider (LocationManager.GPS_PROVIDER) використовує супутники для точного позиціонування.
📶 Network Location Provider (LocationManager.NETWORK_PROVIDER) використовує точки Wi-Fi та вишки стільникового зв'язку для приблизного позиціонування.
🧩 Fused Location Provider API - сервіс від Google Play Services, який під капотом автоматично поєднує GPS, Wi-Fi, Bluetooth та мобільні мережі для оптимального визначення координат.
Що використовують карти?
📍 Карти Google використовують Fused API.
📍 Waze працює напряму з GPS Provider та Network Location Provider.
📍 OsmAnd - Fused API.
📍 OsmAnd~ - GPS Provider та Network Location Provider.
З AndroidAuto не працює (але пишіть, якщо є ідеї).
Якщо ви використовуєте AndroidAuto, то телефон не просто використовує авто як додатковий екран, а ще й отримує дані з GPS автомобіля, тому телепортація залишиться. Але тут багато залежить від самої машини: деякі автомобілі роблять екстраполяцію, спираючись на власні датчики (швидкість руху, кут повороту керма). Можливо, вже є авто, GPS-модулі яких апаратно ігнорують GPS-спуфінг.
Що не планую додавати в додаток
1. Підтримку iOS (в iOS не можна обрати додаток для підміни GPS).
Що можливо додам в додаток:
1. Підтримку Bluetooth OBD для отримання даних з діагностичного порта про швидкість руху авто, щоб робити проміжні прорахунки.
2. Можливо підтрику IMU, але треба тестувати, бо Fusion API й самі карти вже роблять досить багато й не факт, що варто.
САЙТ (запустив публічну бету додатку): https://noteleport.github.io/
Вже є гарні відгуки. Cам вже три тижні користуюся теж)
VidCtrl 0.4 (критичне оновлення для MacOs) - можете ставити зірочки на GitHub :)
Дуже вдячним всім за відгуки по програмі й допомогу з тестуванням ❤️
Що нового?
🛠 Власна збірка FFmpeg на всіх системах. Відео "Для архіву", стиснуте на MacBook, мало квадратики на обличчях в деякий відео. Той самий кліп, стиснутий на Linux, був чистий, а розмір майже однаковий. Заміри підтвердили різницю: 39,5 проти 41,4 dB за XPSNR, 92,5 проти 96 за VMAF.
Раніше VidCtrl брав готові збірки FFmpeg: на macOS від Martin Riedl, на Linux і Windows від BtbN. У збірці для Mac був свіжий FFmpeg 8.1.2, але не найновіший кодувальник AV1: SVT-AV1 3.1.2 замість 4.2. Його код для чипів Apple стискав гірше, ніж його ж звичайний код: той самий розмір, але виникали квадратики й вифіксити це неможливо. Автор збірки досі тримає цю версію, тож новіші готові збірки проблему не вирішують. Тепер VidCtrl збирає FFmpeg сам: FFmpeg 8.1.3 і SVT-AV1 4.2, з однаковими версіями всіх бібліотек на macOS, Windows і Linux. Перед кожним релізом кожна збірка проходить автоматичну перевірку якості: AV1 на тестовому кадрі мусить набрати понад 44 dB. Тепер усі три системи кодують однаково, до сотих, а проблемний кліп на Mac дає 41,4 dB і VMAF 96, як на Linux. Порявняв візуально на скріншотах - виглядає ідентично.
🐞 Знайшов баг у самому FFmpeg. Фільтр, що міряє XPSNR, неправильно читав 10-бітні кадри, ширина яких не кратна 32 (кожне вертикальне відео з телефона). Додав фікс в додаток й підготував патч для ffmpeg, щоб відправити в апстрім.
📏 Більше тестів й VMAF. "Для архіву" дає 42 dB+ і VMAF 95+ на тестових кліпах. На дуже зернистій 4K-зйомці буває 41,4 dB при VMAF 96, і різниці візуально не видно. Файли в 5–15 разів менші за оригінали з DSLR камери: 1,39 ГБ → 93 МБ.
🤓 "Порівняти з оригіналом" - в контекстому меню тепер є можливість запустити розрахунок XPSNR й VMAF для власного відео, якщо комусь це цікаво раптом
🍏 Покращено "Швидко" на Mac: файли в 2,3–2,7 раза менші, при тій самій близькості до оригіналу, що й AV1.
🎨 Точніший колір в AV1: файл тепер зберігає, як камера розташувала колірні відліки (chroma_location).
▶️ Кнопка перегляду в списку відео. Додали теку, і можна одразу глянути, що це за файли.
🔔 Повідомлення про нову версію. Коли вийде оновлення, біля адреси сайту з'явиться "Нова версія …".
VidCtrl - opensource конвертор відео під Linux/Mac/Windows про який я мріяв
Робив під свої задачі й головне для мене було:
✅Не змушувати мене кожен раз приймати рішення по кодекам й їх параметрам - я вже втомився від цього й хочу все в один клік.
✅Стиснути відео з дзеркальної камери до мінімального розміру, але БЕЗ ВИДИМОЇ ВТРАТИ ЯКОСТІ. Кліп з Nikon D780 на 1.4 ГБ стискається до 92 МБ без візуальнох ватрти якості.
✅Мати підтримку черги.
✅Мати можливість просто прогнати 10 секунди відрізки для тесту, а не повне відео.
✅Конвертувати відео для редагування в безкоштовній Davinci Resolve (наприклад, на Linux не читає H.264/H.265) й Davinci Resolve Studio (не читає AAC).
✅Швидкий перегляд всіх метаданих по відео й по кодекам. Й можливість прибрати метадані, щоб не було в відео PII.
✅Просто дістати аудіодоріжку в зручному мені форматі.
✅Поміняти контейнер для відео.
✅При бажанні можливість побачити деталізовану команду ffmpeg з повним описов всіх параметрів, що будуть використані (якщо раптом вирішу все ж такі запустит щось в консолі з іншими параметрами).
Програма це враппер над ffmpeg, який йде відразу в бандлі. Найбільше часу пішло на відлагодження параметрів ffmpeg і тюнінг UX.
Що таке без втрати якости й як це поміряти?
"На око не відрізнити" не є метрикою, але є XPSNR. Це PSNR, зважений за тим, наскільки різницю видно оку. Ціль - 42 dB по яскравості, це рівень, який вважають візуально без втрат. Міряв 10-секундні шматки 4K (Nikon з рук, відео машини в русі з телефона, слайдшоу з фото). Кожен енкодер (SVT-AV1, x265, AV1 і HEVC на NVENC) кодував різні відео на п'яти значеннях CRF/CQ. Ціль була отримати від всіх шматків відео ≥ 42 dB XPSNR. Вирішує насйкладніший кліп, інші отримують просто додатковий запас по якості. Трохи прийшлось помучитимся. Наприклад, перша версія заміру занижувала оцінку до 19 dB. xpsnr зіставляє кадри за часом, а в MKV-шматку час округлено до мілісекунд, у MP4 ні. При 29.97 fps кожен другий кадр порівнювався з сусіднім.
Зараз на найскладнішому кліпі всі чотири енкодери дають 42.0–42.1 dB, але розмір виходить різний й тому дефолт це AV1 на CPU, який всіх перемагає.
Якщо AV1 на CPU це 1x по розміру, то інші енкодери будуть:
- HEVC 1.15×
- AV1 на NVIDIA 1.7×
- HEVC на NVIDIA 2×.
Ще кілька речей
✅Усе експортується в 10 bit, навіть з 8-бітних джерел: бандингу немає, а файл більший лише на кілька відсотків. Сам не думав, що це нормальний дефолт, а виявилось - саме те, що треба.
✅Робить мінімум: що вже підходить, не чіпає, а якщо треба змінити лише звук, картинка копіюється як є.
✅І найголовніше: cozy theme 🧡
На Linux усе перевірено. Windows і macOS збираються в CI, але на живих машинах я їх ще не пробував (мака в наявності немає 🙈).
Якщо у вас така сама задача, спробуйте, буду радий фідбеку.