<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Thu, Mar 6, 2014 at 10:33 AM, Chuck Crisler <span dir="ltr"><<a href="mailto:ccrisler@mutualink.net" target="_blank">ccrisler@mutualink.net</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">There are many possible explanations why they yield different levels of compression. You don't specify what parameters you are setting in them so you are likely seeing different default options used by the encoders which will yield differing compression ratios. You need to pay attention to the profile and level, but also all of the other options that can be set. You also need to pay attention to output bitrate, framerate and IFrame interval. If you are generating a higher percentage of frames as IFrames, then the resulting size will be much larger.<br>
</div></blockquote><div><br></div><div>I have tried to give them all the same settings. Are there any tools that give statistics on the distribution of compression objects inside the h.264 streams? The vendor has fixed bugs in their closed source compression library before, I suspect there are still some more bugs.</div>
<div><br></div><div>For example I have one video clip that has been designed to be hard to compress. I'm using the same profile, level, bitrate, framerate, iFrame on both compression engines. I am asking for a 1Mb/sec stream. x264 happily gives me the 1Mb/s stream. It looks awful but that is expected given the way the input clip is designed. For this clip the hardware encoder won't do less than a 10Mb/s stream no matter what parameters I give it, but on other video streams it will generate the 1Mb/s stream. So it is doing something wrong with this hard to compress clip.</div>
<div><br></div><div>I have to give the vendor a fairly detailed explanation of the failure to have any hope of getting a fix.</div><div> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr">
</div><div class="gmail_extra"><br><br><div class="gmail_quote"><div><div class="h5">On Wed, Mar 5, 2014 at 9:05 PM, <a href="mailto:jonsmirl@gmail.com" target="_blank">jonsmirl@gmail.com</a> <span dir="ltr"><<a href="mailto:jonsmirl@gmail.com" target="_blank">jonsmirl@gmail.com</a>></span> wrote:<br>
</div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div class="h5">I'm evaluating several hardware h.264 encoders by feed them identical<br>
videos to compress. The output files from these compressors are all<br>
over the map in size. Does anyone know of a tool that would analyze<br>
the h.264 streams and give me an idea of why I'm getting these<br>
different results? I suspect there are bugs in a couple of the<br>
implementations such that they are compressing, but not as much as<br>
they should be.<br>
</div></div><span class="HOEnZb"><font color="#888888"><span><font color="#888888"><br>
--<br>
Jon Smirl<br>
<a href="mailto:jonsmirl@gmail.com" target="_blank">jonsmirl@gmail.com</a><br>
_______________________________________________<br>
gstreamer-devel mailing list<br>
<a href="mailto:gstreamer-devel@lists.freedesktop.org" target="_blank">gstreamer-devel@lists.freedesktop.org</a><br>
<a href="http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel" target="_blank">http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel</a><br>
</font></span></font></span></blockquote></div><br></div>
<br>_______________________________________________<br>
gstreamer-devel mailing list<br>
<a href="mailto:gstreamer-devel@lists.freedesktop.org">gstreamer-devel@lists.freedesktop.org</a><br>
<a href="http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel" target="_blank">http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel</a><br>
<br></blockquote></div><br><br clear="all"><div><br></div>-- <br>Jon Smirl<br><a href="mailto:jonsmirl@gmail.com" target="_blank">jonsmirl@gmail.com</a>
</div></div>