On 28.05.2012 14:45, Carl Eugen Hoyos wrote:
<koli@...> writes:
I was trying to use ffmpeg for screen capture and come to
this problem.
(Note that ffmpeg natively supports screen capture input,
no need to use png's.)
I know, but the PNG images was meant as kind of etalon. If someone can
download those pictures and with some command (option), create a H264
encoded video with sharp red colored text that is possible to play via
ffplay, mplayer (ffmpeg). I don't know a way how to share my desktop for
everybody anytime someone wants to play with it. ;-).
[...]
ffmpeg -r 5 -i ./GrabedPictures/Pic%d.png -r 5 -vcodec libx264
TestX264.avi
Complete, uncut console output missing.
Your resulting file has colourspace yuv420p, that means it cannot
look better / store all colour information;-)
Either you are using an ancient or broken version of FFmpeg, or
your version of x264 only supports yuv420p (current x264 also
supports yuv444p which does not loose chroma information,
current FFmpeg with current x264 automatically chooses yuv444p).
I am not suffering with color degradation. It is ok and acceptable. You
can see the green or red color of the text console in the video is fade
in comparison with original PNG images, but it is OK. Problem is the
sharpness of red text. Why is all other text nice sharp, but the red is
fuzzy?
Anyway what kind of option (switch.value) and how should I use when I
want to encode in yuv444 and not the default yuv420. I was trying
something like
ffmpeg -r 5 -i ./GrabedPictures/Pic%d.png -vf format=yuv444p -vcodec
libx264 -x264opts qp=0 TestLL_X264_yuv444.avi
Here is wanted console output:
ffmpeg version 0.10 Copyright (c) 2000-2012 the FFmpeg developers
built on Mar 2 2012 10:02:15 with gcc 4.5.3
configuration: --prefix=/usr --libdir=/usr/lib64
--shlibdir=/usr/lib64 --mandir=/usr/share/man --enable-shared
--cc=x86_64-pc-linux-gnu-gcc --cxx=x86_64-pc-linux-gnu-g++
--ar=x86_64-pc-linux-gnu-ar --optflags='-O2 -pipe' --extra-cflags='-O2
-pipe' --extra-cxxflags='-O2 -pipe' --disable-static --enable-gpl
--enable-postproc --enable-avfilter --disable-stripping --disable-debug
--disable-vaapi --enable-runtime-cpudetect --enable-libmp3lame
--enable-libtheora --enable-libvorbis --enable-libx264 --enable-libxvid
--disable-indev=v4l --disable-indev=v4l2 --disable-indev=oss
--enable-x11grab --disable-outdev=oss --enable-libfreetype
--enable-pthreads --enable-libdirac --enable-libschroedinger
--enable-libspeex --disable-altivec --disable-avx --disable-vis
--disable-neon --disable-iwmmxt --enable-hardcoded-tables
libavutil 51. 34.101 / 51. 34.101
libavcodec 53. 60.100 / 53. 60.100
libavformat 53. 31.100 / 53. 31.100
libavdevice 53. 4.100 / 53. 4.100
libavfilter 2. 60.100 / 2. 60.100
libswscale 2. 1.100 / 2. 1.100
libswresample 0. 6.100 / 0. 6.100
libpostproc 52. 0.100 / 52. 0.100
Input #0, image2, from './GrabedPictures/Pic%d.png':
Duration: 00:00:20.00, start: 0.000000, bitrate: N/A
Stream #0:0: Video: png, rgba, 1680x1050, 5 fps, 5 tbr, 5 tbn, 5
tbc
File 'TestLL_X264_yuv444.avi' already exists. Overwrite ? [y/N] y
Incompatible pixel format 'rgba' for codec 'libx264', auto-selecting
format 'yuv420p'
[buffer @ 0x2470810] w:1680 h:1050 pixfmt:rgba tb:1/1000000 sar:0/1
sws_param:
[buffersink @ 0x2468600] auto-inserting filter 'auto-inserted scale 0'
between the filter 'Parsed_format_0' and the filter 'out'
[format @ 0x2478d70] auto-inserting filter 'auto-inserted scale 1'
between the filter 'src' and the filter 'Parsed_format_0'
[scale @ 0x247a1b0] w:1680 h:1050 fmt:rgba -> w:1680 h:1050 fmt:yuv444p
flags:0x4
[scale @ 0x2479a70] w:1680 h:1050 fmt:yuv444p -> w:1680 h:1050
fmt:yuv420p flags:0x4
[libx264 @ 0x246f990] using cpu capabilities: MMX2 SSE2Fast SSSE3
Cache64
[libx264 @ 0x246f990] profile High 4:4:4 Predictive, level 4.0, 4:2:0
8-bit
Output #0, avi, to 'TestLL_X264_yuv444.avi':
Metadata:
ISFT : Lavf53.31.100
Stream #0:0: Video: h264 (H264 / 0x34363248), yuv420p, 1680x1050,
q=-1--1, 5 tbn, 5 tbc
Stream mapping:
Stream #0:0 -> #0:0 (png -> libx264)
Press [q] to stop, [?] for help
frame= 100 fps= 12 q=-1.0 Lsize= 616kB time=00:00:19.60 bitrate=
257.4kbits/s
video:608kB audio:0kB global headers:0kB muxing overhead 1.305962%
[libx264 @ 0x246f990] frame I:1 Avg QP: 0.00 size:152460
[libx264 @ 0x246f990] frame P:99 Avg QP: 0.00 size: 4747
[libx264 @ 0x246f990] mb I I16..4: 76.6% 5.3% 18.1%
[libx264 @ 0x246f990] mb P I16..4: 2.1% 0.1% 0.4% P16..4: 0.6%
0.1% 0.0% 0.0% 0.0% skip:96.7%
[libx264 @ 0x246f990] 8x8 transform intra:3.0% inter:19.2%
[libx264 @ 0x246f990] coded y,uvDC,uvAC intra: 20.4% 16.3% 16.3% inter:
0.1% 0.4% 0.4%
[libx264 @ 0x246f990] i16 v,h,dc,p: 78% 21% 0% 0%
[libx264 @ 0x246f990] i8 v,h,dc,ddl,ddr,vr,hd,vl,hu: 46% 49% 3% 1%
0% 0% 0% 1% 0%
[libx264 @ 0x246f990] i4 v,h,dc,ddl,ddr,vr,hd,vl,hu: 42% 42% 6% 3%
2% 1% 1% 2% 1%
[libx264 @ 0x246f990] i8c dc,h,v,p: 81% 12% 8% 0%
[libx264 @ 0x246f990] Weighted P-Frames: Y:0.0% UV:0.0%
[libx264 @ 0x246f990] ref P L0: 70.1% 0.9% 18.8% 10.2%
[libx264 @ 0x246f990] kb/s:248.98
But as you can see the output was still using yuv420. That's why we
coded our own ffmpeg grabber(compressor) and hardcoded there this yuv444
as you can see in this video (e.g. try mediainfo)
http://tucniak.sk/ffmpeg/OwnGrabX264_YUV444.avi
[...]
ffmpeg -r 5 -i ./GrabedPictures/Pic%d.png -r 5 -vcodec huffyuv
OutHuff.avi
ffmpeg -r 5 -i ./GrabedPictures/Pic%d.png -r 5 -vcodec ffv1
-sameq TestFfv1.avi
-sameq does not do what you believe and it has no effect in this
command line (ffv1 is always lossless).
I didn't studied options for these codecs in detail just copied it
somewhere from the web, anyway the outcome is the same.
[...]
What is more interesting when I was trying to play huff or ffv1
video with mplayer or ffplay the red text was still fuzzy.
(Complete, uncut MPlayer console output missing.)
ffplay only supports yuv420p output and you started mplayer
with the wrong -vo, try -vo gl which supports yuv444p output.
OK this helped. With this option mplayer plays it sharp.
It seems that ffmpeg has not
correct decoding of "lossless" video codecs.
Please understand that this is not a very useful comment,
the lossless codecs are tested quite extensibly (which does
not mean they cannot have bugs, but they should be
reported differently).
Maybe "not correct" was not the right description. Now I see that
ffplay does not support it and mplayer does with right option. So
outcome from this is that ffmpeg as library is ok for decoding lossless
yuv444 video.
Carl Eugen
_______________________________________________
Libav-user mailing list
[email protected]
http://ffmpeg.org/mailman/listinfo/libav-user
_______________________________________________
Libav-user mailing list
[email protected]
http://ffmpeg.org/mailman/listinfo/libav-user
