AnimeSuki Forums

TheFluff · 2006-09-30, 10:30

Quote:

Originally Posted by Quarkboy

I experimented quite a while back with -aq, and yes, it did give better results in flat areas, however... I found that at the bitrates I use, it would significantly reduce the quants for the rest of the show if used at a strength where it would help significantly. For instance, an encode where the quants during high-motion scenes was 22+-4 would jump to 24+-4, with is a pretty significant quality loss.

This is exactly the disadvantage of AQ. In some unscientific tests I did with CRF 18 encodes, enabling --aq-strength 0.9 --aq-sensitivity 17 raised the bitrate required to reach the given CRF 18 by about 10%.
To be completely honest, my humble opinion is that AQ is far from always required, or even useful. But for what Mentar is talking about, I agree; it should be used for high-bitrate/high-quality encodes.

Mentar · 2006-09-30, 11:35

Guys, I find myself in a position somewhere between puzzlement and amusement here. This "disadvantage" which "raises" quants for constant-quant/quality encodes is a logical consequence and pretty much exactly what I want. It's nothing you should list as "buuuuut this is the downside" as if that wasn't clear to begin with.

Now before you all look at me perplexed, think of it this way: The current x264 bitrate bias emphasizes normal "bright" and well-contrasted spots on the expense of darker ones with less details. Of course you can make the encoder decision to say "it's sucky TV raws anyway, screw these spots", blur them into oblivion and just accept their degradation, and use the bitrate _stolen_ from there to polish up the rest of the frame more. Heck, there's even some logic to that, because most ASP-based TV raws already have these kind of dark spots damaged to begin with, so "preserving" it sometimes even acts as preserving "weaknesses". But still, it's a conscious decision to abandon the trouble spots.

In other words, it's "taken from the needy, given to the greedy", while the negative impacts of further screwing over the needy are mollified by smoothing it over. And this is what I (personally) dislike in many (not all, but many) 140-and-smaller encodes: While the contrasts tend to be clean with little ringing, the overall picture tends to be very very soft, and darker areas look strangely unicolor, with occasional big macroblocks stirred into the soup. Now I won't contest that this is a perfectly valid way to arrange the picture and entirely up to the encoder, but... not my cup of tea, sorry ^_^;

Once we reach the DVD-encode bitrates, it seems that we've reached a consensus that the bits should be sufficient to allow for AQ cleanups. About the medium-range (170) I guess we'll still have to fence it out

ffdshow · 2006-10-01, 03:23

Quote:

Originally Posted by slayer

h.264 is great! i want to download more of it but seeds.. gah no one wants to dl more..

Yes, it is a problem for h264 in double releases.

There is a pattern in our releases, at first the download rate of x264:XviD is roughly 1:1, then the number x264 drops and in longer term in fall back to about 1:2.5.

I think it has something to do with the seeds, many people don't like to download when the torrent seems slow. So if people batch the h264 but not xvid. The ratio should rise.

Talking about the double release, I think it is getting in the way. While a normal XviD encode takes 20-60 minutes, I am using 2-4 hours to encode x264. Counting the upload time, it is often a next day release.

Farix · 2006-10-01, 07:35

Quote:

Originally Posted by ender

Farix: simple - there's not enough users that would benefit from that - most of those that aren't afraid to go for H264 would go for the HD version anyway, and most of the rest don't want to change from XviD/AVI.

Do you have any evidence of this or are you just making an assumption?

Quote:

Originally Posted by kodachrome

...the file name?

How many groups put [HD] or [SD] in the fill name and how likely is it for your avarage downloader to look look at the file name before clicking on the link?

checkers · 2006-10-01, 08:37

Quote:

Originally Posted by Farix

Do you have any evidence of this or are you just making an assumption?

How many groups put [HD] or [SD] in the fill name and how likely is it for your avarage downloader to look look at the file name before clicking on the link?

I feel both of these assumptions are fair to make.
On the first, those who care more about the file the recieve are more willing to spend time & effort in getting better files to work.
On the second, most h264 HD releases that come from groups also doing a SD xvid release add a HD into the filename. The number of people who wouldn't see any single one of: filesize, HD in name, h264 in name, mkv/mp4 extension and confuse the download with a SD xvid gets what they deserve

Devastator · 2006-10-01, 09:03

Indeed. I don't think I've seen any groups that release in both XviD and h.264 and do not give some sort of hint (ie. tagging or commenting) as to what to expect.

Similarly for the SD / HD argument. Typically if it's unstated, it can be assumed to be SD. Even without stating SD / HD, the group may at least state a resolution from which such information can be discerned.

I don't recall seeing HDTV releases without a tag stating such, but I suppose there is the odd case when a group may not (or forgot). Even then, the file size should clue people in.

I believe that if those who download truly want to be conscious about what they're getting, they should be paying more attention rather than haphazardly clicking links and confirming (and even then there's still X amount of time between when you open the torrent and complete it) at first notice of the series title.

starscalling · 2006-10-01, 09:24

oops double posted on axx... if a mod would del this one that would be nice.

starscalling · 2006-10-01, 09:25

lol
wazzup@teh homies!
from a leecher prespective what we want is quality tempered with size
when blu ray dvd's become cheap and common then it wont be as important, but ive found that 233MB encodes are easy to swallow as are 175MB and there is no reason to shrink the encode smaller than that. i would love to see true hd encodes or higherdef encodes, but filesizes around a gig scare me a bit. ive a few TB of the current size encodes and i just dont know if i could go back to 4 eps per disk >_<
also ive noticed that some groups when doing an mkv dont force the subs track on ~_~ if someone [ i know its a bit off topic but they are often 264 if that makes u feel better ] wouldnt mind telling me how to do so i could quite nicely correct said groups and yeah....
anyway keep up the good work... what a thread...

emptyeighty · 2006-10-01, 13:35

Quote:

Originally Posted by starscalling

lol
i would love to see true hd encodes or higherdef encodes, but filesizes around a gig scare me a bit.

Largest 1080p ep i've seen is 350MB.

Quote:

also ive noticed that some groups when doing an mkv dont force the subs track on ~_~ if someone [ i know its a bit off topic but they are often 264 if that makes u feel better ] wouldnt mind telling me how to do so i could quite nicely correct said groups and yeah....

Simply set default audio/sub combinations in Haali. Read here.

TheFluff · 2006-10-01, 14:43

Or if you want to do it properly from the beginning, there's this checkbox called "default track" in mkvmerge GUI.

emptyeighty · 2006-10-01, 15:35

Quote:

Originally Posted by TheFluff

Or if you want to do it properly from the beginning, there's this checkbox called "default track" in mkvmerge GUI.

Also tell them to use chapters while you're at it :-)

Sylf · 2006-10-01, 20:16

Quote:

Originally Posted by emptyeighty

Largest 1080p ep i've seen is 350MB.

Did you really mean 1080p? I actually don't remember anyone releasing 1080p so far. All "HD" releases that I've seen are 720p. If it's really 1080p, I wouldn't be surprised even if an episode comes out at 500MB-600MB per 24 min episode, depending on the content.

DryFire · 2006-10-02, 00:24

Shinsen released a 1920x1080p fansub at 350mb, and prior to that there was a 708mb one which was basically the japanese raw +softsubs released on a private hd tracker.

Bother were of Chevalier episode 1.

Zero1 · 2006-10-05, 18:07

Code:

------------------------------------------------------------------------
r581 | pengvado | 2006-10-05 10:15:55 +0200 (Thu, 05 Oct 2006) | 2 lines

no more vfw

Discuss

DryFire · 2006-10-05, 18:18

It's kind of sad vfw was ever there in the first place :/

checkers · 2006-10-05, 18:57

The few complaints about it on the doom9 board seem to mostly say "we can decide what's best for ourselves and anyway there is no easy way to do h264 encoding without the vfw".
To which I say "if you really feel you need avi output it's a simple matter with avc2avi, and I think "familiar" would be a better term, because programs like megui with its inbuilt profile system require far less codec configuration". I would finish with an insult about their mothers and, if required, a last retort of "stop hosing".

The one thing that I'm worried about is the vfw lovers just not upgrading their x264. Maybe it would have been better to subtly break the vfw over a number of versions in order to maximise confusion and sow dissent within the evil enemies ranks.
</serious post>
(</html jokes>)

Farix · 2006-10-05, 20:00

/me heads for the nearest fall-out shelter

But seriously, this may be the cattle prod needed to get the non-vfw supported utilities to improve their usability without having the end user go through a steep learning curve.

SirCanealot · 2006-10-05, 20:19

Quote:

Originally Posted by checkers

The one thing that I'm worried about is the vfw lovers just not upgrading their x264.

Yeah, my version of x264 is kinda old, and I don't feel any INSANE need to upgrade it. I actually must remember to do so before the next time I encode with it, but I wouldn't be worried about the video quality if I forgot to. If the latest VFW version is a few weeks or months old, it's still a -ing good encoder that you won't *NEED* to upgrade for ages...

Quarkboy · 2006-10-05, 22:17

Quote:

Originally Posted by SirCanealot

Yeah, my version of x264 is kinda old, and I don't feel any INSANE need to upgrade it. I actually must remember to do so before the next time I encode with it, but I wouldn't be worried about the video quality if I forgot to. If the latest VFW version is a few weeks or months old, it's still a -ing good encoder that you won't *NEED* to upgrade for ages...

I'd say the time for a MUST upgrade would be once they've optimized the quality based on some physiological input, kind of what the -aq patch does now but actually doing it intelligently

. I believe the second best h264 codec, ateme (feel free to flame me on this

), has something of this sort implemented. Other than that, there have really only been very minor improvements over the last, 100 versions or so.

TheFluff · 2006-10-05, 22:27

Quote:

Originally Posted by Zero1

Code:

------------------------------------------------------------------------
r581 | pengvado | 2006-10-05 10:15:55 +0200 (Thu, 05 Oct 2006) | 2 lines

no more vfw

Discuss

REJOICE AND PRAISE THE LORD, FOR WE ARE ONE STEP CLOSER TO SALVATION

2006-10-01, 14:43	Link #490
TheFluff Excessively jovial fellow Join Date: Dec 2005 Location: ISDB-T Age: 37	Or if you want to do it properly from the beginning, there's this checkbox called "default track" in mkvmerge GUI. __________________ \| 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

2006-10-05, 18:07	Link #494
Zero1 Two bit encoder Fansubber Join Date: Jan 2006 Location: Chesterfield, UK Age: 39	Code: ------------------------------------------------------------------------ r581 \| pengvado \| 2006-10-05 10:15:55 +0200 (Thu, 05 Oct 2006) \| 2 lines no more vfw Discuss __________________ Made of win and awesome: 7-zip // x264 (Sharktooth's builds) // XviD (Koepi's builds) // MP4box (celtic_druid's builds) // Firefox // CCCP // CoreAVC

2006-09-30, 11:35	Link #482
Mentar Banned Join Date: Nov 2003 Location: Hamburg Age: 54	Guys, I find myself in a position somewhere between puzzlement and amusement here. This "disadvantage" which "raises" quants for constant-quant/quality encodes is a logical consequence and pretty much exactly what I want. It's nothing you should list as "buuuuut this is the downside" as if that wasn't clear to begin with. Now before you all look at me perplexed, think of it this way: The current x264 bitrate bias emphasizes normal "bright" and well-contrasted spots on the expense of darker ones with less details. Of course you can make the encoder decision to say "it's sucky TV raws anyway, screw these spots", blur them into oblivion and just accept their degradation, and use the bitrate _stolen_ from there to polish up the rest of the frame more. Heck, there's even some logic to that, because most ASP-based TV raws already have these kind of dark spots damaged to begin with, so "preserving" it sometimes even acts as preserving "weaknesses". But still, it's a conscious decision to abandon the trouble spots. In other words, it's "taken from the needy, given to the greedy", while the negative impacts of further screwing over the needy are mollified by smoothing it over. And this is what I (personally) dislike in many (not all, but many) 140-and-smaller encodes: While the contrasts tend to be clean with little ringing, the overall picture tends to be very very soft, and darker areas look strangely unicolor, with occasional big macroblocks stirred into the soup. Now I won't contest that this is a perfectly valid way to arrange the picture and entirely up to the encoder, but... not my cup of tea, sorry ^_^; Once we reach the DVD-encode bitrates, it seems that we've reached a consensus that the bits should be sufficient to allow for AQ cleanups. About the medium-range (170) I guess we'll still have to fence it out

2006-10-01, 09:03	Link #486
Devastator Senior Member Join Date: May 2006	Indeed. I don't think I've seen any groups that release in both XviD and h.264 and do not give some sort of hint (ie. tagging or commenting) as to what to expect. Similarly for the SD / HD argument. Typically if it's unstated, it can be assumed to be SD. Even without stating SD / HD, the group may at least state a resolution from which such information can be discerned. I don't recall seeing HDTV releases without a tag stating such, but I suppose there is the odd case when a group may not (or forgot). Even then, the file size should clue people in. I believe that if those who download truly want to be conscious about what they're getting, they should be paying more attention rather than haphazardly clicking links and confirming (and even then there's still X amount of time between when you open the torrent and complete it) at first notice of the series title.

2006-10-01, 09:24	Link #487
starscalling looking for translators Join Date: Dec 2004 Location: somewhere nice	oops double posted on axx... if a mod would del this one that would be nice.

2006-10-01, 09:25	Link #488
starscalling looking for translators Join Date: Dec 2004 Location: somewhere nice	lol wazzup@teh homies! from a leecher prespective what we want is quality tempered with size when blu ray dvd's become cheap and common then it wont be as important, but ive found that 233MB encodes are easy to swallow as are 175MB and there is no reason to shrink the encode smaller than that. i would love to see true hd encodes or higherdef encodes, but filesizes around a gig scare me a bit. ive a few TB of the current size encodes and i just dont know if i could go back to 4 eps per disk >_< also ive noticed that some groups when doing an mkv dont force the subs track on ~_~ if someone [ i know its a bit off topic but they are often 264 if that makes u feel better ] wouldnt mind telling me how to do so i could quite nicely correct said groups and yeah.... anyway keep up the good work... what a thread...

2006-10-02, 00:24	Link #493
DryFire Panda Herder Join Date: Dec 2005 Location: A bombed out building in Beruit.	Shinsen released a 1920x1080p fansub at 350mb, and prior to that there was a 708mb one which was basically the japanese raw +softsubs released on a private hd tracker. Bother were of Chevalier episode 1.

2006-10-05, 18:18	Link #495
DryFire Panda Herder Join Date: Dec 2005 Location: A bombed out building in Beruit.	It's kind of sad vfw was ever there in the first place :/

2006-10-05, 18:57	Link #496
checkers Part 8 IT Support Join Date: Jul 2006 Location: Western Australia Age: 35	The few complaints about it on the doom9 board seem to mostly say "we can decide what's best for ourselves and anyway there is no easy way to do h264 encoding without the vfw". To which I say "if you really feel you need avi output it's a simple matter with avc2avi, and I think "familiar" would be a better term, because programs like megui with its inbuilt profile system require far less codec configuration". I would finish with an insult about their mothers and, if required, a last retort of "stop hosing". The one thing that I'm worried about is the vfw lovers just not upgrading their x264. Maybe it would have been better to subtly break the vfw over a number of versions in order to maximise confusion and sow dissent within the evil enemies ranks. </serious post> (</html jokes>)

2006-10-05, 20:00	Link #497
Farix Senior Member Join Date: Jan 2005	/me heads for the nearest fall-out shelter But seriously, this may be the cattle prod needed to get the non-vfw supported utilities to improve their usability without having the end user go through a steep learning curve.