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

[bobololo]

Ladies and Gentlemen,

And here we go, the beta packages are currently being sent out, so I really suggest you to check your mailbox :)

Please report your feedback in this thread.

-- bobololo.

[superdump]

/me is already testing. :D

[guldukat]

i'm also testing

ps: if you get the LoadLibrary() error message upon registering the directshow filters you need the following dll file msvcr71.dll (http://www.dll-files.com/dllindex/dll-files.shtml?msvcr71)

[JohnV]

Ok, by permission from bobololo, I post the first few clips encoded with the beta Ateme h264 encoder. For optimal playback, download and install the NeroVision Express package (seeking of h264 is broken at the moment though), or if you are a beta tester, you probably received Ateme decoder filters.

The source matrial is not quite optimal quality wise though but it's not horribly big download like most HD content. It's one of the new 1280x720 DivX High Definition clips: http://trailers.divx.com/Universal/BourneSupremacy_HD.zip (34 MB)
so in any case the result from the transcode is not as good as the source DivX.
Also the encoder switches may not be optimal since this is a very new encoder for me and everybody. No preprocessing used.

First clip is about half the filesize of the DivX clip but with the original resolution (1280x720). Video bitrate is 1900kbps
http://nero.ateme.com/beta_encodes/BourneSupremacy_HD_Ateme-h264_1900kbps.mp4

The next is the same but without B-frames, so it's playable with clearly slower computers (plays on my 1.6Ghz laptop with about 70% cpu with ND/Ateme decoder filter):
http://nero.ateme.com/beta_encodes/BourneSupremacy_HD_Ateme-h264_1900kbps_noB.mp4

Third clip is same HD resolution, but video encoded with 1000kbps:
http://nero.ateme.com/beta_encodes/BourneSupremacy_HD_Ateme-h264_1000kbps.mp4

I did some unoptimzed VP 6.2, WMV9 and Real10 encodes at 1000kbps also. Everybody can make their own comparisons, but to me these Ateme h264 clips show very competitive quality indeed.
I havent tested lower than 1000kbps yet, but at 1000kbps and over, quality is indeed very competitive. My results were that at 1000kbps Ateme h264 looked better than VP 6.2 and Real10, and was quite on par with WMV9 with a bit different type of artifacting. XviD couldn't keep up with the quality in my test. All codecs tested with 2pass vbr. But I won't post other codecs' clip because there's a chance my encodes weren't totally optimal, so test yourself and comment.

[Razorblade2000]

it would be cool if someone could do some low-bitrate encoding (480*X and a bitrate of 300 kbit/s)

I am really interested how h.264 performs :D

[superdump]

If you have problems registering (a LoadLibrary() error) the decoder filters you probably need msvcr71.dll. You can obtain it from here (http://www.dll-files.com/dllindex/dll-files.shtml?msvcr71).

[Bulletproof]

Preliminary results for my own testing so far is very impressive. This is the best H.264 codec hands down right now.

[SeeMoreDigital]

Since installing the beta software I've been unable to play ordinary Mpeg4/AAC .MP4 encodes in WMP9 - ShowTime is okay though!

I've just used system restore and all is well again. But has anybody else had problems with this, or is it just me?


Cheers

[bond]

Originally posted by JohnV
The source matrial is not quite optimal quality wise though but it's not horribly big download like most HD content. It's one of the new 1280x720 DivX High Definition clips: http://trailers.divx.com/Universal/BourneSupremacy_HD.zip (34 MB)
so in any case the result from the transcode is not as good as the source DivX.uhm, such sources are far from being optimal, you should use uncompressed or HDTV sources, you will find links to if you use search

[JohnV]

Originally posted by bond
uhm, such sources are far from being optimal, you should use uncompressed or HDTV sources, you will find links to if you use search
Sure, but not everybody can/want to download 200-800MB in order to see the source and test by themselves. This was a compromise and everybody understands that the source is not optimal, still it's relatively decent.

[Selur]

on my system it seems like setting "-ref 16" breaks the clips at least for playback

Anyone having the same problem?

Cu Selur

Ps.:
edit: ref 1, 2, ... (testing atm) work fine

[WaryWolf]

i was having some trouble with the playback filters opening a 800x600 clip, resized to 800x592 and testing it now :)

[JohnV]

Originally posted by Selur
on my system it seems like setting "-ref 16" breaks the clips at least for playback

Anyone having the same problem?

Cu Selur

Ps.:
edit: ref 1, 2, ... (testing atm) work fine
Ateme dev on #mpeg said:
<_babayaga> -ref 5 is a maximum, above it's useless

[Selur]

"-ref 5 is a maximum, above it's useless"
he,he okay thx :)

Cu Selur

[CruNcher]

It can happen that some of your encoded clips do not playback correct in Media Player Classc and couse 100% cpu utilization on load this problem is currently under investigation those clips will play fine via Graphedit and Directshow directly tough so they still can be evaluated stay tuned.

[JohnV]

Originally posted by Razorblade2000
it would be cool if someone could do some low-bitrate encoding (480*X and a bitrate of 300 kbit/s)

I am really interested how h.264 performs :D
Ok, I got permission from bobololo. Here's a low bitrate clip.
640x256 300kbps h264 video and 48kbps aac-he audio.
Length 1.31 minutes. Size: 3.82 MB
No preprocessing used. I decided to use 640x instead of 480x, maybe 512x could be ideal, but anyway this should be quite nice.

http://www.hydrogenaudio.org/stuff/OutOfTime_Ateme-h264_300kbps.mp4

[bond]

Originally posted by JohnV
Ok, I got permission from bobololo. Here's a low bitrate clip.what source? dvd or the hd divx stuff?

Again no other Avisynth pre-processing except undot.why do you use undot? for testing it might be better to use no preprocessing at all

I decided to use 640x instead of 480x, maybe 512x could be ideal, but anyway this should be quite niceunless its getting not very blocky its ok to use such a res and h.264 should indeed be stressed :D

[JohnV]

Originally posted by bond
[B]what source? dvd or the hd divx stuff?
DVD movie.
why do you use undot? for testing it might be better to use no preprocessing at allWell, simply because it comes as default with Gordian Knot 0.28.8 created avs script and I remember reading that since it removes "orphan" pixels, it's ok to be used, doesn't do harm and doesnt change the image practically at all, but can improve compression. Tell me if I'm wrong.

Edit. No undot used anymore because of complaints from bond.

[bond]

Originally posted by JohnV
Tell me if I'm wrong.well its indeed preprocessing, making the compressibility better by taking out small details, making it harder to spot the codecs own performance

imagine someone preprocessing an audio clip (even if only a little bit), while trying to show an audio codecs performance on hydrogenaudio...

[bond]

and make sure to use lanczos resize, as its the most accurate resizer + get some sleep ;)

[Bulletproof]

From my testing right now I think the default settings are able to make a file that looks almost like quantizer 2 in xvid at half the filesize.

Source: Spiderman 2

http://www.boomspeed.com/boya/sp2.JPG

http://www.boomspeed.com/boya/sp3.JPG

http://www.boomspeed.com/boya/sp4.JPG

[Tommy Carrot]

I've done a few tests, and my opinion so far is quite positive, the output is far more watchable than x264's, the motions are more fluid and natural (this is a serious problem with other h264 codecs), and the blocks are far less pronounced with disabled inloop filter.

Strangely, i got better results with disabled b-frames. Enabling the bidirectional prediction causes some kind of 'stuttering', periodical jumps in the motions (especially during pans), and vibrating blocks (not that annoying, but still...).

By the way, any idea how can i open the MP4 files in avisynth? I didn't have any success with it.

[CruNcher]

Tommy Carrot
yep im also expirience those slightly jumps

[Bulletproof]

I don't think you can right now, but I'm not 100% sure. The way I got those screenshots was to create a custom graph in graphedit that outputted a HuffYUV file and then took the screenshots from that. I remember a while back that avisynth had added support for .GRF files (graphedit), maybe its possible to create a graph and have it open in avisynth but im not sure if it will work or not.

Have not expierenced those jumps yet, but I need to do more testing to find out.

[Tommy Carrot]

Originally posted by Bulletproof
Have not expierenced those jumps yet, but I need to do more testing to find out.
It's more noticable at lower bitrates (i used fixed quant 27).

[bobololo]

Concerning the jumping blocks you may observe in uniform area at low bitrate, this probably comes from bframes skipped blocks which are too agressively decided. To reduced this effect in the current version you could try to reduce the number of consecutive bframes (-maxb) or disable the bidir prediction. We'll try to find a way to fix that in the next update.

For taking screenshots, to my knowledge the easiest way to proceed is to simply open the render filter properties and to use the snapshot function.

@bulletprof: the initial quantizer is the value used by default at the first pass for vbr and abr modes. For 2 pass encoding, it doesn't really matter since a more suited initial quantizer will be choosen automatically for the second pass using the data of the first pass.

-- bobololo.

[minolta]

i'm too late to request beta-testing. if okay with bobololo, can somebody post a screenshot of the encoder gui with all advanced settings? i'm just curious...but PLEASE verify with bobololo before posting.
-minolta

[Andrey]

>>can somebody post a screenshot of the encoder gui
It has no gui :)
BTW, 2 questions:
1. About deblocking filter settings. If I gonna to enable it, what is maximum bitrate recommended and what that -6:6 means ?
Is -6 for less inloop deblocking ?
Now I stayed with default.
2. What about psyhovisual settings ?
What is recommended by devs in this case for DVD encode ?
Leave default ?
------------------------------------------------
Now 50% of second pass of StarWars: Ep II is ready.
1st pass - 20.5fps, second pass ~4fps I think.
clip resolution is 704x416, Undot() only.
Using Celeron 2600.
Waiting... :)

[bobololo]

Originally posted by minolta
i'm too late to request beta-testing. if okay with bobololo, can somebody post a screenshot of the encoder gui with all advanced settings? i'm just curious...but PLEASE verify with bobololo before posting.
-minolta

Ok here it is :

http://nero.ateme.com/~tchi/gui.PNG :)

@Andrey: deblocking strength -6 means very weak deblocking, 6 means strong deblocking. And regarding the psychovisual, ie may help to have better visual quality. As of now, the effects of psychovisual are not very pronounced, but we're interested to know if you can see something better when using it.

-- bobololo.

[thegeby]

1st attempt: 2.6 Celeron laptop 4200 rpm HD

Clip 1080P/30fps WMV fed into default encavc. Crashed at 100%. No error messge except Windows kind offer to call home. Resulting MP4 file full size but corrupt.:(

To quote someone in NYC: "I'll be baack"

[LostMP4]

First encode with nearly-default settings showed no problems and nice overall look, now running a second one:

System

Athlon XP 2600+ (Barton 11.5x166 = 1919 MHz)
1024 MB Ram
Windows XP SP2 (with a lot of stuff installed and removed, really NOT CLEAN, I'll format soon)
Encoding in low priority while using the PC (net-surfing, antivirus and something else)

Input AVS

AviSynth 2.55 RC3
dgmpgdec 1.0.11
MPEG-2 source

Core encoder version 1.0.1.14

Resolution : 720x576 @ 25.00 fps
Length : 72840 Frames
Rate Control : 2pass
Target Bit Rate : 1200 kb/s
Quality : Extra
Init Quantiser : 20
Max Consecutive BFrames : 3
Deblocking Strength : Adaptive
Num Reference : 5
Psychovisual : 2
Cartoon mode : Off
Features : ipred ppred bpred cabac deblock hpel qpel part

-- Start processing pass 1 / 2
* 100.00% completed
* 72840 frames processed @ 15.51 fps
-- Start processing pass 2 / 2

(running at about 4 fps)

I want to compare this encode with the same clip encoded with Nero Digital MPEG-4 ASP latest codec (and I'll try the muxer later)

14:30 update:
encode takes about 230 MB RAM
second pass is still running, reaching peaks of about 3600 Kb/s but it appears to be always over 1500Kb/s :rolleyes:

[everwicked]

Hi everyone,

I just released a VQStudio (subjective) beta (http://www.everwicked.com/vqstudio/beta/index.html) that works well with Ateme's filters (there had to be a work around).

Let me know what's broken :cool:

Cheers

[Gabriel_Bouvigne]

My poor 256MB laptop is swapping in a crazy way:
130MB of memory to decode a 12.5fps QCIF H264 clip!

[Tommy Carrot]

Originally posted by thegeby
Crashed at 100%. No error messge except Windows kind offer to call home. Resulting MP4 file full size but corrupt.:(


I experienced the same, it always crashes at the end of a clip. I suspect the b-frames again, because it doesn't happen without them. The resulting file has about the right size, but the index part (or at least i think it is, that part looks very similar to the index table of the avi container) is missing from the end of it, i guess this is why it's unplayable.

[Gabriel_Bouvigne]

Very low bitrate test:
a 23s QCIF 12.5fps, low motion (caméra café)
-rcmode abr -br 32000

*resulting bitrate is 44kbps, which is severly way off.
Perhaps there should be a more restricted abr mode for short clips or clips that would be streamed (32kbps video + 8kbps AMR would fit in UMTS bandwidth)

*psy 1 helps to keep a few more details on the faces

*psy2 removes too much detail on the background (which is static in my sample). It nearly removed a door from a wall.

edit: I am wondering if the bitrate difference between target and resulting file could be container overhead

edit: -br 32000 and not 32

[LostMP4]

Originally posted by Gabriel_Bouvigne
Very low bitrate test:
a 23s QCIF 12.5fps, low motion (caméra café)
-rcmode abr -br 32

*resulting bitrate is 44kbps, which is severly way off.
Perhaps there should be a more restricted abr mode for short clips or clips that would be streamed (32kbps video + 8kbps AMR would fit in UMTS bandwidth)

*psy 1 helps to keep a few more details on the faces

*psy2 removes too much detail on the background (which is static in my sample). It nearly removed a door from a wall.

edit: I am wondering if the bitrate difference between target and resulting file could be container overhead

What? Did you select a bitrate of 32 bits/sec? (-br 32)

[Gabriel_Bouvigne]

No, that is a mistake. I used -br 32000 and not 32.

Regarding my psy2 comment, you can discard it as the increased brightness came from my player.
I tryed again, and I think that the results are quite close to psy1. I perhaps like q1 better than q2.

[everwicked]

Originally posted by LostMP4
What? Did you select a bitrate of 32 bits/sec? (-br 32)

I guess that's really pushing it huh :D

[Gabriel_Bouvigne]

Same clip (QCIF, 12.5fps)

Target bitrate: abr 16kbps

At this bitrate, there are a lot of blocking effect when characters are moving, creating stairway effects on sharp diagonal transitions.

In this case, adding -deblock adapt helps a lot to reduce the stairway effect.

[Sagittaire]

how split H264/ACC/MP4 ... ?

[acidsex]

Couple questions.

Has it been optimized for speed yet? I am only getting 9fps on a P4 2.5ghz.

Next, during the first pass analysis, is it normal for it to go extremely slow unlike the first pass analysis using Nero Digital?

[guldukat]

Originally posted by acidsex
Couple questions.

Has it been optimized for speed yet? I am only getting 9fps on a P4 2.5ghz.

Next, during the first pass analysis, is it normal for it to go extremely slow unlike the first pass analysis using Nero Digital?

well h264 aint normal mpeg4, it's much much much more complex, and you can be grateful that it is THAT fast, dont hesitate to compare the speed to other h264 competitors (there are many)

[acidsex]

Seeking seems to be broken as well using Showtime. Everytime I seek, it freezes and then crashes.

[guldukat]

Originally posted by acidsex
Seeking seems to be broken as well using Showtime. Everytime I seek, it freezes and then crashes.


if you're a beta tester, you should've received some directshow filters, use them instead of showtime, seeking is supposed to work there

[superdump]

First batch of results from me: grab them here (http://www.swains.plus.com/superdump/-qual.txt).

All useful information is in the text file.

[LostMP4]

Originally posted by acidsex

Next, during the first pass analysis, is it normal for it to go extremely slow unlike the first pass analysis using Nero Digital?

AVC first pass is extremely slow compared to ASP, but about 3-4 times faster than AVC second pass

[superdump]

Originally posted by LostMP4
AVC first pass is extremely slow compared to ASP, but about 3-4 times faster than AVC second pass There's a fast first pass on long clips but not on short clips. I don't know what the cutoff number of frames is though.

[Tommy Carrot]

I know this might sound stupid, but i got better results with 'normal' quality mode than with 'best', at higher bitrates (720x288@1200 kbps). Somehow it's sharper and has more details. At lower bitrates, it's not true anymore, the more accurate rendition of the motions of 'best' quality overweights the little detail loss.

I don't agree with acidsex on the performance issues: i got 14-20 fps on my athlon 1700 in normal mode (and 7-10 in best mode). Anyone who played with the reference software will understand why do i find this so impressive.

edit: Superdump, i would advise you to disable the b-frames, they are the main cause of the motion issues.

[babayaga]

Originally posted by Gabriel_Bouvigne
Very low bitrate test:
a 23s QCIF 12.5fps, low motion (caméra café)
-rcmode abr -br 32000

*resulting bitrate is 44kbps, which is severly way off.
Perhaps there should be a more restricted abr mode for short clips or clips that would be streamed (32kbps video + 8kbps AMR would fit in UMTS bandwidth)


The rate-control is not optimised (yet) for those kind of bitrates. Currently, the ABR is perfectly ok with 32kB of over/undersize which is very consistant with standard video backup applications (if I count right you're experiencing 34kB of oversize).

Anyway, you're right and we will address this issue in the next version.

Thanks for pointing this out.

[everwicked]

If anyone has downloaded the VQStudio beta i posted about earlier, please re-download, there was a huge bug in it.

Sorry about that.

[CruNcher]

edit: Superdump, i would advise you to disable the b-frames, they are the main cause of the motion issues.


also cabac off improves picture stability in some scenes for me :)

[bobololo]

Originally posted by Tommy Carrot
I experienced the same, it always crashes at the end of a clip. I suspect the b-frames again, because it doesn't happen without them. The resulting file has about the right size, but the index part (or at least i think it is, that part looks very similar to the index table of the avi container) is missing from the end of it, i guess this is why it's unplayable.

It's quite strange, could you please provide the source that led to that result ? I mean the source file and the avs script you gave to encavc so we can reproduce and find what is wrong.

You can upload it to ftp://nero.ateme.com/incoming.

[superdump]

Tommy Carrot: I'm conducting thorough visual tests of pretty much all the settings. I'll get round to turning b-frames off then make my choices for the "best quality" settings to my eyes and then a "performance/quality" tradeoff.

CruNcher: CABAC is some sort of lossless arithmetic coding thing, so why would that affect it?

[LostMP4]

Core encoder version 1.0.1.14

Resolution : 720x576 @ 25.00 fps
Length : 72840 Frames
Rate Control : 2pass
Target Bit Rate : 1200 kb/s
Quality : Extra
Init Quantiser : 20
Max Consecutive BFrames : 3
Deblocking Strength : Adaptive
Num Reference : 5
Psychovisual : 2
Cartoon mode : Off
Features : ipred ppred bpred cabac deblock hpel qpel part

-- Start processing pass 1 / 2
* 100.00% completed
* 72840 frames processed @ 15.51 fps
-- Start processing pass 2 / 2
* 72839: encoding @ 15.42 fps - bitrate 52.68 kb/s - 100.00% completed
* 72840 frames encoded @ 3.88 fps - average bitrate 1199.43 kb/s

Encoding complete

* for other details look my previous post
- decoding appears to be flawless (video only, no muxed, yet)
- with Ateme filters it's possible to seek in the file
- with Showtime the clip plays well but can't seek or change speed
- final bitrate is perfect
- quality is higher (of course) compared to the same clip with the same preprocessing and bitrate (and time needed to encode too...)

[CruNcher]

CruNcher: CABAC is some sort of lossless arithmetic coding thing, so why would that affect it?


yeah i watched again it comes from the source not from cabac

[Andrey]

Ok. First result.
1. Codec crashed after job completion, but file is playable.

Resolution : 704x416 at 25.00 fps
Rate Control : 2pass
Target Bit Rate : 1289 kb/s
Quality : Extra
Init Quantiser : def
Max Consecutive BFrames : 3
Deblocking Strength : def
Num Reference : 3
Psychovisual : 0

encavc.exe -i h264.avs -o h264.mp4 -qual extra -rcmode 2pass -br 1289000 - psy 0 -maxb 3 -par 235:100 -ref 3

What I can tell imidiately:
1. Codec obey bitrate settings.
2. Result is much more pleasant to the eyes, than XViD encode, but lack details sometimes. Deblocking ?
Next time I'll disable it or set to -6.
What is better ?

BTW, how to take a screenshot from this encode ?
MPC always show me a error message when taking it...

[bond]

Originally posted by superdump
CruNcher: CABAC is some sort of lossless arithmetic coding thing, so why would that affect it?its a lossless way of saving bits, so the additonal bits recieved by using cabac might make the difference cruncher saw

[CruNcher]

1. Codec crashed after job completion, but file is playable.


check your avisynth plugins folder and try to determine by removing each plugin 1 after another wich is causeing the crash most times this comes from a not clean programmed plugin.

about the sharpness thing you could try -clref deblock (disable)
or -deblock adapt (adaptive deblocking) please report wich looks better for you :)

[superdump]

OK, second batch of results from me incoming. I've updated the first batch since I very first posted it so you may want to check it again. This time round it's deblocking. I tested with the same clip with -deblock -6, -4,..., 4, 6 and disabled. Grab the results here (http://www.swains.plus.com/superdump/-deblock.txt).

[LostMP4]

No luck with the muxer :(
Did anyone managed to make a "complete" MP4 file?

[superdump]

Originally posted by LostMP4
No luck with the muxer :(
Did anyone managed to make a "complete" MP4 file? I've done it before, yes. With LC AAC and with HE AAC. What's the problem?

[LostMP4]

Originally posted by superdump
I've done it before, yes. With LC AAC and with HE AAC. What's the problem?

It seems to don't like any aac file :confused:
(and I'm not sure I'm using the correct sintax to use it :p)

[bobololo]

Hi there,

The first day of testing has just passed and I'd just like to sum up somes points and provide some replies to posted queries.

* Bugs and other malfunctions
- when installing the dshow filters, if you encounter the LoadLibrary() error message, it's because you don't have msvcr71.dll in your system. You can get it there (http://www.dll-files.com/dllindex/dll-files.shtml?msvcr71).
- Once installed, make sure your dshow player use them and instead of other ones. Most players (like mplayerc) provide some ways to assign priorities to filters (overrides options).
- a strange issue exists with mplayerc, it happens that some files locks the player at the opening stage. The preliminary investigations done didn't explain the causes of this behaviour. Other players like wm player, bsplayer, zoom player don't show this issue.
- the decoder memory usage is huge. It's a mistake in the decoding filter and will be fixed.
- there is actually a bug in the core encoder that provokes a crash on the last frame of the sequence. It's caused by a mistake in bframes management. It is fixed now. A work around is to disable the bframes.
- the rate control doesn't achieve its target for ultra low bitrate. Some improvements are on the way.
- using 16 references causes some trouble. It is fixed now. Anyway having more than 5 references is almost useless. The gains are so small.

* Encoder Settings / Quality
- Many of you reported that on low bitrate, the bframes give some jumping blocks on uniform and slow motion area. This is due to some agressive bskip blocks decision. Improvements are on the way.
- About the deblocking strength parameter which range from -6 to 6. The smaller (-6) value gives the weaker deblocking and the higher value (6) gives the stronger deblocking and also smoother picture. The "adapt" value can also be used to ask the encoder to adapt automatically the deblocking strengh to the picture quality. This means that when a picture is strongly compressed, the deblocking will have more effects to reduce the compression artefacts. In the opposite, on low compressed picture, the filter will be disable to preserve the higher sharpness as possible.
- Regarding the encoding speed, well don't expect to get the same speed as our ASP encoder. Anyway, you can reach pretty fast encoding in lower quality level. And we have still some goodies to come :)

* suggestions
- During your test, it would be very interesting to get subjective impression of different encodes which are quite different from the perception you can have when staring clips picture per picture looking at the details and blocks :) Visual Quality Studio from Everwicked is a nice tool you can use to perform subjective comparison. It is based on the widely used DSCQS. You can grab it here (http://www.everwicked.com/vqstudio/beta/index.html).
- a ftp server has been setup so you can send us your file for debugging or other purposes. Also it can be useful when people want to show us samples where 'best' quality is better than 'extra' ;). The upload directory address is ftp://nero.ateme.com/incoming (anonymous). It is for upload only (one can't download files uploaded there).

* next update
- the next update with all the fixes and improvement is scheduled for next week. But this is not 100% yet :)

* last words
- we're still waiting for the feedback of top regular users like SeeMoreDigital, Sirber, CruNcher, Nic and many others :) Did you suddenly lose your tongue ? You were so much excited to test this beta that your silence is quite surprising ;)
- and of course, thanks to all testers !

-- bobololo.

[Andrey]

about the sharpness thing you could try -clref deblock (disable) or -deblock adapt (adaptive deblocking) please report wich looks better for you
h264 already looks better than original :D
Funny. The problem was in myst - it gave a little distortion, but picture was perfectly clean after encoding :) No distortion, no myst :)
XViD shows terrible makroblocks there, only quant 2 is usable...
Seems that SW II is hard to encode.

[Teegedeck]

Originally posted by bobololo

- we're still waiting for the feedback of top regular users like SeeMoreDigital, Sirber, CruNcher, Nic and many others :) Did you suddenly lose your tongue ? You were so much excited to test this beta that your silence is quite surprising ;)
Wellll... - since I came back home on tuesday I struggled to get the last bits of mpegable avc out of my system and finally managed getting decoding to work after a Nero re-install this evening. So definitely no solid results from me before the end of the week, as I foretold in my initial PM.

edit: I plan on testing at which quantizer and settings ateme reaches transparency (or is comparable to XviD at a setting which I regard as giving transparent results).

[Sagittaire]

- we're still waiting for the feedback of top regular users like SeeMoreDigital, Sirber, CruNcher, Nic and many others Did you suddenly lose your tongue ? You were so much excited to test this beta that your silence is quite surprising


eh eh eh ... test in progress, test in progress ... but in introduction it's a very powerfull codec:

My favorite setting: higest quality but slowest
encavc.exe -i clip.avs -o H264-2000.mp4 -qual extra -rcmode 2pass -br 2048000 -psy 2 -deblock adapt -ref 5

if you are wise and if bobololo authorize it would make you a HDTV demo ... ;-)

- King Arthur trailer
- 1440*800*24 picture aspect 2.35 and pixel aspect 4:3
- LC-AAC 5.1 high quality

[virus]

Originally posted by bobololo
Did you suddenly lose your tongue?
No, but I've suddenly lost my time :)
(that means: today has been a very, very busy day, but tomorrow I think I can find time to start playing with the codec... luckily the new version is scheduled for the next week, the weekend is absolutely needed ;))

virus

[JohnV]

Originally posted by JohnV
Ok, I got permission from bobololo. Here's a low bitrate clip.
640x256 300kbps h264 video and 48kbps aac-he audio.
Length 1.31 minutes. Size: 3.82 MB
No preprocessing used. I decided to use 640x instead of 480x, maybe 512x could be ideal, but anyway this should be quite nice.

http://www.hydrogenaudio.org/stuff/OutOfTime_Ateme-h264_300kbps.mp4
Here's the same with h264 inloop deblocking strength 2.
At this low bitrate the encoder's adaptive deblocking is not quite aggressive enough for my taste at least on TFT screen ;), so I like this fixed strength a bit better.
Also enabled is the cartoon-mode, which according to bobololo "enhances decision by taking chroma into account".
Haven't really compared the effect of the cartoon mode, but thought that people might be interested in it and it is enabled in this encode:
http://www.hydrogenaudio.org/stuff/OutOfTime_Ateme-h264_300kbps_inloop2.mp4

[SeeMoreDigital]

Originally posted by bobololo
* last words
- we're still waiting for the feedback of top regular users like SeeMoreDigital, Sirber, CruNcher, Nic and many others :) Did you suddenly lose your tongue ? You were so much excited to test this beta that your silence is quite surprising ;)
- and of course, thanks to all testers !

-- bobololo. I'm sorry about this bobololo. Initially I had some problems loading the software. And then my Mpeg4 DSdec filters became unstable (I've been running lean, with just XviD 1.1.x beta, Nero and FFdshow).

Plus today I installed a new graphics card, which unfortunately also has had it's quirks. Some of which I'm yet to resolve!

All in all, it's not been a very good couple of days. But I've enjoyed reading the posts in this thread.... It would be nice to have some encodes to play though!


Cheers

[Bulletproof]

When you disable some encoding tools like bframes or qpel etc using the -clref option is the encoder still supposed to show them in the features list? Because this is what I tried:

encavc.exe -i test.avs -o test.mp4 -clref deblock bpred hpel qpel -setef ipred ppred cabac part

and the output from encavc says:

Features : ipred ppred bpred cabac hpel qpel part

[JohnV]

Originally posted by Bulletproof
When you disable some encoding tools like bframes or qpel etc using the -clref option is the encoder still supposed to show them in the features list? Because this is what I tried:

encavc.exe -i test.avs -o test.mp4 -clref deblock bpred hpel qpel -setef ipred ppred cabac part

and the output from encavc says:

Features : ipred ppred bpred cabac hpel qpel part
use -clref deblock,bpred,qpel etc.. in other words use comma between the enabled/disabled tools.

[RadicalEd]

The bskip thing wreaks havoc here :|
Bobololo, could you give a brief explanation of the -cartoon setting?
whoops, missed johnv's small quote a few posts up.
Also enabled is the cartoon-mode, which according to bobololo "enhances decision by taking chroma into account".

[plonk420]

i'm having muxing problems too.

encoded an 800kbps clip @ 720x480 (d'oh, forgot to resize to 640x480) and a 96kbps nero aac-he file and it just sits at the cli. does't even create the output file (empty or not).

used simple switches, too:
encavc -i clip.avs -o clip.mp4 -qual best -rcmode 2pass -br 800000
mp4muxer -i video.mp4 -i audio.mp4 -f:audio -o av.mp4

also what should i be using to play the audio in JohnV's video? i've created my own MP4s with graphedit using 3ivx 4.5.1's mp4 muxer and AACs (LC and HE) and had no probs with CoreAAC, but i'm getting an error related to the audio output pin. i used nero (AAC) for both the xvid mp4s i've muxed (successfully), as well as the avc clips i'm trying to mux.


could we maybe have two threads? maybe an encoder/muxer feedback thread and a video quality feedback thread?

[bobololo]

Originally posted by plonk420
i'm having muxing problems too.
used simple switches, too:
encavc -i clip.avs -o clip.mp4 -qual best -rcmode 2pass -br 800000
mp4muxer -i video.mp4 -i audio.mp4 -f:audio -o av.mp4

Your muxing command line is slightly wrong, try this instead (as mentioned in the documentation) :

mp4muxer -i video.mp4 -i audio.mp4 -f t:audio -o av.mp4

Originally posted by plonk420
could we maybe have two threads? maybe an encoder/muxer feedback thread and a video quality feedback thread?

I think the usage issues that obviously appear at the beginning will be solved quickly and be replaced by quality considerations afterward. So I'm not sure it is worth flooding the forum with several threads ;)

-- bobololo.

[Nic]

@bobololo: Hey, sorry for me losing my tongue ;) , I've got a cold so only managed to do little testing. Everythings working great, nice set of tools, I'll report more soon :)

[babayaga]

Originally posted by superdump
There's a fast first pass on long clips but not on short clips. I don't know what the cutoff number of frames is though.


About 10 000 frames at the end of the clip. So there is currently no speed gain for short clips (like trailers).

The last 256 frames receive a special treatment to avoid a too large bitrate error. That's why the last 10s of clips are sometimes less good-looking than they could be.
In the special case of a hard clip with a very low energy ending (near still frames), this can lead to a bad looking ending. I guess that's what you're seeing with LOTR2.

In a movie/trailer encode, it's generaly not a problem because it's in the end credit. If you take just a chapter of a movie it could be an issue.

I've seen the same kind of "problem" with XviD and DivX.

But remember that we have to avoid by all means a too large oversize since the encode could be directly burned on a CD/DVD.

[chilledoutuk]

The last 256 frames receive a special treatment to avoid a too large bitrate error. That's why the last 10s of clips are sometimes less good-looking than they could be.

this explains the problems i have been having with the new version of recode at the end of video sequences when i crop off the credits.
From now on ill leave 10s of credits on.

Is not possible to detect that your not burning to a disc and therefore not use this special treatment or at least de-activate it when a custom size is set by the user.

[plonk420]

Originally posted by bobololo
Your muxing command line is slightly wrong, try this instead (as mentioned in the documentation) :

mp4muxer -i video.mp4 -i audio.mp4 -f t:audio -o av.mp4

:eek: oops .. how embarassing -_- guess i should try to get more sleep than i have been this week...

any ideas as to the audio problem, anyone?

[babayaga]

Originally posted by chilledoutuk
this explains the problems i have been having with the new version of recode at the end of video sequences when i crop off the credits.
From now on ill leave 10s of credits on.

Is not possible to detect that your not burning to a disc and therefore not use this special treatment or at least de-activate it when a custom size is set by the user.

The exact beheaviour is very dependant on the structure of the clip. Most of the times, the very ending is better looking than the rest of the clip, but sometimes it's the opposite.

That's my own feelings, we've never received a report stating that there could be a problem at the very end, Superdump is the first one :-)

BTW, do you think that the quality is constant enough or is there too much variation ?

[Selur]

hmm,.. playing around with deblocking settings and I'm wondering is it possible to maybe lower the deblocking setting automaticly fpr low contrast areas?

Especially for water scenes deblocking, seems to smooth too much. :)
Though I really like the deblocking in general.

Cu Selur

[Gabriel_Bouvigne]

Originally posted by babayaga

BTW, do you think that the quality is constant enough or is there too much variation ?

I think that for some targets there might be too much variation.
This is the case with very low bitrate (20-30kbps) short content.

Encoding at 12.5fps, this makes a quality drop of 20seconds, which is huge for a 1min clip.

(ok, this might not be a priority as h264 decoders are not yet available for phones)

[chilledoutuk]

recently I have been backing up stargate sg1 season 7 with full anamorphic resolution to files of 560mb per a 42min episode. Also with the directors cometry included now thanks to the new version of recode :D .

in most of the episodes there is no problem at the end of the encoded video sequence.

But on a couple of episodes there is noticable blocking just before the end of the video sequence. what also concerns me is the anmount the codec undersizes this episode i set the size to 562mb and i get a video that is 552mb which is a 10mb undersize compared to a 4mb undersize of other episodes.
This episode that repeatadlty caused rate control problems for nero is episode 4 on stargate sg1 vol 35 (PAL).

you may want to check it out.

[LostMP4]

2 new encodes, same clip as before, this time without deblocking and preprocessing, using two different bitrates (the second one is just a little oversized):


Resolution : 720x576 @ 25.00 fps
Length : 72840 Frames
Rate Control : 2pass
Target Bit Rate : 1200 kb/s
Quality : Extra
Init Quantiser : 20
Max Consecutive BFrames : 3
Num Reference : 5
Psychovisual : 0
Cartoon mode : Off
Features : ipred ppred bpred cabac hpel qpel part

-- Start processing pass 1 / 2
* 100.00% completed
* 72840 frames processed @ 15.26 fps
-- Start processing pass 2 / 2
* 72839: encoding @ 16.29 fps - bitrate 62.73 kb/s - 100.00% completed
* 72840 frames encoded @ 3.99 fps - average bitrate 1199.53 kb/s


Resolution : 720x576 @ 25.00 fps
Length : 72840 Frames
Rate Control : 2pass
Target Bit Rate : 600 kb/s
Quality : Extra
Init Quantiser : 20
Max Consecutive BFrames : 3
Num Reference : 5
Psychovisual : 0
Cartoon mode : Off
Features : ipred ppred bpred cabac hpel qpel part

-- Start processing pass 1 / 2
* 100.00% completed
* 72840 frames processed @ 19.02 fps
-- Start processing pass 2 / 2
* 72839: encoding @ 16.73 fps - bitrate 13.78 kb/s - 100.00% completed
* 72840 frames encoded @ 5.36 fps - average bitrate 600.03 kb/s


I noticed some blocking (of course, I don't use deblocking) on still parts... maybe the reference blocks are choosen with to little accuracy :confused:

PS: even with halfed bitrate the pictures are always very clean

[virus]

bobololo, please clear your PM box a bit, it's full ;)

[superdump]

Originally posted by chilledoutuk
recently I have been backing up stargate sg1 season 7 with full anamorphic resolution to files of 560mb per a 42min episode. Also with the directors cometry included now thanks to the new version of recode :D .

in most of the episodes there is no problem at the end of the encoded video sequence.

But on a couple of episodes there is noticable blocking just before the end of the video sequence. what also concerns me is the anmount the codec undersizes this episode i set the size to 562mb and i get a video that is 552mb which is a 10mb undersize compared to a 4mb undersize of other episodes.
This episode that repeatadlty caused rate control problems for nero is episode 4 on stargate sg1 vol 35 (PAL).

you may want to check it out. I'm sure these comments will be appreciated but you are commenting about the MPEG-4 ASP codec within Nero Recode which is off-topic from this thread. We are all discussing the Ateme H.264 Beta which you had to sign up for and is not part of Nero Recode yet.

[SteMa]

Hi! Can I get the ateme beta codec too? I wish to do some encoding myself if it's not a problem. Sorry if i'm late but I really like doing encodes :D

[superdump]

Originally posted by LostMP4
2 new encodes, same clip as before, this time without deblocking and preprocessing, using two different bitrates (the second one is just a little oversized):


Resolution : 720x576 @ 25.00 fps
Length : 72840 Frames
Rate Control : 2pass
Target Bit Rate : 1200 kb/s
Quality : Extra
Init Quantiser : 20
Max Consecutive BFrames : 3
Num Reference : 5
Psychovisual : 0
Cartoon mode : Off
Features : ipred ppred bpred cabac hpel qpel part

-- Start processing pass 1 / 2
* 100.00% completed
* 72840 frames processed @ 15.26 fps
-- Start processing pass 2 / 2
* 72839: encoding @ 16.29 fps - bitrate 62.73 kb/s - 100.00% completed
* 72840 frames encoded @ 3.99 fps - average bitrate 1199.53 kb/s


Resolution : 720x576 @ 25.00 fps
Length : 72840 Frames
Rate Control : 2pass
Target Bit Rate : 600 kb/s
Quality : Extra
Init Quantiser : 20
Max Consecutive BFrames : 3
Num Reference : 5
Psychovisual : 0
Cartoon mode : Off
Features : ipred ppred bpred cabac hpel qpel part

-- Start processing pass 1 / 2
* 100.00% completed
* 72840 frames processed @ 19.02 fps
-- Start processing pass 2 / 2
* 72839: encoding @ 16.73 fps - bitrate 13.78 kb/s - 100.00% completed
* 72840 frames encoded @ 5.36 fps - average bitrate 600.03 kb/s


I noticed some blocking (of course, I don't use deblocking) on still parts... maybe the reference blocks are choosen with to little accuracy :confused:

PS: even with halfed bitrate the pictures are always very clean LostMP4: I recommend you try the deblocking. I love XviD because of the sharpness and detail of textured areas and distinct lack of blurring. (Blurring does actually make me feel sick in high motion scenes). However, very light deblocking does give a nicer output and can work wonders with some sections of videos. At least from my brief experience of it (see the results above). Try -deblock -6 / -5 and -4 and also try the adaptive method. We've suggested an adaptive method with varying aggressivenesses to bobololo so that we can all benefit from having adaptive deblocking but to the degree which suits out visual tastes. :) Keep those results coming though, you're doing a grand job.

[Selur]

"so that we can all benefit from having adaptive deblocking but to the degree which suits out visual tastes."
yup, this would be nice. :)

[LostMP4]

Originally posted by superdump
LostMP4: I recommend you try the deblocking. I love XviD because of the sharpness and detail of textured areas and distinct lack of blurring. (Blurring does actually make me feel sick in high motion scenes). However, very light deblocking does give a nicer output and can work wonders with some sections of videos. At least from my brief experience of it (see the results above). Try -deblock -6 / -5 and -4 and also try the adaptive method. We've suggested an adaptive method with varying aggressivenesses to bobololo so that we can all benefit from having adaptive deblocking but to the degree which suits out visual tastes. :) Keep those results coming though, you're doing a grand job.

I've already tried deblocking in my first encodes, I was looking for the differences with various options on/off

[superdump]

Originally posted by babayaga
About 10 000 frames at the end of the clip. So there is currently no speed gain for short clips (like trailers).

The last 256 frames receive a special treatment to avoid a too large bitrate error. That's why the last 10s of clips are sometimes less good-looking than they could be.
In the special case of a hard clip with a very low energy ending (near still frames), this can lead to a bad looking ending. I guess that's what you're seeing with LOTR2.

In a movie/trailer encode, it's generaly not a problem because it's in the end credit. If you take just a chapter of a movie it could be an issue.

I've seen the same kind of "problem" with XviD and DivX.

But remember that we have to avoid by all means a too large oversize since the encode could be directly burned on a CD/DVD. Thanks for the response babayaga. So the poor quality ending on my clip is linked with the slow first pass RC for clips of less than 10000 frames? I think that if your perceived a similar problem in XviD it wouldn't be so pronounced as I don't think there is an intended decrease in bitrate to prevent an overflow at the end. I'll have to enquire how this works in XviD, or maybe you could yourself by visiting #xvid on freenode and talking to GomGom or Foxer or another XviD dev. I think it just uses a bit reservoir and very good calculations. I've never seen any of my XviD encodes be oversized at 'normal' bitrates. As for DivX I wouldn't have a clue how that works and I don't really care. :)

[virus]

I cannot encode anything. The encoder dies with "can't create input thread" at the start of the encoding. But my AVS is ok and I can watch it regularly both under VFW and DS... since nobody is reporting such a behaviour maybe my problem is Win98SE? Nobody using the 9x kernel around?

I've emailed bobololo about the details. Now I'm stuck :(

[superdump]

Originally posted by babayaga
The exact beheaviour is very dependant on the structure of the clip. Most of the times, the very ending is better looking than the rest of the clip, but sometimes it's the opposite.

That's my own feelings, we've never received a report stating that there could be a problem at the very end, Superdump is the first one :-)

BTW, do you think that the quality is constant enough or is there too much variation ? chilledoutuk is talking about Recode's MPEG-4 ASP codec as I pointed out a couple of posts above. I've never witnessed the same problem in Recode but then I've only ever done full film encodes with it so I wouldn't have noticed the problem... in which case, if I'm only ever doing full film encodes with it then I wouldn't notice the 'problem' in normal use.

As for the degree of constant quality... throughout the rest of the clip it is fairly constant but only in the two halves. The slow motion section looks MUCH better than the high motion section. I think this bias should be altered slightly in my opinion. :)

[babayaga]

Originally posted by chilledoutuk
This episode that repeatadlty caused rate control problems for nero is episode 4 on stargate sg1 vol 35 (PAL).


In the beta you received, there is no special protection for oversize like the one that is embedded in Recode, and there is also no compensation for the container overhead or other streams.

Besides, the rate-control algorithm is brand new even if it uses old concepts that were already in place back to the first version of Recode 2.
So the visual impression could be different, and that's in what I'm interested today.

Reading this forum, I've the feeling that except some issues at the very end of some sequences (Superdump) or extremly low bitrates (Gabriel_Bouvigne), nobody complained for very serious problems like an excessive variation of quality or a large error.
Am I wrong ?

[LostMP4]

About mp4muxer: it crashed muxing h264 video stream with a AAC.
Now the file is "locked" (mp4muxer), double-clicking on it says it isn't a valid win32 program, I can't use or delete it (I tryed restarting the PC, too)
I can copy it to another folder, obtaining another locked file that I can't delete :confused:
A "new" mp4muxer exctracted from the archive works well (audio in MP4, I don't dare to try aac anymore)
What's happened?

[superdump]

Originally posted by babayaga
In the beta you received, there is no special protection for oversize like the one that is embedded in Recode, and there is also no compensation for the container overhead or other streams.

Besides, the rate-control algorithm is brand new even if it uses old concepts that were already in place back to the first version of Recode 2.
So the visual impression could be different, and that's in what I'm interested today.

Reading this forum, I've the feeling that except some issues at the very end of some sequences (Superdump) or extremly low bitrates (Gabriel_Bouvigne), nobody complained for very serious problems like an excessive variation of quality or a large error.
Am I wrong ? As stated in the post previous to yours, I think the bias between high motion scenes (which I imagine produce larger frames) and low motion scenes needs to be adjusted slightly to create a more constant quality in the two regions. Gabriel suggests less variability but I'm not sure whether he means less variability in bitrate or quality? I'd suggest more variability in bitrate or at least an adjustment to the RC such that much bits are given to high motion scenes and less to low motion. That is my opinion based on the clip I've been using.

I'm going to wait for an update now before I continue extensive testing as I'd like to test with b-frames more extensively. I can't really comment on this feature when the bskipping is too aggressive and makes it difficult to notice quality improvements.

I can't see much difference in quality in the multiref encodes I've done but these all used b-frames so it was distracting there too. I'll have to do some with only i/p-frames and test those.

Nothing else springs to mind at the moment.

[SeeMoreDigital]

Originally posted by LostMP4
...A "new" mp4muxer exctracted from the archive works well (audio in MP4, I don't dare to try aac anymore)
What's happened? I would not worry about it too much. These things happen.

At least some of the bugs are being discovered now (during beta testing) and not later!


Cheers

[RBF]

I made comparison Ateme H.264 with VSS, VP6, XVID.
400kbit/s 720x352

PIV-2800 512RAM

Core encoder version 1.0.1.14

Input file : clip.avs
Output file : clip.mp4
Resolution : 720x352 @ 23.98 fps
Length : 4316 Frames
Rate Control : 2pass
Target Bit Rate : 400 kb/s
Quality : Best
Init Quantiser : 24
Max Consecutive BFrames : 3
Deblocking Strength : -2
Num Reference : 1
Psychovisual : 0
Cartoon mode : Off
Features : ipred ppred bpred cabac deblock hpel qpel part

-- Start processing pass 1 / 2
* 100.00% completed
* 4316 frames processed @ 11.64 fps
-- Start processing pass 2 / 2
* 04315: encoding @ 10.28 fps - bitrate 536.14 kb/s - 100.00% completed
* 4316 frames encoded @ 11.71 fps - average bitrate 400.04 kb/s

Encoding complete

VP6 best quality, Videosoft - best quality, XVID 6/4 Aq/Qp 2B H263,Real Video 10 - sharpest image. All - 2 pass

1
Ateme - http://rbf.nm.ru/Nero_400_1.jpg
VP62 - http://rbf.nm.ru/VP6_400_1.jpg
Videosoft-H264 - http://rbf.nm.ru/VSSH_400_1.jpg
XVID - http://rbf.nm.ru/XVID_400_1.jpg
Real Video 10 - http://rbf.nm.ru/Real10_400_1.jpg

2
Ateme - http://rbf.nm.ru/Nero_400_2.jpg
VP62 - http://rbf.nm.ru/VP6_400_2.jpg
Videosoft-H264 - http://rbf.nm.ru/VSSH_400_2.jpg XVID - http://rbf.nm.ru/XVID_400_2.jpg
Real Video 10 - http://rbf.nm.ru/Real10_400_2.jpg


3
Ateme - http://rbf.nm.ru/Nero_400_3.jpg
VP62 - http://rbf.nm.ru/VP6_400_3.jpg
Videosoft-H264 - http://rbf.nm.ru/VSSH_400_3.jpg
XVID - http://rbf.nm.ru/XVID_400_3.jpg
Real Video 10 - http://rbf.nm.ru/Real10_400_3.jpg

4
Ateme - http://rbf.nm.ru/Nero_400_4.jpg
VP62 - http://rbf.nm.ru/VP6_400_4.jpg
Videosoft-H264 - http://rbf.nm.ru/VSSH_400_4.jpg
XVID - http://rbf.nm.ru/XVID_400_4.jpg
Real Video 10 - http://rbf.nm.ru/Real10_400_4.jpg

Generalizing results after full viewing 5 clips - Ateme H.264 has given more detailed picture from less artefacts than other codecs on 400kbit/s 720x352.

[LostMP4]

Originally posted by SeeMoreDigital
I would not worry about it too much. These things happen.

At least some of the bugs are being discovered now (during beta testing) and not later!


Cheers

Well, I've got 3 files I can't delete in any way :rolleyes:

[JohnV]

Originally posted by RBF
I made comparison Ateme H.264 with VSS, VP6, XVID.
400kbit/s 720x352

PIV-2800 512RAM

Core encoder version 1.0.1.14

Input file : clip.avs
Output file : clip.mp4
Resolution : 720x352 @ 23.98 fps
Length : 4316 Frames
Rate Control : 2pass
Target Bit Rate : 400 kb/s
Quality : Best
Init Quantiser : 24
Max Consecutive BFrames : 3
Deblocking Strength : -2
Num Reference : 1
Psychovisual : 0
Cartoon mode : Off
Features : ipred ppred bpred cabac deblock hpel qpel part

-- Start processing pass 1 / 2
* 100.00% completed
* 4316 frames processed @ 11.64 fps
-- Start processing pass 2 / 2
* 04315: encoding @ 10.28 fps - bitrate 536.14 kb/s - 100.00% completed
* 4316 frames encoded @ 11.71 fps - average bitrate 400.04 kb/s

Encoding complete

VP6 best quality, Videosoft - best quality, XVID 6/4 Aq/Qp 2B H263. All - 2 pass

1
Ateme - http://rbf.nm.ru/Nero_400_1.jpg
VP62 - http://rbf.nm.ru/VP6_400_1.jpg
Videosoft-H264 - http://rbf.nm.ru/VSSH_400_1.jpg
XVID - http://rbf.nm.ru/XVID_400_1.jpg

2
Ateme - http://rbf.nm.ru/Nero_400_2.jpg
VP62 - http://rbf.nm.ru/VP6_400_2.jpg
Videosoft-H264 - http://rbf.nm.ru/VSSH_400_2.jpg
XVID - http://rbf.nm.ru/XVID_400_2.jpg


3
Ateme - http://rbf.nm.ru/Nero_400_3.jpg
VP62 - http://rbf.nm.ru/VP6_400_3.jpg
Videosoft-H264 - http://rbf.nm.ru/VSSH_400_3.jpg
XVID - http://rbf.nm.ru/XVID_400_3.jpg

4
Ateme - http://rbf.nm.ru/Nero_400_4.jpg
VP62 - http://rbf.nm.ru/VP6_400_4.jpg
Videosoft-H264 - http://rbf.nm.ru/VSSH_400_4.jpg
XVID - http://rbf.nm.ru/XVID_400_4.jpg

Generalizing results after full viewing 4 clips - Ateme H.264 has given more detailed picture from less artefacts than other codecs on 400kbit/s 720x352.

Any reason why you didn't use "extra" -quality mode and psychovisual 2? Those could improve quality further.

[bobololo]

Originally posted by RBF
I made comparison Ateme H.264 with VSS, VP6, XVID.
400kbit/s 720x352

[...]
Length : 4316 Frames
Rate Control : 2pass
Target Bit Rate : 400 kb/s
Quality : Best
[...]

Generalizing results after full viewing 4 clips - Ateme H.264 has given more detailed picture from less artefacts than other codecs on 400kbit/s 720x352.
Very interesting batch of encodes. Btw, you could get even better results with 'extra' quality mode !

-- bobololo.

[bobololo]

Originally posted by LostMP4
Well, I've got 3 files I can't delete in any way :rolleyes: Aren't you infected by a virus ?

-- bobololo.

[LostMP4]

Originally posted by bobololo
Aren't you infected by a virus ?

-- bobololo.

Excluding Microsoft and Norton software(now merged in the ultimate parasite, thanks to SP2 and Symantec updates), none :p
After its crash, mp4muxer.exe had this problem, I can't delete, move or rename it, but I can copy it, obtaining a new "locked" file :confused: (now I've in 4 folders 4 mp4muxers, 3 not-working and locked and 1 working freshly extracted from the archive)

[Andrey]

Generalizing results after full viewing 4 clips - Ateme H.264 has given more detailed picture from less artefacts than other codecs on 400kbit/s 720x352.
Inloop deblocking, I think.
BTW, the difference in water on last screenshot is really surprising.

One more question: if I kill codec process occasionally, the resulting file isn't playable (2nd pass, of course).
Is this the way things are ment to be ?

[Bulletproof]

Originally posted by LostMP4
About mp4muxer: it crashed muxing h264 video stream with a AAC.
Now the file is "locked" (mp4muxer), double-clicking on it says it isn't a valid win32 program, I can't use or delete it (I tryed restarting the PC, too)
I can copy it to another folder, obtaining another locked file that I can't delete :confused:
A "new" mp4muxer exctracted from the archive works well (audio in MP4, I don't dare to try aac anymore)
What's happened?

Try starting windows in safe mode and then delete the files.

[easyfab]

Originally posted by LostMP4
Excluding Microsoft and Norton software(now merged in the ultimate parasite, thanks to SP2 and Symantec updates), none :p
After its crash, mp4muxer.exe had this problem, I can't delete, move or rename it, but I can copy it, obtaining a new "locked" file :confused: (now I've in 4 folders 4 mp4muxers, 3 not-working and locked and 1 working freshly extracted from the archive)

ctrl+alt+suppr -> kill the explorer process and open a new explorer process, your files should be unlocked now.

[Andrey]

A bug, but I don't know if it is Atheme dshow filter or BSPlayer.
When playing at full screen, image is shown at the top, not centered...
EDIT:
I like how 630Kbit 512x304 encode of SW II looks in general with adaptive deblocking. Even better (subjectively) than XViD one with heavy preprocessing... (makroblocks in XViD are too ugly when dealing with myst, flying sand and so on)
When I will find how to create a screenshots, I will post them :)

[bobololo]

Finally we're going to release tonight a new beta that fixes most of the critical issues (last frame crash, mpc lock, etc.) we had so you can find out others ones ;) We hope this new one is more stable for your encodes !

In the Beta-2 you'll have :

- Last frame crash with bframes fixed (encavc.exe)
- CreateThread() error with Win98SE fixed (encavc.exe)
- new adaptive deblocking flag "-adaptdeblock" working in
association with -deblock <strength> (encavc.exe)
- 16 references issue fixed (encavc.exe)
- better RC for very low bitrate target (encavc.exe)
- Media Player Classic lock fixed (adf_srcmp4.ax)
- Insane memory usage of the decoder filter fixed (adf_dech264.ax)
- a new tool call mp4 tool box. It allows you to extract a part of
a mp4 file and save it to another one. You'll be able to upload
to us your files illustrating your observations.

About the new deblocking option, you'll be able to use the adaptive deblocking and adjust its working range depending on your preference. For instance you can set it as follow :

-deblock -2 -adaptdeblock

This will tell the encoder to adapt the deblocking strength around the -2 level.

Enjoy :)

-- bobololo.

[Sirber]

Any URL / email?

[bobololo]

Originally posted by Sirber
Any URL / email? You'll be notified by mail.

[SeeMoreDigital]

Blimey... a beta-2 already... You guys are really fast!

I'll have to get stuck in now!


Cheers

[virus]

Originally posted by bobololo
- CreateThread() error with Win98SE fixed (encavc.exe)

:D
(I managed to be useful encoding exactly 0 bytes...)

Thanks for the brand-new build bobololo, your efforts are very appreciated. The MP4 extraction tool is a great idea. :)

virus

[Soulhunter]

Ok, before getting the new version I gonna post my 1st speed results...


System: Athlon XP 3000+ / 1024MB DDR400 / Windows XP


Source: 1024x576 @ 29.97fps

Results:

~ 07.4 fps @ -qual normal

~ 05.5 fps @ -qual good

~ 04.7 fps @ -qual best

~ 04.0 fps @ -qual extra



Source: 720x576 @ 25fps

Results:

~ 14.8 fps @ -qual normal

~ 11.9 fps @ -qual good

~ 08.8 fps @ -qual best

~ 08.2 fps @ -qual extra



Source: 640x480 @ 25fps

Results:

~ 18.7 fps @ -qual normal

~ 14.4 fps @ -qual good

~ 10.7 fps @ -qual best

~ 09.5 fps @ -qual extra


For a H.264 encoder its damn fast !!!

First visual impression -> Wow... :eek:

Btw, does someone know a tool to extract "wanted" frames from this encodes ???


Bye

[superdump]

Originally posted by Soulhunter
Btw, does someone know a tool to extract "wanted" frames from this encodes ???

Originally posted by bobololo
- a new tool call mp4 tool box. It allows you to extract a part of
a mp4 file and save it to another one. You'll be able to upload
to us your files illustrating your observations.

[Soulhunter]

@ superdump

Maybe I understood this wrong, but...

Think its a mp4 splitting/cutting tool !?!

I meant a single frame -> picture tool...


Bye

[Teegedeck]

I wish I had more precise findings to contribute right now - but I'm stuck with this 19'' Trinitron today; better view tomorrow on a TFT.

Let me just say; the codec is a jolly good piece of work. Psychovisuals and deblocking still are a no-no for my type of encoding (surprise, surprise...) but generally it seems possible to reach transparency at quite a reasonable bitrate. I still have to verify that on the TFT though.

Till tomorrow.

[bill_baroud]

my computer died on me just when i got the first beta, so i'll start testing with the beta 2 .... no i'm not dead, sorry for the delay :D

[SeeMoreDigital]

Originally posted by Soulhunter
For a H.264 encoder its damn fast !!! Nice one Soulhunter!

What did your 1024x576 encodes look like compared to the other codecs you've tested?

I'm interested because I'm hoping to use AVC for full frame HighDef encoding!


Cheers

[Krismen]

I've got one question: Is there anybody who can give a link to Ateme h.264 directshow decoder?

[Sirber]

beta1 has been removed from the server.

[guldukat]

Originally posted by Krismen
I've got one question: Is there anybody who can give a link to Ateme h.264 directshow decoder?

you received this filter by mail, IF you'Re a beta tester, else you have to wait for the final release in the nero package

[chilledoutuk]

I took the DiVX Bourne supremacy HDTV trailer from DiVX networks website which had 3500kbps bitrate and rencoded it to 2000kbps h.264 and the quality was almost transparent which is impressive.

I’m going to run some more tests on some HDTV sources and see how it performs.

[Jukke]

Hi,
I got strange file sizes from the muxer. Encoded as follows:
encavc.exe -i tv4.avs -o video.mp4 -qual normal -rcmode 2pass -br 600000 -clref bpred -psy 1
mp4muxer.exe -i video.mp4 -i audio.mp4 -f t:audio -o av.mp4
The avs is:
LoadPlugin("C:\Program\av\GORDIA~1\AviSynthPlugins\dgdecode.dll")
mpeg2source("C:\Scratch\Captures\ateme\tv4.d2v")
crop(6,6,714,564)
LanczosResize(608,480)
The muxer output is:
drv_mp4: video.mp4:3 opened (video(AVC): 608x480)
drv_mp4: audio.mp4:1 opened (audio, 48000 Hz, 2 channels)
muxing stream(s): [0] AU 4519 (Video), [1] AU 4238 (Audio)
stream[0]: muxing done (4520 AUs, 180.75 s)
stream[1]: muxing done (4239 AUs, 180.81 s)
mux completed
video.mp4 is 13314kb
audio.mp4 is 1496kb
and the muxed av.mp4 is staggering 36474kb!
Anybody finds this normal?

[Soulhunter]

Originally posted by SeeMoreDigital
Nice one Soulhunter!

What did your 1024x576 encodes look like compared to the other codecs you've tested?

I'm interested because I'm hoping to use AVC for full frame HighDef encoding!


Cheers
The source for this encode was the 1080i space shuttle clip Ive linked @ the other thread !!!

Ive encoded it 12x times with bitrates between 500-10000 kbps...

Atm its too early to tell you something concrete !!!

But I will post back tomorrow... ;)


Bye

[Sagittaire]

- better RC for very low bitrate target (encavc.exe)

Yes RC 2 pass isn't very good: quality isn't constant and there are quality degradation for the end of encoding. It's a typical Rate Control problem: too much bit for the beginning and less bit for the end to respect the bitrate. It would be necessary to make the first pass with a higher quantizer to have better estimate for the second pass with high quantizer encodind (low compressibility encoding)

720*304 500 Kbps Matrix Reloaded encoding with 35 000 Frames

http://jfl1974.free.fr/Test/Comparatif/H264vsDivX5-500.JPG

http://jfl1974.free.fr/Test/Comparatif/H264vsXviD-500.jpg

http://jfl1974.free.fr/Test/Comparatif/H264vsVP6-500.JPG

http://jfl1974.free.fr/Test/Comparatif/H264vsWMV9-500.JPG

http://jfl1974.free.fr/Test/Comparatif/H264vsRV10-500.JPG

[superdump]

Originally posted by guldukat
you received this filter by mail, IF you'Re a beta tester, else you have to wait for the final release in the nero package The current NeroVision Express package will decode the files encoded here but there won't be any seeking.

[LostMP4]

Originally posted by superdump
The current NeroVision Express package will decode the files encoded here but there won't be any seeking.

Use Ateme's filters if you want to seek ;)

[Soulhunter]

Originally posted by Soulhunter

I meant a single frame -> picture tool...
Sorry, totally overlooked the easiest way... :o

Avisynth -> DirectShowSource -> VDubMod -> Snapshot source frame


Bye

[superdump]

LostMP4: Indeed, I was just making sure that that person knew they could use NVE to watch clips posted here if they weren't part of the beta test.

Originally posted by Soulhunter
Sorry, totally overlooked the easiest way... :o

Avisynth -> DirectShowSource -> VDubMod -> Snapshot source frameYou've managed to get DSSource() to work with the Ateme filters/AVC files? Interesting. As far as I know it doesn't work anywhere else bar decoding the first frame.

[Soulhunter]

Hmm, even @ 8000 kbps Ive spotted out some faults !!!


Blocks:

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

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


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

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


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

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


Gradients:

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

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


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

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


Originally posted by superdump

You've managed to get DSSource() to work with the Ateme filters/AVC files?

Uhm, yes...

DirectShowSource("C:\Ateme\2.mp4")

Made the screenshots above this way !!!


Bye

[superdump]

SoulHunter: Nice shots. Or rather, useful shots. On the first one the blocks are noticable on the smoke cloud on the left, but AVC seems to introduce to some artificial lighting on the lower left and up the right hand side. Very strange. In fact, now I've looked at the rest there seems to be an ongoing pattern of light introduction.

EDIT: What settings were you using? Did you use -psy >0?

[Tommy Carrot]

I didn't experienced any similar blocks and artifacts in my tests. Are you sure they are there during playback too? Can't be possible that the opening via avisynth causes them somehow(as most of us cannot open MP4s in avisynth)?

[Soulhunter]

Originally posted by superdump
What settings were you using? Did you use -psy >0?
Saved all command lines Ive used...

C:\Ateme\encavc.exe

-i C:\Ateme\shuttle.avs

-o C:\Ateme\2.mp4

-qual best

-rcmode 2pass

-br 10000000

-psy 0

Note: Ateme was maxed-out @ around 8000 kbps !!!


Originally posted by Tommy Carrot
I didn't experienced any similar blocks and artifacts in my tests. Are you sure they are there during playback too? Can't be possible that the opening via avisynth causes them somehow(as most of us cannot open MP4s in avisynth)?
Yes, its definitely visible while playback !!!

The two other sources Ive used are ok... :confused:

Think I gonna encode it again !!!

Need to sleep now... ;)


Bye

[bobololo]

A new beta of the encoder is ready for download. You should receive the link by mail in a few minutes. The change log was posted previsouly.

I strongly suggest you to use the new filters provided in this package as they should be more stable (just run reg.bat).

Also the jumping blocks in bframes issue isn't addressed in this version yet. So if you intend to test low bitrate encodes, it is recommanded to disable the bframes.

-- bobololo.

[bobololo]

Originally posted by Jukke
drv_mp4: video.mp4:3 opened (video(AVC): 608x480)
drv_mp4: audio.mp4:1 opened (audio, 48000 Hz, 2 channels)
muxing stream(s): [0] AU 4519 (Video), [1] AU 4238 (Audio)
stream[0]: muxing done (4520 AUs, 180.75 s)
stream[1]: muxing done (4239 AUs, 180.81 s)
mux completed
video.mp4 is 13314kb
audio.mp4 is 1496kb
and the muxed av.mp4 is staggering 36474kb!
Anybody finds this normal?

Nice, you find a little glitch in our file handling. You may have a previous file using the same name. Delete av.mp4 and try again. It should be better then. Let me know.

-- bobololo.

[virus]

:rolleyes:

this time I'm unable to render the file... I'm unable to register the filters. I run the .bat and regsrv32 does not give any error ("succeded"...). But the filters are not successfully registered and I cannot open/decode the file (the render fails, checked with GSpot, too). I've tried to build a graph manually using Graphedit but when I select the Ateme filters (both filters) from the list and hit "Insert filter" I get the following:

"The filter could not be created. Resources used by this filter may already be in use. Interface not registered (return code: 0x80040154)"

I've tried re-registering. No luck. :(
What can I do?

[superdump]

Originally posted by virus
:rolleyes:

this time I'm unable to render the file... I'm unable to register the filters. I run the .bat and regsrv32 does not give any error ("succeded"...). But the filters are not successfully registered and I cannot open/decode the file (the render fails, checked with GSpot, too). I've tried to build a graph manually using Graphedit but when I select the Ateme filters (both filters) from the list and hit "Insert filter" I get the following:

"The filter could not be created. Resources used by this filter may already be in use. Interface not registered (return code: 0x80040154)"

I've tried re-registering. No luck. :(
What can I do? I know it's the suckiest method ever, but have you tried rebooting? :)

[bobololo]

Originally posted by Andrey
One more question: if I kill codec process occasionally, the resulting file isn't playable (2nd pass, of course).
Is this the way things are ment to be ?

Yes, the mp4 file headers are written when the file is closed. If you kill the process while the encoding is running, the resulting file will miss these headers which makes it unusable.

-- bobololo.

[superdump]

You guys running beta 2 will most likely need the msvcrtd.dll (http://www.dll-files.com/dllindex/dll-files.shtml?msvcrtd) file available from that page to run the MP4 Tool Box program.

Here are a few nifty screenshots of what it can do:

http://www.swains.plus.com/superdump/MP4TB-01.png

http://www.swains.plus.com/superdump/MP4TB-02.png

http://www.swains.plus.com/superdump/MP4TB-03.png

http://www.swains.plus.com/superdump/MP4TB-04.png

http://www.swains.plus.com/superdump/MP4TB-05.png

[bobololo]

Originally posted by virus
:rolleyes:

this time I'm unable to render the file... I'm unable to register the filters. I run the .bat and regsrv32 does not give any error ("succeded"...). But the filters are not successfully registered and I cannot open/decode the file (the render fails, checked with GSpot, too). I've tried to build a graph manually using Graphedit but when I select the Ateme filters (both filters) from the list and hit "Insert filter" I get the following:

"The filter could not be created. Resources used by this filter may already be in use. Interface not registered (return code: 0x80040154)"

I've tried re-registering. No luck. :(
What can I do?

Maybe try unreg the filters from beta-1, then re-register those from beta-2. Is that still with win98se ? Maybe you could consider upgrading to 2k/xp ?

[virus]

Originally posted by bobololo
Maybe try unreg the filters from beta-1, then re-register those from beta-2. Is that still with win98se ? Maybe you could consider upgrading to 2k/xp ?
Yes, Win98SE. The filters from beta-1 have been unregistered and deleted right after you annunced the beta-2 release, I've even rebooted after deleting them. Oh, and I've also rebooted after installing the beta-2 ones. No luck.

And of course upgrading is out of question... I've got dozens of DS filters installed (some of them manually with regsrv32) and they all work pretty fine. Do you want me to buy a copy of WinXP just to beta-test a filter? ;)

[Sirber]

encavc.exe -i test.avs -o test.mp4 -qual extra -rcmode vbr -br 600000 -psy 1 -maxb 3 -cartoon -ref 2

Encoder encode at 3mbps, regardless what BR I set :confused:. Also, the output is unplayable.

http://www.detritus.qc.ca/test.mp4

[superdump]

Originally posted by bobololo
Maybe try unreg the filters from beta-1, then re-register those from beta-2. Is that still with win98se? Maybe you could consider upgrading to 2k/xp?Lol! Fantastic suggestion. :) I guess as M$ aren't supporting Win98SE anymore I guess Ateme might not need to. But still, it might be nice.

From my testing of the new adaptive deblocking with base level setting it's looking good. I would now recommend using this method over fixed and choose your level.

[bobololo]

Originally posted by Sirber
encavc.exe -i test.avs -o test.mp4 -qual extra -rcmode vbr -br 600000 -psy 1 -maxb 3 -cartoon -ref 2

Encoder encode at 3mbps, regardless what BR I set :confused:. Also, the output is unplayable.

Our VBR means constant quantizer, so the specified bitrate is just ignored. Try "-rcmode 2pass" instead.

[Sirber]

ha! encoding now at correct bitrate.

Thx!

[edit]

Output is still unplayable, with ffdshow or your filter. MPC uses 70% CPU though...

About encoding:
FPS is about 7-10 on my 2000+.

[bobololo]

Originally posted by Sirber
Output is still unplayable, with ffdshow or your filter. MPC uses 70% CPU though...

Are you using beta-2 filters ? have you try graphedit with the following graph ?

Ateme MPEG-4 Parser (your_file.mp4) -> Ateme H.264 Decoder -> Video Renderer

If this works, check at your mpc filter overrides and make ateme's prefered and block some eventual filters able to split mp4 and decode H.264.

-- bobololo.

[virus]

Originally posted by superdump
I guess as M$ aren't supporting Win98SE anymore I guess Ateme might not need to. But still, it might be nice.

Absolutely wrong. Support for the Win9x kernel has been extended until June 30, 2006 (link (http://tech-report.com/onearticle.x/6099)) due to the still relevant diffusion of this family of OSs. Also, Nero is fully Win9x-compliant (or at least, it runs well on my PC... together with XviD, VP6.2, DivX, 3ivX, ffdshow/ffvfw and many other stuff)
Do you really think that Ahead is going to buy an NT-only codec?

(but where's bond with his WinME box anyway? :))

[Sirber]

Works in GraphEdit, does not in MPC.

The only filters used are:
WMR7 (windowed)
Nero Video Decoder
my file

:confused:

Also, from what I've seen in Graphedit, Q is jumping and very squary. You can check with the file on top of this page.

[superdump]

Originally posted by Sirber
Also, from what I've seen in Graphedit, Q is jumping and very squary. You can check with the file on top of this page. This is probably almost all down to bskip being too aggressive at the moment. But a clip as stressful as that at that low a bit rate would probably look similar with any codec, no? Try disabling b-frames and maybe turn up the deblocking a bit.

[JohnV]

Originally posted by Sirber
Works in GraphEdit, does not in MPC.

The only filters used are:
WMR7 (windowed)
Nero Video Decoder
my file

:confused:

Also, from what I've seen in Graphedit, Q is jumping and very squary. You can check with the file on top of this page. Try this: Goto MPC options -> Filters -> Overrides, and make Ateme h264 decoder preferred.

[Sirber]

I did that, Ateem H264 is being used. No frames is displayed also. I know this is very stressfull for a codec, but RV10 and VP6 can manage to have good to medium quality on that test clip.

[superdump]

Originally posted by Sirber
I did that, Ateem H264 is being used. No frames is displayed also. I know this is very stressfull for a codec, but RV10 and VP6 can manage to have good to medium quality on that test clip.Did you try without b-frames and with something like '-deblock -2 -adaptdeblock'? Maybe even stronger than that. Try a few different settings and see what the best you can get is. When the b-frame problem is fixed you can make a proper comparison.

[Sirber]

At 3000kbps and at 600kbps, I can't play it. Karl seems to have played it correctly. I will check if it's bframe related, tomorrow :D

[LostMP4]

Last test (with beta-1)
This time to check ABR mode accuracy and to make a "faster" encode - quality is still very good and without B-frames

Core encoder version 1.0.1.14

Resolution : 720x576 @ 25.00 fps
Length : 72840 Frames
Rate Control : Abr
Target Bit Rate : 1200 kb/s
Quality : Normal
Init Quantiser : 20
Num Reference : 0
Psychovisual : 0
Cartoon mode : Off
Features : ipred ppred hpel qpel part

-- Start processing pass 1 / 1
* 72839: encoding @ 24.34 fps - bitrate 76.19 kb/s - 100.00% completed
* 72840 frames encoded @ 5.78 fps - average bitrate 1199.27 kb/s

[Jukke]

Originally posted by bobololo
Nice, you find a little glitch in our file handling. You may have a previous file using the same name. Delete av.mp4 and try again. It should be better then. Let me know.

-- bobololo. Bingo!
After re-muxing audio/video with no av.mp4 present the file sizes are just normal.

Audio: 1496kb
Video: 13315kb
Audio/Video: 14826kb

btw, my interlaced analogue TV-sources encodes pretty well, despite what the documentation says about interlaced material.

[plonk420]

bobololo, just like LAME has certain bitrates / presets that are tested a lot, are there any bitrate targets you might want to see tested more or genres of movies/video that would be more helpful than not? ie, Finding Nemo or, say, The Cell's "trip" sequence, or 30i/25i video?

[Teegedeck]

I believe finding a lead to good presets is one of the tasks beta-testers are supposed to fulfil.

[plonk420]

Originally posted by Sirber
Output is still unplayable, with ffdshow or your filter. MPC uses 70% CPU though...
[/B]

what bitrate and resolution? and i guess what clip? i got 720x480 @ 800kbps playing just fine on a AXP 1800+ with the beta1 decoder

[Selur]

just finished my 1st full film encode: (with beta 1)

Source: Demolition Man PAL DVD

input avisynthscript:
----------------------
LoadPlugin("C:\PROGRA~1\GORDIA~1\MPEG2Dec3.dll")
mpeg2source("D:\DEMOLITIONMAN169\VIDEO_TS\demolitionman.d2v")
crop(4,66,712,438)

encodersettings:
----------------------
"D:\encavc-beta-1\encavc" -i "D:\encavc-beta-1\demolitionman.avs" -o "D:\encavc-beta-1\demolitionman_753.mp4" -qual extra -rcmode 2pass -br 753000 -psy 2 -maxb 3 -par 16:9 -setef part -ref 5 -qp 12

an ended up with this:
http://selur.privat.t-online.de/line.jpg

haven't investigated much but since my earlier encodeings all look fine I suspect the line to be cased by the resolution 712x438.

Cu Selur

[plonk420]

man i'm feeling dumb tonight... how do you disable bframes? is it
-maxb 0
or
-setef bpred
i tried -setef bpred and bpred still showed up under Features
(this line: Features : ipred ppred bpred cabac deblock hpel qpel part)

[Jukke]

Originally posted by plonk420
man i'm feeling dumb tonight... how do you disable bframes? is it
-maxb 0
or
-setef bpred
i tried -setef bpred and bpred still showed up under Features
(this line: Features : ipred ppred bpred cabac deblock hpel qpel part) Try -clref bpred

[Sagittaire]

@ Selur

exotic resize 712x438 ... perhabs
use mod16 ...

@ Bobololo

with beta-2 (low compressibility encoding)

encavc.exe -i clip.avs -o H264-2000.mp4 -qual extra -rcmode 2pass -qp 30 -br 512000 -psy 2 -deblock -2 -adaptdeblock -ref 5

and ...

http://jfl1974.free.fr/Test/Comparatif/H264vsVP6-500.JPG

always RC probleme for the end of encoding ... target bitrate control is perfect (too perfect ... ???): quality is visualy very worst for the end ...

Perhabs a RC command ...

- RC light
poor target bitrate but very constant quality

- RC normal
good target bitrate and constant quality

- RC hard
perfect taget bitrate but constant quality is not certain

[Selur]

exotic resize 712x438
No resize, just cropping
(anamorph encoding is da way to go :D)

use mod16 ...
I will, just wanted to point out, that it`s buggy if your resolution is not mod16. :)

doing a small test with beta2 (same resolution) atm, and then with a mod4/mod8/mod16 encode, to see if mod4/8/16 is enough :)

=> same resolution with beta2 gives no problem :)

Cu Selur

[Gabriel_Bouvigne]

I did an encode of a 688x560/25fps clip with: -rcmode 2pass -br 600000 -clref qpel

I am unable to decode it in real time on my PIII 1.1GHz. I understand that this type of computer has not been sold since a few years, but I would have liked to be able to play it.

The thing that immediately come to my mind would be to reduce deblocking filter based on decoding speed. I understant that deblocking is done in loop on the encoder side and is a mandatory part of the standard, but perhaps some people could prefer to have a non compliant output than not beeing able to decode in real time.

Regarding ringing: it is quite different from the "usual" ASP ringing. It looks more like noise than ringing.

[bobololo]

To users who still have troubles with basic encoding, playing muxing, etc and can't get started (hey Sirber it's for you ;)). I strongly suggest you to join #mpeg on irc.freenode.org, there you'll find some fast and efficient support helping you to get the stuff working. So if you still are unable to encode and playback your file whereas every other seems to have no problem, just go there so we can prevent transforming this thread into a "getting started support" thread :)

Thanks.

ps: perhaps if this still continue, we really should split the thread into : "getting started, trouble & functional issues support" thread and "Quality feedback" thread as one of you already suggested ? What do you think ?

-- bobololo.

[Selur]

may be splitting into:
- getting started
- quality feadback
- bug report

Cu Selur

Ps.: didn`t happen with beta1:
-does anyone besides me have problems to playback beta2 files with tcmp? works fine with graphedit and wmp. (since it works when I, open it in graphedit and then open it in tcmp without closing graphedit I suspect it is a tcmp bug.)

-adding ffdshow as postprocessor gives me a green screen

[babayaga]

Originally posted by Sagittaire

with beta-2 (low compressibility encoding)

encavc.exe -i clip.avs -o H264-2000.mp4 -qual extra -rcmode 2pass -qp 30 -br 512000 -psy 2 -deblock -2 -adaptdeblock -ref 5

always RC probleme for the end of encoding ... target bitrate control is perfect (too perfect ... ???): quality is visualy very worst for the end ...

Perhabs a RC command ...

- RC light
poor target bitrate but very constant quality

- RC normal
good target bitrate and constant quality

- RC hard
perfect taget bitrate but constant quality is not certain

Just 2 small points :
1. your encode parameters don't give the best possible PSNR (-psy 0 -deblock -0 -cartoon should be better). For instance, -psy 1 or 2 should improve fades at the expense of the PSNR.

Regarding objective metrics like SSIM, our encoder should be above everybody else (including VP6 :-), but it's not the point in this beta test. We are far more interested by testers feelings.
Beeing 1 dB above XvID does not always implies that people with eyes prefer our encoder's results.
I've still in mind an XviD encode given by Cruncher that stuned me about the details and sharpness but that had relatively low objective metrics.

2. I guess I know the exact sequence you're using :-). I've not tried it lately and I'll check it tonight. This particular sequence stresses very much the fast 1st pass algorithm...

For the end of the sequence, you (and Superdump) made your point. The beheaviour will be modified to be on par with the rest of the sequence.

About the accuracy, I don't want to change it since it's very good and it's a very important issue to "normal" users.

Finally, don't suppose the RC algorithm we're using. It's very different from XviD or ffmpeg (AFAIK).

[LostMP4]

Beta 2, low bitrate, no B-frames (some blocking noticeable...)
Maybe an Abr related "bug": about at 98% encoding i noticed bitrate to stay over 6000 kb/s for a few seconds (to reach the filesize, I guess). It's better have an undersized file than having these peaks (visually "useless" but troublesome for playback from a CD and maybe incompatible with many profiles)

Core encoder version 1.0.1.16

Resolution : 720x576 @ 25.00 fps
Length : 72840 Frames
Rate Control : Abr
Target Bit Rate : 600 kb/s
Quality : Extra
Init Quantiser : 20
Deblocking Strength : -2 (adaptive)
Num Reference : 0
Psychovisual : 0
Cartoon mode : Off
Features : ipred ppred cabac deblock hpel qpel part

-- Start processing pass 1 / 1
* 72839: encoding @ 16.21 fps - bitrate 62.54 kb/s - 100.00% completed
* 72840 frames encoded @ 4.36 fps - average bitrate 599.77 kb/s

Encoding complete

[LostMP4]

A question about RAM usage in encoding: is it normal it uses about 200 MB? Is that related to the available RAM (I've 1024 MB) or a must?

[Teegedeck]

@anyone having playback problems: Do you have any other h.264 codec installed? Make sure to remove it if altering priorities in MPC or Windows' videocodec properties doesn't help. Delete the dlls if all else fails. (Make a backup copy if you're not quite sure what you are doing...)

[Selur]

takes about 110MB on my system with 512MB RAM and about 220MB on my system with 1024MB RAM.
=> no must :)

Cu Selur

Ps.: only h264 decoder I have on my system is ffdshow, but since I disabled h264 support in it, this shouldn`t be the problem.

[LigH]

Probably not much to add here (I'm a little late):

avs2mp4.bat@ECHO OFF
IF "%1" == "" GOTO NoParam
IF "%2" == "" GOTO NoParam
IF "%3" == "" GOTO NoParam

ECHO %0 %1 %2 %3
C:\Programme\encavc\encavc -i "%1" -o "%2" -qual best -rcmode 2pass -br %3 -psy 1 -adaptdeblock -ref 2
GOTO :End

:NoParam
ECHO Syntax: %0 ^<input.avs^> ^<output.mp4^> ^<bitrate^>

:End

Matrix_Reloaded_Trailer_Ultra.logavs2mp4.bat Matrix_Reloaded_Trailer_Ultra.avs Matrix_Reloaded_Trailer_Ultra.mp4 900000
ENCAVC - Copyright (c) 2004 ATEME (http://www.ateme.com)

This software is an experimental MPEG-4 AVC / H.264 encoder. It is intended
for evaluation purpose only and redistribution is strictly PROHIBITED.

Resulting files generated by this software can be corrupted due to the
instability of the encoder. Please report back if it occurs.

Core encoder version 1.0.1.16

Input file : Matrix_Reloaded_Trailer_Ultra.avs
Output file : Matrix_Reloaded_Trailer_Ultra.mp4
Resolution : 1000x540 @ 24.00 fps
Length : 3634 Frames
Rate Control : 2pass
Target Bit Rate : 900 kb/s
Quality : Best
Init Quantiser : 24
Max Consecutive BFrames : 3
Deblocking Strength : -2 (adaptive)
Num Reference : 2
Psychovisual : 1
Cartoon mode : Off
Features : ipred ppred bpred cabac deblock hpel qpel part

-- Start processing pass 1 / 2
* 100.00% completed
* 3634 frames processed @ 4.99 fps
-- Start processing pass 2 / 2
* 03633: encoding @ 10.37 fps - bitrate 4.53 kb/s - 100.00% completed
* 3634 frames encoded @ 5.05 fps - average bitrate 900.25 kb/s

Encoding complete
Summary so far:

- stable, fairly fast for H.264 (3.2 GHz P4-HT)
- plays well in: WMP 6.4, WMP 9 (no seeking, though - just linear playback, pauseable)
{ addition: WMP 6.4 (player2.exe) crashes on exit. }
- does not play in: MPC (jumps between start/end forth and back), Nero ShowTime (black output, but timeline advances)
- 900 kbps is a bit too low for 1000x540 in a few scenes, but overall: :eek: as expected frm H.264

[Gabriel_Bouvigne]

I tryed without deblocking filter, and unfortunately it doesn't help enough to make the upper clip decodable in real time.

[Selur]

@Gabriel_Bouvigne: disabling cabac might also speed things up

[Sagittaire]

@Gabriel_Bouvigne

try -clref bpred,cabac for high resolution

[LostMP4]

Originally posted by LigH
Summary so far:

- stable, fairly fast for H.264 (3.2 GHz P4-HT)
- plays well in: WMP 6.4, WMP 9 (no seeking, though - just linear playback, pauseable)
- does not play in: MPC (jumps between start/end forth and back), Nero ShowTime (black output, but timeline advances)
- 900 kbps is a bit too low for 1000x540 in a few scenes, but overall: :eek: as expected frm H.264

It should play in Showtime, maybe you haven't the latest update installed

[Sirber]

Originally posted by plonk420
what bitrate and resolution? and i guess what clip? i got 720x480 @ 800kbps playing just fine on a AXP 1800+ with the beta1 decoder 640x480. I don't think it's CPU related.

[Sirber]

Originally posted by LigH
- does not play in: MPC (jumps between start/end forth and back), Nero ShowTime (black output, but timeline advances)Same problem as me :D

[Teegedeck]

Right-click and check if it actually is the Ateme-filter which does the playback.

[Manao]

LostMP4 : your speaking of encoding ? If so, in the 200 MB, you should count the memory used by avisynth. For me ( 512 MB ), with a classic script, encavc ( ref 5, bpred, 712x438 ) uses 87 MB. If I add to the script SetMemoryMax(16), it takes only 39 MB.

[Jukke]

Originally posted by LigH
- does not play in: MPC (jumps between start/end forth and back), Nero ShowTime (black output, but timeline advances)
Beta2 encodes (3 minute clips) runs smoothly in MPC on my machine (as mentioned earlier, had to disable h264 support in ffDShow for the ateme decoder to get into action), can seek as well. Nero ShowTime locks up when trying to seek.

[Sirber]

Originally posted by Teegedeck
Right-click and check if it actually is the Ateme-filter which does the playback. It is, check page 8.

[Soulhunter]

Something about the new version...

Im no more able to open the mp4's in VDubMod via AviSynth's DirectShowSource !!!

I get this (http://img86.exs.cx/my.php?loc=img86&image=New_AtemeB2.png) here... :(

After registering the old filters, everything works !!!


Bye

[JohnV]

Originally posted by Gabriel_Bouvigne
I did an encode of a 688x560/25fps clip with: -rcmode 2pass -br 600000 -clref qpel

I am unable to decode it in real time on my PIII 1.1GHz. I understand that this type of computer has not been sold since a few years, but I would have liked to be able to play it.

The thing that immediately come to my mind would be to reduce deblocking filter based on decoding speed. I understant that deblocking is done in loop on the encoder side and is a mandatory part of the standard, but perhaps some people could prefer to have a non compliant output than not beeing able to decode in real time.

Regarding ringing: it is quite different from the "usual" ASP ringing. It looks more like noise than ringing.
I'd try -clref bpred,deblock.
Also using adaptive deblocking often uses less cpu than constant.

[Jukke]

Wouldn't it be nice if the encoder could have a mode similar to the thread priority idle in Virtualdub? Would be great if the encoder could run silently in the background, without slowing down other applications running on the machine at the same time.
I guess the supposed audience of the encoder would like to do other things with their only home computer than just encode video.

[Sirber]

I think that will be handeled by Nero once the codec is in it.

[Soulhunter]

Strange, what happened here... :confused:

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

- Ateme sample (http://img86.exs.cx/my.php?loc=img86&image=Ateme_5_550.png)
-qual best -rcmode 2pass -br 10000000 -psy 0 -maxb 1
Note: I raised the brightness 5% to make this fault more visible !!!


Bye

[thegeby]

Report
Beta 2
Celeron 2.66 512MB
Clip from NTSC film

AVS Script:
Loadplugin(MPEGDecoder.dll)
MPEGSource(lost.vob)
ConvertToYV12

Default avcenc

Encoding freezes at +/-80%. Identical result with two different clips (from same movie)

[LigH]

Originally posted by Teegedeck
Right-click and check if it actually is the Ateme-filter which does the playback.
MPC uses the "Nero Video Decoder". I'd probably have to update NVE, the filter tells me (C) 2003; stupid me...
__

After updating to NVE 2.1.2.18:

MPC plays (pauseable), but hangs or crashes on stop. Hangs on seek.
WMP 6.4 tries hard to seek but hangs. Stoppable.
NST 1.5.0.37: Black window, but advances (reports "Video: AVC")

After un- and re-registering the Ateme beta 2 filter:

MPC jumps forth and back between start and end. Those were the same I had before updating NVE.

[JohnV]

Originally posted by LigH
MPC uses the "Nero Video Decoder". I'd probably have to update NVE, the filter tells me (C) 2003; stupid me...
__

After updating to NVE 2.1.2.18:

MPC plays (pauseable), but hangs or crashes on stop. Hangs on seek.
WMP 6.4 tries hard to seek but hangs. Stoppable.
NST 1.5.0.37: Black window, but advances (reports "Video: AVC")

After un- and re-registering the Ateme beta 2 filter:

MPC jumps forth and back between start and end. Those were the same I had before updating NVE.
In MPC try preferring the Ateme filter and disable raw video decoding from ffdshow if you have that enabled.

[LigH]

Originally posted by JohnV
In MPC try preferring the Ateme filter...
Yes, this worked!

MPC plays fine, seekable, pauseable, stoppable. :cool:

Let's see if we can prefer its merit permanetly using e.g. RadLight filter manager.

[superdump]

Originally posted by Soulhunter
Strange, what happened here... :confused:

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

- Ateme sample (http://img86.exs.cx/my.php?loc=img86&image=Ateme_5_550.png)
-qual best -rcmode 2pass -br 10000000 -psy 0 -maxb 1
Note: I raised the brightness 5% to make this fault more visible !!!Is the brightness level the same in your reference and output snapshots?

[superdump]

Originally posted by Jukke
Wouldn't it be nice if the encoder could have a mode similar to the thread priority idle in Virtualdub? Would be great if the encoder could run silently in the background, without slowing down other applications running on the machine at the same time.
I guess the supposed audience of the encoder would like to do other things with their only home computer than just encode video. Use ctrl+alt+delete and right-click on the encavc process to set the priority to whatever level you wish. I think you're looking for "low". :)

[superdump]

Originally posted by Soulhunter
Something about the new version...

Im no more able to open the mp4's in VDubMod via AviSynth's DirectShowSource !!!

I get this (http://img86.exs.cx/my.php?loc=img86&image=New_AtemeB2.png) here... :(

After registering the old filters, everything works !!!With the old filters, for me, it would just decode the first frame and no more. With the new filters, I also get this green output. We're not sure why at the moment.

[P0l1m0rph1c]

Or use start.exe. Like:

start /IDLE encavc -i asdasd.avs -o asdasd.avs -br 123123 blah blah

[Jukke]

Originally posted by superdump
Use ctrl+alt+delete and right-click on the encavc process to set the priority to whatever level you wish. I think you're looking for "low". :) :) You're so right! Never seen that option before, I'm happy.

[Jukke]

Originally posted by P0l1m0rph1c
Or use start.exe. Like:

start /IDLE encavc -i asdasd.avs -o asdasd.avs -br 123123 blah blah Even better than Superdump's way. Great, thanks!

[Soulhunter]

Originally posted by superdump
Is the brightness level the same in your reference and output snapshots?
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 ???


Bye

[bobololo]

Some of you ask me for futher mp4muxer documentation. Here it is :

mp4muxer.exe -i <stream> [-f <extra_params>] [[-i <stream>] [-f <extra_params>]] [-m <interleaving in ms>] -o <output.mp4>

When <stream> is a mp4 file, you can pass extra parameters to specify which track you want to use (indeed, the mp4 file can contain several audio/video tracks). The extra parameters are :

"t:audio" to use first audio track (without the double quotes)
"t:video" to use first video track (without the double quotes)

If you want a audio or video track different from the first one, you can use :

t:audio&id=<trackid>
t:video&id=<trackid>

where <trackid> is the correct track id to use (you can get the track id using mp4 tool box). Be sure to know what you're doing when using these advanced parameters.

When <stream> is aac file (adts format), there is no extra parameter available.

Please make sure your file has .mp4 or .aac extensions. Others will be ignored.

ps: a new -priority <above|below|idle|normal|high|realtime> has just been added to encavc.exe :) To be available in the next beta release.

-- bobololo.

edit: -priority option is not in available in beta 2 yet.

[Jukke]

Originally posted by bobololo
Some of you ask me for futher mp4muxer documentation. Here it is :

mp4muxer.exe -i <stream> [-f <extra_params>] [[-i <stream>] [-f <extra_params>]] [-m <interleaving in ms>] -o <output.mp4>

ps: a new -priority <above|below|idle|normal|high|realtime> has been added to encavc.exe :)Beautiful!

When we're at it, when you wrap AAC audio in an mp4-container in FAAC, you could also add some metadata (or is it atoms?) like:
faac.exe -w -q 75 --artist "Author" --title "Title" --comment "Rating" "UsualSuspects.wav" -o "audio.mp4"
Is it possible to add similar functionality to mp4muxer?

[edit] formatting

[Selur]

okay, now I'm
1st totally lost in this thread, too much discussion :)
2nd grumpy since the dsfilters don't like me
(won't work with directshowsource in avisynth; don't like ffdshow als postprocessor; only seem to work like they should in MPC, which I don't like,...)
3rd frustrated, since I just killed my second full movie encode
(pressed the wrong batchfile :( (I wrote) )

Cu Selur

[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 :)

[virus]

Some numbers about the efficiency of the new tools... :)

Encoding at fixed quantizer: -rcmode vbr -qp 20 <other options>
(this should be roughly equivalent to a 1stpass with XviD)

-qual normal -clref bpred,cabac,part -adaptdeblock
2560.09 kbit/s

-qual best -clref bpred,cabac,part -adaptdeblock
2387.80 kbit/s

-qual extra -clref bpred,cabac,part -adaptdeblock
2385.78 kbit/s

-qual extra -clref bpred,cabac -adaptdeblock
2301.58 kbit/s

-qual extra -clref bpred -adaptdeblock
2187.28 kbit/s

-qual extra -ref 3 -clref bpred -adaptdeblock
2172.43 kbit/s

-qual extra -ref 3 -maxb 2 -adaptdeblock
2068.38 kbit/s

CABAC is not a surprise, I always rated it as the best innovation in H.264. Multiple frames references score quite badly here because this tool shines on low/mid motion scenes (and this was not our case). I wonder how many room is still left for improving the MB partitioning tool, since it doesn't use 8x4, 4x8 and 4x4 blocks. Maybe they can be supported in "extra" quality mode? (the algorithm itself is already quite time-consuming)

A further note: encavc saturates at ridiculously high bitrates. It delivered on this very same clip up to 12 mbit/s (with spikes of 20!). Is this a side-effect of the exponential quantizers used in H.264? A bitrate explosion at low QPs?

[Manao]

You should also take into account the PSNR in your figures ( or at least visual impressions ) : for exemple, between best and extra the size almost doesn't change, but the PSNR raises.

H264 indeed saturates at a very high bitrate, but even if subjective transparency is reached around a quantizer of 18, PSNR is still improved if you lower the quantizer ( for example, where XviD at quant 2 was giving a PSNR of 44.5, H264 is able to give a PSNR of 50 or more, with a higher size, of course )

[BoNz1]

Hi, first I must apologize for my slow testing :(. It took a long time to gather these results and make some hopefully useful comments about them.

Anyway, I have done some subjective testing on the Ateme beta 2 H.264 encoder and XviD 1.01. As they are subjective I have not drawn any conclusions from the results ie which codec is better etc. IF you decide to, beware! These are all reasonably hard clips and may not be representative of a real encode of a full length video. Also, how I perceive quality may be different than you. But I think some problems with both codecs were identified though.

Anyway, I do have some more clips I wanted to test. But I am very tired and it has taken me almost 5 hours to do these 4 clips. I will provide the source video clips tomorrow if that is deemed necessary.

Beware, this thing is 9 pages long. Although a lot of it is settings and other boring stuff you can skip ;). Here it is! (http://www.geocities.com/bonzi5252/Subjective_Test.zip)

[thegeby]

Just did a double testing against a 98.2MB 1280x720p WMV clip, transcoding from that clip via Avisynth and using the same bitrate (less the original audio). I am VERY impressed with the beta.

1) clip using vbr 6000000, otherwise default, resulting filesize 70.5 MB, much smoother playback than the original on a Celeron 1.8GHz, the same slight judder as noted by others. Playback rate varying from 2.8 Mb/s all the way to 20.5Mb/s. This is OK for local playback, but would cause problems during broadcasting.

2) Clip using cbr 6000000, otherwise default, resulting filesize 79.7 MB, no obvious difference in playback vs. clip 1). Playback rate, exceeding target at 7.2-7.7 Mb/s.

Given that this is made from a clip that is specifically picked for WMV quality and transcoded to H.264....Wow.

However for broadcast use, it needs to achieve these results at a lower bitrate (not to mention real time encoding:D ).

[Manao]

The flag -rcmode vbr makes the encode being done at fixed quantizer, bitrate control is then disabled, so you were lucky to reach the right size in your first attempt ( if you reached it ). It's astonishing that cbr doesn't reach the bitrate you're asking, since regulation seems accurate ( except perhaps at low bitrate, which is not the case here ).

[plonk]

Originally posted by Teegedeck
@anyone having playback problems: Do you have any other h.264 codec installed? Make sure to remove it if altering priorities in MPC or Windows' videocodec properties doesn't help. Delete the dlls if all else fails. (Make a backup copy if you're not quite sure what you are doing...)

i was having audio playback problems. solved by a combination of removing 3ivx and removing some preferred/blocked filters in MPC's Override section. pity, because i liked the ease of using 3ivx and graphedit to mux mp4s...

[Manao]

BoNz1 : I read your comments : very interesting. The first subjective measurement is however rather astonishing ( h264 being worse than XviD ) but your visual impressions seems to confirm it ( EDIT : my bad, I thought subjective measurement in VQStudio was simply a VQM measurement, but it isn't. So results aren't astonishing anymore /EDIT ). You should test without bpred ( since they have a mocing blocks issue for the moment ).

Also, since you used inloop deblocking for h264, did you postprocess XviD to make the comparison ? If not, I think it would be fair to do so, since the major issue you're raising is blocking.

[plonk]

Originally posted by Soulhunter

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 !!!


yeah, one of the READMEs states that the ftp upload folder is upload only, so no downloads, and i'm assuming no LISTings

[LigH]

I did a few more encodes on a Duron 800. Stable; speed in comparable relation to my previous tests.

Direct sample:
H:\Programme\encavc\avs2mp4.bat j:MRev.avs j:MRev.mp4 900000
ENCAVC - Copyright (c) 2004 ATEME (http://www.ateme.com)

This software is an experimental MPEG-4 AVC / H.264 encoder. It is intended
for evaluation purpose only and redistribution is strictly PROHIBITED.

Resulting files generated by this software can be corrupted due to the
instability of the encoder. Please report back if it occurs.

Core encoder version 1.0.1.16

Input file : j:MRev.avs
Output file : j:MRev.mp4
Resolution : 1024x532 @ 24.00 fps
Length : 3600 Frames
Rate Control : 2pass
Target Bit Rate : 900 kb/s
Quality : Best
Init Quantiser : 24
Max Consecutive BFrames : 3
Deblocking Strength : -2 (adaptive)
Num Reference : 5
Psychovisual : 2
Cartoon mode : On
Features : ipred ppred bpred cabac deblock hpel qpel part

-- Start processing pass 1 / 2
* 100.00% completed
* 3600 frames processed @ 1.94 fps
-- Start processing pass 2 / 2
* 03599: encoding @ 2.84 fps - bitrate 56.21 kb/s - 100.00% completed
* 3600 frames encoded @ 1.98 fps - average bitrate 900.80 kb/s

Encoding complete
Resized sample:
H:\Programme\encavc\avs2mp4.bat j:MRev'.avs j:MRev'.mp4 900000
ENCAVC - Copyright (c) 2004 ATEME (http://www.ateme.com)

This software is an experimental MPEG-4 AVC / H.264 encoder. It is intended
for evaluation purpose only and redistribution is strictly PROHIBITED.

Resulting files generated by this software can be corrupted due to the
instability of the encoder. Please report back if it occurs.

Core encoder version 1.0.1.16

Input file : j:MRev'.avs
Output file : j:MRev'.mp4
Resolution : 512x272 @ 24.00 fps
Length : 3600 Frames
Rate Control : 2pass
Target Bit Rate : 900 kb/s
Quality : Best
Init Quantiser : 24
Max Consecutive BFrames : 3
Deblocking Strength : -2 (adaptive)
Num Reference : 5
Psychovisual : 2
Cartoon mode : On
Features : ipred ppred bpred cabac deblock hpel qpel part

-- Start processing pass 1 / 2
* 100.00% completed
* 3600 frames processed @ 4.64 fps
-- Start processing pass 2 / 2
* 03599: encoding @ 10.37 fps - bitrate 8.68 kb/s - 100.00% completed
* 3600 frames encoded @ 4.68 fps - average bitrate 900.59 kb/s

Encoding complete
Now I wanted to compare the results using AviSynth functions like Compare(), SSIM() - unfortunately:

- DirectShowSource fails (green video)
- GraphEdit fails to save a *.GRF file (Error 80004003: Invalid pointer).

Had to construct a graph manually to save the Ateme output as an AVI file:

Ateme MPEG-4 File Parser => Ateme H264 Decoder => AVI Decompressor => (a VfW encoder) => AVI Mux => File writer

But the resulting AVI file requires a SwapUV(); can I add a filter to do that in the graph?

[everwicked]

Originally posted by BoNz1
Anyway, I have done some subjective testing on the Ateme beta 2 H.264 encoder and XviD 1.01.

Congratulations, you're the first person to conduct a blind test in this thread :)

[Teegedeck]

To my shame I must admit that I didn't get Visual Quality Studio to work. :( After testing, the promised results don't pop up. So I have to rely on switching between the two clips manually.

[Selur]

btw. would be cool if the encoder could/would support/use both/all cpu's on smp systems. (got a dual athlon mp 1800+ system,.. 50-60% CPU usage during encoding :( )

Cu Selur

[lexor]

Originally posted by everwicked
Congratulations, you're the first person to conduct a blind test in this thread :)
blind test? with a video encoder? umm... I see nothing wrong with that testing methodology. :D

[thegeby]

Re: Manao
The flag -rcmode vbr makes the encode being done at fixed quantizer, bitrate control is then disabled

I realise my considerations are a bit premature, but my interest is mainly in H.264 as a possible future HDTV broadcast codec. This makes bitrate the main interesting parameter. If it does not fit in a 7 or 8 MHz broadcast channel (6 MHz if in the US) it will not do. What I am really looking for is a bitrate that would allow two HDTV channels multiplexed in one broadcast channel.

The original Ateme Matrix clip did that, but unless you are running a pure film channel, you are bound to do live segments...., i.e as quick encodes as possible. Given that this is an early public beta, I can only repeat that I am impressed.

[SeeMoreDigital]

Congratulations everyone :D

In the few days this thread began, it has taken the forum by storm!

Well done Ateme for giving us the chance to get involved in such a well organised and professional way.


Thanks bobololo

[LigH]

Unfortunately, I don't see a useful way to run an objective comparison: I tried to export the mentioned graph to an AVI file (e.g. a pure YV12 video). But the result has almost 3 times as many frames as the original one... :confused:

And which filter preference merits I tried, DirectShowSource() only returns a green picture.

Besides that, the Ateme filters are fast enough to play back the video smoothly with 512x272 or 512x288 pixels at 24 fps on a Duron 800: Well done, they are nicely fast for playback.

[virus]

Originally posted by LigH
And which filter preference merits I tried, DirectShowSource() only returns a green picture.
DirectShowSource() doesn't work with the latest NVE filters, too. It returns "unable to determine the duration of the video", even if I specify "fps=25" and "seek=false" in the call (seeking is b0rked for these filters)...

@Manao: ...that's why I didn't provide PSNR values... I simply cannot compute them with CompareYV12() and evaluate them against the values I've already calculated for the other codecs. (you should know better that I'm a PSNR freak ;))

[Mr_Schizo]

Ok, here is a little feedback from my tests so far.
* Check the stability of the encoder
No Problems here till now (with beta2). Checked with alot of smaller clips,trailers and 2 Full movie encodes.
* Check if the encoder performs well on various source types (progressive only)
The "Core Performance" (i don't count RC and deblocking as Core in this case)of the encoder is very powerfull on the most "hollywood" movies/trailer. But their is also an exception where the encoder performs very bad. It seems that the encoder has some difficulties with very sharp,grainy,detailed slow motion material with unnatural contrasts. This can lead to blocks, ugly grain removal and extreme heavy blurring (inloop deblocker)- everything in the same clip with the terrible result of a heavy fluctuating quality.
* Check the encoder performance on different computers
I've only checked it on my own computer where i like the performance. It's pretty fast for a h264 encoder even with slowest settings.

2500XP,704x288 1.pass ~37fps 2.Pass ~8fps with slowest settings
* Check the efficiency of tools with regards to the quality improvement
I can't see any gain from PSY or REF but i'll use it as long as i also can't spot out any negative effects of it. Quality is much more important than speed, at least for me. The gain from best to extra is noticeable in the most cases, so i'll use the latter. I haven't played around enough with b-frames till now to give any decent statements about it.
* Check which settings are the best suited to your eyes !
My preferred settings for 1CD encodes atm are:
Natural material:
RC: 2pass
Quality: extra
maxB-frames: 3
deblocking strength:-deblock -2/-3/-4 -adaptdeblock (can't realy spot out any differences between the three-maybe a bug or my bad eyes)
Num of Ref Frames: 5 (bobo said that it works smart, so it should not harm except of the speed decrease)
PSY: 2
Cartoon Mode: On (gives a slightly noticeable quality improvement)
Features: everything enabled (haven't tried that till now)
Cartoon/Anime Material: not testet
* Check the encoder against competitors (xvid, vp6, wm9, etc.)
Nothing to check here! ;) It's clearly superior in 9 of 10 encodes against everything i've seen so far.

What should be improved ?:
-The b-frame issue-flickering blocks (done allready afaik)
-the handling of grainy material
-RC coupled with deblocking
-PSY should be coupled with deblocking which works picture-part-based (something like higher quants in the background caused of PSY also means higher deblocking of the background and so on)
*The last 2 points are the ones where i see by far the most room for improvements.

Ok, thats it for now :) !

[everwicked]

Originally posted by Teegedeck
To my shame I must admit that I didn't get Visual Quality Studio to work. :( After testing, the promised results don't pop up. So I have to rely on switching between the two clips manually.

My sincere apologies. I fixed it shortly after I uploaded the last beta but then I forgot to update the site... That's what you get for working late.

Anyways, here (http://www.everwicked.com/vqstudio/beta/subjective-20040902.zip) 's the fixed version.

[Teegedeck]

Thanks :) a lot, will try it tomorrow.

[Tommy Carrot]

All right, guys, it's time to share my findings about the quality of this codec. :) I made a little quality comparison test against xvid. I used constant quantizer, because i think this is the most fair way to compare the raw performance of the codecs.

The settings of the xvid encoding was: mpeg quant 3, bframes(2,1.5,1), vhq 4, chroma me. I choosed these settings because these are close enough to the real life 1cd rips settings i usually use. The resulting video file is 53,662 kb.

My goal was to find the settings for the ateme h.264 codec which gives subjectively nearly identical visual result to the above one. I've used extra quality and disabled b-frames, and vbr RC mode, other than those, everything was at default.

I've started to increase the quantizer until i felt the quality of the two videos are almost perfectly matching, and this came at quant 27. At most scenes, h.264 was still better with slightly more details and cleaner pictures, while xvid was a bit better in a few cases, especially in the darker scenes (but this was the minority in the clip).

And here comes the best part of it: the resulting filesize is 32,310 kb!!! H.264 delivered similar quality at ~60% bitrate, compared to xvid. If this is not fucking impressive, i don't know what is!

[bobololo]

@RBF: regarding, our mp4 source filter is simply a helping tool for us, it's not intended to have all the features you can expect from ND products filters (support for multi audio, subtitle, chapter, etc.). And we won't support it since it is not the purpose. Also you spotted an nice idea, we could add options in encavc to limit the quantizer range. We should have them in beta 3.

@Soulhunter: your file is up, can you also post the t3 trailer source you're using ? Thanks.

@Mr_Schizo: the decode filter doesn't support AR settings for now. We'll try to do something, but it's not a high priority task since you can adjust the AR in mpc manually.

@Teegedeck: I see your point, I really suggest your then to make your tries on homogeneous sequence. About the adaptive deblocking, it's actually how it works. It's adjust the filter strength depending on the picture quantizer.

[BoNz1]

Originally posted by Manao
You should test without bpred ( since they have a mocing blocks issue for the moment ).


Well, I had considered doing this. However, I decided against it. It is a known issue so I didn't really worry about it. I didn't notice any frames like Soulhunter found. If I would have seen some frames like this I might have considered testing without bpred. I probably did have some impact on the results. But it is difficult to tell how much without doing another subjective test ;).


Also, since you used inloop deblocking for h264, did you postprocess XviD to make the comparison ? If not, I think it would be fair to do so, since the major issue you're raising is blocking.

Well that is a good point and one that I had not thought of. Usually, I watch all my XviD encodes without any postprocessing since I find this to be more pleasing to my eyes than with it on. So they settings in the XviD decoder were exactly the same.

[CruNcher]

@LigH

you could gain some extra speed without part like +2-4 fps without loseing to much.

Ok i almost finished all my testclips and overall i have to say im impressed by the Detail Preservation and Ringin prevention @ low bitrates as this are my main criterias as everyone knows :)
The only drawback are the backgrounds in low bitrate encodes short transforms do not really well with them there i would prefer ASP for but well it's a matter of how you like it anyways :P
So i soon will start with full DVD encodes with my settings and then it's time for finding enhanceing solutions :D

Here is what seems to be a prediction bug that i found lately

Source Frame (after transition)
http://cruncher.mufflastig.com/h264/source.png
Source Transition
http://cruncher.mufflastig.com/h264/sourcetransition.png
Compressed Result (after transition)
http://cruncher.mufflastig.com/h264/coloredblocks.png

[Teegedeck]

Originally posted by bobololo
About the adaptive deblocking, it's actually how it works. It's adjust the filter strength depending on the picture quantizer.
Maybe it would be good to change its adaptive behaviour a bit in the long run. For me, the same adaptive deblocking strength that was too strong for quant 20 was too weak for quant 23. I'll hopefully have the time today to do one or two more hours of testing.

ATM strengths like these seemed to preserve a maximum of detail while providing enough smoothing:

qp 19: none
qp 20: -3
qp 21: -2
qp 22: 0
qp 23: 3

Now, don't tell me that adaptive strength -3 at quant 20 will actually have no effect at all and that my eyes betrayed me - such things do happen but hopefully not to me. ;)

[babayaga]

Originally posted by virus
A further note: encavc saturates at ridiculously high bitrates. It delivered on this very same clip up to 12 mbit/s (with spikes of 20!). Is this a side-effect of the exponential quantizers used in H.264? A bitrate explosion at low QPs?

At low quantisers (below about Qp=20), the relation between the bitrate and the quantiser is close to a straight line.

For instance, the bitrate should be something like 6 times higher at Qp=0 than Qp=20

[Andrey]

Hi guys.
I was a bit off testing because of terrorist attack on school here.
:devil:
I don't know when I will be on a good mood again...

Ok, back to the codec.
One problem (I think) I noticed - seems that there are some problems with rate control. Doing Equilibrium encoding at 912Kbit I occassionally was near monitor while encoding finishing.
At 99.6% avg bitrate begin to raise constantly and reached 5.5Mbit !!!
Then at 99.8% it begin to drop and reached 190Kbit.
But when I look at the picture, I didn't see that quality is too high or too low. May be that was a concole printing bug ?

About encoding: with deblocking -4 + adaptive it is still too blurry compared to XViD + MPEG quantizer. (not h263 one!)
BTW, how to create a screenshot ? MPC still crashes when trying to do it in standard way...

[babayaga]

Originally posted by Andrey

One problem (I think) I noticed - seems that there are some problems with rate control. Doing Equilibrium encoding at 912Kbit I occassionally was near monitor while encoding finishing.
At 99.6% avg bitrate begin to raise constantly and reached 5.5Mbit !!!
Then at 99.8% it begin to drop and reached 190Kbit.
But when I look at the picture, I didn't see that quality is too high or too low. May be that was a concole printing bug ?

Was it during the first or the second pass ?

Anyway, this kind of things eventually happen and this is no bug, since you don't spot a quality modification (which is the goal) and the size is correctly achieved.
BTW the size of individual frames varies in a very large proportion, even larger than in MPEG-4.

If you fear about the ability of you CD player, there is an option to limit the maximum instaneous bitrate but it's not available in the beta.

[Andrey]

Second pass.
The bitrate was fluctuating in 600Kbit - 1200Kbit (which, I think, is normal for 912Kbit encode) as I occassionaly looked at the monitor.
But that ~6Mbit was a bit overtop, I think :)
Especially on a practically still scene - if you remeber Equilibrium end...

>>If you fear about the ability of you CD player, there is an option to limit the maximum instaneous bitrate but it's not available in the beta.
Thanks for the info...

[LostMP4]

Originally posted by Andrey
Second pass.
The bitrate was fluctuating in 600Kbit - 1200Kbit (which, I think, is normal for 912Kbit encode) as I occassionaly looked at the monitor.
But that ~6Mbit was a bit overtop, I think :)
Especially on a practically still scene - if you remeber Equilibrium end...

>>If you fear about the ability of you CD player, there is an option to limit the maximum instaneous bitrate but it's not available in the beta.
Thanks for the info...

The same happened to me, as reported some posts ago, and it looks to me a way to reach the final filesize, since it happened during static credits
I'd like to obtain an undersized file more than a beefed file

[Soulhunter]

Originally posted by bobololo

@Soulhunter: your file is up, can you also post the t3 trailer source you're using ? Thanks.Ok then, simply wasn't sure coz the index was still shown empty !!!

The source "Soulhunter_T3_Source.avi" is on the way... ;)


EDIT:

Some additional info for ya guys...

- Used decoder was ffdshow (even if VDubMod tells its XviD)

- I feeded the file via AviSynth -> AviSource to the encoder


Bye

[Sagittaire]

SSIM test: HPII 640*272 800 Kbps
*best for my eyes


options SSIM

defaut 80.53

qual normal 77.84
qual good 79.66
qual best 80.53 *
qual extra 80.65 *

psy 0 80.53
psy 1 80.79 *
psy 2 80.83 *

deblock -6 79.68
deblock -4 79.88
deblock -2 80.53 *
deblock 0 80.99
deblock 2 80.47
deblock 4 78.69
deblock 6 75.98

adapt -6 79.68
adapt -4 79.68
adapt -2 79.68
adapt 0 79.76
adapt 2 80.21
adapt 4 80.75 *
adapt 6 80.88

maxb 3 80.53 *
maxb 2 80.55 *
maxb 1 80.51 *
maxb 0 80.11

cartoon 80.55

ref 1 80.53 *
ref 2 80.62 *
ref 5 80.75 *
ref 20 80.77 *

best setting 81.59


Good quality (and good speed) for SSIM
-rcmode 2pass -br 800000 -psy 2 -deblock 0

Best quality with SSIM
-qual extra -rcmode 2pass -br 800000 -psy 2 -deblock 0 -ref 5

Good quality (and good speed) for my eyes
-rcmode 2pass -br 800000 -psy 2 -deblock 4 -adaptdeblock

Best quality for my eyes
-qual extra -rcmode 2pass -br 800000 -psy 2 -deblock 4 -adaptdeblock -ref 5

Edit error: adapt 4 for my eyes

[virus]

Originally posted by Sagittaire

adapt -6 79.68
adapt -4 79.68
adapt -2 79.68

I wonder if this is related to the "different deblock strength, ~same file"-issue I signalled some posts ago. It was exactly in the range [-6, -2] too, and with -adaptdeblock enabled.

[babayaga]

Originally posted by Sagittaire
SSIM test: HPII 640*272 800 Kbps
...
best setting 81.59


Sometimes I love your figures :-))

If I recall correctly, the closest in your SSIM test was VP6.2 at something like 76. Am I wrong ?

[CruNcher]

The same happened to me, as reported some posts ago, and it looks to me a way to reach the final filesize, since it happened during static credits
I'd like to obtain an undersized file more than a beefed file


Exactly for such things i prayed to the developers to include a OSD in the beta decoder. I hope they didn´t forget that wish of me ;)

[Sagittaire]

Sometimes I love your figures :-))

If I recall correctly, the closest in your SSIM test was VP6.2 at something like 76. Am I wrong ?


perhabs, i don't remember if i use the same avs script ... but your MPEG4 AVC is very very powerfull ... ;-)

complete test in progress with Matrix reloaded:

- metric test
- blind test
- sample for demo

[bobololo]

Here is a little contribution from plonk420 :

http://nero.ateme.com/beta_encodes/cathedral-beta2-400extra-crop-avc.mp4

No you're not dreaming, it's only 400 kb/s :)

[bobololo]

Originally posted by Sagittaire
perhabs, i don't remember if i use the same avs script ... but your MPEG4 AVC is very very powerfull ... ;-)

complete test in progress with Matrix reloaded:

- metric test
- blind test
- sample for demo

You should wait for the beta 3, it's about to be ready.

[vio_man]

Originally posted by bobololo
Here is a little contribution from plonk420 :

http://nero.ateme.com/beta_encodes/cathedral-beta2-400extra-crop-avc.mp4

No you're not dreaming, it's only 400 kb/s :)

I would like to see this encode but I don't have Ateme's filters :( I'm a AVC enthusiastic :)

[LostMP4]

Originally posted by vio_man
I would like to see this encode but I don't have Ateme's filters :( I'm a AVC enthusiastic :)
Nero Showtime is the answer

[Sagittaire]

You should wait for the beta 3, it's about to be ready.

oky ... :D

improuvement for beta 3 ???

[bobololo]

Originally posted by Sagittaire
oky ... :D
improuvement for beta 3 ???

For the core encoder, we'll have :

- quite better bframes
- improved RC
- a few speed optimizations (sse2)

I think it should be ready by tomorrow evening.

[vio_man]

Originally posted by bobololo
Here is a little contribution from plonk420 :

http://nero.ateme.com/beta_encodes/cathedral-beta2-400extra-crop-avc.mp4

No you're not dreaming, it's only 400 kb/s :)

Wow :eek: I've just watched the video and I must say I'm really impressed by the quality at such bitrate :) I think AVC/H.264 will take over MPEG-4 ASP in time.

[Sagittaire]

Little HDTV demo:

Trailer HPIII 80 sec
Video 1280*720 16/9 1280 Kbps
Audio HE-AAC 5.1 128 Kbps

Trailer King Arthur 125 sec
Video 1280*720 2.35 2000 Kbps
Audio HE-AAC 5.1 200 Kbps

configuration Intel 2.4 Ghz or Athlon XP 2400+

[bobololo]

Originally posted by Sagittaire
Little HDTV demo:

Trailer HPIII 80 sec
Video 1280*720 16/9 1280 Kbps
Audio HE-ACC 5.1 128 Kbps

Trailer King Arthur 125 sec
Video 1280*720 2.35 2000 Kbps
Audio HE-ACC 5.1 200 Kbps

configuration Intel 2.4 Ghz or Athlon XP 2400+

Nice trailers. Which settings did you use ? In the HP3 clip, sometimes I find the background a little bit too blurred to my taste and I've the feeling it was caused by a strong deblocking. Is it possible to provide the source ?

It appears here that audio and video are not sync (and I don't think it was caused by slow decoding since my cpu is loaded at 60% only).

Also next time before posting some material from the beta, please ask if you can (I don't think there is any problem with your trailers). The same apply to your test you're publishing on your website. The reasons are quite simple, the current tested betas are not always revelant of the final release and we may prefer not to spread the beta encodes even they're already very good.

This point was clearly explicited in the terms of the test you accepted, so please make your best to respect them.

[Sagittaire]

This point was clearly explicited in the terms of the test you accepted, so please make your best to respect them.

yes ... i remember that ... for this reason trailer out (auto-censured) ... sorry


In the HP3 clip, sometimes I find the background a little bit too blurred to my taste and I've the feeling it was caused by a strong deblocking.

-qual extra -rcmode vbr -qp 30 -psy 2 -deblock 6 -adaptdeblock -ref 1

it's high quant and very high compression but very good quality for 1300 Kbps and 720p i think. Personaly i like high treshold for adapt deblock ( adapt in [2-6] interval) ...


Is it possible to provide the source. It appears here that audio and video are not sync (and I don't think it was caused by slow decoding since my cpu is loaded at 60% only).

It's video.ts 12 Mbps MPEG2 1080i capture from HDTV. Sync is difficult because delay correction (DVD2AVI done not correct ac3 delay for these source) ... the problem is not mp4 muxer ... ;-)

[Andrey]

Wow I've just watched the video and I must say I'm really impressed by the quality with such bitrate I think AVC/H.264 will take over MPEG-4 ASP in time.
On low bitrates - definitely. :)
Inloop filtering produce really unexpected (in good meaning) results.

Still can not do good medium-to-high bitrate (~1Mbit) encode - too blurry. Seems that deblocking must be disabled for such a bitrates...
Will check it...

[708145]

I found some time to conduct my first experiments and I found 2 things:

a) I cannot play my produced .mp4 files but can play the .mp4 files posted by others. Maybe this is due to not muxing audio to it? But shouldn't the video stream play on itself?

b) For several HDTV 720p clips the encoder is able to produce 1000kbit encodes (+++ hit the target size _very_ well +++) but not so for 600kbit. Is this a bug? It should at least produce something <1000kbit if it's not possible to hit 600kbit exactly.

--
J:\b2>encavc -i "bourne.avs" -o "bourne_600.mp4" -qual best -rcmode 2pass -br 600000 -psy 1 -adaptdeblock -ref 2
ENCAVC - Copyright (c) 2004 ATEME (http://www.ateme.com)

This software is an experimental MPEG-4 AVC / H.264 encoder. It is intended
for evaluation purpose only and redistribution is strictly PROHIBITED.

Resulting files generated by this software can be corrupted due to the
instability of the encoder. Please report back if it occurs.

Core encoder version 1.0.1.16

Input file : bourne.avs
Output file : bourne_600.mp4
Resolution : 1280x720 @ 25.00 fps
Length : 1813 Frames
Rate Control : 2pass
Target Bit Rate : 600 kb/s
Quality : Best
Init Quantiser : 24
Max Consecutive BFrames : 3
Deblocking Strength : -2 (adaptive)
Num Reference : 2
Psychovisual : 1
Cartoon mode : Off
Features : ipred ppred bpred cabac deblock hpel qpel part

-- Start processing pass 1 / 2
* 100.00% completed
* 1813 frames processed @ 1.51 fps
-- Start processing pass 2 / 2
* 01812: encoding @ 2.89 fps - bitrate 22.19 kb/s - 100.00% completed
* 1813 frames encoded @ 2.51 fps - average bitrate 14.86 kb/s

Encoding complete
--
fps are not valid since I was doing several (2-3) encodes at the same time.

This is on an AXP1800+/768MB-PC133/Win2kpro/radeon8500

bis besser,
Tobias

[Soulhunter]

Originally posted by 708145
...average bitrate 14.86 kb/s
Does your avs use DirectShowSource ???

When yes, try AviSource instead... ;)


Bye

[bobololo]

@SoulHunter: The problem (blocks) you reported at high bitrate should be fixed now, we have found some bugs that only occur at very low Qp (< 12) which should be your case.

@Cruncher: The transition issue you reported come from the source (snapshot from the vob file that comes with the DVD) :

http://nero.ateme.com/~tchi/t3_source.png.

[Soulhunter]

Originally posted by bobololo

@SoulHunter: The problem (blocks) you reported at high bitrate should be fixed now, we have found some bugs that only occur at very low Qp (< 12) which should be your case.

Nice, waiting for the new build... :)

Btw, some info about this other "bug" yet ???


Bye

[plonk420]

Originally posted by bobololo
Here is a little contribution from plonk420 :

http://nero.ateme.com/beta_encodes/cathedral-beta2-400extra-crop-avc.mp4

No you're not dreaming, it's only 400 kb/s :)

there was a bug (prolly the fault of the user :o ) where the incorrect framerate was used... should be 25ish... i'll reencode when the next beta comes out and hopefully we can replace this slightly embarassing file with the fixed one :eek:

[CruNcher]

@bobololo yes i apologize i was too fast with my asumption i rechecked and indeed it's allready in the source sorry for this :(

[bobololo]

After a week of intensive testing, we're happy to announce the release of the third beta package which is currently being uploaded to our public server. Testers' should receive the notification mail soon.

The changelog for this new version is the following :

- AviSynth DirectShowSource() issue fixed (adf_dech264.ax)
- Can't save graph in graphedit with source filter issue
fixed (adf_srcmp4.ax)
- Overwrite file issue fixed (mp4muxer.exe)
- New "-priority" option (encavc.exe)
- New "-maxqp" and "-minqp" options (encavc.exe)
- The extraction function could produce invalid mp4
(wrong config), it's fixed (mp4tb.exe)
- xmlparse.dll and xmltok.dll now compiled in release
- Misc bugfixes in the core encoder (encavc.exe)
- Improved bframes support (encavc.exe)
- Add AR support in the decoder filter (adf_dech264.ax)

As you can see, a bunch of bugs were fixed again thanks to your helpful reports and now the encoder is more stable than ever :)

Beside, with more than 300 posts and 12000 views in only 7 days, this feedback thread has completely exploded :) We couldn't imagine how popular this test could be ! In order to avoid your feedback to be completely overflooded, I created a new thread (http://forum.doom9.org/showthread.php?s=&threadid=82036) dedicated to quality feedback only while this one will be dedicated to bug, issues and help for starters. If a moderator is reading this, it would be really appreciated if he could rename this thread into something like "Ateme H.264 Beta - Bug, Issues and Getting Started" :)

This will hopefuly make the progress of this beta test more convenient for all !

Thanks again to all testers, your contribution is greatly welcomed.

-- bobololo.

[LostMP4]

Can I have details on the -priority option, please?
Which values are available?

[bobololo]

Originally posted by LostMP4
Can I have details on the -priority option, please?
Which values are available?

*Damned* I missed this option in the doc ...

-priority <below|above|high|idle|realtime|normal>

[LostMP4]

Originally posted by bobololo
*Damned* I missed this option in the doc ...

-priority <below|above|high|idle|realtime|normal>

You must be bugged ;)

Ok, for beta-3 this useful option is available, too:

-priority <idle|below|normal|above|high|realtime>

[virus]

ok, I've given the devs one more chance installing and testing the beta-3 filters, which don't work as always.

Now, I just want to let you know that I'm quitting the test.
I'm tired of asking (and offering help to fix the bugs) and be ignored, tired of fighting against the windmills alone, and I sincerely regret all the time I've wasted overnight to prepare some material, take PSNR figures, and so on even if I'm in a very busy period. My spare time, used for free, think about it dear Ateme devs, when you'll receive your salary at the end of the month...

I think I deserved something a bit different for my efforts, but hey, when it comes down to business you know how it's going to be... well, not a problem, 29 or 30 testers doesn't make any difference. I will continue read on your feedback guys, so please continue outputting numbers and opinions, I'm still interested in them.

have fun :)
virus

[bond]

Originally posted by bobololo
If a moderator is reading this, it would be really appreciated if he could rename this thread into something like "Ateme H.264 Beta - Bug, Issues and Getting Started"you wish we play, btw you can change the thread title by yourself too if you simply edit the title of your first post in this thread :)

[bobololo]

Originally posted by virus
ok, I've given the devs one more chance installing and testing the beta-3 filters, which don't work as always.

Now, I just want to let you know that I'm quitting the test.
I'm tired of asking (and offering help to fix the bugs) and be ignored, tired of fighting against the windmills alone, and I sincerely regret all the time I've wasted overnight to prepare some material, take PSNR figures, and so on even if I'm in a very busy period. My spare time, used for free, think about it dear Ateme devs, when you'll receive your salary at the end of the month...

I think I deserved something a bit different for my efforts, but hey, when it comes down to business you know how it's going to be... well, not a problem, 29 or 30 testers doesn't make any difference. I will continue read on your feedback guys, so please continue outputting numbers and opinions, I'm still interested in them.

have fun :)
virus

Well, I understand your disapointment and I'm sorry about it, but also consider what you were asking to us. Win9x support would involve our staff to setup a new PC, install the OS & drivers, all the development environment (just figure out how huge it is ...). And only then start investigating the issue. And all this for only 1 tester. Now imagine each tester has similar request, then I think we'd never be able to get our focus on the main topic of this test and the encoder would never be released ;)

Please keep in mind that we're not Microsoft nor Ahead. We're just compression codecs designers. Our expertise is to squeeze video data as much as possible and even we're learning and trying to do so, it is not to write software that works on every platform/os existing on this world (imagine one moment, that a single tester requests for BeOS support, what should we do then ?) ;)

BTW what's wrong with ShowTime filters ? Couldn't you continue to use them ?

[virus]

Originally posted by bobololo
BTW what's wrong with ShowTime filters ? Couldn't you continue to use them ? I can't seek nor use AVISynth. Ever tried to do an in-motion clip comparison without seeking capabilities? Or maybe compare two frames from two different encavc encodes side by side? Try without using seeking nor StackVertical() and then you can see.

Anyway, I can understand your point. But I also want to remind you that you never specified "Win2k/XP only" in your call for testers. Nor you said that 2k/XP was required at any point of this thread. Why fool me?

BTW I've already offered (4 days ago) to check the register and all the stuff you need on my own PC. And you didn't ever care to answer, as you do for the other stuff (the issue with the deblocker - thank God Sagittaire posted an answer to that some hours ago)

You know, when someone is unwanted it's better to ignore him. This I find disrespectful. Anyway, I don't care. One less tester, one less bug to resolve. Easy and simple, uh?

(ah, and even the XviD team is made up of "just compression codecs designers" who work on their spare time but their filters work flawlessly here... so I don't think I'm making such a huge request)

virus

[JohnV]

Originally posted by virus
I can't seek nor use AVISynth. Ever tried to do an in-motion clip comparison without seeking capabilities? Or maybe compare two frames from two different encavc encodes side by side? Try without using seeking nor StackVertical() and then you can see.

Anyway, I can understand your point. But I also want to remind you that you never specified "Win2k/XP only" in your call for testers. Nor you said that 2k/XP was required at any point of this thread. Why fool me?

BTW I've already offered (4 days ago) to check the register and all the stuff you need on my own PC. And you didn't ever care to answer, as you do for the other stuff (the issue with the deblocker - thank God Sagittaire posted an answer to that some hours ago)

You know, when someone is unwanted it's better to ignore him. This I find disrespectful. Anyway, I don't care. One less tester, one less bug to resolve. Easy and simple, uh?

(ah, and even the XviD team is made up of "just compression codecs designers" who work on their spare time but their filters work flawlessly here... so I don't think I'm making such a huge request)

virus For Pete's sake... At this stage it's much more important to optimize the quality than start spending lots of beta tuning time to fix some Win9x compatibility issues which affect 0.00001% of users.
I'm sure Win9X compatibility comes when it's the time, but considering how small minority this user group is, I totally understand that quality issue feedback/tuning gets much higher priority from Ateme at this point of the beta-test.

[acidsex]

For some odd reason, I never received the Beta-3 email. Dont know if it had to do with the hurricane we went through this past weekend but if bobololo could please send it to me, it would be greatly appreciated.

[virus]

Originally posted by JohnV
At this stage it's much more important to optimize the quality than start spending lots of beta tuning time to fix some Win9x compatibility issues which affect 0.00001% of users.
It's 10%, not 0.00001% :)
(I gave a link to an article about that in this very thread)

I want to remind you that Ahead (as Micro$oft) still supports Win98, 98SE, ME. And I also want to remind you that without my help, Ateme would have sold to Ahead a codec that wouldn't work at all on half of their supported platforms, since encavc-beta1 was b0rked on Win9x. I think that I deserved a different treatment for doing that... just make things clear, without making me waste time on this stuff, would have been much appreciated ;)

Anyway, it's all the same story. Why support that exotic Linux OS if everyone on Earth uses Windows? Why care about compatibility with Firefox if everyone uses IE? Why support that strange XviD-thingie when everybody in the world is happy with DivX? It's all the same. Business and software diversity are such different concepts... ;)

(and it's easy to make comments like yours when you're on the winning side. much less when you're in the minority)

virus

EDIT:
I'm sure Win9X compatibility comes when it's the time
please read again bobololo's statements... win9x compatibility will never come.

[JohnV]

Originally posted by virus


EDIT:

please read again bobololo's statements... win9x compatibility will never come. Eh.. Nero Digital uses Ahead's inhouse h.264 decoder anyway, not Ateme's decoder. So maybe complete win9x support won't come for this Ateme beta-test, but ShowTime works with Win9x, doesn't it? Furthermore according to my knowledge at least the h.264 seeking issue should be fixed in the next NVE update package.

[virus]

Originally posted by JohnV
Furthermore according to my knowledge at least the h.264 seeking issue should be fixed in the next NVE update package.
Good. (not that I need it anymore :D)
Anyway I'm not asking Ateme to support anything. But they should have simply said "dear virus, you cannot partecipate in this test with your OS, sorry, please don't waste time on it". Instead, they choose not to talk and ignore me. Had I not spoken out tonight, no more words would have been spent on the whole issue. That's disrespectful. (and I even offered to debug everything on my machine! :rolleyes: )

Ateme is free to do what they want. I'm just asking for a bit of respect for my (free) efforts ;)

virus

[everwicked]

Hi,

I don't speak for bobololo, nor I am trying to defend him but I have experienced similar problems since I have started developing for windows so I might be able to explain a few things.

Originally posted by virus
I can't seek nor use AVISynth. Ever tried to do an in-motion clip comparison without seeking capabilities? Or maybe compare two frames from two different encavc encodes side by side? Try without using seeking nor StackVertical() and then you can see.


Quite a few people like StackVertical(). I myself feel that is not used as it should. What i mean is, that you shouldn't be looking for differences, frame by frame. If you let the video play and get a generic impression then go ahead.

There are also two more things you can do:
1) Use VQStudio
2) Use GraphEdit to export the mp4 file to another, lossless or uncompressed AVI. You can then do whatever you need with it, including seeking.


Anyway, I can understand your point. But I also want to remind you that you never specified "Win2k/XP only" in your call for testers. Nor you said that 2k/XP was required at any point of this thread. Why fool me?


I am quite certain they did not know it wouldn't work on win9x. Noone was trying to fool you. That is clear, to me at least. You were just unlucky to find out in practice.


BTW I've already offered (4 days ago) to check the register and all the stuff you need on my own PC. And you didn't ever care to answer, as you do for the other stuff (the issue with the deblocker - thank God Sagittaire posted an answer to that some hours ago)


Unfortunately, it doesn't have to do with your PC at all. The state of your installation is unrelated to these issues which are clearly related to advancements not evident in Win9x. I don't know what it is, but it can be anything, varying from Unicode to threading. If you don't believe me, you can browse through msdn.microsoft.com. Check at the bottom and see that a lot of functions are not supported by Win9x.


(ah, and even the XviD team is made up of "just compression codecs designers" who work on their spare time but their filters work flawlessly here... so I don't think I'm making such a huge request)

The XviD team has quite a few people and it has some basic differences with ateme:
1) they "ship" a complete product
2) because of 1, they also have mechanisms to ensure portability.
Something that noone has pointed out is that Ateme does NOT sell a standalone encoder but rather an encoding library.


I want to remind you that Ahead (as Micro$oft) still supports Win98, 98SE, ME. And I also want to remind you that without my help, Ateme would have sold to Ahead a codec that wouldn't work at all on half of their supported platforms, since encavc-beta1 was b0rked on Win9x. I think that I deserved a different treatment for doing that... just make things clear, without making me waste time on this stuff, would have been much appreciated


As I said above, they only sell the library to ahead, not the interface. And as bobololo himself said, the core is cross-platform.


Anyway, it's all the same story. Why support that exotic Linux OS if everyone on Earth uses Windows? Why care about compatibility with Firefox if everyone uses IE? Why support that strange XviD-thingie when everybody in the world is happy with DivX? It's all the same. Business and software diversity are such different concepts...


Aside from the ateme issue, my personal opinion is that if you want to support multiple platforms then you're limited to Java or .NET if only linux/windows is target. Then you lose speed assuming it's video processing we're talking about. Let alone how many people moan about the required runtime.

If you keep the speed and work with C/C++, then let's face it. Developers will spend more time testing and adding work-arounds for broken stuff in obsolete OS's. Time that they could have used to introduce new features. In that way, the minority is hurting the majority, not themselves.


please read again bobololo's statements... win9x compatibility will never come.


It will come. Just not with Ateme's encoder/filters. Once again, someone from Ateme pointed out that they are used for in-house development. Too bad it didnt work for win9x users for this test. However, when Ahead gets it and the new Nero is out, it will support your beloved OS.

Just my 0.02 &euro;

[superdump]

virus: The AVC binary doesn't work on your Win9x machine, right? Waaaay back when you first mentioned this bobololo stated that that's an issue with their tools (i.e. encavc) NOT WITH THE CODEC ITSELF. So just sit back and wait until it's released in Nero then try it again. If it's a quick fix they'd have done it already and as you're the only tester complaining about Windows 9x incompatibility I assume everyone else running the test executable is doing fine. As far as I'm concerned that's not bad going at all really. It's not viable to spend a lot of time fixing Win9x compatibility for a couple of week long beta test. Quality development, as stated, is more important as the other 49/50 beta testers are concerned with this, as are the codec developers. Ahead can fix Win9x compatibility as that will be part of their goal, not necessarily Ateme's.

Have a nice day.

[virus]

Originally posted by superdump
virus: The AVC binary doesn't work on your Win9x machine, right? Waaaay back when you first mentioned this bobololo stated that that's an issue with their tools (i.e. encavc) NOT WITH THE CODEC ITSELF. the codec (encavc.exe, not the filters) was b0rked in beta-1 under Win9x. I resolved the issue with bobololo by email so you probably don't know about it. And again: saying "sorry you cannot test with your OS" at *that* time (and not now) would have been better. The point is that nobody ever cared to say that.

BTW It's also not viable to spend a lot of time to prepare a lot of stuff for a beta-test and not having someone warn you "hey, you're doing useless work, we're not going to support your OS right now". Can you see my point?

[plonk420]

*groans*
just update your os already, if just for the codec test...! >:| after it's done, go back to your favored 98 or whatever... i upgraded XP (from 2000) just for a LAN party and haven't been (or looked) back since

[virus]

Originally posted by everwicked
2) Use GraphEdit to export the mp4 file to another, lossless or uncompressed AVI. You can then do whatever you need with it, including seeking.As I already pointed out a couple of times before, GraphEdit won't render the graph, nor let me build it manually... ;)

I am quite certain they did not know it wouldn't work on win9x. Noone was trying to fool you. That is clear, to me at least. I disagree. bobololo stopped talking to me right after he was sure that encavc worked under my OS, because Ateme needed that (encavc is meant to be cross-platform). You can re-read the thread if you want. He answered all the questions except mines, and commented all the results except mines. He didn't ever care to state *clearly* something like "sorry, we're not going to support your OS". That would have been sufficient for me. Instead, he chose to ignore me.
Is this a correct, polite behaviour? Especially considering that I've tried to be helpful?

[JohnV]

For Pete's sake stop the crying already. :rolleyes:

Lets all praise virus from the behalf of all the two Doom9 members using Win9x and behalf of the other Win9x users out there. It's time for this thread to go back on topic instead of whining about what someone should or shouldn't have said.

[Bulletproof]

I seem to have a video that I encoded that refuses to play using the latest beta, when trying to open it in WMP it just freezes up. If I use the default encoding settings it decodes just fine but when I use this:

encavc.exe -i test.avs -o test.mp4 -qual extra -cartoon -rcmode 2pass -br 1000000

It freezes up in WMP.

[bobololo]

Originally posted by Bulletproof
I seem to have a video that I encoded that refuses to play using the latest beta, when trying to open it in WMP it just freezes up. If I use the default encoding settings it decodes just fine but when I use this:

encavc.exe -i test.avs -o test.mp4 -qual extra -cartoon -rcmode 2pass -br 1000000

It freezes up in WMP.

Can you upload the file ? Thanks.

edit:

Originally posted by virus
I disagree. bobololo stopped talking to me right after he was sure that encavc worked under my OS, because Ateme needed that (encavc is meant to be cross-platform). You can re-read the thread if you want. He answered all the questions except mines, and commented all the results except mines. He didn't ever care to state *clearly* something like "sorry, we're not going to support your OS". That would have been sufficient for me. Instead, he chose to ignore me.
Is this a correct, polite behaviour? Especially considering that I've tried to be helpful?

Ok this will be my last post here about this subject, if you can't understand my point, it's useless to continue this low discussion.

1. The fix we did with encavc.exe was related to the system call CreateThread() which has a different behaviour between win9x and win2k/xp. This function is use to create the thread that read the input source and has nothing to do with the core encoder. We didn't change even 1 line of code in the core encoder to fix this issue.

2. You reported that changing the deblocking filter settings, there were few changes in your clip. I didn't answer you because if you read all the posts before, it clearly appeared that changing deblocking filters settings does something. Plus you didn't tell which bitrate you were using, it was obvious that if you encoded at high bitrate the deblocking doesn't do anything since there is no blocks !

3. I didn't either reply to some questions posted when I considered my answer wouldn't have much interest.

I now hope you can stand back and see the reality of the facts which is quite different from your whacky interpretation. In no way we tried to exploit you in order to make our codec works with win9x (once again the core encoder is completely OS independant) and ignored you just after. I simply can't believe how you can imagine such things, this is hallucinating !

This discussion is closed for me, I won't reply anymore on this topic.

-- bobololo.

[708145]

Originally posted by plonk420
*groans*
just update your os already, if just for the codec test...! >:| after it's done, go back to your favored 98 or whatever... i upgraded XP (from 2000) just for a LAN party and haven't been (or looked) back since

XPpro is 180€! I wouldn't do that just for a codec test. Don't know about prices in italy, though.

But now let's stop this allright?

/me on Win2kpro

bis besser,
Tobias

[plonk420]

now if only i could figure out why my video is dropping frames even tho it looks perfect in Vdub... :(

edit: FINALLY figured out where the problem is..! when i frame by frame my AVISynth script in vdub all is well. however, when VDub saves the AVI (or when EncAVC encodes from the AVS script) something gets skewed and the duplicated frame gets kept and some other frame gets dropped...! :angry: w...t...f...?!?

MPEG2Source("cathedral.d2v").BiCubicResize(640,480).crop(0,64,0,-64).SelectEvery(6,0,1,2,3,4).AssumeFPS(25)

(it makes no difference if the AssumeFPS is there or not)

[Manao]

What dll are you using for decoding mpeg2 ? MPEG2DEC3 ? dgdecode ?

With DVD2AVi / MPEG2DEC3, there was sometimes some frames missing. With DGdecode ( and DGindex ), you shouldn't have this issue anymore. Perhaps it will solve your problem.

Also, perhaps the frame you need to drop isn't always the 6th of each sycle of 6 frames. You should try decimate ( from the decomb package ), it may solve your issue.

Finally, if nothing works, try to cut a small part of your vob and make it available, some gurus on the avisynth forum will surely find what is wrong with it.

[avih]

Originally posted by JohnV
For Pete's sake stop the crying already. :rolleyes:

Lets all praise virus from the behalf of all the two Doom9 members using Win9x and behalf of the other Win9x users out there. It's time for this thread to go back on topic instead of whining about what someone should or shouldn't have said.

Take it easy JohnV, and please try to stay polite.

avih.

[Sagittaire]

I seem to have a video that I encoded that refuses to play using the latest beta, when trying to open it in WMP it just freezes up. If I use the default encoding settings it decodes just fine but when I use this:

encavc.exe -i test.avs -o test.mp4 -qual extra -cartoon -rcmode 2pass -br 1000000

It freezes up in WMP.


1)For me don't work with WMP10 or QTP but work perfectly with MPC: after test only default renderer works with MPC. WMR7 and WMR9 with windowed or renderless doesn't work ...


2) this avs script works
video=DirectShowSource("G:\H264-500.mp4",fps=25)
video=trim(video,0,35237)
return video

but not this script (VD or VDM bug)
video=DirectShowSource("G:\H264-500.mp4",fps=25)
return video


3) Directshow with H264 consumes RAM enormously. The RAM is not reloaded when I open several avs consecutively: I must open and close VD to avoid depassement of virtual memory.

but it isn't important for me: it's beta test on quality. These problem are decodeur problem exclusively and will be solved later.

[virus]

Originally posted by bobololo
... and ignored you just after. I simply can't believe how you can imagine such things, this is hallucinating !

Yeah, how can I imagine such things? Well...

Originally posted by bobololo on 4th September 2004 00:17
We're doing our best to try to make them work on your plateform as it was previously done following your report on encavc.

These were the last words you've addressed to me (before I spoke out a few hours ago). You didn't even care to answer "we cannot make it to work, sorry". You didn't even care to say a single word, either accepting or rejecting my offer to debug your filters on my PC.
You can be one of the best coders in the world but still I don't think you have the right to jerk me around.

This is my point. Sorry for any further incomprehension, anyway.

Discussion closed for me, too

cheers :)
virus

[avih]

Originally posted by virus

.....

Discussion closed for me, too

cheers :)
virus

thank you :)

[plonk420]

Originally posted by Manao
What dll are you using for decoding mpeg2 ? MPEG2DEC3 ? dgdecode ?

With DVD2AVi / MPEG2DEC3, there was sometimes some frames missing. With DGdecode ( and DGindex ), you shouldn't have this issue anymore. Perhaps it will solve your problem.

Also, perhaps the frame you need to drop isn't always the 6th of each sycle of 6 frames. You should try decimate ( from the decomb package ), it may solve your issue.

yep, using DVD2AVI / MPEG2DEC3; however, it displays 100% correctly when i advance frame-by-frame in VDub. when i Save As AVI or run the AVS file thru the encoder, THAT is when it messes up... :(

[LostMP4]

H.264 quantizer question..
If I remember correctly, increasing the quantizer by 6 should half the filesize... right :confused:
If that's right increasing the quantizer by 12 should reduce the filesize to a quarter

I made two test vbr encodes, with 21 (min and max) and 33 (min and max) quantizer but the first file it's about 6 times larger than second (1015 MB and 170 MB)

So, something is wrong (my memory, something related to my setting or maybe the codec?)

Core encoder version 1.0.1.19

Resolution : 720x576 @ 25.00 fps
Length : 72840 Frames
Process Priority : Below
Rate Control : Vbr
Quality : Extra
Init Quantiser : 21 [21 - 21]
Max Consecutive BFrames : 3
Deblocking Strength : 0 (adaptive)
Num Reference : 5
Psychovisual : 2
Cartoon mode : On
Features : ipred ppred bpred cabac deblock hpel qpel part

-- Start processing pass 1 / 1
* 72839: encoding @ 12.20 fps - bitrate 352.48 kb/s - 100.00% completed
* 72840 frames encoded @ 2.66 fps - average bitrate 2919.37 kb/s

Encoding complete

Core encoder version 1.0.1.19

Resolution : 720x576 @ 25.00 fps
Length : 72840 Frames
Process Priority : Below
Rate Control : Vbr
Quality : Extra
Init Quantiser : 33 [33 - 33]
Max Consecutive BFrames : 3
Deblocking Strength : 0 (adaptive)
Num Reference : 5
Psychovisual : 2
Cartoon mode : On
Features : ipred ppred bpred cabac deblock hpel qpel part

-- Start processing pass 1 / 1
* 72839: encoding @ 11.20 fps - bitrate 29.63 kb/s - 100.00% completed
* 72840 frames encoded @ 4.48 fps - average bitrate 488.87 kb/s

Encoding complete

[superdump]

Originally posted by LostMP4
H.264 quantizer question..
If I remember correctly, increasing the quantizer by 6 should half the filesize... right :confused:
If that's right increasing the quantizer by 12 should reduce the filesize to a quarter

I made two test vbr encodes, with 21 (min and max) and 33 (min and max) quantizer but the first file it's about 6 times larger than second (1015 MB and 170 MB)

So, something is wrong (my memory, something related to my setting or maybe the codec?)I think bobololo said that the filesize is 'nervous' using constant quantiser mode. I don't know if increasing qp by 6 is intended to halve the filesize but even if it is it won't do that in every case, depends on the source.

[bobololo]

Originally posted by LostMP4
H.264 quantizer question..
If I remember correctly, increasing the quantizer by 6 should half the filesize... right :confused:
If that's right increasing the quantizer by 12 should reduce the filesize to a quarter

I made two test vbr encodes, with 21 (min and max) and 33 (min and max) quantizer but the first file it's about 6 times larger than second (1015 MB and 170 MB)

So, something is wrong (my memory, something related to my setting or maybe the codec?)

The bitrate variation versus quantizer is absolutely not linear. If it was the case, the RC would be quite easier ;)

[LigH]

You might be interested in calculating the "bits per pixel and frame" value, as GordianKnot is calculating, for example. For DivX 5 or XviD-H.263, we usually recommend 0.25-0.30 bppf; for XviD-MPEG, we recommend 0.30-0.35 bppf. I wonder which minimum you would recommend for Ateme H.264?!

At first I'll try to upload a zipped Excel sheet here (I wonder if I'm allowed to upload - if so, it may appear soon here). Also I made a Windows EXE, but it is a but huge (due to using Delphi): ~185 KB.

[Soulhunter]

Nice, all problems with the T3 trailer are gone with the new beta... :)


Bye

[ac-chan123]

I have testet the mp4 files from this treat with the new IIS Frauenhofer mp4 Player (http://www.iis.fraunhofer.de/pub_rel/presse/2004/mpeg4/index.html). None of them are played. The Player says profile unkow.

[SeeMoreDigital]

Originally posted by ac-chan123
I have testet the mp4 files from this treat with the new IIS Frauenhofer mp4 Player (http://www.iis.fraunhofer.de/pub_rel/presse/2004/mpeg4/index.html). None of them are played. The Player says profile unkow. Can you upload a short sample?


Cheers

[LostMP4]

Originally posted by ac-chan123
I have testet the mp4 files from this treat with the new IIS Frauenhofer mp4 Player (http://www.iis.fraunhofer.de/pub_rel/presse/2004/mpeg4/index.html). None of them are played. The Player says profile unkow.
Tested my encodes, same error (AVC profile unknow)
maybe profiles aren't implemented yet...

[Bulletproof]

Originally posted by bobololo
Can you upload the file ? Thanks.


I have uploaded the file on the ftp in the incoming dir.

[bond]

Originally posted by LostMP4
maybe profiles aren't implemented yet...hm maybe the ateme encoder doesnt indicate the used profile in the .mp4 file, but the frauenhofer player needs it (might only play baseline profile streams and not main profile ones), but thats only speculation

[bobololo]

Originally posted by bond
hm maybe the ateme encoder doesnt indicate the used profile in the .mp4 file, but the frauenhofer player needs it (might only play baseline profile streams and not main profile ones), but thats only speculation

It seems that fraunhofer doesn't support main profile...

edit: FYI, streams encoded with our beta use main profile (77) and level 4.0 (40).

[bobololo]

Originally posted by Bulletproof
I seem to have a video that I encoded that refuses to play using the latest beta, when trying to open it in WMP it just freezes up. If I use the default encoding settings it decodes just fine but when I use this:

encavc.exe -i test.avs -o test.mp4 -qual extra -cartoon -rcmode 2pass -br 1000000

It freezes up in WMP.

Ok I got your file and tried to play it with mpc and wmp9 and both worked fine. Only I couldn't seek in wmp9. Which version of wmp do you use ? Does is work with other player ? Have you updated your filters with those provided in beta 3 ?

I'll try tomorrow on other PCs with different version of wmp if possible.

[Bulletproof]

I think my decoding filters were screwed up, I used unreg and reg again and it's playing fine now in WMP 6.4, thanks.

[LostMP4]

Originally posted by bobololo
streams encoded with our beta use main profile (77) and level 4.0 (40).

Will you support extended profile?

[bobololo]

Originally posted by LostMP4
Will you support extended profile?

Hum I don't think so, however FRExt tools are much more interesting :)

[Tommy Carrot]

Originally posted by bobololo
Hum I don't think so, however FRExt tools are much more interesting :)

Could anyone tell me what tools does FRExt/high profile have other than the additional colorspaces? I did a search, but everything i could find was a bunch of japanese pages, and press releases.

[bobololo]

Originally posted by Tommy Carrot
Could anyone tell me what tools does FRExt/high profile have other than the additional colorspaces? I did a search, but everything i could find was a bunch of japanese pages, and press releases.

The draft amendement is available on the jvt public ftp directory (ftp.imtc-files.org/jvt-experts). Check in the 2004/07 event at Redmond. If i remember correct, the draft is JVT-L049.doc. I'd like to check but it seems their ftp server is down now.

[Tommy Carrot]

Thx, i'll check later when the ftp is back. :)

[ac-chan123]

http://bs.hhi.de/~wiegand/JVT.html
There is the final draft.

[superdump]

Originally posted by LigH
You might be interested in calculating the "bits per pixel and frame" value, as GordianKnot is calculating, for example. For DivX 5 or XviD-H.263, we usually recommend 0.25-0.30 bppf; for XviD-MPEG, we recommend 0.30-0.35 bppf. I wonder which minimum you would recommend for Ateme H.264?!Whaaaat?! I would say anything in the 0.15-0.20 range is good for most things. Maybe my aims are somewhat different to yours. I'm a 1CD kinda guy if possible, but any outputs I get certainly don't look bad. Looks like you're more interested in 1/3 of a DVD or 2 CDs. Still, 0.25 as a minimum is not right in my opinion. 0.15 maybe.

[thegeby]

You might be interested in calculating the "bits per pixel and frame" value, as GordianKnot is calculating, for example. For DivX 5 or XviD-H.263, we usually recommend 0.25-0.30 bppf; for XviD-MPEG, we recommend 0.30-0.35 bppf. I wonder which minimum you would recommend for Ateme H.264?!

Such a comparison would not be very useful between codecs. The whole point of a "more efficient" codec is to achieve a lower b/pf than the competition at the same quality. It could be useful, however in discussing quality settings within a codec, i.e. "at what level is individual x happy?"

[bobololo]

Originally posted by ac-chan123
http://bs.hhi.de/~wiegand/JVT.html
There is the final draft.

I assume the final draft you're considering is JVT-G050 ? In such case, this draft doesn't include Fidelity Range Extension.

Ok now that the server is back, here is the link to the FRExt latest draft :

ftp://ftp.imtc-files.org/jvt-experts/2004_07_Redmond/JVT-L047d9.zip

edit: Huhu my first posted url was wrong ;)

[Andrey]

First of all - conglaturations, beta 3 filters now allow me to save screenshot in mpc easily. Bingo, thanks :)
Still, they do not show right AR. I definded it as 235:100 - should it work ? Or I need to reencode ?
BTW, I've managed to create Equilibrium encode very close to xvid one.
See two examples here:
http://sirgrey.nm.ru/XViD.png
http://sirgrey.nm.ru/h264.png

[Tommy Carrot]

Originally posted by bobololo
I assume the final draft you're considering is JVT-G050 ? In such case, this draft doesn't include Fidelity Range Extension.

Ok now that the server is back, here is the link to the FRExt latest draft :

ftp://ftp.imtc-files.org/jvt-experts/2004_07_Redmond/JVT-L047d9.zip

edit: Huhu my first posted url was wrong ;)
Thanks again. :)

[bobololo]

Originally posted by Andrey
First of all - conglaturations, beta 3 filters now allow me to save screenshot in mpc easily. Bingo, thanks :)
Still, they do not show right AR. I definded it as 235:100 - should it work ? Or I need to reencode ?


The -par option allows you to set the pixel AR and not the display AR.

[bill_baroud]

hello, sorry to have still reported nothing but life catch me up (3 days searching for a new flat 800km from here etc ...) but i started to wrote a little gui to make my test easier ...
well it's not working atm, but if some guys are interested it looks like this atm
> http://moodub.free.fr/h264gui.gif

[Andrey]

The -par option allows you to set the pixel AR and not the display AR.
Oh. Ok :)
Always was confused with that pixel/picture AR difference...
Thanks for the info!

[Soulhunter]

Originally posted by Andrey

Always was confused with that pixel/picture AR difference...


Hint: Some nice info about this @ the homepage of SeeMoreDigital... ;)


Bye

[LigH]

Originally posted by thegeby
Such a comparison would not be very useful between codecs...
Is that the reason why attachments don't get released here? :rolleyes: (May I have to report that answer to have one released?)
__

Indeed, the personal range of acceptable quality would be very individual.

You might tell people: "At #.## bppf, most of my used material achieved a SSIM value better than ##". Would that be more objective?

Well - it was just an idea. Some people may like it, some find a drawback to criticize (BTW, that's fine for me).

[plonk420]

Originally posted by plonk420
yep, using DVD2AVI / MPEG2DEC3; however, it displays 100% correctly when i advance frame-by-frame in VDub. when i Save As AVI or run the AVS file thru the encoder, THAT is when it messes up... :(

oh my .. i've been overlooking DGMPEGDec all this time... :eek:

[IgorC]

If anyone have link fot Ateme Codec or ANY idea from where i can download it . Pliz send me email igoruso@msn.com

[plonk420]

Originally posted by IgorC
If anyone have link fot Ateme Codec or ANY idea from where i can download it . Pliz send me email igoruso@msn.com

sorry, you had to apply to betatest if you read the original post. that and there were only so many accepted (not sure how many or the criterea, if there was any). and if you're trying to finagle the encoder out of somebody, please don't. that's against some boards' rules, if not a warnable or even bannable offense.

based on your previous posts, i'd suggest reading FAQs/Stickies for whatever forum you're posting to. google [the technology] and FAQ (ie, rv10 faq ... or abx faq .. or lame faq). use the search command on webboards.

few people have the patience to research for you and email you what to do. webboards are there so that 1 post can be read by many in the same boat and if there's helpful replies, then you can kill multiple birds with one stone.

rules of thumb:
1. search
2. google
3. lurk and learn (see my post just above; i just now learned about DGDecode/DGIndex [previously DVD2AVI], and i hope i did so without annoying too many regulars or whoever found it to be such a stupid-seeming oversight)
4. don't act outside of webboard ettiquite: in this case, don't ask for betas unless it's the norm for the board (like a warez trading board, which this is obviously and definitely NOT). go back and read the Forum Rules: http://forum.doom9.org/forum-rules.htm

if you follow the rules, you'll be welcome at this awesome board; if not, well, you sure won't be posting here much longer...

[CruNcher]

Bobololo can you confirm that the Deadline now is 3 weeks ?
mentioned by Ahead on the IBC so with Nero 6.6 there will be AVC introduced in Recode 2 ?

[aketon]

Originally posted by CruNcher
Bobololo can you confirm that the Deadline now is 3 weeks ?
mentioned by Ahead on the IBC so with Nero 6.6 there will be AVC introduced in Recode 2 ?

Does anybody know how much this codec is going to cost???:)
I hope that ahead is not going to follow the Videosoftinc way! They sell their codec for 99$!!!:confused:

[Latexxx]

Originally posted by aketon
Does anybody know how much this codec is going to cost???:)
I hope that ahead is not going to follow the Videosoftinc way! They sell their codec for 99$!!!:confused:
I believe that this codec will be part of the Nero package which already includes mpeg 4 asp codec.

[bobololo]

Originally posted by CruNcher
Bobololo can you confirm that the Deadline now is 3 weeks ?
mentioned by Ahead on the IBC so with Nero 6.6 there will be AVC introduced in Recode 2 ?

I also heard about this but I can't really confirm, the release plan about AVC in Recode may evolve but not sure.

[easyfab]

bobololo,

Don't know if it is the right place but I have a question about avc and ateme. Not software but hardware question. I see on ateme pages that you have hardware solutions for avc decoding and encoding.
Will it give in (near) futur a standalone avc player? encoder ?

[bobololo]

Originally posted by easyfab
bobololo,

Don't know if it is the right place but I have a question about avc and ateme. Not software but hardware question. I see on ateme pages that you have hardware solutions for avc decoding and encoding.
Will it give in (near) futur a standalone avc player? encoder ?

We're offering a reference design of a platform that could address various products : ip set top box, dvd player, PVR, etc. Now it's up to OEM to adopt the reference design and to build a nice products based on it. Unfortunately this process is always very long. Btw while dealing with standalone players, accoding to some rumours ;) we may be able to see the first NeroDigital certified (MPEG-4 ASP) standalones by the end of the year.

[thegeby]

accoding to some rumours we may be able to see the first NeroDigital certified (MPEG-4 ASP) standalones by the end of the year

Well, considering that the required chip has been listed in the Sigma product line for several months now, the rumours might be true:scared:

[LigH]

Somewhere in my processing, there appears to be a 1 frame shift!
Used QuickTime 6.51 and QuickTime Alternative (mainly, its DirectShow filter) to get the video content of the Matrix trailers, e.g.

Matrix_Reloaded_Trailer_Ultra_MOV.avsDirectShowSource("trailer_final_1000_dl.mov",fps=24)
ConvertToYV12(interlaced=false)

Wrote its result into an AVI using a losslessly compressing codec (ffdshow's HuffYUV, YV12 variant, Median prediction)

Put this AVS into the encavc Encoder (beta 3) to get a Matrix_Reloaded_Trailer_Ultra.mp4 (bitrate: 1300 kbps, 0.100 bppf)

Used a similar script to get its content and save that into a losslessly compressed AVI (I had to use AVS2AVI; VirtualDubMod froze here!)

Matrix_Reloaded_Trailer_Ultra_MP4.avsDirectShowSource("Matrix_Reloaded_Trailer_Ultra.mp4",fps=24)
This worked well after setting Ateme's filters' merits a little above "normal".

Wanted to compare both lossless AVIs using this very complicated script:

MRel_Diff.avsmov = AviSource("Matrix_Reloaded_Trailer_Ultra_MOV_HFYU-YV12.avi")
mp4 = AviSource("Matrix_Reloaded_Trailer_Ultra_MP4_HFYU-YV12.avi")
comp = Compare(mov.ConvertToYUY2, mp4.ConvertToYUY2, "", "MRel_H264.log")
ssim = SSIM(mov, mp4, "MRel_H264.csv", "MRel_H264.txt", lumimask=true)
diff = Subtract(mov, mp4).Levels(96,1,160,0,255)
return comp.Overlay(ssim).Overlay(diff)
The last line is necessary to make AviSynth believe, all of the comparing results might be part of the returned video clip -- else AviSynth would optimize their calls out, and I would not get the log files.

The result was a difference clip which started to look like an "Emboss" effect.

Reason:

In the QuickTime movie, the green "rating" screen is shown up to frame 119, the tailer starts black with frame 120.

In the H.264 movie, the green "rating" screen is shown up to frame 118, the tailer starts black with frame 119.

The length of the videos was equal, though -- else the function "Compare" would have complained that the lengths were different.
__

P.S.: Saving a graph from GraphEdit's result rendering the *.mp4 file and deleting the final "Video Renderer", an AviSynth script using DirectShowSource to open this *.grf file opens well in VirtualDubMod without freezing...

[Manao]

LigH : I've got no shift at all when I make SSIM & PSNR measurements. However, I don't use the same protocol you're using.

* firstly, my source is either a vob/d2v ( opened through mpeg2source ) or an avi huffyuv ( opened through DirectShowSource )
* secondly, I use DirectShowSource with mp4, and I don't bother to save it to huffyuv ( which is a loss of time, imho ).
* finally, instead of using overlay ( which requires some processing ), I use Interleave, which doesn't ( hence I'm able to computes PSNR / SSIM for several codecs at the same time ).

My best guest here is an issue with DirectShowSource ( which doesn't support a lot of thing, especially not seeking ). Try to encode the huffyuv instead of the avs + directshowsource script

[LigH]

Originally posted by Manao
...
Try to encode the huffyuv instead of the avs + directshowsource script
Good point - I'll try that.
__

Besides that: A few results here, comparing Ateme's H.264 and Koepi's XviD 1.0.2 at the same bitrate (1300 kbps, 0.100 bppf):

C:\Programme\encavc\encavc -i "*.avs" -o "*.mp4" -qual best -rcmode 2pass -br 1300 -psy 2 -adaptdeblock -ref 5 -cartoon
SSIM: Structural Similarity Index Metric 0.23
Average SSIM= 73.43
__

Comparing channel(s) YUV
Total frames processed: 3633

Minimum Average Maximum
Mean Absolute Deviation: 0.1142 1.2308 3.8867
Mean Deviation: -0.6448 -0.1523 +0.6153
PSNR: 32.7755 43.4412 56.9946
Overall PSNR: 41.7488
XviD 1st-pass: AS@L5, H.263, AQ, QP, GMC, 2 B-VOP *1.50 +1.00, COpt, MSP=6, VHQ=1, CM, max. 250 I, QF = 2-31/2-31/2-31, Trellis
XviD 2nd-pass: AS@L5, H.263, AQ, QP, GMC, 2 B-VOP *1.50 +1.00, COpt, MSP=6, VHQ=4, CM, max. 250 I, QF = 2-31/2-31/2-31, Trellis, BR=1300, OCS=0, Max OI=10, Max OD=10
SSIM: Structural Similarity Index Metric 0.23
Average SSIM= 68.82
__

Comparing channel(s) YUV
Total frames processed: 3634

Minimum Average Maximum
Mean Absolute Deviation: 0.0000 1.3317 4.0590
Mean Deviation: -0.8221 -0.1164 +0.7197
PSNR: 32.5336 45.4346 108.4650
Overall PSNR: 41.0346

[Teegedeck]

BTW, does the -cartoon switch really do nothing else but activate chroma ME? No changed skip-block thresholds or anything?

[Manao]

The difference between average and overall is huge for XviD, because of some black frames I think ( a max PSNR of 108 means that the frame was perfectly reconstructed ).

You should trim those black frames before making any comparison, because they bias objective measurements.

Also, for XviD, while making objective measurements, AQ is not a good idea, because it lowers the PSNR at same filesize.

[bobololo]

Originally posted by Teegedeck
BTW, does the -cartoon switch really do nothing else but activate chroma ME? No changed skip-block thresholds or anything?

I'm not sure if in xvid the chroma motion mode only affects the ME, but in our case, enabling the cartoon mode includes the chroma components in the whole decision process (ME, prediction modes, etc.), not only the ME.

[RBF]

bobololo

Whether it is impossible to add fast first pass, just as XVID?

[LostMP4]

Originally posted by RBF
bobololo

Whether it is impossible to add fast first pass, just as XVID?

It is available since the first beta, but only for long clips (>10000 frames or something like that, search in this thread!)

[LostMP4]

Is the fourth beta on the way?

[Bishep]

bobololo,
I misunderstood one thing... :confused: Are sub macroblocks partitioned down to 4x4? Or they are always 8x8? If not, do you have plans to partition :devil: them?

[Teegedeck]

Originally posted by bobololo
I'm not sure if in xvid the chroma motion mode only affects the ME, but in our case, enabling the cartoon mode includes the chroma components in the whole decision process (ME, prediction modes, etc.), not only the ME.
I asked because testers have started using -cartoon on all their encodes. Which would be a mistake if -cartoon also affects skip-thresholds as it does in XviD.

[babayaga]

Originally posted by Bishep
bobololo,
I misunderstood one thing... :confused: Are sub macroblocks partitioned down to 4x4? Or they are always 8x8? If not, do you have plans to partition :devil: them?

Currently, the beta 3 does not offer the option to choose sub-partitions (4x4, 8x4 and 4x8). Some could be generated but not after evaluating all options.

The efficiency gain for sub-partitions is rather small on standard applications (MPEG-2 source transcoded) but the speed penalty is high.

[babayaga]

Originally posted by LostMP4
Is the fourth beta on the way?

Yes :-)
And it will include a faster 1st pass, even on short clips.

[CruNcher]

@babayaga
im currently uploading a rar package wich shows a b-frame problem with normal mode could you check this :(

[bond]

sorry if i overread it, but did anyone already do an intercodec 2pass speed comparison, like comparing atemes codec to xvid, rv or wmv (with "maximum quality-low speed settings", like qpel...) for putting things also speed-wise into perspective?

[LostMP4]

Originally posted by bond
sorry if i overread it, but did anyone already do an intercodec 2pass speed comparison, like comparing atemes codec to xvid, rv or wmv (with "maximum quality-low speed settings", like qpel...) for putting things also speed-wise into perspective?

According to my tests "speed" is between 2-3 fps with all slowest options at about 1200 kbps (using the PC while doing encodes)
source: 720x576, 25 fps, using AviSynth 2.55, dgmpgdec1011
PC: Athlon XP 2600+ (Barton 166x11.5) 1024MB

[CruNcher]

jep bond ;)
you can read glimpse about this in the Quality Feedback thread
but i will wait first for the b-frame fix before i publish the detail preservation results speedwise compared to XviD ;)

[bobololo]

It has just been released, check your mailbox for the updated link !

Here is the changelog :

* beta 4 - beta 3

- Better intra/inter decision that provides higher coding efficiency (sharper and more fluent motion) (encavc.exe)
- RC improvement, it's more accurate and we should have less undersize (encavc.exe)
- Strengthen the psycho level 2 (encavc.exe)
- New weighted prediction for fade transitions (-setef wpred) (encavc.exe)
- Custom deblocking matrix (-customdeblock) (encavc.exe)
- Slight speed increase (simd code optimisation) (encavc.exe)
- Faster 1st pass (encavc.exe)
- Misc bugfixes in the dshow filters (adf_srcmp4.ax, adf_dech264.ax)

Enjoy :)

[IgorC]

Well after such closed beta test Ateme will provide 6-months trial version like Divx Team, isn´t it? :p

[bobololo]

Originally posted by IgorC
Well after such closed beta test Ateme will provide 6-months trial version like Divx Team, isn´t it? :p

The codec will be available in NeroDigital products like Recode 2.

[SeeMoreDigital]

I've have not received an email link for beta4...

I guess I'm not worthy anymore :(


Cheers

[bobololo]

Originally posted by SeeMoreDigital
I've have not received an email link for beta4...
I guess I'm not worthy anymore :(


Well, the testers list has been automatically updated following feedback posted so far. Testers who didn't show much responses to previous betas or who didn't notice me about their (un)availability were switched to an idle state. They can get back to an active state and receive new beta as soon as they notice me about their willing to continue the test.

This is done in order to avoid the spread of too many copies of the beta to people who don't really participate to the test.

I know you had hardware trouble and can't encode right now, just let me know as soon as you are able to participate and I'll switch you back to an active state.

[LostMP4]

Core encoder version 1.0.1.26

Input file : D:\encavc\test.avs
Output file : D:\encavc\09.mp4
Resolution : 720x576 @ 25.00 fps
Length : 72840 Frames
Process Priority : Idle
Rate Control : 2pass
Target Bit Rate : 1200 kb/s
Quality : Normal
Init Quantiser : 20 [0 - 51]
Max Consecutive BFrames : 3
Deblocking Strength : 0 (adaptive)
Direct Spatial MV Pred : Off
Num Reference : 1
Psychovisual : 1
Cartoon mode : On
Features : ipred ppred bpred wpred cabac deblock hpel qpel part

-- Start processing pass 1 / 2
* 100.00% completed
* 72840 frames processed @ 36.75 fps
-- Start processing pass 2 / 2
* 72839: encoding @ 25.60 fps - bitrate 53.19 kb/s - 100.00% completed
* 72840 frames encoded @ 10.20 fps - average bitrate 1204.24 kb/s

Encoding complete

These settings provide an excellent quality AND fast encode :)

Please notice the final bitrate: just a little oversized but I guess this wouldn't cause any trouble

About fast first pass: I noticed a really fast start, then the process became slower and slower...

And a RAM related issue (maybe...): I saw in Task Manager a large portion of RAM (about 230 MB) allocated but not process-related... maybe it was used by avisynth... I'll restart the PC and try with a new encode

[Sagittaire]

big bug with beta4 ... with all bframes ... !!!

encavc.exe -i azerty.avs -o psy0.mp4 -qual extra -rcmode 2pass -br 800000 -deblock 0 -ref 5 -setef wpred -cartoon

http://jfl1974.free.fr/Video/Bug-beta4.JPG


no bug without wpred

encavc.exe -i azerty.avs -o psy0.mp4 -qual extra -rcmode 2pass -br 800000 -deblock 0 -ref 5 -cartoon


no bug with wpred and without bpred

encavc.exe -i azerty.avs -o psy0.mp4 -qual extra -rcmode 2pass -br 800000 -deblock 0 -ref 5 -setef wpred -cartoon -clref bpred

[LostMP4]

Originally posted by Sagittaire
big bug with beta4 ... with all bframes ... !!!

encavc.exe -i azerty.avs -o psy0.mp4 -qual extra -rcmode 2pass -br 800000 -deblock 0 -ref 5 -setef wpred -cartoon

http://jfl1974.free.fr/Video/Bug-beta4.JPG


no bug without wpred

encavc.exe -i azerty.avs -o psy0.mp4 -qual extra -rcmode 2pass -br 800000 -deblock 0 -ref 5 -cartoon

Have you unistalled previous filters and installed the new ones?

[Sagittaire]

Have you unistalled previous filters and installed the new ones?

yes ... very strange ... ???

[bobololo]

Originally posted by Sagittaire
[B]big bug with beta4 ... with all bframes ... !!!

Update to the newest decoder filter. The previous had a bug in the weighted prediction.

[Sagittaire]

adf_dech264.ax 1.1.2.0 and adf_srcmp4.ax 1.2.2.0 for beta 3 and beta 4 ... perhabs error for my pack ... ???

[Nic]

@bobololo: I am testing...I'll try to come up with something useful, but I'd only be re-iterating what has already been said. Mainly been trying at the 128, 512 & 768 kbps range and comparing to other codecs. Especially at 512 (two pass -qual best -adaptquant) it's very impressive...
(Been testing on a dual Xeon P4 2.4ghz...and it works very stable there (only thought i'd mention as Xeon's tend to be a bit more picky with some optimised code....))

-Nic

[Sagittaire]

Have you unistalled previous filters and installed the new ones?

No ... lol

I found the problem ... :devil:

[IgorC]

I have seen some pictures of beta 3 and beta 4. Beta 4 provides more details. I also noticed that there are LESS blocks with homogeneous textures . And that’s good I can see balance between sharp-smooth. The price of sharp is some blocks. But those blocks are very , VERY hard to notice. This one is the best.
Have a look
Beta 4 - http://rbf.nm.ru/Nero_b4_extra_400_2.jpg
Beta 3 - http://rbf.nm.ru/Nero_400_2.jpg

Beta 4 - http://rbf.nm.ru/Nero_b4_extra_400_4.jpg
Beta 3 - http://rbf.nm.ru/Nero_400_4.jpg

I have no codec, i found it in one of the forums

[Andrey]

>>560x336
>>encavc.exe -i sword.avs -o h264.mp4 -qual extra -rcmode 2pass -br
1002000 -psy 2 -maxb 3 -par 64:45 -ref 5 -adaptdeblock -deblock -2 -
setef wpred
Just created Swordfish encode with this params.
1. Just the same runtime error after encoding ends. I think, it might be avisync, not encavc error, because vdub get this error too when using avs source.
2. Is par correct now ? Anyway, mpc plays this file not as widescreen.
3. BSPlayer plays the file not centered when playing fullscreen.
4. Bitrate at the end of the file was 6.8Mbit/s. The difference with previous version is that it is not dropped at the end of the file.

[bobololo]

We've been warned about a crash problem with beta 4 that could occur at low bitrate. We're working on it. A hotfix will be posted soon !

[Manao]

Andrey : could you post your avisynth script ? We could then know whether it is avisynth or encavc which causes the crash.

[ziw0d0]

@bobololo
Whether it is possible to receive filters (adf_srcmp4.ax, adf_dech264.ax) And to participate in testing as the independent observer?

[IgorC]

Just personal message. I understand that it´s closed beta testing. So somebody noticed something like feedback on the one Russian forum. But there is no reason for rumors .
I respect conditions of closed beta testing. The only way to have beta was communicate to Bobololo .
So can anybody post some *. mp4 of new beta 4. (bitrate 300-400-700-1000-1500-2000 kbit/s)

[bobololo]

Originally posted by IgorC
Just personal message. I understand that it´s closed beta testing. So somebody noticed something like feedback on the one Russian forum. But there is no reason for rumors .
I respect conditions of closed beta testing. The only way to have beta was communicate to Bobololo .
So can anybody post some *. mp4 of new beta 4. (bitrate 300-400-700-1000-1500-2000 kbit/s)

I'm not sure to follow you, but the beta was not so closed. It was opened to anyone who registered *in time*.

And by the way, I take advantage of this post to announce once again that we don't need more testers now and therefore it is useless to send me PM requesting to join. Your interest is really appreciate but we are definitely not able to handle more testers. I know that some of you can't wait to play with this new codec. Please be patient we're closer and closer from the public release :)

[bobololo]

Hi there,

I just sent out beta 4a which is a hotfix for the crash some of you reported. The changelog is :

- Fix a crash when encoding at low bitrate (encavc.exe)
- RC adjust preventing some rare oversizes (encavc.exe)

[pogo stick]

Oh, my god! I didn't think that H.264 things will start moving so fast! Screenshots and feedback are very promising and impressing! :)
But I am missing all the fun. :(
So I have few "out of curiosity" questions:
Will interlaced encoding and decoding be supported in future? I think some people (including me, after I tried interlaced XviD) will be missing it.
What about editing tools for H.264/MP4 files? Are there any plans for it? It seems like this codec will be very popular and such tool will be necessary.
And I båg and entreat for mercy to those who is responsible for DShow filters in Ahead products to make filters more user-friendly. Audio and video codecs may be great, but if DS parser and muxer will cause headache it will be very very sad. And why should Nero DS filters not work with not-Nero filters? For me it's very strange.
I don't know if this thread is the right place to beg someone :), but I hope that I will be heard.
Did you noticed that I am not asking about becoming tester or asking about Planning release date?:D
Wish you success and good luck!

[IgorC]

Talking about final version of Ateme H.264 and coming until end of 2004 VP7. I think On2¨s team will investigate Ateme H.264 codec for provide better quality , so probably Ateme codec will lose popularity without be popular.
Or Ateme will present new version in the time.

[CruNcher]

was -cartoon deactivated in beta4a for normal mode, because it didn't worked and Speed droped by 5 fps ?

[JohnV]

Originally posted by IgorC
Talking about final version of Ateme H.264 and coming until end of 2004 VP7. I think On2¨s team will investigate Ateme H.264 codec for provide better quality , so probably Ateme codec will lose popularity without be popular.
Or Ateme will present new version in the time.
I don't quite understand what you are trying to say but here's few facts:
On2/VP6 has had a big set back in China: http://www.digitimes.com/news/a20040917A2003.html

H.264 has lots of industry support already compared to VP6: http://sivut.koti.soon.fi/julaak/AVC_Alliance_1.jpg

The AVC alliance includes ADB, Apple, Ateme, Broadcom, Dolby, Envivio, Fraunhofer-HHI, Fujitsu, Harmonic, Hitachi, Hewlett-Packard, JVC, LSI Logic, Mitsubishi, Moonlight, Motorola, Nokia, Packet Video, Panasonic, Philips, Polycon, Samsung, Sentivision, Sharp, Sony, ST Micro, Tandberg, Texas instruments and Thomson Broadcast, and more are joining all the time.
AVC is also part of the HD-DVD and Blue-Ray standards.

I have very much trouble believing that VP6/7 can become really popular unless VP7 is truely an unbelievable codec, otherwise it will be tough times for On2 I fear...

Btw. Here's Ateme's h.264 decoder board decoding on TI 600Mhz DSP real time h.264:
http://sivut.koti.soon.fi/julaak/AVC_Alliance_3.jpg

[RBF]

I have encoded with Ateme interlaced clip consisting of white and red fields.
Ateme encoder has correctly coded both fields not mixing them. Ateme and Nero decoders correctly without mixing colors have decoded interlaced clip.
Whether it is necessary to enter additional adjustment interlaced/not interlaced source, when now all is correctly encoded?

[Manao]

RBF :If you were encoding it with interlaced support, the filesize would be lower ( theorically ) at same PSNR. However, I don't think encavc already support interlacing as the H264 norm implements it, so no need to test it yet.

[Mr_Schizo]

heya bobo,

i encountered the green blocks again :( .This time in another part of Underworld where it wasn't present before. I encoded it also without wpred which results in a fine/bugfree encode. So i guess it's an bug in wpred(well, we already guessed that and it should be a bit more validated now). I have seen it only at longer encodes so far with beta4 and also beta4a. I'll do another whole movie encode tomorrow (Matrix) to see if it also happens there.

I've prepared a little bugreport package which contains the b0rked clip and some notes about the used settings.
I've uploaded it to your incoming ftp (it's the "greenblocks" one).

[bobololo]

Originally posted by Mr_Schizo
heya bobo,

i encountered the green blocks again :( .This time in another part of Underworld where it wasn't present before. I encoded it also without wpred which results in a fine/bugfree encode. So i guess it's an bug in wpred(well, we already guessed that and it should be a bit more validated now). I have seen it only at longer encodes so far with beta4 and also beta4a. I'll do another whole movie encode tomorrow (Matrix) to see if it also happens there.

I've prepared a little bugreport package which contains the b0rked clip and some notes about the used settings.
I've uploaded it to your incoming ftp (it's the "greenblocks" one).

Thanks for reporting back this issue. We've checked and it appears the defect comes from the decoder. We're currently working on the fix and the new filters will be released soon.

[bobololo]

Originally posted by RBF
I have encoded with Ateme interlaced clip consisting of white and red fields.
Ateme encoder has correctly coded both fields not mixing them. Ateme and Nero decoders correctly without mixing colors have decoded interlaced clip.
Whether it is necessary to enter additional adjustment interlaced/not interlaced source, when now all is correctly encoded?

Currently the encoder doesn't support interlaced encoding. So whatever you send to the encoder, it considers the input as progressive material.

[keel]

Bobololo...any chance that the encoder or decoder for your codec will work under System X on the Mac in the future? I realize most users here have PCs, but there's also a lot of video production taking place on Macs, which is what we use. Don't mean to start a platform war (I've seen and been in enough, and had enough!), I use both, and am learning linux.

Thanks,
Frank

[plonk420]

Originally posted by keel
Bobololo...any chance that the encoder or decoder for your codec will work under System X on the Mac in the future? I realize most users here have PCs, but there's also a lot of video production taking place on Macs, which is what we use. Don't mean to start a platform war (I've seen and been in enough, and had enough!), I use both, and am learning linux.

Thanks,
Frank

i doubt there's much of a chance. there's just not enough money to be made, and all the "big houses" only trust big name brands like Avid, Apple, Cleaner (gag)...

it's a pitty because i've been strugling getting webvideo even remotely as high quality as even WMV9. and Discrete wants $200-300 for a 2pass version of their underwhelmingly mediocre (or worse) Sorenson 3 codec. you'd think the thousands the place i'm interning at is shelling out for Avid systems, Avid would at LEAST have the courtesy to send Sorenson 3 Pro...

i'd LIKE to try the new apple codec that was shipped with Panther, but i don't think they're going to shell out money for a new OS just for a codec...

i could have SWORN Apple Quicktime or Compressor had 2-pass mpeg-4 ASP, but i may just be confusing it with mpeg-2

either way, i haven't been able to get HQ streaming video macside :( stupid macs >_>

[Bulletproof]

Will the B-frames cap at 3 be removed eventually or is 3 the most efficient you can get? I also noticed there is no GMC (global motion compensation) option in the encoder, has this become obsolete?

[akupenguin]

GMC is not included in the H.264 spec. It never made a whole lot of difference in MPEG4 ASP, and I suppose it was made obsolete by MV prediction (replaces much of GMC's function) and multiple reference frames (would reduce GMC's efficiency).

I can't comment on Ateme's plans for B-frames.

[bobololo]

Originally posted by Bulletproof
Will the B-frames cap at 3 be removed eventually or is 3 the most efficient you can get? I also noticed there is no GMC (global motion compensation) option in the encoder, has this become obsolete?
Yes max 3 consecutive bframes is the optimal setting we've observed so far and we didn't have reports saying that having more involves much better results. Plus except the issue we have with bframes in the first beta, nobody really complained about them. Therefore we'll set the default to 3 and probably don't let the user to change this setting. Do you think we should let the users change this ?

Regarding the GMC, akupenguin provided a very good reply :)

[SeeMoreDigital]

Originally posted by Bulletproof
Will the B-frames cap at 3 be removed eventually or is 3 the most efficient you can get? I also noticed there is no GMC (global motion compensation) option in the encoder, has this become obsolete? Has anybody read bonds AVC Information (http://forum.doom9.org/showthread.php?s=&threadid=73022#post461589) recently. Aside from it being a useful read, are there any points that require revising?

There's also a useful, "Mpeg2, Mpeg4 ASP & Mpeg4 AVC Comp Table" that might also require updating: -

http://img55.exs.cx/img55/293/h264_features_matrix.gif


Cheers

[Bulletproof]

Originally posted by bobololo
Yes max 3 consecutive bframes is the optimal setting we've observed so far and we didn't have reports saying that having more involves much better results. Plus except the issue we have with bframes in the first beta, nobody really complained about them. Therefore we'll set the default to 3 and probably don't let the user to change this setting. Do you think we should let the users change this ?

Regarding the GMC, akupenguin provided a very good reply :)

I actually thought 3 was coded to be the max in the beta encoder because in the encavc.txt file it says [1 ; 3] but I just realized the encoder allows above 3 if you specify :eek: . Alot of people probably assumed the same thing and only tested with 3 b-frames which is why we probably haven't heard much about it. I will test some more B-frames and get back to you.

[akupenguin]

Originally posted by SeeMoreDigital
There's also a useful, "Mpeg2, Mpeg4 ASP & Mpeg4 AVC Comp Table" that might also require updatingSuggestions:
Either remove Rate/Distortion Optimization from the comparison, or add a check in the MPEG-2 and ASP columns: As stated in the AVC thread, RDO is really a function of the encoder, not the format. And while this feature was introduced by the H.264 reference codec, it is now available at least in libavcodec and XviD, so that includes MPEG-4 ASP and MPEG-2.
MPEG-4 ASP also allows 8x8 block size (a.k.a. 4MV).

[Bulletproof]

Ok it does seem 3 b-frames is the most efficient you can get, after 3 the quality just degrades.

In that chart it says that the standard allows 4x4 blocksize, was this implemented into the encoder? The encavc.txt file says the part option goes down to 8x8.

[bobololo]

Originally posted by Bulletproof
Ok it does seem 3 b-frames is the most efficient you can get, after 3 the quality just degrades.

In that chart it says that the standard allows 4x4 blocksize, was this implemented into the encoder? The encavc.txt file says the part option goes down to 8x8.
Yes it is implemented in the encoder but we haven't find a efficient way to exploit them. 4x4 sub partitions give too small gains compared to the extra computation they require. They've consequently been disabled.

[IgorC]

Seems to be good news http://www.dvd-software.info/blog/archives/industry_news/

[Bulletproof]

How is the custom deblocker activated, im using v1.0.1.28 of the encoder and trying: encavc.exe -i test.avs -o test.mp4 -customdeblock deblock.txt but the encoder doesn't say anything about using it and it still says and looks -2 for deblocking strength.

[bobololo]

Originally posted by Bulletproof
How is the custom deblocker activated, im using v1.0.1.28 of the encoder and trying: encavc.exe -i test.avs -o test.mp4 -customdeblock deblock.txt but the encoder doesn't say anything about using it and it still says and looks -2 for deblocking strength.

Even the application doesn't display anything to tell you're using custom deblocking, it is actually using it if you specify a custom file with the -customdeblock flag.

[Bulletproof]

I did a test by changing all the values in the deblock.txt to 6 and enabling the customdeblock option and I encoded another file but this time I just specified -deblock 6 to it. The files do not look identical however.

[bobololo]

Dear Testers,

And here comes the end of the beta test ! Since we didn't find any critical issues nor received alarming reports lately, we can consider that the encoder, with our latest bugfixes and sligh improvments, is now stable enough to be released.

This beta test was very successful and of course we would like to thank you so much for the very good feedback you all testers provided to us. They were very valuable for the improvements of the encoder. And we hope you'll appreciate the level it has reached thanks to your help.

Beside, to show our gratefulness to your contributions, we'll try to reward all involved testers. So keep an eye to your mailbox you'll receive further instructions soon.

Now watch out for the final public release and be prepared for the next beta round of the next major version of the encoder (which could maybe come soon, who knows ? ;)).

-- bobololo.

[LostMP4]

Originally posted by bobololo

Beside, to show our gratefulness to your contributions, we'll try to reward all involved testers. So keep an eye to your mailbox you'll receive further instructions soon.

Now watch out for the final public release and be prepared for the next beta round of the next major version of the encoder (which could maybe come soon, who knows ? ;)).

-- bobololo.

I sign for the next beta :D
(and wait for the bobololo's poster as reward :p)