Ты бы не гуглил, а ИИ вопрошал:

Ты уткнулся не в «магическую» проблему RTMP, а в таймстемпы и разреженные кадры. Когда делаешь fps=1/300 (1 кадр раз в 5 минут), для стрима это выглядит как огромные дыры во времени, и ffmpeg/плееры начинают:

• ждать данные (буферизоваться)
• пытаться «догадаться» параметры потока
• ловить non-monotonic DTS
• в итоге висеть минуту+ перед стартом

А RTMP вообще плохо переносит такие «редкие» видеопакеты — он ожидает более-менее регулярный поток.

🚨 Главная проблема

Вот эта часть:

-vf select='eq(pict_type,I)',fps=1/300

Ты:

• сначала выбираешь I-фреймы
• потом душишь fps до 1 кадра в 300 секунд

👉 В результате:

• видео поток практически «замирает»
• таймстемпы прыгают
• RTMP думает, что поток умер

⚠️ Почему с fps=1 работает

Потому что:

• поток становится регулярным (1 fps)
• тайминги нормальные
• RTMP и ffplay счастливы

💡 Как правильно сделать

Тебе нужно разделить задачи, а не пытаться сделать всё одним фильтром.

✅ Правильный подход

1. RTMP стрим — нормальный, непрерывный

Не трогай fps вообще:

ffmpeg -i rtsp:// -i sample.aac \
-c:v copy -c:a aac -shortest \
-f flv rtmp://

👉 Важно:

• лучше не copy AAC, а перекодировать (-c:a aac)

• это уберёт ошибки типа:

  Could not find codec parameters
  

2. Снимок раз в 5 минут — отдельно

ffmpeg -i rtsp:// \
-vf fps=1/300 \
-update 1 -q:v 2 \
\tmp\key.jpg

🔥 Или в одном процессе (правильно через tee)

ffmpeg -i rtsp:// -i sample.aac \
-filter_complex "[0:v]split=2[v1][v2];[v2]fps=1/300" \
-map "[v1]" -map 1:a -c:v copy -c:a aac -f flv rtmp:// \
-map "[v2]" -q:v 2 -update 1 -f image2 \tmp\key.jpg

👉 Здесь:

• [v1] — нормальный поток → RTMP
• [v2] — редкие кадры → JPG
• никаких лагов

⚠️ Важный момент про -c:v copy

Ты сейчас копируешь видео:

-c:v copy

Но при этом используешь фильтры (-vf или -filter_complex) — это конфликт.

👉 Если есть фильтр → будет перекодирование, даже если ты написал copy.

💣 Почему у тебя ещё DTS ошибки

Non-monotonic DTS

Это из-за:

• RTSP (неровные таймстемпы)
• • редкие кадры
• • merge с AAC

Можно стабилизировать:

-fflags +genpts
-use_wallclock_as_timestamps 1

🧠 Итог

Проблема не в:

• AAC
• RTMP
• ffplay

Проблема в том, что ты: 👉 сделал поток с fps ≈ 0.0033

А RTMP — это live streaming протокол, а не «раз в 5 минут кадр».

✔️ Коротко решение

👉 Не души fps в основном потоке 👉 Делай снимки отдельной веткой (split)

Если хочешь, могу собрать тебе:

• ultra-stable команду для продакшена
• или вариант с минимальной задержкой (low latency RTMP)

Спасибо дорогой, такой подход я встречал уже в ИИ, но мне было лень все эти «[0:v]split=2[v1][v2];[v2]fps=1/300» абракадабру делать. Я думал что ЭТО дублирование выходов и что они друг на друга не влияют. Попробую сделать так. Вообще tee я делал уже, но в этом случае подумал что он не нужен, потому что там 1 поток кодирования, а если(вдруг?) я захочу rtmp кодировать h265, делать картинки и ещё + mp4+aac, тогда tee не подойдет

Схема не работает

Streamcopy requested for output stream fed from a complex filtergraph. Filtering and streamcopy cannot be used together.

Схема не работает

А ты что, повёлся на выхлоп бредогенератора?

Опа! А я еще удивился, какой аноним заботливый, столько написал много и еще помощь предложил в конце

Lol rolf

НО в целом полезно, годно

Так не работает

fps=1/300

А оно вообще должно? В смысле, в математику в принципе. Сколько ffmpeg пользовался, даже и не знал, что он так умеет… Если написать fps=0.00333, тоже не работает?

\tmp\key.jpg

А это что вообще за жесть…

upd:

Хочу
rtsp + aac ==> rtmp + image every 5 sec (упростил до минимума)

Ну так image every 5 sec — это 1/5 (fps=0.2), а не 1/300. Откуда взялось 1/300? Это every 5 min.

Откуда взялось 1/300

1/60 * 5

Вот - отсюда. В минуте 60 секунд, умножаем ещё на 5 - получается 5 минут, потом делим 1 секунду на 300 - получается нужный FPS

Сколько ffmpeg пользовался, даже и не знал, что он так умеет

Он много чего умеет и делить и умножать и всякие функции min\max есть

Дробные fps умеет, да. Это действительно необходимо. Даже в случае автора: между с fps=1/300 12-й кадр будет ровно на 1 часе, а с fps=0.00333 он будет на 1:00:03.6, что весьма заметное расхождение и может оказаться не тем, что надо. Можно, конечно, написать 0.0033333, но это будет громоздко, некрасиво, а ошибка, хоть и отодвинется на более позднее время, но всё равно останется. А с 1/300 сразу всё хорошо. Хотя конкретно автору, возможно, это и несущественно, но бывают случаи когда один видеопоток у тебя уже есть и тебе надо к нему сгенерировать второй, и надо чтобы таймстампы кадров шли строго синхронно - и если у тебя не будет возможности точно задать частоту, они будут рассинхронизироваться спустя какое-то время.

Вот - отсюда. В минуте 60 секунд, умножаем ещё на 5 - получается 5 минут

Это я и так написал. Мой вопрос в том, откуда взялись «5 минут», если в начале ты сам пишешь «Хочу […] every 5 sec».

Элементарно, нужно каждые 5 минут драть кадр с потока