Opened 10 years ago

Last modified 10 years ago

#3071 new defect

Encoding of files from FMS emits many errors and never ends

Reported by: yotam Owned by:
Priority: normal Component: avfilter
Version: git-master Keywords:
Cc: Blocked By:
Blocking: Reproduced by developer: no
Analyzed by developer: no

Description

Summary of the bug:
Input files originate from FMS
The audio channels are merged with amerge filter,
this causes many errors and file encoding never ends.
When replacing amerge with amix the encoding is performed properly (but this is not a good workaround).
The input files are submitted into your ftp (never_ending_encoding_input1.mp4, never_ending_encoding_input2.mp4, never_ending_encoding_input3.png)

The output was too long for this box so i subbmitted it to ftp as
never_ending_encoding.log

How to reproduce:

ffmpeg started on 2013-10-22 at 17:47:42
Report written to "ffmpeg-20131022-174742.log"
Command line:
ffmpeg -filter_complex "[1:v]scale='128:96'[1657367588-1865681157];[0:v][1657367588-1865681157]overlay='6:379'[1865681157-1094475852];[1865681157-1094475852][2:v]overlay='474:430'" -filter_complex "[1:a][0:a]amerge" -y -i never_ending_encoding_input1.mp4 -i never_ending_encoding_input2.mp4 -i never-ending-encoding_input3.png -c:v libx264 -x264opts "level=3.1" -c:a libvo_aacenc -report -movflags faststart 1.mp4
ffmpeg version N-57114-g5340c3d Copyright (c) 2000-2013 the FFmpeg developers

built on Oct 13 2013 18:08:16 with gcc 4.8.1 (GCC)
configuration: --enable-gpl --enable-version3 --disable-w32threads --enable-avisynth --enable-bzlib --enable-fontconfig --enable-frei0r --enable-gnutls --enable-iconv --enable-libass --enable-libbluray --enable-libcaca --enable-libfreetype --enable-libgsm --enable-libilbc --enable-libmodplug --enable-libmp3lame --enable-libopencore-amrnb --enable-libopencore-amrwb --enable-libopenjpeg --enable-libopus --enable-librtmp --enable-libschroedinger --enable-libsoxr --enable-libspeex --enable-libtheora --enable-libtwolame --enable-libvidstab --enable-libvo-aacenc --enable-libvo-amrwbenc --enable-libvorbis --enable-libvpx --enable-libwavpack --enable-libx264 --enable-libxavs --enable-libxvid --enable-zlib
libavutil 52. 46.101 / 52. 46.101
libavcodec 55. 35.100 / 55. 35.100
libavformat 55. 19.100 / 55. 19.100
libavdevice 55. 4.100 / 55. 4.100
libavfilter 3. 88.101 / 3. 88.101
libswscale 2. 5.101 / 2. 5.101
libswresample 0. 17.103 / 0. 17.103
libpostproc 52. 3.100 / 52. 3.100

Attachments (5)

never_ending_encoding.log (798.4 KB ) - added by yotam 10 years ago.
log
never_ending_encoding_input1.mp4 (1.5 MB ) - added by yotam 10 years ago.
input file 1
never_ending_encoding_input2.mp4 (1.6 MB ) - added by yotam 10 years ago.
input file 2
never-ending-encoding_input3.png (4.6 KB ) - added by yotam 10 years ago.
input file 3
2.log (633.4 KB ) - added by yotam 10 years ago.
2.log

Change History (12)

by yotam, 10 years ago

Attachment: never_ending_encoding.log added

log

by yotam, 10 years ago

input file 1

by yotam, 10 years ago

input file 2

by yotam, 10 years ago

input file 3

comment:1 by yotam, 10 years ago

Correction: the log and input files are attached here

comment:2 by Carl Eugen Hoyos, 10 years ago

Is this problem only reproducible using external libraries or also with -vcodec mpeg4 -strict -2 -acodec aac ?

comment:3 by yotam, 10 years ago

The problem persists in both configurations

comment:4 by yotam, 10 years ago

The bug is still reproducible with the following command, which replaces vo_aacenc with the built-in aac codec and simplifies the video processing:

ffmpeg -filter_complex "[0:v][1:v]overlay='6:379'" -filter_complex "[1:a][0:a]amerge" -y -i never_ending_encoding_input1.mp4 -i never_ending_encoding_input2.mp4 -c:v libx264 -x264opts "level=3.1" -c:a aac -strict -2 -report -movflags faststart 2.mp4

However, when the video codec is replaced as well (mpeg4 instead of libx264), the original symptoms partially go away (the error appears only once and the operation completes rather than hanging) but instead the following warning message appears repeatedly during processing:

[Parsed_overlay_0 @ 00000000042ee340] [framesync @ 000000000257b6c8] Buffer queue overflow, dropping.

Last edited 10 years ago by yotam (previous) (diff)

in reply to:  4 ; comment:5 by Carl Eugen Hoyos, 10 years ago

Replying to yotam:

However, when the video codec is replaced as well (mpeg4 instead of libx264), the original symptoms partially go away (the error appears only once and the operation completes rather than hanging) but instead the following warning message appears repeatedly during processing:

[Parsed_overlay_0 @ 00000000042ee340] [framesync @ 000000000257b6c8] Buffer queue overflow, dropping.

I suspect (complete, uncut console output missing) that you have to use a constant quantiser (or a high bitrate), for example -qscale 5

in reply to:  5 comment:6 by yotam, 10 years ago

Replying to cehoyos:

Replying to yotam:

However, when the video codec is replaced as well (mpeg4 instead of libx264), the original symptoms partially go away (the error appears only once and the operation completes rather than hanging) but instead the following warning message appears repeatedly during processing:

[Parsed_overlay_0 @ 00000000042ee340] [framesync @ 000000000257b6c8] Buffer queue overflow, dropping.

I suspect (complete, uncut console output missing) that you have to use a constant quantiser (or a high bitrate), for example -qscale 5

constant quantizer failed to change the behavior, as did using a high bitrate. The full console output for the modified command (replacing the video codec) is attached as 2.log

by yotam, 10 years ago

Attachment: 2.log added

2.log

comment:7 by Michael Niedermayer, 10 years ago

iam not able to reproduce this it seems

Note: See TracTickets for help on using tickets.