Recent builds regression bug - KO from 12th Feb 2013 - OK before

[feelart]

Regression bug - recent builds issue - KO from 12th Feb 2013 - OK before

Execution on latest build (no error reported), creates an improprer video

E:\data\Skills\ITC How to\FFmpeg & Lame>ffmpeg.exe -y -loop 1 -f image2 -i Masque16_9.png -vcodec libx264 -t 4 -r 25 x264M
ask25FPS.mp4
ffmpeg version N-50515-g28adecf Copyright (c) 2000-2013 the FFmpeg developers
  built on Mar  6 2013 00:35:40 with gcc 4.7.2 (GCC)
  configuration: --enable-gpl --enable-version3 --disable-w32threads --enable-avisynth --enable-bzlib --enable-fontconfig
--enable-frei0r --enable-gnutls --enable-libass --enable-libbluray --enable-libcaca --enable-libfreetype --enable-libgsm -
-enable-libilbc --enable-libmp3lame --enable-libopencore-amrnb --enable-libopencore-amrwb --enable-libopenjpeg --enable-li
bopus --enable-librtmp --enable-libschroedinger --enable-libsoxr --enable-libspeex --enable-libtheora --enable-libtwolame
--enable-libvo-aacenc --enable-libvo-amrwbenc --enable-libvorbis --enable-libvpx --enable-libx264 --enable-libxavs --enabl
e-libxvid --enable-zlib
  libavutil      52. 17.103 / 52. 17.103
  libavcodec     54. 92.100 / 54. 92.100
  libavformat    54. 63.103 / 54. 63.103
  libavdevice    54.  3.103 / 54.  3.103
  libavfilter     3. 42.103 /  3. 42.103
  libswscale      2.  2.100 /  2.  2.100
  libswresample   0. 17.102 /  0. 17.102
  libpostproc    52.  2.100 / 52.  2.100
[image2 @ 000000000036d980] max_analyze_duration 5000000 reached at 5000000 microseconds
Input #0, image2, from 'Masque16_9.png':
  Duration: 00:00:00.04, start: 0.000000, bitrate: N/A
    Stream #0:0: Video: png, rgba, 1120x630 [SAR 2835:2835 DAR 16:9], 25 fps, 25 tbr, 25 tbn, 25 tbc
[libx264 @ 000000000036f560] using SAR=1/1
[libx264 @ 000000000036f560] using cpu capabilities: MMX2 SSE2Fast SSSE3 FastShuffle SSE4.2 AVX
[libx264 @ 000000000036f560] profile High 4:4:4 Predictive, level 3.1, 4:4:4 8-bit
[libx264 @ 000000000036f560] 264 - core 129 r2245 bc13772 - H.264/MPEG-4 AVC codec - Copyright 2003-2013 - http://www.vide
olan.org/x264.html - options: cabac=1 ref=3 deblock=1:0:0 analyse=0x3:0x113 me=hex subme=7 psy=1 psy_rd=1.00:0.00 mixed_re
f=1 me_range=16 chroma_me=1 trellis=1 8x8dct=1 cqm=0 deadzone=21,11 fast_pskip=1 chroma_qp_offset=4 threads=6 lookahead_th
reads=1 sliced_threads=0 nr=0 decimate=1 interlaced=0 bluray_compat=0 constrained_intra=0 bframes=3 b_pyramid=2 b_adapt=1
b_bias=0 direct=1 weightb=1 open_gop=0 weightp=2 keyint=250 keyint_min=25 scenecut=40 intra_refresh=0 rc_lookahead=40 rc=c
rf mbtree=1 crf=23.0 qcomp=0.60 qpmin=0 qpmax=69 qpstep=4 ip_ratio=1.40 aq=1:1.00
Output #0, mp4, to 'x264Mask25FPS.mp4':
  Metadata:
    encoder         : Lavf54.63.103
    Stream #0:0: Video: h264 ([33][0][0][0] / 0x0021), yuv444p, 1120x630 [SAR 1:1 DAR 16:9], q=-1--1, 12800 tbn, 25 tbc
Stream mapping:
  Stream #0:0 -> #0:0 (png -> libx264)
Press [q] to stop, [?] for help
frame=  100 fps= 67 q=-1.0 Lsize=      32kB time=00:00:03.92 bitrate=  67.3kbits/s
video:30kB audio:0kB subtitle:0 global headers:0kB muxing overhead 6.446302%
[libx264 @ 000000000036f560] frame I:1     Avg QP:19.50  size: 23349
[libx264 @ 000000000036f560] frame P:25    Avg QP:23.09  size:   106
[libx264 @ 000000000036f560] frame B:74    Avg QP:31.85  size:    58
[libx264 @ 000000000036f560] consecutive B-frames:  1.0%  0.0%  3.0% 96.0%
[libx264 @ 000000000036f560] mb I  I16..4: 86.4%  4.7%  9.0%
[libx264 @ 000000000036f560] mb P  I16..4:  0.3%  0.1%  0.0%  P16..4:  0.6%  0.0%  0.0%  0.0%  0.0%    skip:99.0%
[libx264 @ 000000000036f560] mb B  I16..4:  0.2%  0.0%  0.0%  B16..8:  0.7%  0.0%  0.0%  direct: 0.0%  skip:99.1%  L0:46.6
% L1:53.4% BI: 0.0%
[libx264 @ 000000000036f560] 8x8 transform intra:5.9% inter:57.0%
[libx264 @ 000000000036f560] coded y,u,v intra: 4.2% 4.1% 4.1% inter: 0.0% 0.0% 0.0%
[libx264 @ 000000000036f560] i16 v,h,dc,p: 63% 37%  0%  0%
[libx264 @ 000000000036f560] i8 v,h,dc,ddl,ddr,vr,hd,vl,hu: 25%  2% 73%  0%  0%  0%  0%  0%  0%
[libx264 @ 000000000036f560] i4 v,h,dc,ddl,ddr,vr,hd,vl,hu: 35% 33% 15%  2%  3%  3%  3%  3%  3%
[libx264 @ 000000000036f560] Weighted P-Frames: Y:0.0% UV:0.0%
[libx264 @ 000000000036f560] ref P L0: 28.8% 12.7% 52.9%  5.6%
[libx264 @ 000000000036f560] ref B L0: 67.2% 31.5%  1.4%
[libx264 @ 000000000036f560] ref B L1: 96.0%  4.0%
[libx264 @ 000000000036f560] kb/s:60.50

E:\data\Skills\ITC How to\FFmpeg & Lame>

Now the output video x264Mask25FPS.mp4 can NOT be played by a number of players, namely SMPlayer 0.8, Windows Media Player.
But it can with VLC 2.05

If using build ffmpeg-20130209-git-969039e-win64-static (or earlier), video x264Mask25FPS.mp4 can be played with all players

Note changing video codec to mpeg4, does not create the bug.

Note what about ticket 2289?

[feelart]

Should it be useful, Smplayer log crash

[Carl Eugen Hoyos]

Please provide the complete, uncut console output for a working encoding or add "-pix_fmt yuv420p" to your command line.

[feelart]

Here you are

E:\data\Skills\ITC How to\FFmpeg & Lame>ffmpeg.exe -y -loop 1 -f image2 -i Masque16_9.png -vcodec libx264 -t 4 -r 25 -pix_
fmt yuv420p x264Mask25FPS.mp4
ffmpeg version N-50515-g28adecf Copyright (c) 2000-2013 the FFmpeg developers
  built on Mar  6 2013 00:35:40 with gcc 4.7.2 (GCC)
  configuration: --enable-gpl --enable-version3 --disable-w32threads --enable-avisynth --enable-bzlib --enable-fontconfig
--enable-frei0r --enable-gnutls --enable-libass --enable-libbluray --enable-libcaca --enable-libfreetype --enable-libgsm -
-enable-libilbc --enable-libmp3lame --enable-libopencore-amrnb --enable-libopencore-amrwb --enable-libopenjpeg --enable-li
bopus --enable-librtmp --enable-libschroedinger --enable-libsoxr --enable-libspeex --enable-libtheora --enable-libtwolame
--enable-libvo-aacenc --enable-libvo-amrwbenc --enable-libvorbis --enable-libvpx --enable-libx264 --enable-libxavs --enabl
e-libxvid --enable-zlib
  libavutil      52. 17.103 / 52. 17.103
  libavcodec     54. 92.100 / 54. 92.100
  libavformat    54. 63.103 / 54. 63.103
  libavdevice    54.  3.103 / 54.  3.103
  libavfilter     3. 42.103 /  3. 42.103
  libswscale      2.  2.100 /  2.  2.100
  libswresample   0. 17.102 /  0. 17.102
  libpostproc    52.  2.100 / 52.  2.100
[image2 @ 000000000212a400] max_analyze_duration 5000000 reached at 5000000 microseconds
Input #0, image2, from 'Masque16_9.png':
  Duration: 00:00:00.04, start: 0.000000, bitrate: N/A
    Stream #0:0: Video: png, rgba, 1120x630 [SAR 2835:2835 DAR 16:9], 25 fps, 25 tbr, 25 tbn, 25 tbc
[libx264 @ 000000000212f7c0] using SAR=1/1
[libx264 @ 000000000212f7c0] using cpu capabilities: MMX2 SSE2Fast SSSE3 FastShuffle SSE4.2 AVX
[libx264 @ 000000000212f7c0] profile High, level 3.1
[libx264 @ 000000000212f7c0] 264 - core 129 r2245 bc13772 - H.264/MPEG-4 AVC codec - Copyright 2003-2013 - http://www.vide
olan.org/x264.html - options: cabac=1 ref=3 deblock=1:0:0 analyse=0x3:0x113 me=hex subme=7 psy=1 psy_rd=1.00:0.00 mixed_re
f=1 me_range=16 chroma_me=1 trellis=1 8x8dct=1 cqm=0 deadzone=21,11 fast_pskip=1 chroma_qp_offset=-2 threads=6 lookahead_t
hreads=1 sliced_threads=0 nr=0 decimate=1 interlaced=0 bluray_compat=0 constrained_intra=0 bframes=3 b_pyramid=2 b_adapt=1
 b_bias=0 direct=1 weightb=1 open_gop=0 weightp=2 keyint=250 keyint_min=25 scenecut=40 intra_refresh=0 rc_lookahead=40 rc=
crf mbtree=1 crf=23.0 qcomp=0.60 qpmin=0 qpmax=69 qpstep=4 ip_ratio=1.40 aq=1:1.00
Output #0, mp4, to 'x264Mask25FPS.mp4':
  Metadata:
    encoder         : Lavf54.63.103
    Stream #0:0: Video: h264 ([33][0][0][0] / 0x0021), yuv420p, 1120x630 [SAR 1:1 DAR 16:9], q=-1--1, 12800 tbn, 25 tbc
Stream mapping:
  Stream #0:0 -> #0:0 (png -> libx264)
Press [q] to stop, [?] for help
frame=  100 fps= 71 q=-1.0 Lsize=      29kB time=00:00:03.92 bitrate=  60.8kbits/s
video:27kB audio:0kB subtitle:0 global headers:0kB muxing overhead 7.184745%
[libx264 @ 000000000212f7c0] frame I:1     Avg QP:18.91  size: 21105
[libx264 @ 000000000212f7c0] frame P:25    Avg QP:24.26  size:    68
[libx264 @ 000000000212f7c0] frame B:74    Avg QP:31.25  size:    57
[libx264 @ 000000000212f7c0] consecutive B-frames:  1.0%  0.0%  3.0% 96.0%
[libx264 @ 000000000212f7c0] mb I  I16..4: 87.2%  3.8%  9.0%
[libx264 @ 000000000212f7c0] mb P  I16..4:  0.4%  0.0%  0.0%  P16..4:  0.2%  0.0%  0.0%  0.0%  0.0%    skip:99.4%
[libx264 @ 000000000212f7c0] mb B  I16..4:  0.1%  0.0%  0.0%  B16..8:  1.1%  0.0%  0.0%  direct: 0.0%  skip:98.8%  L0:75.6
% L1:24.4% BI: 0.0%
[libx264 @ 000000000212f7c0] 8x8 transform intra:4.6% inter:15.0%
[libx264 @ 000000000212f7c0] coded y,uvDC,uvAC intra: 4.4% 8.3% 8.1% inter: 0.0% 0.0% 0.0%
[libx264 @ 000000000212f7c0] i16 v,h,dc,p: 70% 30%  0%  0%
[libx264 @ 000000000212f7c0] i8 v,h,dc,ddl,ddr,vr,hd,vl,hu: 49%  5% 46%  0%  0%  0%  0%  0%  0%
[libx264 @ 000000000212f7c0] i4 v,h,dc,ddl,ddr,vr,hd,vl,hu: 36% 32% 14%  2%  3%  3%  3%  3%  3%
[libx264 @ 000000000212f7c0] i8c dc,h,v,p: 57% 35%  8%  0%
[libx264 @ 000000000212f7c0] Weighted P-Frames: Y:0.0% UV:0.0%
[libx264 @ 000000000212f7c0] ref P L0: 38.2%  3.2% 51.4%  7.3%
[libx264 @ 000000000212f7c0] ref B L0: 24.7% 74.7%  0.6%
[libx264 @ 000000000212f7c0] ref B L1: 97.8%  2.2%
[libx264 @ 000000000212f7c0] kb/s:54.13

E:\data\Skills\ITC How to\FFmpeg & Lame>

[feelart]

Interesting, for builds after 9th Feb, by adding -pix_fmt yuv420p, the output video is not improperly closed, previous builds have no such issue

[Carl Eugen Hoyos]

Replying to feelart:

Interesting, for builds after 9th Feb, by adding -pix_fmt yuv420p, the output video is not improperly closed, previous builds have no such issue

Sorry, I do not understand: Does it work as expected with -pix_fmt yuv420p or is there still a problem? If it does not work, please provide the command line with -pix_fmt yuv420p together with the console output.

[Carl Eugen Hoyos]

Regarding your original problem (that the output has changed between two versions of the binary you downloaded): To the best of my knowledge, there was no change in FFmpeg (yuv444p x264 output is supported since a long time), but the x264 compilation options have changed, it now supports yuv444p encoding, it didn't before.

[feelart]

Well it does work with -pix_fmt yuv420p (I don't understand what it means/does), but rather nasty because no error or warning is raised without it and dependent of the player, you might play or not the video

but the x264 compilation options have changed

Then it is like recently closed ticket 2284, and I do experience other problems with recent builds & x264, vs builds ante 9th Feb 2013.

[Carl Eugen Hoyos]

Replying to feelart:

Well it does work with -pix_fmt yuv420p (I don't understand what it means/does),

The playback applications you were testing (except vlc) only implement a very small part of the h264 specification. I believe there is no application that implements the whole specification, but yuv444p works fine with all FFmpeg-based players like MPlayer and vlc.
FFmpeg tries to loose as little quality as possible (since you did not specify anything else on the command line) and the best yuv-based colour-space that relates to your input colour space - rgba - would be yuva444p. Since x264 does not support encoding transparency, yuv444p is chosen.

but rather nasty because no error or warning is raised without it and dependent of the player, you might play or not the video

What kind of warning could be shown?
If you know that you are going to play your output file on players that only support yuv420p, specify that on the command line.

but the x264 compilation options have changed

(note that this was of course only a guess, this is not the Zeranoe-support forum, I don't know how the binaries are compiled. If you have special needs, like compilation of x264 without support for anything else than yuv420p, it is strongly recommended that you compile yourself.)

Then it is like recently closed ticket 2284

Remember that this was not a FFmpeg-related ticket.

and I do experience other problems with recent builds & x264, vs builds ante 9th Feb 2013.

Please report all bugs that you experience with FFmpeg, but please remember that this is not a support forum, see ​http://ffmpeg.org/contact.html

[feelart]

I think there is a miss-understanding.

It reveals bugs that I and other experienced.
Indeed

If all that changed is compiler (gcc 4.7.2) options then it reveals is a deaper problem, and that's good.

Proof

C:\PortableApps\MM\FFmpeg_regression\ffmpeg-20130209-git-969039e-win64-static\ffmpeg.exe -y -loop 1 -f image2 -i Masque16_9.png -vcodec libx264 -t 4 -r 25 outNoPix20130209.mp4
C:\PortableApps\MM\FFmpeg_regression\ffmpeg-20130209-git-969039e-win64-static\ffmpeg.exe -y -loop 1 -f image2 -i Masque16_9.png -vcodec libx264 -t 4 -r 25 -pix_fmt yuv420p outWithPix20130209.mp4

ffmpeg.exe -y -loop 1 -f image2 -i Masque16_9.png -vcodec libx264 -t 4 -r 25 -pix_fmt yuv420p outWithPix.mp4
ffmpeg.exe -y -loop 1 -f image2 -i Masque16_9.png -vcodec libx264 -t 4 -r 25 outNoPix.mp4

With build 2013-02-09 with or without -pix_fmt yuv420p are MD5 equivalent, but not with recent builds!

Then it is like recently closed ticket 2284
Remember that this was not a FFmpeg-related ticket.

I couldn't know that in advance....
Nor can users know, that a there is a change of compiler options...

The playback applications you were testing (except vlc) only implement a very small part of the h264 specification.

It works like a charm with all players when encoded with builds < 12-02-2013

but please remember that this is not a support forum,

I do know, I didn't report an usage issue, I just ask within a bug report a complementary information.

Please report all bugs that you experience with FFmpeg,

Unfortunately, the way you respond makes it very dissuasive, that I do start to understand the libav fork...
One thing is to observe a bug, another is to make reproducable by a 3rd party, then try to extract its simplest form.
It would already be a progress to say when there is a bug, but not FFmpeg but, to say this bug is passed to the relevant owner.

I believe you'll get a bunch bugs(possibly many redundant) report with other people regarding libx264. See for instance,
​http://ffmpeg.zeranoe.com/forum/viewtopic.php?f=7&t=1054

Me reporting others (at least 3) malformed streams bugs I do observe, in the present state, you totally dissuated me, I'll give a try at libav.
Have a nice day.

[Carl Eugen Hoyos]

Allow me to try again:
When converting from png (bgra) to h264, you did not specify a colour-space. Since you did not specify a colour-space and the colour-space of your input file is not supported by the encoder, FFmpeg has to choose a colour-space for the output file.
x264 can be compiled either with or without support for encoding yuv444p (this is what I meant with "compilation options" above, I suspect this wasn't clear, it is not compiler-related).
If x264 supports both yuv420p and yuv444p as colour-spaces - as appears to be the case with the new binaries you were testing but not the older ones which seem to only support yuv420p - which should be chosen? yuv444p means that most quality is preserved and that is why it is chosen by FFmpeg. I strongly believe that it is an important feature of FFmpeg that it always chooses the "best" colour space from a quality point of view automatically. See for example ticket #290 for a user request that was one of the causes for the implementation of the current heuristic.
If you know in advance that quality does not matter or if you know in advance that you must play your output file with software that does not support anything else but yuv420p, then please add -pix_fmt yuv420p to your command line.

[Cigaes]

The automatic selection of the pixel format has been recently changed to reduce the possible loss of information:

commit b97d61f924eef1a8930f80cd43d0733c12f67f35
Author: Michael Niedermayer <michaelni@gmx.at>
Date:   Tue Feb 19 15:00:01 2013 +0100

    avfilter/ff_merge_formats: only merge if doing so does not loose chroma or alpha
    
    Fixes Ticket1280
    
    Signed-off-by: Michael Niedermayer <michaelni@gmx.at>

Your problem is that you rely on something automatic. If you have specifics needs, you have to express them to ffmpeg with the corresponding option, there is no "do what I mean" option.

[Carl Eugen Hoyos]

Replying to Cigaes:

The automatic selection of the pixel format has been recently changed to reduce the possible loss of information:

commit b97d61f924eef1a8930f80cd43d0733c12f67f35

I don't think this commit is related to this particular issue, iirc it fixes the case where a filter is specified on the command line and the filter does not support the input colour-space and does not support the optimal colour-space for the output stream (and instead of the optimal colour-space a colour-space supported by filter and encoder was chosen, typically gray), the "problem" here was reproducible before:

./ffmpeg -i tests/lena.pnm out.jpg
ffmpeg version N-50095-gb9237aa Copyright (c) 2000-2013 the FFmpeg developers
  built on Mar 12 2013 01:32:13 with gcc 4.7 (SUSE Linux)
  configuration:
  libavutil      52. 17.102 / 52. 17.102
  libavcodec     54. 92.100 / 54. 92.100
  libavformat    54. 63.100 / 54. 63.100
  libavdevice    54.  3.103 / 54.  3.103
  libavfilter     3. 38.103 /  3. 38.103
  libswscale      2.  2.100 /  2.  2.100
  libswresample   0. 17.102 /  0. 17.102
Input #0, image2, from 'tests/lena.pnm':
  Duration: 00:00:00.04, start: 0.000000, bitrate: N/A
    Stream #0:0: Video: ppm, rgb24, 256x256, 25 tbr, 25 tbn, 25 tbc
Output #0, image2, to 'out.jpg':
  Metadata:
    encoder         : Lavf54.63.100
    Stream #0:0: Video: mjpeg, yuvj444p, 256x256, q=2-31, 200 kb/s, 90k tbn, 25 tbc
Stream mapping:
  Stream #0:0 -> #0:0 (ppm -> mjpeg)
Press [q] to stop, [?] for help
frame=    1 fps=0.0 q=0.0 Lsize=N/A time=00:00:00.04 bitrate=N/A
video:16kB audio:0kB subtitle:0 global headers:0kB muxing overhead -100.134130%

[feelart]

If you're quote "If you know in advance that quality does not matter or if you know in advance that you must play your output file with software that does not support anything else but yuv420p, then please add -pix_fmt yuv420p to your command line." would be valid then MD5 signature for FFmpeg ante 9th Feb would all be the same and would be the same as results with ffmpeg-20130209 with -pix_fmt yuv420p, but they are not.

ffmpeg.exe -y -loop 1 -f image2 -i Masque16_9.png -vcodec libx264 -t 4 -r 25 outNoPix.mp4
ffmpeg.exe -y -loop 1 -f image2 -i Masque16_9.png -vcodec libx264 -t 4 -r 25 -pix_fmt yuv444p outyuv444p.mp4
ffmpeg.exe -y -loop 1 -f image2 -i Masque16_9.png -vcodec libx264 -t 4 -r 25 -pix_fmt yuv420p outyuv420p.mp4

C:\PortableApps\MM\FFmpeg_regression\ffmpeg-20130209-git-969039e-win64-static\ffmpeg.exe -y -loop 1 -f image2 -i Masque16_9.png -vcodec libx264 -t 4 -r 25 -pix_fmt yuv444p outyuv444p20130209.mp4
C:\PortableApps\MM\FFmpeg_regression\ffmpeg-20130209-git-969039e-win64-static\ffmpeg.exe -y -loop 1 -f image2 -i Masque16_9.png -vcodec libx264 -t 4 -r 25 outNoPix20130209.mp4
C:\PortableApps\MM\FFmpeg_regression\ffmpeg-20130209-git-969039e-win64-static\ffmpeg.exe -y -loop 1 -f image2 -i Masque16_9.png -vcodec libx264 -t 4 -r 25 -pix_fmt yuv420p outyuv420p20130209.mp4

outNoPix.mp4 3b32b8dec42f3c42fc3a4d89e7d9907a
outyuv444p.mp4 3b32b8dec42f3c42fc3a4d89e7d9907a
outyuv420p.mp4 a7fbc37922a6dfda68b838ff5d7eb883
outyuv444p20130209.mp4 507631b32e6d83ce7fe886b2da1f1689
outNoPix20130209.mp4 d6f1a6d5c6d57f4dc1fe883a68791ec8
outyuv420p20130209.mp4 d6f1a6d5c6d57f4dc1fe883a68791ec8

"Since you did not specify a colour-space and the colour-space of your input file is not supported by the encoder, FFmpeg has to choose a colour-space for the output file."
Jpeg, has no transparency, convert the source to Jpeg and I'll let you discover stagerring results.

"Your problem is that you rely on something automatic. If you have specifics needs, you have to express them to ffmpeg with the corresponding option, there is no "do what I mean" option."
Nope, without warning of behaviour change, I expect consistent reproducable behaviour, which is breached by your own comment:
"The automatic selection of the pixel format has been recently changed to reduce the possible loss of information:", through a warning, as one one has depricate command warning for instance.

I understand that you emphasise on your good quality intentions vs reliability, afterall Fukushima was also done on good intentions.
Regarding bug(s) ​http://ffmpeg.zeranoe.com/forum/viewtopic.php?f=7&t=1054, I doubt you checked, I found a fix, it's Windows Movie Maker.
Air crash investigation are full of good intentions and collections of wrong assumptions.

[Carl Eugen Hoyos]

Replying to feelart:

If you're quote "If you know in advance that quality does not matter or if you know in advance that you must play your output file with software that does not support anything else but yuv420p, then please add -pix_fmt yuv420p to your command line." would be valid then MD5 signature for FFmpeg ante 9th Feb would all be the same and would be the same as results with ffmpeg-20130209 with -pix_fmt yuv420p, but they are not.

The reason is a change in cf8d9b7
Please test the following command lines with your "20130209-git-969039e" version to see that this commit did not introduce a bug but actually fixed one by changing an erratic and difficult to describe behaviour:
$ ffmpeg -i Masque16_9.png -pix_fmt rgb24 out.png
$ ffmpeg -loop 1 -i out.png -vcodec libx264 -t 4 -r 25 out.mp4
(The command "works" with your rgba sample, but produces yuv444p output for rgb24 input: This was imo inconsistent behaviour that was fixed in cf8d9b7.)

[Cigaes]

feelart:

Your tests with MD5 do not prove anything, because you are still relying on default settings. And even if they have not changed, you are only proving that other enhancements have been made in the libx264 glue or the MP4 muxer since the previous version you are testing.

I found a fix, it's Windows Movie Maker.

Ok, this is a troll; I will not answer further.

cehoyos:

Even without filters, it is lavfi who selects the pixel format. More precisely, what happens is that encoder->pix_fmts is used to set the formats accepted by the buffersink, while the input's pixel format is given to buffersrc. Then lavfi merges the formats lists, inserts the necessary conversion filter and selects the best common pixel format.