[00:04] <J_Darnley> Is fate.sh supposed to prepend $target_path onto $target_samples? [00:05] <J_Darnley> It keeps making R:/fate/build/Z:/fate-samples/audio-reference/luckynight_2ch_44kHz_s16.wav as an input file [03:15] <cone-265> ffmpeg.git 03Carl Eugen Hoyos 07master:96fc2908f0c0: Read bits_per_coded_sample from V_MS/VFW/FOURCC mkv files. [08:54] <plepere> ubitux : in VP9, for the 2D filters in the MC, do you call 2 1D filtes ? [08:54] <plepere> *filters [08:55] <plepere> yeah, seems so. found it in the dsp_init. [09:10] <ubitux> michaelni: careful when merging compand btw [09:10] <ubitux> they switch from double to float because they didn't have a clip function for double [09:10] <ubitux> but i'm not sure of the float being accurate enough given how much add & friends done in the filters [09:12] <ubitux> also, they replace av_strtok with strtok_r (because it wasn't available in their tree), but of course they just had the portability problem we had a while ago; so all the parsing part should be the same [09:12] <ubitux> i'd say the merge should be mostly void, given than andrewrk submitted a patch [09:12] <ubitux> for the memory corruption problem [09:13] <ubitux> maybe there are other relevant changes; andrewrk can you comment? [09:13] <plepere> ubitux : do you know if my patches have been reviewed / accepted /rejected ? [09:14] <ubitux> plepere: did you honor all the comments and sent a new version? [09:15] <plepere> the ones I had in the week-end, yes [09:15] <andrewrk> ubitux, here's the diff from ffmpeg to libav: http://paste.ubuntu.com/6998627/ [09:15] <plepere> but I've got nothing on the last patch I've submitted on monday [09:15] <ubitux> plepere: can you send the ffmpeg-devel archives? i'm lost in all the iteration [09:16] <plepere> ubitux, http://ffmpeg.org/pipermail/ffmpeg-devel/2014-February/154897.html [09:16] <andrewrk> ubitux, it also changed the token from " " to "|" [09:16] <andrewrk> so the options are incompatible between libraries [09:16] <andrewrk> there is some additional error checking [09:17] <ubitux> arh [09:17] <ubitux> so there are some actual random changes [09:17] <ubitux> i see changes in the options [09:17] <ubitux> like default strings [09:18] <andrewrk> my hands were tied. I didn't suggest those changes [09:18] <ubitux> for separator we need to change the if to support both char [09:18] <andrewrk> looks like the change to using av_frame_get_buffer instead of av_samples_alloc_array_and_samples is a good one [09:20] <andrewrk> ubitux, they had me switch it from double to float not because of the missing clip function but because they thought double was overkill [09:20] <andrewrk> how possible do you think it would be to have a civil discussion with them and agree on whether it should be float or double? [09:22] <ubitux> i don't care what they use [09:22] <ubitux> it's not a compatibility problem [09:22] <ubitux> maybe just a potential source of bugs, but it's not even confirmed [09:22] <andrewrk> ah. I assumed it was. any differences in implementation make merging patches trickier [09:22] <ubitux> i'm just playing safe here [09:30] <ubitux> plepere: will look [09:32] <ubitux> plepere: please don't add those "+////////////////////////////////////////////////////////////////////////////////" [09:32] <plepere> ubitux, ok. [09:32] <ubitux> diff is more readable btw, that's cool :) [09:33] <ubitux> (no need to resend a version now, drop it for the next iteration) [09:33] <plepere> ubitux, yes yes. I'm already working on loop unrolling anyways. :) [09:34] <ubitux> plepere: do you mind if i comment here or you prefer on the ml? [09:34] <plepere> you can comment here. :) [09:34] <plepere> I'll take written notes [09:51] <ubitux> plepere: last nit style; don't comment the code, drop it ("// s->hevcdsp.put_hevc_qpel[my][mx] ..."), and align vertically the arguments with the ( when breaking lines [09:52] <ubitux> there are settings to do that automatically in most editors [09:55] <plepere> in which files ? [09:55] <ubitux> second patch [09:55] <ubitux> all the function call you changed basically [09:58] <ubitux> plepere: in the asm, you can use the cglobal to name local variables [09:58] <ubitux> so you don't have to pick random numbers for the registers [09:58] <ubitux> and actually gives some meaning to them [09:59] <plepere> so I can name parameters + variables directly ? [09:59] <ubitux> yep [09:59] <plepere> neat [09:59] <ubitux> see in libavcodec/x86/vp9lpf.asm [09:59] <ubitux> cglobal vp9_loop_filter_h_%1_16, 5,10,16, 256, dst, stride, E, I, H, mstride, dst1, dst2, stride3, mstride3 [09:59] <ubitux> args stop after the H [09:59] <plepere> ok. :) [09:59] <ubitux> mstride & friends are extra regs [10:00] <ubitux> 5 = 5 args, 10 = 5args+5extra reg [10:00] <plepere> got it. :) [10:02] <ubitux> mov r9, 0  like with simd pxor, you can use xor here [10:02] <ubitux> but well you're probably gonna unroll anyway [10:02] <ubitux> i'll comment on that part after it's changed [10:03] <ubitux> the loops are clumsy as they are anyway [10:05] <plepere> the unrolled single loops are better. :) [10:06] <ubitux> +%macro MC_PIXEL_COMPUTE8_8 0 [10:06] <ubitux> + MC_PIXEL_COMPUTE2_8 [10:06] <ubitux> +%endmacro [10:06] <ubitux> what's the point of this? [10:06] <ubitux> maybe use %define? [10:06] <plepere> yes, %define is more logical in this case. :/ [10:07] <ubitux> you can probably move the cglobal and RET into the macros themselves [10:07] <ubitux> i think i already raised that, maybe you answered.. [10:08] <plepere> well there is no big macro now [10:08] <plepere> since the unrolling makes the functions quite different now [10:08] <ubitux> ok [10:08] <ubitux> #if ARCH_X86_64 [10:09] <ubitux> include that in the if itself [10:09] <ubitux> if (ARCH_X86_64 && ...) [10:09] <plepere> which if ? it's there so it doesn't compile in 32bit [10:10] <ubitux> it will, the linker optim will prevent from trying to find the inexisting symbols [10:10] <ubitux> see the if above [10:10] <ubitux> we use that method everywhere, don't worry [10:12] <ubitux> i'll comment on the unrolled version of the patch [11:25] <ubitux> michaelni: i'd like to have compand properly merged before 2.2; if you or paul aren't that motivated i can help [11:26] <ubitux> michaelni: also, #3131 looks important [11:26] <ubitux> but i can't comment much on it [11:26] <ubitux> anything you think is blocking? [11:27] <nevcairiel> some people reported that remuxing the stream solved the issue as well, so must be some odd interaction between demuxer parser and decoder [11:31] <michaelni> ubitux, do you have a test command line for our compand filter ? [11:32] <ubitux> michaelni: not really, maybe the one is the ticket [11:32] <ubitux> which triggers the crash with that particular sample [11:33] <michaelni> ubitux, iam talking about the audio filter not 3131 [11:33] <ubitux> me too [11:34] <ubitux> michaelni: there is command in #3383 [11:36] <michaelni> thx [12:02] <cone-124> ffmpeg.git 03Andrew Kelley 07master:738f83582a3a: lavfi: add compand audio filter [12:02] <cone-124> ffmpeg.git 03Michael Niedermayer 07master:5d166de25853: Merge remote-tracking branch 'qatar/master' [12:02] <cone-124> ffmpeg.git 03Michael Niedermayer 07master:22307f170ffc: avfilter/af_compand: whitespace changes from af_compand_fork [12:02] <cone-124> ffmpeg.git 03Michael Niedermayer 07master:1df1a1fe6120: avfilter/af_compand_fork: avoid strtok_r() so as not to break build [12:39] <cone-124> ffmpeg.git 03Michael Niedermayer 07master:86a191e25bc5: avfilter/af_compand: merge avframe code from af_compand_fork [13:07] <cone-124> ffmpeg.git 03Michael Niedermayer 07master:66ad3292eb45: avfilter/af_compand: add Andrew Kelley to the copyright [13:07] <cone-124> ffmpeg.git 03Michael Niedermayer 07master:5c78fe08b0a6: avfilter/af_compand: cosmetics and doxy comment from libavfilter/af_compand_fork.c [13:07] <cone-124> ffmpeg.git 03Michael Niedermayer 07master:4b8797514732: avfilter/af_compand: pts init code from libavfilter/af_compand_fork.c [13:07] <cone-124> ffmpeg.git 03Michael Niedermayer 07master:e509df4bc8eb: avfilter/af_compand: error checks from libavfilter/af_compand_fork.c [13:07] <cone-124> ffmpeg.git 03Michael Niedermayer 07master:619d6b8f55ce: avfilter/af_compand: "use local variable for channels" from libavfilter/af_compand_fork.c [13:07] <cone-124> ffmpeg.git 03Michael Niedermayer 07master:5e02ff3e3d15: avfilter/af_compand: switch defaults to libavfilter/af_compand_fork.c [13:07] <cone-124> ffmpeg.git 03Michael Niedermayer 07master:05412f4cd41e: avfilter/af_compand: cosmetics from libavfilter/af_compand_fork.c [13:22] <cone-124> ffmpeg.git 03Michael Niedermayer 07master:c62d83a5e7dd: avfilter/af_compand: more cosmetics from libavfilter/af_compand_fork.c [13:22] <cone-124> ffmpeg.git 03Michael Niedermayer 07master:8f946ac8ea10: avfilter: remove af_compand_fork [16:00] <durandal_1707> andrewrk: s/libav/Libav in license of compand [16:01] <Compn> shouldnt it be s/libav/FFmpeg ? [16:01] <durandal_1707> i talk about cosmetics flaws in Libav code [16:08] <ubitux> haha [16:09] <Compn> lol [16:09] <Compn> durandal_1707 : the libav logo on libav.org is uncapitalized :P [16:11] <durandal_1707> they should finally decide, are they going to be named Libav of libav [16:11] <durandal_1707> s/of/or ^&*^*& [16:15] <ubitux> LibAV seems trending [16:18] <beastd> i would always spell it Libav or LibAV or whatever. Plain libav is just too misleading... [16:20] <ubitux> i think carl like to call them "avconv" [16:20] <ubitux> because it's less confusing [16:45] <Daemon404> who wants to take bets [16:46] <Daemon404> im going to encode 600 4k frames with vp9 on placebo [16:46] <Daemon404> on a 24-core xeon [16:46] <Daemon404> how many days? bets welcome. [16:46] <Daemon404> not that cores matter for vpx [16:48] <ubitux> mmh [16:48] <ubitux> 20 hours [16:48] <ubitux> you only have 600 frames after all [16:49] <Daemon404> for 4k? [16:49] <Daemon404> damn that will be faster than x265 with 24 threads [16:49] <Daemon404> lol. [16:49] <ubitux> ah [16:49] <nevcairiel> 0.5 fpm or so i would guess [16:49] <nevcairiel> seems not too far fetched [16:50] <Daemon404> i want to do proper testing but every encoder except x264 is so goddamn slow [16:50] <Daemon404> i need to like [16:50] <ubitux> x265*? [16:50] <Daemon404> run a figgen mapreduce on our servers [16:50] <Daemon404> ubitux, no [16:50] <ubitux> ah sorry [16:50] <ubitux> derp reading sorry [16:50] <ubitux> i have 63% of the ETV raw [16:50] <Daemon404> maybe i can hijack our hadoop servers and run trancodes [16:50] <Daemon404> hurr hurr hurr [16:50] <ubitux> i'll probably make the new encodes next week [16:50] <ubitux> and the next week i'll have them in vp9 [16:51] <Daemon404> i have some 4k clips if you want [16:51] <Daemon404> but im already doign encodes with them [16:51] <ubitux> i want to retry with the raw instead of the x264 encode for etv [16:51] <Daemon404> yeah im using beyondhd test clips [16:51] <ubitux> to check if that's why x264 won at high bitrate [16:51] <Daemon404> raw 10-bit 4:4:4 [16:51] <Daemon404> (well, rgb) [16:52] <Daemon404> oh, i wanted to ask [16:52] <Daemon404> is tehre a good resource on using newton' method in a practical manner [16:52] Action: Daemon404 was avoiding readig all teh calculus on the wiki page [16:55] <kierank> x1 = x0 - f(0)/f'(0) [16:55] <kierank> f(x0) I mean for both [16:55] <kierank> use a central difference for the derivative [16:56] <Daemon404> >central difference [16:56] <Daemon404> its been too long and i dont remember wtf this is [16:56] <Daemon404> ive never had to do derivativs manually in code, somehow [16:57] <kierank> f'(x) ~= f(x+epsilon) - f(x-epsilon) / 2e [16:57] <Daemon404> from wiki, i cant see: [16:57] <Daemon404> a) where e comes from [16:57] <kierank> it's just a width [16:58] <Daemon404> http://upload.wikimedia.org/math/0/3/0/03003621f1d1c21db25c422bac0c580e.png [16:58] <kierank> literally deltay / delta x [16:58] <Daemon404> wiki has no e at all [16:58] <kierank> they use h [16:58] <Daemon404> oh i see why im confused [16:58] <Daemon404> you wrote out epsilon twice [16:58] <Daemon404> then used 'e' [16:58] <Daemon404> which i took to be the constant, e [17:00] <kierank> yeah should be epsilon :) [17:01] <Daemon404> ive literally never had to do calculus in code [17:01] <Daemon404> i dont think ive done central difference since highschool [17:02] <Daemon404> and only for like week there, until we got to the ways the rest of the world does it [17:02] <Daemon404> :V [17:02] <Daemon404> oh well [17:04] <kierank> why do you need calculus [17:05] <Daemon404> kierank, ... >derivatives [17:05] <ubitux> huh, what's this license change. [17:05] <Daemon404> how is that not calculus? [17:05] <kierank> Daemon404: for what [17:05] <Daemon404> newton-pahson? [17:05] <Daemon404> raphson* [17:06] <kierank> why do you need newton raphson [17:06] <Daemon404> because many encoders have shit ratecontrol [17:07] <Daemon404> actually i have numpy and R installed (and matlab elsewhere) [17:07] <Daemon404> maybe ill just have them do it for me [17:07] <Daemon404> im sure they have less annoying ways [17:22] <Daemon404> it's really goddamn annoying to compare encoders when x264 is literally the only one that can get anywhere close [17:22] <Daemon404> re: rc [17:29] <Daemon404> kierank, scipy.optimize.newton works wonderfully [17:29] <smarter> ubitux: consider trying without --aq-mode=1 [17:30] <ubitux> yeah i'll do 2 encodes [17:30] <ubitux> smarter: do you know when libvpx is going to get faster? [17:30] <smarter> it's getting faster all the time :p [17:31] <smarter> though cpu-used=0 is still pretty damn slow [17:31] <ubitux> i mean faster enough to get usable [17:31] <smarter> I think that SATD-based RDO would help, but that's a big undertaking [17:31] <smarter> I might experiment with that if I get the time [17:32] <ubitux> you think we can consider doing some vp9 encodes in about 6 month? [17:32] <smarter> no idea really [17:33] <smarter> (concerning --aq-mode=1, in my tests it made SSIM worse with blurry/noisy content, I had a fix but I couldn't see any difference visually, and it made aq-mode=1 less useful in other cases, so I didn't bother applying it) [17:34] <ubitux> speaking of this, was the double-bitrate issue raised? [17:34] <smarter> create an issue in the bug tracker maybe? [17:35] <ubitux> erh, :eff [17:35] <ubitux> this reminds me i wanted to check an issue with vp8 encoder in libvpx [17:36] <smarter> I also suspect that this is because of aq-mode=1, but it would require making the first pass much more complex I think [17:36] <ubitux> http://trac.ffmpeg.org/ticket/3137 [17:36] <ubitux> this bug is extremely annoying ^ [17:37] <ubitux> but i guess i have to reproduce with libvpx directly [17:38] <cone-124> ffmpeg.git 03Paul B Mahol 07master:a2e4b4e96836: avfilter/af_compand: some more cosmetics to decrease difference with qatar [17:38] <cone-124> ffmpeg.git 03Paul B Mahol 07master:9f2a3bcee7bc: avfilter: remove superflous lines [17:40] <durandal_1707> i cant belive it, i fixed that spell mistake.. but it keep going in [17:41] <ubitux> ? [17:46] <durandal_1707> and why they added shuffleplanes filter its functionality is extremly limited [17:46] <durandal_1707> mergeplanes can do what it does and much more .... [17:47] <ubitux> considers you happy they didn't name it the same [17:47] <ubitux> yourself* [17:47] <saste> durandal_1707, nih syndrome [17:55] Action: Daemon404 jabs saste to review a weeks-old example code patch he sent [17:57] <durandal_1707> andrewrk: you gonna send af_ladspa to libAV? [17:57] <saste> Daemon404, name of patch? [17:58] <Daemon404> [PATCH] examples/demuxing_decoding: Fix invalidd API usage [18:01] <ubitux> nice [18:01] <ubitux> libvpx seems to create broken webm files :( [18:01] <ubitux> oh well, whatever [18:06] <durandal_1707> and naming filter shuffleplanes would just add confusion with same function from VS [18:10] <Daemon404> ubitux, with ivfenc? [18:10] <Daemon404> oh webm [18:50] <cone-124> ffmpeg.git 03Paul B Mahol 07master:9d297641ee0b: avformat/sdr2: h264 stream needs parsing [19:21] <cone-124> ffmpeg.git 03Michael Niedermayer 07master:bdadf05ec853: avcodec/parser: put lost comments back [19:21] <cone-124> ffmpeg.git 03Timothy Gu 07master:baa650cc7946: configure: use pkg-config to detect libbluray [19:56] <Daemon404> we should add a copyright header in allcodecs.c for everyone who has ever touched it [19:56] <Daemon404> riff.c too [20:03] <iive> why only them? let's put everybody everywhere. [20:27] <Compn> Daemon404 : simple stuff like that isnt copyrightable ? :P [20:27] <Compn> at least the tables [20:27] <Compn> not the other code in there :P [20:29] <cone-124> ffmpeg.git 03Peter Ross 07master:1524b0fa68e0: libavcodec/rawdec: avoid memcpy when performing 16-bit samples shift [00:00] --- Thu Feb 27 2014