GNOME Bugzilla – Bug 766686
Cannot play video on windows 10 64 bit
Last modified: 2017-09-22 09:44:46 UTC
Created attachment 328235 [details] Consists of the snapshot of command line and has the debug I am using gstreamer 1.8.1 and trying to play video from command line using the following command gst-launch-1.0 filesrc location=test.mpeg ! decodebin !autovideosink On windows 7 64 bit, the video plays. On windows 10 64 bit it doesn't. The attachment consists of the snapshots of the command line from windows 7 and windows 10. Also it consists of all the debug of gstreamer captured on windows 10 by setting the debug level to 6. I am not sure how to upload the mpeg file because of its big size.
Is it related to this specific file or does it happen with others too? All the same container/codecs? Please also add a videoconvert after decodebin. Can you get debug logs with GST_DEBUG=6 and attach them?
I did not try any other files. The attachment has the debug log on it. Actually the GST_DEBUG was set to 9. When I try to set the GST_DEBUG to 6, there is nothing in the log and this is what I see in the command prompt C:\gstreamer\1.0\x86_64\bin>gst-launch-1.0 filesrc location=test.mpeg ! decodebin !autovideosink Setting pipeline to PAUSED ... Pipeline is PREROLLING ... Redistribute latency... ERROR: from element /GstPipeline:pipeline0/GstDecodeBin:decodebin0/GstMpegPSDemux:mpegpsdemux0: Internal data stream error. Additional debug info: gstmpegdemux.c(2981): gst_ps_demux_loop (): /GstPipeline:pipeline0/GstDecodeBin:decodebin0/GstMpegPSDemux:mpegpsdemux0: stream stopped, reason not-negotiated ERROR: pipeline doesn't want to preroll. Setting pipeline to NULL ... Freeing pipeline ... When I try to launch the test video source as gst-launch-1.0 videotestsrc ! autovideosink I do not get any error and the test video launches. But when I tried to launch one of the test video sources as below, I am getting the same error C:\gstreamer\1.0\x86_64\bin>gst-launch-1.0.exe udpsrc port=5555 ! application/x-rtp, clock-rate=60000,payload=96 ! rtpmp4vdepay ! avdec_mpeg4 ! fpsdisplaysink Setting pipeline to PAUSED ... Pipeline is live and does not need PREROLL ... Setting pipeline to PLAYING ... New clock: GstSystemClock ERROR: from element /GstPipeline:pipeline0/GstUDPSrc:udpsrc0: Internal data flow error. Additional debug info: gstbasesrc.c(2948): gst_base_src_loop (): /GstPipeline:pipeline0/GstUDPSrc:udpsrc0: streaming task paused, reason not-negotiated (-4) Execution ended after 0:00:00.227094261 Setting pipeline to PAUSED ... Setting pipeline to READY ... Setting pipeline to NULL ... Freeing pipeline ... When I set the GST_DEBUG to 9, It hangs as below. C:\gstreamer\1.0\x86_64\bin>gst-launch-1.0.exe udpsrc port=5000 ! application/x-rtp, clock-rate=60000,payload=96 ! rtpmp4vdepay ! avdec_mpeg4 ! fpsdisplaysink Setting pipeline to PAUSED ... Pipeline is live and does not need PREROLL ... I got the log only when I set the GST_DEBUG to 9. I couldn't attach it because of its size. All of the above is happening on Windows 10 64 bit.
And when you add a videoconvert before the video sink?
The video still doesn't play.
How does it fail (not the udpsrc pipeline, the others for now)? Also please get a debug log with GST_DEBUG=6, otherwise we can't do much here.
Created attachment 328404 [details] log for video not playing on windows 10 64 bit with GST_Debug set to 6
It just hangs. Attached is the log that was collected when trying to play the video.
This looks like the Windows problem where it just stops outputting debug logs at some point. Can you try with GST_DEBUG_FILE=somefilename instead of redirecting stderr?
Both the logs that are attached are collected by setting the GST_DEBUG_FILE. For the second log that has been uploaded, the GST_DEBUG has been set to 6. I zipped the file and uploaded it because of its size.
It stops in the middle of printing a line, which usually happens because of Windows having broken stderr support. It usually works better in the msys shell than cmd.exe
The log didn't look like it had broken lines. Sorry, I am not familiar with msys shell.
The last line is: > 0:03:33.140389904 3864 0000000010A10240 INFO GST_EVENT gstevent.c:679:gst_event_new_caps: This should be followed by the actual caps after the :
Created attachment 328456 [details] log for video not playing on win 10 64 bit using msys shell Here is the log generated using msys shell. It looks same.
It does indeed, and it still looks incomplete. Maybe instead of this you can share the test.mpeg with us so we can try reproducing it ourselves on Win10 64 bit?
Created attachment 328602 [details] video file Because of file size constraints, I am attaching a file which is of smaller size. This file also doesn't play on win 10 but plays on win 7. To play the video I'm using gst-launch-1.0 filesrc location=test.mp4 ! decodebin ! autovideosink
It plays just fine here on Win10 64 bit, both with gst-play-1.0, gst-launch-1.0 playbin uri=file:///path/to/test.mp4 and gst-launch-1.0 filesrc ! decodebin ! autovideosink. I assume those other commands also fail for you the same way? During installation of the binaries, did you make sure to select everything?
Yes, I selected everything. I am using win 10 64 bit clean virtual machine on which I installed gstreamer.
Can you check again with 1.9.90 if anything improved here? If not, please get another debug log
Not enough info to do anything about this unfortunately. If it's still an issue with the latest GStreamer release (1.10.x) I'm sure someone else will run into it sooner or later and file another bug. Please feel free to re-open if it's still an issue with 1.10 and you can get us a new log. Thanks!