How to see the number of I-frames and B-frames from the standard error stream?

[kakashipakkun]

I am sure I have read it somewhere but I forgot where it was. I have searched through the forums and found no answer.

There is a standard error stream in the log of MeGUI and there is a lot of numbers. And I have read it before that the numbers somewhat represent the numbers of different types of frames. Can somebody help me on that?

[talen9]

Post a log and we'll highlight the info you need in it :)

[Dark Shikari]

avis [info]: 1920x1080 @ 23.98 fps (290740 frames)
x264 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 Cache64
x264 [info]: slice I:2735 Avg QP:19.18 size:236616
x264 [info]: slice P:102900 Avg QP:21.24 size: 91361
x264 [info]: slice B:185105 Avg QP:23.21 size: 49111
x264 [info]: consecutive B-frames: 4.3% 4.9% 75.4% 15.4%
x264 [info]: mb I I16..4: 1.3% 97.9% 0.7%
x264 [info]: mb P I16..4: 0.1% 16.4% 0.1% P16..4: 50.1% 20.5% 10.3% 0.0% 0.0% skip: 2.6%
x264 [info]: mb B I16..4: 0.0% 2.3% 0.0% B16..8: 46.4% 1.1% 1.7% direct:11.6% skip:36.9% L0:46.4% L1:41.4% BI:12.1%
x264 [info]: 8x8 transform intra:98.8% inter:48.2%
x264 [info]: direct mvs spatial:98.2% temporal:1.8%
x264 [info]: ref P L0 39.3% 28.5% 17.9% 14.3%
x264 [info]: ref B L0 57.7% 32.5% 9.8%
x264 [info]: ref B L1 83.4% 16.6%
x264 [info]: kb/s:12626.4

[talen9]

There it is :p

Sorry, but I didn't have a log available just then :)

[kakashipakkun]

Opps... looks like i have asked the wrong question. I meant, how to see the distribution of the frames in different quantizers?

[Dark Shikari]

Opps... looks like i have asked the wrong question. I meant, how to see the distribution of the frames in different quantizers?Meaningless question, since x264 doesn't use frame quantizers for much of anything.

If you want to see the macroblock quantizers, FFDshow has a visualization option.

[kakashipakkun]

I see... Thanks! ^^

[LoRd_MuldeR]

I think Avinaptic can show the info you requested, useful or not:


[ About H.264 encoding ]

Number of frames: 10970
Drop/delay frames: 0
Corrupted frames: 0

P-slices: 4688 ( 42.735 %) ###########
B-slices: 6075 ( 55.378 %) ##############
I-slices: 207 ( 1.887 %)
SP-slices: 0 ( 0.000 %)
SI-slices: 0 ( 0.000 %)

[ DRF analysis ]

Average DRF: 26.878942
Standard deviation: 2.243825
Max DRF: 33

DRF<19: 0 ( 0.000 %)
DRF=19: 1 ( 0.009 %)
DRF=20: 1 ( 0.009 %)
DRF=21: 17 ( 0.155 %)
DRF=22: 151 ( 1.376 %)
DRF=23: 591 ( 5.387 %) #
DRF=24: 1054 ( 9.608 %) ##
DRF=25: 1312 ( 11.960 %) ###
DRF=26: 1660 ( 15.132 %) ####
DRF=27: 1716 ( 15.643 %) ####
DRF=28: 1654 ( 15.077 %) ####
DRF=29: 1453 ( 13.245 %) ###
DRF=30: 801 ( 7.302 %) ##
DRF=31: 418 ( 3.810 %) #
DRF=32: 127 ( 1.158 %)
DRF=33: 14 ( 0.128 %)
DRF>33: 0 ( 0.000 %)

P-slices average DRF: 25.905930
P-slices std. deviation: 1.983050
P-slices max DRF: 31

B-slices average DRF: 27.731522
B-slices std. deviation: 2.050117
B-slices max DRF: 33

I-slices average DRF: 23.893719
I-slices std. deviation: 1.650152
I-slices max DRF: 28

[talen9]

LoRd_MuldeR, i recently found out that the DRF analysis AVInaptic does on x264 streams is not accurate or meaningful at all :(

Or, at least, it strongly disagrees with the x264 logs of the same stream:

x264 [info]: slice I:2735 Avg QP:19.18 size:236616
x264 [info]: slice P:102900 Avg QP:21.24 size: 91361
x264 [info]: slice B:185105 Avg QP:23.21 size: 49111

which definitely go a lot better along with the CRF value I specify in my recent encodes ...

So, I think that a) AVInaptic does his analysis assuming that the quantizers are specified on a frame basis or b) recent changes in CRF meaning with respect to the average QP has borked the analysis.

[Warpman]

LoRd_MuldeR, i recently found out that the DRF analysis AVInaptic does on x264 streams is not accurate or meaningful at all :(

Or, at least, it strongly disagrees with the x264 logs of the same stream:



which definitely go a lot better along with the CRF value I specify in my recent encodes ...

So, I think that a) AVInaptic does his analysis assuming that the quantizers are specified on a frame basis or b) recent changes in CRF meaning with respect to the average QP has borked the analysis.
can you post an example where x264 stats and avinaptic disagree?

[Zwitterion]

Avinaptic, FFDshow OSD (csv export, averaged) and x264 agree for AQ=0.
When using Avinaptic it doesn't make any difference if AQ is non-zero, the value will still be the same.

edit: false alarm

[Sagekilla]

Quick question, do x264 logs print out the average quant for a frame or do they still use the global quant the frame was assigned to before any AQ was applied?

Also, how exactly does Avinaptic determine DRF?

[talen9]

@Warpman: sorry, I don't have ready just right now a pair of encoded file / encode log, I'll post them later; anyway, try doing an encode with, say, crf 18.5 and see for yourself which average DRF AVInaptic reports ... lately it's saying to me something like 20.5-21 and over ... doing a weighted average of the values in the logfile, what comes out is around 19-19.5.

@Sagekilla: have a look for yourself at AVInaptic source code ... and good luck :confused: I think that the only person which is able to understand it is fsinapsi himself, maybe having some knowledge of LISP helps a little (the programming language AVInaptic is written into is of fsinapsi's own devise, the syntax is loosely base on LISP / elisp) :rolleyes:

[Dark Shikari]

Quick question, do x264 logs print out the average quant for a frame or do they still use the global quant the frame was assigned to before any AQ was applied?

Also, how exactly does Avinaptic determine DRF?x264 prints out average frame quants, Avinaptic prints out global quants, which is why the latter is useless.

[LoRd_MuldeR]

x264 prints out average frame quants, Avinaptic prints out global quants, which is why the latter is useless.

Avinaptic was last updated when VAQ was not committed yet. That might be the reason...

[Dark Shikari]

Avinaptic was last updated when VAQ was not committed yet. That might be the reason...Or perhaps because getting all the MB quants would require decoding the entire bitstream completely, rather than just the frame headers?

[LoRd_MuldeR]

Or perhaps because getting all the MB quants would require decoding the entire bitstream completely, rather than just the frame headers?

I got no idea how Avinaptic works internally, but this sound like another good reason...