Hi, 2016-04-30 21:44 GMT+02:00 Alexandra Hájková <[email protected]>: > 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.
It would have been useful in the case there were actual cases where it was slower, but it's not about that. > 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? Just for the record, so as to not appear silent here. This is a vc2/dirac lowdelay decoder that spends most of its time in Golomb code parsing. The commit optimizing Golomb reading only touched some of those, for good reason maybe, but not the interleaved versions. Although the slowdown does appear with the new reader and multithreading, single-threaded decoding is faster with the new reader, so it's more likely the multithreading or my porting that are the cause of this. >> - 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. It's just that I got bitten by get_bits_count vs bitstream_tell vs bitstream_tell_size >> - 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 didn't have a strong opinion, but several developers mentioned that. Thanks, -- Christophe _______________________________________________ libav-devel mailing list [email protected] https://lists.libav.org/mailman/listinfo/libav-devel
