> 2) Golomb replacement > > This doesn't go as smoothly as for get_bits. As far as I have > understood, the branch has separate patches, but it would need to be > squashed to be compilable (useful for regression tracking). > I would suggest, although it is tedious, to add temporary files for > the new implementation. It's too bad git doesn't seem to allow making > copies and thus preserving history.
Some of the patchsets, I'd like to send if this one will be accepted, have to be compiled together, I was also thinking about adding temporary "_2" headers and also considered that tedious. > > And last but not least, although you've optimized it, Golomb parsing > actually shows the shortcomings of the new code. I have tried porting > code making heavy use of it, and there's a major slowdown (15%) there. May I ask how did you get these results? Did you use TIME macros inside golomb with some decoder? If you did, which one it was? > By the way, some bonus points: > - Although it is internal and the obvious reply is that libav doesn't > need it, a documentation for porting old code could be useful. If you mean some list with which new bitreading func is equivalent to which old one, it's not a problem. > - Shortening the function names (s/bitstream_/bs_/ ? bitstream_"tell"_size?) I disagree with this, my intention was to follow the naming conventions and to be consistent with bytestream.h. Anyway what are the short names good for? When you see bytestream_peek or bitstream_peek, it's clear what's going on whereas "bs" might be confusing. > > I like some of the technical results, but I think there are non-obvious > issues. > Best regards, Alexandra _______________________________________________ libav-devel mailing list [email protected] https://lists.libav.org/mailman/listinfo/libav-devel
