[x264-devel] Patch open gop

Trahald wewk584 at gmail.com
Fri Sep 4 01:24:22 CEST 2009


ok.. partial reset renamed and slimmed down, ref list header macroed ,
reordering only done for bref, mmco only defined in sh

the reordering thing i dont plan to do ( im slow would take me too long, and
really dont know where to start, needs opengop )
On Thu, Sep 3, 2009 at 2:37 PM, Trahald <wewk584 at gmail.com> wrote:

> normal mode needs reordering for correct output. (actually just for the
> BREFs.. i can change it to x264_type_bref instead of slicetypeb.).
>
> On Thu, Sep 3, 2009 at 12:35 AM, Jason Garrett-Glaser <
> darkshikari at gmail.com> wrote:
>
>> Trahald,
>>
>> Here's my current local patch; I've revamped the commandline usage
>> once again and cleaned it up a bit.  Here's Loren's requests before we
>> commit it (why aren't you paying attention in IRC--it would get done a
>> lot faster that way?):
>>
>> 12:18 < pengvado> I think x264_reference_partial_reset could be simpler if
>> it
>>                  processes B-frames rather than skipping non-B-frames
>> 12:20 < pengvado> it should also do if(!pyramid) return at the beginning,
>>                  rather than while(pyramid) at the end.
>> 12:22 < pengvado> ref list header code should be macroed, functioned, or
>> looped
>>                  for the 2 lists, not duplicated
>> 12:23 < pengvado> ref list reordering should be enabled only if the
>> desired
>>                  order actually differs from the default order
>> 12:24 < pengvado> which should never happen in B-frames
>> 12:24 < pengvado> (unless you're abusing then for forward-only prediction
>> or
>>                  something like that)
>> 12:28 < pengvado> why do you need a mmco[] in both slice header and
>> x264_t?
>> 12:29 < pengvado> if it's because x264_reference_partial_reset runs before
>>                  slice_header_init, then just don't overwrite it in
>>                  slice_header_init
>> 12:33 < pengvado> x264_reference_partial_reset should be named something
>> that
>>                  says which part, such as x264_reference_hierarchy_reset
>> 12:34 < pengvado> and then there's the comment on reordering, but I
>> already
>>                  sent that
>> 12:34 < pengvado> nothing else
>>
>> 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/20090903/e7a3bd6b/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: test2.diff
Type: application/octet-stream
Size: 16614 bytes
Desc: not available
URL: <http://mailman.videolan.org/pipermail/x264-devel/attachments/20090903/e7a3bd6b/attachment-0001.obj>


More information about the x264-devel mailing list