For the typefind one I had tried to use

openFile: aFileName
	| player checkForPending decoder capsPointer capsData capsDataString |

	player := self new.
	player filesrc: aFileName.
	player oggHookupToTypeFind.
	decoder := player pipeLine findElementCalled: 'typefind'.
	player play.
	capsPointer := decoder getKeyValuePointer: 'caps'.
	self halt.
	capsData := GStreamerCaps handle: capsPointer.
	capsDataString := capsData getString.
	self halt.
....



oggHookupToTypeFind
	| file  result typeFind |

	file := GStreamerElement elementFactoryMake: 'filesrc' name: 'filesrc'.
	file setKey: 'location' toStringValue: self filesrc.
	typeFind := GStreamerElement elementFactoryMake: 'typefind' name:  
'typefind'.

	"Setup the pipeline"
	pipeLine := GStreamerPipeline name: 'my-pipeline'.
	pipeLine addElement: file.
	pipeLine addElement: typeFind.

	result := GStreamerSystem default linkElementSrc: file toDest:  
typeFind.



to get back the caps

  caps                : detected capabilities in stream
                         flags: readable
                         Caps (NULL)

But that returns

capsDataString -> "'application/ogg'"

for both audio and video files which is not helpful


On Aug 14, 2008, at 11:51 PM, Yoshiki Ohshima wrote:

>>> * #openFile: was written under the assumption that .ogg file is
>>>    either "video and audio" or "audio only" but I have a file that
>>>    is "video only".  If I open a video only file with older
>>>    definition, it basically forever paused and wait until it is
>>>    ready and doesn't play it back.  #openFile: should check the type
>>>    of tracks and call a proper #oggHookupToSqueak... method.  But is
>>>    there a simple way to query it when I have the filesrc element?
>>
>> Yes there is a problem there, I was looking at "typefind" to see if  
>> we
>> could decide what type of file it is, but
>> that might require a plugin change in order to get the CAPS element
>> back.  I was also trying to see if you
>> could resolve pipeline setup as always both setup with audio/video  
>> and
>> work with that, but haven't gotten
>> around to testing it, however you are welcome to try. In this case  
>> you
>> could ask the elments for attribute data to see
>> if there are frames, or audio?
>
>  I'll give it a try.  Thank you!
>
> -- Yoshiki

--
= 
= 
= 
========================================================================
John M. McIntosh <johnmci at smalltalkconsulting.com>
Corporate Smalltalk Consulting Ltd.  http://www.smalltalkconsulting.com
= 
= 
= 
========================================================================