Martin Storsjö mar...@martin.st added the comment:
FWIW, a demuxer that handles receiving raw rtp:// URLs without having a
local SDP description was committed in SVN rev 25527.
--
substatus: wont_implement - implemented
FFmpeg issue
Martin Storsjö mar...@martin.st added the comment:
Hi,
Thanks for locating the bug, I'll have a look at it shortly.
As for this issue, there is no duplication between rtpproto and rtpdec, both
of them are used in the full setup, at different levels.
rtpproto is the main handler of rtp://
New submission from Robert Schlabbach rober...@gmx.net:
It appears that when using an RTP input URL, the input
is _not_ passed through the RTP parser, but instead
the raw packets still containing the (unparsed) RTP
header are directly passed to the contained protocol
handler, such as mpegts.
Robert Schlabbach rober...@gmx.net added the comment:
Ok, I've figured out the data path now:
libavformat/mpegts.c - read_packet()
- libavformat/aviobuf.c - get_buffer()
- libavformat/aviobuf.c - fill_buffer()
- libavformat/avio.c - url_read()
- libavformat/rtpproto.c -
Robert Schlabbach rober...@gmx.net added the comment:
Further investigation reveals that the RTP parser in
rtpdec.c is invoked from rtsp.c and apparently through
playing SDP files. So I created a simple SDP file for
the same RTP/UDP multicast stream as in the first
message above:
v=0
c=IN
Robert Schlabbach rober...@gmx.net added the comment:
Update: I've located the bug in rtpdec.c which broke
RTP/UDP multicast streaming via SDP files, and
submitted a patch under issue #2280.
I'll leave this issue to its original purpose, which
is what to do about the rtp:// URL protocol
