FFplay regression with H264 high profile input (gcc 4.2.* specific)

[Ian McIntosh]

Summary of the bug:

FFplay version 0.8.12 successfully decodes and plays this file. FFplay from snapshot downloaded http://git.videolan.org/?p=ffmpeg.git;a=snapshot;h=HEAD;sf=tgz (ffmpeg-HEAD-0c142e4.tar.gz 19 June 2012) does not like this file.

A sample of the source file is attached.

How to reproduce:

Output using ffplay-0.8.12

./ffplay ../h264_high_profile.h264
ffplay version 0.8.12, Copyright (c) 2003-2011 the FFmpeg developers
  built on Jun 18 2012 14:48:35 with gcc 4.2.2
  configuration: --enable-memalign-hack --disable-devices --disable-network --enable-shared --disable-static --disable-debug --enable-swscale --enable-gpl --prefix=/tmp
  libavutil    51.  9. 1 / 51.  9. 1
  libavcodec   53.  8. 0 / 53.  8. 0
  libavformat  53.  5. 0 / 53.  5. 0
  libavdevice  53.  1. 1 / 53.  1. 1
  libavfilter   2. 23. 0 /  2. 23. 0
  libswscale    2.  0. 0 /  2.  0. 0
  libpostproc  51.  2. 0 / 51.  2. 0
[h264 @ 0x807d810] Estimating duration from bitrate, this may be inaccurate
Input #0, h264, from '../h264_high_profile.h264':
  Duration: N/A, bitrate: N/A
    Stream #0.0: Video: h264 (High), yuv420p, 704x576, 25 fps, 25 tbr, 1200k tbn, 50 tbc
   8.91 A-V:  0.000 s:0.0 aq=    0KB vq=    0KB sq=    0B f=0/0   0/0

Output from HEAD-0c142e4

./ffplay ../h264_high_profile.h264
ffplay version 0.10.2.git-0c142e4 Copyright (c) 2003-2012 the FFmpeg developers
  built on Jun 19 2012 07:03:12 with gcc 4.2.2
  configuration: --enable-memalign-hack --disable-devices --disable-network --enable-shared --disable-static --disable-debug --enable-swscale --enable-gpl --prefix=/tmp
  libavutil      51. 58.100 / 51. 58.100
  libavcodec     54. 25.100 / 54. 25.100
  libavformat    54.  8.100 / 54.  8.100
  libavdevice    54.  0.100 / 54.  0.100
  libavfilter     2. 81.100 /  2. 81.100
  libswscale      2.  1.100 /  2.  1.100
  libswresample   0. 15.100 /  0. 15.100
  libpostproc    52.  0.100 / 52.  0.100
[h264 @ 0x8082c10] top block unavailable for requested intra4x4 mode -1 at 10 0
[h264 @ 0x8082c10] error while decoding MB 10 0, bytestream (5074)
[h264 @ 0x8082c10] concealing 1584 DC, 1584 AC, 1584 MV errors
[h264 @ 0x8082c10] concealing 1353 DC, 1353 AC, 1353 MV errors
[h264 @ 0x8082c10] top block unavailable for requested intra4x4 mode -1 at 11 0
[h264 @ 0x8082c10] error while decoding MB 11 0, bytestream (2753)
[h264 @ 0x8082c10] concealing 1584 DC, 1584 AC, 1584 MV errors
[h264 @ 0x8082c10] concealing 1516 DC, 1516 AC, 1516 MV errors
[h264 @ 0x8082c10] concealing 1499 DC, 1499 AC, 1499 MV errors
[h264 @ 0x8083010] Estimating duration from bitrate, this may be inaccurate
Input #0, h264, from '../h264_high_profile.h264':
  Duration: N/A, bitrate: N/A
    Stream #0:0: Video: h264 (High), yuv420p, 704x576, 25 fps, 25 tbr, 1200k tbn, 50 tbc
[ffplay_buffer @ 0x8539810] w:704 h:576 pixfmt:yuv420p tb:1/1200000 fr:0/1 sar:0/1 sws_param:
[h264 @ 0x8084810] top block unavailable for requested intra4x4 mode -1 at 10 0
[h264 @ 0x8084810] error while decoding MB 10 0, bytestream (5074)
[h264 @ 0x8084810] concealing 1584 DC, 1584 AC, 1584 MV errors
[h264 @ 0x8084c10] concealing 1353 DC, 1353 AC, 1353 MV errors
[h264 @ 0x8084010] top block unavailable for requested intra4x4 mode -1 at 11 0
[h264 @ 0x8084010] error while decoding MB 11 0, bytestream (2753)
[h264 @ 0x8084010] concealing 1584 DC, 1584 AC, 1584 MV errors
[h264 @ 0x8084810] concealing 1516 DC, 1516 AC, 1516 MV errors 0B f=0/0
[h264 @ 0x8084c10] concealing 1499 DC, 1499 AC, 1499 MV errors0/0
[h264 @ 0x8084010] concealing 1562 DC, 1562 AC, 1562 MV errors0/0
[h264 @ 0x8084810] concealing 1549 DC, 1549 AC, 1549 MV errors
[h264 @ 0x8084c10] top block unavailable for requested intra4x4 mode -1 at 28 0
[h264 @ 0x8084c10] error while decoding MB 28 0, bytestream (4088)
[h264 @ 0x8084c10] concealing 1584 DC, 1584 AC, 1584 MV errors
[h264 @ 0x8084010] concealing 1567 DC, 1567 AC, 1567 MV errors0/0
[h264 @ 0x8084810] concealing 1431 DC, 1431 AC, 1431 MV errors0/0
[h264 @ 0x8084c10] concealing 1575 DC, 1575 AC, 1575 MV errors0/0
[h264 @ 0x8084010] concealing 1285 DC, 1285 AC, 1285 MV errors0/0
[h264 @ 0x8084810] concealing 1482 DC, 1482 AC, 1482 MV errors0/0
[h264 @ 0x8084c10] top block unavailable for requested intra mode at 16 0
[h264 @ 0x8084c10] error while decoding MB 16 0, bytestream (5696)
[h264 @ 0x8084c10] concealing 1584 DC, 1584 AC, 1584 MV errors
[h264 @ 0x8084010] concealing 1577 DC, 1577 AC, 1577 MV errors
[h264 @ 0x8084810] top block unavailable for requested intra mode at 23 0
[h264 @ 0x8084810] error while decoding MB 23 0, bytestream (5604)
[h264 @ 0x8084810] concealing 1584 DC, 1584 AC, 1584 MV errors
[h264 @ 0x8084c10] top block unavailable for requested intra4x4 mode -1 at 10 0
[h264 @ 0x8084c10] error while decoding MB 10 0, bytestream (3930)
[h264 @ 0x8084c10] concealing 1584 DC, 1584 AC, 1584 MV errors
[h264 @ 0x8084010] concealing 1567 DC, 1567 AC, 1567 MV errors0/0
[h264 @ 0x8084810] concealing 1084 DC, 1084 AC, 1084 MV errors
   2.67 A-V:  0.000 fd=   0 aq=    0KB vq=    0KB sq=    0B f=0/0

[Carl Eugen Hoyos]

Since decoding works fine here with 0c142e4 and the same solution worked for another h264 problem:
Could you test "make distclean && ./configure && make" ?

[Ian McIntosh]

Thanks for the quick reply.

Tested "make distclean && ./configure && make" and got the same result...see output below

I will try and download a ffplay binary and see if it works with that. I assume if it works for you then there is possibly a problem with my build environment

ffplay /tmp/h264_high_profile.h264
ffplay version 0.10.2.git-0c142e4 Copyright (c) 2003-2012 the FFmpeg developers
  built on Jun 19 2012 10:07:34 with gcc 4.2.2
  configuration:
  libavutil      51. 58.100 / 51. 58.100
  libavcodec     54. 25.100 / 54. 25.100
  libavformat    54.  8.100 / 54.  8.100
  libavdevice    54.  0.100 / 54.  0.100
  libavfilter     2. 81.100 /  2. 81.100
  libswscale      2.  1.100 /  2.  1.100
  libswresample   0. 15.100 /  0. 15.100
[h264 @ 0x8e1dc10] top block unavailable for requested intra4x4 mode -1 at 10 0
[h264 @ 0x8e1dc10] error while decoding MB 10 0, bytestream (5074)
[h264 @ 0x8e1dc10] concealing 1584 DC, 1584 AC, 1584 MV errors
[h264 @ 0x8e1dc10] concealing 1353 DC, 1353 AC, 1353 MV errors
[h264 @ 0x8e1dc10] top block unavailable for requested intra4x4 mode -1 at 11 0
[h264 @ 0x8e1dc10] error while decoding MB 11 0, bytestream (2753)
[h264 @ 0x8e1dc10] concealing 1584 DC, 1584 AC, 1584 MV errors
[h264 @ 0x8e1dc10] concealing 1516 DC, 1516 AC, 1516 MV errors
[h264 @ 0x8e1dc10] concealing 1499 DC, 1499 AC, 1499 MV errors
[h264 @ 0x8e1e010] Estimating duration from bitrate, this may be inaccurate
Input #0, h264, from '/tmp/h264_high_profile.h264':
  Duration: N/A, bitrate: N/A
    Stream #0:0: Video: h264 (High), yuv420p, 704x576, 25 fps, 25 tbr, 1200k tbn, 50 tbc
[ffplay_buffer @ 0x92d4810] w:704 h:576 pixfmt:yuv420p tb:1/1200000 fr:0/1 sar:0/1 sws_param:
[h264 @ 0x8e1f810] top block unavailable for requested intra4x4 mode -1 at 10 0
[h264 @ 0x8e1f810] error while decoding MB 10 0, bytestream (5074)
[h264 @ 0x8e1f810] concealing 1584 DC, 1584 AC, 1584 MV errors
[h264 @ 0x8e1fc10] concealing 1353 DC, 1353 AC, 1353 MV errors 0B f=0/0
[h264 @ 0x8e1f010] top block unavailable for requested intra4x4 mode -1 at 11 0
[h264 @ 0x8e1f010] error while decoding MB 11 0, bytestream (2753)
[h264 @ 0x8e1f010] concealing 1584 DC, 1584 AC, 1584 MV errors
[h264 @ 0x8e1f810] concealing 1516 DC, 1516 AC, 1516 MV errors 0B f=0/0
[h264 @ 0x8e1fc10] concealing 1499 DC, 1499 AC, 1499 MV errors
[h264 @ 0x8e1f010] concealing 1562 DC, 1562 AC, 1562 MV errors0/0
[h264 @ 0x8e1f810] concealing 1549 DC, 1549 AC, 1549 MV errors0/0
[h264 @ 0x8e1fc10] top block unavailable for requested intra4x4 mode -1 at 28 0
[h264 @ 0x8e1fc10] error while decoding MB 28 0, bytestream (4088)
[h264 @ 0x8e1fc10] concealing 1584 DC, 1584 AC, 1584 MV errors
[h264 @ 0x8e1f010] concealing 1567 DC, 1567 AC, 1567 MV errors
[h264 @ 0x8e1f810] concealing 1431 DC, 1431 AC, 1431 MV errors0/0
[h264 @ 0x8e1fc10] concealing 1575 DC, 1575 AC, 1575 MV errors0/0
[h264 @ 0x8e1f010] concealing 1285 DC, 1285 AC, 1285 MV errors
[h264 @ 0x8e1f810] concealing 1482 DC, 1482 AC, 1482 MV errors0/0
[h264 @ 0x8e1fc10] top block unavailable for requested intra mode at 16 0
[h264 @ 0x8e1fc10] error while decoding MB 16 0, bytestream (5696)
[h264 @ 0x8e1fc10] concealing 1584 DC, 1584 AC, 1584 MV errors
[h264 @ 0x8e1f010] concealing 1577 DC, 1577 AC, 1577 MV errors
[h264 @ 0x8e1f810] top block unavailable for requested intra mode at 23 0
[h264 @ 0x8e1f810] error while decoding MB 23 0, bytestream (5604)
[h264 @ 0x8e1f810] concealing 1584 DC, 1584 AC, 1584 MV errors
[h264 @ 0x8e1fc10] top block unavailable for requested intra4x4 mode -1 at 10 0
[h264 @ 0x8e1fc10] error while decoding MB 10 0, bytestream (3930)
[h264 @ 0x8e1fc10] concealing 1584 DC, 1584 AC, 1584 MV errors
[h264 @ 0x8e1f010] concealing 1567 DC, 1567 AC, 1567 MV errors0/0
[h264 @ 0x8e1f810] concealing 1084 DC, 1084 AC, 1084 MV errors0/0
   4.18 A-V:  0.000 fd=   0 aq=    0KB vq=    0KB sq=    0B f=0/0

[Carl Eugen Hoyos]

Since we would like to stay compatible with as many build environments as possible (if that is the reason):
Could you try to find the commit introducing the regression with git bisect?
You probably want to use a configure line like this to speed up the process:
./configure --disable-everything --enable-protocol=file --enable-demuxer=h264 --enable-decoder=h264 && make ffplay
(Try hard to initially only test "Merge remote-tracking branch" revisions.)

[Ian McIntosh]

Okay, I can do that. It may take a bit longer than it would others as I have never used git before (having only ever downloaded snapshots), so there will be a (hopefully short) learning curve. So please bear with me if I take time in responding.

I am building on netBSD 4.0_STABLE with gcc 4.2.2 and yasm 1.2.0.

[Tim Dawson]

I am having a similar problem. To test, I have static builds of ffmpeg 0.7.12, 0.8.12, 0.9.2, 0.10.3, and 0.11, as well as libav 8-something, all build at basically the same time, with the same options, in the same environment.

I am trying to work with an AVCHD file from a Canon camcorder. The tools from ffmpeg 7 through 9 all work with this file . . . ffmpeg 10 and 11 error gruesomely . . .

ffmpeg-9 works . . . clean video and audio

tadawson @ netier3 /usr4/srclib/audiolibs <353>:/usr/local/ff*9/bin/ffplay 0 >
ffplay version 0.9.2, Copyright (c) 2003-2012 the FFmpeg developers
  built on Jun 28 2012 08:35:44 with gcc 4.2.4
  configuration: --prefix=/usr/local/ffmpeg-9
  libavutil    51. 32. 0 / 51. 32. 0
  libavcodec   53. 42. 4 / 53. 42. 4
  libavformat  53. 24. 2 / 53. 24. 2
  libavdevice  53.  4. 0 / 53.  4. 0
  libavfilter   2. 53. 0 /  2. 53. 0
  libswscale    2.  1. 0 /  2.  1. 0
[h264 @ 0x8ddcce0] Increasing reorder buffer to 1
[mpegts @ 0x8dd9040] max_analyze_duration 5000000 reached at 5003333
Input #0, mpegts, from '00004.MTS':
  Duration: 00:02:13.66, start: 0.485833, bitrate: 6729 kb/s
  Program 1 
    Stream #0:0[0x1011]: Video: h264 (High) (HDMV / 0x564D4448), yuv420p, 1440x1080 [SAR 4:3 DAR 16:9], 59.96 fps, 59.94 tbr, 90k tbn, 59.94 tbc
    Stream #0:1[0x1100]: Audio: ac3 (AC-3 / 0x332D4341), 48000 Hz, stereo, s16, 256 kb/s
^C 1.55 A-V: -0.008 fd=   2 aq=  320KB vq= 6774KB sq=    0B f=0/0   f=0/0   
tadawson @ netier3 /usr4/srclib/audiolibs <354>: 

Version 10 or 11 fails - OK audio, mangled video:

tadawson @ netier3 /usr4/srclib/audiolibs <355>: /usr/local/ff*11/bin/ffplay >
ffplay version 0.11 Copyright (c) 2003-2012 the FFmpeg developers
  built on Jun 28 2012 08:43:11 with gcc 4.2.4
  configuration: --prefix=/usr/local/ffmpeg-11
  libavutil      51. 54.100 / 51. 54.100
  libavcodec     54. 23.100 / 54. 23.100
  libavformat    54.  6.100 / 54.  6.100
  libavdevice    54.  0.100 / 54.  0.100
  libavfilter     2. 77.100 /  2. 77.100
  libswscale      2.  1.100 /  2.  1.100
  libswresample   0. 15.100 /  0. 15.100
[h264 @ 0x8e67520] Reference 2 >= 2
[h264 @ 0x8e67520] error while decoding MB 49 0, bytestream (9249)
[h264 @ 0x8e67520] Increasing reorder buffer to 1
[h264 @ 0x8e67520] top block unavailable for requested intra mode at 21 1
[h264 @ 0x8e67520] error while decoding MB 21 1, bytestream (7097)
[h264 @ 0x8e67520] top block unavailable for requested intra4x4 mode -1 at 14 0
[h264 @ 0x8e67520] error while decoding MB 14 0, bytestream (11789)
[h264 @ 0x8e67520] Reference 3 >= 2
[h264 @ 0x8e67520] error while decoding MB 10 1, bytestream (9170)
[h264 @ 0x8e67520] top block unavailable for requested intra mode at 2 0
[h264 @ 0x8e67520] error while decoding MB 2 0, bytestream (36250)
[h264 @ 0x8e67520] Reference 2 >= 2
[h264 @ 0x8e67520] error while decoding MB 3 1, bytestream (16956)
[h264 @ 0x8e67520] top block unavailable for requested intra mode at 8 0
[h264 @ 0x8e67520] error while decoding MB 8 0, bytestream (10344)
[h264 @ 0x8e67520] Reference 3 >= 2
[h264 @ 0x8e67520] error while decoding MB 1 1, bytestream (8717)
[h264 @ 0x8e67520] Reference 2 >= 2
[h264 @ 0x8e67520] error while decoding MB 62 2, bytestream (8439)
[h264 @ 0x8e67520] Reference 2 >= 2
[h264 @ 0x8e67520] error while decoding MB 48 1, bytestream (9068)
[h264 @ 0x8e67520] Reference 2 >= 2
[h264 @ 0x8e67520] error while decoding MB 13 0, bytestream (33875)
[h264 @ 0x8e67520] Reference 2 >= 2
[h264 @ 0x8e67520] error while decoding MB 4 1, bytestream (17028)
[h264 @ 0x8e67520] top block unavailable for requested intra mode at 5 0
[h264 @ 0x8e67520] error while decoding MB 5 0, bytestream (11457)
[h264 @ 0x8e67520] Reference 2 >= 2
[h264 @ 0x8e67520] error while decoding MB 9 1, bytestream (11853)
[mpegts @ 0x8e63940] max_analyze_duration 5000000 reached at 5003333
Input #0, mpegts, from '00004.MTS':
  Duration: 00:02:13.66, start: 0.485833, bitrate: 6729 kb/s
  Program 1 
    Stream #0:0[0x1011]: Video: h264 (High) (HDMV / 0x564D4448), yuv420p, 1440x1
080 [SAR 4:3 DAR 16:9], 59.96 fps, 59.94 tbr, 90k tbn, 59.94 tbc
    Stream #0:1[0x1100]: Audio: ac3 (AC-3 / 0x332D4341), 48000 Hz, stereo, s16, 
256 kb/s
[h264 @ 0x8e8df00] Reference 2 >= 2q=    5KB vq=  116KB sq=    0B f=0/0   
[h264 @ 0x8e8df00] error while decoding MB 49 0, bytestream (9249)
[h264 @ 0x8e8e360] top block unavailable for requested intra mode at 21 1
[h264 @ 0x8e8e360] error while decoding MB 21 1, bytestream (7097)
[h264 @ 0x8e8e7c0] top block unavailable for requested intra4x4 mode -1 at 14 0
[h264 @ 0x8e8e7c0] error while decoding MB 14 0, bytestream (11789)
[h264 @ 0x8e66760] Reference 3 >= 2
[h264 @ 0x8e66760] error while decoding MB 10 1, bytestream (9170)
[h264 @ 0x8e8db60] top block unavailable for requested intra mode at 2 0
[h264 @ 0x8e8db60] error while decoding MB 2 0, bytestream (36250)
[h264 @ 0x8e8df00] Reference 2 >= 2
[h264 @ 0x8e8df00] error while decoding MB 3 1, bytestream (16956)
^Ctadawson @ netier3 /usr4/srclib/audiolibs <356>: 

[Carl Eugen Hoyos]

Replying to tadawson:

I am having a similar problem.

Please provide a sample.

Does h264_high_profile.h264 (the file attached to this ticket) play for you?

[Tim Dawson]

No - your attachment gives a bit of garbled still video in 10.3, 11.0 and 11.1, along with lots of errors. In the current GIT source build, I don't get the errors, but I get zero video output as well.

The ffmpeg 7, 8, and 9 builds that I referenced above display your test clip flawlessly, so it looks like this is the same problem. Let me see if I can find/create something small enough to upload as a secondary test case.

Upload created. It was a challenge getting anything small enough to allow the upload, but it's there. Again, this renders flawlessly in ffmpeg9 and below, and dies ugly in 10 and above . . .

I use ffplay as an example, but attempts to recode with ffmpeg give the same result, and the newest mplayer, based on ffmpeg 10.2 has the same exact behavior, rendering it unusable.

[Tim Dawson]

Vidio from Caon HF-R300 that runs fine in ffmpeg 9 and below, dies above.

[Tim Dawson]

Interestingly, .MP4 files fail in the same way from this device - again, with a compile in the same environment, they are OK in 7, 8, and 9 . . .

Sample uploaded. Well, I would have . . . with video, the max file size on this site limits to 1 second or so clips. I will resample MP4 and upload on request.

Interestingly, the ffmpeg 10 build is the closest on this - distorted, but visible. On 11.any (including current GIT pull), video is not identifiable.

I'd upload one of my static builds, but again, too big . . .

• Tim

[Ian McIntosh]

What is outstanding here is to complete the git bisect task to attempt to narrow down the problem to a specific commit. Unfortunately I have not had much time to look at this and so haven't made much headway.

[Carl Eugen Hoyos]

Replying to tadawson:

I will upload on request.

​http://ffmpeg.org/bugreports.html
(Feel free to ignore the size limit if you believe a longer sample is useful.)

[Tim Dawson]

Replying to cehoyos:

Replying to tadawson:

I will upload on request.

​http://ffmpeg.org/bugreports.html
(Feel free to ignore the size limit if you believe a longer sample is useful.)

I tried - the limit is hard, and the upload fails.

• Tim

[Carl Eugen Hoyos]

Replying to tadawson:

​http://ffmpeg.org/bugreports.html
(Feel free to ignore the size limit if you believe a longer sample is useful.)

I tried - the limit is hard, and the upload fails.

Please read ​http://ffmpeg.org/bugreports.html (there is no limit)

[Carl Eugen Hoyos]

Replying to tadawson:

I am having a similar problem. To test, I have static builds of ffmpeg 0.7.12, 0.8.12, 0.9.2, 0.10.3, and 0.11, as well as libav 8-something, all build at basically the same time, with the same options, in the same environment.

Could you test current git head? Your sample works fine here...
Which CPU (and OS) are you using?
Does --disable-asm / --disable-yasm / --disable-optimizations make a difference?

[Tim Dawson]

The current GIT head as of about 5 hours ago, also failed . . .

ffplay version N-42169-g6ea973f Copyright (c) 2003-2012 the FFmpeg developers

built on Jul 3 2012 16:20:24 with gcc 4.2.4

If there is more current, I can retest.

Platform is AMD Phenom(tm) II X4 940 Processor

OS started as Slackware 12.1 - I have been evolving it myself ever since, since I have not been particularly happy with any particular distro. I can provide lib versions of anything you may want to know . . . libc is 2.7, gcc is 4.2.4, kernel is 2.6.37.6, video is nVidia 9800GT cards (two) with nVidia drivers - I have tried from 175.x to the current 302.x, with no change.

I uploaded (to the ftp server - missed that, just saw how to cut a file down) both the MP4 sample that fails, as well as my compile of the GIT head detailed above of ffmplay. It was compiled with no additional libs, so is pretty clean, and hopefully can run for test on your systems.

I will also try the options you listed above . . . results in a moment.

[Tim Dawson]

Test of GIT referenced above with suggested options is different, but still not viable. The initial image renders cleanly (a first) and the cli output appears to be running, but the video is static . . . nothing past the first frame.

Output of test:

ffplay version N-42169-g6ea973f Copyright (c) 2003-2012 the FFmpeg developers
  built on Jul  4 2012 00:49:16 with gcc 4.2.4
  configuration: --prefix=/usr/local/ffmpeg-GIT --disable-asm --disable-yasm --disable-optimizations
  libavutil      51. 63.100 / 51. 63.100
  libavcodec     54. 32.100 / 54. 32.100
  libavformat    54. 14.100 / 54. 14.100
  libavdevice    54.  0.100 / 54.  0.100
  libavfilter     3.  0.101 /  3.  0.101
  libswscale      2.  1.100 /  2.  1.100
  libswresample   0. 15.100 /  0. 15.100
Input #0, mpegts, from '/Images/AVCHD/canon_avchs_ffmpeg.mts':
  Duration: 00:00:01.50, start: 0.471211, bitrate: 7281 kb/s
  Program 1 
    Stream #0:0[0x1011]: Video: h264 (High) (HDMV / 0x564D4448), yuv420p, 1440x1080 [SAR 4:3 DAR 16:9], 59.96 fps, 59.94 tbr, 90k tbn, 59.94 tbc
    Stream #0:1[0x1100]: Audio: ac3 (AC[45]3 / 0x332D4341), 48000 Hz, stereo, s16, 256 kb/s
Frame changed from size:0x0 to size:1440x1080B vq=  264KB sq=    0B f=0/0  
[ffplay_buffer @ 0x8e0ffb0] w:1440 h:1080 pixfmt:yuv420p tb:1/90000 fr:0/1 sar:4/3 sws_param:
[ffplay_buffersink @ 0x8e111b0] No opaque field provided

ldd output for the binary:

tadawson @ netier3 /usr/local/ffmpeg-GIT/bin <75>: ldd ffplay

linux-gate.so.1 => (0xffffe000)
libjack.so.0 => /usr/local/lib/libjack.so.0 (0xb77d0000)
libasound.so.2 => /usr/X11R6/lib/libasound.so.2 (0xb76c0000)
libSDL-1.2.so.0 => /usr/X11R6/lib/libSDL-1.2.so.0 (0xb760b000)
libpthread.so.0 => /lib/libpthread.so.0 (0xb75f4000)
libm.so.6 => /lib/libm.so.6 (0xb75ce000)
libbz2.so.1 => /lib/libbz2.so.1 (0xb75bc000)
libz.so.1 => /usr/X11R6/lib/libz.so.1 (0xb75a8000)
librt.so.1 => /lib/librt.so.1 (0xb759f000)
libc.so.6 => /lib/libc.so.6 (0xb7453000)
libstdc++.so.6 => /usr/X11R6/lib/libstdc++.so.6 (0xb736d000)
libdl.so.2 => /lib/libdl.so.2 (0xb7369000)
libgcc_s.so.1 => /usr/X11R6/lib/libgcc_s.so.1 (0xb735d000)
libX11.so.6 => /usr/X11R6/lib/libX11.so.6 (0xb7276000)
libXext.so.6 => /usr/X11R6/lib/libXext.so.6 (0xb7268000)
libXrandr.so.2 => /usr/X11R6/lib/libXrandr.so.2 (0xb7262000)
libXrender.so.1 => /usr/X11R6/lib/libXrender.so.1 (0xb725a000)
libvga.so.1 => /usr/X11R6/lib/libvga.so.1 (0xb71dd000)
/lib/ld-linux.so.2 (0xb780f000)
libxcb-xlib.so.0 => /usr/X11R6/lib/libxcb-xlib.so.0 (0xb71db000)
libxcb.so.1 => /usr/X11R6/lib/libxcb.so.1 (0xb71c4000)
libXau.so.6 => /usr/X11R6/lib/libXau.so.6 (0xb71c1000)
libXdmcp.so.6 => /usr/X11R6/lib/libXdmcp.so.6 (0xb71bc000)

This doesn't appear to use much that is codec/video related, but if there is anything that might have an impact, please identify it, and I'll see if I can update. Most appears to be just X libs, though, which are not easily changed . . .

• Tim

[Carl Eugen Hoyos]

Replying to tadawson:

Test of GIT referenced above with suggested options is different, but still not viable. The initial image renders cleanly (a first) and the cli output appears to be running, but the video is static . . . nothing past the first frame.

Try -an

[Tim Dawson]

Better - that runs cleanly for about 4 seconds and then freezes. The video is clean until the freeze also.

• Tim

[Carl Eugen Hoyos]

Replying to tadawson:

Better - that runs cleanly for about 4 seconds

and then freezes.

-an -autoexit

Please find out now which of
--disable-asm / --disable-sse / --disable-yasm / --disable-optimizations
is responsible for fixing the issue. (I don't have an AMD cpu here so I cannot find out.)
(Please do not upload binaries to incoming except when specifically asked.)

[Tim Dawson]

I will check. Does the functionality with the "-an" indicate a problem with audio? If so, any suggestions? I have been running ALSA, at a pretty recent level . . .

And sorry about the binary - I (mistakenly) thought it might be useful . . . .

• Tim

[Tim Dawson]

--disable-asm is the ticket.

With that set, my video runs cleanly, as does the clip from the other gentleman who opened this ticket.

I do note that my yasm install was at 1.0.2, vs. the current 1.2.0, so am updating that and will recompile to see if there is any effect.

[Carl Eugen Hoyos]

Replying to tadawson:

I will check. Does the functionality with the "-an" indicate a problem with audio? If so, any suggestions? I have been running ALSA, at a pretty recent level . . .

--disable-.... makes the binary so slow that A/V sync cannot be kept anymore, -an disables audio and dropping frames

And sorry about the binary - I (mistakenly) thought it might be useful . . . .

Don't worry!

[Carl Eugen Hoyos]

Could you test if one of those makes a difference (without --disable-asm)?
--disable-amd3dnow
--disable-amd3dnowext
--disable-sse
--disable-ssse3
--disable-avx
(don't know if the last two make a difference on a Phenom)

[Carl Eugen Hoyos]

Am I correct that you can also reproduce the issue with
$ ffmpeg -i canon_avchs_ffmpeg.mts -ss 2 out.png
?
(Problems should normally be reported against ffmpeg because ffplay depends on an external library that is known to contain bugs - this makes no difference in this case, but I want to make sure we have a ffmpeg-only test-case.)

[Tim Dawson]

Thanks. But yet again, the older versions appear to handle the stream with the audio running . . . there must be something else that changed, considering that this isn't exactly a slow system. I didn't mention clock speed, but it's quad 3GHz cores, and 3GB RAM . . . not exactly light . . .

Oh, and the yasm change made no difference. I may take binutils up to .22 from .18 for fun, but don't anticipate any positive impact there either. I am also recompiling 11.1 and 10.3 with --disable-asm since I need at least 10.3 (or 10.4 . . ) for software compatibility.

• Tim

[Tim Dawson]

I'll also gladly run the other tests - it's only about 2 mins per compile, and it's only sleep, and progress is good.

And yes, at least with the GIT head versions, ffmpeg has the same issue, and clears with the same compile flag change.

• Tim

[Carl Eugen Hoyos]

Replying to tadawson:

Thanks. But yet again, the older versions appear to handle the stream with the audio running . . .

Even if you compile the old version with --disable-asm --disable-yasm --disable-optimizations ?
(It is possible that with a sufficiently old version, no frames are dropped at the cost of horrible A/V-desync.)

[Tim Dawson]

Without any changes, the old version will run this video . . . I have seen sometimes that it may lose sync with the stream a minute or two in, but it is very clean up until that point. I have not tried setting the flags on the old stuff at this point, since they are not really in use - they were build as a test case for my build environment to submit this bug - I figured that if it was my environment, it should affect all . . . I had not planned to make any changes in the older compiles, but can if you like.

And for what it is worth, my CPU(s) basically sit idle while these play . . . if there is a system load issue, it isn't in the CPUs . . .

• Tim

[Tim Dawson]

Note: The older version is much smoother with -an . . . so the audio stream may be a factor, although I would not think that would be much overhead vs. video.

Any suggestions?

[Tim Dawson]

Additional note: 10.3 is somewhat noisy with the --disable-asm, but runs the video. Some pixelation . . .

[Carl Eugen Hoyos]

Replying to tadawson:

Any suggestions?

Please test the following configure options (without anything else, especially not with --disable-asm) with current git head: (as said, I cannot test, and the ticket is already open for some time, so if you want to help...)
--disable-amd3dnow
--disable-amd3dnowext
--disable-sse
--disable-ssse3
--disable-avx
(don't know if the last two make a difference on a Phenom)

[Carl Eugen Hoyos]

Replying to tadawson:

Additional note: 10.3 is somewhat noisy with the --disable-asm, but runs the video. Some pixelation . . .

I am not sure I understand: With 0.11 and current git head, the video does not play with ./configure && make, but with ./configure --disable-asm && make, but with 0.10, the video neither plays with --disable-asm nor without?

[Tim Dawson]

I tried the other optimization disables, and no joy - still broken. Note that I added a few libs back that are in my normal build, but all was good with --disable-asm alone, even in that config.

tadawson @ netier3 /Images/AVCHD <218>: /usr/local/ff*GIT/bin/ffplay -an 0000>
ffplay version N-42169-g6ea973f Copyright (c) 2003-2012 the FFmpeg developers

built on Jul 4 2012 02:34:26 with gcc 4.2.4
configuration: --disable-amd3dnow --disable-amd3dnowext --disable-sse --disable-ssse3 --disable-avx --enable-libmp3lame --enable-libx264 --enable-gpl --enable-libfaac --enable-nonfree --prefix=/usr/local/ffmpeg-GIT
libavutil 51. 63.100 / 51. 63.100
libavcodec 54. 32.100 / 54. 32.100
libavformat 54. 14.100 / 54. 14.100
libavdevice 54. 0.100 / 54. 0.100
libavfilter 3. 0.101 / 3. 0.101
libswscale 2. 1.100 / 2. 1.100
libswresample 0. 15.100 / 0. 15.100
libpostproc 52. 0.100 / 52. 0.100

[h264 @ 0x8eb74c0] left block unavailable for requested intra mode at 0 7
[h264 @ 0x8eb74c0] error while decoding MB 0 7, bytestream (23225)
[h264 @ 0x8eb74c0] top block unavailable for requested intra mode at 46 0
[h264 @ 0x8eb74c0] error while decoding MB 46 0, bytestream (9197)
[h264 @ 0x8eb74c0] top block unavailable for requested intra mode at 21 1
[h264 @ 0x8eb74c0] error while decoding MB 21 1, bytestream (7097)
[h264 @ 0x8eb74c0] top block unavailable for requested intra4x4 mode -1 at 14 0
[h264 @ 0x8eb74c0] error while decoding MB 14 0, bytestream (11789)

[Tim Dawson]

Replying to cehoyos:

Replying to tadawson:

Additional note: 10.3 is somewhat noisy with the --disable-asm, but runs the video. Some pixelation . . .

I am not sure I understand: With 0.11 and current git head, the video does not play with ./configure && make, but with ./configure --disable-asm && make, but with 0.10, the video neither plays with --disable-asm nor without?

Let me clarify: Most of my testing is being done with the current GIT head. With --disable-asm alone, things work with that build. With the other changes you asked to test, the GIT head continues to fail - no different than when we started - output is one update above.

The 11.1 release also works once --disable-asm is added to the build - it also failed prior.

The 10.4 release also works once --disable-asm is added to the build - it also failed prior.

To get any video output past frame 1 in 11.1, 10.4, and the GIT head, I need to use the "-an" flag. For 0.9, 0.8, and 0.7, video may get a bit stuttery, but always outputs with audio.

The 0.9 0.8 and 0.7 releases never failed, so I have not tested with --disable-asm. They may have been a bit jerky in output at times, but the stream always output.

[Tim Dawson]

Not that I was expecting a change, but an uplift to binutils 2.22 from 2.18 (new as, for what it's worth) has had no effect.

[Carl Eugen Hoyos]

You could also test --disable-mmx and --disable-mmx2

[Tim Dawson]

Still fails:

tadawson @ netier3 /Images/AVCHD <266>: /usr/local/ffmpeg-GIT/bin/ffplay -an >
ffplay version N-42169-g6ea973f Copyright (c) 2003-2012 the FFmpeg developers
  built on Jul  4 2012 03:41:04 with gcc 4.2.4
  configuration: --disable-mmx --disable-mmx2 --disable-amd3dnow --disable-amd3dnowext --disable-sse --disable-ssse3 --disable-avx --enable-libmp3lame --enable-libx264 --enable-gpl --enable-libfaac --enable-nonfree --prefix=/usr/local/ffmpeg-GIT
  libavutil      51. 63.100 / 51. 63.100
  libavcodec     54. 32.100 / 54. 32.100
  libavformat    54. 14.100 / 54. 14.100
  libavdevice    54.  0.100 / 54.  0.100
  libavfilter     3.  0.101 /  3.  0.101
  libswscale      2.  1.100 /  2.  1.100
  libswresample   0. 15.100 /  0. 15.100
  libpostproc    52.  0.100 / 52.  0.100
[h264 @ 0x8dfc4c0] Reference 6 >= 2
[h264 @ 0x8dfc4c0] error while decoding MB 26 0, bytestream (9273)
[h264 @ 0x8dfc4c0] top block unavailable for requested intra mode at 21 1
[h264 @ 0x8dfc4c0] error while decoding MB 21 1, bytestream (7097)
[h264 @ 0x8dfc4c0] top block unavailable for requested intra4x4 mode -1 at 14 0
[h264 @ 0x8dfc4c0] error while decoding MB 14 0, bytestream (11789)
[h264 @ 0x8dfc4c0] Reference 6 >= 2
[h264 @ 0x8dfc4c0] error while decoding MB 10 1, bytestream (9170)
[h264 @ 0x8dfc4c0] top block unavailable for requested intra mode at 2 0
[h264 @ 0x8dfc4c0] error while decoding MB 2 0, bytestream (36250)
[h264 @ 0x8dfc4c0] Reference 6 >= 2
[h264 @ 0x8dfc4c0] error while decoding MB 2 1, bytestream (16982)
[h264 @ 0x8dfc4c0] Reference 6 >= 2
[h264 @ 0x8dfc4c0] error while decoding MB 0 0, bytestream (10372)
[h264 @ 0x8dfc4c0] Reference 6 >= 2
[h264 @ 0x8dfc4c0] error while decoding MB 1 1, bytestream (8717)
[h264 @ 0x8dfc4c0] Reference 6 >= 2
[h264 @ 0x8dfc4c0] error while decoding MB 68 0, bytestream (8495)
[h264 @ 0x8dfc4c0] Reference 6 >= 2
[h264 @ 0x8dfc4c0] error while decoding MB 48 1, bytestream (9068)
[h264 @ 0x8dfc4c0] Reference 6 >= 2
[h264 @ 0x8dfc4c0] error while decoding MB 12 0, bytestream (33891)
[h264 @ 0x8dfc4c0] Reference 6 >= 2
[h264 @ 0x8dfc4c0] error while decoding MB 0 1, bytestream (17144)
[h264 @ 0x8dfc4c0] top block unavailable for requested intra mode at 5 0
[h264 @ 0x8dfc4c0] error while decoding MB 5 0, bytestream (11457)
[h264 @ 0x8dfc4c0] Reference 6 >= 2
[h264 @ 0x8dfc4c0] error while decoding MB 83 1, bytestream (11983)
[h264 @ 0x8dfc4c0] Reference 6 >= 2
[h264 @ 0x8dfc4c0] error while decoding MB 9 1, bytestream (11853)
[mpegts @ 0x8df8950] max_analyze_duration 5000000 reached at 5003333
Input #0, mpegts, from '00004.MTS':
  Duration: 00:02:13.66, start: 0.485833, bitrate: 6729 kb/s
  Program 1 
    Stream #0:0[0x1011]: Video: h264 (High) (HDMV / 0x564D4448), yuv420p, 1440x1080 [SAR 4:3 DAR 16:9], 59.96 fps, 59.94 tbr, 90k tbn, 59.94 tbc
    Stream #0:1[0x1100]: Audio: ac3 (AC[45]3 / 0x332D4341), 48000 Hz, stereo, s16, 256 kb/s

[Carl Eugen Hoyos]

Please use git bisect if you want to help - start with 16abd68 and a8ae00b - I tried to pm you but that failed;-(

[Tim Dawson]

Gladly. Which GIT head relates to which build? I had been starting to play with n0.10 and n0.9.2 as GIT targets, but there were 750-odd commits in that interval. And which would be the "good" and which the "bad"?

At any rate, I'll have a free day here shortly, and will try to push through this testing . . . Today is a holiday here, and if I don't spend time with my wife, I'll get killed!

Oh, and how did you try to PM?

-Tim

[reimar]

First: while finding the cause is very welcome, it is likely that just using a different compiler version will avoid the issue.
Second: Please try with "-cpuflags 0" as first option.
If that does not work, it is probably some asm code that cannot be disabled at run time, like the CABAC decoding (for that it would be interesting to know if only CABAC-encoded H.264 files are affected or also those using CAVLC).
If it does work, you can try "-cpuflags -mmx" etc. instead of having to recompile for each.

[Carl Eugen Hoyos]

Replying to tadawson:

I had been starting to play with n0.10 and n0.9.2 as GIT targets

Please start with 16abd68 and a8ae00b

[Tim Dawson]

And again, I ask . . . which it the upper and which is the lower? As I said, I'm not a GIT guru, and I seem to recall the hashes are not necessarily in order . . .

• Tim

[Tim Dawson]

-cpuflags 0 has no effect . . . still broken.

I am looking into a compiler change, but that, frankly, is not an easy thing to update. Considering that this compiler is mainstream in the Slackware distro, I find it hard to imagine it being that buggy, and this issue not being known . . . but who knows?

I'll proceed with the git bisect . . . but would still like more info on the hashes you recommend to start with . . .

[Tim Dawson]

Well, a rather lengthy session in GIT has given a specific commit where this started to fail:

8bc7fe4daf5c26555d77e2261c96ee14a800fad4 is first bad commit

bad: [8bc7fe4daf5c26555d77e2261c96ee14a800fad4] Merge remote-tracking branch 'qatar/master'

Not sure what that tells you, but that is where it started to fail!

• Tim

[Carl Eugen Hoyos]

So ffplay plays the sample correctly with c83ef63 and avplay with 58c42af ?

[Tim Dawson]

I can't speak to avplay, since that is not in this source tree, but one rev prior to the above (I cleared the bisect . . . sorry!) plays the video fine with ffplay.

[Carl Eugen Hoyos]

Replying to tadawson:

I can't speak to avplay, since that is not in this source tree

It is.
It makes a significant difference if the regression was introduced in 8bc7fe4 or earlier (the commit has more than one ancestor).

[Tim Dawson]

Sorry, just noted that avplay had been being build in some checkouts . . . I didn't test that. The fault I see was in ffplay only. I'll go rework a narrow range in bisect and see if I can find a trigger build for avplay as well.

[Tim Dawson]

OK . . . I have that threshold point identified. It was a good deal farther back in the libav branch than the initial range of GIT IDs, so it took a while . . .

f1f6d3615f3f9a81f41905ea0c8116b4985870e4 is first bad commit
commit f1f6d3615f3f9a81f41905ea0c8116b4985870e4
Author: Justin Ruggles <​justin.ruggles@gmail.com>
Date: Mon Oct 31 13:41:47 2011 -0400

avcodec: add support for planar signed 8-bit PCM.

It is found in some 8svx files (e.g. ones created by SoX).
Currently the decoder reuses the 8svx functions because we already have
handling of a single large planar packet for the compressed 8svx codecs.

:040000 040000 30ac5bb7c0ba7b971c24394d9acb9bd0ad922d43 a831fa5d537c5d5acb11c35b
fee7286cb10f8bfe M libavcodec
:040000 040000 9f82ba4704bd1dae0b8e6ff72d8f6531ca4f8c27 de94db0e842b39ffb2aa8180
db9af6dc2ea90743 M libavformat

So, to verify, a git checkout of f1f6d3615f3f9a81f41905ea0c8116b4985870e4 fails, and a git checkout of fed5ca255feacb03500a22f3fcd920cc98e9dcee works with avformat. The test with ffplay is as above - that ceased to function when the two branches were merged.

• Tim

[Carl Eugen Hoyos]

Thank you for testing!
(Unfortunately, imo, your result seems to strengthen Reimar's point that this is a tool-chain problem but maybe I am wrong.)

Unrelated: Can you reproduce the crash from ticket #1376 with ​http://samples.mplayerhq.hu/V-codecs/MPG3/mpg3.avi ?

$ ffmpeg -acodec pcm_s32le -i mpg3.avi -vn -f null -

[Tim Dawson]

I'm not sure what to say . . . This system is probably 75% compiled from source with this toolset, and everything else works . . . so, myself, I'd favor a code bug, or at the very least, an "oddity" that skirts the C standards or something . . . I have built, but not yet installed, a later compiler (gcc 4.4.7, and trying for 4.5.4 as well), so if I feel like taking a risk of bricking my build environment, I'll push that in and see if things change.

Testing the other, with the build with and without --disable-asm on the current GIT head does not crash, but isn't pretty either . . . . I'll post my output on the other ticket. ffplay with or without --disable-asm will display that avi stream reasonable well, with an occasional error or glitch.

• Tim

[Tim Dawson]

Well, no guts, no glory . . . I updated from gcc 4.2.4 to gcc 4.4.7, and recompiled, and the problem I am having with the MTS files with ffmpeg/ffplay are now resolved. I can now also run with audio, etc. and get stable, clean video . . .

The initial testcase video for this ticket is also clean with no compile flag changes with this compiler.

Not sure what the issue was, but GCC 4.2.4 should definitely be flagged as buggy with ffmpeg . . .

• Tim

[Ian McIntosh]

For what its worth, when I updated my GCC from 4.2.2 to 4.6.2 - my problems were resolved as well. So GCC 4.2.2 should probably be added to that flagged list then.

[Tim Dawson]

I have also tested gcc 4.5.4, 4.6.3, and 4.7.1, and all appear to do fine. It appears that the gcc 4.2 tree has the bug, and, ironically, was chosen as the base for some distros . .

• Tim

[kelexel]

I can confirm this working with gcc-4.6 on FreeBSD-9.
If you're using built-in gcc-4.2 (the default gcc shipped with FreeBSD) you will have errors as mentioned above.
Using 4.6, h264 decoding works perfectly.
Big ups for finding a solution to that one :)

[Carl Eugen Hoyos]

I believe this issue will not be fixed / no workarounds will be added for gcc 4.2.
I opened ticket #3970 as a feature request for configure refusing this compiler or at least print a warning.