Problem with filesink to named pipe

[Anne Ogborn]

I have a camera on an embedded OMAP board. I'm trying to read it by camera to gstreamer to java via a named pipe. I'm having trouble getting it to work. To eliminate the java, I've been substituting tail -f for the receiver.

Under gstreamer 0.10 this script works fine to write the data to file (and the file can be played back by my java).

#!/bin/bash
rm /tmp/camera_pipe
mkfifo /tmp/camera_pipe
chmod 777 /tmp/camera_pipe
gst-launch -v -e omx_camera device=0 do-timestamp=1 mode=0 name=cam cam.src ! \
"video/x-raw-yuv, format=(fourcc)NV12, width=240, height=320, framerate=30/1" ! tee name=t1 t1. ! queue ! ducatih264enc profile=100 level=50 rate-preset=low-delay bitrate=24000 ! h264parse ! \
queue ! avimux ! filesink location=/mydir/somefile.avi t1. ! queue ! dri2videosink sync=true

the log spew contains

(gst-launch-0.10:13594): GLib-GObject-CRITICAL **: Read/writable property 'exposure' on class 'GstOmxCamera' has type 'GstOmxCameraExposureControl' which is not exactly equal to the type 'guint' of the property on the interface 'GstPhotography'

and 

src/omx_proxy_camera.c:248Camera_SendCommand()ERROR:  Error in DCC Init


Changing the filesink location to a named pipe makes it 'choke' - attaching to the pipe with tail -f , nothing comes out until I C-c the pipeline, at which point I get one buffer's worth (I assume, it's a couple screens) of binary.

I'm a gstreamer newbie. I'm pretty comfortable I've checked the obvious like permissions on the named pipe.

I've tried inserting and removing queue elements at various points.

I've tried using cat to prove I can see random stuff through the pipeline

I'm pretty much at wits end here.

Can anybody suggest any other ways of attacking the problem? I've been at this for 4 days now. Am I barking up the wrong tree - is using filesink a guaranteed trail of tears? What are other people doing to get data out of gstreamer pipelines at the end? 
I've gotten it to write out via tcpserversink, but since the Java's reading using OpenCV2.4.8's VideoCapture, it will only take a file. Having telnet in the midst of the connection seems perverse.

Xc[   <-- artist's rendition of Annie after staring at this a while.


Thanks,

Annie