FFMPEG / libx264: Jak określić zmienną liczbę klatek na sekundę, ale z maksymalną wartością?

Zamiast zapewnienia stałej liczby klatek na sekundę dla FFMPEG / libx264 (-r / -framerate), chciałbym określić zmienną liczbę klatek na sekundę o wartości MAKSYMALNEJ i pozwolić, aby libx264 zmniejszał liczbę klatek na sekundę według własnego uznania. Chodzi o to, aby uzyskać dodatkową kompresję, gdy istnieje coś w rodzaju wydłużonej klatki nieruchomej (co zdarza się DUŻO w moich źródłowych filmach).

Zdaję sobie sprawę, że predykcyjna lub dwukierunkowa ramka MPEG kompresuje się naprawdę dobrze, ale możliwe jest również, że źródłowa częstotliwość klatek jest mniejsza niż ta, do której zamierzam transkodować (możliwe, że WIĘKSZY strumień!).

Sfrustrowany faktem, że nie znalazłeś odpowiedzi, zamierzałem przynajmniej odpowiedzieć na pytania innych osób dotyczące włączenia VFR (nie V B R) z FFMPEG.

Odpowiedzią na to jest dziwnie nazwana -vsyncopcja. Możesz ustawić kilka różnych opcji, ale jedną z nich jest „2” lub vfr. Ze strony podręcznika:

-vsync parametr
Metoda synchronizacji wideo. Ze względów kompatybilności stare wartości można określić jako liczby. Nowo dodane wartości będą zawsze musiały być określone jako ciągi znaków.

• 0, przejście

  • Każda ramka jest przekazywana ze znacznikiem czasu od demultipleksera do multipleksera.

• 1, por

  • Ramki zostaną zduplikowane i usunięte, aby osiągnąć dokładnie żądaną stałą liczbę klatek.

• 2, vfr

  • Ramki są przekazywane ze znacznikiem czasu lub upuszczane, aby zapobiec sytuacji, w której 2 ramki mają ten sam znacznik czasu.

• upuszczać

  • Jako przekazywanie, ale niszczy wszystkie znaczniki czasu, dzięki czemu multiplekser generuje nowe znaczniki czasu na podstawie częstotliwości klatek.

• -1, auto

  • Wybiera od 1 do 2 w zależności od możliwości multipleksera. To jest metoda domyślna.

Zauważ, że znaczniki czasu mogą być później modyfikowane przez multiplekser. Na przykład w przypadku, gdy włączona jest opcja formatu unikaj_negatywnych_ts .

Za pomocą opcji -map można wybrać, z którego strumienia powinny być pobierane znaczniki czasu. Możesz pozostawić niezmienione wideo lub audio i zsynchronizować pozostałe strumienie z niezmienionym.

Jednak nie mam dość reputacji, aby opublikować komentarz, aby tylko odpowiedzieć na to „pytanie cząstkowe”, które wszyscy wydają się mieć. Ale miałem kilka pomysłów, o których nie byłem szczerze optymistą ... Ale pierwszy, który wypróbowałem, naprawdę zadziałał . Więc.

Po prostu musisz połączyć -vsync 2opcję z -r $maxfpsopcją, oczywiście tam, gdzie zamieniasz $maxfpsją z maksymalną możliwą liczbą klatek na sekundę! I DZIAŁA! Nie powiela ramek z pliku źródłowego, ale upuszcza ramki, które powodują, że plik przekracza maksymalną liczbę klatek na sekundę!

Domyślnie wydaje się, że -r $maxfpssam z siebie powoduje po prostu duplikowanie / upuszczanie ramek w celu uzyskania stałego klatek i -vsync 2sam z siebie powoduje bezpośrednie przyciąganie ramek bez faktycznego wpływu na wartości PTS.

Nie byłem tym optymistą, ponieważ już wiedziałem, że -r $maxfpsstawia to stałą liczbę klatek na sekundę. Szczerze spodziewałem się błędu lub tego, że po prostu zastosuje się do tego, co nastąpi pierwsze, ostatnie lub cokolwiek innego. Fakt, że robi dokładnie to, co chciałem, sprawia, że ​​jestem całkiem zadowolony z programistów FFMPEG.

Mam nadzieję, że to pomoże tobie lub komuś innemu później, jeśli nie będziesz już musiał tego wiedzieć.

Chciałbym określić zmienną liczbę klatek na sekundę z MAKSYMALNĄ wartością i pozwolić libx264 na zmniejszenie liczby klatek na sekundę według własnego uznania. Chodzi o to, aby uzyskać dodatkową kompresję, gdy istnieje coś takiego jak wydłużona ramka nieruchoma

W moim rozumieniu może to być dość nieporadne, ale jest niepożądane z kilku złożonych i sprzecznych z intuicją powodów

Mimo że strumień x264 ma liczbę klatek na sekundę, szybkość klatek jest bardziej problemem na poziomie kontenera niż kodekiem.

W kodowaniu VFR z przekazywaniem będzie istniał plik tekstowy z wyszczególnieniem szybkości klatek w stosunku do liczby klatek / razy, a przy kodowaniu źródła funkcja taka jak tcfile-in lub tcfile-out przekazuje znaczniki czasu do kodu , aby zmapować lokalizacje stawek i zachować subiektywnie spójne wideo ze źródła.

Idea niskiej liczby klatek na sekundę jest logiczna, ale nie działa z kilku powodów. Chociaż x264 obsługuje VFR z pewnymi możliwościami, nie sądzę, aby istniała funkcja analizy, która różnicowałaby szybkość klatek w odniesieniu do ruchu w celu zmniejszenia rozmiaru pliku (w sposób podobny do wielu elementów sterujących przepływnością).

Źródłem jest również problem: źródła VFR domyślnie zachowają zmienność klatek, ale najwyraźniej kodowanie pliku CFR ze zmienną przepływnością (czasem dobry pomysł, szczególnie gdy potrzebna jest telecine), po prostu wytworzy tę samą CFR.

Oznacza to, że prawdopodobnie będziesz musiał ręcznie ponownie zapisać bitrate (tj. Znaczniki czasu powolnych scen zmiksowane w pliku) lub skorzystać z algorytmu dziesiętnego klatki, takiego jak dup, dedup i dokładnieDedup dla avisynth . Jeśli Twój film ma bardzo niski ruch, niektóre klatki (nawet połowa?) Zostałyby wyrzucone. Problem polega na tym, że te algorytmy nie są zaawansowane i nie dokonują dobrych wyborów na podstawie nagrań z „prawdziwego życia” co do tego, co przyczyni się do najlepszego kodowania.

Ponadto usunięcie ramek zawierających elementy takie jak ramki I i B zmniejsza ilość szczegółów dostępnych w czasie, co powoduje, że ruch wygląda „stepowy” i może zakłócać inne podstawowe parametry wideo i powodować artefakty, takie jak aliasing.

A ze względu na sposób działania kwantyzatorów, x264 faktycznie nieproporcjonalnie zmniejszy bitrate w tych scenach o niskim ruchu. Jeśli nie masz pokazu slajdów z identycznymi obrazami, nastąpi ruch (jeśli tylko ziarno i inne artefakty) i nastąpi utrata jakości, która nie byłaby widoczna bez drastycznych zmian przepływności.

I wreszcie, powodem, dla którego nie ma wielu opcji robienia tego, co chcesz, jest to, że x264 jest naprawdę dobry w zarządzaniu przepływnością za pomocą kompresji czasowej (rejestrowanie zmian w częściowych klatkach). Przejście do 1/2 klatek na sekundę nie spowoduje zmniejszenia rozmiaru pliku o połowę; 10% to prawdopodobnie realistyczny zysk, którego można oczekiwać po zwolnieniu lub animacji.

Krótko mówiąc, zmniejszenie szybkości bitowej scen statycznych niewiele zrobi dla rozmiaru pliku, ale doda wiele problemów z jakością i synchronizacją, nie wspominając o niezgodności z oprogramowaniem do edycji wideo.

Jeśli chcesz wypróbować decymator, możesz być w stanie ograniczyć maksymalną nową liczbę klatek na sekundę, używając opcji poziomów , z których każdy ma maksymalną rozdzielczość i szybkość klatek. Niestety prawdopodobnie będziesz musiał pracować przy bardzo niskich rozdzielczościach, aby uzyskać żądaną liczbę klatek na sekundę, korzystając z profili. Wraca do ręcznego edytowania częstotliwości, albo całkowicie, albo do korekcji liczby klatek, którą uważasz za zbyt wysoką. Tak czy inaczej, potrzeba żonglowania, aby utrzymać synchronizację dźwięku z nowymi ramkami, jeśli zmiany zostaną wprowadzone po procesie kodowania, gdy plik tc zostanie zachowany.

Zaletą jest to, że spędzanie czasu na optymalizacji wielu ustawień szybkości transmisji przyniesie znacznie więcej w zakresie zarządzania rozmiarem pliku i poprawi jakość wideo, zamiast powodować komplikacje przy niewielkim zysku. Zachowanie oryginalnego FPS jest prawdopodobnie najlepszym pomysłem, chyba że dążysz do standardów transmisji lub mediów. Odtwarzacze są w stanie odtwarzać zmienne szybkości transmisji (w przeciwieństwie do edytorów), a im więcej klatek w filmie, tym płynniejsze odtwarzanie i być może mniejszy rozmiar pliku, z powodu mniejszych zmian ruchu między klatkami.

Oto zbiór linków do informacji o standardach i dyskusji na forum, które powinny pomóc w tym mylącym aspekcie kodowania:

- narzędzia dziesiętne avisynth

- przełączniki fps i -r
- x264 Ogólne (plik tc, fps)
- standardy plików kodów czasowych
- Poziomy i profile
- Krótkie, jasne podsumowanie ustawień CFR / VFR (sekcja „Framerate”)

doom9, wideohelp i c dyskusje teoretyczne
1 2 3 4 5 6 7