GNOME Bugzilla – Bug 695248
ffdec_h264 crash probably due to packet corruption.
Last modified: 2015-02-24 12:57:49 UTC
I'm running a udpsrc multicast pipeline from a wifi connection. The source is a mobile platform with IP camera that emits a H.264 encoded 720p video stream. The stream behaves when there's a very good reception, but every once in a while crashes the application. I believe this is caused by the reception of corrupted data frames. I'm logging this with gstreamer in the hope that it will make the decoder more robust. Process: FPV [24114] Path: /Users/USER/Desktop/FPV.app/Contents/MacOS/./FPV Identifier: org.radialmind.FPV Version: 1.0 (1) Code Type: X86-64 (Native) Parent Process: bash [24103] User ID: 501 Date/Time: 2013-03-04 10:17:15.841 -0300 OS Version: Mac OS X 10.8.2 (12C60) Report Version: 10 Crashed Thread: 9 Exception Type: EXC_BAD_ACCESS (SIGSEGV) Exception Codes: KERN_INVALID_ADDRESS at 0x00007eec92eb2398 VM Regions Near 0x7eec92eb2398: CG backing stores 00000001c6270000-00000001c6617000 [ 3740K] rw-/rw- SM=SHM --> MALLOC_TINY 00007ff7c2400000-00007ff7c2500000 [ 1024K] rw-/rwx SM=COW Thread 9 Crashed: 0 libgstffmpeg.so 0x00000001151de694 MPV_frame_start + 548 1 libgstffmpeg.so 0x00000001150ada3b ff_h264_frame_start + 27 2 libgstffmpeg.so 0x00000001150aedb1 decode_slice_header + 4529 3 libgstffmpeg.so 0x00000001150b16e1 decode_nal_units + 2513 4 libgstffmpeg.so 0x00000001150b1ac0 decode_frame + 112 5 libgstffmpeg.so 0x000000011527d1e0 avcodec_decode_video2 + 176 6 libgstffmpeg.so 0x0000000114e99b37 gst_ffmpegdec_frame + 1687 7 libgstffmpeg.so 0x0000000114e97fe1 gst_ffmpegdec_chain + 2785 8 libgstreamer-0.10.0.dylib 0x000000011093e09b gst_pad_push + 459 9 libgstbase-0.10.0.dylib 0x00000001108d0e23 gst_base_transform_chain + 339 10 libgstreamer-0.10.0.dylib 0x000000011093e09b gst_pad_push + 459 11 libgstcoreelements.so 0x0000000114de9f52 gst_queue_loop + 1730 12 libgstreamer-0.10.0.dylib 0x00000001109672b8 gst_task_func + 488 13 libglib-2.0.0.dylib 0x00000001103a7e17 g_thread_pool_thread_proxy + 199 14 libglib-2.0.0.dylib 0x00000001103a712a g_thread_proxy + 90 15 libsystem_c.dylib 0x00007fff8c368742 _pthread_start + 327 16 libsystem_c.dylib 0x00007fff8c355181 thread_start + 13 I do have a couple of files where this occurred, but these are not playable as H.264 requires the EOS event to finish gracefully. Those have not been written to these files. If these *are* deemed helpful for replication, let me know and I'll supply these somewhere.
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.
Could you capture such a stream that crashes the decoder, perhaps with ... ! tee name=t t. ! queue ! gdppay ! filesink location=capture.gdp t. ! queue ! rtph264depay ! ... or wireshark or so? Or re-test with GStreamer 1.x, ideally git master (which includes a much newer version of libav where this might be fixed already).
gtoonstra ? Can you answer tim's question ?
Hi Edward, I've attempted today to recreate the issue but have not been successful. The software used for decoding is the same version as used before (2012-11 version on Mac OSX). However some changes have occurred on the machine and the actual decoding pipeline has been updated since. With the IP cam this issue was easier to reproduce, but that IP cam died in the test on 5th of March due to other issues. So unfortunately I don't have any video stream that can be used to analyze this further.
Closing this bug report as no further information has been provided. Please feel free to reopen this bug report if you can provide the information that was asked for in a previous comment. Thanks!