Opened 4 years ago

Closed 21 months ago

#1464 closed defect (wontfix)

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

Reported by: ianm Owned by:
Priority: normal Component: undetermined
Version: git-master Keywords: h264 gcc
Cc: tadawson Blocked By:
Blocking: Reproduced by developer: no
Analyzed by developer: no

Description

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

Attachments (2)

h264_high_profile.h264 (114.8 KB) - added by ianm 4 years ago.
canon_avchs_ffmpeg.mts (1.3 MB) - added by tadawson 4 years ago.
Vidio from Caon HF-R300 that runs fine in ffmpeg 9 and below, dies above.

Download all attachments as: .zip

Change History (60)

Changed 4 years ago by ianm

comment:1 Changed 4 years ago by cehoyos

  • Component changed from FFplay to undetermined
  • Keywords h264 added
  • Version changed from unspecified to git-master

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

comment:2 Changed 4 years ago by ianm

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

comment:3 Changed 4 years ago by cehoyos

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.)

comment:4 Changed 4 years ago by ianm

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.

comment:5 follow-ups: Changed 4 years ago by 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.

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>: 
Last edited 4 years ago by cehoyos (previous) (diff)

comment:6 in reply to: ↑ 5 Changed 4 years ago by cehoyos

  • Cc tadawson added

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?

comment:7 Changed 4 years ago by tadawson

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.

Last edited 4 years ago by tadawson (previous) (diff)

Changed 4 years ago by tadawson

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

comment:8 follow-up: Changed 4 years ago by tadawson

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
Last edited 4 years ago by tadawson (previous) (diff)

comment:9 Changed 4 years ago by ianm

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.

comment:10 in reply to: ↑ 8 ; follow-up: Changed 4 years ago by 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.)

comment:11 in reply to: ↑ 10 ; follow-up: Changed 4 years ago by tadawson

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

comment:12 in reply to: ↑ 11 Changed 4 years ago by cehoyos

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)

comment:13 in reply to: ↑ 5 Changed 4 years ago by cehoyos

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?

comment:14 Changed 4 years ago by tadawson

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.

comment:15 follow-up: Changed 4 years ago by 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.

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
Version 0, edited 4 years ago by tadawson (next)

comment:16 in reply to: ↑ 15 Changed 4 years ago by cehoyos

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

comment:17 follow-up: Changed 4 years ago by tadawson

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

  • Tim

comment:18 in reply to: ↑ 17 Changed 4 years ago by cehoyos

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.)

comment:19 follow-up: Changed 4 years ago by 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 . . .

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

  • Tim

comment:20 Changed 4 years ago by tadawson

--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.

comment:21 in reply to: ↑ 19 Changed 4 years ago by cehoyos

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!

comment:22 Changed 4 years ago by cehoyos

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)

comment:23 Changed 4 years ago by cehoyos

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.)

comment:24 follow-up: Changed 4 years ago by tadawson

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

comment:25 Changed 4 years ago by tadawson

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

comment:26 in reply to: ↑ 24 Changed 4 years ago by cehoyos

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.)

comment:27 Changed 4 years ago by tadawson

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

comment:28 follow-up: Changed 4 years ago by tadawson

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?

comment:29 follow-up: Changed 4 years ago by tadawson

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

comment:30 in reply to: ↑ 28 Changed 4 years ago by cehoyos

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)

comment:31 in reply to: ↑ 29 ; follow-up: Changed 4 years ago by 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?

comment:32 Changed 4 years ago by tadawson

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)

comment:33 in reply to: ↑ 31 Changed 4 years ago by tadawson

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.

comment:34 Changed 4 years ago by tadawson

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.

comment:35 Changed 4 years ago by cehoyos

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

comment:36 Changed 4 years ago by tadawson

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
Last edited 4 years ago by cehoyos (previous) (diff)

comment:37 Changed 4 years ago by cehoyos

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

comment:38 follow-up: Changed 4 years ago by tadawson

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

Last edited 4 years ago by tadawson (previous) (diff)

comment:39 Changed 4 years ago by tadawson

Last edited 4 years ago by tadawson (previous) (diff)

comment:40 Changed 4 years ago by 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.

Last edited 4 years ago by reimar (previous) (diff)

comment:41 in reply to: ↑ 38 Changed 4 years ago by cehoyos

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

comment:42 Changed 4 years ago by tadawson

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

comment:43 Changed 4 years ago by tadawson

-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 . . .

comment:44 Changed 4 years ago by tadawson

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

comment:45 Changed 4 years ago by cehoyos

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

comment:46 follow-up: Changed 4 years ago by tadawson

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.

comment:47 in reply to: ↑ 46 Changed 4 years ago by cehoyos

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).

comment:48 Changed 4 years ago by tadawson

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.

comment:49 Changed 4 years ago by tadawson

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 avplay. The test with ffplay is as above - that ceased to function when the two branches were merged.

  • Tim
Last edited 4 years ago by tadawson (previous) (diff)

comment:50 Changed 4 years ago by cehoyos

  • Status changed from new to open

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 -

comment:51 Changed 4 years ago by tadawson

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
Last edited 4 years ago by tadawson (previous) (diff)

comment:52 Changed 4 years ago by tadawson

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
Last edited 4 years ago by tadawson (previous) (diff)

comment:53 Changed 4 years ago by ianm

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.

comment:54 Changed 4 years ago by tadawson

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

comment:55 Changed 4 years ago by michael

  • Summary changed from FFplay regression with H264 high profile input to FFplay regression with H264 high profile input (gcc 4.2.* specific)

comment:56 Changed 4 years ago by 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 :)

comment:57 Changed 21 months ago by cehoyos

  • Keywords gcc added

comment:58 Changed 21 months ago by cehoyos

  • Resolution set to wontfix
  • Status changed from open to closed

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.

Note: See TracTickets for help on using tickets.