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 |
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 |
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 |
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]>
-- 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 |
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 |
Free forum by Nabble | Edit this page |