CRF isn't only option to define bitrate. For instance, larger qcomp means assigning more bitrate to complex scenes and less to simple/static ones. Kageru has larger qcomp, this alone can reduce bitrate a lot in such low-action anime (by making static scenes look bit worse).
4:4:4 by itself does increase bitrate because you simply need to encode 4x more chroma pixels. That said, chroma usually has much less details than luma (see https://en.wikipedia.org/wiki/File:Bar...ation.jpg) so 4:4:4 won't have very significant impact on overall bitrate. In addition to that, choosing 4:4:4 in x264 automatically raaises chroma_qp_offset parameter, so unless you manually reduce it chroma gets compressed more aggressively and is likely to have even less bitrate than 4:2:0 with same parameters. Plus, there's video filtering.
My experience is, that chroma subsampling of 4:4:4 (no subsampling) provides compression improvements with H.264 High Predictive Profile (as used here), especially at 10-bit (but more CPU consumption). There's also a different deblocking setup.
That's right. Audio bit rate isn't mentioned but I don't think it can cause a 500 Kbps difference in overall bit rate and the difference in x264 versions is a minor one. I'm still baffled o.O
Because it's more than just x264 settings that factor size. You can't see what filtering was applied via mediainfo, and for example, if one opted to denoise more, it could come out much smaller. Not saying that is the case here, just pointing out that x264 aren't the only thing that'll determine final size. Another thing the mediainfo isn't showing there is what bitrates the audio was encoded at. Although the qcomp setting does differ between the two, which also attributes to the differences. Different x264 versions as well was used.
Both files are 720p, 10-bit, MKV, AVC, AAC, 2Ch with the same FPS and many other settings, so Why the one with CRF=15.6 is about 30% smaller than the one with CRF=16??!! It becomes more surprising considering the fact that chroma subsampling of the smaller file is 4:4:4 while the other has the routine 4:2:0.
How long do encrypted download links stay up for (ex. when would encrypted downloads for 2015/16 series be removed)?
Comment in Feedback 13/01/2017 03:19 — Anonymous: "Anonymursss"
Yep, only in a medium like anime would you get that sort of shit. I get the feeling that the person you quoted is utterly ignorant and comdemning of others. Anyway, there's no possibility to push forward a dead torrent here. Try finding a different source and post it here again.
What, why would you even want to watch an anime like that? I mean, their breast could make twist and is the size of a giant pie, its practically like a hentai too! It definitely deserved the title of one of the most gross and disgusting anime of all time.
SF (SolidFiles) is not https. UptoBox, 1Fishier and CnU are, but 1Fisher is on it's last legs and no CnU links here for a long time.
Encryption is fine, but what you should really be wondering is whether download sites like SolidFiles delete their logs frequently, if you're looking for something to worry about. Because they have your IP and know what you've downloaded.
Everyday more and more websites embrace HTTPS and make themselves, and the Web as a whole, more secure. Just in the past few months many sites have implemented encryption on their communication with visitors and users. It's great to see more file hosting sites have started to go HTTPS, from SF, 1Fishier and CnU to UptoBox and ... And it's great to visit Anime Tosho in HTTPS :)
Almost a week ago this was posted on nyaa. When the page was opened it still said "torrent is still being processed - not all files may be displayed." Checked it again but still nothing. Went to nyaa to check on torrent. A blank page loaded stating "The torrent you are looking for does not appear to be in the database." Link: https://animetosho.org/view/fairy-tail...ed.n886224 Source Link:
Are there ISP, that block typical 1-click-hosters, and if so, are users of AT faced with this problem? I've never noticed such statements here in the feedback forum so far.
I also don't see much need for such a short term storage/ddl solution. Within the first two weeks there are typically links of all currently supported hosters active.
Just a suggestion, instead of storing file in long term, how about making the direct link appear as soon as torrent processed? Just like yukinoshita site but only stored for 2weeks before auto deleted
){kind=link}
25/01/2017 17:57 — naramaki