aboutsummaryrefslogtreecommitdiffstats
path: root/libavcodec/h264_mp4toannexb_bsf.c
diff options
context:
space:
mode:
authorRonald S. Bultje <rsbultje@gmail.com>2009-03-03 13:51:34 +0000
committerRonald S. Bultje <rsbultje@gmail.com>2009-03-03 13:51:34 +0000
commiteafb17d140f6772c9aac8fbf31641f24a371b2c0 (patch)
tree20846edc04bef15e71e204bab43f99e2a6a3ac3a /libavcodec/h264_mp4toannexb_bsf.c
parent0d8ee24c7b7a1ed0f28b0000bda77b07d4137135 (diff)
downloadffmpeg-eafb17d140f6772c9aac8fbf31641f24a371b2c0.tar.gz
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. Originally committed as revision 17767 to svn://svn.ffmpeg.org/ffmpeg/trunk
Diffstat (limited to 'libavcodec/h264_mp4toannexb_bsf.c')
0 files changed, 0 insertions, 0 deletions