Hard to say what the problem is without access to the stream - could you run

 $ gst-launch-0.10 mmssrc location=mms://clusterstream.telenet-ops.be/tvstream1 ! filesink location=tvstream1.asf

on a command line and accumulate ~1MB of data or so (just interrupt with Control-C) and then put the file up somewhere (or try to attach it to the bug report)?


Also, the output of 

 $ gst-launch-0.10 -v mmssrc num-buffers=1024 location=mss://clusterstream.telenet-ops.be/tvstream1 ! asfdemux name=d   d.video_00 ! queue ! fakesink  d.audio_00 ! queue ! fakesink  2> log.txt
 $ gzip log.txt

might be useful (please attach gzipped log.txt.gz file). You can lower the num-buffers number if it takes too long or the file becomes too big (a few hundred lines should be enough usually).

Closing this bug report as no further information has been provided. Please feel free to reopen this bug if you can provide the information asked for.
Thanks!


(For what it's worth, there is a known issue with asfdemux not setting timestamps on the video stream correctly, so the issue here is probably the same as in some of the other open asfdemux bugs).

I've been able to run the first pipeline you gave me.  This resulted in a file that, when played, was perfect.  Video and audio are in sync when I play it with totem/gstreamer.  Though, when playing it directly from the internet-stream I still have a delay of about 3-4 seconds (sometimes less) for the audio. When playing the stream, the video also isn't fluid, while playing the file saved on disk, this is no problem.

The other pipeline gives me this error:
FOUT: van element /pipeline0/mms0: Could not connect to this stream
Extra debug-informatie:
gstmms.c(317): gst_mms_start (): /pipeline0/mms0