Looking for H.264 Source Code in C

[nm]

Originally Posted by skyjuice

What if I'd like to change the quantizer value to a specific fixed bitrate value? Or can I use the command --bitrate for this purpose) such as --bitrate xxx --qpfile?

Yes, if CBR or ABR is fine and you don't need different manually specified sizes for different frames. Just set quantizers to -1 in qpfile and use whatever rate control you want.

Originally Posted by skyjuice

To use qpfile, I just have to type the contents in a text file and name it qpfile and run it using --qpfile, right?

You can name the text file whatever.xyz and run x264 with --qpfile whatever.xyz

[sneaker_ger]

As a side note: "-1" can be omitted. So:

0 K -1
645 K -1
8456 K -1

is the same as:

0 K
645 K
8456 K

[skyjuice]

Originally Posted by nm

Yes, if CBR or ABR is fine and you don't need different manually specified sizes for different frames. Just set quantizers to -1 in qpfile and use whatever rate control you want.

The problem is I need to specify a higher fixed bitrate for I-frame and lower fixed bitrate value for P-frame. Is this possible using any of the methods discussed before?

[skyjuice]

Anyway, I tried using the command

ffmpeg -i input.mp4 -f image2 frame-%03d.pgm

after encoding my sequence of pgm file and the result is individual decoded frames. To calculate the PSNR of the first frame (original and decoded), I used the command pnmpsnr [original] [decoded] and was told that

images do not have the same maxval. The first image has maxval 65535 while the second has 255

I believe this is due to the process where x264 has compressed some bit per pixel out of the image. Is there anyway to rectify this?

[LoRd_MuldeR]

Originally Posted by skyjuice

The problem is I need to specify a higher fixed bitrate for I-frame and lower fixed bitrate value for P-frame. Is this possible using any of the methods discussed before?

Why? Usually you only have a single I-Frame once in a while. Talking about a "bit rate" (which usually is expressed as kilobits per second) for a single frame that only lasts for 1/25 or 1/50 second is kind of strange.

[nm]

Originally Posted by skyjuice

I believe this is due to the process where x264 has compressed some bit per pixel out of the image. Is there anyway to rectify this?

You have 16-bit images as source and x264 converts them to 8-bit before actually encoding them. One option is to convert the original images to a suitable format yourself, so that x264 won't preprocess the input and the final PSNR score isn't influenced by different conversions. The most common format is 8-bit YUV 4:2:0, but other subsamplings and even RGB are possible if you instruct x264 properly. 10-bit video can be encoded with a 10-bit enabled x264 build.

With grayscale images, you don't need to worry about chroma subsampling, but you might want to dither if the original source is really 16-bit and not upconverted 8-bit. ImageMagick's convert tool should do the trick, for example. Or even ffmpeg if you don't need fancy dithering.

[skyjuice]

Anyway, I solved the problem by using the 'compare' command to get the PSNR output. One thing that puzzles me is the --bitrate option.

1) Why is it the encoded bitrate is not the same as the one that I specified? For example, when I type:

x264 img_%04d.pgm --bitrate 500 -o outputvideo.mkv

I get "encoded 8 frames, 3.52 fps, 1069.47 kb/s" instead. The same goes for "--fps" command.

2) Is it possible to specify the bitrate value, say 500.54 instead of 500? As I know x264 only accepts integer value.

[J_Darnley]

1 - 8 frames is far too short for rate control to do anything. Use 2-pass if you need a specific size or use crf.
2 - No. A modification to allow bits/s to be set might be possible but is it really necessary? Rate control probably is not precise enough for that anyway.

[skyjuice]

Is it possible if I want to specify the decoded frames to be of certain bitrate in term of bit/pixels? I am trying to plot a graph of PSNR vs bitrate (bit/pixel) which looks something like this

[skyjuice]

Originally Posted by J_Darnley

1 - 8 frames is far too short for rate control to do anything. Use 2-pass if you need a specific size or use crf.
2 - No. A modification to allow bits/s to be set might be possible but is it really necessary? Rate control probably is not precise enough for that anyway.

I still dont quite get it here. I need to have a constant rate control (using --fps and --bitrate) so that I get a fair output for comparison. How many frames should I be using to ensure that the encoder can apply the value of fps or bitrate that I enter because right now I got the following message whenever i encode

Stream #0: not enough frames to estimate rate; consider increasing probesize

[nm]

Originally Posted by skyjuice

I still dont quite get it here. I need to have a constant rate control (using --fps and --bitrate) so that I get a fair output for comparison. How many frames should I be using to ensure that the encoder can apply the value of fps or bitrate that I enter because right now I got the following message whenever i encode

You'll need about 50 to 100 frames and run two passes:

x264 --bitrate 500 --pass 1 -o output.264 input
x264 --bitrate 500 --pass 2 -o output.264 input

Or perhaps more if you want accurate results with a short clip:

x264 --bitrate 500 --pass 1 -o output.264 input
x264 --bitrate 500 --pass 3 -o output.264 input (--pass 3 is not a typo here!)
x264 --bitrate 500 --pass 3 -o output.264 input
x264 --bitrate 500 --pass 3 -o output.264 input
...

But if three passes isn't accurate enough, fourth isn't going to help. You'll need a longer clip then.


IMO, 8 frames is not enough for any video testing. You need at least a couple seconds at a realistic framerate (10 to 60 fps) for real world video comparisons.

Originally Posted by skyjuice

Stream #0: not enough frames to estimate rate; consider increasing probesize

That message comes from libav/FFmpeg which demuxes and decodes your input video. Use --force-cfr --fps 25 (or whatever your real framerate is) to override its guesses.