[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