After changing norm with gsttuner interface, pipeline fails to go into playing state

[wally bkg]

I'm having a problem with the gsttuner interface changing the video norm but
the pipeline not going to PLAYING afterwards.  My capture cards all seem to
default to PAL on power up, I need to set them to NTSC before I can use
them.

Can someone offer me a clue as to why the v4l2src pipline would fail to go
into Playing state after the video norm has been changed using the gsttuner
interface?

After a reboot, (or setting the norm to PAL with another application):
The v4l2 device is '/dev/video1'.
Previous Norm: PAL
Current Norm: NTSC
Capturing from v4l2src to appsink
isource failed to go into PLAYING state
Reading from appsrc to xvimagesink
^C

But if I run the program again:

The v4l2 device is '/dev/video1'.
Previous Norm: NTSC
Current Norm: NTSC
Capturing from v4l2src to appsink
Reading from appsrc to xvimagesink
Main Loop Running...
obus Error: Output window was closed
Returned, stopping playback
Deleting pipelines


Closing the xvimagesink is my  "normal" exit mode for the time being and
probably will be a good choice overall for my needs.  I've about six
different capture cards and a pair of USB capture devices and all have this
issue.  I can reset the norm to PAL with xawtv or TVtime and repeat the
process, locks up when changing the norm, works the second time I run the
program as the norm has been changed before the lockup.

I assume the lockup is because without the appsink running the pipeline that
starts with appsrc never runs.

If I remove the appsink and appsrc and make only a single pipeline then it
seems to always start after the norm change, but then is pretty useless to
me as the whole point is to use the appsink to source data for my image
processing and then use a pair of appsrc pipelines for real time visual
feedback and recording the output to disk.

--wally.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/gstreamer-devel/attachments/20110413/f862b7db/attachment-0001.htm>