Birkaç "standart" kare hızı vardır, ancak o kadar çok olur ki, keyfi kareleri desteklemek, özellikle belirli birçok kareyi desteklemekten daha kolaydır. Bu özellikle VLC gibi yazılım oynatıcılar için geçerlidir.
VARIABLE fps için daha fazla destek var. (VFR, değişken kare hızı). Bu, aynı videodaki kareler arasındaki aralığın sabit olmadığı yerdir. Birçok video kapsayıcı dosya biçimi (Matroska ( .mkv
) veya MPEG-4 ( .mp4
Apple ile yakından ilişkili .mov
) gibi) bir FPS numarası bile değil, bir zaman tabanı (örneğin saniyenin 1 / 30'u) ve ardından her bir kareyi depolar zaman tabanının katı olarak bir zaman damgasına sahiptir. Öyle ki, her bir kare arasındaki aralık bir CFR (sabit kare hızı) videodaki zaman tabanının bir veya küçük tamsayı sayısıdır.
Yinelenen karelere yakın güvenlik kamerası görüntüleri VFR için bariz bir kullanım örneği olacaktır. Hatta, geçici yedeklemeden (inter (p ve b) karelerle) iyi yararlanmayan basit bir video codec bileşeni ile sıkıştırılıyorsa bile moreso. ( ffmpeg -vf mpdecimate
yakın çift kareleri bırakmak için oynayın . mp4'e çıktı -vsync 2
alıyorsanız kullanın , çünkü bir nedenden dolayı bu muxer için varsayılan değildir, ancak mkv içindir.)
Başka bir durum modern akıllı telefonlar. Örneğin, kardeşimin Moto G (2. nesil) VFR videolarını kaydediyor. Sensörün daha fazla ışığa ihtiyacı olduğunda kare hızını düşürür. Mediainfo'nun telefon yazılımı tarafından oluşturulan ve içeride kaydedilen bir mp4 üzerinde çalıştırılmasından elde edilen çıktılardan bazıları:
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
Tek bir VFR video akışının oynatılması zor değildir. Yazılım bir sonraki kareyi görüntülemeye hazır hale getirir, görüntülenene kadar uyur, sonra uyanır ve görüntüler.
İnsanların video karelerini yalnızca bir monitör görüntülediğinde görebildiğini dikkate aldığınızda işler biraz daha karmaşıklaşır. VFR monitörleri mevcuttur, ancak hala nadirdir. (g-sync freesync için google).
Ekrana taranırken görüntülenen görüntünün değiştirilmesi, videonun çirkin bir şekilde yırtılmasına neden olur (genellikle vsync kapalı bir oyun oynarken görülür). Bu, oynatıcıyı görüntülenen görüntüyü 50 veya 60Hz'de değiştirmeye sınırlar. (CRT'ler, bir aralık içinde keyfi vrefresh oranlarını destekler, ancak tüm zamanlamaların doğru olduğu modları pişirmek karmaşıktır, bu nedenle çoğu insan sadece birkaç sabit yenileme hızı kullandı ve şimdi insanların yine de yalnızca sabit bir yenileme hızını destekleyen LCD'leri var. freesync monitörler zaten daha yaygın. Gerçekten dört gözle bekliyorum. :)
Dolayısıyla, monitör yenileme hızının katı veya faktörü olmayan video kare hızlarında, 3 monitör yenilemesi için bazı kareler, örneğin video sabit bir 25FPS'de olması gerekiyorsa bile, bazıları için 2 kare görüntülenir. (60Hz monitörde).
Birden fazla kliple çalışmak ve aralarında solukluk, resim içinde resim veya diğer çeşitli efektler yapmak istediğinizde işler daha karmaşık hale gelir. Tüm kliplerin aynı anda yeni bir çerçeveye sahip olduğunu varsayabilirseniz, video düzenleme yazılımı yazmak çok daha kolaydır. (Klips hizalamasını tüm karelere yapışmaya zorlar).
Bu nedenle NLE'lerin (rastgele Ücretsiz yazılım örnekleri seçmek için kdenlive veya pitivi gibi), sizi sabit bir FPS'ye zorlama ve bu kare hızıyla eşleşmeleri için kliplerinizden kare bırakma / çoğaltma. Seçtiğiniz CFR keyfi olabilir, ancak genellikle tüm "proje" için sabit olması gerekir.
(Herhangi bir NLE, VFR kliplerle tam olarak çalışır mı ve bu durumda VFR çıkışı üretir mi?)
Özet olarak, değişken senkronize monitörler ve işletim sistemimiz olduğunda, bizi geride tutan tek şey video düzenleme olacaktır. Ve yayıncılık, görünüşe göre CFR bunun için de büyük bir anlaşma mı?
Merak ediyorsanız, 29.970 (aslında 30000/1001) ve 23.976 (aslında 24000/1001, telecining'den) can sıkıcı tamsayı olmayan kare hızları NTSC renginin hatasıdır. 1.001'i arayın . Sadece birkaç B&W setinin ses alt taşıyıcısı için% 0,1 frekans daha fazla işleyememe riskini almak isteselerdi, dünya bu saçmalıktan kurtulmuş olurdu. (Sanırım pek çok setin daha iyi olacağına benzeyen bir yerde başka bir makale gördüm, ama mükemmel uyumdan emin değildiler. Wikipedia hiçbir setin% 0.1 daha yüksek bir ses alt taşıyıcısı tutamayacağı gibi ses çıkarıyor. Gerçekler.)
Rahatsız edici kare hızları, yayıncılığın daha az günahlarından biridir. Gerçekten (bu, tüm pikseller aynı anda aydınlatılan) ekranlarda video kalitesinin sıkıntısıydı ve bu değişmeyecekti. Hala HDTV için neden titreşim tutulduğunu anlamıyorum. Spor ve eşyalar için aynı geçici çözünürlüğü elde etmek için 720p60 kullanmak yerine neden 1080i60 tanımlandı? 1920x540p60'a benzer, ancak korkunç görünmemesi için alıcı uçta çok fazla hesaplama gerektiren tek ve çift alanlar arasında aptal bir dikey ofset ile.
Düzenle:
Kullanım durumunuz için, yerel FPS'de arşivlemeyi kesinlikle öneririm. Kareleri bırakarak hiçbir bilgiyi atmayın. Çerçeveleri çoğaltmayın ve dosyalarınızı daha büyük yapmayın (veya h.264 kodlayıcınızın kopyaları fark etmek ve tüm çerçeve için yalnızca 20 bayt alan atla makro bloklarıyla dolu bir çerçeve çıkarmak için daha fazla zaman harcamasını sağlayın).
Gelecekte, herhangi bir kare hızını çalabilen freesync ekranlara sahip olduğumuzu düşündüğümüzde, videonuzun daha sorunsuz oynatılması için çekmenizi 24 fps'ye geri almak isteyeceksiniz! Veya freesync bir şekilde yakalanmazsa veya LCD'lerden sonra gelen ekran CFR ise, oran dönüşümü muhtemelen en iyi şekilde oynatma zamanında yapılır. 24fps bile 60Hz monitörde mükemmel oynar gibi değil. (Bazı karelerin 3 * 1/60. İçin, bazıları 2 * 1/60. İçin görüntülendiğini görsel olarak fark etmiyorum, ancak bu doğru).
Quicktime ile ilgili sorun yaşıyorsanız IDK. Belki de Handbrake'in h.264 bit akımında ve doğru kapta ayarlanmış dosyaları ve kapta dosya oluşturduğundan emin olun. (Evet, h.264 üstbilgileri konteynerin söylediklerinden ayrı bir kare hızını depolayabilir. Dokümanlara bakın mkvmerge --fix-bitstream-timing-information
. Ve --default-duration 16fps
bir mkv dosyası yapmak için ile kullanmayı deneyin . Sonra mp4'e geri mux ve bu hızlı zaman düzeltmek olmadığını görmek? ) Belki de ilk etapta mp4 araçlarıyla yapmanın bir yolu vardır. Örneğin bakınız: /ubuntu/370692/how-to-change-the-framerate-of-a-video-without-reencoding
Rasgele kare hızı mp4'ün geçerli olduğunu ve hatta değişken kare hızı mp4'ün geçerli olduğunu garanti edebilirim. Quicktime yanlış oynarsa, Quicktime'ın hatası olabilir. Veya Handbrake'ın dosyayı yanlış yapma hatası olabilir. Genellikle doğrudan ffmpeg kullanıyorum, çünkü ben bir komut satırı ninjasıyım.