View Full Version : why is the bitrate not changed?
qgdeng
25th July 2008, 10:56
hello,
i have added x264 library to ffmpeg, and i used the following command to code:
ffmpeg -s cif -i akiyo_cif.yuv -vcodec libx264 -b BIT_RATE -bt BIT_RATE -rc_eq 'blurCplx^(1-qComp)' -qcomp 0.6 -qmin 10 -qmax 51 -qdiff 4 -y b1.mp4
when i changed the BIT_RATE, i found that the compressed stream don't change, but i changed the -qmax parameter, the stream size was changed dramatically.
Which values did you actually use? Note that they are in bits/s and you need to use suffix "k" for kilobits/s, like "-b 1000k".
fibbingbear
25th July 2008, 12:05
Off the top of my head, if you're choosing a very high bitrate, it could be that everything is hitting the qmax limit when it's being encoded. Qmax limits the maximum "detail" allowed in a frame IIRC.
DarkZell666
25th July 2008, 12:43
Off the top of my head, if you're choosing a very high bitrate, it could be that everything is hitting the qmax limit when it's being encoded. Qmax limits the maximum "detail" allowed in a frame IIRC.
Rather the qmin, since the scale is backwards. qmin defines maximum quality (minimum quantizer) and qmax defines minimum quality (maximum quantizer). Just for a reminder, high quantizers = high compression = low quality (or was it an oopsie due to too much beer ? :P)
Though I'd vote for nm's post, at least I was mislead a bunch of times by the bits/s unit ... :cool:
qgdeng
25th July 2008, 12:58
I set bitrate to 1000k, and the quality of the encoded stream is very bad (the printed information is "bitrate=20.7kb/s", which <<1000k). So I doubt whether I use error parameters. Because i think the quality should be good with this bitrate.
So I doubt whether I use error parameters.
Bad parameters are the most likely explanation. Try to specify the bitrate in bits/s: -b 1000000
Edit: I just tried your command line with the same Akiyo CIF source. With:
ffmpeg -s cif -i akiyo_cif.yuv -vcodec libx264 -b 1000 -bt 1000 -rc_eq 'blurCplx^(1-qComp)' -qcomp 0.6 -qmin 10 -qmax 51 -qdiff 4 -y t1.mp4
I get:
video:30kB audio:0kB global headers:1kB muxing overhead 8.583133%
[libx264 @ 0xb7c10410]slice I:26 Avg QP:49.50 size: 922
[libx264 @ 0xb7c10410]slice P:274 Avg QP:51.00 size: 23
[libx264 @ 0xb7c10410]mb I I16..4: 96.3% 0.0% 3.7%
[libx264 @ 0xb7c10410]mb P I16..4: 0.1% 0.0% 0.0% P16..4: 1.2% 0.0% 0.0%
0.0% 0.0% skip:98.7%
[libx264 @ 0xb7c10410]final ratefactor: 75.05
[libx264 @ 0xb7c10410]SSIM Mean Y:0.7329794
[libx264 @ 0xb7c10410]kb/s:20.2
And with:ffmpeg -s cif -i akiyo_cif.yuv -vcodec libx264 -b 1000k -bt 1000k -rc_eq 'blurCplx^(1-qComp)' -qcomp 0.6 -qmin 10 -qmax 51 -qdiff 4 -y t2.mp4
This:video:1469kB audio:0kB global headers:1kB muxing overhead 0.175261%
[libx264 @ 0xb7c9f410]slice I:25 Avg QP:13.31 size: 23458
[libx264 @ 0xb7c9f410]slice P:275 Avg QP:13.66 size: 3337
[libx264 @ 0xb7c9f410]mb I I16..4: 18.1% 0.0% 81.9%
[libx264 @ 0xb7c9f410]mb P I16..4: 0.2% 0.0% 0.0% P16..4: 60.7% 0.0% 0.0% 0.0% 0.0% skip:39.1%
[libx264 @ 0xb7c9f410]final ratefactor: 11.90
[libx264 @ 0xb7c9f410]SSIM Mean Y:0.9922137
[libx264 @ 0xb7c9f410]kb/s:1002.7
qgdeng
26th July 2008, 04:20
I use the same command:
ffmpeg -s cif -i akiyo_cif.yuv -vcodec libx264 -b 1000k -bt 1000k -rc_eq 'blurCplx^(1-qComp)' -qcomp 0.6 -qmin 10 -qmax 51 -qdiff 4 -y t2.mp4
And the following is my result:
E:\seq\ffmpeg>ffmpeg -s cif -i akiyo_cif.yuv -vcodec libx264 -b 1000k -bt 1000k
-rc_eq 'blurCplx(1-qComp)' -qcomp 0.6 -qmin 10 -qmax 51 -qdiff 4 -y t2.mp4
FFmpeg version SVN-r14321, Copyright (c) 2000-2008 Fabrice Bellard, et al.
configuration: --enable-gpl --enable-pthreads --enable-libvorbis --enable-libx
264
libavutil version: 49.7.0
libavcodec version: 51.60.0
libavformat version: 52.17.0
libavdevice version: 52.0.0
built on Jul 22 2008 00:19:21, gcc: 3.4.4 (cygming special, gdc 0.12, using dmd 0.125)
Input #0, rawvideo, from 'akiyo_cif.yuv':
Duration: N/A, start: 0.000000, bitrate: N/A
Stream #0.0: Video: rawvideo, yuv420p, 352x288, 25.00 tb(r)
Output #0, mp4, to 't2.mp4':
Stream #0.0: Video: libx264, yuv420p, 352x288, q=10-51, 1000 kb/s, 25.00 tb(c)
Stream mapping:
Stream #0.0 -> #0.0
[libx264 @ 0x1002e1d0]using cpu capabilities: MMX2 SSE2Fast SSSE3 Cache64
Press [q] to stop encoding
video:27kB audio:0kB global headers:1kB muxing overhead 9.289617%
[libx264 @ 0x1002e1d0]slice I:25 Avg QP:50.24 size: 858
[libx264 @ 0x1002e1d0]slice P:275 Avg QP:51.00 size: 23
[libx264 @ 0x1002e1d0]mb I I16..4: 96.4% 0.0% 3.6%
[libx264 @ 0x1002e1d0]mb P I16..4: 0.1% 0.0% 0.0% P16..4: 1.3% 0.0% 0.0% 0.0% 0.0% skip:98.7%
[libx264 @ 0x1002e1d0]final ratefactor: -25.18
[libx264 @ 0x1002e1d0]SSIM Mean Y:0.7310507
[libx264 @ 0x1002e1d0]kb/s:18.6
frame= 300 fps=218 q=2341919.0 Lsize= 30kB time=12.00 bitrate= 20.7kbits/s
I use cygwin for compile the src code of ffmpeg and x264.
DarkZell666
26th July 2008, 09:45
Output #0, mp4, to 't2.mp4':
Stream #0.0: Video: libx264, yuv420p, 352x288, q=10-51, 1000 kb/s, 25.00 tb(c)
Now that's wicked, since the 1000k from your command line actually seems to be interpreted correctly. Would you mind trying the -b 1000000 as suggested by nm ?
Also, I read here and there that using cygwin was a no-go (dunno why though, and I may be mistaken) for compiling that sort of stuff. Any particular reason you didn't use msys ?
Dark Shikari
26th July 2008, 15:32
Since you're inputting directly from YUV files, why not use x264 directly?
vBulletin® v3.8.11, Copyright ©2000-2026, vBulletin Solutions Inc.