Freeze during x264 transcoding

[kef]

Hello,

Recently ffmpeg freeze everytime I try to transcode an MP4 recorded by wirecast. I don't know if it's come from a wirecast update or a ffmpeg modification.
The MP4 play well with VLC/MPlayer but freeze when I try to transcode it.
To be sure I update to the lastest version of x264 and ffmpeg, it's work well with other videos, but specificaly with this one, it's still freezing.

My transcoding command was complex at the beginning but I get exactly the same phenomenom with something simple like :
ffmpeg -i input.mp4 -sameq -an output.mp4

And everything seems normal in the result :
{{{ffmpeg version N-31775-g640a905, Copyright (c) 2000-2011 the FFmpeg developers
Built on Aug 8 2011 12:21:40 with gcc 4.3.2

libavutil 51. 11. 1 / 51. 11. 1
libavcodec 53. 9. 1 / 53. 9. 1
libavformat 53. 6. 0 / 53. 6. 0
libavdevice 53. 2. 0 / 53. 2. 0
libavfilter 2. 28. 1 / 2. 28. 1
libswscale 2. 0. 0 / 2. 0. 0
libpostproc 51. 2. 0 / 51. 2. 0

Seems stream 0 codec frame rate differs from container frame rate: 50.00 (50/1) -> 25.00 (50/2)
Input #0, mov,mp4,m4a,3gp,3g2,mj2, from 'test.mp4':

Metadata:

major_brand : f4v
minor_version : 0
compatible_brands: isommp42m4v
creation_time : 2011-08-08 15:09:50

Duration: 00:00:21.38, start: 0.000000, bitrate: 697 kb/s

Stream #0.0(eng): Video: h264 (Main), yuv420p, 960x540 [SAR 1:1 DAR 16:9], 598 kb/s, 24.94 fps, 25 tbr, 90k tbn, 50 tbc
Metadata:

creation_time : 2011-08-08 15:09:50

Stream #0.1(eng): Audio: aac, 44100 Hz, stereo, s16, 93 kb/s
Metadata:

creation_time : 2011-08-08 15:09:50

[buffer @ 0xa4724e0] w:960 h:540 pixfmt:yuv420p tb:1/1000000 sar:1/1 sws_param:
[mpeg4 @ 0xa46bce0] removing common factors from framerate
Output #0, mp4, to 'test-output.mp4':

Metadata:

major_brand : f4v
minor_version : 0
compatible_brands: isommp42m4v
creation_time : 2011-08-08 15:09:50
encoder : Lavf53.6.0
Stream #0.0(eng): Video: mpeg4, yuv420p, 960x540 [SAR 1:1 DAR 16:9], q=2-31, 200 kb/s, 25 tbn, 25 tbc
Metadata:

creation_time : 2011-08-08 15:09:50

Stream mapping:

Stream #0.0 -> #0.0

Press [q] to stop, ? for help}}}

[kef]

An exemple of those mp4

[llogan]

Reproduced with N-31775-g640a905 in x86_64 Arch Linux.

$ ffmpeg -v 9 -loglevel 99 -i ffmpeg_transcoding_freeze.mp4 -an -y output.mp4
ffmpeg version N-31775-g640a905, Copyright (c) 2000-2011 the FFmpeg developers
  built on Aug  8 2011 10:58:06 with gcc 4.6.1
  configuration: --prefix=/usr
  libavutil    51. 11. 1 / 51. 11. 1
  libavcodec   53.  9. 1 / 53.  9. 1
  libavformat  53.  6. 0 / 53.  6. 0
  libavdevice  53.  2. 0 / 53.  2. 0
  libavfilter   2. 28. 1 /  2. 28. 1
  libswscale    2.  0. 0 /  2.  0. 0
[mov,mp4,m4a,3gp,3g2,mj2 @ 0x30b8420] Format mov,mp4,m4a,3gp,3g2,mj2 probed with size=2048 and score=100
[mov,mp4,m4a,3gp,3g2,mj2 @ 0x30b8420] ISO: File Type Major Brand: f4v 
[h264 @ 0x30bae60] Unsupported bit depth: 0
[aac @ 0x30bbc20] Unsupported bit depth: 0
[h264 @ 0x30bae60] no picture
    Last message repeated 1 times
[mov,mp4,m4a,3gp,3g2,mj2 @ 0x30b8420] All info found

Seems stream 0 codec frame rate differs from container frame rate: 50.00 (50/1) -> 25.00 (50/2)
Input #0, mov,mp4,m4a,3gp,3g2,mj2, from 'ffmpeg_transcoding_freeze.mp4':
  Metadata:
    major_brand     : f4v 
    minor_version   : 0
    compatible_brands: isommp42m4v 
    creation_time   : 1875-07-02 08:41:34
  Duration: 00:00:21.38, start: 0.000000, bitrate: 697 kb/s
    Stream #0.0(eng), 24, 1/90000: Video: h264 (Main), yuv420p, 960x540 [SAR 1:1 DAR 16:9], 1/50, 598 kb/s, 24.94 fps, 25 tbr, 90k tbn, 50 tbc
    Metadata:
      creation_time   : 1875-07-02 08:41:34
    Stream #0.1(eng), 1, 1/90000: Audio: aac, 44100 Hz, stereo, s16, 93 kb/s
    Metadata:
      creation_time   : 1875-07-02 08:41:34
[buffer @ 0x317a8c0] w:960 h:540 pixfmt:yuv420p tb:1/1000000 sar:1/1 sws_param:
[mpeg4 @ 0x317a2c0] removing common factors from framerate
Output #0, mp4, to 'output.mp4':
  Metadata:
    major_brand     : f4v 
    minor_version   : 0
    compatible_brands: isommp42m4v 
    creation_time   : 1875-07-02 08:41:34
    encoder         : Lavf53.6.0
    Stream #0.0(eng), 0, 1/25: Video: mpeg4, yuv420p, 960x540 [SAR 1:1 DAR 16:9], 1/25, q=2-31, 200 kb/s, 25 tbn, 25 tbc
    Metadata:
      creation_time   : 1875-07-02 08:41:34
Stream mapping:
  Stream #0.0 -> #0.0
Press [q] to stop, [?] for help
[h264 @ 0x30bae60] no picture
*** 419432 dup!e repeated 1 times
Killed

[cehoyos]

Please provide a backtrace.

Does it only freeze if the input is H264, or also for other video codecs?
Does latest FFmpeg git fail with an earlier version of x264?
Does latest x264 fail with an earlier version of FFmpeg?
When did it break?

[cehoyos]

Muxing to mp4 (avi works fine) is broken since 91360ce61d00bb20429fb41857abebf50a5c6b1d, r25805.

[kef]

Does it only freeze if the input is H264, or also for other video codecs?

Yes this is the only format I find which freeze ffmpeg like this. I also tried with other wirecast export like vp6 or mov, but they didn't fail at transcoding.

When did it break?

I find when the problem appear. In previous version of wirecast 3.X, baseline was the default h264 profil, but since few time with the new version 4.X, Main profile is the default value. If I try the same process than before and just change the profile to Baseline, there is absolutely no problem and the MP4 transcode well.

Does latest FFmpeg git fail with an earlier version of x264?

Yes, I try with a x264 snapshot of december and I get the same problem.

Does latest x264 fail with an earlier version of FFmpeg?

Yes, I try with an ffmpeg 0.6.1 and I get the same problem.

I'm looking to get a backtrace later because I don't have the debug binary on this server.

[quantamm]

I think I'm also seeing this bug. I'm using:

ffmpeg version 0.9, Copyright (c) 2000-2011 the FFmpeg developers

built on Dec 12 2011 19:52:01 with gcc 4.6.2

If someone can provide instructions on how to produce a "backtrace", then I can supply one, or whatever other information is needed.

[cehoyos]

Please see http://ffmpeg.org/bugreports.html

[cehoyos]

But please note that the cause for the regression is known, so no backtrace is needed anymore.

[cehoyos]

Should be fixed for the provided sample by Michael.