Discussion:
[issue2658] Generating a Tiff from a video throws a seg fault
(too old to reply)
Adam
2011-03-12 00:37:15 UTC
Permalink
New submission from Adam <***@gmail.com>:

I tried to run the following command but I get a seg fault. It appears to be
the case with any type of video. It sometimes works when -ss is before -i but
for a variety of reasons I can't use this approach. Regardless I tried that
approach on this file and it didn't work.

ffmpeg -strict inofficial -y -i sample.mp4 -ss 40 -r 1 -vframes 1 -f image2
sample.tiff

output: http://pastebin.com/6XnwNMDB

info about my ffmpeg (via macports). A user on irc reported reproducing the
same bug with git-N-28415-g3efbbbb

FFmpeg version 0.6, Copyright (c) 2000-2010 the FFmpeg developers
built on Mar 3 2011 21:54:45 with gcc 4.2.1 (Apple Inc. build 5646) (dot 1)
configuration: --prefix=/opt/local --enable-gpl --enable-postproc
--enable-swscale --enable-avfilter --enable-avfilter-lavf --enable-libmp3lame
--enable-libvorbis --enable-libtheora --enable-libdirac --enable-libschroedinger
--enable-libfaac --enable-libfaad --enable-libxvid --enable-libx264
--enable-libvpx --enable-libspeex --enable-nonfree --mandir=/opt/local/share/man
--enable-shared --enable-pthreads --disable-indevs --cc=/usr/bin/gcc-4.2
--arch=x86_64
libavutil 50.15. 1 / 50.15. 1
libavcodec 52.72. 2 / 52.72. 2
libavformat 52.64. 2 / 52.64. 2
libavdevice 52. 2. 0 / 52. 2. 0
libavfilter 1.19. 0 / 1.19. 0
libswscale 1.11. 0 / 1.11. 0
libpostproc 51. 2. 0 / 51. 2. 0

----------
messages: 13856
priority: normal
status: new
substatus: new
title: Generating a Tiff from a video throws a seg fault
type: bug

________________________________________________
FFmpeg issue tracker <***@roundup.ffmpeg.org>
<https://roundup.ffmpeg.org/issue2658>
________________________________________________
Lou
2011-03-12 01:05:18 UTC
Permalink
Lou <***@fakeoutdoorsman.com> added the comment:

Crashes are important. Reproduced with git-N-28415-g3efbbbb.

$ gdb --args ./ffmpeg_g -i ~/vbox/IronMan.mkv -ss 40 -vframes 1 -y out.tiff
GNU gdb (GDB) 7.2-ubuntu
Copyright (C) 2010 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from /home/lou/ffmpeg-n/ffmpeg_g...done.
(gdb) r
Starting program: /home/lou/ffmpeg-n/ffmpeg_g -i /home/lou/vbox/IronMan.mkv -ss
40 -vframes 1 -y out.tiff
[Thread debugging using libthread_db enabled]
FFmpeg version git-N-28415-g3efbbbb, Copyright (c) 2000-2011 the FFmpeg developers
built on Mar 11 2011 15:38:12 with gcc 4.4.5
configuration: --disable-optimizations
libavutil 50. 39. 0 / 50. 39. 0
libavcodec 52.114. 0 / 52.114. 0
libavformat 52.103. 0 / 52.103. 0
libavdevice 52. 3. 0 / 52. 3. 0
libavfilter 1. 76. 0 / 1. 76. 0
libswscale 0. 12. 0 / 0. 12. 0
[matroska,webm @ 0x131d690] Estimating duration from bitrate, this may be inaccurate

Seems stream 0 codec frame rate differs from container frame rate: 47.95
(10000000/208541) -> 24.00 (24/1)
Input #0, matroska,webm, from '/home/lou/vbox/IronMan.mkv':
Duration: 00:01:48.50, start: 0.000000, bitrate: N/A
Stream #0.0: Video: h264 (High), yuv420p, 1280x720, PAR 115:87 DAR 1840:783,
23.98 fps, 24 tbr, 1k tbn, 47.95 tbc (default)
Stream #0.1: Audio: aac, 48000 Hz, stereo, s16 (default)
[buffer @ 0x139d180] w:1280 h:720 pixfmt:yuv420p
[setdar @ 0x13934b0] a:47/20
[setdar @ 0x13934b0] w:1280 h:720 -> dar:47/20 par:78/59
Output #0, image2, to 'out.tiff':
Metadata:
encoder : Lavf52.103.0
Stream #0.0: Video: tiff, yuv420p, 1280x720 [PAR 78:59 DAR 416:177], q=2-31,
200 kb/s, 90k tbn, 24 tbc (default)
Stream mapping:
Stream #0.0 -> #0.0
Press [q] to stop encoding
[buffer @ 0x139d180] Buffering several frames is not supported. Please consume
all available frames before adding a new one.
Last message repeated 33 times
Program received signal SIGSEGV, Segmentation fault.
0x0000000000408286 in print_report (output_files=0xdd9060, ost_table=0x136e030,
nb_ostreams=1, is_last_report=0) at ffmpeg.c:1389
1389 enc->coded_frame->quality/(float)FF_QP2LAMBDA : -1);
(gdb)

(gdb) bt
#0 0x0000000000408286 in print_report (output_files=0xdd9060,
ost_table=0x136e030, nb_ostreams=1, is_last_report=0) at ffmpeg.c:1389
#1 0x000000000040d6b3 in transcode (output_files=0xdd9060, nb_output_files=1,
input_files=0xdd8540, nb_input_files=1, stream_maps=0x0, nb_stream_maps=0) at
ffmpeg.c:2662
#2 0x0000000000411eca in main (argc=9, argv=0x7fffffffe318) at ffmpeg.c:4388

$ valgrind --tool=memcheck ./ffmpeg_g -i ~/vbox/IronMan.mkv -ss 40 -vframes 1 -y
out.tiff
==17483== Memcheck, a memory error detector
==17483== Copyright (C) 2002-2010, and GNU GPL'd, by Julian Seward et al.
==17483== Using Valgrind-3.6.0.SVN-Debian and LibVEX; rerun with -h for
copyright info
==17483== Command: ./ffmpeg_g -i /home/lou/vbox/IronMan.mkv -ss 40 -vframes 1 -y
out.tiff
==17483==
FFmpeg version git-N-28415-g3efbbbb, Copyright (c) 2000-2011 the FFmpeg developers
built on Mar 11 2011 15:38:12 with gcc 4.4.5
configuration: --disable-optimizations
libavutil 50. 39. 0 / 50. 39. 0
libavcodec 52.114. 0 / 52.114. 0
libavformat 52.103. 0 / 52.103. 0
libavdevice 52. 3. 0 / 52. 3. 0
libavfilter 1. 76. 0 / 1. 76. 0
libswscale 0. 12. 0 / 0. 12. 0
[matroska,webm @ 0x68c4840] Estimating duration from bitrate, this may be inaccurate

Seems stream 0 codec frame rate differs from container frame rate: 47.95
(10000000/208541) -> 24.00 (24/1)
Input #0, matroska,webm, from '/home/lou/vbox/IronMan.mkv':
Duration: 00:01:48.50, start: 0.000000, bitrate: N/A
Stream #0.0: Video: h264 (High), yuv420p, 1280x720, PAR 115:87 DAR 1840:783,
23.98 fps, 24 tbr, 1k tbn, 47.95 tbc (default)
Stream #0.1: Audio: aac, 48000 Hz, stereo, s16 (default)
[buffer @ 0x68d6ee0] w:1280 h:720 pixfmt:yuv420p
[setdar @ 0x6ab6c20] a:47/20
[setdar @ 0x6ab6c20] w:1280 h:720 -> dar:47/20 par:78/59
Output #0, image2, to 'out.tiff':
Metadata:
encoder : Lavf52.103.0
Stream #0.0: Video: tiff, yuv420p, 1280x720 [PAR 78:59 DAR 416:177], q=2-31,
200 kb/s, 90k tbn, 24 tbc (default)
Stream mapping:
Stream #0.0 -> #0.0
Press [q] to stop encoding
==17483== Invalid read of size 4
==17483== at 0x408286: print_report (ffmpeg.c:1389)
==17483== by 0x40D6B2: transcode (ffmpeg.c:2662)
==17483== by 0x411EC9: main (ffmpeg.c:4388)
==17483== Address 0x68 is not stack'd, malloc'd or (recently) free'd
==17483==
==17483==
==17483== Process terminating with default action of signal 11 (SIGSEGV)
==17483== Access not within mapped region at address 0x68
==17483== at 0x408286: print_report (ffmpeg.c:1389)
==17483== by 0x40D6B2: transcode (ffmpeg.c:2662)
==17483== by 0x411EC9: main (ffmpeg.c:4388)
==17483== If you believe this happened as a result of a stack
==17483== overflow in your program's main thread (unlikely but
==17483== possible), you can try to increase the size of the
==17483== main thread stack using the --main-stacksize= flag.
==17483== The main thread stack size used in this run was 8388608.
==17483==
==17483== HEAP SUMMARY:
==17483== in use at exit: 11,415,532 bytes in 441 blocks
==17483== total heap usage: 1,132 allocs, 691 frees, 24,243,110 bytes allocated
==17483==
==17483== LEAK SUMMARY:
==17483== definitely lost: 0 bytes in 0 blocks
==17483== indirectly lost: 0 bytes in 0 blocks
==17483== possibly lost: 0 bytes in 0 blocks
==17483== still reachable: 11,415,532 bytes in 441 blocks
==17483== suppressed: 0 bytes in 0 blocks
==17483== Rerun with --leak-check=full to see details of leaked memory
==17483==
==17483== For counts of detected and suppressed errors, rerun with: -v
==17483== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 4 from 4)
Segmentation fault

----------
priority: normal -> important
status: new -> open
substatus: new -> reproduced

________________________________________________
FFmpeg issue tracker <***@roundup.ffmpeg.org>
<https://roundup.ffmpeg.org/issue2658>
________________________________________________
Justin Ruggles
2011-04-07 19:02:54 UTC
Permalink
Justin Ruggles <***@gmail.com> added the comment:

i have no idea if the attached patch is correct, but it fixes the crash

______________________________________________
Libav issue tracker <***@roundup.libav.org>
<https://roundup.libav.org/issue2658>
______________________________________________

Loading...