AnimeSuki Forums

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

Go Back   AnimeSuki Forum > Anime Related Topics > Fansub Groups

Notices

Reply
 
Thread Tools
Old 2008-09-09, 05:15   Link #161
Dark Shikari
x264 Developer
 
 
Join Date: Feb 2008
Quote:
Originally Posted by Nagato View Post
with low bitrates the blocks will be revived like zombies anyway.
Not if you use psy-RD
Dark Shikari is offline   Reply With Quote
Old 2008-09-09, 07:34   Link #162
TheFluff
Excessively jovial fellow
 
 
Join Date: Dec 2005
Location: ISDB-T
Age: 28
Quote:
Originally Posted by MoonLight- View Post
MSmooth
don't do this
__________________
| 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 2008-09-09, 10:37   Link #163
edogawaconan
LOL?
*Fansubber
 
 
Join Date: Aug 2006
Location: Indonesia
Send a message via MSN to edogawaconan Send a message via Yahoo to edogawaconan
Quote:
Originally Posted by MoonLight- View Post
<snip>
tell the watcher to use gradfun. and pray that their system is powerful enough
__________________
edogawaconan is offline   Reply With Quote
Old 2008-09-09, 11:55   Link #164
max2k
Member
 
 
Join Date: Jul 2007
Quote:
Originally Posted by edogawaconan View Post
tell the watcher to use gradfun. and pray that their system is powerful enough
Yes tell the crowd who think avi is the same think like divx, to use a postprocesor filter... Yes gradefun() ist postprocesing Filter, but with enough bitrate some off the grain will be keept in a x264 encode, and its looks nicer then addgrain()....
max2k is offline   Reply With Quote
Old 2008-09-09, 12:42   Link #165
Dark Shikari
x264 Developer
 
 
Join Date: Feb 2008
Quote:
Originally Posted by max2k View Post
Yes tell the crowd who think avi is the same think like divx, to use a postprocesor filter... Yes gradefun() ist postprocesing Filter, but with enough bitrate some off the grain will be keept in a x264 encode, and its looks nicer then addgrain()....
Gradfun2db() compensates for a lack of precision in the YV12 colorspace... its not really related to any particular video format.
Dark Shikari is offline   Reply With Quote
Old 2008-09-09, 12:58   Link #166
max2k
Member
 
 
Join Date: Jul 2007
I tested gradefun2db() with some colorbanding heavy source, it was fine for the x264 encode, but xvid never keept enough of the grain, even with 150% of the average bitrate of the 1pass, to compensate the colorbanding.
max2k is offline   Reply With Quote
Old 2008-09-09, 13:20   Link #167
edogawaconan
LOL?
*Fansubber
 
 
Join Date: Aug 2006
Location: Indonesia
Send a message via MSN to edogawaconan Send a message via Yahoo to edogawaconan
Quote:
Originally Posted by max2k View Post
Yes tell the crowd who think avi is the same think like divx, to use a postprocesor filter... Yes gradefun() ist postprocesing Filter, but with enough bitrate some off the grain will be keept in a x264 encode, and its looks nicer then addgrain()....
tell them to right-click that cute red FFv icon on systray and click on gradfun?

*and tell anyone else whom doesn't use windows/ffdshow that they are out of luck
__________________
edogawaconan is offline   Reply With Quote
Old 2008-09-09, 13:47   Link #168
MoonLight-
Lucid Light
 
 
Join Date: May 2008
blocks get better atm ^^

I didn't know that 3600 is low bitrate, anyway I switched to 4200..
but.. blocks still existied in darky clips T_T

I think darky animes is the most annoying for encoders, especially when darky clip
and blur comes together imo
MoonLight- is offline   Reply With Quote
Old 2008-09-09, 14:44   Link #169
max2k
Member
 
 
Join Date: Jul 2007
With a bitrate of 4200 in x264 ther should be some serious decoding issues and one episdoe with 24 minutes should have a size around 800mb...
max2k is offline   Reply With Quote
Old 2008-09-09, 15:32   Link #170
TheFluff
Excessively jovial fellow
 
 
Join Date: Dec 2005
Location: ISDB-T
Age: 28
Quote:
Originally Posted by max2k View Post
With a bitrate of 4200 in x264 ther should be some serious decoding issues
what kind of issues?
__________________
| 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 2008-09-09, 17:15   Link #171
max2k
Member
 
 
Join Date: Jul 2007
Quote:
Originally Posted by TheFluff View Post
what kind of issues?
I dont think i realy have to tell you.

Some thing on the line of heavy slow downs on playback on most systems because of to high cpu usage at the decoding time. You know x264 is not mpeg2 or a lossless codec, it has more complex compresion algorithm, thats why files can be mouch smaller with good quality, but need more cpu power to encode and to decode. And the bitrate is the next bigest factor how hard a file is to decode.

(I should really try a to high bitrate encode in x264 myself, i dont know if x264 realy stops if he dont can use the bitrate anymore, like xvid would do. And how hard the surplus informations are to decode. I did a automated 2pass at a bitrate of 1500 with a source that would reach quant16 at 600, and he used all the bitrate so i thought the x264 codec whould use all the bitrate u give him at any time. Is it wrong?)

Last edited by max2k; 2008-09-09 at 17:31.
max2k is offline   Reply With Quote
Old 2008-09-09, 18:32   Link #172
Dark Shikari
x264 Developer
 
 
Join Date: Feb 2008
Quote:
Originally Posted by max2k View Post
I tested gradefun2db() with some colorbanding heavy source, it was fine for the x264 encode, but xvid never keept enough of the grain, even with 150% of the average bitrate of the 1pass, to compensate the colorbanding.
Well of course, Xvid doesn't have the kind of AQ or psy RD that x264 has, which basically makes it impossible to retain the dithering from gradfun2db at any sane settings.

Quote:
Originally Posted by max2k View Post
I dont think i realy have to tell you.

Some thing on the line of heavy slow downs on playback on most systems because of to high cpu usage at the decoding time. You know x264 is not mpeg2 or a lossless codec, it has more complex compresion algorithm
Actually, most lossless formats are much slower to decode than H.264. Also, its called H.264, not x264; x264 is just the encoder, not the name of the format.
Dark Shikari is offline   Reply With Quote
Old 2008-09-10, 04:13   Link #173
max2k
Member
 
 
Join Date: Jul 2007
Quote:
Originally Posted by Dark Shikari View Post
Actually, most lossless formats are much slower to decode than H.264.
But thats more on the line of the bitrate they need to be lossless and not on the line of compresion algorithm, or?
max2k is offline   Reply With Quote
Old 2008-09-10, 04:40   Link #174
Dark Shikari
x264 Developer
 
 
Join Date: Feb 2008
Quote:
Originally Posted by max2k View Post
But thats more on the line of the bitrate they need to be lossless and not on the line of compresion algorithm, or?
Well yes, the main reason is because they have to compress (and decompress) a whole lot more information. Though, for example, FFV1 uses a very similar entropy coder to H.264.
Dark Shikari is offline   Reply With Quote
Old 2008-09-10, 04:59   Link #175
TheFluff
Excessively jovial fellow
 
 
Join Date: Dec 2005
Location: ISDB-T
Age: 28
Quote:
Originally Posted by max2k View Post
I dont think i realy have to tell you.

Some thing on the line of heavy slow downs on playback on most systems because of to high cpu usage at the decoding time. You know x264 is not mpeg2 or a lossless codec, it has more complex compresion algorithm, thats why files can be mouch smaller with good quality, but need more cpu power to encode and to decode. And the bitrate is the next bigest factor how hard a file is to decode
You make a logical argument but it's actually most likely wrong. You make the mistaken assumption that the bitrate is mostly evenly distributed and that 4mbps is a lot; this is wrong. Even with much lower bitrates (~1800kbps) x264's rate control can happily throw 10-15mbps or more at short (10-30 seconds) sequences (see f.ex. the kurenai op, which peaked at something dumb like 20mbps for a few seconds). It's true that doubling the average bitrate would give it more bits to allocate and in theory raise the bitrate peaks even more, but while this will happen to some extent, most of the extra bits will probably go to raising the average bitrate of the rest of the clip, at least with a sane minimum QP.

Quote:
Originally Posted by max2k View Post
(I should really try a to high bitrate encode in x264 myself, i dont know if x264 realy stops if he dont can use the bitrate anymore, like xvid would do. And how hard the surplus informations are to decode. I did a automated 2pass at a bitrate of 1500 with a source that would reach quant16 at 600, and he used all the bitrate so i thought the x264 codec whould use all the bitrate u give him at any time. Is it wrong?)
see --qpmin, set it to 1 to allow essentially infinite bitrates
(actually coding as lossy with qpmin 1 most likely allows a lot higher bitrates than coding as lossless (qp 0) in many cases. funny how that works.)
__________________
| 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 2008-09-10, 06:00   Link #176
max2k
Member
 
 
Join Date: Jul 2007
I not thought that that the "bitrate is mostly evenly distributed"(I did mouch xvid encopding in VfW, so i know how the bitrate distruption can look in a vbr encode). But i did make the failure to think : If i raise the average bitrate, that the "hard to compress scens" would get more bitrate near this factor.

Is ther a way to go sure that i dont get complains from leachers, that thought they can look the h264 720p Denou Coil encode, until the explosions scens start to kick in in episode 5, and bring the first real "bitrate peaks" of this series?
max2k is offline   Reply With Quote
Old 2008-09-10, 06:47   Link #177
TheFluff
Excessively jovial fellow
 
 
Join Date: Dec 2005
Location: ISDB-T
Age: 28
You can use the VBV buffer settings (intended to make sure the encoder doesn't encode streams with bitrate peaks that a DVD player or streaming device are too slow to read) to limit bitrate peaks of an encode.
__________________
| 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 2008-09-10, 11:16   Link #178
Dark Shikari
x264 Developer
 
 
Join Date: Feb 2008
Quote:
Originally Posted by TheFluff View Post
see --qpmin, set it to 1 to allow essentially infinite bitrates
(actually coding as lossy with qpmin 1 most likely allows a lot higher bitrates than coding as lossless (qp 0) in many cases. funny how that works.)
QP0 isn't lossless unless you explicitly set --qp 0 or --crf 0.
Dark Shikari is offline   Reply With Quote
Old 2008-09-10, 15:00   Link #179
TheFluff
Excessively jovial fellow
 
 
Join Date: Dec 2005
Location: ISDB-T
Age: 28
Quote:
Originally Posted by Dark Shikari View Post
QP0 isn't lossless unless you explicitly set --qp 0 or --crf 0.
Oh. I had no idea.
__________________
| 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 2008-09-11, 02:44   Link #180
OroSaiwa
Junior Member
 
 
Join Date: Jun 2008
Quote:
Originally Posted by TheFluff View Post
You can use the VBV buffer settings (intended to make sure the encoder doesn't encode streams with bitrate peaks that a DVD player or streaming device are too slow to read) to limit bitrate peaks of an encode.
Talking about VBV and since Dark Shikari is an x264 developer, I keep having problems of VBV buffer underflow with my encodes, either I specify the VBV Buffer Size and Max Bitrate according to this http://rob.opendot.cl/index.php/usef...es-and-levels/ or leave it automatic.

I started to panic when I saw so many VBV underflows in avinaptic but then I checked another couple of encodes (CGR2 HD of Eclipse) and saw that avinaptic gave the same errors. It might be an avinaptic bug since it's not been updated since November?

Checked on Doom9 and saw this issue is frequent but I can't post there for another day.

Nicholi told me it's not sth to worry too much about if it's underflow. Overflow would be bad.

Anyway this is my line from my megui profile:

Quote:
program --pass 2 --bitrate 3516 --stats ".stats" --level 5.1 --ref 8 --mixed-refs --no-fast-pskip --bframes 4 --b-pyramid --b-rdo --bime --weightb --subme 7 --trellis 2 --partitions p8x8,b8x8,i4x4,i8x8 --8x8dct --b-bias 4 --me umh --merange 24 --threads 2 --thread-input --progress --no-dct-decimate --no-psnr --no-ssim --output "output" "input"
I'm ripping Code Geass Blu-rays at 1080p, mkv softsub so mostly for PCs.

I keep doing experiments and trying new things to introduce in the Italian fansub scene

Thnx to TheFluff and Mentar for their help and their patience.
OroSaiwa 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 13:14.


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