Opened 5 years ago

Closed 5 years ago

Last modified 5 years ago

#16 closed defect (fixed)

"non-monotonically increasing dts" because of corrupt rtptime

Reported by: il--ya Owned by: michael
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)

rtsp.c.patch (1.5 KB) - added by il--ya 5 years ago.
patch

Download all attachments as: .zip

Change History (5)

Changed 5 years ago by il--ya

patch

comment:1 Changed 5 years ago by michael

  • 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 Changed 5 years ago by cehoyos

  • Resolution set to fixed
  • Status changed from new to 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 Changed 5 years ago by il--ya

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.

Version 0, edited 5 years ago by il--ya (next)

comment:4 Changed 5 years ago by renyaotom

this ticket is resolved by the newest version of libav.

i test just now.

Note: See TracTickets for help on using tickets.