#16(FFmpeg:new): "non-monotonically increasing dts" because of corrupt rtptime
#16: "non-monotonically increasing dts" because of corrupt rtptime ------------------------+--------------------- Reporter: il--ya | Owner: michael Type: defect | Status: new Priority: important | Component: FFmpeg Version: git | Keywords: Blocked By: | Blocking: Reproduced: 0 | Analyzed: 0 ------------------------+--------------------- 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 -- Ticket URL: <https://ffmpeg.org/trac/ffmpeg/ticket/16> FFmpeg <http://ffmpeg.org> FFmpeg issue tracker
#16: "non-monotonically increasing dts" because of corrupt rtptime ----------------------+---------------------- Reporter: il--ya | Owner: michael Type: defect | Status: new Priority: important | Component: FFmpeg Version: git | Resolution: Keywords: | Blocked By: Blocking: | Reproduced: 0 Analyzed: 1 | ----------------------+---------------------- Changes (by michael): * analyzed: 0 => 1 Comment: Patch looks good to me i wonder if 32bit is actually enough, is the rfc saying somewhere how many bits one needs? -- Ticket URL: <http://avcodec.org/trac/ffmpeg/ticket/16#comment:1> FFmpeg <http://ffmpeg.org> FFmpeg issue tracker
#16: "non-monotonically increasing dts" because of corrupt rtptime ----------------------+---------------------- Reporter: il--ya | Owner: michael Type: defect | Status: closed Priority: important | Component: FFmpeg Version: git | Resolution: fixed Keywords: | Blocked By: Blocking: | Reproduced: 0 Analyzed: 1 | ----------------------+---------------------- Changes (by cehoyos): * status: new => closed * resolution: => fixed Comment: 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. -- Ticket URL: <http://avcodec.org/trac/ffmpeg/ticket/16#comment:2> FFmpeg <http://ffmpeg.org> FFmpeg issue tracker
#16: "non-monotonically increasing dts" because of corrupt rtptime ----------------------+---------------------- Reporter: il--ya | Owner: michael Type: defect | Status: closed Priority: important | Component: FFmpeg Version: git | Resolution: fixed Keywords: | Blocked By: Blocking: | Reproduced: 0 Analyzed: 1 | ----------------------+---------------------- Comment (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. -- Ticket URL: <http://avcodec.org/trac/ffmpeg/ticket/16#comment:3> FFmpeg <http://ffmpeg.org> FFmpeg issue tracker
#16: "non-monotonically increasing dts" because of corrupt rtptime -----------------------------------+----------------------------------- Reporter: il--ya | Owner: michael Type: defect | Status: closed Priority: important | Component: FFmpeg Version: git | Resolution: fixed Keywords: | Blocked By: Blocking: | Reproduced by developer: 0 Analyzed by developer: 1 | -----------------------------------+----------------------------------- Comment (by renyaotom): this ticket is resolved by the newest version of libav. i test just now. -- Ticket URL: <http://ffmpeg.org/trac/ffmpeg/ticket/16#comment:4> FFmpeg <http://ffmpeg.org> FFmpeg issue tracker
participants (1)
-
FFmpeg