[ffmpeg] задержка MPEG2

А скармливать-то кадры начинаешь с ключевого?

в каком смысле? кадр как кадр, все одинаковые

Он про то, что в MPEG кадры бывают разные. В ffmpeg у AVFrame вроде флаги есть и там должен стоять флаг KEY_FRAME.

Это я к тому, как проверить ключевой он или нет.

man MPEG. Это ещё хорошо, что кадры пустые, мог быть и прикольный мусор.

как сделать так чтобы самый первый кадр стал ключевым? что бы каждый входной кадр давал пакет в котором он же и содержится?

что я принципиально делаю не так?

я сделал все кадры очень разными и на них я вижу запаздывание

как сделать так чтобы самый первый кадр стал ключевым?

А как ты их делаешь?

что бы каждый входной кадр давал пакет в котором он же и содержится?

Ключевой (опорный) кадр - это полноценный кадр, по которому можно нарисовать всю картинку. Дальше в потоке идут несколько неключевых кадров, которые содержат только разницу между предыдущим и текущим кадром.

это я абсолютно хорошо понимаю

я чуть позже скину пример кода

суть в том что я кормлю три кадра в avcodec_encode_video и мой самый первый кадр вылезает лишь после трех кормлений последующими кадрами, а далее они следуют своим чередом но задержанно а ключевые кадры видны тем что у них рахмер больше и они встречаются с той частотой что я задал в контексте кодера

я сейчас суть пытаюсь понять - это фундаменьальное ограничение и надо брать другой кодек, или параметры не такие...

Попробуй установить в поле flags структуры AVCodecContext флаг CODEC_FLAG_LOW_DELAY.

При этом ты получишь закодированный поток без B-frames, но, возможно, избавишься от задержки.

MPEG2 с одними ключевыми кадрами по размеру от голимого MJPEG будет отличаться слабо.

Без B-frames это не то же самое, что без P-frames.

Так что, там будут не только ключевые кадры.

спасибо, с этим флагом CODEC_FLAG_LOW_DELAY задержка стала всего 1 кадр, но к сожалению мне для моей задачи надо чтобы этот же кадр был будучи пересланным на другую сторону стал тут же раскодирован, т.е. задержка ноль кадров

никаких экстремально жестких требований к размеру передаваемых пакетов нет, кодирование видео лишь для хоть какого то уменьшения потока по сравнению с совершенно несжатым сырым потоком RGB вот и вся задача, чтобы через wifi 20-30 мегабит прокачалось например (разрешение 1024*768)

однако нагрузка на процессор большее важна, ее желательно меньше если возможно, а то что это будет не самый минимум по размеру потока - менее критично

выбирал между H264 и MPEG2 - я выяснил что H264 ужимает поток меньше но и ресурсов принципиально больше жрет, вот я и выбрал MPEG2

хочу понять - это ограничение на один кадр задержки - оно фундаментальное и непреодолимое? или мне стоит выбрать другой кодек? благо их в ffmpeg тонны

MPEG2 с одними ключевыми кадрами по размеру от голимого MJPEG будет отличаться слабо

да, действительно, MJPEG топорный кодек, но есть ли такие же топорные кодеки которые все же учитывают межкадровую разницу, скажем так некий MJPEG+, чтобы малость минимизировать разницу за счет учета предыдущих кадров?

А зачем тебе вообще MPEG2? Аппаратный кодировщик есть?

А зачем тебе вообще MPEG2? Аппаратный кодировщик есть?

не, в одном варианте у меня есть аппаратный декодер 1080p@60fps, на передающую часть я могу влепить какой нибудь аппаратный упаковщик H264 (кстати, ffpmeg работает с аппаратными кодерами?)

но есть вторая система - в ней нет аппаратного кодера-декодера ни на одной из сторон

вот я и ищу любой кодек который даст нулевую задержку упаковки кадра, потому что у меня там и так до кучи задержек... mv, есть ли такой на примете (помимо MJPEG, а может и его возьму)?

наткнулся я на интересную статью - http://x264dev.multimedia.cx/archives/249 -

1) Encoding with sliced threads on a Core i7 server takes 6.9ms for an 800×600 frame. It could actually be less; that was with settings similar to “–preset veryfast” in x264, and “ultrafast” would have been even faster (but much worse compression). 2) Decoding, well, I didn’t time it, but it better be a lot less than that, so I rounded to 10ms. Probably depends on what decoder you’re using. I know that I can decode 1080p in realtime with one core on a good system, and libavcodec supports sliced threads, so 2-4ms for decoding wouldn’t be too far off.

Since the frame is sent out immediately after encoding, the latency can be lower than 1/fps.

It’s certainly not an exact number, as it does depend heavily on the hardware, decoder used, and x264 settings used, but I think it’s a fair “order of magnitude”: one can surely get less than 10ms if one really wanted, and one could also get more.

так что думаю что буду переползать на x264, раз там сделали нечто специальное для почти нулевой задержки + «libavcodec supports sliced threads»

вот я и ищу любой кодек который даст нулевую задержку упаковки кадра, потому что у меня там и так до кучи задержек... mv, есть ли такой на примете (помимо MJPEG, а может и его возьму)?

Т.е. тебе просто для передачи видеопотока с сервера на клиент? Можно и mjpeg, libavcodec его достаточно быстро кодирует, но канал будет хорошо есть, если разрешение кадров и fps большие.

x264 в ffmpeg&co 7 лет назад клал на лопатки P4-3.2 при кодировании одного 640x480.

max_b_frames = 0 и первый же avcodec_encode_video возвращает закодированный кадр. Проверил на FFmpeg версии с прошлой весны кодек mpeg-2 video.

УМВР.

На задержку потока влияет только количество B-Frames.

Есть еще задержка начала декодирования, т.е. как быстро зритель сможет переключиться на другой канал. Это зависит от размера GOP и везения сразу попасть на I-Frame.

Если сделать gop_size = 1, то получишь только I-Frames и нигде никаких задержек не будет.

	c = avcodec_alloc_context3(codec);
	picture = avcodec_alloc_frame();

	c->bit_rate = 5000000;
	c->width = 640;
	c->height = 480;
	c->time_base.den = 60;
	c->time_base.num = 1;
	c->gop_size = 1;
	c->max_b_frames = 0;
	c->pix_fmt = PIX_FMT_YUV420P;
	c->flags |= CODEC_FLAG_LOW_DELAY;
	av_image_alloc(picture->data, picture->linesize, c->width, c->height, c->pix_fmt, 1);

все равно получается что закорм первого кадра (при помощи avcodec_encode_video) выдает ноль байт, и только второй кадр имеет размер несколько десятков килобайт и содержит первый кадр

codec_id какой?

Минимальный компилируемый код выложи для воспроизведения проблемы.

Здесь ты используешь avcodec_alloc_context3. Я подумал - ну ты крут и задача очень специфична, за такое платят большие бабки! Потом заглянул в твою соседнюю ветку про взаимодействие программ. Теперь я подумал, а ты про libavformat и вообще про транспортные заморочки, типа MPEG-TS, в курсе?

не, куда там я крут, смешно :) про mpeg-ts не в курсе

топ как раз для того чтобы знать куда копать

но я уже думаю о x264 - для него есть нормальные примеры и готовые пресеты типа zerodelay и ultrafast если скорость сжатия больше важна чем объем

codec id - mpeg2video

я почитал про mpeg2 ts - это лишь транспортный протокол который для меня имеет понятное назначение но его возможности избыточны для меня, хотя... придется и с ним познакомиться

но как mpeg2 ts решит проблему задержки на кадр?

т.е. у меня какая то проблема в коде и при тех параметрах задержка уже доджна быть нулевая?

про libavformat думал он для контейнеров типа avi mkv и т.п. ...

mpeg ts и libavformat проблему с задержкой не решит, это я отвлекся.

т.е. у меня какая то проблема в коде и при тех параметрах задержка уже доджна быть нулевая?

да. я так считаю. покажи код, который можно откомпилировать и воспроизвести проблему. у меня есть два подозрения: другой кодек (не mpeg2video), нарушена последовательность инициализации кодека. давай код.

я почитал про mpeg2 ts - это лишь транспортный протокол который для меня имеет понятное назначение но его возможности избыточны для меня, хотя... придется и с ним познакомиться

Тогда посмотри на RTP.

ок, спасибо за совет использовать RTP, почитаю

а тему отметил как решенную т.к. я перешел на x264 - с ней не возникло проблем - задержка нулевая, декодируется без проблем

там много внятных пресетов в том числе и с нулевой задержкой :)