2007-02-01, 00:04 | Link #702 |
Weapon of Mass Discussion
Fansubber
Join Date: Feb 2003
Location: New York, USA
|
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?
__________________
|
2007-02-05, 12:03 | Link #703 |
Junior Member
Join Date: Mar 2006
|
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. |
2007-02-05, 20:27 | Link #704 | |
Translator, Producer
Join Date: Nov 2003
Location: Tokyo, Japan
Age: 44
|
Quote:
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.
__________________
Last edited by Quarkboy; 2007-02-05 at 20:57. |
|
2007-02-05, 20:51 | Link #705 |
Aegisub dev
Join Date: Sep 2004
Location: Stockholm, Sweden
Age: 40
|
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.
__________________
|
2007-02-06, 05:57 | Link #707 |
Mind Wanderer
Join Date: Apr 2006
Location: In front of my computer
Age: 52
|
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 ? |
2007-02-06, 06:07 | Link #708 | ||
Translator, Producer
Join Date: Nov 2003
Location: Tokyo, Japan
Age: 44
|
Quote:
Quote:
So basically, the smaller the file, the more (percentage-wise) you'd save over xvid.
__________________
|
||
2007-02-06, 09:04 | Link #709 |
makes no files now
Join Date: May 2006
|
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.
__________________
|
2007-02-06, 10:13 | Link #710 |
Hi
Fansubber
|
one question:
is AE-Maxquality profile in megui is good enough? cli params: Code:
--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" dark scenes still kills x264 btw
__________________
Last edited by edogawaconan; 2007-02-06 at 10:17. Reason: easier code view |
2007-02-06, 13:02 | Link #711 |
Junior Member
Join Date: Mar 2006
|
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. Last edited by Kurth; 2007-02-06 at 13:17. |
2007-02-07, 03:56 | Link #712 |
Excessively jovial fellow
Join Date: Dec 2005
Location: ISDB-T
Age: 38
|
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.
__________________
|
2007-02-08, 07:51 | Link #713 | |
Mind Wanderer
Join Date: Apr 2006
Location: In front of my computer
Age: 52
|
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)? Quote:
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] |
|
2007-02-08, 09:11 | Link #714 | ||
Panda Herder
Join Date: Dec 2005
Location: A bombed out building in Beruit.
|
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). Quote:
Quote:
|
||
2007-02-08, 11:31 | Link #715 | |
Excessively jovial fellow
Join Date: Dec 2005
Location: ISDB-T
Age: 38
|
Quote:
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.
__________________
|
|
2007-02-08, 12:39 | Link #716 | |
Translator, Producer
Join Date: Nov 2003
Location: Tokyo, Japan
Age: 44
|
Quote:
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"
__________________
|
|
2007-02-08, 16:42 | Link #717 | |
makes no files now
Join Date: May 2006
|
Quote:
XviD: ~500kbps; x264: ~240kbps Yeah, that would make it 50%... lol
__________________
|
|
2007-02-08, 19:52 | Link #718 | |
Junior Member
Join Date: Mar 2006
|
Quote:
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. |
|
2007-02-09, 01:15 | Link #720 |
Part 8
IT Support
|
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 |
|
|