Gstreamer hangs while generating timelapse from JPEGs on Raspberry pi - gstreamer

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:
What am I doing wrong?
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.

Answer 2

I don't have a Pi to test on right now, but I'd suspect one possible issue is that you have two OMX elements in the same process. GStreamer is just wrapping OMX and IIRC the OMX API doesn't really want you running two things at once, particularly in the same process...
I'd try it with a jpegdec instead of omxmjpegdec, with a pipeline more along these lines:
gst-launch-1.0 multifilesrc location="GOPR%04d.JPG "start-index=4711 stop-index=4750 ! image/jpeg,framerate=1/5 ! jpegdec ! videoconvert ! omxh264enc ! h264parse ! matroskamux ! filesink location=test.mkv
I don't think there is any point to using queue elements on the Pi either.