[Ffmpeg-devel-irc] ffmpeg-devel.log.20190404

[burek]

[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