GNOME Bugzilla – Bug 782333
rtph264depay: Generates broken SPS packets including other packets
Last modified: 2017-05-22 17:32:18 UTC
Hello, I am dealing with some problems in h264parse related to memory allocation. After some debugging it seems that the problem is related to the video processed, which makes the parser to detect a huge SPS size (even it is out of gint range). I have logged out this values and in a execution I obtained: gsth264parse.c:1309:gst_h264_parse_make_codec_data: sps_size: 3330, pps_size: 18 gsth264parse.c:1309:gst_h264_parse_make_codec_data: sps_size: 7415, pps_size: 25 gsth264parse.c:1309:gst_h264_parse_make_codec_data: sps_size: 15600, pps_size: 32 gsth264parse.c:1309:gst_h264_parse_make_codec_data: sps_size: 31838, pps_size: 39 gsth264parse.c:1309:gst_h264_parse_make_codec_data: sps_size: 64464, pps_size: 46 gsth264parse.c:1309:gst_h264_parse_make_codec_data: sps_size: 129648, pps_size: 53 gsth264parse.c:1309:gst_h264_parse_make_codec_data: sps_size: 260112, pps_size: 60 gsth264parse.c:1309:gst_h264_parse_make_codec_data: sps_size: 521007, pps_size: 67 gsth264parse.c:1309:gst_h264_parse_make_codec_data: sps_size: 1042730, pps_size: 74 gsth264parse.c:1309:gst_h264_parse_make_codec_data: sps_size: 2086173, pps_size: 81 gsth264parse.c:1309:gst_h264_parse_make_codec_data: sps_size: 4173145, pps_size: 88 gsth264parse.c:1309:gst_h264_parse_make_codec_data: sps_size: 8347119, pps_size: 95 gsth264parse.c:1309:gst_h264_parse_make_codec_data: sps_size: 16694956, pps_size: 102 gsth264parse.c:1309:gst_h264_parse_make_codec_data: sps_size: 33390795, pps_size: 110 gsth264parse.c:1309:gst_h264_parse_make_codec_data: sps_size: 66782412, pps_size: 118 gsth264parse.c:1309:gst_h264_parse_make_codec_data: sps_size: 133565776, pps_size: 126 gsth264parse.c:1309:gst_h264_parse_make_codec_data: sps_size: 267132453, pps_size: 134 gsth264parse.c:1309:gst_h264_parse_make_codec_data: sps_size: 534265844, pps_size: 142 gsth264parse.c:1309:gst_h264_parse_make_codec_data: sps_size: 1068532668, pps_size: 150 gsth264parse.c:1309:gst_h264_parse_make_codec_data: sps_size: 2137066380, pps_size: 158 gsth264parse.c:1309:gst_h264_parse_make_codec_data: sps_size: -20833577, pps_size: 166 We can also see the memory error detected with GDB: GLib-ERROR **: /build/glib2.0-prJhLS/glib2.0-2.48.2/./glib/gmem.c:100: failed to allocate 18446744073106744596 bytes Thread 37 "queue2:src" received signal SIGTRAP, Trace/breakpoint trap.
+ Trace 237431
Thread 140734980146944 (LWP 30813)
can you provide a sample stream that causes this? Also no need to always CC me in your bug reports. If anything it makes it less likely that I'm going to take a look ;)
Sorry, I though that it was interested for you. I won't do it again ;). The streams is received from RTP, but I will try to get it if this can help to fix the bug.
(In reply to Miguel París Díaz from comment #2) > Sorry, I though that it was interested for you. I won't do it again ;). It is, but I get mails about every new bug report and any changes to existing ones anyway. For RTP, you can create a pcap capture for example and then use pcapparse. Or GDP.
Thanks for your suggestion I was able to generate a GDP file [1] that can be used to reproduce the problem just using gst-launch in the next way: gst-launch -v -m filesrc location=h264.gdp ! gdpdepay ! h264parse ! fakesink After few seconds the next error is logged out and the process is core dumped: GLib-ERROR **: /build/glib2.0-prJhLS/glib2.0-2.48.2/./glib/gmem.c:100: failed to allocate 18446744071568623010 bytes Refs [1] https://www.dropbox.com/s/snam0v634ycnu2n/h264.gdp?dl=0
Yes I can confirm. A smaller file would've been nicer, but ok :)
You are right, I was also surprised about the huge size of the file because the video duration is only few seconds. So, I suppose that this should be related to the bug and that the "remote encoder" should do something that makes GStreamer pipeline to crash, what can be considered a security problem. What do you think?
Where does the stream come from btw, it's definitely broken :) The NAL sizes are indeed huge for the SPS, and each new SPS seems to be twice as big. We should just error out on that at some point.
Note that we also keep every SPS around as they all have different IDs, they are not cleaned up at any point because they might still be used in the future. So a proper fix should probably also consider that. However for the SPS, we should just set a reasonable size limit. It can't be infinitely large. Not sure what number is a good maximum though.
The stream comes from Chrome. I totally agree with you, it seems a the behavior of Chrome is not correct and we should protect ourself detecting this case and returning an error instead of crashing. What I do not know is which would be a reasonable limit :S. Do you have some suggestion or can we ask somebody familiar with H.264?
Can you also provide a GDP stream from before the rtph264depay? The RTP packets. Maybe rtph264depay breaks the stream.
These big "SPS" packets actually contain a full PPS and IDR embedded afterward. It could be rtph264depay doing something dumb - if it were actually in the stream I'd expect it to just chew up all bandwidth and completely fail to play after a short time.
Hello again, I have created a GDP file [1] with RTP packets (just before the depayloader) as Sebastian requested. This GDP file is 266KB, while the related GDP file after the depayloader is 7.7GB. In order to reproduce the problem you can run the next pipeline: gst-launch -v -m filesrc location=gdp-rtp-h264-depay_in-001.out ! gdpdepay ! rtph264depay ! h264parse ! fakesink After a while the next error is logged out and the process is core dumped: GLib-ERROR **: /build/glib2.0-prJhLS/glib2.0-2.48.2/./glib/gmem.c:100: failed to allocate 18446744073543753205 bytes Refs [1] https://www.dropbox.com/s/dfsx6wlwbvyf70w/gdp-rtp-h264-depay_in-001.out?dl=0
Clearly rtph264depay then, thanks :)
I have seen senders that send multiple NALs (with bytestream sync markers) as one NAL rtp chunk fwiw, so worth checking if that's what's happening here.
That 2nd dropbox link isn't generally accessible
Sorry Jan, I did not realize it. I have just updated the permissions, please try again ;).
I can reproduce the bug with 1.8, but not with 1.10 or git master. Seems to have been fixed in rtph264depay since then, probably by commit 7025d014bbec126d2e583f6a71ec3149797eb345 Author: Olivier Crête <olivier.crete@collabora.com> Date: Tue Sep 27 15:26:19 2016 -0400 rtph26[45]depay: Don't handle NALs inside STAP units twice They've already been handled before pushing them into the adapter.
Great!! I will check several times again with this patch and will close this issue if I cannot reproduce it. Thank you :D.
Fixed by commit commented by Jan. Thanks!!
You should really consider updating your GStreamer version though :)
Sure, it seems that there are a lot of bugfixes :D.