[FFmpeg-devel] Fw: [foms] Paper submissions to LCA
Jason Garrett-Glaser
darkshikari
Fri Jul 17 02:13:55 CEST 2009
> This is unfortunately the opposite of what is needed to do part of the
> decoding on a DSP or other coprocessor.
We have CONFIG_SMALL for that. This isn't an issue.
>> 2. ?Write paranoid-schizophrenic entropy decoder; separate load_bits
>> and get_bits into two functions and only call load_bits when one knows
>> that the bit buffer needs to be reloaded.
>
> Isn't this what some of the bitstream readers already do?
Not that I know of. get_bits is a single function; an example of
CoreAVC style would be as follows:
load_bits(); /* We know we have at least 16 bits of data in buffer,
for example */
a=get_vlc(blah blah); /* The max size of this VLC is 5 bits. */
b=get_bits(3);
c=get_vlc(blah blah); /* the max size of this VLC is 7 bits. */
load_bits(); /* We have to reload the buffer now. */
>> 7. ?Template everything you can get your hands on. ?Motion
>> compensation functions should be templated for weighted pred, implicit
>> weighted pred, bipred, non-bipred, etc. ?Decoding functions should be
>> templated based on frametype (I, P, B).
>> 8. ?Borrow every bit of assembly you can get your hands on from x264
>> to squeeze out as much performance as possible.
>>
>> Many of these changes would involve a great deal of refactoring, both
>> in h264.c and dsputil. ?Some would probably be completely impossible
>> to get past a patch review, particularly 2).
>
> What does that say about the review process?
It says that the review process rightfully rejects nigh-unreadable code ;)
Dark Shikari
More information about the ffmpeg-devel
mailing list