http://www.mainconcept.com/h264_encoder.shtml

http://www.heise.de/newsticker/meldung/44488 (german article)


my first impression:
i compared xvid with qpel, trellis, vhq4 and 2 b-frames, other sttings on default and the mainconcept encoder with the default settings and main profile using a very small (!) test clip: neo using his mobile phone in matrix1

imho h.264 brings already pretty good results at ~500kbps bitrate, tough not comparable to xvid sharpness-wise (maybe i should have tried xvid without qpel?)
but the quality seems to be strongly fluctuating, meaning it seems that sometimes the picture is blurry, than sharp again, than blurry, with blocks sometimes showing up in between... (maybe thats a decoding issue?)

all-in-all not bad for a start, and i think there is _a lot of_ room for improvements (imagine how normal mpeg-4 part2 encodes looked like some years ago )

AFAIK this technology preview is only able to use CBR which would explain the fluctuating quality.

How fast is encoding/decoding (compared to xvid)?

nope, i didnt test long encodes with different scenes which would show such a behaviour maybe
and its funny but i dont get these blocks when decoding via avisynths dshowsource

well there is a very _huge_ difference
i didnt really look at the used time cause its definitely too slow to be used for normal encodes on my 866mhz p3


also i have to change my statements above a little bit, in my test encode i think i can say that xvid and mc's h.264 are pretty much on par qualitywise (of course i didnt do any broad testing which would be necessary for such a statement maybe)

just in time (doing some very lo bitrate encodings now)....
comparison to nandub and ffvfw on simillar bitrates (bitrates are cca. 250-320kbit/s for 15fps 288x240 and 352x288 clips.....) would be interesting
i skipped the realvideo as i would need to make new settings file,and helix is slow,and rv9 blurs (non-toon material)....etc.

web says;
"Operating systems: Windows 2000, Me, XP (DirectX 9 required)"

hmm...8mb dload for dirx9?we'll see...(hehe)
we'll see if it works on dirx8 that is...

10mb dload for avc---ayayay....
also,selur said
"Ps.: crashes with avs fiels as input"

huh,seems like i'll wait!

let me add one more comment from doom9 forum;
bulletproof said:
"I did a quick test with 1mbit bitrate and the video came out pretty blurry, very much like a WMV video."

i already guessed somewhere that ms will steal all the h264 patents it needs same as it stole mpeg4(ms mpeg4) and do some mods and release it.....(wmencoder9 is also slow as hell,but beats rv9 on natural lobitrate video
see my last post here
http://virtualdub.everwicked.com/index.php?act=ST&f=3&t=5924
...heh)
why will it steal them?because it's involved in making of the standard....

inloop filtering?for filtering we have avs and vdub,no need for codec to do filtering....

anyway,i need avs support in any case....can anyone confirm selur's experience (no loading of avs)?
how about ffvfw's "makeavis"?will it load that?

won't dload 10mb just to see it can't load avs...
but will dload it if it can load avs in any of these 2 ways....

expecting your comments...

On very low bitrates it can make a huge difference if the filtering is done inside. Vdub can only filter before encoding, oustide the codec.

H.264 is featuring inside. This means that you decode an I frame, filter it, and the next P will be predicted from the FILTERED I. This is a huge difference with mpeg4 SP or MP@ML

so,what's the difference?
1-vdub or avs cleaned video;less noise in I-frame=less noise in subsequent P's....
2-h264's inloop;codec denoises,result is the same....(seems to be slow(ie. not optimized filtering as vdub's or avs'),but is straight forward;even girls can do it(hehe))

(note that inloop also needs to filter PRIOR to encoding,as otherwise it makes no sense;noise is wasting bitrate,and whole point of filtering(inloop or other) is to have less noise PRIOR to encoding....it's very hard to save the day with good post processing(on decoding) if you have lots of noise,as encoding efficiency suffers...more blocks,mosquiots etc....)

wmv9 acts that way;it removes the details along side removing the noise...

the trouble is this;i doubt wmv9(or h264,if bulletproof is right(on 1mbit),and i think he is) has adaptive filtering(ie. filter less as bitrate increases)...
that's why normal mpeg4 might even win on higher bitrates...it just might...
and on lower bitrates..well,there's always ffdshow and addnoise....
(as i said,if there's a confirmation that this encoder can load avs,i'll try it against mpeg4...i already tried wmv9 and i didn't took that encoding path..it's 2x(or more) slower while being 10-20% better than mpeg4 on lo bitrates...and better here means that it blocks less,but also has less detail....i rather use ffdshow to compensate...)

here's small excerpt on this from "h264_loopfilter.pdf"[67kB];
"A filter is applied to every decoded macroblock in order to reduce blocking distortion. The deblocking
filter is applied after the inverse transform in the encoder (before reconstructing and storing the
macroblock for future predictions) and in the decoder (before reconstructing and displaying the
macroblock). The filter has two benefits: (1) block edges are smoothed, improving the appearance of
decoded images (particularly at higher compression ratios) and (2) the filtered macroblock is used for
motion-compensated prediction of further frames in the encoder, resulting in a smaller residual after
prediction. (Note: intra-coded macroblocks are filtered, but intra prediction is carried out using
unfiltere d reconstructed macroblocks to form the prediction). Picture edges are not filtered."

this sort of filtering is a BAD thing and shows that desperate measures are employed;this just blurs the image (few nice illustration shots in this pdf....both blocked and filtered images look like crap;one is full of blocks,and another is blurred like freakin' rv9!)
(perhaps this is the link to get pdf's
http://www.vcodex.fsnet.co.uk/h264.html )

There is a huge difference. H264 is storing block residues against "deblocked" reference picture, not against simply unquantized picture. This way, the residues to store after motion compensation are way smaller.


Try encoding a 100kbps video, using SP or MP, you will quickly understand how this could be beneficial.

you're right,but in your first answer you mentioned decoding only...(as if deblocking was done by decoder alone).....
and it's done on encoding and decoding...

indeed,there's a difference;vdub/avs filters don't work with macroblocks,but with complete image etc.
this IS different filtering,but i doubt 100kbps will look good with any codec that exists today....it needs lores,and then blocks' relative size is big and blocking/blurring is very visible no matter you in-loop filter or not....

if i must choose between blocking and blurring,i'll choose blocking,as noise will help it;noise won't help heal the blurred image as much...
(i had wmv9 versus divx3 on 350kbit images,hmm..where are they when i need them...anyway,after ffdshow post-processing i liked divx3 better...was much sharper...without ffdshow divx3 appeared much blockier than wmv9...)

I did some very short encodes with this encoder when it first came out and wasn't very impressed largely due to because every now and then there would be blocks that would appear all over the screen. Today I decided to have another go at it with some higher bitrate encodes and I must say it is very impressive although my computer struggles to decode at 704x304 at real time. I tested it out on some content that XviD has problems with and I was most impressed very good detail with no bad artifacts except for the weird blocks that appear from time to time. Now if it could only be a little faster

The h.264 in-loop deblocking filter's benefits can be measured both objectively and subjectively and have been documented during the development of the h.264 standard. It's not just a simple blurring, application of the filter varies on a per block edge basis. The usage of the filter is accounted for by the encoder, hence the in-loop name. It does vary based upon bitrate, higher quantization will mean more use of the filter.

bonzi,does that look like key-frame "pumping"?(ie. like overcompressed KF's?)
can you post few subsequent screenshots?jpeg will do...
and also,did you load avs or?

but i thought whol epoint of new codecs is going DOWN with the bitrate,and not up(but ok,this is too early time to say anything about h264)

idioteque,such filters are nothing new......even h261 and h263 have it.....
i didn't said it's just simple blur filter,but just that i didn't liked such filtering....i would be more satisfied if the encoding was so eficient that there was no need for this....

I can't really post any screenshots. It seems to be more of a decoding issue than anything to me. It only seems to happen to me when my computer can't keep up then all the blocks appear and yes this happens even if I use the avs. However, if I load it into virtualdub to try and isolate a frame with the problem none of them have any problems . BTW I personally don't care much about low bitrate as long as the quality is good I'm happy and it is very good with h.264 with the very limited tests I have done so far.

i am pretty sure their decoder filter is borked (or maybe weak cpus cause the blocks?)

Has anyone tried to play these files using mplayer?

Good question. You might have a difficult time playing it in mplayer because of the way it is stored but skal made a tool to extract the bitstream out of the container. Unfortunately he doesn't have the source code for it any longer so there is no chance to use it under windows and I don't have linux installed on any of my computers ATM. However, I can tell you right now that if you used the inloop filter it will look very ugly if it does play in mplayer. If you are going to try turn that off when you encode. I think that bond posted his sample in bitstream as well on doom9 but I cannot get it to play in mplayer. However, I cannot get any other h264 video to play in it either.

anyone tried moonlight?
http://www.moonlight.co.il/cons.php
i'll now dload 1,8MB player and 1MB clip to see what jews did with h264...
(they were claiming that they can make mpeg2 almost as effective as mpeg4,but i didn't checked the real clips....too big dloads for me)

let's see if it works....let's see how same wmv9 clip looks like....

hm is this moonlight "player" a dshow filter?

edit: yep it is, tough i cant get it to work with mainconcept files

i'm having "KF-pumping" issues on
"last orders"(160kbps) trailer.......(although i'm seeing some of those on wmv9 clip too....they probably used CBR mode for wmv9)

even though wmv9 clip has more blocks it looks sharper than h264 clip....(i told you i hate smoothing...heh)

i believe i'm not mistaking if i say that this technology is not mature at all,and it needs more time to become of any use....
(needs faster encoding,faster decoding,compatibility etc.)

i'll leave it at that for now.....

Very much so. This encoder is not too far removed from the expert's group reference encoder as far as both it's speed and quality is concerned. Real world h.264 is still in it's infancy, but in my opinion shows much promise. We'll just have to wait a bit longer. (but hopefully not too long!)

@bond:excellent job mate;now my links are listed in doom9 news section...ohh what an honour(LOL!)

but somehow,someway,i find ateme/ti to be much more interesting
http://www.ateme.com/products/mpeg4.php
http://focus.ti.com/docs/general/splashdsp...data/dm64x_home

where are mpeg4 on-die codecs we all dream about....damn that mpeg2/dvd industry!

quoting bond from doom9 ( http://forum.doom9.org/showthread.php?threadid=71396 ) ;

is the correct answer;"same as they do now"...?

sorry,but i *just* couldn't resist....