Welcome to Doom9's Forum, THE in-place to be for everyone interested in DVD conversion. Before you start posting please read the forum rules. By posting to this forum you agree to abide by the rules. |
15th August 2005, 14:54 | #21 | Link |
Mr. Sandman
Join Date: Sep 2003
Location: Haddonfield, IL
Posts: 11,768
|
added Death The Sheep guide (link to this thread) to x264 builds sticky.
__________________
MPEG-4 ASP Custom Matrices: EQM V1(old), EQM AutoGK Sharpmatrix (aka EQM V2), EQM V3HR (updated 01/10/2004), EQM V3LR, EQM V3ULR (updated 04/02/2005), EQM V3UHR (updated 17/12/2004) and EQM V3EHR (updated 05/10/2004) Info about my ASP matrices. MPEG-4 AVC Custom Matrices: EQM AVC-HR Info about my AVC matrices My x264 builds. Mooo!!! |
15th August 2005, 17:40 | #22 | Link |
<The VFW Sheep of Death>
Join Date: Dec 2004
Location: Deathly pasture of VFW
Posts: 1,149
|
I saw the doom9 guide section and couldn't help but wonder: how could I go about submitting this guide to the main Doom9 site? If I did that, I would have more space, a cleaner layout, and room to put in screenshots! How's that for a high-quality space for a high-quality guide?
__________________
Recommended all-in-one stop for x264/GCC needs on Windows: Komisar x264 builds! Last edited by DeathTheSheep; 16th August 2005 at 02:30. |
17th August 2005, 19:34 | #23 | Link | |
Registered User
Join Date: Jan 2002
Posts: 112
|
Bitrate Variance Question
Quote:
I may have misunderstood two of the x264 parameters (ratetol and qcomp) but I believe qcomp is responsible for deciding how much more high motion scenes are compressed (aka lower bitrate) than static scenes. I think ratetol is an additional constraint on how much you allow qcomp to do its job. I believe that ratetol is the appropriate parameter to set/modify if you have streaming or hardware playback concerns. However, the low/high motion compensation that you are describing in the above quoted text would, I believe, be more appropriately handled by adjustments to qcomp in conjunction with a sufficiently permissive ratetol. I am a little confused why ratetol defaults so low. I would think you would want to default it as high as possible, and then adjust qcomp for motion compensation issues. Anyway, just my perhaps misguided thoughts. |
|
18th August 2005, 16:50 | #24 | Link | ||
<The VFW Sheep of Death>
Join Date: Dec 2004
Location: Deathly pasture of VFW
Posts: 1,149
|
Qcomp, in a quite literal sense, is a form of Bitrate Variability--actually, it was simply renamed in the VFW and multiplied by 100 for integer simplicity.
The "ratetol" parameter, as you mentioned, controls the amount of bitrate explicitly awarded to the video, in turn effecting the quantizers used on it. It does so as part of a bitrate regulation -- to ensure that the content reaches a certain bitrate without fluxuation. Quote:
For this "fluxuation insurance," high-motion scenes would obviously require a higher quantizer than do still scenes in order to maintain a certain steady bitrate. However, qcomp directly controls these quantizers (A quantizer curve compression, or quantizer regulation), which in turn impacts the bitrate, serving either to give it absolute stability (0) or allow infinite fluxuation (1) based on what quantizers are used on each frame in the video. Control diagram: <> qcomp -> quantizers -> bitrate variability <> ratetol -> bitrate variability -> quantizers Quote:
It is therefore safe to assume that with Qcomp in play, ratetol serves as a sort of "peak cutoff," allowing the video to conform to the quantizer specifications in qcomp so long as they don't exceed the bounds specified in ratetol. Yes, ratetol would be an excellent parameter to set when encoding streaming content (if using the cli, of course), because of these solid bounds. Their purposes seem to check and balance one another and provide more explicit control.
__________________
Recommended all-in-one stop for x264/GCC needs on Windows: Komisar x264 builds! Last edited by DeathTheSheep; 18th August 2005 at 16:54. |
||
23rd August 2005, 18:28 | #26 | Link |
<The VFW Sheep of Death>
Join Date: Dec 2004
Location: Deathly pasture of VFW
Posts: 1,149
|
Merely the high profile transform. I apologize for any inconvenience.
Yours, DTS
__________________
Recommended all-in-one stop for x264/GCC needs on Windows: Komisar x264 builds! |
27th August 2005, 20:34 | #27 | Link |
Registered User
Join Date: Sep 2004
Location: Near LA, California, USA
Posts: 1,545
|
I have a couple questions that I haven't seen here.
1) What is "B-Frame Bias"? Does this setting determine what direction (Future frames/Past Frames) that a B-Frame takes into account? What kind of sources would this be useful for? 2) Is the "Chroma ME" setting useful for encoding B&W sources? I'm assuming it isn't, but I don't know for sure. Thanks. |
27th August 2005, 22:28 | #28 | Link |
Registered User
Join Date: Feb 2005
Location: São Paulo, Brazil
Posts: 392
|
@revgen:
1) This was called "BVOP Sensitivity" in Xvid. B-frame Bias let you tweak the amount of Bframes the encoder will put in the clip. 0 is the defaut b-frame decision algorithm. A positive value increases the amount of B-frames; a negative value decreases it. It's better you don't touch in that option. Normaly the defauts are always better, unless in a speed by quality trade of. Warning: It isn't the same as max consecutive B-frames. 2) I can't guarantee too... |
27th August 2005, 23:42 | #29 | Link | |||||||||||||||||
Registered User
Join Date: Nov 2001
Posts: 9,770
|
Quote:
why do you think that its a bad idea to trust x264 on deciding what quant to use? any samples which show that x264 does a bad decision on that? Quote:
Quote:
Quote:
Quote:
Quote:
Quote:
Quote:
Quote:
Quote:
Quote:
Quote:
Quote:
Quote:
Quote:
Quote:
Quote:
__________________
Between the weak and the strong one it is the freedom which oppresses and the law that liberates (Jean Jacques Rousseau) I know, that I know nothing (Socrates) MPEG-4 ASP FAQ | AVC/H.264 FAQ | AAC FAQ | MP4 FAQ | MP4Menu stores DVD Menus in MP4 (guide) Ogg Theora | Ogg Vorbis use WM9 today and get Micro$oft controlling the A/V market tomorrow for free |
|||||||||||||||||
29th August 2005, 16:15 | #31 | Link | ||||
x264 developer
Join Date: Sep 2004
Posts: 2,392
|
Quote:
Quote:
Quote:
Quote:
I'm not saying that the net effect is to increase size at a given QP (I don't know offhand; all of my loopfilter comparisons were 2pass, because it's the only fair way), just that you can't deduce the global effect from the definition of loopfilter. |
||||
29th August 2005, 21:13 | #32 | Link | ||||||
Angel of Night
Join Date: Nov 2004
Location: Tangled in the silks
Posts: 9,559
|
Quote:
Quote:
Quote:
|
||||||
3rd September 2005, 00:28 | #33 | Link | ||||||||||
<The VFW Sheep of Death>
Join Date: Dec 2004
Location: Deathly pasture of VFW
Posts: 1,149
|
The Response
Bond:
As a renowned doom9 moderator with 5.7 thousand posts, your scrutiny is indeed commendable, justifying this vast post number while casting my rather insignificant 250 forum contributions into the realms of near-obscurity. To Whom It May Concern: Such a large number of doubts, questions, and concerns will not go unheeded by me, as I will attempt to explain myself for each of my points. I do this for the sake of both my guide and the doom9 community, which I hope will partake the reaping of its bounty. For the sake of simplicity, I will display the questioned excerpt from my guide and explain myself briefly for each of the points bond (and perhaps other members) brought up about them in preceding posts. ---- M Y ---- D E F E N C E ------------- I make the following statements to justify the content of my guide. Quote:
DTS: However you may have conceived the preposterous notion that I intended to redefine x264’s quantizer utilization mechanism, I assure you, this is not the case at all. As is relatively obvious given the context of this quote, I was discussing the method to achieve high quality video using the “Constant Quality” 1-Pass mode of x264, where the user’s input literally is the codec’s control over the quantization. I also gave examples of when to use this feature. Please, read the guide carefully before jumping to conclusions based on fallacious/preconceived notions. Quote:
IgorC: induction and deduction aren't the same things. Here is a sample stream with “0” input for the number of reference frames: http://www.thefilehut.com/userfiles/xsquaredx/0refs.avi Quote:
DTS: Although I might come off as a bit abrupt on my part, this statement may well prove nothing more than a lack of experience in the ultra low bitrate area on your part. The section of the guide from which the above quote was pulled was from an ultra-low bitrate section. foxyshadis: B-frames help to a certain point, however below a certain framerate & bitrate they lower subjective quality. That section's about ultra-low bitrate streaming encodes, where assumptions from low-to-mid quality encodes don't all hold… A few threads have come up about this. IgorC: induction and deduction aren't the same things. Particular case doesn't define situation in general. DTS: Now, without looking into the matter further, it is not entirely safe to make such assumptions. Consider the following examples of standard, low bitrate, low-framerate content, one with and the other without B-frames. Which looks better to you? Remember, even if it seems that both results look shabby to you, you may not be of the target audience. With: http://www.thefilehut.com/userfiles/...x/bframes1.avi Without: http://www.thefilehut.com/userfiles/...x/bframes0.avi These files were encoded with exactly the same settings (standard settings except for 2 references and 6-RDO refinement). The file with 2 consecutive B-frames is actually larger, and there is much more block noise during movement, and movement isn’t accurate (see how the character’s face looks to be falling off as he walks towards the camera). To further illustrate my point, I will refer you to a certain quote which attempts to explain such a phenomenon: skal: Let's look at 3 frames at ~8fps (the upper ones in the following -ugly- sketch), and watch the coding in progress: Arghh! When the encoder is coding frame P1, look at what he has as reference! It's P0, coded at QP=45. A mere block feast! Question: How do you expect to ME to find a good match between frame P0 and frame P1 ??? The first one is a block soup, but P1 still has lot of details. One could pick any block from the first frame and match it with the third, with a SAD of ~51340986542 (roughly) The motion vector field will be erratic, and the middle b-frame will find it difficult using the mighty BDirect mode (not to mention that it'll be hard to match the frame P0 / P1, too). RadicalEd: [It’s] possible for B frames to increase size indirectly, especially if they're not being overquantized with respect to the Ps. This is because a B frame essentially creates a void in prediction and the next P frame has to jump behind it and use the P (or I) frame before the B to predict from. Therefore P frames get bigger as a result of B frames. This is probably more prominent with anime as well, so maybe that's what sheep is experiencing. Quote:
DTS: At a constant quality quant=30, which I believe is the “fairest” way to test the quality of different settings on a filesize basis (it employs a uniform quality quantization throughout), see the following for yourself. Each having nearly identical quality to the other, which file is smallest? 5 refs http://www.thefilehut.com/userfiles/xsquaredx/5refs.avi 10 refs http://www.thefilehut.com/userfiles/...edx/10refs.avi 16 refs http://www.thefilehut.com/userfiles/...edx/16refs.avi In my guide, I say 5 is the “typically excepted maximum.” But even so, it doesn’t take a leap of imagination to understand that there is a clear 14% filesize decrease between 5 references and 10 references. It isn’t a good idea to generalize on all content based on a single sect of testing; I have done tests with many bitrates and types of content, and there clearly a quality advantage at 10 references (over 5), but no real advantage over 10. My guide’s “absolute maximum” in this section is 8. Quote:
DTS: I apologize, but I cannot take the word of that thread over the testing I have done, which has revealed much evidence to the contrary. Frankly, as IgorC pointed out below: IgorC: Particular case doesn't define situation in general. DTS: My results speak for themselves; I’ve no need to argue with anyone about my own findings. Consider these results at a constant quality of quant=35: Cabac - http://www.thefilehut.com/userfiles/xsquaredx/cabac.avi Cavlc - http://www.thefilehut.com/userfiles/xsquaredx/cavlc.avi Benchmark them with this (ensure you set the screen size to 100%): http://cc.serveftp.org:8884/TCPMP_0.66e_for_Win32.exe The results are clear: with the same exact source and exact same settings, cabac clearly underperforms cavlc in terms of decoding speed with the high-speed, high-quality ffmpeg H.264 decoder. Quote:
DTS: Perhaps you should have looked back upon said remark and the context in which it resided so as to attain a more complete understanding of the properties of such a motion estimation range. For instance, if you had more thoroughly read this thread, you would have found a thread in which I specified results to the contrary: http://forum.doom9.org/showthread.ph...397#post698397 akupenguin: dia and hex cap merange at 16. It slightly reduces code complexity, and if the real mv is more than 16 pixels from the prediction, they won't find it anyway. DTS: Essentially, however, the range 32 uneven multi-hexagon search, because of its nature, would search a more exhaustive area within its range based on the principle that its core is larger, even if it is incapable of predicting past the 16 ME boundary (at which hex is capped). Again, I am not a developer, but I have seen consistent, concrete results using a umh ME range of 32. Quote:
akupenguin: Because at lower framerates, objects have moved farther between consecutive frames. => need to search farther on average to find an object. DTS: This is also true of animated content, which by very definition is “animated;” drawings are typically spaced far enough apart from one another to render a higher ME range beneficial. This is also where B-frame users run into more trouble—due to the discrepancy between certain pairs of frames in low-framerate/animated content, bidirectionally predicted frames may not be able to accurately fill the gap easily, and even so, the subsequent P-frame would have to look 2 frames behind it for prediction (unless B-pyramid is activated). Look above for more information containing some B-frame analysis. My guide, however, states when to employ (or when not to employ) both B-frames and a high ME range, and it does so based on this “rule.” Quote:
DTS: And if you’d read the entire thread, you will see that I acknowledge this, but due to the fact that decoder-side support of this is very limited at the moment (not to mention the lack of the current VFW’s lack of support), I chose to leave this out of my guide. foxyshadis [to bond’s response]: True, but decoders don't. (I think ffdshow's support for it was buggy when I tried last month, and no others worked at all.) DTS [earlier quote in this thread, to CiNcH]: Indeed. This is precisely the reason I left it out of my guide. Quote:
DTS: True, but I still don’t really see much of a problem with my statement; B-pyramid, by very definition, is the usage of B-frames as “references” for following frames. By using B-frames as references, you are, in a sense, adding a type of references to the stream, thereby increasing quality slightly—due both to the fact that more references increase the video quality, and due to the fact that frames following the B-frames can use the B-frame for prediction (therefore, they would serve as references). Remember, I’m not a developer, so I don’t know the internal code, but try the guide—the quality attained using my tested method really speaks for itself. Quote:
DTS: It makes perfect sense. You see, the latest codec at the time of writing (rev. 285) consistently caused crashes for me when too many references were used with B-frame references. Why? I don’t know, but the fact is, the problem persists even today with revision 291 on all of my machines using the newest hardware and software. Whether the cause resides in the input colorspace, the codec’s internals, or a seemingly infinite number of other factors, it still frequently crashes on both of my brand-new computers and many others I know of, giving it my definition of “unstable” and therefore warranting a few words of my caution. It is for this reason that I’ve worded my statement so; perhaps when my guide is read at a later date, this option may have become more stable for all machines (or, at very least, when all major decoder-side components are stable—ffdshow has only begun to become stable for me within the past few months, to say nothing of others). But otherwise, I’d have to say that, yes, it is common knowledge to always use the newest version of a program/codec unless a newer version is known to have introduced sizeable flaws. Therefore, I shall also employ this advice in the upcoming, newer version of my guide. [My statement continues in the following post]
__________________
Recommended all-in-one stop for x264/GCC needs on Windows: Komisar x264 builds! Last edited by DeathTheSheep; 3rd September 2005 at 01:08. |
||||||||||
3rd September 2005, 00:30 | #34 | Link | ||||||||
<The VFW Sheep of Death>
Join Date: Dec 2004
Location: Deathly pasture of VFW
Posts: 1,149
|
[This is a continuation of the statement started in the previous post]
Quote:
(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:
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:
Quote:
Quote:
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:
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:
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:
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
__________________
Recommended all-in-one stop for x264/GCC needs on Windows: Komisar x264 builds! |
||||||||
3rd September 2005, 01:48 | #35 | Link | |
Registered User
Join Date: Sep 2004
Location: Near LA, California, USA
Posts: 1,545
|
Quote:
|
|
3rd September 2005, 02:29 | #36 | Link |
Registered User
Join Date: Jan 2002
Posts: 112
|
DTS,
In the context of 2pass (or more) high quality encodes, I humbly suggest testing the parameters "--ratetol inf" and "--qpstep 40". In my testing I have had good results with these. Sorry, I don't know what they are referred to in the VfW encoder as I use CLI. They represent "Bitrate Variance" and "Maximum Quantizer Delta" in MeGUI. Cheers! |
3rd September 2005, 13:36 | #37 | Link |
Registered User
Join Date: Nov 2001
Posts: 9,770
|
huh lots of things, i will pick out the most important ones
first of all thx everyone for the given info - nero and moonlight support custom quant decoding - when setting 0 reference frames in x264 it will encode with 1 reference frame (or 2 reference frames if b-frames are enabled). that is because x264 is smarter than the user i assume - if you have crashes with b-ref and large numbers of mref you should start an own thread about this and tell the x264 devs - "most x264 encodes use .avi" - where do you see that? on your harddisc?
__________________
Between the weak and the strong one it is the freedom which oppresses and the law that liberates (Jean Jacques Rousseau) I know, that I know nothing (Socrates) MPEG-4 ASP FAQ | AVC/H.264 FAQ | AAC FAQ | MP4 FAQ | MP4Menu stores DVD Menus in MP4 (guide) Ogg Theora | Ogg Vorbis use WM9 today and get Micro$oft controlling the A/V market tomorrow for free |
3rd September 2005, 23:40 | #38 | Link | ||
Registered User
Join Date: Aug 2002
Location: Spain
Posts: 233
|
Quote:
Quote:
__________________
I like to remember things my own way. Not necessarily the way they happened. (Fred Madison) |
||
3rd September 2005, 23:46 | #39 | Link | |
Registered User
Join Date: Nov 2001
Posts: 9,770
|
Quote:
__________________
Between the weak and the strong one it is the freedom which oppresses and the law that liberates (Jean Jacques Rousseau) I know, that I know nothing (Socrates) MPEG-4 ASP FAQ | AVC/H.264 FAQ | AAC FAQ | MP4 FAQ | MP4Menu stores DVD Menus in MP4 (guide) Ogg Theora | Ogg Vorbis use WM9 today and get Micro$oft controlling the A/V market tomorrow for free |
|
4th September 2005, 00:17 | #40 | Link |
Registered User
Join Date: Aug 2002
Location: Spain
Posts: 233
|
I see, so we should always set 512 in Recode if we'd want the accuracy of x264, is that correct?
__________________
I like to remember things my own way. Not necessarily the way they happened. (Fred Madison) |
Thread Tools | Search this Thread |
Display Modes | |
|
|