Don't let finalize_packet() touch pkt->stream_index. Instead, let individual
commit3e6a9e1fb04596c6c53ac23f0abfdbcb3256313a
authorrbultje <rbultje@9553f0bf-9b14-0410-a0b8-cfaf0461ba5b>
Tue, 3 Mar 2009 13:51:34 +0000 (3 13:51 +0000)
committerrbultje <rbultje@9553f0bf-9b14-0410-a0b8-cfaf0461ba5b>
Tue, 3 Mar 2009 13:51:34 +0000 (3 13:51 +0000)
tree6a4f543c0339d8f8e387520c8014e55d28db5f07
parent4ec232afe82ddca131d72336944e8d025a72f61f
Don't let finalize_packet() touch pkt->stream_index. Instead, let individual
payload handlers take care of that themselves at their own option. What this
patch really does is "fix" a bug in MS-RTSP protocol where incoming packets
are always coming in over the connection (UDP) or interleave-id (TCP) of
the stream-id of the first ASF packet in the RTP packet. However, RTP packets
may contain multiple ASF packets (and usually do, from what I can see), and
therefore this leads to playback bugs. The intended stream-id per ASF packet
is given in the respective ASF packet header. The ASF demuxer will correctly
read this and set pkt->stream_index, but since the "stream" parameter can
not be known to rtpdec.c or any of the RTP/RTSP code, the "st" parameter
in all these functions is basically invalid. Therefore, using st->id as
pkt->stream_index leads to various playback bugs. The result of this patch
is that pkt->stream_index is left untouched for RTP/ASF (and possibly for
other payloads that have similar behaviour).

The patch was discussed in the "[PATCH] rtpdec.c: don't overwrite
pkt->stream_index in finalize_packet()" thread on the mailinglist.

git-svn-id: file:///var/local/repositories/ffmpeg/trunk@17767 9553f0bf-9b14-0410-a0b8-cfaf0461ba5b
libavformat/rtp_h264.c
libavformat/rtpdec.c