[FFmpeg-trac] #2347(avcodec:closed): Recent builds regression bug - KO from 12th Feb 2013 - OK before

[FFmpeg]

#2347: Recent builds regression bug  - KO from 12th Feb 2013 - OK before
------------------------------------+-----------------------------------
             Reporter:  feelart     |                    Owner:
                 Type:  defect      |                   Status:  closed
             Priority:  normal      |                Component:  avcodec
              Version:  git-master  |               Resolution:  invalid
             Keywords:  libx264     |               Blocked By:
             Blocking:              |  Reproduced by developer:  0
Analyzed by developer:  0           |
------------------------------------+-----------------------------------

Comment (by 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.

-- 
Ticket URL: <https://ffmpeg.org/trac/ffmpeg/ticket/2347#comment:12>
FFmpeg <http://ffmpeg.org>
FFmpeg issue tracker