gst-rtsp-server and ffmpeg message

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

gst-rtsp-server and ffmpeg message

Thành Trung Nguyễn
Hi,

I'm working on a project that use gst-rtsp-server as the streaming server and got the following message on the client with h264 and mpeg4 video format:

ffmpeg :0:: warning: first frame is no keyframe
ffmpeg :0:: Missing reference picture
ffmpeg :0:: number of reference frames exceeds max (probably corrupt input), discarding one
ffmpeg :0:: non-existing PPS referenced
ffmpeg :0:: sps_id out of range

For the first 2 message, I think it's not a problem since the first frame that client got in the stream is not keyframe/reference frame.
But for the rest, I do not know why did it happens, I tried to google but seam I can't find anything useful. Is there any one know how can I fix these or just disable them ?

Thanks
--
Cheers !

trungnt

------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gstreamer-devel
Reply | Threaded
Open this post in threaded view
|

Re: gst-rtsp-server and ffmpeg message

Arnout Vandecappelle
On Monday 12 Oct 2009 13:18:01 Thành Trung Nguyễn wrote:

> Hi,
>
> I'm working on a project that use gst-rtsp-server as the streaming server
> and got the following message on the client with h264 and mpeg4 video
> format:
>
> ffmpeg :0:: warning: first frame is no keyframe
> ffmpeg :0:: Missing reference picture
> ffmpeg :0:: number of reference frames exceeds max (probably corrupt
>  input), discarding one
> ffmpeg :0:: non-existing PPS referenced
> ffmpeg :0:: sps_id out of range

 This sounds like you're missing codec_data for your decoder.  Can you check
on your client which caps are set on the elements?  You typically have a
config string on rtph264depay's sink pad and a codec-data buffer on its src
pad.

 If your rtsp server is not sending out the codec data (e.g. because you start
in the middle of a stream), then you have a problem :-)

 Regards,
 Arnout

--
Arnout Vandecappelle                               arnout at mind be
Senior Embedded Software Architect                 +32-16-286540
Essensium/Mind                                     http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium                BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint:  D206 D44B 5155 DF98 550D  3F2A 2213 88AA A1C7 C933

------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gstreamer-devel
Reply | Threaded
Open this post in threaded view
|

Re: gst-rtsp-server and ffmpeg message

Arnout Vandecappelle
On Tuesday 13 Oct 2009 10:03:44 Thành Trung Nguyễn wrote:

> Here's what I got from gst-launch -v on rtph264depay elements:
>
> /GstPipeline:pipeline0/GstRtpH264Depay:rtph264depay0.GstPad:src: caps =
> video/x-h264
>
> /GstPipeline:pipeline0/GstRtpH264Depay:rtph264depay0.GstPad:sink: caps =
> application/x-rtp, media=(string)video, payload=(int)96,
> clock-rate=(int)90000, encoding-name=(string)H264,
> profile-level-id=(string)4d401f,
> sprop-parameter-sets=(string)\"Z01AH5JUAoAt2AiAAAADAIAAAB5HjBlQ\\,aO48gA\\=
> \\=\", a-tool=(string)GStreamer, a-type=(string)broadcast,
> clock-base=(guint)2373374152, seqnum-base=(guint)13660,
> npt-start=(guint64)0, play-speed=(double)1, play-scale=(double)1
>
> I'm not sure but I think video/x-h264 is the codec data you said, isn't it
>  ?

 The 'sprop-parameter-sets' is the config string I mentioned.  The 'video/x-
h264' should have codec data as a parameter, or it may send the codec-data as
an in-stream buffer (and now I seem to remember that's actually the default).  
But since the sprop-parameter-sets are there, the codec data will be there as
well.

 Run with --gst-debug=rtph264depay:5,ffdec:3 to get a bit (well, actually a
lot) more detail.  If that mentions that the codec_data buffer is pushed, then
something else is wrong...

 Maybe the problem is that the codec data gets discarded again because the
discontinuity that comes from the errors of your first two frames.  That is
solved by setting it as caps instead of pushing it as a buffer.  Add the
'byte-stream=false' property to rtph264depay.

 Regards,
 Arnout

 PS Please send replies to the list, other people may benefit from these
messages.

>
> 2009/10/13 Arnout Vandecappelle <[hidden email]>
>
> > On Monday 12 Oct 2009 13:18:01 Thành Trung Nguyễn wrote:
> > > Hi,
> > >
> > > I'm working on a project that use gst-rtsp-server as the streaming
> > > server and got the following message on the client with h264 and mpeg4
> > > video format:
> > >
> > > ffmpeg :0:: warning: first frame is no keyframe
> > > ffmpeg :0:: Missing reference picture
> > > ffmpeg :0:: number of reference frames exceeds max (probably corrupt
> > >  input), discarding one
> > > ffmpeg :0:: non-existing PPS referenced
> > > ffmpeg :0:: sps_id out of range
> >
> >  This sounds like you're missing codec_data for your decoder.  Can you
> > check
> > on your client which caps are set on the elements?  You typically have a
> > config string on rtph264depay's sink pad and a codec-data buffer on its
> > src pad.
> >
> >  If your rtsp server is not sending out the codec data (e.g. because you
> > start
> > in the middle of a stream), then you have a problem :-)
> >
> >  Regards,
> >  Arnout
> >
> > --
> > Arnout Vandecappelle                               arnout at mind be
> > Senior Embedded Software Architect                 +32-16-286540
> > Essensium/Mind                                     http://www.mind.be
> > G.Geenslaan 9, 3001 Leuven, Belgium                BE 872 984 063 RPR
> > Leuven
> > LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
> > GPG fingerprint:  D206 D44B 5155 DF98 550D  3F2A 2213 88AA A1C7 C933
>

--
Arnout Vandecappelle                               arnout at mind be
Senior Embedded Software Architect                 +32-16-286540
Essensium/Mind                                     http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium                BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint:  D206 D44B 5155 DF98 550D  3F2A 2213 88AA A1C7 C933

------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gstreamer-devel
Reply | Threaded
Open this post in threaded view
|

Re: gst-rtsp-server and ffmpeg message

Thành Trung Nguyễn
Here's what I got when using --gst-debug:

....
0:00:40.041460639 29100  0x91ac738 DEBUG           rtph264depay gstrtph264depay.c:560:gst_rtp_h264_depay_process:<rtph264depay0> queueing 1386 bytes
0:00:40.041587089 29100  0x91ac738 DEBUG           rtph264depay gstrtph264depay.c:404:gst_rtp_h264_depay_process:<rtph264depay0> receiving 1132 bytes
0:00:40.041702807 29100  0x91ac738 DEBUG           rtph264depay gstrtph264depay.c:421:gst_rtp_h264_depay_process:<rtph264depay0> NRI 2, Type 28
0:00:40.041814445 29100  0x91ac738 DEBUG           rtph264depay gstrtph264depay.c:519:gst_rtp_h264_depay_process:<rtph264depay0> S 0, E 1
0:00:40.041929402 29100  0x91ac738 DEBUG           rtph264depay gstrtph264depay.c:560:gst_rtp_h264_depay_process:<rtph264depay0> queueing 1130 bytes
0:00:40.042042693 29100  0x91ac738 DEBUG           rtph264depay gstrtph264depay.c:568:gst_rtp_h264_depay_process:<rtph264depay0> output 1130 bytes
0:00:40.042204307 29100  0x91ac738 DEBUG           rtph264depay gstrtph264depay.c:404:gst_rtp_h264_depay_process:<rtph264depay0> receiving 2 bytes
0:00:40.042320160 29100  0x91ac738 DEBUG           rtph264depay gstrtph264depay.c:421:gst_rtp_h264_depay_process:<rtph264depay0> NRI 0, Type 9
....

I haven't found anything like 'codec_data buffer is pushed'.

I had tried to set  caps like this:
gst-launch rtsp://localhost:8554/h264 ! rtph264depay  ! video/x-h264 ! ffdec_h264 ! ffmpegcolorspace ! autovideosink
but still got this message:
...
0:00:03.521963200 29480  0x94ef290 ERROR                 ffmpeg :0:: number of reference frames exceeds max (probably corrupt input), discarding one
...

Tried to set byte-stream=false to rtph264depay, I got this message:
0:00:03.536385694 29480  0x94ef290 ERROR                 ffmpeg :0:: no frame!

So do you know if is there anything wrong ?

2009/10/13 Arnout Vandecappelle <[hidden email]>
On Tuesday 13 Oct 2009 10:03:44 Thành Trung Nguyễn wrote:
> Here's what I got from gst-launch -v on rtph264depay elements:
>
> /GstPipeline:pipeline0/GstRtpH264Depay:rtph264depay0.GstPad:src: caps =
> video/x-h264
>
> /GstPipeline:pipeline0/GstRtpH264Depay:rtph264depay0.GstPad:sink: caps =
> application/x-rtp, media=(string)video, payload=(int)96,
> clock-rate=(int)90000, encoding-name=(string)H264,
> profile-level-id=(string)4d401f,
> sprop-parameter-sets=(string)\"Z01AH5JUAoAt2AiAAAADAIAAAB5HjBlQ\\,aO48gA\\=
> \\=\", a-tool=(string)GStreamer, a-type=(string)broadcast,
> clock-base=(guint)2373374152, seqnum-base=(guint)13660,
> npt-start=(guint64)0, play-speed=(double)1, play-scale=(double)1
>
> I'm not sure but I think video/x-h264 is the codec data you said, isn't it
>  ?

 The 'sprop-parameter-sets' is the config string I mentioned.  The 'video/x-
h264' should have codec data as a parameter, or it may send the codec-data as
an in-stream buffer (and now I seem to remember that's actually the default).
But since the sprop-parameter-sets are there, the codec data will be there as
well.

 Run with --gst-debug=rtph264depay:5,ffdec:3 to get a bit (well, actually a
lot) more detail.  If that mentions that the codec_data buffer is pushed, then
something else is wrong...

 Maybe the problem is that the codec data gets discarded again because the
discontinuity that comes from the errors of your first two frames.  That is
solved by setting it as caps instead of pushing it as a buffer.  Add the
'byte-stream=false' property to rtph264depay.

 Regards,
 Arnout

 PS Please send replies to the list, other people may benefit from these
messages.

>
> 2009/10/13 Arnout Vandecappelle <[hidden email]>
>
> > On Monday 12 Oct 2009 13:18:01 Thành Trung Nguyễn wrote:
> > > Hi,
> > >
> > > I'm working on a project that use gst-rtsp-server as the streaming
> > > server and got the following message on the client with h264 and mpeg4
> > > video format:
> > >
> > > ffmpeg :0:: warning: first frame is no keyframe
> > > ffmpeg :0:: Missing reference picture
> > > ffmpeg :0:: number of reference frames exceeds max (probably corrupt
> > >  input), discarding one
> > > ffmpeg :0:: non-existing PPS referenced
> > > ffmpeg :0:: sps_id out of range
> >
> >  This sounds like you're missing codec_data for your decoder.  Can you
> > check
> > on your client which caps are set on the elements?  You typically have a
> > config string on rtph264depay's sink pad and a codec-data buffer on its
> > src pad.
> >
> >  If your rtsp server is not sending out the codec data (e.g. because you
> > start
> > in the middle of a stream), then you have a problem :-)
> >
> >  Regards,
> >  Arnout
> >
> > --
> > Arnout Vandecappelle                               arnout at mind be
> > Senior Embedded Software Architect                 +32-16-286540
> > Essensium/Mind                                     http://www.mind.be
> > G.Geenslaan 9, 3001 Leuven, Belgium                BE 872 984 063 RPR
> > Leuven
> > LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
> > GPG fingerprint:  D206 D44B 5155 DF98 550D  3F2A 2213 88AA A1C7 C933
>

--
Arnout Vandecappelle                               arnout at mind be
Senior Embedded Software Architect                 +32-16-286540
Essensium/Mind                                     http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium                BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint:  D206 D44B 5155 DF98 550D  3F2A 2213 88AA A1C7 C933



--
Cheers !

trungnt

------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gstreamer-devel
Reply | Threaded
Open this post in threaded view
|

Re: gst-rtsp-server and ffmpeg message

Arnout Vandecappelle
On Tuesday 13 Oct 2009 11:51:42 Thành Trung Nguyễn wrote:

> Here's what I got when using --gst-debug:
>
> ....
> 0:00:40.041460639 29100  0x91ac738 DEBUG           rtph264depay
> gstrtph264depay.c:560:gst_rtp_h264_depay_process:<rtph264depay0> queueing
> 1386 bytes
> 0:00:40.041587089 29100  0x91ac738 DEBUG           rtph264depay
> gstrtph264depay.c:404:gst_rtp_h264_depay_process:<rtph264depay0> receiving
> 1132 bytes
> 0:00:40.041702807 29100  0x91ac738 DEBUG           rtph264depay
> gstrtph264depay.c:421:gst_rtp_h264_depay_process:<rtph264depay0> NRI 2,
>  Type 28
> 0:00:40.041814445 29100  0x91ac738 DEBUG           rtph264depay
> gstrtph264depay.c:519:gst_rtp_h264_depay_process:<rtph264depay0> S 0, E 1
> 0:00:40.041929402 29100  0x91ac738 DEBUG           rtph264depay
> gstrtph264depay.c:560:gst_rtp_h264_depay_process:<rtph264depay0> queueing
> 1130 bytes
> 0:00:40.042042693 29100  0x91ac738 DEBUG           rtph264depay
> gstrtph264depay.c:568:gst_rtp_h264_depay_process:<rtph264depay0> output
>  1130 bytes
> 0:00:40.042204307 29100  0x91ac738 DEBUG           rtph264depay
> gstrtph264depay.c:404:gst_rtp_h264_depay_process:<rtph264depay0> receiving
>  2 bytes
> 0:00:40.042320160 29100  0x91ac738 DEBUG           rtph264depay
> gstrtph264depay.c:421:gst_rtp_h264_depay_process:<rtph264depay0> NRI 0,
>  Type 9

 So there's nothing like 'decoding param 0 (Z01AH5JUAoAt2AiAAAADAIAAAB5HjBlQ)'
in the debug output?  That's extremely strange...

> I haven't found anything like 'codec_data buffer is pushed'.

 Yeah, looks like rtph264depay doesn't log anything for that.  You can turn on
debugging for basertpdepayload and look for two subsequent 'Pushing buffer'
messages.

> Tried to set byte-stream=false to rtph264depay, I got this message:
> 0:00:03.536385694 29480  0x94ef290 ERROR                 ffmpeg :0:: no
> frame!

 That's really strange...  No debug messages from rtph264depay?

 Regards,
 Arnout
--
Arnout Vandecappelle                               arnout at mind be
Senior Embedded Software Architect                 +32-16-286540
Essensium/Mind                                     http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium                BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint:  D206 D44B 5155 DF98 550D  3F2A 2213 88AA A1C7 C933

------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gstreamer-devel