<div>Can you please tell me where I can find some better quantization algorithms.</div>
<div> </div>
<div>Regards,</div>
<div>Mahesh.<br><br></div>
<div class="gmail_quote">On Jan 31, 2008 3:05 PM, Loren Merritt <<a href="mailto:lorenm@u.washington.edu">lorenm@u.washington.edu</a>> wrote:<br>
<blockquote class="gmail_quote" style="PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid">
<div class="Ih2E3d">On Thu, 31 Jan 2008, mahesh k wrote:<br><br>> I do find some difference in the quantization of X264 and our.<br><br></div><a href="http://mailman.videolan.org/pipermail/x264-devel/2007-November/003729.html" target="_blank">http://mailman.videolan.org/pipermail/x264-devel/2007-November/003729.html</a><br>
<div class="Ih2E3d"><br>> I think they are using function pointers. But my results are matching with<br>> JM.<br><br></div>Of course your results aren't identical to JM. Every encoder is different.<br>What kind of screwed up standard would allow only a single possible<br>
encoder algorithm? Not even JM is identical to JM; it has tons of options,<br>including multiple quantization algorithms.<br>
<div class="Ih2E3d"><br>> please let me know whether X264 is as per H.264 standard or not.<br><br></div>The definition of a compliant encoder is one that generates compliant<br>bitstreams. So try this thought experiment: Given a h264 stream (and only<br>
the compressed stream, assume you don't have access to the original source<br>video), can you tell what quantization algorithm was used to generate it?<br>No? Then quantization can't have any impact on standards compliance.<br>
<font color="#888888"><br>--Loren Merritt<br></font>
<div>
<div></div>
<div class="Wj3C7c">_______________________________________________<br>x264-devel mailing list<br><a href="mailto:x264-devel@videolan.org">x264-devel@videolan.org</a><br><a href="http://mailman.videolan.org/listinfo/x264-devel" target="_blank">http://mailman.videolan.org/listinfo/x264-devel</a><br>
</div></div></blockquote></div><br>