Write basics of x264 guide #41
Conversation
|
I just saw that #38 exists, but fortunately it looks like there's not much overlap at the moment, as mine is a very intro-level guide. Going through each of the x264 options is what I intended to do for the Advanced section. @PWINNER if you don't mind, I'd like to use your branch as a starting point for the Advanced section, but wanted to communicate first so there's no duplicate work going on (if you're still actively working on it). |
|
Great! I'm considering the easy mode too. I'll keep pushing forward my part. |
There was a problem hiding this comment.
Thanks for the addition. This does has considerable overlap with #38, but I'm sure we'll be able to work it out. Fortunately there are no conflicts because it's in a different file.
I left some notes regarding formatting and correctness. The formatting notes with general advice (like code blocks) of course also apply to other locations.
|
How general are the concepts of 1-pass, 2-pass and CRF encoding? If they apply to many codecs (and I think they do), we might better move this to a the general encoding page and explain these concepts with the example of x264. This page generally reads more like a guide than a reference, which I definitely like, but this might not be the correct page for it. You don't have to address this point within this PR, as I can work on how I imagine it later, but I'd like to talk about it first and hear some input. |
There's QP, CQP, CRF, VBR, CBR in these codecs. I think they're a better start point than 1-pass, 2-pass, etc. Shall we introduce them first? |
|
I agree, I think it makes sense to have an overview of the general concepts in the top level Codecs page, and guides/implementation details on the specific codec page (e.g. this one). So there's definitely some room to split up the 1-pass, 2-pass, and CRF sections into the main page. |
encoding/codecs/h264.md
Outdated
| - CRF 13: This is considered visually lossless to videophiles. | ||
| This can produce rather large files, | ||
| but is a good choice if you want high quality videos. | ||
| Fansubbing groups often use this for Blu-ray encodes. | ||
| - CRF 16-18: This is considered visually lossless to most viewers, | ||
| and leans toward high quality while still providing a reasonable filesize. | ||
| This is a typical range for fansub encodes. | ||
| - CRF 21-24: This provides a good balance between quality and filesize. | ||
| Some quality loss becomes visible, but this is generally a good choice | ||
| where filesize becomes a concern, such as for videos viewed over the internet. | ||
| - CRF 26-30: This prioritizes filesize, and quality loss becomes more obvious. | ||
| It is generally not recommended to go higher than CRF 30 in any real-world | ||
| encoding scenario, unless you want your videos to look like they were made | ||
| for dial-up. |
There was a problem hiding this comment.
What feels odd about this section is that the ranges aren’t continuous. What about the range between 13 and 16? 19 and 20? Bluray encodes often are in the range 13-15, so you could just extend these ranges a little to not leave any gaps.
There was a problem hiding this comment.
I considered this too, but decided the reader should be smart enough to recognize that anything outside the regions specified is either, well, not in any of these regions or only for special occasions. It's hard enough to define definite regions for CRF as is already, so leaving a few gaps leaves more room for interpretation.
Now, what we should mention is that CRF is slightly dependant on resolution, or rather what videophiles generally consider as transparent or acceptable.
| ``` | ||
| 4.7GiB * 1024MiB/GiB = 4812.8MiB | ||
| 4812.8MiB * 1024KiB/MiB = 4928307.2KiB | ||
| 4928307.2KiB * 8Kbits/KiB = 39426457.6Kbits | ||
| ``` | ||
|
|
||
| Now we divide the kilobit size we calculated by our video length, | ||
| to find our kilobit per second target bitrate: | ||
|
|
||
| ``` | ||
| 39426457.6Kbits / 7200 seconds = 5475 Kbps | ||
| ``` |
There was a problem hiding this comment.
We have the option of changing this math to render with TeX (which also might come in handy on other pages where math has been put in codeblocks or in-line currently) with the katex gitbook plug-in. Here's what the changes would look like (and the rendering works with the current text/theme options we give the user).
Currently:
With katex:
I know @FichteFoll has mentioned concerns about adding more plug-ins to the book, so I'll ask for their feedback on this.
With the current 12 plug-ins, initial generation: finished with success in 2.0s
"" on file-changed restart: finished with success in 1.7s
With katex, initial generation: finished with success in 2.5s
"" on file-changed restart: finished with success in 1.9s
There was a problem hiding this comment.
I love LateX. Let's do this! Thanks for taking the time to look into (as I considered suggesting this as well but due to being relatively short on time I didn't want to commit to it).
| The full list of presets, from fastest to slowest, is: | ||
|
|
||
| 1. ultrafast | ||
| 1. superfast | ||
| 1. veryfast | ||
| 1. faster | ||
| 1. fast | ||
| 1. medium | ||
| 1. slow | ||
| 1. slower | ||
| 1. veryslow | ||
| 1. placebo |
There was a problem hiding this comment.
This numbering is actually okay because it wraps this in an <ol> HTML tag, so the numbers here don't matter.
There was a problem hiding this comment.
Yeah, this is the standard way of doing ordered lists in markdown. It makes it easier to add/remove items in the future (though that probably won't happen in this case).
There was a problem hiding this comment.
I should probably update this on the contributing page, since this is much easier and cleaner looking 👍 .
There was a problem hiding this comment.
Good idea. I didn't check whether we mention this already, but I use this style in a couple other documentation projects. (Just like semantic line feeds, and I think everyone should use those!)
|
This PR is a prime example of how I imagine this collaborative effort to work. 👍 Thanks for the help on this, everyone, and of course @shssoichiro. I'm satisfied with this as is and am going to merge now. @OrangeChannel, please do the katex integration in a separate PR. You can add a sentence or two regarding ordered lists on the master branch directly. |
FichteFoll
changed the title
6 participants
No description provided.