#16 closed defect (fixed)
"non-monotonically increasing dts" because of corrupt rtptime
| Reported by: | Ilya I | Owned by: | Michael Niedermayer |
|---|---|---|---|
| Priority: | important | Component: | ffmpeg |
| Version: | git | Keywords: | |
| Cc: | Blocked By: | ||
| Blocking: | Reproduced by developer: | no | |
| Analyzed by developer: | yes |
Description
I'm using ffmpeg-r26400-swscale-r32676.
I've found a bug in libavformat/rtsp.c, function rtsp_parse_rtp_info(): rtptime and seq values from RTSP interpreted as signed long, strtol() function is used to read these values. Problem is that these values are unsigned, and when >0x7fffffff, strtol() returns wrong value. This causes various errors (mainly "non monotonically incresing dts" complaint).
unsigned version strtoul() should be used to read these values. Patch attached
Attachments (1)
Change History (5)
by , 14 years ago
| Attachment: | rtsp.c.patch added |
|---|
comment:1 by , 14 years ago
| Analyzed by developer: | set |
|---|
Patch looks good to me
i wonder if 32bit is actually enough, is the rfc saying somewhere how many bits one needs?
comment:2 by , 14 years ago
| Resolution: | → fixed |
|---|---|
| Status: | new → closed |
Patch applied, thank you!
I did not find any reference to 32 or 64bit or the needed range for seq and rtptime in rfc 2326.
comment:3 by , 14 years ago
According to rfc 1889, RTP timestamps are 32 bit long. It's not clear from RFC text, whether it should be signed or unsigned, but according to implementation example in Annex A, it is defined as 32-bit unsigned int.
u_int32 ts; /* timestamp */
Rtptime field in rtsp represent initial value of RTP timestamp, so it should be 32 bit unsigned value too.
comment:4 by , 13 years ago
this ticket is resolved by the newest version of libav.
i test just now.
patch