View Full Version : X264 warning: specified frame type (3) is not compatible with keyframe interval
laserfan
20th November 2008, 15:14
I got a warning in Pass2 of my last encoding (see in RED):
Beginning Pass1
x264 core:65 r1028M 83baa7f
D:\Temp\job1>"C:\Program Files\x264\x264.exe" --pass 1 --bitrate 5644 --stats "D:\Temp\job1\
job1.stats" --level 4.1 --keyint 24 --min-keyint 2 --bframes 3 --weightb --direct auto --subme 2 --partitions none --ipr
atio 1.1 --pbratio 1.1 --vbv-bufsize 14000 --vbv-maxrate 16500 --qcomp 0.5 --threads auto --thread-input --progress --no
-psnr --no-ssim --output NUL "D:\Temp\job1\job1.avs" --mvrange 511 --aud --nal-hrd --sar 1:1
avis [info]: 1920x1080 @ 23.98 fps (135119 frames)
x264 [info]: using SAR=1/1
x264 [info]: using cpu capabilities: MMX2 SSE2 Cache64
x264 [info]: profile Main, level 4.1
x264 [info]: slice I:7958 Avg QP:24.46 size: 78658
x264 [info]: slice P:68386 Avg QP:24.65 size: 37632
x264 [info]: slice B:58775 Avg QP:25.41 size: 12988
x264 [info]: consecutive B-frames: 18.8% 54.2% 13.5% 13.5%
x264 [info]: mb I I16..4: 64.7% 0.0% 35.3%
x264 [info]: mb P I16..4: 34.5% 0.0% 0.0% P16..4: 48.9% 0.0% 0.0% 0.0% 0.0% skip:16.6%
x264 [info]: mb B I16..4: 4.4% 0.0% 0.0% B16..8: 22.9% 0.0% 0.0% direct:17.8% skip:54.9% L0:34.5% L1:56.7% BI:
8.7%
x264 [info]: final ratefactor: 25.03
x264 [info]: direct mvs spatial:96.6% temporal:3.4%
x264 [info]: kb/s:5625.4
encoded 135119 frames, 4.94 fps, 5630.00 kb/s
Beginning Pass2
x264 core:65 r1028M 83baa7f
D:\Temp\job1>"C:\Program Files\x264\x264.exe" --pass 2 --bitrate 5644 --stats "D:\Temp\job1\
job1.stats" --level 4.1 --keyint 24 --min-keyint 2 --ref 3 --mixed-refs --bframes 3 --weightb --direct auto --trellis 1
--partitions p8x8,b8x8,i4x4,i8x8 --8x8dct --ipratio 1.1 --pbratio 1.1 --vbv-bufsize 14000 --vbv-maxrate 16500 --qcomp 0.
5 --me umh --threads auto --thread-input --progress --no-psnr --no-ssim --output "D:\Temp\video1.264" "D:\
Temp\job1\job1.avs" --mvrange 511 --aud --nal-hrd --sar 1:1
avis [info]: 1920x1080 @ 23.98 fps (135119 frames)
x264 [info]: using SAR=1/1
x264 [info]: using cpu capabilities: MMX2 SSE2 Cache64
x264 [info]: profile High, level 4.1
x264 [warning]: specified frame type (3) is not compatible with keyframe interval
x264 [info]: slice I:7957 Avg QP:24.93 size: 71875
x264 [info]: slice P:68389 Avg QP:25.26 size: 36114
x264 [info]: slice B:58773 Avg QP:25.24 size: 15885
x264 [info]: consecutive B-frames: 18.8% 54.2% 13.5% 13.5%
x264 [info]: mb I I16..4: 11.7% 82.5% 5.8%
x264 [info]: mb P I16..4: 1.2% 9.7% 0.2% P16..4: 57.3% 7.7% 7.0% 0.0% 0.0% skip:17.0%
x264 [info]: mb B I16..4: 5.6% 0.0% 0.0% B16..8: 24.4% 0.7% 0.3% direct:15.8% skip:53.3% L0:41.3% L1:50.1% BI:
8.6%
x264 [info]: 8x8 transform intra:70.1% inter:78.5%
x264 [info]: direct mvs spatial:86.9% temporal:13.1%
x264 [info]: ref P L0 75.8% 15.3% 8.9%
x264 [info]: ref B L0 82.3% 17.7%
x264 [info]: kb/s:5643.2
encoded 135119 frames, 1.55 fps, 5647.79 kb/s
I Googled & found this bit of code, which may/may not be right but I'm not a programmer so don't get the meaning of it anyway:
/* Limit GOP size */
if( frm->i_frame - h->frames.i_last_idr >= h->param.i_keyint_max )
{
if( frm->i_type == X264_TYPE_AUTO )
frm->i_type = X264_TYPE_IDR;
if( frm->i_type != X264_TYPE_IDR )
x264_log( h, X264_LOG_WARNING, "specified frame type (%d) is not compatible with keyframe interval\n", frm->i_type );
I have a lot of questions:
1. The message implies something is amiss WITHIN THE X264 COMMAND but I used the same command on a very similar video (episode) just prior to this one and I got no such warning
2. What is "frame type (3)" and what does the warning mean? Did it encounter a scene where it couldn't make a 24 frame GOP or something?
3. Why wouldn't I have gotten the warning ALSO in Pass 1?
4. Is there now likely to be a glitch in the x264-encoded video somewhere (I have not looked at the entire hour & a half program) such that I should re-do it, and if yes, what would need to be changed in my x264 options?
Sorry for all the newbie-ish questions but any feedback on this, or on my x264 commands themselves, would be most welcome! :confused:
Sharktooth
20th November 2008, 17:46
fix your commandline, not the code!
--min-keyint 2 along with b-frames is just ridicolous...
kemuri-_9
20th November 2008, 18:28
all i can answer with assurance is
2. What is "frame type (3)" and what does the warning mean? Did it encounter a scene where it couldn't make a 24 frame GOP or something?
frame type 3 is declared by the x264.h defines section as a P frame.
so technically it's saying it had to place a P frame where an I frame should of gone to maintain the max GOP.
from that code section it states that the frame was a P frame and was determined elsewhere (more than likely the stats file)
so if you happened to do any .stat altering or change the number of refs from the first pass to the 2nd, this is likely the problem.
...
*points to 1 ref in pass 1 to 3 w/ mixed-ref in pass 2*
...
this is likely the fault of the problem.
use the same number of references in the first pass as the second pass.
akupenguin
20th November 2008, 20:28
--min-keyint 2 along with b-frames is just ridicolous...
What's wrong with min-keyint 2?
use the same number of references in the first pass as the second pass.
No, you're supposed to use more refs in the 2nd pass.
so if you happened to do any .stat altering
Yes.
Dark Shikari
20th November 2008, 20:52
...
*points to 1 ref in pass 1 to 3 w/ mixed-ref in pass 2*
...
this is likely the fault of the problem.
use the same number of references in the first pass as the second pass.Can we have a rule that disallows giving advice when you have no idea what you're talking about?
laserfan
20th November 2008, 20:58
fix your commandline, not the code!
--min-keyint 2 along with b-frames is just ridicolous...
It would be nice if you explained this. My passes are [verbatim I think] out of the MeGUI program, AVCHD profile.
all i can answer with assurance is frame type 3 is declared by the x264.h defines section as a P frame. so technically it's saying it had to place a P frame where an I frame should of gone to maintain the max GOP.Hmmm, but placing another I-frame would shorten the GOP!? Or maybe you're saying the Next GOP?
if you happened to do any .stat altering or change the number of refs from the first pass to the 2nd, this is likely the problem.
...
*points to 1 ref in pass 1 to 3 w/ mixed-ref in pass 2*
...
this is likely the fault of the problem.
use the same number of references in the first pass as the second pass.Well, I didn't do any manipulation of the stats file, but I assume now there's some inconsistency between my pass1 & pass2 that needs to be fixed.
I believed I had correctly borrowed the Pass structures from MeGUI, but maybe I misunderstood selection of Pass 1 & Pass 2 in the drop-downs of that program.
So now it's been suggested I have at least two problems in my commands (Sharktooth's comment & refs) but no consensus... :confused:
laserfan
20th November 2008, 21:00
Can we have a rule that disallows giving advice when you have no idea what you're talking about?Save me, Dark! :o
Sharktooth
20th November 2008, 21:03
min-keyint 2 is only useful for editing but i doubt that encode was meant to be edited. usually you edit BEFORE encoding to a lossy format.
the other reason could be seeking, but i seriously doubt that's the case too... since you wanna seek frame by frame OR at a certain bigger steps (like 1 second, or 30 frames at a time).
however, having a second look at his commandline, having a keyint of 24 makes me think he is trying to make a BD5/BD/AVC-HD compatible stream... that could make sense but he misses some options in the commandline.
EDIT: apparently, pengvado is right. there's something wrong in the statsfile.
laserfan
20th November 2008, 21:10
the only possible reason could be he is trying to make a BD5/BD/AVC-HD compatible stream... that could make sense but he misses some options in the commandline.This is the case; I'm making BD-5/9s for playback in BD standalone. So looking for a bulletproof (i.e. playback glitch-free) encoding method.
Although I run x264 from the command line, the Pass options above were borrowed from MeGUI (or so I thought). I've also looked at jdobbs' commandlines and RipBot264s--no one here seems to agree on "compatibility".
Please fix my commands if you see obvious errors, or Pass 1 vs Pass 2 problems.
Dark Shikari
20th November 2008, 21:16
"something is wrong in the statsfile" is not very useful if we can't see the statsfile.
Sharktooth
20th November 2008, 21:49
i didnt see the statsfile... but as pengvado said it's very likely the cause of the problem.
so, laserfan, please post the statsfile.
btw, the missing options are "--aud --nal-hrd". those require a patched x264 build with NAL/HRD patch.
video_magic
20th November 2008, 22:13
....
No, you're supposed to use more refs in the 2nd pass.
..
Aha, this is another one of the x264 options which one could use a different value for, or omit, differently for the first versus the second pass?
Please would you point to somewhere where this kind of option is explained, or I would be thankful if you or someone else expert would explain here. Thankyou very much as always.
laserfan
20th November 2008, 22:52
i didt see the statsfile... but as pengvado said it's very likely the cause of the problem.
so, laserfan, please post the statsfile.
btw, the missing options are "--aud --nal-hrd". those require a patched x264 build with NAL/HRD patch.Those options are there in my cl above, and I used the latest build patched w/NAL/HRD as listed there also. I did check again my commandlines against MeGUI and the Standalone-AVC-HD profile as published by YOU Shark so I still don't understand your first comment. Correction, my Pass 1 differs from MeGUI's Pass 1 Turbo mode w/SA-AVC-HD by a --me dia option I missed somehow.
Packed-to-the-max, my stats file is still 2.2Mb in size so I'll have to host it somewhere...
EDIT: Should be able to find the stats file here (http://rapidshare.com/files/165774491/stats.7z.html).
Thanks, LM, I couldn't think of mediafire--will try it next time!
LoRd_MuldeR
20th November 2008, 22:56
Packed-to-the-max, my stats file is still 2.2Mb in size so I'll have to host it somewhere...
http://mediafire.com/ ;)
Sharktooth
21st November 2008, 05:10
Those options are there in my cl above, and I used the latest build patched w/NAL/HRD as listed there also. I did check again my commandlines against MeGUI and the Standalone-AVC-HD profile as published by YOU Shark so I still don't understand your first comment.
never mind... im just blind...
Selur
21st November 2008, 20:51
Just reading this thread now an still a bit confused reading it. :)
Could it hurt do lower min keyint to 1 ? (with 2pass encoding)
I mean shouldn't x264 be 'clever' enough to not do some 'stupid' key frame placement?
Sharktooth
21st November 2008, 21:05
you dont really want consecutive keyframes... it's a waste of space unless you encode for editing (in that case, keyint and min-keyint could be 1, or 2, etc...)
in any case, this situation is different, the min keyint was set to a certain value (2) coz higher values seem to create problems to BD standalones (dont ask me why... even 4 sometimes borks...)
Selur
21st November 2008, 21:32
it's a waste of space ...
Why, shouldn't 2pass encoding prevent such wastefulness? I mean is this 'just' a x264 'problem' or am I missing something general?
laserfan
21st November 2008, 23:14
Just reading this thread now an still a bit confused reading it.Well, of course you are--there has yet to be a single post (which hasn't been contradicted/refuted/sniped-at by others) in response to my questions!!! :scared:
kemuri-_9
22nd November 2008, 00:26
I looked at the stats you provided and there was never a GOP larger than 24 in it
but as this is probably the 1st pass .stats it make makes sense, as x264 didn't complain about a GOP failure in it.
so the next step would be to copy the .stats to a backup file
and then run your 2nd pass again except using --pass 3 instead of --pass 2,
so it'll overwrite the 1st pass .stats with the results from the 2nd pass.
can then provide us with that new .stats and see if something is noticeable.
laserfan
22nd November 2008, 15:27
I appreciate your response kemuri-_9 but I don't think I'm going to do that.
It seems like no one here knows what to make of this error (what might have caused it) so unless I see some visual glitch in the final video I ain't gonna bother anymore with it.
Thanks anyway!
laserfan
22nd November 2008, 18:21
OK, having asserted --keyint 24 and --min-keyint 2, I'd gotten a warning in Pass2 of my encoding:
x264 [warning]: specified frame type (3) is not compatible with keyframe interval
Before I deleted all my temp files, I did a search on "statsfile" to try to learn more about it, but
couldn't find anything explaining the shorthand therein. So for grins I opened the .264 with Avidemux
which created an index file--taking a look at that the only >24 GOP I can find is the last one (25):
ADMY0003
Type : E
File : D:\Temp\Safe\video4.264
Append : 0
Image : P
Picture : 1920 x 1088 23975 fps
Payload : H264
Nb Gop : 00007908
Nb Images: 0000135119
Nb Audio : 00
Main aud : 00
Streams : V0000:00e0
# NGop NImg nbImg type:abs:rel:size ...
V 000 000000 24 I:00000006...
# Timestamp 00:00:00,000
V 001 000024 24 I:00000c77...
# Timestamp 00:00:00,000
V 002 000048 24 I:0000167c...
.
.
.
V 7906 135070 24 I:ed2446a0,00000,00273...
# Timestamp 00:00:00,000
V 7907 135094 25 I:ed2451e8,00000,00225 P:ed24540d,00000,0005d P:ed24546a,00000,00058
P:ed2454c2,00000,00058 P:ed24551a,00000,00058 P:ed245572,00000,0005c P:ed2455ce,00000,00059
P:ed245627,00000,00059 P:ed245680,00000,00061 P:ed2456e1,00000,00062 P:ed245743,00000,00059
P:ed24579c,00000,00059 P:ed2457f5,00000,00059 P:ed24584e,00000,0005f P:ed2458ad,00000,0005e
P:ed24590b,00000,0005d P:ed245968,00000,00059 P:ed2459c1,00000,00060 P:ed245a21,00000,00065
P:ed245a86,00000,0005d P:ed245ae3,00000,00060 P:ed245b43,00000,0005c P:ed245b9f,00000,0005c
P:ed245bfb,00000,0005c P:ed245c57,00000,00043
# Timestamp 00:00:00,000
# Video Aspect Ratio : 1:1
Then I looked again at the .stats file and notice at the end:
#options: 1920x1080 fps=2500000/104271 cabac=1 ref=1 deblock=1:0:0 analyse=0x1:0 me=hex
subme=2 psy_rd=0.0:0.0 mixed_ref=0 me_range=16 chroma_me=1 trellis=0 8x8dct=0 cqm=0 deadzone=21,11
chroma_qp_offset=0 threads=3 nr=0 decimate=1 mbaff=0 bframes=3 b_pyramid=0 b_adapt=1 b_bias=0
direct=3 wpredb=1 keyint=24 keyint_min=2 scenecut=40(pre) rc=cbr bitrate=5644 ratetol=1.0
qcomp=0.50 qpmin=10 qpmax=51 qpstep=4 vbv_maxrate=16500 vbv_bufsize=14000 ip_ratio=1.10
pb_ratio=1.10 aq=1:1.00
in:0 out:0 type:I q:10.00 tex:461 mv:1932 misc:5327 imb:8160 pmb:0 smb:0 d:-;
.
.
.
in:135094 out:135094 type:I q:13.12 tex:575 mv:1916 misc:661 imb:8160 pmb:0 smb:0 d:s;
in:135098 out:135095 type:P q:10.00 tex:0 mv:0 misc:504 imb:0 pmb:0 smb:8160 d:s;
in:135095 out:135096 type:b q:12.97 tex:0 mv:0 misc:480 imb:0 pmb:0 smb:8160 d:s;
in:135096 out:135097 type:b q:12.97 tex:0 mv:0 misc:480 imb:0 pmb:0 smb:8160 d:s;
in:135097 out:135098 type:b q:12.97 tex:0 mv:0 misc:480 imb:0 pmb:0 smb:8160 d:s;
in:135102 out:135099 type:P q:10.00 tex:3 mv:12 misc:521 imb:1 pmb:0 smb:8159 d:s;
in:135099 out:135100 type:b q:11.00 tex:0 mv:0 misc:480 imb:0 pmb:0 smb:8160 d:s;
in:135100 out:135101 type:b q:11.00 tex:0 mv:0 misc:480 imb:0 pmb:0 smb:8160 d:s;
in:135101 out:135102 type:b q:11.00 tex:27 mv:3 misc:490 imb:0 pmb:1 smb:8159 d:s;
in:135106 out:135103 type:P q:10.00 tex:36 mv:12 misc:520 imb:1 pmb:0 smb:8159 d:s;
in:135103 out:135104 type:b q:11.00 tex:0 mv:0 misc:480 imb:0 pmb:0 smb:8160 d:s;
in:135104 out:135105 type:b q:11.00 tex:0 mv:0 misc:480 imb:0 pmb:0 smb:8160 d:s;
in:135105 out:135106 type:b q:11.00 tex:0 mv:0 misc:480 imb:0 pmb:0 smb:8160 d:s;
in:135110 out:135107 type:P q:10.00 tex:6 mv:22 misc:532 imb:2 pmb:0 smb:8158 d:s;
in:135107 out:135108 type:b q:11.00 tex:32 mv:2 misc:494 imb:0 pmb:1 smb:8159 d:s;
in:135108 out:135109 type:b q:11.00 tex:29 mv:2 misc:489 imb:0 pmb:1 smb:8159 d:s;
in:135109 out:135110 type:b q:11.00 tex:0 mv:0 misc:480 imb:0 pmb:0 smb:8160 d:s;
in:135114 out:135111 type:P q:10.00 tex:25 mv:11 misc:516 imb:1 pmb:0 smb:8159 d:s;
in:135111 out:135112 type:b q:11.00 tex:90 mv:6 misc:488 imb:0 pmb:1 smb:8159 d:s;
in:135112 out:135113 type:b q:11.00 tex:39 mv:2 misc:487 imb:0 pmb:1 smb:8159 d:s;
in:135113 out:135114 type:b q:11.00 tex:70 mv:5 misc:501 imb:0 pmb:2 smb:8158 d:s;
in:135117 out:135115 type:P q:10.00 tex:0 mv:0 misc:504 imb:0 pmb:0 smb:8160 d:s;
in:135115 out:135116 type:b q:11.00 tex:0 mv:0 misc:480 imb:0 pmb:0 smb:8160 d:s;
in:135116 out:135117 type:b q:11.00 tex:0 mv:0 misc:480 imb:0 pmb:0 smb:8160 d:s;
in:135118 out:135118 type:I q:10.99 tex:527 mv:1887 misc:658 imb:8160 pmb:0 smb:0 d:s;
This suggests to my (admittedly untrained/uneducated/mostly-clueless-about-x264-innards) eye
that frame 135118 is a single picture I-frame, which violates --min-keyint 2? Make sense to anyone? But another oddity is it seems the stats file thinks I have 135118 frames and the Avidemux 135119?
Still not sure what the error says, but the video appears perfect so I hereby declare victory. Thanks to all
who helped, and for any further comments.
Snowknight26
22nd November 2008, 18:50
But another oddity is it seems the stats file thinks I have 135118 frames and the Avidemux 135119?
The stats file starts at frame 0.
kemuri-_9
22nd November 2008, 18:51
the stats files are written as 0 -> 1 - total_frames
frame #135118 is actually the 135119th frame
it's just a principle of number that things are like this (as most things are numbered in this fashion)
and i already mentioned before, the warning is from a P frame going where an I frame should have to maintain the max GOP length, not the minimum.
so, if a P frame was to go where that last I frame is, the maximum GOP length is violated: as it is 25 for the last group instead of 24 - the specified max
this may be what actually happened, but without your stream or a .stats generated from a --pass 3, it's mostly speculation.
--min-keyint 2 would be violated if there was two back-to-back I frames (this is the x264 'I' which is an IDR frame),
which there isn't a case of, so it's not violated (afaik)
Snowknight26
23rd November 2008, 03:27
Funny enough, it just happened to me too. First time out of at least 150 encodes that I've done with a similar command line:
C:\temp\Encoding>x264 --pass 1 --bitrate 11151 --stats "eraser/eraser.stats" --b
frames 3 --b-adapt 2 --b-pyramid --direct auto --deblock -3:-3 --subme 4 --analy
se none --me hex --threads auto --thread-input --progress --no-psnr --output NUL
"eraser/eraser.avs"
avis [info]: 1920x800 @ 23.98 fps (164755 frames)
x264 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 Cache64
x264 [info]: profile Main, level 4.1
x264 [info]: slice I:3111 Avg QP:15.10 size:172292
x264 [info]: slice P:62160 Avg QP:16.72 size: 75294
x264 [info]: slice B:99484 Avg QP:18.54 size: 41187
x264 [info]: consecutive B-frames: 4.6% 32.5% 22.5% 40.4%
x264 [info]: mb I I16..4: 36.2% 0.0% 63.8%
x264 [info]: mb P I16..4: 51.4% 0.0% 0.0% P16..4: 43.0% 0.0% 0.0% 0.0% 0
.0% skip: 5.6%
x264 [info]: mb B I16..4: 22.5% 0.0% 0.0% B16..8: 42.0% 0.0% 0.0% direct:
20.1% skip:15.4% L0:30.5% L1:47.6% BI:21.8%
x264 [info]: final ratefactor: 19.00
x264 [info]: direct mvs spatial:100.0% temporal:0.0%
x264 [info]: SSIM Mean Y:0.9826973
x264 [info]: kb/s:10843.0
encoded 164755 frames, 13.02 fps, 10843.16 kb/s
C:\temp\Encoding>x264 --pass 2 --bitrate 11151 --stats "eraser/eraser.stats" --b
frames 3 --level 4.1 --ref 5 --mixed-refs --no-fast-pskip --b-pyramid --weightb
--direct auto --deblock -3:-3 --subme 9 --trellis 2 --psy-rd 1.0:0 --analyse all
--8x8dct --no-dct-decimate --me umh --threads auto --thread-input --progress --
no-psnr --output "eraser/eraser.mkv" "eraser/eraser.avs"
avis [info]: 1920x800 @ 23.98 fps (164755 frames)
x264 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 Cache64
x264 [info]: profile High, level 4.1
x264 [warning]: specified frame type (3) is not compatible with keyframe interva
l
x264 [warning]: specified frame type (3) is not compatible with keyframe interva
l
x264 [info]: slice I:3110 Avg QP:16.26 size:157737
x264 [info]: slice P:62161 Avg QP:16.88 size: 80507
x264 [info]: slice B:99484 Avg QP:18.69 size: 41036
x264 [info]: consecutive B-frames: 4.6% 32.5% 22.5% 40.4%
x264 [info]: mb I I16..4: 6.6% 89.0% 4.5%
x264 [info]: mb P I16..4: 1.9% 21.6% 0.9% P16..4: 38.1% 23.9% 8.9% 0.1% 0
.1% skip: 4.5%
x264 [info]: mb B I16..4: 0.2% 2.1% 0.1% B16..8: 56.8% 2.1% 2.4% direct:
15.0% skip:21.4% L0:42.7% L1:43.5% BI:13.8%
x264 [info]: 8x8 transform intra:88.8% inter:55.4%
x264 [info]: direct mvs spatial:97.9% temporal:2.1%
x264 [info]: ref P L0 57.5% 19.1% 10.5% 7.0% 5.9%
x264 [info]: ref B L0 73.4% 15.8% 7.3% 3.4%
x264 [info]: ref B L1 92.3% 7.7%
x264 [info]: SSIM Mean Y:0.9826283
x264 [info]: kb/s:11150.0
encoded 164755 frames, 2.66 fps, 11150.12 kb/s
Need I upload the stats file?
Any reason/explanation for this?
Edit: Stats file: http://www.stfcc.org/misc/eraser.stats
Dark Shikari
23rd November 2008, 03:58
It could have been revealed by the recent change that removed this:
/* FIXME: ugly padding because VfW drops delayed B-frames */
rc->num_entries += h->param.i_bframe;
But that's just speculation.
laserfan
23rd November 2008, 16:08
...if a P frame was to go where that last I frame is, the maximum GOP length is violated: as it is 25 for the last group instead of 24 - the specified max
this may be what actually happened, but without your stream or a .stats generated from a --pass 3, it's mostly speculation.Thanks kemuri for your response--I'm not gonna bother with another pass so this will remain a mystery I guess.
GZZ
26th November 2008, 11:09
Got a little comment og this one. Was encoding Jumper Bluray yesterday, when I got this error 3 times: specified frame type (3) is not compatible with keyframe interval on my 2 pass.
I then did the 2 pass again and second time I didnt get this error. I used the same state file in both cases. So I'm not sure its an error in the state file. My input was from DGAVCDEC in a AVS file loaded into x264 R1028.
Dont have the stat file anymore, was just a comment on this issue.
laserfan
27th November 2008, 16:17
A couple more of these warnings FWIW. Question: is there anywhere an explanation of the .stats file elements, and/or a tool that helps to analyze it?
Beginning Pass1
x264 0.65.1029M cb3c213
Tue 11/25/2008
01:31 PM
D:\>"C:\Program Files\x264\x264.exe" --pass 1 --bitrate 4153 --stats "video.stats" --level 4.
1 --keyint 24 --min-keyint 2 --bframes 3 --weightb --direct auto --subme 2 --partitions none --ipratio 1.1 --pbratio 1.1
--vbv-bufsize 14000 --vbv-maxrate 16500 --qcomp 0.5 --me dia --threads auto --thread-input --progress --no-psnr --no-ss
im --output NUL "video.avs" --mvrange 511 --aud --nal-hrd --sar 1:1
avis [info]: 1920x1080 @ 23.98 fps (176235 frames)
x264 [info]: using SAR=1/1
x264 [info]: using cpu capabilities: MMX2 SSE2 Cache64
x264 [info]: profile Main, level 4.1
x264 [info]: slice I:12176 Avg QP:19.46 size: 53776
x264 [info]: slice P:89495 Avg QP:22.52 size: 25776
x264 [info]: slice B:74564 Avg QP:23.93 size: 9953
x264 [info]: consecutive B-frames: 21.7% 50.2% 8.6% 19.5%
x264 [info]: mb I I16..4: 79.7% 0.0% 20.3%
x264 [info]: mb P I16..4: 28.0% 0.0% 0.0% P16..4: 28.3% 0.0% 0.0% 0.0% 0.0% skip:43.7%
x264 [info]: mb B I16..4: 4.3% 0.0% 0.0% B16..8: 16.0% 0.0% 0.0% direct:11.8% skip:67.9% L0:37.3% L1:54.2% BI:
8.5%
x264 [info]: final ratefactor: 25.24
x264 [info]: direct mvs spatial:88.3% temporal:11.7%
x264 [info]: kb/s:4031.0
encoded 176235 frames, 5.83 fps, 4036.61 kb/s
Tue 11/25/2008
09:54 PM
Beginning Pass2
x264 0.65.1029M cb3c213
Tue 11/25/2008
09:54 PM
D:\>"C:\Program Files\x264\x264.exe" --pass 2 --bitrate 4153 --stats "video.stats" --level 4.
1 --keyint 24 --min-keyint 2 --ref 3 --mixed-refs --bframes 3 --weightb --direct auto --trellis 1 --partitions p8x8,b8x8
,i4x4,i8x8 --8x8dct --ipratio 1.1 --pbratio 1.1 --vbv-bufsize 14000 --vbv-maxrate 16500 --qcomp 0.5 --me umh --threads a
uto --thread-input --progress --no-psnr --no-ssim --output "video.264" "video.avs" --mvrange 511 --aud --nal-hrd
--sar 1:1
avis [info]: 1920x1080 @ 23.98 fps (176235 frames)
x264 [info]: using SAR=1/1
x264 [info]: using cpu capabilities: MMX2 SSE2 Cache64
x264 [info]: profile High, level 4.1
x264 [warning]: specified frame type (3) is not compatible with keyframe interval
x264 [warning]: specified frame type (3) is not compatible with keyframe interval
x264 [info]: slice I:12175 Avg QP:20.10 size: 51038
x264 [info]: slice P:89497 Avg QP:23.72 size: 25054
x264 [info]: slice B:74563 Avg QP:23.62 size: 12758
x264 [info]: consecutive B-frames: 21.7% 50.2% 8.6% 19.5%
x264 [info]: mb I I16..4: 36.7% 57.0% 6.2%
x264 [info]: mb P I16..4: 1.9% 6.5% 0.4% P16..4: 37.5% 5.4% 6.2% 0.0% 0.0% skip:42.1%
x264 [info]: mb B I16..4: 6.4% 0.0% 0.0% B16..8: 17.7% 0.5% 0.2% direct:10.8% skip:64.3% L0:44.1% L1:47.2% BI:
8.7%
x264 [info]: 8x8 transform intra:51.5% inter:76.1%
x264 [info]: direct mvs spatial:78.3% temporal:21.7%
x264 [info]: ref P L0 76.2% 15.1% 8.6%
x264 [info]: ref B L0 79.9% 20.1%
x264 [info]: kb/s:4152.1
encoded 176235 frames, 2.04 fps, 4157.60 kb/s
Wed 11/26/2008
09:57 PM
Dark Shikari
27th November 2008, 22:06
A couple more of these warnings FWIW. Question: is there anywhere an explanation of the .stats file elements, and/or a tool that helps to analyze it?Update your x264, it's already been fixed.
laserfan
27th November 2008, 23:03
Ok, I've done that--any help re: reading the stats file?
kemuri-_9
27th November 2008, 23:22
Ok, I've done that--any help re: reading the stats file?
can always look at
x264_ratecontrol_end( x264_t *h, int bits )
in encoder/ratecontrol.c
for that information.
laserfan
28th November 2008, 01:28
Thanks, I'll take a look. :)
vBulletin® v3.8.5, Copyright ©2000-2012, Jelsoft Enterprises Ltd.