Gstreamer hangs while generating timelapse from JPEGs on Raspberry pi

Question

Situation:

I want to generate a timelapse on my Raspberry Pi 512mb, using the onboard H.264 encoder.

Input: +300 JPEG files (2592 x 1944 pixels), example: http://i.imgur.com/czohiki.jpg

Output: h264 video file (2592 x 1944 pixels)

GStreamer 1.0.8 + omxencoder (http://pastebin.com/u8T7mE18)

Raspberry Pi version: Jun 17 2013 20:45:38 version d380dde43fe729f043befb5cf775f99e54586cde (clean) (release)

Memory: gpu_mem_512=400

Gstreamer pipeline:

sudo gst-launch-1.0 -v multifilesrc location=GOPR%04d.JPG start-index=4711 stop-index=4750 caps="image/jpeg,framerate=(fraction)25/1" do-timestamp=true ! omxmjpegdec ! videorate ! video/x-raw,framerate=1/5 ! videoconvert ! omxh264enc ! "video/x-h264,profile=high" ! h264parse ! queue max-size-bytes=10000000 ! matroskamux ! filesink location=test.mkv --gst-debug=4

Problem: Gstreamer hangs and no output is generated.

--gst-debug=4:

0:00:01.027331700 2422 0x17824f0 INFO GST_EVENT gstevent.c:709:gst_event_new_segment: creating segment event time segment start=0:00:00.000000000, stop=99:99:99.999999999, rate=1.000000, applied_rate=1.000000, flags=0x00, time=0:00:00.000000000, base=0:00:00.000000000, position 0:00:00.000000000, duration 99:99:99.999999999

0:00:29.346875982 2422 0x17824f0 INFO basesrc gstbasesrc.c:2619:gst_base_src_loop: pausing after gst_base_src_get_range() = eos

--gst-debug=5:

0:01:16.089222125 2232 0x1fa8f0 DEBUG basesrc gstbasesrc.c:2773:gst_base_src_loop: pausing task, reason eos

0:01:16.095962979 2232 0x1fa8f0 DEBUG GST_PADS gstpad.c:5251:gst_pad_pause_task: pause task

0:01:16.107724723 2232 0x1fa8f0 DEBUG task gsttask.c:662:gst_task_set_state: Changing task 0x2180a8 to state 2

0:01:16.435800597 2232 0x1fa8f0 DEBUG GST_EVENT gstevent.c:300:gst_event_new_custom: creating new event 0x129f80 eos 28174

0:01:16.436191588 2232 0x1fa8f0 DEBUG GST_PADS gstpad.c:4628:gst_pad_push_event: event eos updated

0:01:16.436414584 2232 0x1fa8f0 DEBUG GST_PADS gstpad.c:3333:check_sticky: pushing all sticky events

0:01:16.436620579 2232 0x1fa8f0 DEBUG GST_PADS gstpad.c:3282:push_sticky: event stream-start was already received

0:01:16.436816575 2232 0x1fa8f0 DEBUG GST_PADS gstpad.c:3282:push_sticky: event caps was already received

0:01:16.437001571 2232 0x1fa8f0 DEBUG GST_PADS gstpad.c:3282:push_sticky: event segment was already received

0:01:16.440457495 2232 0x1fa8f0 DEBUG GST_EVENT gstpad.c:4771:gst_pad_send_event_unchecked: have event type eos event at time 99:99:99.999999999: (NULL)

0:01:16.449986289 2232 0x1fa8f0 DEBUG videodecoder gstvideodecoder.c:1144:gst_video_decoder_sink_event: received event 28174, eos

0:01:16.462165024 2232 0x1fa8f0 DEBUG omxvideodec gstomxvideodec.c:2489:gst_omx_video_dec_drain: Draining component

0:01:16.463930986 2232 0x1fa8f0 DEBUG omx gstomx.c:1223:gst_omx_port_acquire_buffer: Acquiring video_decode buffer from port 130

0:01:16.465537951 2232 0x1fa8f0 DEBUG omx gstomx.c:1334:gst_omx_port_acquire_buffer: video_decode port 130 has pending buffers

0:01:16.466576928 2232 0x1fa8f0 DEBUG omx gstomx.c:1353:gst_omx_port_acquire_buffer: Acquired buffer 0x21f938 (0xb2068550) from video_decode port 130: 0

0:01:16.468237892 2232 0x1fa8f0 DEBUG omx gstomx.c:1375:gst_omx_port_release_buffer: Releasing buffer 0x21f938 (0xb2068550) to video_decode port 130

0:01:16.470360846 2232 0x1fa8f0 DEBUG omx gstomx.c:1420:gst_omx_port_release_buffer: Released buffer 0x21f938 to video_decode port 130: None (0x00000000)

0:01:16.472046809 2232 0x1fa8f0 DEBUG omxvideodec gstomxvideodec.c:2544:gst_omx_video_dec_drain: Waiting until component is drained

Full console dump: https://mega.co.nz/#!eI1ASBSY!R4mnuGqRH7M8dT4q6j03mBKsQ1A-7oCXU4stu50LnOw

Question:

1. What am I doing wrong?

2. Is there another or more efficient way to create high res timelapses from JPEGs on a raspberry pi?

Answer 1

Sorry about the necro, but I think this is trying to use the Raspberry Pi HW H264 encoder at a higher resolution than it is capable of. It can manage just over 1080p30, and has a maximum line length of 2048 pixels, so your source images are too large.

You could try MJPEG which does not have the same limitation.