[This is a continuation of the statement started in the previous post]
Quote:
|
Originally Posted by DeathTheSheep
<> For deblocking strength, try not go out of bounds of the -3 to 3 range. Generally, any more than 3 will turn your result into mush while decreasing PSNR and actually increasing the output file slightly. Any less than -3 may cause the result to look a bit too blocky and any lack of texture will merely become more apparent as all smoothing is taken out.
|
bond: positive values of loop will tend to remove details -> smaller filesize
(akupenguin [to bond’s statement]: Not necessarily.)
DTS: It is not safe to conclude this. If your statement is true, then I assume that at a fixed quantizer (and therefore with uniform quality throughout), filesize will decrease if loop filter is more heavily applied. Take a look at these sample encodings, where any difference is clearly discernable. I disabled B-frames, but all other settings are default (and quantizer = 30). You see, this statement is simply not true for most cases, and like akupenguin said, “you can’t deduce the global effect from the definition.”
Strength= 0;
http://www.thefilehut.com/userfiles/...x/deblock0.avi
Strength=-6;
http://www.thefilehut.com/userfiles/.../deblock-6.avi
Strength= 6;
http://www.thefilehut.com/userfiles/...x/deblock6.avi
And here are some 2-pass samples, which show such a phenomenon less, due to the fact that they are the same size because of the nature of 2-pass mode (but PSNR was lower for the -6 and 6 deblocked clips, as I predicted). In part due to the ultra, ultra low bitrate (unfortunately, I don’t have my own dsl line with which I can upload large files), and in part due to the animated nature of my content (I have qualms about uploading parts of Hollywood movies), the subjective quality stays about the same for the DB: 0 and DB: 6 encodes, but as the bitrate gets higher, difference is more capable of being clearly differentiated—the highly deblocked tends to wash too much detail.
http://www.thefilehut.com/userfiles/...ockX_2pass.avi (replace the X with 0, 6, or -6).
All in all, though, it appears as if increasing or decreasing deblocking intensity by too far a margin will hurt both quality and filesize, as I clearly stated in my guide.
Quote:
|
Originally Posted by DeathTheSheep
Present in certain AVC encoders, this is a method of lumi (+chroma) masking in which very light or dark areas of a scene are encoded in terrible quality, which gives more bitrate to the rest of the video.
|
bond: i wouldnt talk about "terrible quality" here, as the point here is to encode with lower bitrate where the eye cant see the difference anyways, so for the eye the quality will stay the same
DTS: It is true that I have seen fairly prominent flaws in low-lighted content not present in identical encodes with psychovisual enhancements disabled. Nevertheless, I was speaking of “quality” in terms of bitrate allocation; that is, how accurately dark areas are encoded. If I’d have said “visual quality,” I would be implying otherwise. Nevertheless, I can see your point, and I shall clear this up in my next version of the guide (let’s call the next version a “beta.”)
As to another issue relating to psychovisual enhancements, I’d like to make it clear that I am not a developer of NeroDigital AVC, and do not know what each psychovisual enhancement does internally, but I can be sure that the test results I have attained with ND AVC in very dark (dungeon) sources are of noticeably less visual quality than without psychovisual enhancements (most notably in textured areas), and it was indeed “noticeable.” If you insist, you may test this for yourself on a very dark source and see for yourself. This is most relevant at higher bitrates (so I can’t upload an indicative source).
Quote:
|
Originally Posted by DeathTheSheep
<> B-frame reduction (if you choose to use B-frames) should be adjusted according to the desired datarate. For most DVD backups, the default B-frame reduction of 30% seems to be sufficient. However, with certain animated medium bitrate content, I suggest use of up to 50% B-frame reduction.
|
Quote:
|
Originally Posted by DeathTheSheep
<> Personally, I find that the keyframe threshold of 45% and keyframe QP boost: 20 to be the optimal in achieving quality at medium bitrates. However, if you wish to produce Ultra-Low-Bitrate video (DVD backups less than one CD), consider reducing this to 0, for your video's quality (PSNR) per BM will increase.
|
Quote:
|
Originally Posted by DeathTheSheep
<> In maximum-quality content, I find that the keyframe threshold of 35% and keyframe QP boost of either: 30 or 0 to be the optimal in achieving quality at medium-high bitrates in my "maximum possible quality" mode.
|
bond: where do these values come from? any screenshots? again my request for samples that show that x264s defaults perform worse than with your proposal
DTS: First and foremost, I’d like to clear up one massive point of obvious confusion: The above values, as were the constant values attained elsewhere in my guide, came to be as a combined result of my own empirical testing and material observation of visual results. The “evidence” is also within the results of this method.
Indeed, If you disagree with the guide without even attempting to try it, you cannot be certain of its fallacious nature. Remember, this is a
guide (and one in “pre-alpha” stage at that), and as such, it deserves to be treated as one; give it a chance first and
then compare the results to those of any other method you choose. Recall the fact that it is, at this point,
you contesting
me, or more correctly, the aforementioned results. However, I’m not about to argue with speculation-- speculation is easy and fun, isn’t it?—but rather, if the results I consistently achieve are in question, it is the duty of the challenger to provide counterevidence, which will indeed be addressed. In the case that you may have pondered the reason for my frequent requests for more forum space (or an alleviation of the 16k character limit), it was to provide extended services such as screenshots, a better graphic scheme, and more information—some of which, perhaps, serving to justify my conclusions. (Perhaps if you had read the entire thread, you might have come to this realization.)
------- M Y -------
C O N C E S S I O N
-------------------
I make the following statements to admit errors on my part.
Quote:
|
Originally Posted by DeathTheSheep
The bitrate variability feature controls how much your datarate can fluxuate at any given time. That is, if you plan on encoding at 500kbps and set this value to 40, the maximum amount of bitrate given to more complex scenes is 700kbps.
|
akupenguin: No. See some explanations I gave to Chen.
DTS: I am not a developer, so I apologize for the misinformation regarding the internal workings of this tool. However, if the bitrate variability tool does not work as I have so erroneously stated, it still controls the amount by which the video stream fluctuates by means of it controlling QP curve compression, right?
Again I apologize, but I don’t really know who “Chen” is, much less where the aforementioned explanations were given. Any assistance?
Quote:
|
Originally Posted by DeathTheSheep
To stream x264 video, you need to have a player capable of handling streaming; nearly all players I can think of at the moment support this. I suggest using Media Player Classic, but Windows Media Player 9/10 works just as well for many people as long as the ffdshow decoder is installed. Make sure to configure the player to automatically start a stream with the desired file extension (the most commonly made x264 files use the ".avi" extension).
|
bond: you are sure that dshow players will be able to play streamed h.264 .avi files? somehow i cant believe this. do you have a sample stream link i can try?
DTS: I understand your confusion. In fact, the wording wasn’t clear here in my guide. When I mention “desired file extension,” I’m not referring explicitly to .avi. On the contrary, I am referring to any format capable of streaming media, such as .asf or mp4, if you so choose. I also point out that the .avi file extension is most commonly used for the storage of x264 files, implying that at least a container switch could be in order if streaming is desired. I agree, though, that perhaps a bit more than the wording is unclear, and I apologize. Perhaps if I had more room, I could elaborate, but I will nevertheless either change the guide’s final wording or remove the streaming section entirely (but leave the streaming settings). However, it does appear as if I was mistaken about ffdshow being able to play streaming H.264 content as of yet; in fact, only with certain codecs was I able to attain streaming capability in WMP. Indeed, I should have stated that a streaming-enabled decoder is necessary, but I erroneously assumed the new versions of ffdshow could handle such content. I apologize; I’m clearly not an expert at making streams (do I have my own streaming server?), but my guide is intended for high-quality AVC settings, not a streaming how-to. Here is a sample asf stream attained using the beta ASF muxer.
http://www.thefilehut.com/userfiles/...x/trythis2.asf
Perhaps the Moonlight H.264 Decoder & Streaming Pack could be of use in this situation, in which case it would supposedly be able to stream certain AVC-MP4 streams.
Quote:
|
Originally Posted by DeathTheSheep
If a certain frame's reference is far off into the file, the entire file becomes unplayable until the video is downloaded up to that reference.
|
akupenguin: No, multiple references have no effect on seekability. (BTW, they also have no effect on AVI compatibility.) All reference frames would have to decoded anyway, because they're between the current frame and the previous keyframe...
DTS: You are absolutely correct, and I was absolutely (and rather foolishly) mistaken. I assumed (see, there’s the mistake) that somehow reference frames had an impact on streaming x264. I therefore assumed (there we go again...) that there must have been some sort of “backwards referencing” going on, which, looking back on it, now strikes me as preposterous. The reason I made these assumptions was that I could find so very little streaming x264 content online to perform comprehensive testing on. It was an imprudent decision to put any sort of streaming directions in my guide, for as I said above, my guide is intended for high-quality AVC
settings advice, not a streaming how-to.
-----------
Final Words
-----------
By placing this preliminary version of a guide in a forum, I was obviously asking for responses and input, and I am thankful for all you have given me. Indeed, I greatly appreciate what I have learned and what the community has learned in the process. And this learning, I might add, will not be wasted on me, for I will release a so-called “beta” version of my highly updated and expanded guide in due time.
However, I can’t shake the feeling that there was some sort of negative connotation in your post, bond, based on the way you posed some of your questions. True, we all do different tests, and we can all make mistakes, and I’m sure you realize this too. We simply have to learn from them and grow. It never hurts to expand your knowledge-- my own, for my part. I thank you for being part of my own betterment in addition to part of your own, and I wish the rest of the community luck in utilizing this guide to its full potential.
I look forward to more comments and suggestions; after all, this is your guide, too!
DTS