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

[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.