Існує кілька "стандартних" частот кадрів, але їх стає так багато, що підтримка довільних частот кадрів простіше, ніж спеціально підтримка багатьох конкретних. Особливо це стосується програмних плеєрів, таких як VLC.
Все більше і більше підтримки існує для VARIABLE fps. (VFR, змінна частота кадрів). Ось де інтервал між кадрами в одному відео не є постійним. Багато форматів файлів для відеоконтейнерів (наприклад, Matroska ( .mkv) або MPEG-4 ( .mp4тісно пов'язані з Apple .mov)) навіть не зберігають FPS-номер, а швидше базу часу (наприклад, 1/30 секунди), а потім кожен кадр має часову позначку, кратну цій часовій базі. Так буває, що інтервал між кожним кадром є одним або невеликим цілим числом одиниць бази часу у відеокліпі CFR (постійної частоти кадрів).
Кадри охоронної камери з майже повторюваними кадрами будуть очевидним випадком використання для VFR. Тим більше, що його стискають спрощеним відео кодеком, який не використовує переваги тимчасової надмірності (з інтер (p і b) кадрами). (Грати з ffmpeg -vf mpdecimateвпустити ряд дублюючих кадрів. Використовується -vsync 2при виведенні в mp4, тому що з якоїсь - то причини це не за замовчуванням для цього мультиплексора, але це для мов.)
Ще один випадок - це сучасні смартфони. Наприклад, Moto G мого брата (2-й рід) записує відео VFR. Це знижує частоту кадрів, коли датчику потрібно більше світла. Частина результатів роботи медіаінфо на mp4, створеному програмним забезпеченням телефону, записана в приміщенні:
Bit rate : 9 999 Kbps
Width : 1 280 pixels
Height : 720 pixels
Display aspect ratio : 16:9
Rotation : 90°
Frame rate mode : Variable
Frame rate : 16.587 fps
Minimum frame rate : 14.985 fps
Maximum frame rate : 30.030 fps
Відтворення одного відеофільму VFR не є складним. Програмне забезпечення просто готовий до відображення наступного кадру, спить, поки його не відображатимуть, потім прокидається і виводить його.
Все стає дещо складніше, якщо взяти до уваги той факт, що люди можуть бачити відеокадри лише тоді, коли їх відображає монітор. Монітори VFR існують, але вони все ще рідкісні. (google для g-sync freesync).
Зміна відображеного зображення під час його сканування на монітор призводить до некрасивого розриву відео (зазвичай це спостерігається під час гри з відключеною vsync). Це обмежує програвача до зміни відображеного зображення на 50 або 60 Гц. (CRT підтримують довільну частоту в режимі reffresh, в межах діапазону, але складно готувати режими з усіма правильними таймінгами, тому більшість людей просто використовували кілька фіксованих частот оновлення. А тепер у людей є LCD, які так чи інакше підтримують фіксовану частоту оновлення. До тих пір, поки монітори freesync все одно є більш поширеними. Я дуже чекаю цього :)
Тож із частотою кадрів відео, яка не є кратною або коефіцієнтом частоти оновлення монітора, деякі кадри відображатимуться для 3-х оновлень монітора, а деякі - 2, наприклад, навіть якщо відео має бути постійним 25 кадрів в секунду. (на моніторі 60 Гц).
Речі ускладнюються, коли ви хочете працювати з декількома кліпами і зникати між ними, або зображенням у картинці, або різними іншими ефектами. Набагато простіше писати програмне забезпечення для редагування відео, якщо ви можете припустити, що всі кліпи мають новий кадр одночасно. (Вони змушують вирівнювання кліпу оснащуватися цілими кадрами).
Ось чому NLE (наприклад, kdenlive або pitivi, щоб вибрати випадкові приклади безкоштовного програмного забезпечення), швидше за все, змушують вас встановити фіксовану FPS та скидати / дублювати кадри зі своїх кліпів, щоб вони відповідали частоті кадрів. Вибраний вами CFR може бути довільним, але він, як правило, повинен бути постійним для всього "проекту".
(Чи будь-які NLE повністю працюють з VFR-кліпами і виробляють VFR вихід у такому випадку?)
Отже, підсумовуючи, щойно ми матимемо монітори та операційні системи із змінною синхронізацією, єдине, що нас стримує - це редагування відео, я думаю. І мовлення, оскільки, очевидно, CFR теж велика справа для цього?
У випадку, якщо вам цікаво, 29.970 (фактично 30000/1001) та 23.976 (фактично 24000/1001, від телецинінгу) набридливі не цілі частоти кадрів є виною кольору NTSC. пошук 1.001 . Якби вони були готові ризикувати, коли декілька наборів програм не зможуть обробити додаткову частоту 0,1% для аудіопідсильника, світ не пошкодував би цієї дурниці. (Я думаю, я десь побачив ще одну статтю, яка зробила це звуком більше схожим на багато наборів, але вони не були б впевнені в ідеальному співзвученні. факти.)
Однак дратує частота кадрів - один із найменших гріхів мовлення. Це дійсно переплетення, що було основою якості відео на сучасних (усі пікселі, що запалюються одразу), і це не змінилося б. Я досі не розумію, чому переплетення зберігалося для HDTV. Чому 1080i60 коли-небудь визначали, замість того, щоб використовувати 720p60 для отримання тієї ж часової роздільної здатності для занять спортом та іншим? Це схоже на 1920x540p60, але з дурним вертикальним зміщенням між непарними і парними полями, що вимагає багато обчислень на кінці прийому, щоб це не виглядало жахливо.
редагувати:
Для вашого випадку я б абсолютно запропонував архівувати на нативної FPS. Не викидайте жодної інформації, скидаючи кадри. Не дублюйте кадри і не збільшуйте свої файли (або зробіть ваш кодер h.264 витрачати більше часу, помічаючи дублікати та виводить кадр, повний пропущених макроблок, що займає всього 20 байт на весь кадр).
У майбутньому, коли ми сподіваємося, що у всіх є дисплеї freesync, які можуть відтворювати будь-який кадр, ви захочете скасувати підкачку до 24 кадрів в секунду, щоб ваше відео відтворювалося більш плавно! Або якщо freesync якимось чином не ввімкнеться, або дисплей, який з’являється після РК-дисплеїв, є CFR, перетворення швидкості, мабуть, найкраще робити під час відтворення в будь-якому випадку. Це не так, як 24 кадрів в секунду навіть чудово грає на моніторі 60 Гц. (Я візуально не помічаю факту, що деякі кадри відображаються для 3 * 1/60, тоді як деякі відображаються для 2 * 1/60, але це правда).
Якщо у вас проблеми з Quicktime, тоді IDK. Можливо, переконайтесь, що Handbrake створює файли з правильним кадром, встановленим у бічній потоці h.264, а також контейнер. (Так, заголовки h.264, очевидно, можуть зберігати частоту кадрів, окремо від того, що каже контейнер. Дивіться документи для mkvmerge --fix-bitstream-timing-information. І спробуйте використовувати його --default-duration 16fpsдля створення файлу mkv. Потім MIX, що повертається до mp4, і побачить, чи це виправляє швидкість? ) Або, можливо, є спосіб зробити це в першу чергу інструментами mp4. Див. Наприклад: /ubuntu/370692/how-to-change-the-framerate-of-a-video-without-reencoding
Я можу гарантувати, що довільна частота кадрів mp4 є дійсною, і навіть змінна частота кадрів mp4 є дійсною. Якщо Quicktime грає неправильно, це може бути виною Quicktime. А може, помилка Handbrake в тому, що файл помилився. Зазвичай я просто використовую ffmpeg безпосередньо, тому що я ніндзя командного рядка.