<div dir="ltr"><div><div><div><div>Hi Bill. </div>It may not be this, but I've noticed in one of your log files that the framerate of the video is 0/1. gst-inspect does say that avimux allows for framerate 0/1, but I have had issues with that earlier that were gone when using fixed framerate. </div>Also AVI, if that is what avimux actually makes, does not support variable framerates. There is a hack, yes, that may work, but that would hardly work for streaming and I would not believe that would be put into avimux. </div>Regards </div>Peter </div><div class="gmail_extra"> <div class="gmail_quote">On Tue, Jul 12, 2016 at 9:52 PM, William Salibrici <<a href="mailto:bsalibrici@latticeinc.com" target="_blank">bsalibrici@latticeinc.com</a>> wrote: <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> <div link="#0563C1" vlink="#954F72" lang="EN-US"> <div> Hello, The following rtpbin receiver pipeline works just fine for me. My receiver machine is windows 7, 64 bit and I’m using GStreamer 1.8.1 with your windows pre-built binaries. I receive an h264 video stream and display it and its associated mulaw audio stream and play it. The audio and video are synchronized and all is well here. rtpbin name=rtpbin udpsrc address="192.168.1.101" port=5018 caps="application/x-rtp,media=video,clock-rate=90000,encoding-name=H264,payload=96" ! rtpbin.recv_rtp_sink_0 rtpbin. ! rtph264depay ! h264parse ! openh264dec ! videoconvert ! d3dvideosink udpsrc address="192.168.1.101" port=5020 caps="application/x-rtp,media=audio,clock-rate=8000,encoding-name=PCMU,payload=0" ! rtpbin.recv_rtp_sink_1 rtpbin. ! rtppcmudepay ! mulawdec ! directsoundsink Next I’m attempting to use the following similar rtpbin receiver pipeline to mux the audio and video streams together to create a movie file and it fails with ‘streaming task paused, reason not-negotiated (-4)’. As you can see, the front end of this pipeline [for each stream up to the queues] is identical to the one above that works ok. My rtpbin sender is sending identical data for both receiver pipelines using the same ports for audio and video. rtpbin name=rtpbin udpsrc address="192.168.1.101" port=5018 caps="application/x-rtp,media=video,clock-rate=90000,encoding-name=H264,payload=96" ! rtpbin.recv_rtp_sink_0 rtpbin. ! rtph264depay ! h264parse ! queue ! mux. udpsrc address="192.168.1.101" port=5020 caps="application/x-rtp,media=audio,clock-rate=8000,encoding-name=PCMU,payload=0" ! rtpbin.recv_rtp_sink_1 rtpbin. ! rtppcmudepay ! queue ! mux. avimux name=mux ! filesink location=C:/my/movie.avi sync=true max-lateness=900000000 I have attached three [reasonably small] debug files as follows: debug.log – obtained with ‘set GST_DEBUG=2,*udp*:6,*avi*:6’. test-normal.txt – screen capture for ‘gst-launch-1.0 –e’ of pipeline. test-dash-v.txt - screen capture for ‘gst-launch-1.0 –e -v’ of pipeline [shows some caps info]. If you look at line 273 of the debug log, you will see the following: ‘gst_avi_mux_vidsink_set_caps:<mux> refused caps video/x-h264, …’ Using the inspect tool for avimux shows the following for an acceptable sink pad capability: video/x-h264 stream-format: byte-stream alignment: au width: [ 16, 4096 ] height: [ 16, 4096 ] framerate: [ 0/1, <a href="tel:2147483647" value="+12147483647" target="_blank">2147483647</a>/1 ] So it appears as though an acceptable sink capability is being rejected but I don’t understand why. I might be tripping over something simple. Any ideas on what I could be doing wrong? Thanks, Bill </div> </div> _______________________________________________ gstreamer-devel mailing list <a href="mailto:gstreamer-devel@lists.freedesktop.org">gstreamer-devel@lists.freedesktop.org</a> <a href="https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel" rel="noreferrer" target="_blank">https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel</a> </blockquote></div> </div>