AnimeSuki Forums

Register Forum Rules FAQ Members List Social Groups Search Today's Posts Mark Forums Read

Go Back   AnimeSuki Forum > Anime Related Topics > General Anime > Fansub Groups

Notices

Reply
 
Thread Tools
Old 2007-01-23, 09:56   Link #701
Sylf
翻訳家わなびぃ
*Fansubber
 
 
Join Date: Nov 2003
Age: 41
Send a message via MSN to Sylf Send a message via Yahoo to Sylf
Quote:
Originally Posted by Shounen View Post
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.
Sylf is offline   Reply With Quote
Old 2007-02-01, 00:04   Link #702
NoSanninWa
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?
__________________

There's not that fine a line between willing suspension of disbelief and something just being stupid.
NoSanninWa is offline   Reply With Quote
Old 2007-02-05, 12:03   Link #703
Kurth
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.
Kurth is offline   Reply With Quote
Old 2007-02-05, 20:27   Link #704
Quarkboy
Anime Translator
 
 
Join Date: Nov 2003
Location: Tokyo, Japan
Age: 35
Send a message via AIM to Quarkboy
Quote:
Originally Posted by Kurth View Post
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.
__________________
Yomiuri Television Enterprise
International Media Strategy Chief
Sam Pinansky

Last edited by Quarkboy; 2007-02-05 at 20:57.
Quarkboy is offline   Reply With Quote
Old 2007-02-05, 20:51   Link #705
jfs
Aegisub dev
 
 
Join Date: Sep 2004
Location: Stockholm, Sweden
Age: 30
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.
__________________

Aegisub developer [ Forum | Manual | Feature requests | Bug reports | IRC ]
Don't ask for: More VSFilter changes (I won't), karaoke effects, help in PM's
jfs is offline   Reply With Quote
Old 2007-02-06, 01:44   Link #706
Kurth
Junior Member
 
Join Date: Mar 2006
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.

Last edited by Kurth; 2007-02-06 at 02:03.
Kurth is offline   Reply With Quote
Old 2007-02-06, 05:57   Link #707
Musaran
Mind Wanderer
 
 
Join Date: Apr 2006
Location: In front of my computer
Age: 43
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 ?
Musaran is offline   Reply With Quote
Old 2007-02-06, 06:07   Link #708
Quarkboy
Anime Translator
 
 
Join Date: Nov 2003
Location: Tokyo, Japan
Age: 35
Send a message via AIM to Quarkboy
Quote:
Originally Posted by Musaran View Post
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...
Quote:
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.
__________________
Yomiuri Television Enterprise
International Media Strategy Chief
Sam Pinansky
Quarkboy is offline   Reply With Quote
Old 2007-02-06, 09:04   Link #709
martino
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.
__________________
"Light and shadow don't battle each other, because they're two sides of the same coin"
martino is offline   Reply With Quote
Old 2007-02-06, 10:13   Link #710
edogawaconan
LOL?
*Fansubber
 
 
Join Date: Aug 2006
Location: Indonesia
Send a message via MSN to edogawaconan Send a message via Yahoo to edogawaconan
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"
without considering playback cpu usage at all

dark scenes still kills x264 btw
__________________

Last edited by edogawaconan; 2007-02-06 at 10:17. Reason: easier code view
edogawaconan is offline   Reply With Quote
Old 2007-02-06, 13:02   Link #711
Kurth
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.
Kurth is offline   Reply With Quote
Old 2007-02-07, 03:56   Link #712
TheFluff
Excessively jovial fellow
 
 
Join Date: Dec 2005
Location: ISDB-T
Age: 28
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.
__________________
| ffmpegsource
17:43:13 <~deculture> Also, TheFluff, you are so fucking slowpoke.jpg that people think we dropped the DVD's.
17:43:16 <~deculture> nice job, fag!

01:04:41 < Plorkyeran> it was annoying to typeset so it should be annoying to read
TheFluff is offline   Reply With Quote
Old 2007-02-08, 07:51   Link #713
Musaran
Mind Wanderer
 
 
Join Date: Apr 2006
Location: In front of my computer
Age: 43
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:
Originally Posted by martino View Post
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]
Musaran is offline   Reply With Quote
Old 2007-02-08, 09:11   Link #714
DryFire
Panda Herder
 
Join Date: Dec 2005
Location: A bombed out building in Beruit.
Quote:
Originally Posted by Musaran View Post
-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).

Quote:
-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.


Quote:
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.
DryFire is offline   Reply With Quote
Old 2007-02-08, 11:31   Link #715
TheFluff
Excessively jovial fellow
 
 
Join Date: Dec 2005
Location: ISDB-T
Age: 28
Quote:
Originally Posted by Musaran View Post
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.
__________________
| ffmpegsource
17:43:13 <~deculture> Also, TheFluff, you are so fucking slowpoke.jpg that people think we dropped the DVD's.
17:43:16 <~deculture> nice job, fag!

01:04:41 < Plorkyeran> it was annoying to typeset so it should be annoying to read
TheFluff is offline   Reply With Quote
Old 2007-02-08, 12:39   Link #716
Quarkboy
Anime Translator
 
 
Join Date: Nov 2003
Location: Tokyo, Japan
Age: 35
Send a message via AIM to Quarkboy
Quote:
Originally Posted by Musaran View Post
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"
__________________
Yomiuri Television Enterprise
International Media Strategy Chief
Sam Pinansky
Quarkboy is offline   Reply With Quote
Old 2007-02-08, 16:42   Link #717
martino
makes no files now
 
 
Join Date: May 2006
Quote:
Originally Posted by Musaran View Post
-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
__________________
"Light and shadow don't battle each other, because they're two sides of the same coin"
martino is offline   Reply With Quote
Old 2007-02-08, 19:52   Link #718
Kurth
Junior Member
 
Join Date: Mar 2006
Quote:
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.
Kurth is offline   Reply With Quote
Old 2007-02-08, 23:10   Link #719
edogawaconan
LOL?
*Fansubber
 
 
Join Date: Aug 2006
Location: Indonesia
Send a message via MSN to edogawaconan Send a message via Yahoo to 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)
__________________
edogawaconan is offline   Reply With Quote
Old 2007-02-09, 01:15   Link #720
checkers
Part 8
*IT Support
 
 
Join Date: Jul 2006
Location: Western Australia
Age: 27
Send a message via MSN to 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
checkers is offline   Reply With Quote
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT -5. The time now is 01:36.


Powered by vBulletin® Version 3.8.8
Copyright ©2000 - 2015, vBulletin Solutions, Inc.
We use Silk.