The H.264/AVC/MPEG4 discussion thread

[Sylf]

Originally Posted by Shounen

Softsubs are good for leechers, they just need to use 1 more step to be able to use it.

Trying to tell those groups that softsubs are good - they have their own reason why they stick with hard subs, and why with mp4 container.

[NoSanninWa]

That anti.x264 discussion has hijacked this thread for 5 pages and 5 days. (Wow!) I think it is time to send it elsewhere so that this thread can go back to encoder talk. Find those missing 83 posts here:

Is anti.x264 good or evil?

[Kurth]

What do you people think about turning off CABAC and Deblocking Filter when encoding anime episodes with resolution 704x400 and 640x480 at 175 MB final filesize?
CABAC and Deblocking Filter options eat a lot of CPU when you encode and watch the anime soo if you turn it off you can make a file that use less CPU usage.
175 MB file have a lot of bitrate and even if you turn of those options the quality is still very good I dont really see any blocks that was created by the encode.
The file dont become fast like and Xvid encode but it still have a really better quality than an Xvid encode and people with lower CPU processors can watch it.

[Quarkboy]

Originally Posted by Kurth

What do you people think about turning off CABAC and Deblocking Filter when encoding anime episodes with resolution 704x400 and 640x480 at 175 MB final filesize?
CABAC and Deblocking Filter options eat a lot of CPU when you encode and watch the anime soo if you turn it off you can make a file that use less CPU usage.
175 MB file have a lot of bitrate and even if you turn of those options the quality is still very good I dont really see any blocks that was created by the encode.
The file dont become fast like and Xvid encode but it still have a really better quality than an Xvid encode and people with lower CPU processors can watch it.

Edit, Ignore this see post below->As with turning off deblocking, with ffdshow you can override that in the ffdshow settings even without the encoder doing that. (And I think that it looks horrible, personally).

CABAC is anywhere between 50-70% of the efficiency gain between xvid and h.264. Disabling it would allow almost anyone to play back those encodes, yes, but it's a huge quality hit for encoders to accept.

You're probably right, however, if I made my group's 640x480 encodes at 175 MB I think the extra bitrate might compensate for the CABAC loss, but I really think that it's something no anime encoder would consider doing.

It might be the currently best compromise between quality and playback processor power requirements for YOUR computer, but I don't think anyone will do it.

[jfs]

Also (this is unbased) I believe that turning off deblocking at encoding makes the encoder produce a stream intended for playback without deblocking. This probably means that it'll need to use overall lighter quantization and probably also more use of some other bitrate eaters. So files encoded without in-loop deblocking shouldn't look as bad as files encoded with it but it turned off in the decoder and it can't really be compared.

[Kurth]

It is better if the leechers have better processors but 175 MB encodes seems to waste too much bitrate soo we dont really need to use all very slow options with 175 MB encodes.

[Musaran]

I vaguely remember reading that MPEG 4 ASP had trouble with animation's hard edges and paradoxaly required more bitrate for simpler content, while h264 adressed this.
Is it true ?

And, in your experience, what is the video bitrate ratio between an x264 and XviD encode of same visual quality ?

[Quarkboy]

Originally Posted by Musaran

I vaguely remember reading that MPEG 4 ASP had trouble with animation's hard edges and paradoxaly required more bitrate for simpler content, while h264 adressed this.
Is it true ?

I don't know about that one, but yes, there's a lot less mosquito noise in AVC encodes...

And, in your experience, what is the video bitrate ratio between an x264 and XviD encode of same visual quality ?

It varies depending on the overall bitrate and the total resolution... The ratio is very small ~10% improvement at very high bitrates (for the resolution), however h.264 can obtain far less lossy compression then xvid at SUPER high bitrate (though it's probably not visible to the untrained eye).... At medium bitrates for the resolution I'd guesstimate you can save about 25% switching to h.264... and at very low bitrates it can go up to 50% or more.... For anime sources, some amazing quality results can be achieved at super super low bitrates, with maybe 60-70% bitrate savings over xvid for really really low bitrates.

So basically, the smaller the file, the more (percentage-wise) you'd save over xvid.

[martino]

The most I myself managed to save with H264 over XviD was around 100% (of the XviD's bitrate), this was an anime with very simple animation, very little motion and loads of static scenes. H264 performs noticeably better at very low bitrates as Quarkboy said as compared to XviD.

[edogawaconan]

one question:
is AE-Maxquality profile in megui is good enough?
cli params:

 --pass 2 --bitrate 700 --stats ".stats" --ref 16 --mixed-refs --no-fast-pskip\
 --bframes 3 --b-pyramid --b-rdo --bime --weightb --direct auto --filter 1,1 --subme 7\
 --trellis 2 --analyse all  --8x8dct --vbv-maxrate 25000 --me umh\
 --threads auto --thread-input --progress --no-psnr --no-ssim --output "outputz.mp4" "inputz.avs"

without considering playback cpu usage at all

dark scenes still kills x264 btw

[Kurth]

16 mixed references is soo fucking slow and will not give you more quality that worth the very high encoding time that is needed for 16 mixed refs.
The max that I use here is 8 mixed refs and comparing with and encode with the defaulf value 1 ref there is a large difference in encoding time and a little difference on quality.
You dont really need 16 mixed refs it will not give you enough quality that worth the huge encoding time.

Delete this option "--vbv-maxrate 25000" it is useless for the bitrate that we use.

[TheFluff]

If you have problems with dark scenes, consider using a Sharktooth build and adding --aq-strength 1.0.

Also, --trellis 2 is EXTREMELY slow. I'm unsure about how much it improves over --trellis 1, but if you can't stand the slow encoding speed, try with 1.

[Musaran]

Thanks for the feedback, it confirms what I thought: most efficient in the high compression domain, just like He-AAC.

I also remember reading that MPEG-2 has a "sweet spot" at 1.2 bits per pixel. Is there such a thing for AVC (or ASP for that matter)?

Originally Posted by martino

The most I myself managed to save with H264 over XviD was around 100% (of the XviD's bitrate)

-100% would be going from whatever to nothing, maybe you mean XviD/h264=200% ; h264/XviD= 50% ?


Speaking of encode times, how does h264 (actually it's codecs) behave when pushing it to ever higher encode times to gain ever fewer % efficiency ?
-Is there more efficiency gain than with XviD ?
-Are there "progress steps" or is it rather continuous ?
-Is there some kind of hard limit to improvement ?


And is x264 mostly done, or can it still significantly improve ?

[/curious]

[DryFire]

Originally Posted by Musaran

-Is there more efficiency gain than with XviD ?

If you consider spped/PSNR or speed/SSIM x264 is always better then xvid in that area:
http://forum.doom9.org/showthread.ph...=speed+vs+psnr (a bit old by now).

-Is there some kind of hard limit to improvement ?

There are some options that have a general(?) limit but other things you could spend ages tweaking, like deblocking, aq, deadzone and/or a custom quant matrix.

And is x264 mostly done, or can it still significantly improve ?

It's stable, but still considered to be in the alpha stages feature wise.

[TheFluff]

Originally Posted by Musaran

I also remember reading that MPEG-2 has a "sweet spot" at 1.2 bits per pixel. Is there such a thing for AVC (or ASP for that matter)?

BPP is a completely meaningless statistic and you shouldn't be paying any attention to it whatsoever. Your question is roughly equivalent with "at what bitrate should I encode?", meaning that there isn't any easily predictable answer. If you want to measure how well your source compresses, do a one-pass CQ 18 encode and check the bitrate.

It should also be noted that even at very high bitrates/very low quantizers, h264 still looks better than XviD, in some cases considerably better. ASP codecs have certain inherent flaws that just won't go away no matter how much bitrate you give them.

[Quarkboy]

Originally Posted by Musaran

Speaking of encode times, how does h264 (actually it's codecs) behave when pushing it to ever higher encode times to gain ever fewer % efficiency ?
-Is there more efficiency gain than with XviD ?
-Are there "progress steps" or is it rather continuous ?
-Is there some kind of hard limit to improvement ?


And is x264 mostly done, or can it still significantly improve ?

[/curious]

Hmm, I'd like to address these very difficult questions.

I'm interpreting your first question to mean "does setting the options to the highest quality (whatever that means) in x264 do as much good as setting the options to the highest quality in xvid?"

The answer is completely dependant on the source. And, for that matter, is generally irrelavent since I think any encoder would use xvid with the highest settings for any xvid encode nowadays, with the speed improvements of computers.

On the other hand, it's quite easy to push settings in x264 so high as to slow down encodes to a crawl even on the fastest machines. So then, we get to your second question: Is there some kind of gradual curve of "better quality/slower encoding speed"? Yes.

For example, if we fix all of the x264 settings in some way, and then purely adjust the number of reference frames, you can easily see that encoding slows down considerably as you increase them. How much it slows down is dependant a lot on the source video, but I'd say with no proof that a ref=16 encode will probably be 3 times as slow as a ref = 1 encode. But it's not a linear scale, so a ref = 8 encode might only be 1.5 times as slow as a ref =1 encode. Furthermore, the gain in bitrate efficiency decays exponentially with the number of reference frames. I.e. ref = 2 might give you a 20% savings, but ref = 4 might only be 25%. Ref = 16 might squeeze you up to 27%... etc... So as you push the settings higher and higher, you get less and less gain in compression quality/speed decrease.

Essentially the same thing is true for all the other options that slow things down. Trellis 1 is a great option that saves a bunch of bitrate without slowing things down too mush. Trellis 2 slows things down like crazy and gives something like a 1-2% savings over trellis 1 (I use it anyway ). Other options like no-dct skip etc, are designed to fix certain problem aspects with the codec and don't slow down things TOO much, but can help with certain isolated non-bitate based compression issues.

And finally, to the last question about there being some hard line to improvements, the answer is, no. But there is definitely a soft line.
The truth is, you can only compress video so much with this techniques available to you. The essence of these (and all macroblock based) codecs is "find a piece of video, and figure out where it moves, then store the movement data instead of the video data". In theory, one could analyze the entire video based on 1 pixel macroblocks, identify the optimally small way of representing the motions of all those pixels (i.e. vector track them), reference every frame to every other frame (making playback nearly impossible) and compress things like crazy.
But with sane motion estimation algorithms, when you think about it anything more then reference 16 is insane. How often does a part of a picture relate only to something that appears 16 frames away? And increasing the motion search estimation size area... how often does an object move from one side of the screen to the other in one frame? With the inherent limitations of the algorithm and the representation of the video, all further improvements will be incremental (and consist of improvements to the efficiency of these types of algorithms).


To sum up, I think that h264 might well be the last large improvement in macroblock based video compression we'll see IN OUR LIFETIMES. It will be replaced (if at all) with something completely different in concept (like perhaps a wavelet based approach like SNOW). To misquote Bill Gates "I don't think anyone will ever need better video compression than h.264"

[martino]

Originally Posted by Musaran

-100% would be going from whatever to nothing, maybe you mean XviD/h264=200% ; h264/XviD= 50% ?

Oh, sorry. Don't do maths when your brain is not working.

XviD: ~500kbps; x264: ~240kbps

Yeah, that would make it 50%... lol

[Kurth]

I.e. ref = 2 might give you a 20% savings, but ref = 4 might only be 25%. Ref = 16 might squeeze you up to 27%

I know that this is just an exemple but for the people that read this you should dont believe that ref=2 give 20% bitrate saving because for an encode that I did with 16 mixed refs on a 640x480 pixels Anime I just got near 3% total bitrate saving I got angry and never used this anymore for a huge time encoding for just near 3% bitrate save.

Well that is true some options is useless to use their max values at medium to high bitrates.
The difference on quality between those options is very low but the increase on encode time is very large.
RDO 6 -> RDO 7
Trellis 1 -> Trellis 2
Multi Hexagon -> Exaustive
1 ref -> 16 ref mixed
2-Pass -> 3-Pass

I think those max options might be just usefull for very low bitrate encode because for a 100 MB to 175 MB it is useless to use those max values.
Too slowwwww for just a little bit of quality and bitrate saving, not really usefull.

[edogawaconan]

--aq-strength 1.0 increases encoding time by almost 2 times on my machine O_o

I can actually stand slow encodes because I start encodes before I'm sleeping

(except for exhaustive, that's just stupid)

[checkers]

Highly Scientific AQ speed testing:
Source:
directshowsource("G:\Anime\REC\[Lunar] REC - 01 (XviD) [E0B3B7F0].mkv",audio=false).trim(100,1000)

Common x264 options:
--crf 20 --ref 5 --mixed-refs --no-fast-pskip --bframes 6 --b-pyramid --bime --weightb --direct none --filter -1,-1 --subme 6 --trellis 2 --analyse all --8x8dct --threads 4 --thread-input --cqmfile "M4G Smooth V1.cfg" --progress --no-psnr --no-ssim [...] "test.avs"

Results:
--aq-strength 1.1: 15.29fps

No AQ:: 18.69fps