[00:10:24 CEST] <nevcairiel> jamrial: i figured out why fate doesnt work on my windows boxes anylonger. Some of the helper routines that are now being used by more tests don't like windows-style absolute path syntax, and therefor screw everything up [00:11:13 CEST] <jamrial> nevcairiel: might have to change the test to not use transcode() then [00:11:20 CEST] <jamrial> i'll look at it later [00:11:21 CEST] <nevcairiel> its actually surprising this didnt blow up much sooner, but apparently TARGET_PATH wasn't used much [00:11:49 CEST] <nevcairiel> actually m aybe this can be fixed easier [00:12:12 CEST] <nevcairiel> transcode() wants to prepend TARGET_PATH and checks if its already there [00:12:16 CEST] <nevcairiel> but that check f ails on windows [00:12:25 CEST] <nevcairiel> so.. why not change the actual test to not have it there? [00:12:38 CEST] <nevcairiel> it'll just get added and not blow up [00:12:40 CEST] <nevcairiel> let me test [00:13:02 CEST] <nevcairiel> yup that works [00:15:20 CEST] <nevcairiel> i'll send to the ML [00:15:23 CEST] <jamrial> nice, thanks [00:17:15 CEST] <jamrial> i worry about the transcode() tests adding TARGET_SAMPLES then [00:18:09 CEST] <nevcairiel> its probably not just transcode [00:18:25 CEST] <nevcairiel> a lot of functions have that appending logic [00:18:33 CEST] <nevcairiel> but samples are not typically in TARGET_PATH [00:18:40 CEST] <nevcairiel> since thats the output directory [00:18:51 CEST] <nevcairiel> this one was special since it was generated by another test [00:20:11 CEST] <nevcairiel> TARGET_SAMPLES works because I have that setup with a relative path :D [00:20:31 CEST] <nevcairiel> iirc i did that because absolute-path on windows for that was entirely broken :) [00:20:57 CEST] <jamrial> yeah, i have to do the same [00:21:22 CEST] <nevcairiel> i forget why i didnt u se mingw-style path with /c/ instead of c:/ [00:21:28 CEST] <nevcairiel> but probably msvc stuff didnt liket hat [11:32:59 CEST] <cone-127> ffmpeg 03Michael Niedermayer 07master:8e3b01e20ebd: avcodec/agm: More completely check size before using it [12:41:50 CEST] <durandal_1707> michaelni: do you know way to get different(non-canonical) prefix codes from set of bit-lenghts? [13:12:34 CEST] <michaelni> iam not sure i understand the question, you can build a VERY large number of prefix codes from a list of lengths [13:19:56 CEST] <durandal_1707> michaelni: yes, but i know how for certain values code actually looks like [13:31:20 CEST] <michaelni> durandal_1707, i dont have a good solution i think. if its few codes a text editor or pencil and paper could be used to build the whole list of prefixes with a lot of guessing. once the patterm is obvious the rest could be done with code. I assume theres no simple table in the binary of these codes? [13:31:54 CEST] <michaelni> also of course you coukd hack the encoder (if available) to spit all codes out in sequence or feed special input to achieve the same [13:33:47 CEST] <michaelni> the decoder with some instrumentation decoding random things might also be useable to extract the codes but maybe iam misunderstanding the problem [13:35:58 CEST] <durandal_1707> i have codec that recreate huffman tree from set of 256 bit-lenghts [13:36:49 CEST] <michaelni> try if it matches any of our length -> prefix implementations [13:38:20 CEST] <durandal_1707> already did [13:46:04 CEST] <michaelni> ff_huff_build_tree() with custom HuffCmp might help, if you know how things in the tree are supposed to be ordered [13:51:30 CEST] <durandal_1707> isn't that for frequencies only? [13:53:22 CEST] <michaelni> you can use something like freq = 1<<len [13:54:36 CEST] <michaelni> rather freq = 1<<(max - len) [14:06:22 CEST] <durandal_1707> michaelni: does not work [14:32:30 CEST] <j-b> 'lo [14:33:35 CEST] <durandal_1707> alright [14:42:31 CEST] <kurosu> durandal_1707: I don't think you have another option than RE how the codewords are created [14:54:02 CEST] <kurosu> if it's not that dynamical, maybe you could dump the output and store them in a data file as codebooks [14:54:26 CEST] <kurosu> (though atypical for huffman codes) [15:09:44 CEST] <durandal_1707> it is dynamical [16:11:03 CEST] <JEEB> it seems like the C++ module in ghidra got open sauce'd? [22:57:12 CEST] <carton> Hello! Could you please add "#!/bin/sh" to ffbuild/libversion.sh. It doesn't work with busybox. Thank you. [00:00:00 CEST] --- Fri Apr 5 2019