There has been some developments. It seems the issue is related to the type of video that is being played (maybe the resolution size, or something like that). The video I was trying to play is a MP4 file, and then I found that AVIs can be played, so I thought the problems were MP4 files. On Windows, AVICodec (tool) reports them as: * bad.mp4 File : 22 MB (22 MB), duration: 0:00:50, type: DSH, 1 audio stream(s), quality: 98 % Video : 13.04 MB, 2188 Kbps, 29.970 fps, 1280*768 (16:9), YV12 = Unknown, Supported Audio : 9.15 MB, 1536 Kbps, 48000 Hz, 2 channels, 0xFF = Unknown, Unsupported * good.avi: File : 12.81 MB (12.81 MB), duration: 0:00:59, type: AVI, 1 audio stream(s), quality: 69 % Video : 11.90 MB, 1692 Kbps, 25.0 fps, 720*320 (2.21:1), XVID = XVID Mpeg-4, Supported Audio : 921 KB, 128 Kbps, 44100 Hz, 2 channels, 0x55 = Lame MP3, Supported One of the interesting things we've done is convert bad.mp4 to the same format used by good.avi, and the resulting video also didn't worked. So my theory that the problem was in MP4 files went down the hole, check it out: * converted: File : 5.14 MB (5.14 MB), duration: 0:00:50, type: AVI, 1 audio stream(s), quality: 70 % Video : 3.80 MB, 638 Kbps, 29.970 fps, 1280*768 (16:9), XVID = XVID Mpeg-4, Supported Audio : 1.33 MB, 224 Kbps, 48000 Hz, 2 channels, 0x55 = Lame MP3, Supported The converted video is virtually in the same format as good.avi and it still doesn't work. In case you are interested, the following command shows the pipeline used by my application and it successfully plays MP4 files on Linux: gst-launch filesrc location=bad.mp4 ! decodebin name=decoder decoder. ! audioconvert ! audioresample ! autoaudiosink decoder. ! ffmpegcolorspace ! capsfilter caps=video/x-raw-rgb ! ximagesink I think the next commands are the Windows equivalent of that. I just changed the video sink element at the end but none seems to work: gst-launch.exe filesrc location=bad.mp4 ! decodebin name=decoder decoder. ! audioconvert ! audioresample ! directsoundsink decoder. ! ffmpegcolorspace ! capsfilter caps="video/x-raw-rgb" ! dshowvideosink 0:00:00.109375000 3360 00332E00 ERROR GST_PIPELINE grammar.tab.c:713:gst_parse_perform_link: could not link capsfilter0 to dshowvideosink0 WARNING: erroneous pipeline: could not link capsfilter0 to dshowvideosink0 gst-launch.exe filesrc location=bad.mp4 ! decodebin name=decoder decoder. ! audioconvert ! audioresample ! directsoundsink decoder. ! ffmpegcolorspace ! capsfilter caps="video/x-raw-rgb" ! sdlvideosink 0:00:00.109375000 240 00332E00 ERROR GST_PIPELINE grammar.tab.c:713:gst_parse_perform_link: could not link capsfilter0 to sdlvideosink0 WARNING: erroneous pipeline: could not link capsfilter0 to sdlvideosink0 and finally trying with autovideosink, it looks like it will play the file but it does nothing: C:\ossbuild\Build\Windows\Win32\Release\bin>gst-launch.exe filesrc location=bad.mp4 ! decodebin name=decoder decoder. ! audioconvert ! audioresample ! directsoundsink decoder. ! ffmpegcolorspace ! capsfilter caps="video/x-raw-rgb" ! autovideosink Setting pipeline to PAUSED ... Pipeline is PREROLLING ... I could use some help from the experts. Thank you all, -- Karl Phillip <div class="gmail_quote">On Tue, Dec 20, 2011 at 12:01 PM, Karl Phillip <<a href="mailto:maxphil@gmail.com">maxphil@gmail.com</a>> wrote: <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I wrote a Video Player for Linux that uses QtGstreamer. It works beatifully! Now that I've successfully compiled and tested gstreamer/qtgstreamer for Windows I decided it was time to compile my Video Player for Windows as well, and so it was done, flawlessly. However, when my application is executed audio/video is not being played. I know that onNewDecodedPad() is being triggered for "audio/x-raw-int" and "video/x-raw-rgb", and I'm also certain that all the pipeline setup is good since it works on Linux. Here is what is happening: my VideoPlayer class inherits from QGst::Utils::ApplicationSink , and I noticed that newBuffer() is not being called when the pipeline is set to QGst::StatePlaying. That's odd, right? So I addSignalWatch() to the pipeline bus and further testes revelead that after everything is properly configured and loaded, i.e. after onNewDecodedPad() is executed for both audio/video streams saying that everything is good to go, setting the pipeline to: pipeline->setState(QGst::StatePlaying); doesn't trigger a QGst::MessageStateChanged event, nor a QGst::MessageError event. I don't know what's going on since I can see the very same code working on Linux. What could be causing this? I have added debugs for virtually every QtGstreamer call that is being done, so if anything had failed during the setup I would know. Thanks guys, -- Karl Phillip </blockquote></div>