[x264-devel] Patch open gop

[Trahald]

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.

On Tue, Sep 1, 2009 at 11:52 AM, Jason Garrett-Glaser <darkshikari at gmail.com
> wrote:

> On Mon, Aug 31, 2009 at 10:59 PM, Trahald<wewk584 at gmail.com> wrote:
> > Ok attached patch has strict dpb built in (not an option) and also makes
> > sure no pframes reference bframes (brefs are removed by the first P/i
> after
> > the B/b frames (coded order)
> > for your consideration..
> >
> > On Mon, Aug 31, 2009 at 7:26 PM, Jason Garrett-Glaser
> > <darkshikari at gmail.com> wrote:
> >>
> >> On Mon, Aug 31, 2009 at 9:35 AM, Trahald<wewk584 at gmail.com> wrote:
> >> >
> >> >
> >> > On Mon, Aug 31, 2009 at 12:30 PM, Trahald <wewk584 at gmail.com> wrote:
> >> >>
> >> >> Ok.. here is another version. patchable as of 1235.  Again it adds
> open
> >> >> gop and a --strict-dpb( only does anything when b-pyramid is on)
> option
> >> >> that
> >> >> allows for ref 4 w/ 1080p . both options use mmco.
> >>
> >> Can you send a patch which just adds MMCO b-pyramid?  With strictdpb
> >> on by default (forced on, no option), I don't want x264 violating the
> >> spec.
> >>
> >> I'd like to get this in quickly, which means the way to do this
> >> fastest is to split it into subcomponents which can be most easily
> >> committed.
> >>
> >> Dark Shikari
> >> _______________________________________________
> >> x264-devel mailing list
> >> x264-devel at videolan.org
> >> http://mailman.videolan.org/listinfo/x264-devel
> >
> >
> > _______________________________________________
> > x264-devel mailing list
> > x264-devel at videolan.org
> > http://mailman.videolan.org/listinfo/x264-devel
> >
> >
>
> OK, I did a lot of analysis using this yesterday (and I wrote part of
> b-pyramid mbtree), and testing seems to show that keeping B-refs is
> better than throwing them away because lower-quality refs that are
> close temporally are better than high-quality refs which are far away
> temporally.
>
> This means that the "strict heirarchical" structure you've set up is
> suboptimal quality-wise, but of course some things require it (e.g.
> Blu-ray).
>
> What would I need to do to make this strict heirarchicalness optional,
> i.e. still abide by DPB in all cases, but make the default B-pyramid
> work as before (except spec-compliant) and have an extra option to
> make it strictly heirarchical for Blu-ray?
>
> Dark Shikari
> _______________________________________________
> x264-devel mailing list
> x264-devel at videolan.org
> http://mailman.videolan.org/listinfo/x264-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.videolan.org/pipermail/x264-devel/attachments/20090902/1625059e/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: x264_strictdpb_stricthierarchical.02.diff
Type: application/octet-stream
Size: 9578 bytes
Desc: not available
URL: <http://mailman.videolan.org/pipermail/x264-devel/attachments/20090902/1625059e/attachment-0001.obj>