Opened 8 years ago

Closed 8 years ago

Last modified 8 years ago

#5263 closed defect (invalid)

Negative start times with segment recording rtsp stream

Reported by: Pete Owned by:
Priority: normal Component: undetermined
Version: unspecified Keywords: segment
Cc: Blocked By:
Blocking: Reproduced by developer: no
Analyzed by developer: no

Description

Summary of the bug:
How to reproduce:

ffmpeg -i "rtsp://192.168.1.10:554/channel=1&stream=0.sdp" -vcodec copy -r 10 -acodec aac -f segment -segment_time 900 -segment_atclocktime 1 -reset_timestamps 1 -strftime 1 "/var/www/html/%y/%m/%d/cam1_%H%M%S.mp4"

Output of ffprobe for recorded files:
cam1_191637.mp4, Duration: 00:13:17.31, start: 0.000000, bitrate: 651 kb/s (beginning of recording)
-cut-
cam1_213000.mp4, Duration: 00:14:59.97, start: 0.000000, bitrate: 647 kb/s
cam1_214500.mp4, Duration: 00:14:59.97, start: 0.000000, bitrate: 649 kb/s
cam1_220000.mp4, Duration: 00:14:59.94, start: 0.000000, bitrate: 649 kb/s
cam1_221504.mp4, Duration: 00:14:59.97, start: -4.324000, bitrate: 649 kb/s
cam1_223004.mp4, Duration: 00:14:59.97, start: -4.356000, bitrate: 652 kb/s
cam1_224504.mp4, Duration: 00:14:59.97, start: -4.388000, bitrate: 653 kb/s
cam1_230004.mp4, Duration: 00:14:59.97, start: -4.420000, bitrate: 653 kb/s
cam1_231504.mp4, Duration: 00:14:59.97, start: -4.452000, bitrate: 654 kb/s
cam1_233004.mp4, Duration: 00:14:59.97, start: -4.484000, bitrate: 654 kb/s
-cut- (2 days later after continuous recording)
cam1_101503.mp4, Duration: 00:14:59.97, start: -174.188000, bitrate: 660 kb/s

(restart recording)

cam1_105648.mp4, Duration: 00:03:12.26, start: 0.000000, bitrate: 661 kb/s

ffmpeg version N-78596-g8fdee3e Copyright (c) 2000-2016 the FFmpeg developers
built with gcc 4.8 (Ubuntu 4.8.4-2ubuntu1~14.04)
configuration: --enable-gpl --enable-nonfree

Result:
Files when played through web server do not start for the period of seconds indicated 
by ffprobe 'start' output. So last file listed above waits for 174 seconds before it 
starts to play. Video that is recorded has accurate time displayed in it and I can 
see that recording does actually start at the time indicated by the file name, but 
the negative start value which must be written into the mp4 file causes the player 
to wait for that time before it starts playing. The effect seems to take several hours
 of recording to become apparent, once its started to produce incorrect start times 
the start time gradually becomes more negative with occasional large jumps.

I'm currently running a recording with verbose logs turned on so hope to catch ffmpegs
 output showing pts, pts_time, dts and dts_time when it starts to fail and will 
update with that once I get it. Currently the start times on the files its recorded 
are showing 0 though so it might not be for a few hours.

The code's a bit complex for me to get my head round but I do see that some rounding 
seems to be going on which might be responsible for this, maybe I am asking too much 
to record continuously for days. But I thought it was worth mentioning in case it 
is an actual bug.

Patches should be submitted to the ffmpeg-devel mailing list and not this bug tracker.

Change History (2)

comment:1 by Pete, 8 years ago

Resolution: invalid
Status: newclosed

After more investigation I found that the input streams were diverging, so this is probably not a bug, theres probably a option to reset the differences between the streams. So closing it as invalid.

comment:2 by Carl Eugen Hoyos, 8 years ago

Keywords: start time ffmpeg removed
Note: See TracTickets for help on using tickets.