Ok.. new patch defaults to only removing oldest frame to leave room for delayed decoding. (when b-pyramid is on) --strict-hierarchical causes first P/i after b group to remove that groups bref. brefs remove oldest frame in all cases.<br>
<br><div class="gmail_quote">On Tue, Sep 1, 2009 at 11:52 AM, Jason Garrett-Glaser <span dir="ltr"><<a href="mailto:darkshikari@gmail.com">darkshikari@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div><div></div><div class="h5">On Mon, Aug 31, 2009 at 10:59 PM, Trahald<<a href="mailto:wewk584@gmail.com">wewk584@gmail.com</a>> wrote:<br>
> Ok attached patch has strict dpb built in (not an option) and also makes<br>
> sure no pframes reference bframes (brefs are removed by the first P/i after<br>
> the B/b frames (coded order)<br>
> for your consideration..<br>
><br>
> On Mon, Aug 31, 2009 at 7:26 PM, Jason Garrett-Glaser<br>
> <<a href="mailto:darkshikari@gmail.com">darkshikari@gmail.com</a>> wrote:<br>
>><br>
>> On Mon, Aug 31, 2009 at 9:35 AM, Trahald<<a href="mailto:wewk584@gmail.com">wewk584@gmail.com</a>> wrote:<br>
>> ><br>
>> ><br>
>> > On Mon, Aug 31, 2009 at 12:30 PM, Trahald <<a href="mailto:wewk584@gmail.com">wewk584@gmail.com</a>> wrote:<br>
>> >><br>
>> >> Ok.. here is another version. patchable as of 1235. Again it adds open<br>
>> >> gop and a --strict-dpb( only does anything when b-pyramid is on) option<br>
>> >> that<br>
>> >> allows for ref 4 w/ 1080p . both options use mmco.<br>
>><br>
>> Can you send a patch which just adds MMCO b-pyramid? With strictdpb<br>
>> on by default (forced on, no option), I don't want x264 violating the<br>
>> spec.<br>
>><br>
>> I'd like to get this in quickly, which means the way to do this<br>
>> fastest is to split it into subcomponents which can be most easily<br>
>> committed.<br>
>><br>
>> Dark Shikari<br>
>> _______________________________________________<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>
><br>
><br>
> _______________________________________________<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>
><br>
><br>
<br>
</div></div>OK, I did a lot of analysis using this yesterday (and I wrote part of<br>
b-pyramid mbtree), and testing seems to show that keeping B-refs is<br>
better than throwing them away because lower-quality refs that are<br>
close temporally are better than high-quality refs which are far away<br>
temporally.<br>
<br>
This means that the "strict heirarchical" structure you've set up is<br>
suboptimal quality-wise, but of course some things require it (e.g.<br>
Blu-ray).<br>
<br>
What would I need to do to make this strict heirarchicalness optional,<br>
i.e. still abide by DPB in all cases, but make the default B-pyramid<br>
work as before (except spec-compliant) and have an extra option to<br>
make it strictly heirarchical for Blu-ray?<br>
<div><div></div><div class="h5"><br>
Dark Shikari<br>
_______________________________________________<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>