shmsrc CAPS negotiation problem SOLVED [was: shmsrc gst app pipeline stalling]

[mattes]

I finally figured out how to solve my problem with shmsrc as a video source.

Running the following pipelines works fine, when run from the command line:

server:
  gst-launch -v videotestsrc ! \
     video/x-raw-yuv,width=640,height=480,framerate=30/1,'format=(fourcc)I420'
! \
     shmsink socket-path=/tmp/mysock shm-size=10000000 wait-for-connection=0 

client:
 gst-launch -e shmsrc socket-path=/tmp/mysock is-live=1  do-timestamp=1 !  \
    video/x-raw-yuv,format=\(fourcc\)I420,width=640,height=480,framerate=30/1 !
 \
   videorate ! x264enc ! qtmux ! filesink location=video.mp4

I replaced the client with a c-program using the GStreamer C-api.
The result was the pipeline went into PLAY state and then error out.

I used the following caps filter in  my program:

      filtercaps = gst_caps_new_simple ("video/x-raw-yuv",
         "format", G_TYPE_STRING, "I420",
         "width", G_TYPE_INT, 640,
         "height", G_TYPE_INT, 480,
         "framerate", GST_TYPE_FRACTION, 30, 1,
         NULL);

Going through the debug output I noticed that the caps negotiation between
videorate and x264enc failed and causing the pipeline to abort.

The source caps  showed this:
   video/x-raw-yuv, format=(string)I420, width=(int)640, height=(int)480,
framerate=(fraction)30/1;

The sink caps of x264enc are this:

   video/x-raw-yuv, format=(fourcc){ I420, YV12 }, framerate=(fraction)[ 0/1,
2147483647/1 ], width=(int)[ 16, 2147483647 ], height=(int)[ 16, 2147483647 ]

Nothing wrong on the first look, until I spotted this:

  "format=(string)I420"  is not compatible with  "format=(fourcc){I420,YV12}"

Not clear at first, but I assumed that the caps negotiation failed, due
to the wrong format type. I changed my code to the following:

      filtercaps = gst_caps_new_simple ("video/x-raw-yuv",
         "format", GST_TYPE_FOURCC, GST_MAKE_FOURCC('I', '4', '2', '0'), 
          ....

Now my c-program works the same way the command pipeline sample does.

Everything was tested with 0.10.36

What was misleading in the beginning is that using 'v4l2src' as a video source
does not expose this problem. Only when using 'shmsrc' the problem cropped
up. Not sure why, but I am certain there is a reason.

Hope that helps somebody to avoid such mistake.
PS: make sure to use the correct manual for your gstreamer version.

Mat