#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 , 9 years ago
Resolution: | → invalid |
---|---|
Status: | new → closed |
comment:2 by , 9 years ago
Keywords: | start time ffmpeg removed |
---|
Note:
See TracTickets
for help on using tickets.
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.