FFMPEG / libx264: Değişken kare hızı ancak maksimumda nasıl belirtilir?


16

FFMPEG / libx264'e (-r / -framerate) sabit bir kare hızı sağlamak yerine, MAXIMUM değerine sahip değişken bir kare hızı belirtmek ve libx264'ün uygun gördüğünde kare hızını düşürmesine izin vermek istiyorum. Buradaki fikir, genişletilmiş bir fotoğraf çerçevesi ( kaynak videolarımda A LOT ) gibi bir şey olduğunda ekstra sıkıştırma elde etmektir .

Öngörülü veya çift yönlü bir MPEG çerçevesinin gerçekten iyi sıkıştırılacağını anlıyorum, ancak kaynak kare hızının kodlamayı düşündüğümden daha düşük olması da mümkündür (muhtemelen daha büyük bir akışa neden olabilir!).


1
Nerede (veya nasıl) x264'ün kendisine VFR'yi kullanmasını söylersiniz?
slhck

Benim sorum bu.
Mark Gerolimatos

2
Sorunuz VFR'yi maksimumda nasıl belirleyeceğinizdi . Hatta x264 kullanarak VFR kodlaması belirtmek için herhangi bir yol farkında değilim. (Ayrıca bu noktada
ffmpeg'den bahsetmiyorum

@MarkGerolimatos Yanıtınızı buldunuz mu ?!
Dr.jacky

Hayır, hiç yapmadım.
Mark Gerolimatos

Yanıtlar:


19

Eğer ben en azından cevap VFR (değil V etkinleştirme hakkında başkalarının sorularını gidiyordu, ya bir cevap bulamamıştı olduğunu bıkan B FFMPEG gelen R) çıkışı.

Bunun cevabı garip bir şekilde adlandırılmış -vsyncseçenektir. Birkaç farklı seçeneğe ayarlayabilirsiniz, ancak istediğiniz seçenek '2' veya 'dır vfr. Man sayfasından:

-vsync parametresi
Video senkronizasyon yöntemi. Uyumluluk nedeniyle, eski değerler sayı olarak belirtilebilir. Yeni eklenen değerlerin her zaman dize olarak belirtilmesi gerekir.

  • 0, geçidi

    • Her bir çerçeve zaman damgası ile demuxer'den muxere geçirilir.
  • 1, cfr

    • Tam olarak istenen sabit kare hızını elde etmek için çerçeveler çoğaltılacak ve bırakılacaktır.
  • 2, vfr

    • Çerçeveler, zaman damgasıyla geçirilir veya 2 karenin aynı zaman damgasına sahip olmasını önlemek için düşürülür.
  • düşürmek

    • Geçiş olarak ancak tüm zaman damgalarını yok ederek, muxerin kare hızına göre yeni zaman damgaları oluşturmasını sağlar.
  • -1, otomatik

    • Muxer özelliklerine bağlı olarak 1 ile 2 arasında seçim yapar. Bu varsayılan yöntemdir.

Bundan sonra zaman damgalarının muxer tarafından daha fazla değiştirilebileceğini unutmayın. Örneğin, avo_negative_ts biçim seçeneğinin etkinleştirilmiş olması durumunda.

-Map ile zaman damgalarının hangi akıştan alınacağını seçebilirsiniz. Video veya sesi değiştirmeden bırakabilir ve kalan akışları değişmeden senkronize edebilirsiniz.

Ancak, herkesin göründüğü 'alt soruyu' cevaplamak için yorum yayınlamak için yeterli üne sahip değilim. Ama dürüstçe çok iyimser olmadığım konusunda birkaç fikrim vardı ... Ama ilk denediğim şey gerçekten işe yaradı . Yani.

Sadece birleştirmek gerekir -vsync 2ile seçeneği -r $maxfpsdeğiştirmek elbette seçeneği $maxfpsistediğiniz maksimum kare hızına sahip! Ve çalışıyor! Çerçeveleri kaynak dosyadan çoğaltmaz, ancak dosyanın maksimum kare hızını aşmasına neden olan kareleri bırakır!

Varsayılan olarak, -r $maxfpstek başına sabit bir kare hızı elde etmek için kareleri çoğaltmasına / düşürmesine -vsync 2neden olduğu ve kendi başına PTS değerlerini gerçekten etkilemeden kareleri doğrudan çekmesine neden olduğu görülmektedir.

Bu konuda iyimser değildim çünkü zaten -r $maxfpsbunu sürekli bir kareye koyduğunu biliyordum . Dürüst olmak gerekirse ben bir hata ya da sadece hangisi önce ya da son ya da her neyse geldi itaat bekliyordu. Tam olarak istediğimi yapması beni FFMPEG geliştiricilerinden oldukça memnun ediyor.

Umarım bu size yardımcı olur, ya da daha sonra bunu bilmeniz gerekmiyorsa.


3
-copytsda yardımcı olabilir
rogerdpack

1

MAXIMUM değeri olan değişken bir kare hızı belirtmek ve libx264'ün uygun gördüğünde kare hızını düşürmesine izin vermek istiyorum. Buradaki fikir, genişletilmiş bir fotoğraf çerçevesi gibi bir şey olduğunda ekstra sıkıştırma elde etmektir

Anladığım kadarıyla, bu muhtemelen nispeten sakar bir şekilde olabilir, ancak bazı karmaşık ve mantıksız nedenlerden dolayı istenmeyen bir durumdur.

Bir x264 akışında bir kare hızı (kare sayısı) olmasına rağmen, kare hızı kodlayıcıdan daha çok kapsayıcı düzeyinde bir sorundur.

Düz geçişli bir VFR kodlamasında, temelde kare hızının hangi kare / kez üzerinde olduğunu gösteren bir metin dosyası olacak ve bir kaynağı kodlarken, tcfile-in veya tcfile-out gibi bir işlev zaman damgalarını kodlamadan geçirir. , hız konumlarını eşlemek ve videoyu öznelikle kaynaktan tutarlı tutmak için.

Düşük çerçeveli fikir mantıklı bir fikirdir, ancak çeşitli nedenlerle işe yaramaz. X264, bazı yeteneklerle VFR farkında olsa da, dosya boyutunu azaltmak için (birçok bit hızı kontrolüne benzer bir şekilde) hareketle ilgili kare hızını değiştirecek bir analiz işlevi olduğunu düşünmüyorum.

Kaynak da bir sorundur: VFR kaynakları varsayılan olarak çerçeve değişkenliklerini koruyacaktır, ancak görünüşe göre bir CFR dosyasını değişken bit hızında kodlamak (bazen iyi bir fikir, özellikle telesine ihtiyaç duyulduğunda özellikle aynı CFR) üretilecektir.

Bu, muhtemelen bit hızını elle yeniden yazmanız gerektiği anlamına gelir (yani, dosyaya yapıştırılan yavaş sahnelerin zaman damgaları) veya avisynth için dup, dedup ve exactDedup gibi bir çerçeve belirleme algoritmasına başvurmanız gerekir . Videonuzda çok düşük hareket varsa, bazı kareler (hatta yarım?) Dışarı atılır. Sorun, bu algoritmaların gelişmiş olmaması ve en iyi kodlamaya neyin katkıda bulunacağı konusunda "gerçek hayat" görüntüleri ile iyi seçimler yapmamasıdır.

Ayrıca, I ve B kareleri gibi şeyleri içeren karelerin kaldırılması, zaman içinde mevcut olan ayrıntı miktarını azaltır, bu da hareketin "bozkır" görünmesine neden olur ve diğer temel video parametrelerine müdahale edebilir ve diğer adlandırma gibi yapay nesnelere neden olabilir.

Ve nicemleyicilerin çalışma şekli nedeniyle, x264 bu düşük hareket sahnelerinde bit hızını orantısız olarak daha da azaltacaktır. Aynı görüntülerden oluşan bir slayt gösteriniz yoksa, hareket olacaktır (yalnızca tahıl ve diğer eserler varsa) ve bit hızında ciddi değişiklikler olmadan görülmeyecek kalitede bir kayıp olacaktır.

Ve son olarak, istediğinizi yapmak için pek çok seçeneğin olmamasının nedeni, x264'ün sadece geçici sıkıştırma (kısmi karelerde değişiklikleri kaydetme) kullanarak bit hızını yönetmede gerçekten iyi olmasıdır. 1/2 kare hızına gitmek dosya boyutunu yarıya indirmez; % 10 muhtemelen düşük hareket veya animasyondan beklenen gerçekçi bir kazançtır.

Kısacası, statik sahnelerinizin bit hızını düşürmek dosya boyutunuz için çok az şey yapacaktır, ancak video düzenleme yazılımı ile uyumsuzluktan bahsetmemek için bir dizi kalite ve senkronizasyon sorunu ekleyecektir.

Bir decimator denemek istiyorsanız , her biri maksimum çözünürlük ve kare hızı olan düzey seçeneklerini kullanarak maksimum yeni kare hızını sınırlandırabilirsiniz . Ne yazık ki, profilleri kullanarak istediğiniz kare hızlarını elde etmek için muhtemelen çok düşük çözünürlüklerde çalışmanız gerekir. Oranları tamamen elle düzenlemeye veya çok yüksek olduğunu düşündüğünüz kare hızlarını düzeltmeye geri döner. Her iki durumda da, tcfile korunurken kodlama işleminden sonra değişiklik yapılırsa sesi yeni çerçevelerle senkronize tutmak hokkabazlık gerektirir.

Buradaki paket, çok sayıda bit hızı ayarını optimize etmek için zaman harcamanın, dosya boyutu yönetimi açısından çok daha fazla verim sağlaması ve videonuzun kalitesini, az kazanç için komplikasyonlara neden olmaktan ziyade artıracağıdır. Yayın veya medya standartlarını hedeflemediğiniz sürece orijinal FPS'yi korumak muhtemelen en iyi fikirdir. Oynatıcılar, değişken bit hızlarını (editörlerin aksine) iyi bir şekilde oynatabilir ve videonuzda ne kadar çok kare olursa, kareler arasındaki hareketteki küçük değişiklikler nedeniyle oynatma o kadar düzgün olur ve dosya boyutu da küçülür.

İşte kodlamanın bu kafa karıştırıcı yönüne yardımcı olması gereken standartlar bilgi ve forum tartışmalarına bağlantılar:

- avisynth decimation tools

- fps ve -r anahtarları
- x264 Genel (tcfile, fps)
- zaman kodu dosya standartları
- Düzeyler ve profiller
- Kısa, net CFR / VFR ayar özeti ("kare hızı" bölümü)

doom9, videohelp, & c teorik tartışmalar
1 2 3 4 5 6 7

Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.