About the x264 new progress

[PegasusJack]

Hello, I got some information about X.264 a GPL opensource H.264 codec.
Somebody tested the codec in a P4, 1.7G, 256MB, DDR, W2K. Test file is: news.yuv CIF 300 frames.
The testing performance listedas below:x264: overall Qp= 1 PSNR Y:60.01 U:59.49 V:60.09 6580.0kbps fps:20.302
x264: overall Qp= 2 PSNR Y:57.62 U:57.35 V:57.67 5895.0kbps fps:21.245
x264: overall Qp= 3 PSNR Y:57.09 U:56.94 V:57.20 5642.4kbps fps:20.597
x264: overall Qp= 4 PSNR Y:55.21 U:55.06 V:55.24 5000.0kbps fps:21.130
x264: overall Qp= 5 PSNR Y:54.62 U:54.61 V:54.83 4746.2kbps fps:21.242
x264: overall Qp= 6 PSNR Y:53.32 U:53.33 V:53.53 4175.6kbps fps:22.047
x264: overall Qp= 7 PSNR Y:52.69 U:52.65 V:52.92 3795.1kbps fps:22.594
x264: overall Qp= 8 PSNR Y:51.72 U:51.68 V:52.01 3259.4kbps fps:22.672
x264: overall Qp= 9 PSNR Y:51.19 U:51.12 V:51.54 2994.3kbps fps:22.521
x264: overall Qp=10 PSNR Y:50.30 U:50.31 V:50.87 2608.3kbps fps:22.636
x264: overall Qp=11 PSNR Y:49.61 U:49.75 V:50.54 2278.9kbps fps:23.585
x264: overall Qp=12 PSNR Y:48.77 U:49.01 V:50.00 1929.5kbps fps:24.584
x264: overall Qp=13 PSNR Y:48.14 U:48.55 V:49.59 1708.8kbps fps:25.407
x264: overall Qp=14 PSNR Y:47.41 U:47.99 V:49.05 1475.1kbps fps:25.274
x264: overall Qp=15 PSNR Y:46.73 U:47.54 V:48.55 1280.9kbps fps:25.952
x264: overall Qp=16 PSNR Y:45.95 U:46.98 V:47.88 1098.6kbps fps:25.471
x264: overall Qp=17 PSNR Y:45.26 U:46.65 V:47.60 919.0kbps fps:28.358
x264: overall Qp=18 PSNR Y:44.55 U:46.18 V:47.10 773.1kbps fps:31.956
x264: overall Qp=19 PSNR Y:44.04 U:45.79 V:46.70 690.2kbps fps:33.670
x264: overall Qp=20 PSNR Y:43.32 U:45.23 V:46.10 588.7kbps fps:36.355
x264: overall Qp=21 PSNR Y:42.74 U:44.81 V:45.62 526.4kbps fps:37.221
x264: overall Qp=22 PSNR Y:42.10 U:44.31 V:45.15 470.1kbps fps:38.730
x264: overall Qp=23 PSNR Y:41.39 U:43.72 V:44.56 409.5kbps fps:39.904
x264: overall Qp=24 PSNR Y:40.70 U:43.16 V:43.96 360.7kbps fps:41.277
x264: overall Qp=25 PSNR Y:40.23 U:42.77 V:43.59 328.3kbps fps:42.457
x264: overall Qp=26 PSNR Y:39.36 U:42.01 V:42.93 280.6kbps fps:43.617
x264: overall Qp=27 PSNR Y:38.72 U:41.56 V:42.49 250.4kbps fps:45.317
x264: overall Qp=28 PSNR Y:38.08 U:41.09 V:42.03 220.8kbps fps:46.722
x264: overall Qp=29 PSNR Y:37.33 U:40.60 V:41.55 192.7kbps fps:47.229
x264: overall Qp=30 PSNR Y:36.60 U:40.63 V:41.57 171.3kbps fps:49.489
x264: overall Qp=31 PSNR Y:36.03 U:40.05 V:40.93 154.8kbps fps:50.710
x264: overall Qp=32 PSNR Y:35.21 U:39.66 V:40.62 132.3kbps fps:52.938
x264: overall Qp=33 PSNR Y:34.59 U:38.97 V:40.02 116.8kbps fps:54.171
x264: overall Qp=34 PSNR Y:33.88 U:38.91 V:40.03 104.3kbps fps:55.991
x264: overall Qp=35 PSNR Y:33.10 U:38.53 V:39.49 90.2kbps fps:57.815
x264: overall Qp=36 PSNR Y:32.42 U:37.86 V:39.11 79.4kbps fps:59.465
x264: overall Qp=37 PSNR Y:31.86 U:37.82 V:39.07 72.4kbps fps:60.582
x264: overall Qp=38 PSNR Y:30.98 U:37.27 V:38.36 61.0kbps fps:63.171
x264: overall Qp=39 PSNR Y:30.40 U:37.28 V:38.38 55.7kbps fps:64.157
x264: overall Qp=40 PSNR Y:29.75 U:36.60 V:37.97 48.6kbps fps:65.574
x264: overall Qp=41 PSNR Y:28.97 U:36.60 V:37.95 42.9kbps fps:67.431
x264: overall Qp=42 PSNR Y:28.41 U:36.28 V:37.47 37.9kbps fps:69.156
x264: overall Qp=43 PSNR Y:27.86 U:36.23 V:37.42 35.0kbps fps:70.323
x264: overall Qp=44 PSNR Y:27.02 U:36.16 V:37.43 30.5kbps fps:72.376
x264: overall Qp=45 PSNR Y:26.49 U:35.38 V:36.75 27.2kbps fps:73.710
x264: overall Qp=46 PSNR Y:25.81 U:35.35 V:36.64 24.0kbps fps:75.472
x264: overall Qp=47 PSNR Y:25.24 U:35.23 V:36.65 21.5kbps fps:76.687
x264: overall Qp=48 PSNR Y:24.68 U:34.86 V:36.34 19.0kbps fps:77.821
x264: overall Qp=49 PSNR Y:24.32 U:34.84 V:36.30 17.5kbps fps:79.239
x264: overall Qp=50 PSNR Y:23.59 U:34.79 V:36.18 15.2kbps fps:81.103
x264: overall Qp=51 PSNR Y:23.18 U:34.84 V:36.25 14.0kbps fps:81.945

Meanwhile, he announced that this version was based on semi-SSE optimization. So it means the performance can be improved more.
If it was true, X.264 achieved impressive or fantastic porgress.
Did anyboby know more information about the X.264?

PegasusJack

[PegasusJack]

x264: wrapper for libx264 encoder (h264 encoder, you can find it at
http://lyra.via.ecp.fr). use qmin==qmax to change the qp.

But this web seems closed.
:confused:

[kilg0r3]

Hi Ppl

May I ask which app you use to encode in h.264? When I tray to in vdm 'I always get an could not start encode. maybe corrupt data' error.

[PegasusJack]

Originally posted by kilg0r3
Hi Ppl

May I ask which app you use to encode in h.264? When I tray to in vdm 'I always get an could not start encode. maybe corrupt data' error.
Sorry, for me, I am n;t familar with X264. In this ppost, I want to confirm this test result is correct or not. Sorry, I can't give you hand.

Jack :o

[PegasusJack]

This X.264 testing list seems have some problems. We contact with the guy who issued the report. Just a silient answer. I looked through the CVS and found that the authors only used the MMX to optimize the codec. If MMX can achieve this performance, H.264 implementation would be so easily that will be like to make a cake. It is my ops.

Cheers!
PJ

[bond]

PegasusJack, the codec is called "x264", plz dont name it something like "X.264", it makes it hard to find it via search if this gets widely used ;)

[PegasusJack]

Originally posted by bond
PegasusJack, the codec is called "x264", plz dont name it something like "X.264", it makes it hard to find it via search if this gets widely used ;)
Thanks!
:)

PJ

[CruNcher]

btw the main Developer on the x264 codec works since a while now on ateme/aheads H264 implementation and it will be one of the best ones ;)

[Tommy Carrot]

Originally posted by CruNcher
btw the main Developer on the x264 codec works since a while now on ateme/aheads H264 implementation and it will be one of the best ones ;)

I assume it means that he stopped working on x264. :( This explains why the homepage is down since a few weeks ago. Anyway, best wishes to him.

[bond]

Originally posted by Tommy Carrot
[B]I assume it means that he stopped working on x264. :( This explains why the homepage is down since a few weeks ago.yeah, fenrir will not work on it anymore (apart from bugfixes maybe). i wonder who added the vfw wrapper to the codec and whether the one will continue the development?
maybe its also good to move the code to sourceforge, as the code seems to pretty good for a maybe coming "xvid-style" h.264 codec, and sourceforge is far more friendly for multiple developers contributing than a private homepage i assume

[aketon]

Damn, really bad news!:(

I hope that someone is going to continue the development of the x264 codec!

[Tommy Carrot]

Originally posted by aketon
Damn, really bad news!:( Bad indeed.I hope that someone is going to continue the development of the x264 codec! It would be great if the Xvid guys would take the code as a starting point for Xvid2. :)

[aketon]

Originally posted by Tommy Carrot
Bad indeed. It would be great if the Xvid guys would take the code as a starting point for Xvid2. :)

Not just great! It would be a fantastic idea!!!!:) :) :) :) :) :)

[chenm001]

1. The test result from my. That is real!
2. I send mail to fenrir talk about CVS problem, if he donn't work for x264, I will go on in china.

[Bulletproof]

I tried the x264 implentation in ffdshow today, and I find it to be definitely better than Videosoft's version, however I am not finding any stellar performance in terms of compression with it. I heard so many promising things about H.264 and new compression techniques and accuracy, but I am finding current implementations of H.264 don't even match XviD, is it because current H.264 implementations have been cut down to work with less cpu power?

[bond]

Originally posted by chenm001
1. The test result from my. That is real!thx and welcome to doom9 :)

Originally posted by Tommy Carrot
Bad indeed. It would be great if the Xvid guys would take the code as a starting point for Xvid2.surely a nice idea, but from my experiences till now its very unlikely that a xvid devs will start developing a h.264 codec. most of the time the devs prefer on focusing on their beloved "old" baby, than creating a new one :)
i saw this with the lame devs for example, they dont change from lame to faac for example, working on the aac encoder, with which they could reach far more quality in the long run as with mp3, still they prefer to continue tuning lame as much as possible (and rjamorims last test showed how good lame is)

Originally posted by Bulletproof
but I am finding current implementations of H.264 don't even match XviD, is it because current H.264 implementations have been cut down to work with less cpu power?its because the implementations are very young
xvid wasnt always as good as it is now, it got better and better with the years
you should grap one of the first xvid versions and compare them with what xvid is now, than you will realise how h.264 encodes will get better with the time ;)

[CruNcher]

its because the implementations are very young
xvid wasnt always as good as it is now, it got better and better with the years
you should grap one of the first xvid versions and compare them with what xvid is now, than you will realise how h.264 encodes will get better with the time


I couldn't have said it better, but i wonder that Bulletproof doesn't see that it compression wise outperforms Mpeg-4 ASP allready

[Teegedeck]

Compression-wise in the sub-700kbps area, I'd say.

But it doesn't scale well above that, its sweet spot is well below what for example I use.

If one would compare it to MPEG-4 audio, I'd say XviD=LC AAC, x264=HE AAC. I wouldn't use HE AAC if I want a transparent (archival grade) backup of my music collection, but for portable use or streaming (or movie audio tracks) I'd go for HE AAC.

But if development continues that way, H.264 codecs will certainly improve scalability and thus their range of possible uses.

[aketon]

Originally posted by bond
surely a nice idea, but from my experiences till now its very unlikely that a xvid devs will start developing a h.264 codec. most of the time the devs prefer on focusing on their beloved "old" baby, than creating a new one :)
i saw this with the lame devs for example, they dont change from lame to faac for example, working on the aac encoder, with which they could reach far more quality in the long run as with mp3, still they prefer to continue tuning lame as much as possible (and rjamorims last test showed how good lame is)


But XviD is a MPEG-4 video codec! H.264 is MPEG-4! It isn't like mp3 and aac, which are very different! XviD developers, must see it like they just improving their codec!!!!

[bond]

Originally posted by aketon
But XviD is a MPEG-4 video codec! H.264 is MPEG-4! It isn't like mp3 and aac, which are very different! XviD developers, must see it like they just improving their codec!!!! still they are not compatible to each other!
h.264 is not a backwards compatible extension to the "old" mpeg-4 part2 or so, h.264 is a new video coding standard!

[Teegedeck]

Right. MPEG-4 has many substandards for diverse objectives. Like a standard meant for encoding speech etc.

[SeeMoreDigital]

Personally I can't wait to test some open source 2pass AVC encoders!

What about it, all you devs :D


Cheers

[aketon]

Originally posted by SeeMoreDigital
Personally I can't wait to test some open source 2pass AVC encoders!

Me too!!!:)

[Teegedeck]

Well, two-pass will make it easier to reach a certain filesize, but the quality we see already. It would just make life easier. B-frames would perhaps be interesting? ;)

[aketon]

Yeah, b-frames and two-pass are very nice! I want them too! But, there is something missing! A developer maybe???:D

[CruNcher]

I dont think B-frames are that interesting in H264 i mean they shouldn't even exist anymore the only fact they are doing a good purpose would be if it's proved that weighted biderectional prediction really can improve fades from what i see at the moment with VSS 2pass i have my doubts that it's useing this feature.

[cheerow]

I thought the good (if not wonderful) thing about h.264 b-frames was that they can be predicted from other b-frames, while in ASP they are only predicted from I/P-frames. Am I wrong?!?

[PegasusJack]

If the X264 performance is listed as chenm001 or close to his testing result, I think we should close this thread and whole H.264 developement groups (no matter professional or amateur) should adopt X264 frame and source codes. The reason is: Sounds X264 is the best H.264 around world. You know, X264 was based on MMX or SSE (maybe) optimization. I am sure there are no other guy to achieve this testing result if the result is true. Additional, in next one/two years, it is also impossible to get it (using SSE optimization). We just need append some multi-pass, CABAC, B-frame etc Main profile features to the X264. Then you will get a top cutting-edge H.264. Nobody can beat it.

Cheers!
Jack

[Tommy Carrot]

I gotta agree, x264 is far the most progressed h.264 codec, its quality and speed is unparalleled (not that there are so many alternatives :)), it's really just 1 or 2 steps from being ready for everyday use, this is why its so sad that the development is stucked. I hope someone will continue the project.

[CruNcher]

I'ts hard to understand what you trying to say hmm closeing all development why ? Ateme/Ahead was faster getting the guy in their boat to work on their H264 are you know upset about this ? Skal is also working on his implementation Moonlight on theirs Videosoft Mainconcept and many many more on their own. If you now talking about it cant be made faster and competition is useless because of that (and i think thats why you buildin useless encryption into your codec) thats bs.
You doing exact the same like Real or Microsoft trying to rule the market by making something properiaty that is a open standard that's why it's also great to see developers like On2 doing their own stuff and Research in completly different sections :P. I dont know how much your company was involved in researching H264 but Microsoft and Co where so its logic that they have a Advantage but they also Research internaly like On2 and Real for example :D. So that's buisness research something powerfull into your codec or make it better then others is a vital part if you want to rule the market but please don' change something so that it's not interoperable i mean if you don't research vital parts this is a loussy try to get more clients if the rest of the codec is still the same and bitstream compatible.
And you know in the end it only hurts your clients.

Originally posted by Tommy Carrot
I gotta agree, x264 is far the most progressed h.264 codec, its quality and speed is unparalleled (not that there are so many alternatives :)), it's really just 1 or 2 steps from being ready for everyday use, this is why its so sad that the development is stucked. I hope someone will continue the project.

yeah this knowledge now will flood into Atemes/Ahead H264 implemantation and i think thats ok and fen also said he wil still do bugfixing but the source is their as you said waiting to be improved i can only say the Power lies in the RC thats the vital part to be sucessfull with every codec :) you'll see soon what i mean ;)

[Rash]

How do I get 2-pass for x246 on ffdshow encoder?

[CruNcher]

hi chenm001
hey i think i saw you some "surfs" ago on the web searching the H262 Draft looks like you were succsesfull finding them ;)

@Rash
their is no 2-Pass yet for x264
only available 2pass codec to tryout @ the moment with good performance is videosofts h264 5 day trial :P
but still their RC is not good tweaked their is alot that can be improved just my 2 cents.

[bobololo]

Originally posted by PegasusJack
If the X264 performance is listed as chenm001 or close to his testing result, I think we should close this thread and whole H.264 developement groups (no matter professional or amateur) should adopt X264 frame and source codes. The reason is: Sounds X264 is the best H.264 around world. You know, X264 was based on MMX or SSE (maybe) optimization. I am sure there are no other guy to achieve this testing result if the result is true. Additional, in next one/two years, it is also impossible to get it (using SSE optimization). We just need append some multi-pass, CABAC, B-frame etc Main profile features to the X264. Then you will get a top cutting-edge H.264. Nobody can beat it.

Cheers!
Jack

It's very clear that x264 is one the most promising implementation of H.264 but I think it would be a big mistake to consider the current x264 as the ultimate reference encoder. x264 is a very young implementation yet and from a coding efficiency point of view its improvement margin is quite huge. To have an idea of this, just check the plot below which compares x264 coding efficiency againt h.264 reference software (jm). This plot represents the R-D curves of x264 and JM for the encoding of the well known "foreman" sequence.

JM setup was all tools enabled (bframe, 5 ref, cabac, deblocking). x264 setup was cabac, mb partitioning down to psub8x8 (multi-ref and bframes were disable since they gave worse results).

http://cruncher.mufflastig.com/rd.png

As you can see, the difference is quite important (almost 2 dB in the 500 - 1500 kb/s interval). Such gap is not really acceptable for a high quality encoder that has the ambition to become the best all around the word ;)

ps: I don't understand why you say it's impossible to get it in one or two years ?!

-- bobololo

[PegasusJack]

Originally posted by CruNcher
I'ts hard to understand what you trying to say hmm closeing all development why ? Ateme/Ahead was faster getting the guy in their boat to work on their H264 are you know upset about this ? Skal is also working on his implementation Moonlight on theirs Videosoft Mainconcept and many many more on their own. If you now talking about it cant be made faster and competition is useless because of that (and i think thats why you buildin useless encryption into your codec) thats bs.
You doing exact the same like Real or Microsoft trying to rule the market by making something properiaty that is a open standard that's why it's also great to see developers like On2 doing their own stuff and Research in completly different sections :P. I dont know how much your company was involved in researching H264 but Microsoft and Co where so its logic that they have a Advantage but they also Research internaly like On2 and Real for example :D. So that's buisness research something powerfull into your codec or make it better then others is a vital part if you want to rule the market but please don' change something so that it's not interoperable i mean if you don't research vital parts this is a loussy try to get more clients if the rest of the codec is still the same and bitstream compatible.
And you know in the end it only hurts your clients.



yeah this knowledge now will flood into Atemes/Ahead H264 implemantation and i think thats ok and fen also said he wil still do bugfixing but the source is their as you said waiting to be improved i can only say the Power lies in the RC thats the vital part to be sucessfull with every codec :) you'll see soon what i mean ;)

Hello CruNcher;
I guessed you misunderstand my meanings, actually, I strongly support more people involve H.264 development. But, I want to ask if the Chenm001's testing result is axactly accurate. Whole world should be shock including the Real, Microsoft, Moonlight, Videosoft etc. They will automatically stop H.264 or similar video compression development. Becuase according Chenm001's testing, based on MMX, he can achieve 60 fps for CIF. As my exp, he move it to SSE, 2 times, move to SSE2, 2 times, so that he can achieve 2*2*60= 240 fps in P4 2.5 GHz, what mazing thing, he will make. As I know, whole professional video companies such as Videosoft, Envivio, Moonlight etc can achieve this performance based on SSE2, actually, it is impossible. But Chenm001 made it. So I said, we should stop and switch to other fields. Let's Chenm001 do, he and his men are right guys to do if we didn't consider it may be some mistakes in the testing. If he still insist his testing is right, and it proven fully true, I will keep my promise to stop the H.264 developing.
Unfortunely, no other guy give me that same testing report as Chenm001 given. Many people (in China) complained that the X264 performance is beyond the Chenm001's report. They want to get Chenm001's helps to get same testing performance.
I want to say we definitely need some H.264 opensource/share codec development. But we can't depend on some alternative methos to make it up. H.264 development is and will be a serious development. It was not a joke. Some one will ruin this project if we follow using some faked testing results.
It is my comments!

Jack

[CruNcher]

Maybe he used some heavy assembler optimizations i tested the current x264 and i got arround 10 fps @ q20 with CIF resolution on my p4 1.8 he gets 36 hmm sounds a little heavy
i can understand that everyone wants Chenm001 now :D

[PegasusJack]

Originally posted by CruNcher
Maybe he used some heavy assembler optimizations i tested the current x264 and i got arround 10 fps @ q20 with CIF resolution on my p4 1.8 he gets 36 hmm sounds a little heavy
i can understand that everyone wants Chenm001 now :D
Hello CruNcher;
My MMX encoder's performance is 30 fps @Qp20. We will publish the MMX H.264 codec for free download in coming days. Most of codec (in my MMX), we adopted MMX assembler codes. But it took us 6 months (weeks in &out). It was very hard to achieve the performance. Chenm001 made the world so easily. He just leaped 1000% just overnight. How mazing he was!

Jack

[CruNcher]

@Skal
i would really like to hear you coment did you achived those speeds also ?

@PegasusJack
it's not only about speed as i said also quality is important and especialy the Rate Controll

sure its a great step seeing the Reference Encoder Speeds :)
Maybe Chenm001 is a very good ASM coder and worked also for along time on this why didn't he should make it where you need with a team 6 month for in 6 month alone ;) that's the open source spirit :) Geeks :) but i belive Skal could top Chenm001 results even more ;)

Just look for example XviD - DivX same situation but they going on :)

pegasusjack why did you said than this is impossible to reach i mean the Speed ?

[skal]

hi Cruncher,


with h264, encoding speed highly depends on how much time
you want to spend on good decisions (much more than MPEG4-2
due to the great number of additional coding modes).
60fps on my P3 1.13gHz is very reasonable... for MPEG4-2
like quality ;) 90fps and you get MPEG2 quality hehe.
Now, i think a more reasonable value (ie. jm81a-like
quality) is 30fps for CIF coding.

just my 0.06 euros.


bye!
Skal

[PegasusJack]

Originally posted by CruNcher
@Skal
i would really like to hear you coment did you achived those speeds also ?

@PegasusJack
it's not only about speed as i said also quality is important and especialy the Rate Controll

sure its a great step seeing the Reference Encoder Speeds :)
Maybe Chenm001 is a very good ASM coder and worked also for along time on this why didn't he should make it where you need with a team 6 month for in 6 month alone ;) that's the open source spirit :) Geeks :) but i belive Skal could top Chenm001 results even more ;)

Just look for example XviD - DivX same situation but they going on :)

pegasusjack why did you said than this is impossible to reach i mean the Speed ?

First, I think I should stop doubting the Chenm001's cap. He is a genius indeed. Becuase his friend told us that he jsut used Cygwin to opm (in a chinese forum). How great he is! I amworking in China for 1 years, although I worked in USA and Canada. Honestly, I would like to say there few guys know MMX/SSE/SSE2 in china. Even in USA, a good SSE programmer/st eng is very hard to get. Normally, in H.264 opm, you should analysis the C codes line by line and shift it to assembler. It will work but it take time. Many companies did it like this way. If Chenm001's method is work, there are many senior sf engs (SSE expert) will lost their 100K-USD jobs. Because you just need to buy/free download cygwin's dll and recompile your codes, then Bengo! You gotcha. Why we need those expensive guys?
Please allow me to end this topic, Chenm001 gave us some interesting solutions in H.264 optimization in both Entertainment and tech ways.
I can image some truely H.264 Gurus will laugh if they know the so-call Chenm001's X264 optimization methods. Or maybe, they will apply 2004's Turing award for him(her). At least, I will.

Good luck!

Jack

P.S. Now, I found that H.264 development is so easy that like making a cake :-)

[MfA]

Yes yes, I get your point already (which I might add could be considered a small miracle in its own right). How about just waiting for the code ay?

[aketon]

Any news about the development of x264??? Is it going to continue or not???

[justin]

Fenrir and I did the vfw wrapper. I couldn't figure out how to allocate memory for the compress frames and Fenrir did that and setup parameters to call the libx264 functions. Also, fenrir had to edit everything I sent him so it would match the rest of the x264 codebase

I haven't been in touch with him since early May, and I'd like to work on x264 with him but I don't understand the codebase as of now (I only did the vfw and planned to do the deconder and haven't spent enough time understanding the rest), but I won't be spending much time with it (just sporatic) for now because it's summer :)

it would be awesome if x264 or skal's codec rivaled the commercial ones :D

[bond]

if you plan working on a decoder, you should continue what michael niedermayer and fenrir did in ffmpeg :)

[JohnV]

Originally posted by justin
Fenrir and I did the vfw wrapper. I couldn't figure out how to allocate memory for the compress frames and Fenrir did that and setup parameters to call the libx264 functions. Also, fenrir had to edit everything I sent him so it would match the rest of the x264 codebase

I haven't been in touch with him since early May, and I'd like to work on x264 with him but I don't understand the codebase as of now (I only did the vfw and planned to do the deconder and haven't spent enough time understanding the rest), but I won't be spending much time with it (just sporatic) for now because it's summer :)

it would be awesome if x264 or skal's codec rivaled the commercial ones :D Hmm, somehow I doubt that Fenrir will have time or is even allowed to clearly improve x264, since as Bond has said before, he's now working for Ateme.
And I think a project like this really would need many people anyway ala XviD in order to achieve the state of the art.

[chenm001]

I'm donn't say any. If you known SSE you will found that SSE only speedup float operators......
the x264 is opensource, you can test it youself...

Originally posted by PegasusJack
Hello CruNcher;
I guessed you misunderstand my meanings, actually, I strongly support more people involve H.264 development. But, I want to ask if the Chenm001's testing result is axactly accurate. Whole world should be shock including the Real, Microsoft, Moonlight, Videosoft etc. They will automatically stop H.264 or similar video compression development. Becuase according Chenm001's testing, based on MMX, he can achieve 60 fps for CIF. As my exp, he move it to SSE, 2 times, move to SSE2, 2 times, so that he can achieve 2*2*60= 240 fps in P4 2.5 GHz, what mazing thing, he will make. As I know, whole professional video companies such as Videosoft, Envivio, Moonlight etc can achieve this performance based on SSE2, actually, it is impossible. But Chenm001 made it. So I said, we should stop and switch to other fields. Let's Chenm001 do, he and his men are right guys to do if we didn't consider it may be some mistakes in the testing. If he still insist his testing is right, and it proven fully true, I will keep my promise to stop the H.264 developing.
Unfortunely, no other guy give me that same testing report as Chenm001 given. Many people (in China) complained that the X264 performance is beyond the Chenm001's report. They want to get Chenm001's helps to get same testing performance.
I want to say we definitely need some H.264 opensource/share codec development. But we can't depend on some alternative methos to make it up. H.264 development is and will be a serious development. It was not a joke. Some one will ruin this project if we follow using some faked testing results.
It is my comments!

Jack

[chenm001]

How you known what cygwin mean?

Originally posted by PegasusJack
First, I think I should stop doubting the Chenm001's cap. He is a genius indeed. Becuase his friend told us that he jsut used Cygwin to opm (in a chinese forum). How great he is! I amworking in China for 1 years, although I worked in USA and Canada. Honestly, I would like to say there few guys know MMX/SSE/SSE2 in china. Even in USA, a good SSE programmer/st eng is very hard to get. Normally, in H.264 opm, you should analysis the C codes line by line and shift it to assembler. It will work but it take time. Many companies did it like this way. If Chenm001's method is work, there are many senior sf engs (SSE expert) will lost their 100K-USD jobs. Because you just need to buy/free download cygwin's dll and recompile your codes, then Bengo! You gotcha. Why we need those expensive guys?
Please allow me to end this topic, Chenm001 gave us some interesting solutions in H.264 optimization in both Entertainment and tech ways.
I can image some truely H.264 Gurus will laugh if they know the so-call Chenm001's X264 optimization methods. Or maybe, they will apply 2004's Turing award for him(her). At least, I will.

Good luck!

Jack

P.S. Now, I found that H.264 development is so easy that like making a cake :-)

[chenm001]

you must use the gcc to compile, it will be to active asm optimize.

Originally posted by CruNcher
Maybe he used some heavy assembler optimizations i tested the current x264 and i got arround 10 fps @ q20 with CIF resolution on my p4 1.8 he gets 36 hmm sounds a little heavy
i can understand that everyone wants Chenm001 now :D