GStreamer-devel

rtp transmit occur "not-negotiated (-4)" error

Classic

List

Threaded

32 messages Options

citywolf

Re: rtp transmit occur "not-negotiated (-4)" error

hi,guodecn.

i tried the server you gived to me again,it still showed nothing.i use GST_DEBUG=3,it prints the following:

0:00:02.441339456 20844 0x804e050 INFO GST_STATES gstelement.c:2148:gst_element_continue_state:<pipeline0> completed state change to PAUSED
0:00:02.441368511 20844 0x804e050 INFO GST_STATES gstelement.c:2161:gst_element_continue_state:<pipeline0> posting state-changed READY to PAUSED
Pipeline is live and does not need PREROLL ...
Setting pipeline to PLAYING ...
0:00:02.442507269 20844 0x804e050 WARN bin gstbin.c:2080:do_bin_latency:<pipeline0> failed to query latency
0:00:02.442565659 20844 0x804e050 INFO GST_STATES gstbin.c:2197:gst_bin_change_state_func:<pipeline0> child 'ximagesink0' is changing state asynchronously to PLAYING
0:00:02.442603655 20844 0x804e050 INFO GST_STATES gstelement.c:2148:gst_element_continue_state:<ffmpegcsp0> completed state change to PLAYING
0:00:02.443110732 20844 0x804e050 INFO GST_STATES gstelement.c:2161:gst_element_continue_state:<ffmpegcsp0> posting state-changed PAUSED to PLAYING
0:00:02.443168843 20844 0x804e050 INFO GST_STATES gstbin.c:2191:gst_bin_change_state_func:<pipeline0> child 'ffmpegcsp0' changed state to 4(PLAYING) successfully
0:00:02.443217176 20844 0x804e050 INFO GST_STATES gstelement.c:2148:gst_element_continue_state:<ffdec_h2640> completed state change to PLAYING
0:00:02.443246232 20844 0x804e050 INFO GST_STATES gstelement.c:2161:gst_element_continue_state:<ffdec_h2640> posting state-changed PAUSED to PLAYING
0:00:02.443284507 20844 0x804e050 INFO GST_STATES gstbin.c:2191:gst_bin_change_state_func:<pipeline0> child 'ffdec_h2640' changed state to 4(PLAYING) successfully
0:00:02.443382290 20844 0x804e050 INFO GST_STATES gstelement.c:2148:gst_element_continue_state:<rtph264depay0> completed state change to PLAYING
0:00:02.443411905 20844 0x804e050 INFO GST_STATES gstelement.c:2161:gst_element_continue_state:<rtph264depay0> posting state-changed PAUSED to PLAYING
0:00:02.443449342 20844 0x804e050 INFO GST_STATES gstbin.c:2191:gst_bin_change_state_func:<pipeline0> child 'rtph264depay0' changed state to 4(PLAYING) successfully
0:00:02.449094796 20844 0x804e050 INFO GST_STATES gstelement.c:2148:gst_element_continue_state:<udpsrc0> completed state change to PLAYING
0:00:02.449146761 20844 0x804e050 INFO GST_STATES gstelement.c:2161:gst_element_continue_state:<udpsrc0> posting state-changed PAUSED to PLAYING
0:00:02.449205431 20844 0x804e050 INFO GST_STATES gstbin.c:2191:gst_bin_change_state_func:<pipeline0> child 'udpsrc0' changed state to 4(PLAYING) successfully
New clock: GstSystemClock

guodecn

Re: rtp transmit occur "not-negotiated (-4)" error

I can't find the problem from the print information,you may add the "videoscale" between ffmepgcolorspace and ximagesink, and have a test.

citywolf wrote

hi,guodecn.

i tried the server you gived to me again,it still showed nothing.i use GST_DEBUG=3,it prints the following:

0:00:02.441339456 20844 0x804e050 INFO GST_STATES gstelement.c:2148:gst_element_continue_state:<pipeline0> completed state change to PAUSED
0:00:02.441368511 20844 0x804e050 INFO GST_STATES gstelement.c:2161:gst_element_continue_state:<pipeline0> posting state-changed READY to PAUSED
Pipeline is live and does not need PREROLL ...
Setting pipeline to PLAYING ...
0:00:02.442507269 20844 0x804e050 WARN bin gstbin.c:2080:do_bin_latency:<pipeline0> failed to query latency
0:00:02.442565659 20844 0x804e050 INFO GST_STATES gstbin.c:2197:gst_bin_change_state_func:<pipeline0> child 'ximagesink0' is changing state asynchronously to PLAYING
0:00:02.442603655 20844 0x804e050 INFO GST_STATES gstelement.c:2148:gst_element_continue_state:<ffmpegcsp0> completed state change to PLAYING
0:00:02.443110732 20844 0x804e050 INFO GST_STATES gstelement.c:2161:gst_element_continue_state:<ffmpegcsp0> posting state-changed PAUSED to PLAYING
0:00:02.443168843 20844 0x804e050 INFO GST_STATES gstbin.c:2191:gst_bin_change_state_func:<pipeline0> child 'ffmpegcsp0' changed state to 4(PLAYING) successfully
0:00:02.443217176 20844 0x804e050 INFO GST_STATES gstelement.c:2148:gst_element_continue_state:<ffdec_h2640> completed state change to PLAYING
0:00:02.443246232 20844 0x804e050 INFO GST_STATES gstelement.c:2161:gst_element_continue_state:<ffdec_h2640> posting state-changed PAUSED to PLAYING
0:00:02.443284507 20844 0x804e050 INFO GST_STATES gstbin.c:2191:gst_bin_change_state_func:<pipeline0> child 'ffdec_h2640' changed state to 4(PLAYING) successfully
0:00:02.443382290 20844 0x804e050 INFO GST_STATES gstelement.c:2148:gst_element_continue_state:<rtph264depay0> completed state change to PLAYING
0:00:02.443411905 20844 0x804e050 INFO GST_STATES gstelement.c:2161:gst_element_continue_state:<rtph264depay0> posting state-changed PAUSED to PLAYING
0:00:02.443449342 20844 0x804e050 INFO GST_STATES gstbin.c:2191:gst_bin_change_state_func:<pipeline0> child 'rtph264depay0' changed state to 4(PLAYING) successfully
0:00:02.449094796 20844 0x804e050 INFO GST_STATES gstelement.c:2148:gst_element_continue_state:<udpsrc0> completed state change to PLAYING
0:00:02.449146761 20844 0x804e050 INFO GST_STATES gstelement.c:2161:gst_element_continue_state:<udpsrc0> posting state-changed PAUSED to PLAYING
0:00:02.449205431 20844 0x804e050 INFO GST_STATES gstbin.c:2191:gst_bin_change_state_func:<pipeline0> child 'udpsrc0' changed state to 4(PLAYING) successfully
New clock: GstSystemClock

citywolf

Re: rtp transmit occur "not-negotiated (-4)" error

still showed nothing.
how about you using my pipelines?

guodecn

Re: rtp transmit occur "not-negotiated (-4)" error

In reply to this post by Marco Ballesio

Marco Ballesio,
Because my x264enc lib dependence "x264-snapshot-20101102-2245", but ffdec_h264 dependence the "gst-ffmpeg-0.10.11", they are from different opensource, maybe not matched ,so I change h264 to h263, but other error occur, my pipeline as below:

server:
gst-launch videotestsrc ! ffenc_h263p ! rtph263ppay ! udpsink host=127.0.0.1 port=40000

client:
gst-launch udpsrc port =40000 caps="application/x-rtp,media=(string)video,clock-rate=(int)90000,encoding-name=(string)H263-1998" ! rtph263pdepay ! ffdec_h263p ! xvimagesink

when I set the GST_DEBUG=3, the client show error message as below:
0:00:00.516123278 3298 0xa08b780 ERROR ffmpeg :0:: header damaged
0:00:00.516166011 3298 0xa08b780 WARN ffmpeg gstffmpegdec.c:2259:gst_ffmpegdec_frame:<ffdec_h2630> ffdec_h263: decoding error (len: -1, have_data: 0)

The ffenc_h263p and ffdec_h263p plugins both from the same plugin lib "gst-ffmpeg-0.10.11", also the rtph263ppay and rtph263pdepay are both from the same plugin lib "gst-plugins-good-0.10.25", they should match, but still occur error.

The detailed log message is attached.

btw,could you help me test the h263 pipeline, test whether it can work well on you machine?

Marco Ballesio wrote

Hi,

On Thu, Nov 11, 2010 at 4:19 AM, guodecn <guo.dehua@zxelec.com> wrote:

>
> Marco Ballesio,
> I have follow your two advices, add the codec_data property or set
> config-interval=1, the error is still same to before.
>
> I have set the GST_DEBUG=3, and capture the log, both server and client log
> are all in the attach file.
> I will check my machine evirenment about x264enc, also I will continue to
> debug with the new log.
>

>From the log, it feels like the udpsrc is emitting packets which are not
h264. My bat-senses say that you might have more than one thing connected to
port 40000 on your system. I don't remember if I've already asked you to do
so, but could you get a tcpdump from the receiving side/machine (well,
actually it should be the same as the sending one ;) ). You can collect it
with:

tcpdump -ilo -s0 -w/path/to/tcpdump.cap

> Thank you very much for your fervor.

Mastership requires continuous exercise, and you're giving me a good chance,
so it is me who must thank you ;).

Regards

>
>
>
> Marco Ballesio wrote:
> >
> > Hi,
> >
> > mmmhhh, I've the suspect that in your case sending machine != receivning
> > machine. Maybe you've an old version of x264enc in the first one. It
> > appears, in fact, that the sending part is preparing the
> > sprop-paramenter-set (aka codec data) for being transmitted outband. You
> > can
> > try to either add the property:
> >
> >
> codec_data=(buffer)014d4015ffe10017674d4015eca0a0fd8088000003000bb9aca00078b16cb001000468ebecb2
> >
> > in your receiver udpsrc caps.
> >
> > Alternatively (but less likely to succeed) you can set the following
> > property in rtph264pay to send in-band sps and pps:
> >
> > config-interval=1
> >
> > (should send in-band sps and pps).
> >
> > If it still does not work, please attach somewher the log you get with
> > GST_DEBUG=3
> >
> > Regards
> >
> > On Wed, Nov 10, 2010 at 12:03 PM, guodecn <guo.dehua@zxelec.com> wrote:
> >
> >>
> >> Marco Ballesio,
> >> Very sadly, I use your modfied sample still the same error.
> >> I think the syntax is no problem, my os is fedora13 install on vmware
> >> workstation.
> >> I have no idea.
> >>
> >>
> >> Marco Ballesio wrote:
> >> >
> >> > Hi,
> >> >
> >> > On Wed, Nov 10, 2010 at 11:30 AM, guodecn <guo.dehua@zxelec.com>
> wrote:
> >> >
> >> >>
> >> >> Hi,Marco Ballesio,
> >> >> Thanks for your reply very much.
> >> >>
> >> >> >>However, the issue was the place you've set the "port" property.
> >> >> what's your mean? Don't udpsrc need the port property? if don't
> udpsrc
> >> >> have
> >> >> no port property, we can't receive the data.
> >> >>
> >> >
> >> > sorry, I didn't notice the "caps=" before the caps ;)
> >> >
> >> >
> >> >>
> >> >> I have modify the pipeline as below:
> >> >>
> >> >> server:
> >> >> gst-launch-0.10 -v videotestsrc ! x264enc ! rtph264pay ! udpsink
> >> >> host=127.0.0.1 port=40000
> >> >>
> >> >> client:
> >> >> gst-launch-0.10 -v udpsrc port=40000 caps=
> >> >>
> >> >>
> >>
> "application/x-rtp,media=(string)video,clock-rate=(int)90000,encoding-name=(string)H264,payload=(int)96"
> >> >> ! rtph264depay ! ffdec_h264 ! xvimagesink
> >> >>
> >> >>
> >> > These pipelines are working pretty well, both with the standard ubuntu
> >> > 10.4
> >> > and all the packages aligned with the respective upstream heads. I
> >> suggest
> >> > you to check your syntax and copy/paste efficiency ;)
> >> >
> >> > Regards
> >> >
> >> >
> >> >>
> >> >> But the same error is still exist. Can you modify my pipeline
> correct,
> >> >> and
> >> >> show me.
> >> >>
> >> >> Thanks.
> >> >> --
> >> >> View this message in context:
> >> >>
> >>
> http://gstreamer-devel.966125.n4.nabble.com/rtp-transmit-occur-not-negotiated-4-error-tp3035468p3035742.html
> >> >> Sent from the GStreamer-devel mailing list archive at Nabble.com.
> >> >>
> >> >>
> >> >>
> >>
> ------------------------------------------------------------------------------
> >> >> The Next 800 Companies to Lead America's Growth: New Video Whitepaper
> >> >> David G. Thomson, author of the best-selling book "Blueprint to a
> >> >> Billion" shares his insights and actions to help propel your
> >> >> business during the next growth cycle. Listen Now!
> >> >> http://p.sf.net/sfu/SAP-dev2dev
> >> >> _______________________________________________
> >> >> gstreamer-devel mailing list
> >> >> gstreamer-devel@lists.sourceforge.net
> >> >> https://lists.sourceforge.net/lists/listinfo/gstreamer-devel
> >> >>
> >> >
> >> >
> >>
> ------------------------------------------------------------------------------
> >> > The Next 800 Companies to Lead America's Growth: New Video Whitepaper
> >> > David G. Thomson, author of the best-selling book "Blueprint to a
> >> > Billion" shares his insights and actions to help propel your
> >> > business during the next growth cycle. Listen Now!
> >> > http://p.sf.net/sfu/SAP-dev2dev
> >> > _______________________________________________
> >> > gstreamer-devel mailing list
> >> > gstreamer-devel@lists.sourceforge.net
> >> > https://lists.sourceforge.net/lists/listinfo/gstreamer-devel
> >> >
> >> >
> >>
> >> --
> >> View this message in context:
> >>
> http://gstreamer-devel.966125.n4.nabble.com/rtp-transmit-occur-not-negotiated-4-error-tp3035468p3035787.html
> >> Sent from the GStreamer-devel mailing list archive at Nabble.com.
> >>
> >>
> >>
> ------------------------------------------------------------------------------
> >> The Next 800 Companies to Lead America's Growth: New Video Whitepaper
> >> David G. Thomson, author of the best-selling book "Blueprint to a
> >> Billion" shares his insights and actions to help propel your
> >> business during the next growth cycle. Listen Now!
> >> http://p.sf.net/sfu/SAP-dev2dev
> >> _______________________________________________
> >> gstreamer-devel mailing list
> >> gstreamer-devel@lists.sourceforge.net
> >> https://lists.sourceforge.net/lists/listinfo/gstreamer-devel
> >>
> >
> >
> ------------------------------------------------------------------------------
> > The Next 800 Companies to Lead America's Growth: New Video Whitepaper
> > David G. Thomson, author of the best-selling book "Blueprint to a
> > Billion" shares his insights and actions to help propel your
> > business during the next growth cycle. Listen Now!
> > http://p.sf.net/sfu/SAP-dev2dev
> > _______________________________________________
> > gstreamer-devel mailing list
> > gstreamer-devel@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/gstreamer-devel
> >
> >
> http://gstreamer-devel.966125.n4.nabble.com/file/n3037177/log.txt log.txt
> --
> View this message in context:
> http://gstreamer-devel.966125.n4.nabble.com/rtp-transmit-occur-not-negotiated-4-error-tp3035468p3037177.html
> Sent from the GStreamer-devel mailing list archive at Nabble.com.
>
>
> ------------------------------------------------------------------------------
> Centralized Desktop Delivery: Dell and VMware Reference Architecture
> Simplifying enterprise desktop deployment and management using
> Dell EqualLogic storage and VMware View: A highly scalable, end-to-end
> client virtualization framework. Read more!
> http://p.sf.net/sfu/dell-eql-dev2dev
> _______________________________________________
> gstreamer-devel mailing list
> gstreamer-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/gstreamer-devel
>

------------------------------------------------------------------------------
Centralized Desktop Delivery: Dell and VMware Reference Architecture
Simplifying enterprise desktop deployment and management using
Dell EqualLogic storage and VMware View: A highly scalable, end-to-end
client virtualization framework. Read more!
http://p.sf.net/sfu/dell-eql-dev2dev
_______________________________________________
gstreamer-devel mailing list
gstreamer-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/gstreamer-devel

log_h263_client.txt

guodecn

Re: rtp transmit occur "not-negotiated (-4)" error

In reply to this post by citywolf

I have test your pipeline, have the same error to you. Maybe you have the same problem with me. I can't help you. If you solve it, please tell me.

Thanks.

citywolf wrote

still showed nothing.
how about you using my pipelines?

Marco Ballesio

Re: rtp transmit occur "not-negotiated (-4)" error

In reply to this post by guodecn

Hi,

On Thu, Nov 11, 2010 at 10:22 AM, guodecn <[hidden email]> wrote:

Marco Ballesio,
I don't think there is other thing connect to port 40000, because
change to other port number still have the same problem.
I'm doubtful of the encode plugin don't match the decode plugin.You
can see my h.263 rtp transmit sample and log.

the error is given by the udpsrc, so my best assumption is that there's something wrong with the network/caps. Attaching a tcpdump may help.

Regards

Marco Ballesio wrote:
>
> Hi,
>
> On Thu, Nov 11, 2010 at 4:19 AM, guodecn <[hidden email]> wrote:
>
>>
>> Marco Ballesio,
>> I have follow your two advices, add the codec_data property or set
>> config-interval=1, the error is still same to before.
>>
>> I have set the GST_DEBUG=3, and capture the log, both server and client
>> log
>> are all in the attach file.
>> I will check my machine evirenment about x264enc, also I will continue to
>> debug with the new log.
>>
>
>>From the log, it feels like the udpsrc is emitting packets which are not
> h264. My bat-senses say that you might have more than one thing connected
> to
> port 40000 on your system. I don't remember if I've already asked you to
> do
> so, but could you get a tcpdump from the receiving side/machine (well,
> actually it should be the same as the sending one ;) ). You can collect it
> with:
>
> tcpdump -ilo -s0 -w/path/to/tcpdump.cap
>
>
>
>> Thank you very much for your fervor.
>
>
> Mastership requires continuous exercise, and you're giving me a good
> chance,
> so it is me who must thank you ;).
>
> Regards
>
>
>>
>>
>>
>> Marco Ballesio wrote:
>> >
>> > Hi,
>> >
>> > mmmhhh, I've the suspect that in your case sending machine !=
>> receivning
>> > machine. Maybe you've an old version of x264enc in the first one. It
>> > appears, in fact, that the sending part is preparing the
>> > sprop-paramenter-set (aka codec data) for being transmitted outband.
>> You
>> > can
>> > try to either add the property:
>> >
>> >
>> codec_data=(buffer)014d4015ffe10017674d4015eca0a0fd8088000003000bb9aca00078b16cb001000468ebecb2
>> >
>> > in your receiver udpsrc caps.
>> >
>> > Alternatively (but less likely to succeed) you can set the following
>> > property in rtph264pay to send in-band sps and pps:
>> >
>> > config-interval=1
>> >
>> > (should send in-band sps and pps).
>> >
>> > If it still does not work, please attach somewher the log you get with
>> > GST_DEBUG=3
>> >
>> > Regards
>> >
>> > On Wed, Nov 10, 2010 at 12:03 PM, guodecn <[hidden email]> wrote:
>> >
>> >>
>> >> Marco Ballesio,
>> >> Very sadly, I use your modfied sample still the same error.
>> >> I think the syntax is no problem, my os is fedora13 install on vmware
>> >> workstation.
>> >> I have no idea.
>> >>
>> >>
>> >> Marco Ballesio wrote:
>> >> >
>> >> > Hi,
>> >> >
>> >> > On Wed, Nov 10, 2010 at 11:30 AM, guodecn <[hidden email]>
>> wrote:
>> >> >
>> >> >>
>> >> >> Hi,Marco Ballesio,
>> >> >> Thanks for your reply very much.
>> >> >>
>> >> >> >>However, the issue was the place you've set the "port" property.
>> >> >> what's your mean? Don't udpsrc need the port property? if don't
>> udpsrc
>> >> >> have
>> >> >> no port property, we can't receive the data.
>> >> >>
>> >> >
>> >> > sorry, I didn't notice the "caps=" before the caps ;)
>> >> >
>> >> >
>> >> >>
>> >> >> I have modify the pipeline as below:
>> >> >>
>> >> >> server:
>> >> >> gst-launch-0.10 -v videotestsrc ! x264enc ! rtph264pay ! udpsink
>> >> >> host=127.0.0.1 port=40000
>> >> >>
>> >> >> client:
>> >> >> gst-launch-0.10 -v udpsrc port=40000 caps=
>> >> >>
>> >> >>
>> >>
>> "application/x-rtp,media=(string)video,clock-rate=(int)90000,encoding-name=(string)H264,payload=(int)96"
>> >> >> ! rtph264depay ! ffdec_h264 ! xvimagesink
>> >> >>
>> >> >>
>> >> > These pipelines are working pretty well, both with the standard
>> ubuntu
>> >> > 10.4
>> >> > and all the packages aligned with the respective upstream heads. I
>> >> suggest
>> >> > you to check your syntax and copy/paste efficiency ;)
>> >> >
>> >> > Regards
>> >> >
>> >> >
>> >> >>
>> >> >> But the same error is still exist. Can you modify my pipeline
>> correct,
>> >> >> and
>> >> >> show me.
>> >> >>
>> >> >> Thanks.
>> >> >> --
>> >> >> View this message in context:
>> >> >>
>> >>
>> http://gstreamer-devel.966125.n4.nabble.com/rtp-transmit-occur-not-negotiated-4-error-tp3035468p3035742.html
>> >> >> Sent from the GStreamer-devel mailing list archive at Nabble.com.
>> >> >>
>> >> >>
>> >> >>
>> >>
>> ------------------------------------------------------------------------------
>> >> >> The Next 800 Companies to Lead America's Growth: New Video
>> Whitepaper
>> >> >> David G. Thomson, author of the best-selling book "Blueprint to a
>> >> >> Billion" shares his insights and actions to help propel your
>> >> >> business during the next growth cycle. Listen Now!
>> >> >> http://p.sf.net/sfu/SAP-dev2dev
>> >> >> _______________________________________________
>> >> >> gstreamer-devel mailing list
>> >> >> [hidden email]
>> >> >> https://lists.sourceforge.net/lists/listinfo/gstreamer-devel
>> >> >>
>> >> >
>> >> >
>> >>
>> ------------------------------------------------------------------------------
>> >> > The Next 800 Companies to Lead America's Growth: New Video
>> Whitepaper
>> >> > David G. Thomson, author of the best-selling book "Blueprint to a
>> >> > Billion" shares his insights and actions to help propel your
>> >> > business during the next growth cycle. Listen Now!
>> >> > http://p.sf.net/sfu/SAP-dev2dev
>> >> > _______________________________________________
>> >> > gstreamer-devel mailing list
>> >> > [hidden email]
>> >> > https://lists.sourceforge.net/lists/listinfo/gstreamer-devel
>> >> >
>> >> >
>> >>
>> >> --
>> >> View this message in context:
>> >>
>> http://gstreamer-devel.966125.n4.nabble.com/rtp-transmit-occur-not-negotiated-4-error-tp3035468p3035787.html
>> >> Sent from the GStreamer-devel mailing list archive at Nabble.com.
>> >>
>> >>
>> >>
>> ------------------------------------------------------------------------------
>> >> The Next 800 Companies to Lead America's Growth: New Video Whitepaper
>> >> David G. Thomson, author of the best-selling book "Blueprint to a
>> >> Billion" shares his insights and actions to help propel your
>> >> business during the next growth cycle. Listen Now!
>> >> http://p.sf.net/sfu/SAP-dev2dev
>> >> _______________________________________________
>> >> gstreamer-devel mailing list
>> >> [hidden email]
>> >> https://lists.sourceforge.net/lists/listinfo/gstreamer-devel
>> >>
>> >
>> >
>> ------------------------------------------------------------------------------
>> > The Next 800 Companies to Lead America's Growth: New Video Whitepaper
>> > David G. Thomson, author of the best-selling book "Blueprint to a
>> > Billion" shares his insights and actions to help propel your
>> > business during the next growth cycle. Listen Now!
>> > http://p.sf.net/sfu/SAP-dev2dev
>> > _______________________________________________
>> > gstreamer-devel mailing list
>> > [hidden email]
>> > https://lists.sourceforge.net/lists/listinfo/gstreamer-devel
>> >
>> >
>> http://gstreamer-devel.966125.n4.nabble.com/file/n3037177/log.txt log.txt
>> --
>> View this message in context:
>> http://gstreamer-devel.966125.n4.nabble.com/rtp-transmit-occur-not-negotiated-4-error-tp3035468p3037177.html
>> Sent from the GStreamer-devel mailing list archive at Nabble.com.
>>
>>
>> ------------------------------------------------------------------------------
>> Centralized Desktop Delivery: Dell and VMware Reference Architecture
>> Simplifying enterprise desktop deployment and management using
>> Dell EqualLogic storage and VMware View: A highly scalable, end-to-end
>> client virtualization framework. Read more!
>> http://p.sf.net/sfu/dell-eql-dev2dev
>> _______________________________________________
>> gstreamer-devel mailing list
>> [hidden email]
>> https://lists.sourceforge.net/lists/listinfo/gstreamer-devel
>>
>
> ------------------------------------------------------------------------------
> Centralized Desktop Delivery: Dell and VMware Reference Architecture
> Simplifying enterprise desktop deployment and management using
> Dell EqualLogic storage and VMware View: A highly scalable, end-to-end
> client virtualization framework. Read more!
> http://p.sf.net/sfu/dell-eql-dev2dev
> _______________________________________________
> gstreamer-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/gstreamer-devel
>
>

--
View this message in context: http://gstreamer-devel.966125.n4.nabble.com/rtp-transmit-occur-not-negotiated-4-error-tp3035468p3037374.html

Sent from the GStreamer-devel mailing list archive at Nabble.com.

------------------------------------------------------------------------------
Centralized Desktop Delivery: Dell and VMware Reference Architecture
Simplifying enterprise desktop deployment and management using
Dell EqualLogic storage and VMware View: A highly scalable, end-to-end
client virtualization framework. Read more!
http://p.sf.net/sfu/dell-eql-dev2dev
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gstreamer-devel

------------------------------------------------------------------------------
Centralized Desktop Delivery: Dell and VMware Reference Architecture
Simplifying enterprise desktop deployment and management using
Dell EqualLogic storage and VMware View: A highly scalable, end-to-end
client virtualization framework. Read more!
http://p.sf.net/sfu/dell-eql-dev2dev
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gstreamer-devel

guodecn

Re: rtp transmit occur "not-negotiated (-4)" error

In reply to this post by citywolf

citywolf,
Have you solve the rtp transmit "not-negotiated (-4)" error ?

citywolf wrote

still showed nothing.
how about you using my pipelines?

citywolf

Re: rtp transmit occur "not-negotiated (-4)" error

no...
how about you?

on my machine,audio network streaming pipelines works fine,but no video pipelines works successful.

do you have examples of video network streaming pipelines that just over udp? no rtp,just udp.

citywolf

Re: rtp transmit occur "not-negotiated (-4)" error

In reply to this post by guodecn

guodecn

答复: rtp transmit occur "not-negotiated (-4)" error

I have test udp transmit, still error.

发件人: citywolf [via GStreamer-devel] [mailto:[hidden email]]
发送时间: 2010年11月15日 10:03
收件人: [hidden email]
主题: Re: rtp transmit occur "not-negotiated (-4)" error

View message @ http://gstreamer-devel.966125.n4.nabble.com/rtp-transmit-occur-not-negotiated-4-error-tp3035468p3042421.html
To unsubscribe from rtp transmit occur "not-negotiated (-4)" error, click here.

citywolf

Re: rtp transmit occur "not-negotiated (-4)" error

In reply to this post by citywolf

you chinese?do you use qq?
my qq number is 287698504

Agostino De Matteis

Re: rtp transmit occur "not-negotiated (-4)" error

In reply to this post by citywolf

citywolf wrote:

> do you have examples of video network streaming pipelines that just over
> udp? no rtp,just udp.

Hi.

I use a pipeline (C code) that, for the video streaming, looks like this:

Server:

v4l2src -> videoscale -> capsfilter -> timeoverlay -> x264enc ->
rtph264pay -> udpsink

Parameters for x264enc:
bitrate = 2000,
byte-stream = 1
cabac = 0

Parameters for rtph264pay:
mtu = 1438

Caps used for capsfilter:

gst_caps_from_string("video/x-raw-yuv,width=(int)352,height=(int)288,framerate=(fraction)15/1,format=(fourcc)I420");

Client:

udpsrc -> gstrtpjitterbuffer -> queue -> rtph264depay -> ffdec_h264 ->
queue -> videoscale -> ffmpegcolorspace -> queue -> ximagesink

Caps for udpsrc:

gst_caps_new_simple ("application/x-rtp",
"clock-rate", G_TYPE_INT, 90000,
"encoding-name", G_TYPE_STRING, "H264",
NULL);

As a matter of fact my pipeline is both server and client.

I'm still not sure this is the right/better way to do it but at least it
seems to work :-)

IIRC I got rid of the "not-negotiated error" adding the caps for udpsrc
(client), the capsfilter after videoscale (server), the videoscale
elements (server and client) and the ffmpegcolorspace element (client).

HTH

Regards.

------------------------------------------------------------------------------
Centralized Desktop Delivery: Dell and VMware Reference Architecture
Simplifying enterprise desktop deployment and management using
Dell EqualLogic storage and VMware View: A highly scalable, end-to-end
client virtualization framework. Read more!
http://p.sf.net/sfu/dell-eql-dev2dev
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gstreamer-devel