[FFmpeg-trac] #4264(undetermined:new): ffmpeg supposedly hangs if RTSP session id contains $ or +

FFmpeg trac at avcodec.org
Thu Jan 15 20:48:52 CET 2015


#4264: ffmpeg supposedly hangs if RTSP session id contains $ or +
-------------------------------------+-------------------------------------
             Reporter:  sebras       |                     Type:  defect
               Status:  new          |                 Priority:  normal
            Component:               |                  Version:
  undetermined                       |  unspecified
             Keywords:               |               Blocked By:
             Blocking:               |  Reproduced by developer:  0
Analyzed by developer:  0            |
-------------------------------------+-------------------------------------
 Summary of the bug:

 GStreamer got a [https://bugzilla.gnome.org/show_bug.cgi?id=643812 bug
 report]  a while back where christian mentioned that ffmpeg hangs when
 RTSP session ids in gst-rtsp-server contain $ or +

 Now, [https://tools.ietf.org/html/rfc2326#page-16 RFC 2326] actually does
 not state that characters can or should be URI-escaped in a session id,
 only that linear whitespace should be. However whitespace is not among the
 allowed characters in a session id, and neither is % which would be the
 result of URI-escaping.

 Therefore GStreamer recently accepted a
 [https://bugzilla.gnome.org/show_bug.cgi?id=742869 patch] to refrain from
 URI-escaping the session id in the RTSP session header. Instead the
 argument is that ffmpeg should not hang if it encounters $ or + in the
 header. While I have not reproduced this myself I'm CCing christian who
 reported it. Finally I did quickly look at the RTSP header parsing code in
 ffmpeg and I fail to find any code that actually cares about the session
 id's constituing characters.

 Perhaps the problem with $ is that the session id is mixed up with the $
 used to separate multiple channels multiplexed over the same RTSP TCP
 connection? I'm far from certain about this, but at least it is part of
 the parsing and uses the same character as delimiter.

 christian if you can still reproduce this, please chime in here and help
 out in getting a better fix for this problem.

--
Ticket URL: <https://trac.ffmpeg.org/ticket/4264>
FFmpeg <https://ffmpeg.org>
FFmpeg issue tracker


More information about the FFmpeg-trac mailing list