Avimux refused caps video/x-h264

Wed Jul 13 20:26:11 UTC 2016

Hi Peter,
Thank you for your reply.
The frame rate is actually known and a fixed rate.
I don’t know why it shows up as 0/1 in the log files.
So I tried replacing the video queue element with the following caps filter for a quick test:

                h264parse ! video/x-h264, stream-format=byte-stream, alignment=au, width=640, height=480, framerate=30/1 ! mux.

I attached updated files for you.
Now there are no more ‘refused caps’ entries in the debug log.
The pipeline starts ok and runs for a little bit but it still eventually fails with the ‘not negotiated’ error.
At this point it’s not quite clear exactly which caps negotiation failed.
Any other ideas you may have would be much appreciated!
Regards,

Bill

From: gstreamer-devel [mailto:gstreamer-devel-bounces at lists.freedesktop.org] On Behalf Of Peter Maersk-Moller
Sent: Tuesday, July 12, 2016 6:10 PM
To: Discussion of the development of and with GStreamer <gstreamer-devel at lists.freedesktop.org>
Subject: Re: Avimux refused caps video/x-h264

Hi Bill.
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.
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.
Regards
Peter

On Tue, Jul 12, 2016 at 9:52 PM, William Salibrici <bsalibrici at latticeinc.com<mailto:bsalibrici at latticeinc.com>> wrote:
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, 2147483647<tel:2147483647>/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

_______________________________________________
gstreamer-devel mailing list
gstreamer-devel at lists.freedesktop.org<mailto:gstreamer-devel at lists.freedesktop.org>
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/gstreamer-devel/attachments/20160713/487b0034/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: debug-1.log
Type: application/octet-stream
Size: 58355 bytes
Desc: debug-1.log
URL: <https://lists.freedesktop.org/archives/gstreamer-devel/attachments/20160713/487b0034/attachment-0001.obj>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: test-dash-v-1.txt
URL: <https://lists.freedesktop.org/archives/gstreamer-devel/attachments/20160713/487b0034/attachment-0001.txt>