0.7-rc1: strange colors with x11grab

[nixscripter]

I tried x11grab on the lastest version, and it seems to be separating the color channels for some reason. This worked in 0.6.

I did do an OS re-install, but I am 80% sure I have the exact same versions of X, OpenGL, etc. that I did last time.

A sample is attached, recording the top left corner, 120x80. Full screen does the same thing on a larger scale, and the frame rate I choose does not seem to matter.

[nixscripter]

ffmpeg log, output, and screenshot

[Carl Eugen Hoyos]

Please test latest git head and please add some information about your system (it works here for bgra on little endian Linux).

For future bug-reports: Please open only one ticket per problem and please add complete, uncut output of ffmpeg (including command line) to the ticket (please do not compress and attach the information if it's less than 100 lines).

[nixscripter]

I thought the log was too long to post outsize the zip file, but after specifically counting, 93 is less than 100. Likewise, I thought that release candidates were supposed to get their own testing separate from the current head. I will remember both for the future.

The git version works:

$ ffmpeg -v 9 -loglevel 99 -f x11grab -s 128x80 -r 25 -i :0.0 -b 1200k /tmp/output4.mpg
ffmpeg version git-N-30723-ge887690, Copyright (c) 2000-2011 the FFmpeg developers

built on Jun 11 2011 18:13:17 with gcc 4.6.0 20110603 (prerelease)
configuration: --enable-gpl --disable-debug --prefix=/usr --enable-x11grab --disable-stripping --disable-outdev=oss --disable-indev=oss --enable-pthreads --enable-runtime-cpudetect
libavutil 51. 8. 0 / 51. 8. 0
libavcodec 53. 7. 0 / 53. 7. 0
libavformat 53. 3. 1 / 53. 3. 1
libavdevice 53. 1. 1 / 53. 1. 1
libavfilter 2. 15. 1 / 2. 15. 1
libswscale 0. 14. 1 / 0. 14. 1
libpostproc 51. 2. 0 / 51. 2. 0

[x11grab @ 0x9d41340] device: :0.0 -> display: :0.0 x: 0 y: 0 width: 128 height: 80
[x11grab @ 0x9d41340] shared memory extension found
[x11grab @ 0x9d41340] All info found
[x11grab @ 0x9d41340] Estimating duration from bitrate, this may be inaccurate
Input #0, x11grab, from ':0.0':

Duration: N/A, start: 1307834124.519949, bitrate: 8191 kb/s

Stream #0.0, 1, 1/1000000: Video: rawvideo, bgra, 128x80, 1/25, 8191 kb/s, 25 tbr, 1000k tbn, 25 tbc

Incompatible pixel format 'bgra' for codec 'mpeg1video', auto-selecting format 'yuv420p'
[buffer @ 0x9d4d880] w:128 h:80 pixfmt:bgra tb:1/1000000 sar:0/1 sws_param:
[ffsink @ 0x9d3be80] auto-inserting filter 'auto-inserted scaler 0' between the filter 'src' and the filter 'out'
[scale @ 0x9d3bac0] w:128 h:80 fmt:bgra -> w:128 h:80 fmt:yuv420p flags:0x4
[mpeg @ 0x9d3c900] VBV buffer size not set, muxing may fail
Output #0, mpeg, to '/tmp/output4.mpg':

Metadata:

encoder : Lavf53.3.1
Stream #0.0, 0, 1/90000: Video: mpeg1video, yuv420p, 128x80, 1/25, q=2-31, 1200 kb/s, 90k tbn, 25 tbc

Stream mapping:

Stream #0.0 -> #0.0

Press [q] to stop, ? for help
frame= 15 fps= 0 q=2.0 size= 2kB time=00:00:00.56 bitrate= 29.3kbits/sframe= 28 fps= 27 q=2.0 size= 4kB time=00:00:01.08 bitrate= 30.3kbits/sframe= 41 fps= 26 q=2.0 size= 6kB time=00:00:01.60 bitrate= 30.7kbits/sframe= 54 fps= 26 q=2.0 size= 8kB time=00:00:02.12 bitrate= 30.9kbits/sframe= 67 fps= 26 q=2.0 size= 10kB time=00:00:02.64 bitrate= 31.0kbits/sframe= 80 fps= 26 q=2.0 size= 12kB time=00:00:03.16 bitrate= 31.1kbits/sframe= 93 fps= 26 q=2.0 size= 14kB time=00:00:03.68 bitrate= 31.2kbits/sframe= 106 fps= 25 q=2.0 size= 16kB time=00:00:04.20 bitrate= 31.2kbits/sframe= 119 fps= 25 q=2.0 size= 18kB time=00:00:04.72 bitrate= 31.2kbits/sframe= 132 fps= 25 q=2.0 size= 20kB time=00:00:05.24 bitrate= 31.3kbits/sframe= 145 fps= 25 q=1.6 size= 24kB time=00:00:05.76 bitrate= 34.1kbits/sframe= 158 fps= 25 q=2.0 size= 26kB time=00:00:06.28 bitrate= 33.9kbits/sframe= 159 fps= 25 q=2.0 Lsize= 28kB time=00:00:06.32 bitrate= 36.3kbits/s
video:27kB audio:0kB global headers:0kB muxing overhead 2.818619%
Received signal 2: terminating.

So I suppose this means your release canditate needs to move up a little.

When I tried bisecting quick, I got a fast answer.

The merge base 075933a0687974fca74d6d4ac388d24766d8dc78 is bad.
This means the bug has been fixed between 075933a0687974fca74d6d4ac388d24766d8dc78 and [e8876902a9021ec185ca785653067dd34f24c5ce].

[Carl Eugen Hoyos]

Could you try to find the exact version that fixed the problem?
(I currently cannot use git)

Concerning the 100 lines: I invented them because of your post, output should usually be posted (except if it is really large, in which case the top and bottom of the output should still be posted). Please consider using "Code block".

[nixscripter]

I think I have it, but I'm not positive. When I tried it at first, I got this error:

$ git bisect start 075933a0687974fca74d6d4ac388d24766d8dc78 e8876902a9021ec185ca785653067dd34f24c5ce
Switched to branch 'master'
Some good revs are not ancestor of the bad rev.
git bisect cannot work properly in this case.
Maybe you mistake good and bad revs?

So, I decided to reverse it: you want to know where the bug was fixed -- which is the same thing as were the "error regressed", in a sense.

When I switched them around -- marked the good ones bad, and bad ones good -- I got this:

d85e18e6e342bf58f8e13a95f601082e5d70803a is the first bad commit
commit d85e18e6e342bf58f8e13a95f601082e5d70803a
Author: Michael Niedermayer <​michaelni@gmx.at>
Date: Sat Apr 2 20:26:39 2011 +0200

yadif: Fix assert() failure

Signed-off-by: Anton Khirnov <​anton@khirnov.net>

:040000 040000 1aa9b67a74cf716a11fc6d6ba1d1b93e79dddb1c d4ba44f572108592e75ef66c050c400da9ff6d5e M libavfilter

I don't know if that is right or not.

[Carl Eugen Hoyos]

This is reproducible with 0.7-rc1, I was unable to find a revision in git that also fails.

[Carl Eugen Hoyos]

Fixed in all newer releases.