[FFmpeg-trac] #910(avformat:closed): Segmented encode gives increasing time clips

FFmpeg trac at avcodec.org
Sat Jan 14 00:49:03 CET 2012


#910: Segmented encode gives increasing time clips
-------------------------------------+-------------------------------------
             Reporter:  stljdpwl     |                    Owner:
                 Type:  defect       |                   Status:  closed
             Priority:  normal       |                Component:  avformat
              Version:  0.9.1        |               Resolution:  invalid
             Keywords:  segmenting   |               Blocked By:
  DirectShow                         |  Reproduced by developer:  0
             Blocking:               |
Analyzed by developer:  1            |
-------------------------------------+-------------------------------------
Changes (by saste):

 * analyzed:  0 => 1
 * status:  open => closed
 * resolution:   => invalid


Comment:

 Replying to [ticket:910 stljdpwl]:
 > Encoding a video from DirectShow (windows 7) segmented in 10 sec chunks,
 the first clip is 10 seconds long, the second 20 seconds long (only last
 10 sec with video data), the third is 30 secs long (only last 10 sec with
 video data), and so on.
 >
 >
 > {{{
 > ffmpeg started on 2012-01-10 at 07:49:52
 > Report written to "ffmpeg-20120110-074952.log"
 > Command line:
 > ffmpeg.exe -report -f dshow -i "video=USB2.0 UVC VGA WebCam" -vcodec
 mpeg4 -map 0 -t 60 -f segment -segment_time 10 -segment_format avi
 "output%03d.avi"
 > ffmpeg version N-36635-gceb0dd9 Copyright (c) 2000-2012 the FFmpeg
 developers
 >   built on Jan  9 2012 17:39:58 with gcc 4.6.2
 >   configuration: --enable-gpl --enable-version3 --disable-w32threads
 --enable-runtime-cpudetect --enable-avisynth --enable-bzlib --enable-
 frei0r --enable-libopencore-amrnb --enable-libopencore-amrwb --enable-
 libfreetype --enable-libgsm --enable-libmp3lame --enable-libopenjpeg
 --enable-librtmp --enable-libschroedinger --enable-libspeex --enable-
 libtheora --enable-libvo-aacenc --enable-libvo-amrwbenc --enable-libvorbis
 --enable-libvpx --enable-libx264 --enable-libxavs --enable-libxvid
 --enable-zlib
 >   libavutil      51. 34.100 / 51. 34.100
 >   libavcodec     53. 54.100 / 53. 54.100
 >   libavformat    53. 29.100 / 53. 29.100
 >   libavdevice    53.  4.100 / 53.  4.100
 >   libavfilter     2. 58.100 /  2. 58.100
 >   libswscale      2.  1.100 /  2.  1.100
 >   libswresample   0.  6.100 /  0.  6.100
 >   libpostproc    51.  2.100 / 51.  2.100
 > [...]
 > video:1591kB audio:0kB global headers:0kB muxing overhead -100.000000%
 > }}}

 Hi, this is the assumed behavior of the segment muxer, which does not
 change the timestamps of the original file, and is IMO the correct
 behavior, while the *total duration* of each segment should be more or
 less the specified segment time.

 For example with a video starting with a timestamp of 10 and an ending
 time around 20, the player is assumed to play the file just for 10 seconds
 (this is the behavior assumed for example by ffplay).
 I checked the attached files and they look perfectly sane to me, given the
 way they have been generated.

 You may ask for an extension of the segment muxer (for resetting the
 timestamps at the beginning of each segment) but in this case you should
 provide an explanation of why you need such an option.

-- 
Ticket URL: <https://ffmpeg.org/trac/ffmpeg/ticket/910#comment:2>
FFmpeg <http://ffmpeg.org>
FFmpeg issue tracker


More information about the FFmpeg-trac mailing list