After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 787319 - gsth264parser: buffering period parser fails
gsth264parser: buffering period parser fails
Status: RESOLVED INCOMPLETE
Product: GStreamer
Classification: Platform
Component: gst-plugins-bad
1.12.2
Other Linux
: Normal normal
: git master
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2017-09-05 16:26 UTC by Julian Bouzas
Modified: 2018-05-07 16:00 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
debug log (404.62 KB, text/plain)
2017-09-05 16:26 UTC, Julian Bouzas
Details
wireshark capture (1.50 KB, application/x-pcapng)
2017-09-12 10:01 UTC, Julian Bouzas
Details
segfault backtrace when using gdppay (19.17 KB, text/plain)
2017-09-12 10:07 UTC, Julian Bouzas
Details

Description Julian Bouzas 2017-09-05 16:26:07 UTC
Created attachment 359209 [details]
debug log

Hi,

We have an rtsp source coming from an IP camera that plays fine for a few seconds and then stops because an EOS is sent:

gst-launch-1.0 rtspsrc location=... ! rtph264depay ! decodebin ! fakesink

I have debugged the code and it looks like the h264 parser fails when parsing the SEI message if the payload type is `GST_H264_SEI_BUF_PERIOD`, here:

https://cgit.freedesktop.org/gstreamer/gst-plugins-bad/tree/gst-libs/gst/codecparsers/gsth264parser.c?h=1.12#n1152

That parsing error causes the VAAPI H264 decoder to send an EOS here:

https://cgit.freedesktop.org/gstreamer/gstreamer-vaapi/tree/gst-libs/gst/vaapi/gstvaapidecoder_h264.c?h=1.12#n1765

which is why the video plays fine only for a few seconds...

It seems to only happen when using the VAAPI plugins so I am not sure if this is a gst-plugins-bad issue or a gstreamer-vaapi issue.

If we ignore that error and always return `GST_H264_PARSER_OK` when parsing the buffering period, the video plays fine forever, but I guess this is not the proper solution.

The full log with GST_DEBUG=4 is attached, the relevant lines are:

gsth264parser.c:848:gst_h264_parser_parse_buffering_period: failed to read UE
gsth264parser.c:892:gst_h264_parser_parse_buffering_period: error parsing "Buffering period"
gsth264parse.c:530:gst_h264_parse_process_sei:<h264parse0> failed to parse one or more SEI message

Does anybody know why the parsing is failing?
Comment 1 Tim-Philipp Müller 2017-09-09 16:10:09 UTC
Maybe you could make a wireshark capture, or a stream captured with


 ... ! gdppay ! filesink location=stream.gdp

available, then we can look and check.

I don't think vaapi should be erroring out if it fails to parse an SEI?
Comment 2 Julian Bouzas 2017-09-12 10:01:20 UTC
Created attachment 359595 [details]
wireshark capture

Wireshark capture of the stream playing until the EOS is sent.
Comment 3 Julian Bouzas 2017-09-12 10:07:13 UTC
Created attachment 359596 [details]
segfault backtrace when using gdppay

Segfault backtrace when using the stream with gdppay:

gst-launch-1.0 rtspsrc location=... ! rtph264depay ! decodebin ! gdppay ! filesink location=stream.gdp
Comment 4 Julian Bouzas 2017-09-12 10:11:09 UTC
Hi Tim,

I have attached the wireshark capture of the stream playing until the EOS is sent.

I have also tried to capture the stream with gdppay but it seems to cause a segfault when trying to play the pipeline. It might be a different issue but I have attached the backtrace as well.

I will see if I can make the rtsp source public so that it is easier for you to test it.
Comment 5 Julian Bouzas 2017-09-12 16:07:31 UTC
Here is the rtsp stream in case you want to reproduce it:

rtsp://dev.vcatechnology.com:12554/media/video2

user-id: admin
user-pwd: admin

It happens with the following pipeline:

gst-launch-1.0 rtspsrc location=rtsp://dev.vcatechnology.com:12554/media/video2 user-id=admin user-pw=admin ! rtph264depay ! decodebin ! fakesink
Comment 6 Sebastian Dröge (slomo) 2018-05-07 16:00:10 UTC
The stream does not seem to be available anymore.