Ateme H.264 Beta - Bug, Issues and Getting Started

[bobololo]

Originally posted by Soulhunter
Should be, I raised the brightness @ both samples equally !!!

Seems there is some sort of "smoke" in the Ateme encode that shouldn't be there... :confused:

Maybe this part of the frame belongs to a different frame much later or so ???

I'm trying to reproduce your encode. Can you provide your avs script and the encoding settings you used please ? Thanks.

[CruNcher]

Maybe this part of the frame belongs to a different frame much later or so ???


hmm sounds like the old XviD B-frame prediction problem do you tried it without b-frames is it still visible ?

[Soulhunter]

Originally posted by bobololo
I'm trying to reproduce your encode. Can you provide your avs script and the encoding settings you used please ? Thanks.
I used this (ftp://ftp.heise.de/pub/ct/spezial/shuttle.mpg) source, and....

- De-interlaced it (blend fields)

- Centered the image (dunno the exact parameters anymore)

- Feeded it to FFVFW (IIRC I added some noise)

- Resized it to 1024x576 with Lanczos

- Encoded it to FFV1 (size around 1.05 GB)

- Feeded this via Avisyth (DirectShowSource) to the encoder (settings @ page 10)


Sounds a bit confusing, huh... :o


But maybe I already found the reason for this !!!

Atm I dunno if my premonition is right, but...

I will post back later !!!


Bye

[Soulhunter]

Originally posted by CruNcher
hmm sounds like the old XviD B-frame prediction problem do you tried it without b-frames is it still visible ?
Assumed the same thing, but...

After rising the brightness of the source even more, I realized its already there !!!

Its no smoke, its a very weak flood-light !!!


But @ the Anteme encode its much brighter and "floating" around !!!

Disabling b-frames doesn't help...
____________________________________

EDIT:

Removed, coz probably misleading !!!

Read the stuff below...
____________________________________

Btw, Ive re-done this "too bright flood-light" encode...

Got exactly the same results !!!


Bye

[Bulletproof]

Try disabling the "part" encoding option, maybe that might help.

[Teegedeck]

So here finally come my first test results; I merely tested an 81-frames-long clip from the HDTV Matrix 3 trailer (rev_theatre_0x10383910_1024_dl.mov with "trim(1431,1512)", no filtering of course) and it took me 3 hours... 31 files were encoded in the process.

The clip apparently wasn't a problem-sample as I encountered no bugs of any kind.

Aims
I value a clean test-setup very highly, so please excuse me if I tell you in detail:

Test results aren't worth anything if you aren't 100% sure how to interpret them. So the first question to ask myself before a test is: What do you want to find out?

My personal usage of codecs dictates that I want to find transparency in a codec. I don't care for internet-streaming, I want backup-copies of my stuff that I really cannot tell from the original ("transparency").

So, the first question to this new codec is: Can it deliver transparency?

If Ateme h.264 manages to reach transparency, the next question would be: Does it do that at a lower bitrate than MPEG-4 ASP (XviD)? Otherwise there would be little point in using it. From a technical viewpoint, H.264 should do so easily. Personally, I would be disappointed with anything less than 1/3 bitrate-savings.

The test procedure I've used was as follows:

Setup
Choice of sample
About the selection of the clip: My thought is such that a scene should be tested which would show the problems that arise from a bad codec configuration most visibly. As our eyes are best trained at recognizing faces (we look at faces all the time...), we spot differences here first. So I opted for two short closeups of the faces of agent Smith and 'that other guy with blood all over his chin'. An action sequence would not be my choice because the eye just doesn't manage following too much motion and I don't want to compare screenshots, it's a second-rate quality indicator.

Tested switches
What else is important to say about the test-setup? I used a fixed quantizer because I don't want to test the performance of the two-pass or ABR algo for now.

Not all switches were tested because it would make the test too complex. CABAC, b-frames, data partitioning, h-pel and q-pel were always left on because they should help and I trust the programmers knew what they were doing. I would only expect benefits from switching them off if the codec exhibited problems that point to a buggy implementation.

Switches were tested in a sensible order. As my aim is transparency, all switches that potentially blurr or alter the picture in any other undesirable way were spared till the end. These switches were -deblock and -psy.

Actual test
First I tried to find the highest quantizer that still delivered transparency for me, using the highest encoder quality and only varying the quantizer (deblocking switched off). Actually, my first guess (-qp 20) wasn't so bad (but then again I did play with quant 25 when I first received the encoder and it turned out non-transparent). My result was that "-qp 19 -qual extra -clref deblock" is the highest compression that produces a transparent encoding of this specific clip for me. The encoder quality will be tested in the end to see whether any quality is lost with it.

-qp 20 was the quantizer that was just about not transparent anymore. Now I tried using other features to find out whether I could push the limit of transparency up by one quantizer.

I tried to increase the number of reference frames, which should not alter the picture in any way. I used -ref 5 and -ref 16 but at least for this short test-clip they didn't help the quality in any way.

Next tested whether -psy or -adaptdeblock -deblock helped at quant 20 (the simple -deblock optioin didn't seem so good to handle when I first had a go at it with beta1).

After numerous tries it turned out that (to my surprise) indeed "-adaptdeblock -deblock -3 " made quant 20 look just about transparent to me. (I'm still not absolutely sure whether I would use it, though, or would rather prefer to play it safe). -psy didn't seem to do anything good for an encoding that should yield transparent results.

Now I tested whether I could get away with lowering the encoder quality. The result was that lowering it to 'normal' quite drastically increased the filesize at unchanged picture quality. I could not produce or perceive any difference between -qual best and -qual extra though.

The final step was to compare the quality and bitrate to an XviD (1.1) clip which is just about transparent to me. The clip was encoded with the SixOfNine matrix at quant=4; adaptive quantization was used, trellis, quarterpel, gmc, vhq=4 (for b-frames also), the defaults.

Results
The visual quality was indeed the same (i.e. excellent) - otherwise I would have gone wrong somewhere because transparent is transparent.

Now, if the bitrate of the Ateme clips was about 1/3 lower than that of the XviD clip I'd call it a successful showing of H.264's capabilities. If it was even lower, I'd call it a BIG success.


Filesizes:
Ateme h.264 at -qp 19: 893 kb
Ateme h.264 at -qp 20: 696 kb
XviD at quant=4: 1006 kb

Ateme at -qp 19 was 11.23% smaller than XviD.
Ateme at -qp 20 was 30.81% smaller than XviD.

Caution: These values are results of testing a virtually no-motion clip. Actual values may differ quite a lot. ATM I am encoding the complete trailer in order to find out how filesizes look on high-motion scenes. I will let you know when I'm done.

The bottom-line after testing this sample is: Ateme h.264 fulfilled my expectations for a good h.264 implementation. A competitive codec. My congratulations go out to its developers.

One also has to remember few people are nearly as geekish as I am (or watch their stuff on a 19'' Eizo TFT). Using the -adaptdeblock option in a cautious way lets you raise quantizer still a little to reach XviD SixOfNine-HVS quality for example. Most people will be perfectly sound to call a "-qp 23 -adaptdeblock -deblock 3 -qual extra" encoding transparent (which is only 315 kb in size and still comparable to XviD with SixOfNine-HVS and 978 kb - i.e. at 32.2% its filesize).

A short round-up of the settings mentioned:

TRANSPARENT (comparable to SixOfNine at quant=4):

-qp 19 -qual extra -clref deblock
-qp 20 -adaptdeblock -deblock -3 -qual extra

comparable to SixOfNine-HVS at quant=4:
-qp 21 -adaptdeblock -deblock -2 -qual extra

smallest filesize at acceptably-near-to-transparent quality (a little worse than XviD at SixOfNine-HVS):
matrix -qp 23 -adaptdeblock -deblock 3 -qual extra

(-qual extra could be replaced by -qual best)

UPDATE: I just finished encoding the whole trailer and now the results are closer:

XviD at quant=4: 105 MB;
Ateme at -qp 19: 98.4 MB (6.29% smaller)
Ateme at -qp 20: 87 MB (17.14% smaller)
[edit: The original trailer is 100 MB in size...]

It would seem XviD handles lots of motion and detail very well for a humble MPEG-4 ASP codec. :)

Edit: In the light of these last results, Ateme h.264 seems very good, its edge over XviD for high-end encodings is still small ATM though. More filesize comparisons at the above settings are to follow. I'm gonna test other clips in order to verify transparency at -qp 20, too.

[Soulhunter]

Originally posted by Bulletproof
Try disabling the "part" encoding option, maybe that might help.
Wow, you are right...

After disabling "part" the brightness of the spot-light seems to be correct !!!

- Sample without part (http://img86.exs.cx/my.php?loc=img86&image=Ateme_noPart_550.png)

But if you look close enough, you still see some blocks... :(


Bye

[Soulhunter]

Gah, I got the same symptoms* with a trailer of Terminator 3...

* Means -> Increased brightness & blocks @ parts of some frames !!!

-qual best -rcmode 2pass -br 6000000 -psy 0 -maxb 1

- Source sample (http://img86.exs.cx/my.php?loc=img86&image=T3_Source_1672.png)

- Ateme sample (http://img86.exs.cx/my.php?loc=img86&image=T3_Ateme_1672.png)

But the rest of the encode looks great... :rolleyes:

Gonna encode without "part" to see if it helps here as well !!!


Update:

Nope, disabling "part" does not help in this case... :(


Bye

[superdump]

Soulhunter: I still see the light patch personally. I'd say without part but with cabac it looks about the same as with part but without cabac, maybe sightly worse. It's still not as good as the original though and that light beam has still been enhanced.

[Teegedeck]

It doesn't take much to produce such an effect. Use Didée's semi-insane matrix and you can experience similarly interesting enhanced lighting in XviD, too. So I don't think it is a bug in any of the fancy features.

[bobololo]

Just a little note about our latest fixes/improvements :

- The AviSynth DirectShowSource() issue is fixed. With the current filters a nasty typo prevent mp4 files to be correctly sourced by DirectShowSource(). So don't waste your time tweaker your filters config, it's our fault ;)

- GraphEdit couldn't save the graph when it includes our source filter. This was also caused by another nasty typo ! It's fixed now.

- mp4muxer.exe missed to truncate an existing file. It is fixed.

- The process priority of encavc can be set by the '-priority <prio>' option.

- Last but no least, the bskip jumping blocks issue has received a solution that clearly improves the problem. But still need to be extensively tested.

All these fixes are to come in the next beta expected by the begining of next week.

-- bobololo.

[virus]

Originally posted by bobololo
All these fixes are to come in the next beta
:(

quoting from the Nero Recode 2 official page (http://www.nero.com/en/631943759476949.html):
System Requirements

Microsoft® (Windows) 98, 98SE, ME, 2000, XP, Server 2003
Pentium Celeron 800Mhz (Minimum)
128 MB RAM
Up to 4.8 GB hard disc space (for Image files)
Screen resolution at least 800 x 600 Pixel, 16 Bit colour depth or higher
DVD recorder
could some of the other beta-testers please support my request (yes, even if you run XP)? I see the devs implementing even the unneeded small options (like "-priority") ignoring that the files are completely unplayable under one of the supported platforms. This is normally considered a critical issue and usually receives a very different level of attention. Thanks in advance for your support!

virus

[bobololo]

Originally posted by virus
:(

could some of the other beta-testers please support my request (yes, even if you run XP)? I see the devs implementing even the unneeded small options (like "-priority") ignoring that the files are completely unplayable under one of the supported platforms. This is normally considered a critical issue and usually receives a very different level of attention. Thanks in advance for your support!

Yeah I'm sorry, please consider that this beta is not a recode beta. The codec itself is completely cross-platform but our tools which integrate the codec may have flaw when running on old platform like Win9x. These tools have nothing to do with the final product.

We're doing our best to try to make them work on your plateform as it was previously done following your report on encavc. But with regarding to your filter registration problem we have no hint of what could happen. Have you succeeded to register the filters that came with beta-1 ? Do other filters like ffdshow, divx, etc work fine ?

-- bobololo.

[Sirber]

I got H264 working. I'll try to get the best settings for low bitrate anime.

[virus]

Originally posted by bobololo
Do other filters like ffdshow, divx, etc work fine?
man, you have quite a dark opinion of "the life with Win98SE" :)

Let me say that in the last 2 years I've found only 3 programs (in which I'm interested in) out of ~100 that don't work under Win9x: ICL8, DRF Analyzer and your DirectShow filters... (encavc works OK now)

I have XviD, VP6.2, DivX, 3ivX, ffdshow/ffvfw. All of them run fine. The only clue I have is maybe a conflict with the 3ivX muxer/splitter (which I use for .MP4 support). But the Ateme filters (from both beta-1 and beta-2) are simply not registered, despite the "registered successfully" messages printed out. As a matter of fact, if I try to un-register them the regsrv32 application hangs because there's nothing to un-register ;)

If you want me to check my System Register and report back if all the needed keys are created correctly please let me know. (and don't be so pessimist and suspicious, life under Win98 is still very, very easy & beautiful, even in 2004! :D)

[Tommy Carrot]

Well, i was using win98se up until last month (the reason i decided to change the OS was Doom 3 :p), and i remember a few cases where win98 had problems with registering something because of the long filenames. When i renamed them to 8+3 char form, the windows didn't have issues with the registering anymore. Perhaps this might be be your case too.

[virus]

Originally posted by Tommy Carrot
When i renamed them to 8+3 char form, the windows didn't have issues with the registering anymore. Perhaps this might be be your case too.
Thanks for the suggestion Tommy, but it doesn't work :(
GSpot keeps reporting the filter as "not registered":
Src Property Value
- - ** Problem ** ** Codec not registered
DSH Friendly Name Ateme H264 Decoder
DSH DirectShow CLSID {7E68F9E8-EAFA-4C02-A9FD-BA39F2D95C4A}

[Sirber]

Maybe you're missing some DLLs.

I still haven't found a way to get my clip whitout ugly blinking blocks :(

[bobololo]

@virus: I was just thinking, have you tried latest NeroVisionExpress filters ? Even they don't seek properly, they can let you watch your encodes.

@Soulhunter: can you upload your resulting t3trailer mp4 file that shows these blocks ? It seems the bitsream is broken. It's maybe related to the cabac and we need to check the file. Thanks.

@Teegedeck: very interesting experiments you've done here. I'd like to know if you think that transparency is reached whatever the source you encode at Qp 19 or is it only valid for the clip you mentioned ? Actually, depending on the source type, the compression ratio to get transparency can change a lot.

What is also outstantind in your tests, is that you actually evaluated the raw coding efficiency of our encoder (ie without RC). Your conclusions should make people realize about the high coding efficiency potential of H.264 which is really superior to MPEG-4 ASP. And more is still to come, our codec is quite young and hasn't exploited all the possibilities yet.

Finally, I would suggest you to try regulated modes which also improve the coding efficiency by using a smart bits allocation over the whole sequence. And I wouldn't be suprised it you could get transparency at lower bitrate.

[RadicalEd]

Originally posted by Sirber
I still haven't found a way to get my clip whitout ugly blinking blocks :(

Are you using B-frames? They don't seem to like anime :/

[virus]

Originally posted by bobololo
@virus: I was just thinking, have you tried latest NeroVisionExpress filters?I've been unable to d/l the free trial version of Nero6 ("New free demo package will be available soon"...), how can I find a direct link to the latest NVE demo or something similar?

EDIT: now downloading the standalone NVE package. I have no idea if I can install it...

[bobololo]

Originally posted by virus
I've been unable to d/l the free trial version of Nero6 ("New free demo package will be available soon"...), how can I find a direct link to the latest NVE demo or something similar?

http://nero.com/fr/download_nero6.php?pak=2&serv=de

[virus]

Eureka! :)

The standalone NVE update package is sufficient, even without Nero6. Showtime refuses to start ("your demo version is expired"... LOL) but I can open, watch & pause the encodes in the other players, at least. Seeking b0rks everything, but hey, we're improving, aren't we? :D

[Sirber]

I think the motion estimation engine is too fast and have problem detecting motion in anime content. Look at the sample in page 8.

[CruNcher]

@Soulhunter

I encoded the t3trailer with your settings no problems here hmm
65,7 MB (68.921.605 bytes)

except one wich i allready reported

[thegeby]

Has anybody else had this problem?

On some of our computers the reg.bat returns with a message from regsrv32: "LoadLibrary ("adf_srcmp4.ax") failed - The specified module could not be found". They all have NET Framework 1.1 installed.

The only computer that does thes reg.bat flawlessly unfortunately runs Intel Extreme (not) Graphics. I am very frustrated as after several encodes, I still cannot verify the quality properly, due to the dodgy graphics in my system.
Help!

[Manao]

thegeby : look at the third post of that thread : you need msvcr71.dll in order to register successfully the filters.

[SeeMoreDigital]

Originally posted by Sirber
I think the motion estimation engine is too fast and have problem detecting motion in anime content. Look at the sample in page 8. Sirber... I don't seem to be able to "lock on" and download your sample!

It might be traffic... so I'll keep trying...


Cheers

[Teegedeck]

Originally posted by bobololo
I'd like to know if you think that transparency is reached whatever the source you encode at Qp 19 or is it only valid for the clip you mentioned ? Actually, depending on the source type, the compression ratio to get transparency can change a lot.
You are of course quite right. I chose a clip where non-transparency is very easy to detect, so the constant-quality setting I chose could be called the 'extreme' preset. I am going to test on other sequences.

BTW, my findings from an overnight encoding session are perhaps not so pleasing for you: I compressed an episode of Starsky & Hutch (not so perfect quality). The settings which I rated 'just a little worse than XviD & SixOfNine-HVS @quant4' (actually somewhere between quant 4 and 5), "-qp 23 -adaptdeblock -deblock 3 -qual extra" produced an output of 527 MB. XviD & SixOfNine-HVS @quant4 produced an output of 525 MB. What can I say? Good ME in XviD. ;) Or maybe MPEG-AVC is even more dependent on clean sources than MPEG-4 ASP. (On the complete Matrix 3 trailer this Ateme setting produced an output that was 37.05% smaller than XviD @q=4) - which most people will find transparent.

Yes, I would rate the quality of both files pretty much identical. Actually not quite, right now I see that Ateme produced obvious dancing blocks on the face of one actor where XviD didn't - and also on some black background. Well, I did rate this Ateme setting a little worse than the XviD setting initially. I can post screenshots if you like.

[RBF]

1.It is possible to speak early now, but adf_srcmp4.ax does not play mp4 files with two audio tracks.

2. The -qp parameter works only in vbr-mode , or it is possible to limit maximal quantiser in 2 pass-mode?

[thegeby]

Manao: Thanks.

I had thought that the fact that I had installed Net Framework would cover that, but when checking, I found that NET does not install the file to the System32 folder. A quick copy/paste solved the problem.

[Soulhunter]

Originally posted by CruNcher
@Soulhunter

I encoded the t3trailer with your settings no problems here hmm
65,7 MB (68.921.605 bytes)

except one which i already reported
My encode has a size of 68.867.500 Bytes !!!

Source was a HQ DivX files...

Originally posted by bobololo

@Soulhunter: can you upload your resulting t3trailer mp4 file that shows these blocks ? It seems the bitsream is broken. It's maybe related to the cabac and we need to check the file. Thanks.

Sure, but where to upload this file... :confused:

Maybe here (ftp://nero.ateme.com/incoming) ???


Bye

[Mr_Schizo]

Can anybody test the -par setting on a small clip? Seems to be brocken here (the dshow filter ignored it and played the clip as 1:1).

thx

[CruNcher]

@Soulhunter

Are you sure it's not in the source my was from the DVD trailer
maybe a problem in combination with the DivX filter tough hmm

[virus]

ok, it's finally time to report back some impressions. I cannot do a proper comparison without seeking capabilities nor a working DirectShowSource(), so I decided to go for a high-motion clip (1000 frames) with the sea, some close-ups on faces, a bit of superimposed text and some underwater frames, just to see how well encavc retains detail. Of course the differences in such a clip can only be spotted by a careful frame-by-frame comparison... (which is the only thing I can do right now, until either the NVE or the Ateme filters are fixed)

I used XviD (with deblocking) and VP6.2 (sharpness 7, with deblocking only) at their best settings for comparison. Clean DVD source at 560x304 @ 25fps, Lanczos resized. Commandline used for AVC:

-rcmode 2pass -qual extra -br 1781000 -ref 3 -adaptdeblock

keep in mind that this rate is roughly 70% of XviD 1stpass size (I'll try lower bitrates with the fixes in beta-3). No postprocessing at all for encavc, in perfect H.264-style ;)

Needless to say, at this rate the in-loop filter was under investigation... at a first sight, I didn't like how encavc blurred some frames. But the in-loop filter is not to blame. I simply re-encoded without B-frames and the blurring disappeared ;)
Without B-frames, encavc delivers better detail preservation than VP6.2 (which was the reigning champ on this clip and doesn't use B-frames too) and much less artifacts than XviD, which heavily needs a deringer here.
Ateme's codec managed to reach near-transparency on several frames, especially in the very difficult underwater sequence. Right now I'm going to experiment with the in-loop deblocker to see if I can get even more detail and what the effect of -adaptdeblock actually is. I will also try to find out at what bitrate encavc is roughly on par with VP6.2.

stay tuned :)
virus

[Soulhunter]

Originally posted by CruNcher
@Soulhunter

Are you sure it's not in the source my was from the DVD trailer
maybe a problem in combination with the DivX filter tough hmm

The source looks fine -> the source frames ;)


About the DivX filter...

Dont even have DivX installed atm, I use ffdshow for decoding !!!


But...

If I encode the DivX -> FFV1 and use this as source, I get the same result !!!

But ffdshow is used for FFV1 decoding as well, no... :rolleyes:


Maybe I should use uncompressed input to check if ffdshow is the culprit ???


Btw, Ive cutted this shuttle source down (750 frames / the problem part) n' encoded it again...

Surprisingly the problem is no more visible with this shorten input !!!


Bye

[bobololo]

@sirber: Currently our bframe are not very good at low bitrate, this could explain your remarks on your clip. Some improvements were done lately and will be integrated to the next beta. Meanwhile, could you upload your source so we can reproduce your encode (ftp://nero.ateme.com/incoming) ?

@Soulhunter: yes this is the right place to upload.

@Teegedeck: Your note about "Starky & Hutch" matches precisely with my previous remarks. When encoding at constant quantizer you have a high risk of wasting much bits when it's useless. For a better understanding, consider it's common to have picture size variation in a factor of 2 or 3 when changing +/- 1 quantizer step for a result being nearly transparent (~0.1 dB PSNR). In your case, for a long clip with different types of sequence, you'll need to use the lower quantizer to achieve the overall transparency which may conduct to a quantizer that happens to be too high for many other sequences.

Actually AVC size versus quantizer behaviour is quite more "nervous" than ASP especially if you use bframe.

Basically, IMHO your experiment -trying to find the Qp for transparency and then check the size- is quite valuable for short sequence where the contents is homogeneous. Although, for longer and diversified clips, if you want to see the efficiency of AVC, you really need to rely on a good RC able to correctly estimate size/Qp and to allocate bits wherever is it needed and save lots of bits transparently when it's possible. This in order to achieve optimal quality. To give you an idea, with 2pass RC we usually reach around 0.5 to 1 dB PSNR increase compared to a constant Qp encode for the same bitrate.

-- bobololo.

[Sirber]

Uploading. name: test.avi :D

[Soulhunter]

Feeding a uncompressed source...


1. - The source DivX -> Uncompressed RGB (http://img80.exs.cx/my.php?loc=img80&image=RGB_Source.png) with VDubMod

2. - Uncompressed RGB -> served via AviSynth... (http://img80.exs.cx/my.php?loc=img80&image=Source_AVS.png)
DirectShowSource("C:\Blah.avi").ConvertToYV12().KillAudio()
3. - Ateme "encodes" (http://img80.exs.cx/my.php?loc=img80&image=Encoder.png) this AVS source

4. - The result... (http://img80.exs.cx/my.php?loc=img80&image=Resulting_MP4.png)


Ehm, what happened here ???

Serving this AVS -> VDubMod -> XviD works excellent... :confused:


Bye

[Soulhunter]

Originally posted by bobololo
@Soulhunter: yes this is the right place to upload.
Ok, gonna upload "Soulhunters_T3_Clip.mp4" now !!!


Bye

[anonimitous]

@ Soulhunter
AFAIK Converting YV12->RGB24->YV12 isnt lossless with out subsampling .

[Teegedeck]

Originally posted by bobololo
@Teegedeck: Your note about "Starky & Hutch" matches precisely with my previous remarks. When encoding at constant quantizer you have a high risk of wasting much bits when it's useless. For a better understanding, consider it's common to have picture size variation in a factor of 2 or 3 when changing +/- 1 quantizer step for a result being nearly transparent (~0.1 dB PSNR). In your case, for a long clip with different types of sequence, you'll need to use the lower quantizer to achieve the overall transparency which may conduct to a quantizer that happens to be too high for many other sequences. I hope your understand that and have some patience with me.

Actually AVC size versus quantizer behaviour is quite more "nervous" than ASP especially if you use bframe.

Basically, IMHO your experiment -trying to find the Qp for transparency and then check the size- is quite valuable for short sequence where the contents is homogeneous. Although, for longer and diversified clips, if you want to see the efficiency of AVC, you really need to rely on a good RC able to correctly estimate size/Qp and to allocate bits wherever is it needed and save lots of bits transparently when it's possible. This in order to achieve optimal quality. To give you an idea, with 2pass RC we usually reach around 0.5 to 1 dB PSNR increase compared to a constant Qp encode for the same bitrate.
Certainly I'm going to test the merits of Ateme h.264's RC as well - but all in due time. Pure encoder performance is what I am curious to see now. RC or two-pass code is pretty independent of the codec itself, meaning you could probably plug XviD's RC on top of an H.264 codec with a small rewrite or vice versa. The RC hardly is the innovative part of H.264 that sparked so much interest that it made it as an amendment into the MPEG-4 specs. ATM I want to see the pure performance of its multiple reference-frames, CABAC, in-loop filtering etc.

If I would have tested two-pass with Ateme I would have tested two-pass with XviD, too, of course, so don't trust that this would have brought the Ateme encode ahead (hehehe) of the XviD encode again.

Don't worry, I, too, want to test real-life use (1-CD, 2-CD encodings) but this will be much easier to do when I have an idea which features to use at what bitrate and what quantizer for example will be just too high for certain content.

BTW; wouldn't it be a good idea to automate the strength of adaptive deblocking for two-pass in a way that links it to the current-frame quantizer?

I also was surprised that one step in quantization caused such huge differences in filesize ("nervous" alright). Isn't there any way to have finer quantization steps? This turned out very useful when insightful people created their own custom matrices for XviD.

[ac-chan123]

@ Soulhunter :
try any real uncompresed source from:
- http://www.vqeg.org (Video Quality expert group)
- http://www.cipr.rpi.edu/resource/sequences/
- http://eeweb.poly.edu/~yao/VideobookSampleData/video/
- http://www-i4.informatik.rwth-aachen.de/~imed/
- http://www.hhi.fraunhofer.de/german/bs/HiCon/downloads.htm
...

[Soulhunter]

Originally posted by anonimitous
@ Soulhunter

AFAIK Converting YV12->RGB24->YV12 isnt lossless with out subsampling .

Yes, I know... :rolleyes:

But I dont think that a color conversation is able to drop the filesize from 66MB -> 180kb !!!

Btw, I can play the resulting file, but I get only a black picture... :(


@ ac-chan123

Thanks for the links... :)

But I dont get why a "uncompressed" source should be different* than my converted one !!!

* I know that some info is lost while YV12->RGB->YV12 conversation, but...

That what the encoder gets is a raw YV12 source (IIRC YUY2 wont work) !!!


EDIT:

Found a solution for the raw YV12 -> encoder problem !!!

While DirectShowSource works not correctly with the encoder, AVISource does... :confused:

But, is this a bug in the decoder or in the encoder ???


Bye

[Soulhunter]

Update:

Ok, feeding the encoder with raw Y12 (bypassing ffdshow) does not help !!!

I still get this image distortion... :(


@ bobololo

Do you received my file ???

FileZilla told me that the transmission was completed...

But I cant see my file @ the index, its still shown as empty !!!


Bye

[ac-chan123]

The raw yuv files are better to compare with the encodet one, because ther is no decoder interpting space. Also this are sequences wich are used by most of the commercial encoder programmers and tester(like magazine). This sequences have alle somthing that is not easy to encode.

[Soulhunter]

Originally posted by ac-chan123
The raw yuv files are better to compare with the encoded one, because their is no decoder interpting space. Also this are sequences which are used by most of the commercial encoder programmers and tester(like magazine). This sequences have all something that is not easy to encode. Ok, I gonna use them later -> for my "detail" tests... :)

Thought the links where regarding my ecoding problems !!!

Btw, does someone know why raw YV12 input via DirectShowSource doesnt work ???


Bye

[ac-chan123]

this yuv file have no header, this are pictures only(multiple in one file). use the rawsource filter from warpenterprises( http://www.avisynth.org/warpenterprises/ ).

[LostMP4]

Originally posted by Mr_Schizo
Can anybody test the -par setting on a small clip? Seems to be brocken here (the dshow filter ignored it and played the clip as 1:1).

thx

Don't worry, Recode filters play the file and handle PAR correctly, but they can't seek (until next update?)

[virus]

I have a question on the deblocking strength (used together with -adaptdeblock). I've re-encoded the same test clip mentioned before with deblock strength -4 and -6 (the original clip was at the default -2). The 3 files obtained have exactly the same size, and they only differ for a few bytes near the end... here's an excerpt from the "fc /B" output:

....
0087FE68: FA E8
0087FE6B: 67 6B
0087FE6C: FA E8
008810B6: 67 6B
008810B7: FA E8
008810BA: 67 6B
....

This is the comparison between -4 and -6. Similar output happens comparing with -2. Apparently, almost nothing changed between -2 and -6, which is quite a big difference. I wonder if this is normal (shouldn't -adaptdeblock vary the filtering strength around the specified value?).

BTW I've determined on the aforementioned clip that encavc shows a comparable amount of detail with the best performing competitor (VP6.2) at roughly 200 kbit/s less... that's a ~11% saving. Impressive indeed :)