Closed GoogleCodeExporter closed 9 years ago
That appears to be an ffmpeg problem. have you asked them what the issue could
be internally?
Original comment by david.g.hoyt
on 7 Oct 2010 at 8:44
actually, setting show-preroll-frame=false on the video sink seemed to do away
with it. ffplay showed the video correctly right away, but kinda stuttered
after that. i'm using:
rtsp://s-0-1.sg.softspb.com:554/test/test.mp4
Original comment by david.g.hoyt
on 7 Oct 2010 at 8:50
This is completely normal is your server doesn't sink on keyframes like
multifdsink does with sync-method={1,2}.
Original comment by ylatuya
on 7 Oct 2010 at 8:53
A parser in front of the decoder will help for that as it will drop the first
buffers until you get a keyframe
Original comment by ylatuya
on 7 Oct 2010 at 8:54
I get the same issue with this pipeline too
gst-launch rtspsrc location=... ! rtpmp4vdepay ! mpeg4videoparse ! ffdec_mpeg4
! ffmpegcolorspace ! *sink show-preroll-frame=false
Original comment by drakkan1...@gmail.com
on 7 Oct 2010 at 9:09
I don't know whether this parser sync on keyframes or not, but this very usual
in video streaming. Almost all the codecs works in the same way, you have a
groups of pictures starting from a keyframe and to decode them you need to have
the keyframe. In streaming, if your server doesn't sink on keyframes, in the
first conection you might be starting after the keyframe and all the frame in
this group of pictures until the next keyframe won't be decodable. For example,
to solve this, multifdsink offers a sync mode that starts streaming from the
last or next keyframe. I don't know how the rtsp works and if it's possible to
sync on keyframes, but this is not a gstreamer error
Original comment by ylatuya
on 7 Oct 2010 at 9:22
ylatuya, I know this is normal when I start to see a video, but I think this is
not normal if I have this while I'm seeing the stream, after the first sync.
Infact I don't have this connecting to the same stream using vlc on windows or
gstreamer on linux
Original comment by drakkan1...@gmail.com
on 7 Oct 2010 at 9:41
If it's in the middle of the stream that's not normal :/ I was only paying
attention at the message :P
"warning first frame is no keyframe"
If you feel it's gstreamer bug, open a bug upstream please
Original comment by ylatuya
on 7 Oct 2010 at 9:45
I don't think this is a gstreamer bug, on linux work with no issue, please look
at this pipeline:
gst-launch.exe rtspsrc
location=rtsp://root:pass@192.168.2.127/mpeg4/1/media.amp latency=100 !
rtpmp4vdepay ! mpeg4videoparse ! ffdec_mpeg4 ! ffmpegcolorspace !
directdrawsink sync=false
and here is the output:
Setting pipeline to PAUSED ...
Pipeline is live and does not need PREROLL ...
Setting pipeline to PLAYING ...
New clock: GstSystemClock
0:00:12.828125000 3488 00BF8D60 ERROR ffmpeg .:0:: warning: f
irst frame is no keyframe
0:00:13.406250000 3488 00BF8D60 ERROR ffmpeg .:0:: warning: f
irst frame is no keyframe
0:00:15.812500000 3488 00BF8D60 ERROR ffmpeg .:0:: warning: f
irst frame is no keyframe
0:00:37.843750000 3488 00BF8D60 ERROR ffmpeg .:0:: warning: f
irst frame is no keyframe
0:00:45.968750000 3488 00BF8D60 ERROR ffmpeg .:0:: warning: f
irst frame is no keyframe
0:00:53.171875000 3488 00BF8D60 ERROR ffmpeg .:0:: warning: f
irst frame is no keyframe
0:00:58.562500000 3488 00BF8D60 ERROR ffmpeg .:0:: warning: f
irst frame is no keyframe
0:01:17.921875000 3488 00BF8D60 ERROR ffmpeg .:0:: slice end
not reached but screenspace end (10327 left 7EF86E, score= -41180)
0:01:17.937500000 3488 00BF8D60 ERROR ffmpeg .:0:: header dam
aged
0:01:39.281250000 3488 00BF8D60 ERROR ffmpeg .:0:: slice end
not reached but screenspace end (46599 left 7FE6A1, score= -52723)
0:01:39.296875000 3488 00BF8D60 ERROR ffmpeg .:0:: header dam
aged
0:02:03.328125000 3488 00BF8D60 ERROR ffmpeg .:0:: warning: f
irst frame is no keyframe
0:02:26.921875000 3488 00BF8D60 ERROR ffmpeg .:0:: slice end
not reached but screenspace end (92423 left 7F73DA, score= -78252)
0:02:26.937500000 3488 00BF8D60 ERROR ffmpeg .:0:: header dam
aged
0:02:50.484375000 3488 00BF8D60 ERROR ffmpeg .:0:: slice end
not reached but screenspace end (104889 left 7E96C4, score= -91201)
0:02:50.500000000 3488 00BF8D60 ERROR ffmpeg .:0:: header dam
aged
0:02:55.171875000 3488 00BF8D60 ERROR ffmpeg .:0:: warning: f
irst frame is no keyframe
plese look at the times to see the frequence of the error, is there something
wrong in my pipeline? Please note that I can reproduce the error connecting to
the mpeg4 rtsp stream generated from 2 different cameras?
Original comment by drakkan1...@gmail.com
on 7 Oct 2010 at 4:13
please note that I cannot reproduce the issue with the stable 0.10.6 release
using the same pipeline
Original comment by drakkan1...@gmail.com
on 7 Oct 2010 at 4:29
Looks like a regression. I'm not sure if it's our bad or GStreamer's
Original comment by ylatuya
on 8 Oct 2010 at 10:06
same issue with revision 889
Original comment by drakkan1...@gmail.com
on 11 Oct 2010 at 7:27
I think this commit upstream should fix it:
https://bugzilla.gnome.org/show_bug.cgi?id=631996
Original comment by ylatuya
on 13 Oct 2010 at 11:23
Latest sync w/ git includes this fix: r896.
Original comment by david.g.hoyt
on 13 Oct 2010 at 6:50
I talked directly with drakkan1000 on irc and he conformed me the issue is
fixed but I didn't update the issue state.
http://cgit.freedesktop.org/gstreamer/gst-plugins-good/commit/?id=9f8b56b9742d86
5c2dc59f5e505a8d1871c2d507
Original comment by ylatuya
on 13 Oct 2010 at 10:10
I still have this issue
Original comment by drakkan1...@gmail.com
on 18 Oct 2010 at 9:09
I supect this problem is something related to a specific ffmpeg version, can
ossbuild use the same ffmpeg version as vlc (that works fine with the same
streams)?
Original comment by drakkan1...@gmail.com
on 18 Oct 2010 at 1:50
We probably use a more up-to-date version of ffmpeg. If it's an issue w/
ffmpeg, then you'll (we as well) need to speak w/ those developers to figure
out what the cause is and what the solution should be.
Original comment by david.g.hoyt
on 18 Oct 2010 at 4:11
the problem seems related to rtspsrc/rtmp4vdepay, the same stream served as
http (souphttpsrc) play fine for hours
Original comment by drakkan1...@gmail.com
on 26 Oct 2010 at 11:01
Original issue reported on code.google.com by
drakkan1...@gmail.com
on 7 Oct 2010 at 8:28Attachments: