2011-08-22, 13:28 | Link #981 | |
Team Spice and Wolf UK
Join Date: Feb 2010
Location: England
Age: 36
|
Hi guys,
Sorry to derail slightly from the current argument on 10bit encodes, but any comments appreciated: Atm, I'm in the process of converting my BDs down to H264 in MKV to store on my different bits and pieces. I'm typically ripping a raw copy of the videos with MakeMKV, re-encoding the video seperately, and then either remuxing in the original audio, or reencoding that if it saves a decent amount of space (ie THD to FLAC if it affords a decent space saving although seems more noticeable on DTS-MA), with the aim of producing a 'close to lossless' copy, rather than keeping the original raw file as...well it's pretty inefficient, and I can't really justify a 23GB raw rip, when a 5-7GB file may as well do the trick almost identically. Now, I'm not much of an encoder and the reams of configureable options goes a little over my head at times, so I'm using Ripbot, or occasionally Handbrake if Ripbot doesnt do the job properly, and trying to adopt a basic 'one shoe size fits all policy' for the encodes so as to save me having to produce multiple encodes each time and choosing the one I like the best. Looking through the file descriptions of a few groups I've never had any real issues with the PQ from, I've adjusted the default CRF down to 16.5, which mirrors the worst case scenario with these groups (which typically seems to be somewhere between 16.5 and 18 dependant on source, although one of them estimates the rough CRF and actually does 2 pass) and also fits inside the "CRF16-18 for virtually lossless" suggestion/rule I've seen in multiple different places. Beyond this I'm typically using Ripbot's HD Progressive profile, at CF16.5. On the last encode I did, throwing it into MediaInfo tells me it's used these x264 encode settings: Quote:
If anyone does have any criticism, as best as you can, could you possibly put a short explanation of *why*, as I'd like to learn why it's a mistake Thanks! ********* On the subject of 10bit, it seems a bit of a double edged sword, I can clearly see the benefit it brings, but the loss of ability to playback the files in anything except software decoding mode (on current hardware) is a real shame. They're not as flexible, but with the power/heat/space savings that can be gained with hardware decoding, you can see why a lot of people are happier to stick with 8bit right now, especially as the whole hi10 scene has only recently been incorporated into the likes of CCCP.
__________________
|
|
2011-08-22, 19:45 | Link #982 | |
Excessively jovial fellow
Join Date: Dec 2005
Location: ISDB-T
Age: 37
|
Quote:
__________________
|
|
2011-08-23, 11:10 | Link #983 |
Team Spice and Wolf UK
Join Date: Feb 2010
Location: England
Age: 36
|
Hahah, I may get nerdy/OCD at points, but usually not about x264 encoding.
I'm presuming you can't see any obvious 'wtf?!' problem's with Ripbot's H264 HD preset then, thanks a lot for the feedback
__________________
|
2011-08-23, 11:30 | Link #985 | |
Team Spice and Wolf UK
Join Date: Feb 2010
Location: England
Age: 36
|
I'll be honest and say I've not got a clue what ripbot based the preset profiles on originally!
Looking into what it's profile entails, Ripbot says it's using these settings for the profile (obviously with your chosen CRF value) Quote:
Edit: Looking up the x264 various wikis, I'm presuming based on the Wiki, for my purposes of archiving (although not 1:1) without 100% focus on filesize, I'd be best to look at the "medium, slow, slower, veryslow, placebo" set of presets, perhaps with the --animation tag applied? Command line something along the lines of "\x264_x64.exe --preset slow --tune animation --crf 16.5 -o <output file.h264/mkv> <input file>" Perhaps with a --level 4.1 flag as well? Doing this with a 256MB test file, once it'd been remuxed on the other side ended up with an output file of circa 88MB which is a pretty decent reduction, by contrast Ripbot's output was larger at about 113MB, with a higher bitrate. Now I'm not entirely sure if thats waste or going to any use! Cheers for the assistance, Fluff, I figured it'd be best to ask about this sort of stuff, than sit there and either do something extremely stupid or realise after spending ages re-encoding a load of bits that the way it was done didn't quite cut the mustard, I've not got a bad system but this still takes a while hehe
__________________
Last edited by tyranuus; 2011-08-23 at 15:00. |
|
2011-08-23, 15:03 | Link #986 |
Excessively jovial fellow
Join Date: Dec 2005
Location: ISDB-T
Age: 37
|
Ripbot's line has a number of weirdnesses in it and you're a lot better off with --preset slow --tune animation. If you want a smaller file, use a slower preset (or a higher CRF value). The --level flag is pure metadata and is only relevant if you use a hardware accelerated decoder that respects it. If you do not set it, x264 will set it for you automatically.
__________________
|
2011-08-23, 15:21 | Link #987 |
Team Spice and Wolf UK
Join Date: Feb 2010
Location: England
Age: 36
|
Not sure why but 'words' as the quote made me laugh, guess I'm too used too seeing 'snip', 'blah blah blah', 'stuff which need not be repeated'...anyhoo heh
In your experience I take it you'd say then that the extra bitrate average using that Ripbot profile is being wasted then? File size isn't a real issue for me, I'm more interested in getting decent output, so I don't mind higher bitrate if it's actually getting results, but if its being wasted... I'll probably leave the level tags in, for the simple reason that, like you imply, it might give slightly better compatibility with hardware devices and x264 is also re-encoding at a higher FPS when set to 4.1 than 5/5.1, presumably because it's using fewer ref frames and are also seemingly slightly lesser compression. I'd also thought that the different presets ie slow, slower etc were do with output quality rather than compression so again thanks for that heads up. Again thanks a lot for the advice, if you use paypal PM me and I'd be happy to lob you over a little for a few brews on Thursday (payday) for the help
__________________
|
2011-08-23, 16:58 | Link #988 |
C
Join Date: Oct 2010
|
You may seriously want to look at:
http://forum.doom9.org/showthread.ph...00#post1020500 http://akuvian.org/src/x264/ratecontrol.txt On the other hand, I would suuggest using --b-adapt 2, because it"s a better algorithm that allows to use bframes more efficiently. And I might add: don't use VBV unless you really need it, it's disable by default for a reason. Finally, you may consider using x264 directly and not relying on any GUI, you can write a simple *.bat file to make profiles, you just need to change the output and input names. |
2011-08-23, 17:05 | Link #989 |
Team Spice and Wolf UK
Join Date: Feb 2010
Location: England
Age: 36
|
I've been testing with x264 directly this evening rather than through any GUI following Fluff's previous recommendations, playing around with the presets primarily, along with --tune animation, and --b-adapt2 seems to be included by default in the slow/slower preset, I'm also pretty much doing what you've suggested, although with shortcuts rather than .bat files, although thanks for the links, will take a look
Atm I'm more or less settled with --preset slower --tune animation --level 4.1 --crf 16.5, outputting to an MKV container rather than directly to a .264 file as it means I can open it directly with MPCHC just to check the output quickly before remuxing the files. The 2 minute test file I've been using to play around with ends up at 84.9MB via x264 direct based on the above, once I've remuxed the sub and audio tracks back in from the source file, whereas the equivalent file remuxed with the output from ripbot was ending up as 113MB, so doing it this way definately seems more space efficient, although I'm not 100% sure whether it was a case of Ripbot's profile throwing bitrate at unoptimised settings or whether its tailored for a certain scenario, unfortunately over the last year or two I kept forgetting to register at Doom9 and it's got a hefty 5 day wait period before I can even consider asking Ripbot's author about his choices. One idiosyncracy I've noticed is that mediainfo seems to pickup my raw output as (incorrectly) about 1.2fps. Once I've muxed the audio back in however this resolves, bit strange but at least it's not affecting the files, although I do need to try reencoding the original audio stream before muxing this back in, and ensuring that it still works fine with 2 fresh source files, rather than the original components bar the video.
__________________
Last edited by tyranuus; 2011-08-23 at 17:17. |
2011-08-23, 18:00 | Link #990 | |||
Excessively jovial fellow
Join Date: Dec 2005
Location: ISDB-T
Age: 37
|
Quote:
Quote:
Quote:
Also, increasing the number of refs and b-frames can have drastic effects on compression efficiency of animated material, so that probably explains most of the size difference.
__________________
|
|||
2011-08-23, 23:44 | Link #991 |
Senior Member
Join Date: May 2006
Location: California
|
Unless you actually have something VFR, you should just specify
Edit: I forgot that x264 had a --force-cfr switch, so you can used that instead of specifying a --fps if you want non-VFR output. I wouldn't be surprised if the bug in MediaInfo is caused by a VFR bug in the Haali Muxer. Normally with MediaInfo would show Variable w/ no fps for VFR mkvs without a default duration, but it's instead showing Constant w/ 1.199fps. Either way, the files should still be decoded correctly, since the timecodes are present (though rounded to the nearest integer).
__________________
Last edited by cyberbeing; 2011-08-25 at 08:26. |
2011-08-24, 01:57 | Link #992 |
Team Spice and Wolf UK
Join Date: Feb 2010
Location: England
Age: 36
|
Thanks again, I did notice the 5.0/5.1 tests typically used 8/10 whereas the 4.1 only used 4, and Ripbot's only had 3, so I suspected this might have something to do with it.
One thing I've noticed is that dark scenes seem to show slightly more prevalent blocking under close inspection (possibly being anal but figure I might as well get it done right the first time); now I need to examine the video with a better screen as the one I'm writing this on doesn't really have a great colour depth and it could be an issue just being exacerbated by the screen dithering thats not really noticeable normally, as even the original BD rip shows it to a lesser degree, but I'm guessing that upping/reducing the CRF as needed, dependant on the point of view would be the best way of dealing with this, rather than reducing the preset speed? Ie CRF 16.5-->15, rather than slower preset ---> veryslow @cyberbeing - thanks for the tip on specifying the framerate, to prevent a bug in MKV output. Does it do the same if you just output to .264? I'd only been using MKV output as it saved me a little time remuxing before checking a video. If it doesn't I'll just alter my output by taking the .mkv specifier off the end, which I believe means it SHOULD save it as .264 (if you don't specify the file type - or am I wrong here too?) Aka -o D:\WIP\Test instead of -o D:\WIP\Test.mkv or do I actually need to put .264 on the end?
__________________
Last edited by tyranuus; 2011-08-24 at 02:19. |
2011-08-24, 08:43 | Link #993 |
Senior Member
Fansubber
|
I wouldn't recommend using --tune animation for anime sources unless you override its aq-strength and psy-rd settings. It sets those two really low, which will cause much more banding and blocking in flat areas (such as low contrast areas in dark scenes) than the default values. I tend to use --aq-strength 1.0 (which is the default) and --psy-rd 0.8:0.1 (default is 1.0:0.0) for most anime, at least when encoding in 8-bit. Higher aq and psy will use more bitrate, but they'll probably be more efficient than just lowering crf.
|
2011-08-24, 11:42 | Link #994 |
Team Spice and Wolf UK
Join Date: Feb 2010
Location: England
Age: 36
|
Cheers Desbreko, that might explain what I was noticing more obvious blocking in the dark scene, that's certainly worth bearing in mind if it'd resolve the issue as much as a lower CRF, but remain more efficient. Also, I guess if x264 is limiting the ref frames to 4 with level 4.1 there's not much benefit in the animation tag, if as Fluff says, it's main benefit is doubling the ref frames.
So in this case, do you believe it'd be better to use: --preset slower --tune animation --level 4.1 --crf 16.5 --fps 24000/1001 --aq-strength 1.0 --psy-rd 0.8:0.1 -o <output.mkv> <input> --preset slower--level 4.1 --crf 16.5 --fps 24000/1001 --aq-strength 1.0 --psy-rd 0.8:0.1 -o <output.mkv> <input> OR --preset slower --level 4.1 --crf 16.5 --fps 24000/1001 <output.mkv> <input> Thanks all for the help!
__________________
Last edited by tyranuus; 2011-08-24 at 13:34. |
2011-08-24, 18:49 | Link #995 |
Try me! <3
Join Date: Apr 2011
Location: Germany
Age: 40
|
I've now worked my way through the descriptions for all the x264 settings and created a preset file for use with Avidemux
You can take a look at it here: http://www.megaupload.com/?d=VPAI5UBT Just load the preset in Avidemux and tell me what you think.
__________________
|
2011-08-24, 21:46 | Link #996 | |
Senior Member
Fansubber
|
Quote:
You don't need to set aq-strength if you're not using --tune animation, though, since 1.0 is the default. |
|
2011-08-25, 04:59 | Link #997 |
Team Spice and Wolf UK
Join Date: Feb 2010
Location: England
Age: 36
|
Cheers Desbreko, so presuming I'm understanding correctly both:
--preset slower --tune animation --level 4.1 --crf 16.5 --fps 24000/1001 --aq-strength 1.0 --psy-rd 0.8:0.1 --preset slower--level 4.1 --crf 16.5 --fps 24000/1001 --bframes 5 --psy-rd 0.8:0.1 Should basically produce identical output; thanks a lot for the tips on the AQ/Psy-rd, as I'd probably have ended up just dropping the CRF to 15 or something, which like you say probably wouldn't have been the most efficient option. I'll do some reencodes based on the above, and hopefully that'll clear up the blockiness in darkness; I don't mind the extra bitrate at all @Pantsu, I'm no expert so couldn't give you much feedback, however I noticed you opted for QP when I took a peek at the XML (as I don't use Avidemux) How much difference QP makes over CRF I don't know,but the reason I opted for CRF is I'm constantly seeing it recommended all over the place as achieving better file sizes at equivalent picture quality. Example (3rd post): http://forum.doom9.org/archive/index.php/t-107687.html Typically, for small but decent picture quality encodes I've repeatedly seen the CRF 19-24 range recommended, for higher quality, more-or-less lossless I have seen 16-18 being the recommended region. I based my choice of 16.5 on both the fact I wanted to be in the 'no obvious quality loss' space [16-18], and also by averaging out and comparing some releases from fansub groups who's releases I've enjoyed and not had any picture foibles with (which typically ranged between 16.5-19 with occasional flex on either side). As I've discovered myself though, some of the other tags you use/don't use during the encode can also make a difference to the picture quality
__________________
Last edited by tyranuus; 2011-08-25 at 05:53. |
2011-08-25, 08:34 | Link #998 |
Senior Member
Join Date: May 2006
Location: California
|
I had a brainfart earlier. Since you are going for one-size-fits-all, it may be better to use --force-cfr instead of --fps, so you don't accidentally encode something at the wrong frame-rate by mistake.
__________________
|
2011-08-25, 14:14 | Link #999 | |
Senior Member
Fansubber
Join Date: May 2010
Location: Spain
Age: 33
|
Quote:
|
|
2011-08-25, 18:45 | Link #1000 | |
Team Spice and Wolf UK
Join Date: Feb 2010
Location: England
Age: 36
|
Quote:
Thanks again.
__________________
|
|
Thread Tools | |
|
|