Co oznacza „Przeszły czas trwania X.XXX za duży”?


142

Podczas kodowania H.264 przy użyciu ffmpeg otrzymuję masowo następujące typy ostrzeżeń:

Past duration 0.603386 too large
Past duration 0.614372 too large
Past duration 0.606377 too large

Co mieli na myśli? Nie znalazłem niczego jasnego w Internecie ani w dokumentacji ffmpeg.


2
Pytania dotyczące ffmpeg prosimy kierować do witryny video.stackexchange.com beta. Zobacz opis tagu ffmpeg.
Ondra Žižka

34
@Ondra Jeszcze jedna wymiana stosów? Jestem zdezorientowany z tymi ponad 100 podwitrynami, nie jestem pewien, czy to jest pozytywny kierunek, w którym zmierza wymiana stosów.
mxmlnkn

1
@mxmlnkn Zgadzam się, to sprawia, że ​​tęsknisz za prostszymi czasami ... :)
Erik

4
Myślę, że to jest. StackOverflow służy do programowania, to nie jest programowanie. Istnieje witryna z pytaniami i odpowiedziami do przetwarzania wideo, to jest pytanie dotyczące przetwarzania wideo. Czego nie rozumieć?
Ondra Žižka

Przeczytaj także opis tagu.
Ondra Žižka

Odpowiedzi:


23

Otrzymywałem tysiące tych ostrzeżeń z określonym kodem. Zmniejszałem rozdzielczość wideo 1080p do 480p. W punkcie edycji, gdzie było jakieś podejrzane wideo z powodu defektu źródłowego dysku laserowego, te wiadomości zaczęły pojawiać się, a następnie pojawiały się, jak sądzę, w każdej następnej klatce. Kontynuowali i ciągnęli, jak ten krótki fragment:

Past duration 0.901115 too large=  535031kB time=00:54:15.06 bitrate=1346.5kbits/s dup=0 drop=19 speed=1.15x    
    Last message repeated 31 times
Past duration 0.901115 too large=  535031kB time=00:54:15.62 bitrate=1346.3kbits/s dup=0 drop=19 speed=1.15x    
    Last message repeated 34 times
Past duration 0.901115 too large=  535031kB time=00:54:16.21 bitrate=1346.0kbits/s dup=0 drop=19 speed=1.15x    
    Last message repeated 36 times
Past duration 0.901115 too large=  535338kB time=00:54:16.83 bitrate=1346.5kbits/s dup=0 drop=19 speed=1.15x    
    Last message repeated 39 times

Pierwotne wywołanie ffmpeg wyglądało tak:

ffmpeg -i input.mp4 -s 720x480 -c:v libx264 -preset slower -crf 17 -c:a copy -y output.mkv

Zgodnie z sugestiami tutaj najpierw dodałem -framerate 60000/1001 do wejścia. To niczego nie poprawiło. Zachowałem -framerate i dodałem -r 60000/1001 do wyjścia. To nadal niczego nie poprawiło. Zachowując oba, w końcu dodałem -async 1 -vsync 1. Spowodowało to, że otrzymałem jedno ostrzeżenie i to wszystko. To wezwanie brzmiało:

ffmpeg -i input.mp4 -framerate 60000/1001 -s 720x480 -c:v libx264 -preset slower -crf 17 -c:a copy -y output.mkv -r 60000/1001 -async 1 -vsync 1

Jedyną różnicą, jaką znalazłem w szczegółowym zrzucie z MediaInfo, było usunięcie tej linii znalezionej w pierwotnym wywołaniu, ale nie w drugiej:

Delay relative to video                  : -33ms

Jednak sprawdziłem synchronizację A / V blisko początku plików i pod koniec i nie było zauważalnej różnicy w synchronizacji między dwoma plikami. Ich czasy pracy również były takie same, ale mierzono je tylko z dokładnością do najbliższej sekundy w VLC. Więc sprawdziłem liczbę klatek używając ffmpeg w następujący sposób:

ffmpeg -i output.mkv -map 0:v:0 -c copy -f null -

i szukam "frame = #" pod koniec wyjścia.

Okazuje się, że wideo źródłowe miało długość 375226 klatek, pierwotne wywołanie dało 375195 klatek, a drugie wywołanie 375200. Tak więc drugie wywołanie, ze znacznie mniejszą liczbą komunikatów ostrzegawczych, również porzuciło 5 mniej klatek.

Późniejsze testy wykazały, że -framerate i -r były niepotrzebne, a samo użycie dwóch flag synchronizacji było wystarczające. Dało to identyczne wyniki jak drugie wywołanie powyżej, więc trzecie i najprostsze wywołanie, które znalazłem w celu rozwiązania problemu, jest następujące:

ffmpeg -i input.mp4 -s 720x480 -c:v libx264 -preset slower -crf 17 -c:a copy -y output.mkv -async 1 -vsync 1

I jeszcze inny plik później wygenerował kilka ostrzeżeń nawet z flagami synchronizacji, ale dodanie z powrotem flag szybkości „naprawiło” to (spowodowało tylko dwa zamiast tysięcy ostrzeżeń). Czasami więc drugie wywołanie działa, podczas gdy trzecie nie. Dla moich bezpośrednich celów zamierzam zdecydować się na drugie wezwanie i mam nadzieję, że rozwiąże większość tych problemów.

To wszystko z ffmpeg w wersji 4.0.


2
Dziękuję Ci za to! Po kilku dniach problemów -async 1 -vsync 1naprawiłem to za mnie.
Offek

1
Dzięki za tę analizę @larryy bardzo pomocne
deepelement

90

Jeden z opiekunów dla projektu na SourceForge DVDStyler powiedział to o tym:

Wersje FFMpeg po 15 stycznia 2015 r. Często wyświetlają to ostrzeżenie. Został dodany, aby ostrzec przed możliwymi zniekształceniami sterowania szybkością, w przeciwnym razie nie spowoduje żadnych szkód.


`` zniekształcenie kontroli szybkości '' jest związane z kodowaniem (głównie wideo) i nie ma związku z tym ostrzeżeniem, które dotyczy tego, czy wyjściowy znacznik czasu różni się zbyt (względnie) w porównaniu ze znacznikiem czasu wejściowego
Gyan

Przez kilka pierwszych razy otrzymałem ostrzeżenie, że przerwałem konwersję, ale ta rada sprawiła, że ​​uruchomiłem ją, a ostrzeżenia po chwili ustały, a konwersja zakończyła się pomyślnie. Dzięki.
IRTFM

58

Ten komunikat ostrzegawczy pojawia się podczas próby zakodowania źródła o dużej szybkości klatek na wyjście o niskiej liczbie klatek, co oznacza, że ​​klatki muszą zostać odrzucone.


Wystąpił ten błąd, ponieważ chciałem przekonwertować serię obrazów na wideo:

ffmpeg -i %05d.png -r 24 -c:v libx264 -crf 5 out.mkv

Wydaje się, że problem polega na tym, że jeśli na wejściu nie podano liczby klatek na sekundę, przyjmuje się liczbę klatek na sekundę 25 kl./s:

Input #0, image2, from 'frames/%04d.bmp':
  Duration: 00:00:15.96, start: 0.000000, bitrate: N/A
    Stream #0:0: Video: bmp, bgra, 920x650, 25 fps, 25 tbr, 25 tbn, 25 tbc

Można to również zobaczyć na podstawie całkowitej liczby zakodowanych ramek. Miałem 400 obrazów, ale powyższe polecenie zakodowało tylko 384:

frame=  384 fps= 68 q=-1.0 Lsize=   10931kB time=00:00:15.91 bitrate=5626.1kbits/s dup=0 drop=15    
video:10928kB audio:0kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead: 0.033807%

Komunikaty o błędach znikają, ustawiając zamiast tego wejściową częstotliwość odświeżania, jeśli wyjściowa liczba klatek na sekundę. Szybkość klatek wyjściowych zostanie wtedy automatycznie wybrana jako częstotliwość wejściowa. Dodatkowo w nowszych wersjach ffmpeg musisz uważać, ponieważ używając obrazów PNG z -iopcją lub raczej formatem wejściowym image2lub v4l2, musisz użyć -frameratezamiast -r, zapoznaj się z dokumentacją -ropcji .

ffmpeg -framerate 24 -i %05d.png -c:v libx264 -crf 5 out.mkv

Możliwe jest również osobne określenie liczby klatek na sekundę wejścia i wyjścia:

ffmpeg -framerate 25 -i %05d.png -r 10 -c:v libx264 -crf 5 out.mkv

W tym przypadku zakodowanych zostanie tylko 161/400 ramek. Pozostałe ramki zostaną tymczasowo usunięte. Znika również komunikat o błędzie, myślę, że aby nie spowalniać ffmpeg przez spamowanie na standardowe wyjście, zobacz:


3
„ponieważ tylko przy korzystaniu z obrazów PNG z opcją -i musisz użyć -framerate zamiast -r” - to całkowicie rozwiązało mój problem, dzięki!
Anonimowy

1
Próbując przekonwertować plik wmv na mp4, użycie -rdziałało tam, gdzie -frameratenie było.
1934286

+1 i proponuję przenieść swoje „podsumowanie” na górę. Co więcej, ponieważ rozwiązało to mój przypadek konwersji obrazów na wideo i próby zwiększenia liczby klatek na sekundę na wyjściu, a także przyspieszenia wyjścia. Zacząłem od tego ffmpeg -pattern_type glob -i '*.jpg' -filter:v "setpts=0.25*PTS" -r 50 "$( date "+%Y-%m-%d_%H%M%S")-timelapse-x4-50fps.mp4"bez ostrzeżenia ffmpeg -framerate 50 -pattern_type glob -i '*.jpg' -filter:v "setpts=0.25*PTS" -r 50 "$( date "+%Y-%m-%d_%H%M%S")-timelapse-x4-50fps.mp4"(zwróć uwagę na -framerate 50dodane do wejścia)
el-teedee

49

Patrząc na kod źródłowy , wydaje się, że różnica między czasem prezentacji (pkt.) W strumieniu wejściowym różni się od tego w strumieniu wyjściowym o więcej niż ustalony limit ustawiony na 0,6.

Fragmenty ze źródła:

    delta0 = sync_ipts - ost->sync_opts;
    delta  = delta0 + duration;

...

        if (delta0 < 0 &&
        delta > 0 &&
        format_video_sync != VSYNC_PASSTHROUGH &&
        format_video_sync != VSYNC_DROP) {
        double cor = FFMIN(-delta0, duration);
        if (delta0 < -0.6) {
            av_log(NULL, AV_LOG_WARNING, "Past duration %f too large\n", -delta0);
        } else
            av_log(NULL, AV_LOG_DEBUG, "Cliping frame in rate conversion by %f\n", -delta0);
        sync_ipts += cor;
        duration -= cor;
        delta0 += cor;
    }

To tylko szybki rzut oka, więc nie krępuj się poszukać głębiej.


Czy jest coś, co możemy zrobić, aby „naprawić” ten problem lub jawnie ustawić punkty wyjściowe?
Baodad

1
Nie pamiętam szczegółów dotyczących tego problemu, ale jeśli przez „naprawę” masz na myśli pozbycie się ostrzeżenia, to na podstawie powyższego kodu możesz zajrzeć do opcji format_video_sync = VSYNC_DROPlub format_video_sync = VSYNC_PASSTHROUGHsprawdzić, czy któryś z nich jest wykonalny w twoim przypadku użycia.
Erik

Dzięki. O ustawieniu liczby klatek na sekundę dowiedziałem się wprost za pomocą -rprzełącznika „naprawiono” te ostrzeżenia.
Baodad

1
Coś z własnego doświadczenia: miałem problem ze spamem w wiadomościach z „przeszłym czasem trwania” i naprawiłem go, wymuszając liczbę klatek na sekundę na -r 25, ale potem zacząłem mocno tracić synchronizację dźwięku. Usunięcie opcji -r i użycie opcji „-async 1 -vsync 1” w celu zapobieżenia desynchronizacji dźwięku zapobiegło problemowi z dźwiękiem, ale wydaje się, że nie ma też spamu z „przeszłego czasu trwania”.
Jason Lang

W wersji 4.1 i nowszych poziom dziennika został zaktualizowany, więc nie będzie wyświetlany na domyślnym poziomie dziennika.
Gyan


1

Polecenie powinno faktycznie wyglądać tak:

ffmpeg -loglevel quiet -i input_file.xyz ...

Nie ma przedrostka „-” dla parametru „cichy”, ponieważ nie jest to opcja, a raczej wartość opcji „-loglevel”.

Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.