cornel90 / ffmpegthumbnailer

Automatically exported from code.google.com/p/ffmpegthumbnailer
GNU General Public License v2.0
0 stars 0 forks source link

MovieDecoder hangs at avformat_find_stream_info() #106

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago
For some files which may have wrong headers, the avformat_find_stream_info() 
function from ffmpeg takes forever.

It seems a common problem, actually searching for this function's name in 
Google gives as second result a forum post about the same problem:
http://ffmpeg.zeranoe.com/forum/viewtopic.php?f=15&t=1211

In that forum, the proposed solution is to set the 
AVFormatCtx->max_analyze_duration to 0.

Using ffmpegthumbnailer version 2.0.8

$ ffplay -v
avplay version 0.8.6-4:0.8.6-0ubuntu0.12.04.1, Copyright (c) 2003-2013 the 
Libav developers
  built on Apr  2 2013 17:02:36 with gcc 4.6.3

OS: Ubuntu 12.04 LTS

Original issue reported on code.google.com by oneorj...@gmail.com on 2 Sep 2013 at 5:20

GoogleCodeExporter commented 9 years ago
I'm not a ffmpeg developer; what would be the equivalent way of setting 
AVFormatCtx->max_analyze_duration to 0 inside the ffmpegthumbnailer's 
MovieDecoder::initialize() function?

Original comment by oneorj...@gmail.com on 2 Sep 2013 at 5:22

GoogleCodeExporter commented 9 years ago
try adding:
m_pFormatContext->max_analyze_duration = 0;

Original comment by dirk.vdb on 10 Sep 2013 at 9:01

GoogleCodeExporter commented 9 years ago
Found a workaround to this problem: the call to 
VideoThumbnailer::generateThumbnail() must be done inside a try/catch block AND 
covered by a mutex:

std::vector<uint8_t> buffer;
mutex.lock();
try {
    thumbnailer.generateThumbnail(item.toStdString(), Jpeg, buffer);
}
catch (std::exception& e) {
    qDebug() << "WARNING" << e.what();
}
mutex.unlock();

So this issue is happening for 2 reasons:

1) Insufficient thread protection around the thread-unsafe functions of ffmpeg: 
avformat_open_input() and avformat_find_stream_info(), which in turn call 
avcodec_open() and avcodec_close(). I'm assuming this should be thread-safe 
because generating thumbnails from a set of files is the kind of task which 
naturally asks for parallelization, thus being (always IMHO) part of the 
ffmpegthumbnailer scope as a library.

2) Insufficient protection in VideoThumbnailer::generateThumbnail() against 
exceptions thrown from the constructor of MovieDecoder (which in turn calls 
MovieDecoder::initialize() and may throw a couple of unmanaged 'logic_error' 
exceptions).

Original comment by oneorj...@gmail.com on 13 Sep 2013 at 11:41

GoogleCodeExporter commented 9 years ago
1) I don't fully agree with your reasoning that ffmpegthumbailer should be 
thread safe.
If you want to create thumbnails in parrallel, create multiple instances of the 
VideoThumbnailer class.

2) The generateThumbnail method does not catch these errors because then the 
thumbnail creation would silently fail. The caller should call the method in a 
try catch block.

Original comment by dirk.vdb on 3 Oct 2013 at 2:44

GoogleCodeExporter commented 9 years ago

Original comment by dirk.vdb on 1 Mar 2014 at 8:59