View Full Version : some short questions about x264s (vfw)
Selur
13th February 2005, 19:38
1st yes, I read the whole threads about x264 in the forum (quite a nice read), but I could have overread something so plz don't kill me if I did
2nd didn't want to post in the x264 developement thread since my questions are not really developement related and I didn't know if it would have been better to post in the sex264 thread,...
So here are my questions:
What is the reason for a min idr-keyframe interval?
(I think) I understand that IDR stands for instantaneous decoding refresh and I understand that a max interval is needed (like a max keyframe interval in xvid&co) to ensure seakability.
But why is a min interval needed? Only reason I could come up with is something like vbv in xvid so it would mainly be a 'stay compatible to decoder' thing. If not, what is it? I mean could it hurt compression/quality if one sets min=max IDR interval?
What's the difference between spatial and temporal b-frame prediction?
I read that spatial is better psnr while temporal looks better and (I think) I do unterstand temporal prediction, but what's spatial prediction really doing?
What's the max number of reference frames allowed ?
I know more than 5 doesn't really do much, but I'm curious is there a limit other than cpu power and ram?
What's the difference between the subpicel refinement 'levels'?
Like level 1 does x and y, level 2 does all level 1 does + z, .... would be cool. :)
Does x264 use CAVLC if CABAC is disabled or does it use something else?
Problably CAVLC, but I thought: Why not ask if when you are at it. :)
Hope I don't upset someone for overlooking the answers to my questions in another thread.
So, thx to all who answer. :D
Cu Selur
Ps.: I really like detailed answers. :)
Koepi
13th February 2005, 19:47
If CABAC is switched off, CAVLC will come into effect (as a must). Those two are the bitstream entropy encoders defined by H.264 standard.
The IDR min-interval can make sense bitrate-like. It's comparable to min iframe interval in XviD - it uses too many bits compared to the rest of the bitstream if you have plenty IDR frames in a row, so you basically force some predicted frames with that between IDR frames (there I wonder how it could be possible to have consecutive IDR frames - the encoding tools of H.264 seem so mighty to me that there shouldn't be a necessity for encoding that way... well, maybe if you encode random noise).
Spatial prediction works within the frame instead over neighbouring frames.
I didn't find a maximum number of reference frames until now, but it simply makes no sense to have a whole movie as reference unless you have the earth as a mighty computer ;-) 42!
IHTH,
cheers
Koepi
Selur
13th February 2005, 20:00
thx for answering :)
"Spatial prediction works within the frame instead over neighbouring frames."
okay, that's what I thought, but doesn't b-frame rediction mean it's the way to decide if the codec codes a b-frame or not? If so how can this be decided by just analysing the frame?
"there I wonder how it could be possible to have consecutive IDR frames"
he, he that's what I wondered too since a min IDR interval would not also set a min I-Frame interval (or would it?), how could it hurt to have a too short IDR distance,.. Are IDR frames a lot bigger than I-frames? (I kind of assumed they were like normal I-Frames with an additional flag,..)
"but it simply makes no sense to have a whole movie as reference"
no, but it might help to look through the whole clip for a potential reference frame and then e.g. decide which refrence frames to choose so that only a specific number of frames is needed during a specific playback time,...
=>DOH, this would problably kill a streaming capabilities :D
Cu Selur
Ps.: About subpixel refinement:
I assume:
level 1 = 8x8 sub marcoblocks (which shouldn't do anything assuming all the other searches are on)
level 2 = level 1 + 8x4 sub macroblocks
level 3 = level 2 + 4x8 sub macroblocks
level 4 = level 3 + 4x4 sub macroblocks
level 5 = not a clue :D
bond
13th February 2005, 21:43
Originally posted by Selur
What is the reason for a min idr-keyframe interval?
(I think) I understand that IDR stands for instantaneous decoding refresh and I understand that a max interval is needed (like a max keyframe interval in xvid&co) to ensure seakability.
But why is a min interval needed? with a min interval of 4 you could do [IDR][P][I][P][IDR] with the second P being able to refer to the first P and the first IDR too (this can make sense eg with fast switches in high motion, or shots which show a flash (which could force an i-frame, but appears only very shortly) but still being able to refer to the frames before the flash of the shot)
of course you cant cut at I-frames, but only at IDR ones, so having a not too big min interval is also good
ok the 4 interval sample is very easy, rethink it with a 25 frame interval :D
What's the max number of reference frames allowed ?on the mencoder manual for x264 (written by aku) it says the max is 15
What's the difference between the subpicel refinement 'levels'?
Like level 1 does x and y, level 2 does all level 1 does + z, .... would be coolalso have a look at the manual here (http://mplayerhq.hu/DOCS/man/en/mplayer.1.html):
1: Runs fullpixel precision motion estimation on all candidate macroblock types. Then selects the best type. Then refines the motion of that type to fast quarterpixel precision. (fastest)
2: As 1, but uses a slightly slower fullpixel search and a slightly slower quarterpixel re- finement.
3: Runs halfpixel precision motion estimation on all candidate macroblock types. Then selects the best type. Then refines the motion of that type to quarterpixel precision.
4: Runs fast quarterpixel precision motion esti- mation on all candidate macroblock types. Then selects the best type. Then finishes the quar- terpixel refinement for that type.
5: Runs best quality quarterpixel precision mo- tion estimation on all candidate macroblock types, before selecting the best type. (best, default)
akupenguin
13th February 2005, 21:54
Originally posted by Selur
"Spatial prediction works within the frame instead over neighbouring frames."
okay, that's what I thought, but doesn't b-frame rediction mean it's the way to decide if the codec codes a b-frame or not? If so how can this be decided by just analysing the frame?
No, this "prediction" is a method of compressing motion vectors. It would be lossless compression, except that motion estimation takes into account the number of bits needed to encode the MV, so it's biased towards using the predicted MV.
"but it simply makes no sense to have a whole movie as reference"
no, but it might help to look through the whole clip for a potential reference frame and then e.g. decide which refrence frames to choose so that only a specific number of frames is needed during a specific playback time,...
=>DOH, this would problably kill a streaming capabilitiesYes, it's possible, it's slow to encode, and it kills seeking.
About subpixel refinement:
I assume:
level 1 = 8x8 sub marcoblocks (which shouldn't do anything assuming all the other searches are on)
level 2 = level 1 + 8x4 sub macroblocks
level 3 = level 2 + 4x8 sub macroblocks
level 4 = level 3 + 4x4 sub macroblocks
level 5 = not a clue :D No. See the MPlayer manpage (http://mplayerhq.hu/DOCS/man/en/mplayer.1.html#CODEC%20SPECIFIC%20ENCODING%20OPTIONS%20(MENCODER%20ONLY)) for details.
Selur
13th February 2005, 21:57
So your point would be that a min distance would be so that there wouldn't be IDRs during fast motion scenes, flashes etc., right?
Okay I could live with that for a reason but I'm kind of disapointed that x264 would create a IDR in such a situation, shouldn't it be able to check for those scenarios at least if one does 2 (or more) encoding passes?
For one pass encoding I totally agree to the argument; the cutting point argument would still be valid, but inside a a .mp4 shell cutting should be possible at each frame. (I the real cutting point would still be at the idr and the decoder would just start playback at the cutting point ;) )
"on the mencoder manual for x264 (written by aku) it says the max is 15"
thx :)
reading the manual :)
---------------
"No, this "prediction" is a method of compressing motion vectors."
okay, thx :)
also reading the manpage now :)
thx to all :)
Cu Selur
bond
13th February 2005, 21:58
Originally posted by Selur
it might help to look through the whole clip for a potential reference frame and then e.g. decide which refrence frames to choose so that only a specific number of frames is needed during a specific playback time,...
=>DOH, this would problably kill a streaming capabilities :Dafaik the mainconcept encoder does something like that with the reordering delay option
Koepi
13th February 2005, 22:37
I think reordering delay just means that it extends the reference frame reordering by some amount. (This reordering thing makes me go nuts a little, if I try to think about it with just 10 frames...)
akupenguin:
thakns for clearing that up, yet another misunderstanding from my side corrected :)
Cheers
Koepi
Selur
13th February 2005, 22:37
okay, after reading the mencoder manpage I get it all except the IDR minimum.
as I understood it:
-idr frames are like i-frames with a flag that guarantees the decoder that all frames behind it won't refer to a frame before it, so that the decoder can refresh it's memory
- idr min interval defines the minimal distance between two neighbouring idr frames, so two IDR frames would be at least 'min interval size' frames away.
- idr max interval defines the maximal distance between two neighbouring idr frames, so two IDR frames can't be more than 'max interval size' frames separated.
- One needs IDR-Frames ot cut and to seek and the IDR-interval will only restrict the I-Frames.
For cutting&seeking more IDRs are good so minimum distance doesn't matter here, if one needs more cutting and seeking points one has to lower the max IDR-interval. Even the decoder performance should gain from a lot of IDR-Frames,...
So atm the only reason I could understand that a min interval is needed would be when IDR frames would require significantly more bitrate than I-Frames,...
Cu Selur
Ps.: maybe I just can't see the forest because of all the trees,.. :D
bond
13th February 2005, 22:44
selur: IDR frames in AVC are exactly the same as I-frames in ASP from what i understood!
the difference is that an I-Frame in AVC allows other frames to refer to frames before that I-Frame (something that isnt possible in ASP because of the lack of multiple reference frames)
Originally posted by Koepi
I think reordering delay just means that it extends the reference frame reordering by some amountindeed, but wouldnt it be possible that way to handle single longterm references? eg always reorder a specific frame in the reference list for keeping it useable over a long time?
Selur
13th February 2005, 22:50
"IDR frames in AVC are exactly the same as I-frames in ASP from what i understood!"
okay, that's what I understood too, so the size difference shouldn't be too big and I'm totally lost why a min distance between idr frame is necessary at all. :)
Cu Selur
bond
13th February 2005, 22:54
Originally posted by Selur
okay, that's what I understood too, so the size difference shouldn't be too big and I'm totally lost why a min distance between idr frame is necessary at allbecause you can than allow in between that distance I-Frames PLUS frames after that i-frames referring to frames before that i-frames
eg image in a scene where a man stands still and holds a gun.
suddenly he shoots without moving, resulting in a big flash
after the shot he stands just like before the shot
in avc you can use an i-frame for the frames where the flash occurs, but still letting the following frames refer to the frames before the flash/i-frame saving bitrate
see what i mean? i think thats especially useful for high motion/action
Selur
13th February 2005, 23:05
I understand what you mean, it's like the exaple you pointed out before.
"[IDR][P][I][P][IDR]"
where you used a min IDR interval of 4, the scenario that a P frame could refere over one or more I-frames should still be possible when I set the min IDR interval to a higher value.
e.g. if I set it to 6 the scene from before could look like this
[IDR][P][I][P][I][P][IDR]
So the reference is still 'okay', but cutting points would be farer away. => I see why min=max idr is bad :D
Okay, but why whould a min interval of e.g. 1 be a bad idea?
(mencoder manpage recommends 0.4*max idr-interval als min idr interval)
bond
13th February 2005, 23:08
Originally posted by Selur
Okay, but why whould a min interval of e.g. 1 be a bad idea?it wouldnt be bad, it would simply lead to that all I-Frames are also IDR-Frames and like I-Frames in ASP
meaning excluding one possible enhancement of AVC over ASP
Selur
13th February 2005, 23:28
Okaaaaay,..
"it would simply lead to that all I-Frames are also IDR-Frames "
Why? Shouldn't the codec first check if it wants e.g. a p-frames to refer to a frame that lies before another I-frame and then decide it it wants to 'convert' an i-frame to an IDR-frame?
like this:
take the first 250 frames (=max idr distance) after an IDR Frame(A) search for the best scenario that gives best quality, mark all possible i-frames that could be converted to IDR-Frames. Go to the next possible IDR-Frame(B) and check if some frames behind B, that are still in the max idr distance from A, should/want to refer to a frame. Some of the frames want/should do this B stays an i-frame and we go on to the next I-Frame marked as possible IDR-Frame until we reach the last possible IDR-Frame or a possible IDR-Frame which isn't followed by some frames that should/want to refer to a frame before it. So we got ourself a new IDR-Frame and the process starts again. :)
Cu Selur
bond
13th February 2005, 23:42
Originally posted by Selur
"it would simply lead to that all I-Frames are also IDR-Frames "
Why? Shouldn't the codec first check if it wants e.g. a p-frames to refer to a frame that lies before another I-frame and then decide it it wants to 'convert' an i-frame to an IDR-frame?well he can do that if you allow a min distance bigger than 1
a min distance of 1 simply means by definition that "all i-frames are idr-frames" from how i understand it
Selur
13th February 2005, 23:50
okay, if it's a default settings/procedure, is there anything that speaks against a min distance of 2 and for a min distance = 0.4*max distance?
(hope I'm not too bugging, I'm really happy that you take the time and try to explain it :D)
Cu Selur
bond
14th February 2005, 12:18
Originally posted by Selur
okay, if it's a default settings/procedure, is there anything that speaks against a min distance of 2 and for a min distance = 0.4*max distance?- 0.4*max distance, with the default (250) that would be a min distance of 100, sounds ok, but this will have to be tested (eg if scenechanges dont get IDR altough they should...)
- a min distance of 2 will not allow b/p-frames to refer before an i-frame of course, so yep, a min distance of 3 might be the minimum that makes sense practically
Selur
14th February 2005, 14:21
"a min distance of 2 will not allow b/p-frames to refer before an i-frame of course"
Why? A min distance of 2 would still allow the [IDR][P][I][P][IDR] scenario, which had a min distance of 4 and since 4 is bigger than 2 it should be possible, or is it another 'hardcoded' scenario fo min distance = 2?
bond
14th February 2005, 14:27
yeah of course, stupid me :)
IgorC
15th February 2005, 13:38
Can we expect an implementation of weighted prediction, High Profile etc. in future?
Yong
15th February 2005, 13:59
From x264 win32 daily builds (http://forum.doom9.org/showthread.php?threadid=89979) :
x264 limitations:<...>There are a few other features not supported (weighted prediction, MMCO, B4x4)"
What is MMCO?
Since B4x4 is not supported, will they have any difference video quality with others full-featured h264 codec?
sorry for bad english...
Selur
15th February 2005, 14:05
MMCO should stand for Memory Management Control Operation, see:
http://www.mplayerhq.hu/~michael/ffmpeg-doxy/structMMCO.html#_details
Yong
16th February 2005, 15:00
@Selur:
Thanks:)
bond
16th February 2005, 15:16
Originally posted by Yong
Since B4x4 is not supported, will they have any difference video quality with others full-featured h264 codec?afaik there are no "full-featured h264 codecs" that support 4x4 blocksizes for b-frames...
Yong
16th February 2005, 15:31
Originally posted by bond
afaik there are no "full-featured h264 codecs" that support 4x4 blocksizes for b-frames...
The h264 codec i use is only x264...
So i don't know others h264 codec features...:p
I think now i don't have to worried about the x264 codec quality compare to others h264 codec:D
vBulletin® v3.8.11, Copyright ©2000-2026, vBulletin Solutions Inc.