[Bug 757118] rtspconnection: Problem when parsing vendor specific RTSP response with data after Content-Length

GStreamer (GNOME Bugzilla) bugzilla at gnome.org
Tue Oct 27 23:03:49 PDT 2015


https://bugzilla.gnome.org/show_bug.cgi?id=757118

--- Comment #4 from Davy <realbrightster at gmail.com> ---
headache..

Absolutely, this packet breaks standard.
This is consist of two packets according to standard
and the second packet is neither request nor response -> error case.

0000   52 54 53 50 2f 31 2e 30 20 32 30 30 20 4f 4b 0d  RTSP/1.0 200 OK.
0010   0a 43 53 65 71 3a 20 37 0d 0a 43 6f 6e 74 65 6e  .CSeq: 7..Conten
0020   74 2d 4c 65 6e 67 74 68 3a 20 30 0d 0a 43 6f 6e  t-Length: 0..Con
0030   74 65 6e 74 2d 54 79 70 65 3a 20 74 65 78 74 2f  tent-Type: text/
0040   70 61 72 61 6d 65 74 65 72 73 0d 0a 53 65 73 73  parameters..Sess
0050   69 6f 6e 3a 20 31 33 38 36 31 34 38 33 33 0d 0a  ion: 138614833..
0060   0d 0a 66 72 61 6d 65 72 61 74 65 3a 20 33 30 0d  ..framerate: 30.
0070   0a                                               .

Now we need to decide whether ignoring error(keep playback) or breaking the
pipeline.
I also checked how live555 handling it and the result was
They keep playing RTSP stream and send "405 Method Not Allowed"
- actually they have also parsing problem, but playback never stop.

In my opinion, gstreamer also able to play this stream.

1. reset state

If recv timeout occurred but still not found ending characters(\r\n\r\n,
\r\n\n, r\r...), reset state to initial.
Let build_next ignore it. (ETIMEOUT)

2. timeout case..
In this situation (RTSP message doesn't contain ending characters),
We have to wait until recv timeout which configured by upper layer (ex.
rtspsrc) or RTSP response (timeout=)
If timeout is large, we waste time and subsequent request may be pended. 

Typically, RTSP response packed in one TCP packet so that socket buffer will
store all response characters.  it's very high possibility.

So if we check remaining bytes in socket ahead of read, waiting time will be
reduced.

and some ambiguous stuff..
- GST_RTSP_EPARSE handling
Dose GST_RTSP_EPARSE is critical error for RTSP *CLIENT*?
Now it's handled as receive_error so it stop playback.

-- 
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