GStreamer appsink получает буферы намного медленнее, чем в реальном времени на плате CARMA



Я относительно недавно задал вопрос о переполнении стека, но сделаю все возможное, чтобы подробно объяснить проблему.



В настоящее время я использую IP-камеру Axis для получения живого видео на плате CARMA. Затем GStreamer берет эти кадры с помощью RTSP-клиента, выполняет RTP depayload, а затем декодирует изображения h.264, которые передаются с камеры. Когда я выполняю этот процесс на своем компьютере (в настоящее время оснащенном процессором i7), нет времени задержки, и поток вывод на экран в режиме реального времени, обновление со скоростью 30 Гц. Проблема возникает, когда я переключаюсь на доску CARMA, над которой работаю. Вместо отображения в реальном времени, appsink получает буферы со скоростью намного медленнее, чем обычно. Более конкретно, вместо приема буферов со скоростью 30 Гц, он получает только буферы со скоростью около 10 Гц в среднем, когда никакая другая обработка не происходит на плате CARMA. Следует также отметить, что никакие фреймы не отбрасываются; ссылка на приложение то есть прием буферов-это прием всех буферов, но не в реальном времени. Любое понимание того, почему это происходит, очень ценится. Я проверил, чтобы убедиться, что временные метки также не являются проблемой (т. е. скорость, с которой appsink получает буфер, не меняется, если я использую или не использую временную метку GST). Плата CARMA в настоящее время использует ubuntu 11.04 и использует GCC для компиляции. Ниже приведены некоторые фрагменты кода и их соответствующие пояснения.



Некоторые определения



#define APPSINK_CAPS "video/x-raw-yuv,format=(fourcc)I420"
#define RTSP_URI "rtsp://(ipaddress)/axis-media/media.amp?videocodec=h264"
#define RTSP_LATENCY 0
#define RTSP_BUFFER_MODE 0
#define RTSP_RTP_BLOCKSIZE 65536


Код настройки конвейера GStreamer:



      /* Initialize GStreamer */
gst_init (&argc, &argv);

/* Create the elements */
data.rtspsrc = gst_element_factory_make("rtspsrc", NULL);

data.rtph264depay = gst_element_factory_make("rtph264depay", NULL);

data.nv_omx_h264dec = gst_element_factory_make("nv_omx_h264dec", NULL);

data.appsink = gst_element_factory_make("appsink", NULL);

if (!data.rtspsrc || !data.rtph264depay || !data.nv_omx_h264dec || !data.appsink) {
g_printerr ("Not all elements could be created.n");
return -1;
}


/* Set element properties */
g_object_set( data.rtspsrc, "location", RTSP_URI,
"latency", RTSP_LATENCY,
"buffer-mode", RTSP_BUFFER_MODE,
"rtp-blocksize", RTSP_RTP_BLOCKSIZE,
NULL);
g_object_set( data.rtph264depay, "byte-stream", FALSE, NULL);
g_object_set( data.nv_omx_h264dec, "use-timestamps", TRUE, NULL);


/* Configure appsink. This plugin will allow us to access buffer data */
GstCaps *appsink_caps;
appsink_caps = gst_caps_from_string (APPSINK_CAPS);
g_object_set (data.appsink, "emit-signals", TRUE,
"caps", appsink_caps,
NULL);
g_signal_connect (data.appsink, "new-buffer", G_CALLBACK (appsink_new_buffer), &data);
gst_caps_unref (appsink_caps);


/* Create the empty pipeline */
data.pipeline = gst_pipeline_new ("test-pipeline");

if (!data.pipeline) {
g_printerr ("Pipeline could not be created.");
}


/* Build the pipeline */
/* Note that we are NOT linking the source at this point. We will do it later. */
gst_bin_add_many (GST_BIN(data.pipeline),
data.rtspsrc,
data.rtph264depay,
data.nv_omx_h264dec,
data.appsink,
NULL);

if (gst_element_link (data.rtph264depay, data.nv_omx_h264dec) != TRUE) {
g_printerr ("rtph264depay and nv_omx_h264dec could not be linked.n");
gst_object_unref (data.pipeline);
return -1;
}
if (gst_element_link (data.nv_omx_h264dec, data.appsink) != TRUE) {
g_printerr ("nv_omx_h264dec and appsink could not be linked.n");
gst_object_unref (data.pipeline);
return -1;
}


/* Connect to the pad-added signal (CALLBACK!) */
g_signal_connect (data.rtspsrc, "pad-added", G_CALLBACK (pad_added_handler), &data);

/* Add a probe to perform hashing on H.264 bytestream */
GstPad *rtph264depay_src_pad = gst_element_get_static_pad (data.rtph264depay, "src");
(gulong) gst_pad_add_buffer_probe (rtph264depay_src_pad, G_CALLBACK (hash_and_report), (gpointer)(&data));
gst_object_unref (rtph264depay_src_pad); //unreference the source pad
/* Start playing */
ret = gst_element_set_state (data.pipeline, GST_STATE_PLAYING);

if (ret == GST_STATE_CHANGE_FAILURE) {
g_printerr ("Unable to set the pipeline to the playing state.n");
gst_object_unref (data.pipeline);
return -1;
}


/* Wait until error or EOS */
bus = gst_element_get_bus (data.pipeline);
do {
msg = gst_bus_timed_pop_filtered (bus, GST_CLOCK_TIME_NONE, (GstMessageType)(GST_MESSAGE_STATE_CHANGED | GST_MESSAGE_ERROR | GST_MESSAGE_EOS));

/* Parse message */
if (msg != NULL) {
GError *err;
gchar *debug_info;

switch (GST_MESSAGE_TYPE (msg)) {
case GST_MESSAGE_ERROR:
gst_message_parse_error (msg, &err, &debug_info);
g_printerr ("Error received from element %s: %sn", GST_OBJECT_NAME (msg->src), err->message);
g_printerr ("Debugging information: %sn", debug_info ? debug_info : "none");
g_clear_error (&err);
g_free (debug_info);
terminate = TRUE;
break;
case GST_MESSAGE_EOS:
g_print ("End-Of-stream reached.n");
break;
case GST_MESSAGE_STATE_CHANGED:
/* We are only interested in state-changed messages from the pipeline */
if (GST_MESSAGE_SRC (msg) == GST_OBJECT (data.pipeline)) {
GstState old_state, new_state, pending_state;
gst_message_parse_state_changed (msg, &old_state, &new_state, &pending_state);
g_print ("Pipeline state changed from %s to %s:n", gst_element_state_get_name (old_state), gst_element_state_get_name (new_state));
}
break;
default:
//we should not reach here because we only asked for ERRORs and EOS and State Changes
g_printerr ("Unexpected message received.n");
break;
}
gst_message_unref (msg);
}
} while (!terminate);


Теперь pad_added_handler:



/* This function will be called by the pad-added signal */
//Thread 1
static void pad_added_handler (GstElement *src, GstPad *new_pad, CustomData *data) {
GstPad *sink_pad = gst_element_get_static_pad (data->rtph264depay, "sink");
GstPadLinkReturn ret;
GstCaps *new_pad_caps = NULL;
GstStructure *new_pad_struct = NULL;
const gchar *new_pad_type = NULL;

g_print ("Received new pad '%s' from '%s':n", GST_PAD_NAME (new_pad), GST_ELEMENT_NAME (src));

/* Check the new pad's type */
new_pad_caps = gst_pad_get_caps (new_pad);
new_pad_struct = gst_caps_get_structure (new_pad_caps, 0);
new_pad_type = gst_structure_get_name (new_pad_struct);
if (!g_str_has_prefix (new_pad_type, "application/x-rtp")) {
g_print (" It has type '%s' which is not RTP. Ignoring.n", new_pad_type);
goto exit;
}

/* If our converter is already linked, we have nothing to do here */
if (gst_pad_is_linked (sink_pad)) {
g_print (" We are already linked. Ignoring.n");
goto exit;
}

/* Attempt the link */
ret = gst_pad_link (new_pad, sink_pad);
if (GST_PAD_LINK_FAILED (ret)) {
g_print (" Type is '%s' but link failed.n", new_pad_type);
} else {
g_print (" Link succeeded (type '%s').n", new_pad_type);
}

exit:
/* Unreference the new pad's caps, if we got them */
if (new_pad_caps != NULL)
gst_caps_unref (new_pad_caps);

/* Unreference the sink pad */
gst_object_unref (sink_pad);
}


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



// Called when appsink receives a buffer: Thread 1
void appsink_new_buffer (GstElement *sink, CustomData *data) {
GstBuffer *buffer;

/* Retrieve the buffer */
g_signal_emit_by_name (sink, "pull-buffer", &buffer);
if (buffer) {

(((CustomData*)data)->appsink_buffer_count)++;

//push buffer onto queue, to be processed in different thread
if (GstBufferQueue->size() > GSTBUFFERQUEUE_SIZE) {
//error message
printf ("GstBufferQueue is full!n");
//release buffer
gst_buffer_unref (buffer);
} else {
//push onto queue
GstBufferQueue->push(buffer);
//activate thread
connectionDataAvailable_GstBufferQueue.notify_all();
}
}
}


Ссылка на камеру I использую:



Http://www.axis.com/products/cam_p1357/index.htm



Надеюсь, это поможет. Я буду продолжать исследовать эту проблему сам и предоставлять обновления по мере их поступления. Дайте мне знать, если вам нужна какая-либо другая информация, и я с нетерпением жду ваших ответов!



Спасибо

744   1  

1 ответ:

Таким образом, очевидно, проблема заключалась не в программе (то есть разработке программного обеспечения), а в том, что аппаратные компоненты на плате CARMA не были в состоянии идти в ногу с объемом обработки, который я выполнял. Другими словами, процессор Tegra 3 на CARMA был недостаточен как устройство. Возможные решения-сократить обработку, которую я делаю на плате CARMA, или перейти на другую плату. Я надеюсь, что это поможет людям понять, что ограниченная обработка, которая доступна на меньшие устройства, но также следует помнить, что процессоры (в частности, в категории Tegra 3, которые реализуют систему на модели чипа) в настоящее время могут не иметь вычислительной мощности, необходимой для выполнения проектов или систем, требующих больших вычислений в реальном времени.

Короче говоря, будьте осторожны с тем, что вы покупаете! Сделайте все возможное, чтобы убедиться, что то, что вы покупаете, подходит для проекта! Тем не менее, не бойтесь пробовать новые устройства. Несмотря на то, что не в состоянии сделать то, что я хотел, я узнал больше, чем мог когда-либо ожидать. В конце концов, информатика - это просто непрерывное обучение: p

Comments

    Ничего не найдено.