Video suddenly lost
Locked
 
|
This post was updated on .
I have a Windows WPF C# application using C# Bindings and OSSBuild (GStreamer WinBuilds v0.10.7, Beta 04).
It works like a charm, but yesterday when my colleague was using it on his machine, he suddenly lost the video - when a new XOverlay was created to display a new video file, suddenly all rectangles displaying video became black. The weird thing is that the change is permanent - restarting the system, uninstalling the software and even running standalone debug versions didn't help. I ran a version creating log files and I can see that GStreamer loads video files and plays them without any problems. Everything looks normal, but still no video on the screen. I tried using both dshowvideosink and d3dvideosink with no results. It seems like something is broken in the operating system, but I cannot imagine what could change so suddenly. There were no system updates and no software updates installed, all software was used exactly the same way as two days ago and two weeks ago. Has anyone witnessed anything like that? |
|
This might be a silly question, but are you trying to play the same video every time? I once had an issue where I thought I had a problem with my code but it turned out that the video I was trying to play (and had played successfully dozens of times) had become corrupt. Just sayin ...
On Wed, Oct 3, 2012 at 7:16 AM, Ralph <[hidden email]> wrote: I have a Windows WPF C# application using C# Bindings and OSSBuild (GStreamer Duff _______________________________________________ gstreamer-devel mailing list [hidden email] http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel |
|
|
No, the video files were perfectly OK, they could be played in both VLC and WMP. But... Today it started to work! I downloaded and installed LongoMatch, a Windows application using GStreamer (it provides its own copy of GStreamer library with only necessary files). It displayed the video without any problems. My application suddenly started to work! Uninstalling LongoMatch (making sure all files are deleted) and restarting the system didn't change it, my application works as usual. It seems LongoMatch triggered something in the system which allowed my application to display video correctly. Everything works now, but I still have no idea what happened... |
|
|
In reply to this post by Ralph
Perhaps your registry was corrupt. You might try running with GST_DEBUG next time and examining the output.
_______________________________________________ gstreamer-devel mailing list [hidden email] http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel |
|
|
You may be right, this would explain such behavior. I also found that libgstwaveformsink.dll was missing in my application (I don't know if it could have some influence) and after that discovery I double checked that all files are in place and they are correct versions. But... Today it stopped working again, but in a different way - the first video frame of the file is displayed and the video cannot be neither played nor sought. I uninstalled everything, deleted GStreamer 0.10 registry, restarted and installed again. Still no joy. Today I also found a different machine on which I have the same behavior - frozen first frame. Unfortunately I can't run with GST_DEBUG, it is not supported by C# bindings (see this thread). |
|
|
> Unfortunately I can't run with GST_DEBUG, it is not supported by C#
bindings (see this thread <http://gstreamer-devel.966125.n4.nabble.com/How-to-use-GStreamer-s-debug-sy stem-in-C-td2316239.html> That looks like the folks in that thread made the wrong assumption. GST_DEBUG is an environment variable and the library itself should be able to make use of it regardless of its execution environment (.NET, JVM, etc.). Try setting the environment variable on the command line, then execute your application from the same command prompt. If for some reason that doesn't work, you can recreate the pipeline and execute it via gst-launch with GST_DEBUG set. If it works there but not in your application, then there's likely something odd with either your application or the .NET bindings. If it persists, then you can attach a debugger through Visual Studio and step through the source. It would help if you could create a small sample of the video that reproduces the problem and attach it to a bug report against 0.10. You could also try getting the gstreamer SDK and testing the sample against its gst-launch on the command line. This just helps the devs help you. :D _______________________________________________ gstreamer-devel mailing list [hidden email] http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel |
|
|
This post was updated on .
Fantastic! I managed to get debug information from GStreamer! Dave, you are my hero :) For those who would like to know how to get GStreamer debug from a Windows C# application here's a short manual: 1. Modify your application to pass its command line arguments to GStreamer's Init() method. In WPF C# it looks like this: string assemblyName = Assembly.GetExecutingAssembly().FullName; string[] args = Environment.GetCommandLineArgs().Skip(1).Where(s => s.StartsWith("--")).ToArray(); bool success = true; try { Gst.Application.InitCheck(assemblyName, ref args); } catch (ApplicationException) { success = false; } if (success) { //other initialization } In this example I'm only forwarding arguments beginning with "--", but you can change it if you wish. 2. Create a batch file setting GST_DEBUG environment variable to a chosen level and executing your application: set GST_DEBUG=*:2 YourApplication.exe --enable-gst-debug=yes 2>gstreamer.log where you should replace "*:2" with your desired debug level. "2>gstreamer.log" redirects stderr to a file. "--enable-gst-debug=yes" is passed to GStreamer using the modification from step 1. 3. Run the batch file... And now back to my problem with the application not playing the video. My audio pipeline looks like this: gnlfilesource -> gnlcomposition -> audioconvert -> audioresample -> volume -> autoaudiosink For some reason autoaudiosink is not able to open the audio device: 0:00:13.765000000 5016 1021BC98 WARN default gstwaveformsink.c:386:gst_waveform_sink_prepare:<autoaudiosink0-actual-sink-waveform> error: gst_waveform_sink_prepare: waveOutOpen failed error=>A device ID has been used that is out of range for your system. This happens on just two computers, on dozens of other machines my program works fine. Anyone knows why? |
|
|
I forgot to add that I configure gnlfilesource with the following caps: "audio/x-raw-int; audio/x-raw-float".
Waveformsink fails to open the audio device. This is the code extracted from waveformsink.c which reports the error: /* open the default audio device with the given caps */ mmresult = waveOutOpen (&wfsink->hwaveout, WAVE_MAPPER, &wfx, (DWORD) waveOutProc, (DWORD) wfsink, CALLBACK_FUNCTION); if (mmresult != MMSYSERR_NOERROR) { waveOutGetErrorText (mmresult, wfsink->error_string, ERROR_LENGTH - 1); GST_ELEMENT_ERROR (wfsink, RESOURCE, OPEN_WRITE, ("gst_waveform_sink_prepare: waveOutOpen failed error=>%s", wfsink->error_string), (NULL)); return FALSE; } |
|
|
In reply to this post by Ralph
> error: gst_waveform_sink_prepare: waveOutOpen failed error=>A device ID
has been used that is out of range for your system. This sounds like an issue with your audio output device. I would open up device manager and take a look at the device configuration for conflicts, missing audio drivers, etc. If you find an issue, I'd suggest you write a patch (against master) to detect and then more gracefully deal with that scenario. That said, I'd pose a question to the gst devs -- is there an environmental sanity check done on the system before pipelines begin to roll? I know it might difficult (nigh impossible) to do an exhaustive check, but a quick, straight forward one would make sense. Just a thought... _______________________________________________ gstreamer-devel mailing list [hidden email] http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel |
|
|
No audio devices display any errors. In fact I can get sound from any other program I tried on this machine. Directsoundsink does not work on that machine at all (DSERR_NODRIVER), so I have no option but to use waveformsink. At the moment I implemented a workaround: as soon as GStreamer is initialized I create a test audio pipeline and try to play some silence. If it fails, I skip creating the audio pipeline completely. No sound is better than no video. This is just a temporary workaround, it would be nice to find out why the audio device can't be opened especially when all other programs work. |
|
|
I've just noticed something interesting. As LongoMatch works without any problems playing both video and audio, I looked at GStreamer logs created by LongoMatch and noticed that it also uses autoaudiosink which creates directsoundsink. I can see the version of libgstdirectsound.dll is the same as I am using in my software. What's different? Why an attempt to use directsoundsink returns DSERR_NODRIVER in my application while it works without any problems in LongoMatch?
|
«
Return to GStreamer-devel
|
1 view|%1 views
| Free forum by Nabble | Edit this page |