Здравствуйте, Sharov, Вы писали:

S>С playbin у меня вообще не пошло: пытался добавить свой appsink вместо video-sink -- вылетало окно с показом кадра,
S>пытался линковать playbin и appsink -- просто падало. Т.е. пока filesrc + decodebin+appsink без альтернативы.

Сложно так сказать почему — смотреть надо.

S>Да, я еще погоняю под Debug. У меня такой вариант использования -- нахожу нужный кадр, конвертирую в jpeg, перевожу pipe в Ready.
S>И далее по кругу, с другим файлом. Ну т.е. один pipe для чтения файлов, а не 1 к 1. Ну так вот, после pipe.SetState(Ready) -- блочится
S>на этой строке. Буду более детально смотреть, т.к. совершенное не понятно что не так. Тут пишут, что надо в Ready переводить.

У тебя там блочится на первой же итерации? И такой вопрос: а не занимает ли у тебя перевод конвертация достаточно продолжительное время? По моему опыту в большинстве случаев виснет если буфера переполнены. Я бы попробовал queue в пайплайн добавить. Сначала без ограничения размера и посмотрел бы, как размер памяти процесса себя ведёт. Ну и менял бы параметры, если используется SetState, только после того, как получено сообщение, что состояние изменено. Ты bus-овские сообщения обрабатываешь?

S>Благодарю! Кстати, я там еще один вопрос задал: зная номер n кадра из видео как быстрее его получить --
S>frame stepper (pullsample) n-1 раз, или можно как-то сделать Seek с буфферами?

Хороший вопрос. Сам не пробовал, но из общих соображений понятно, что gst_element_seek должен быть быстрее, однако ограничение есть:

GST_FORMAT_DEFAULT (1) –

the default format of the pad/element. This can be samples for raw audio, frames/fields for raw video (some, but not all, elements support this; use GST_FORMAT_TIME if you don't have a good reason to query for samples/frames)

У тебя же не raw. Можно, конечно, еще попробовать по требуемому номеру кадра и fps расчитать временную метку и уже по ней seek делать. Ну и проверить, насколько точно получается.

И такой вопрос: ты решения вопросов по времени получаемых кадров в результате нашёл (предыдущие темы)?
У нас в конечном счёте решение такое сложилось (камеры в 85-90% случаев аналоговые, без времени, для оставшихся 10-15% rtsp-случаев используется тот же механизм): используем время того компа, на котором осуществляется запись — есть буфер текущего кадра, и приходящее от камеры обновляет его, запись осуществляется с фиксированным fps (appsrc) и данные берёт из буфера текущего кадра. Таким образом отвязываясь от состояния камеры, потерь кадров и т.д. Что есть в буфере кадра на текущий момент, то и считаем актуальным для камеры. Понятно, что в случае rtsp есть задержка, но для наших задач приемлемо.