On 10 Mar 2014, at 13:30, Hendrik Leppkes <h.lepp...@gmail.com> wrote:
> On Mon, Mar 10, 2014 at 1:27 PM, Tim Walker <tdskywal...@gmail.com> wrote: >> On 10 Mar 2014, at 13:24, Luca Barbato <lu_z...@gentoo.org> wrote: >> >>> On 10/03/14 12:43, Tim Walker wrote: >>>> >>>> On 10 Mar 2014, at 11:01, Luca Barbato <lu_z...@gentoo.org> wrote: >>>> >>>>> Do not use inline functions that refer to tables present in other >>>>> libraries. --- libavformat/hevc.c | 10 +++++----- 1 file changed, 5 >>>>> insertions(+), 5 deletions(-) >>>> >>>> I used get_se_golomb because the spec. said those fields were se(v) >>>> and I was unsure whether get_ue_golomb/get_ue_golomb_long would read >>>> the correct number of bits (I really had no clue what I was doing). >>> >>> se or ue are just the same encoding in the bitstream, you just use the >>> first bit as sign. >>> >>>> But it seems your get_se_golomb_long just uses get_ue_golomb_long - >>>> were's skipping these fields anyway, is there any difference in >>>> behavior or does it just make it obvious we're skipping signed golomb >>>> codes? >>> >>> mostly for completeness sake and prevent more cases in the future. >>> >>> lu >> >> Out of curiosity, what does get_se_golomb do which requires a table that we >> don't need in a "get_se_golomb_long" implementation? >> > > It doesn't "require" it, but since golomb parsing is often used in > speed-critical code, the non-long functions are optimized for speed > with help of tables (but limited in parsing length, hence the name > long for those that are not). > > - Hendrik Thanks :-) Tim _______________________________________________ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
