[Bug 695248] ffdec_h264 crash probably due to packet corruption.

GStreamer (bugzilla.gnome.org) bugzilla at gnome.org
Tue Mar 5 18:12:13 PST 2013


https://bugzilla.gnome.org/show_bug.cgi?id=695248
  GStreamer | gst-libav | 0.10.36

--- Comment #1 from gtoonstra at gmail.com 2013-03-06 02:12:02 UTC ---
I've done some further investigation into the issue, but this time using a
simulation environment with a direct ethernet cable connection between a linux
desktop and the mac. The source is a desktop grab on Ubuntu Linux, which
encodes in H.264 and transmits using a udpsink on the same UDP multicast
IP/port as the real application. This eliminates interference potentially
caused by wifi interference, etc.

I found that it's caused by the gstrtpjitterbuffer options I was using. The
complete invocation I was using in the application is like this one in
gst-launcher:

./gst-launch-0.10 -vvv udpsrc multicast-group=239.255.12.12 port=5004
auto-multicast=true
caps="application/x-rtp,media=(string)video,clock-rate=(int)90000,encoding-name=(string)H264,payload=(int)96"
! gstrtpjitterbuffer latency=60 drop-on-latency=true ! rtph264depay !
"video/x-h264, stream-format=(string)byte-stream, alignment=(string)nal" !
h264parse ! ffdec_h264 ! ffmpegcolorspace ! osxvideosink sync=false

I've found that setting 'drop-on-latency' to false makes the problems go away.
It has now been running over 15 minutes without problems. Apparently in
specific situations where a particular frame was dropped, the decoder didn't
handle this gracefully.

-- 
Configure bugmail: https://bugzilla.gnome.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
You are the assignee for the bug.


More information about the gstreamer-bugs mailing list