Robert Schlabbach rober...@gmx.net added the comment:
Here is a sample RTP/UDP multicast stream carrying an
MPEG-2 Transport Stream, captured with Wireshark. 60
seconds, 19753 packets, all RTP sequence numbers from
51583 through 5799 (wrapped 65535-0) should be there.
It is a capture
Robert Schlabbach rober...@gmx.net added the comment:
I wouldn't know of a direct way to play the capture in
VLC, but if you send it to the network via rtpplay,
you can receive it with VLC like this:
vlc rtp://239.35.129.11:1
Yep, rtp:// URLs work as expected in VLC, RTP is
parsed
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
New submission from Robert Schlabbach rober...@gmx.net:
The RTP parser in rtpdec.c contains a bug in
rtp_parse_packet_internal(): If ff_mpegts_parse_packet
() returns that only a part of the buffer was
processed, the remaining buffer is stored, but s-
prev_ret is _not_ set to 1.
As a result
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
Robert Schlabbach rober...@gmx.net added the comment:
Here is the SVN diff patch, tested with patcheck,
which only complained about a missing changelog entry.
But since the source file had no changelog entries at
all, I suppose that's ok
Robert Schlabbach rober...@gmx.net added the comment:
The RTP/UDP multicast source which exposed this
problem is Deutsche Telekom's IPTV service (T-Home
Entertain) in Germany. If you happen to have a
developer amongst you who has this service, you can
reproduces this problem e.g
Robert Schlabbach rober...@gmx.net added the comment:
Ok, here is a single RTP/UDP multicast packet showing
a RTP header extension of 8 32-bit words. Plus the 4
bytes of the header extension itself yields 36 bytes
to be skipped by the RTP decoder.
Wireshark does not autodetect it as RTP, so
New submission from Robert Schlabbach rober...@gmx.net:
The RTP parser in libavformat/rtpdec.c, in the
function rtp_parse_packet_internal() does not check
the RTP header extension bit and neglects to skip
header extensions according to RFC 3550 chapter 5.3.1.
This results e.g. in MPEG-2
11 matches
Mail list logo
