[00:06] <Daemon404> nevcairiel: seems i forgot... [00:06] <Daemon404> icl ships with gdb now [00:06] <Daemon404> lol. [01:28] <cone-783> ffmpeg.git 03Michael Niedermayer 07master:0875a9e4fc4c: avformat/oggparseogm: check input size before reading t [01:28] <cone-783> ffmpeg.git 03Michael Niedermayer 07master:42b6805cc198: avcodec/huffyuvdec: clear remainder of the array on end of input in decode_422_bitstream() [02:02] <BBB> ubitux: why signed? the most common method is +128 (or pxor 0x80; i.e. make unsigned), then pand (0xf8 or 0xf0) and then psrlq/d/w 3 or 4, and then in the end -128 (or pxor 0x80) [02:03] <BBB> oh michael already said that [02:03] <BBB> ok nevermind me [02:55] <iive> BBB: why is the pand? if the operation is byte wise it shouldn't be needed. [02:55] <iive> and i see you do give example with shift that is quad/double/word ... [02:59] <iive> n8 [03:06] <BBB> because there is no bytewise shift [03:06] <BBB> :) [03:11] <cone-783> ffmpeg.git 03Michael Niedermayer 07master:f55bc96a5449: avcodec/pcm-dvd: reset last header on errors [07:28] <ubitux> BBB: why signed; because filter2()/filter4() are signed op [07:29] <ubitux> michaelni, BBB, ok thx will try that [07:30] <ubitux> BBB: btw, about the MC func, any reason to prefer 8 reads vs 2 reads (-3 and +4) and palignr/pshufb? [07:31] <ubitux> (at the beginning of the .loop) [07:32] <ubitux> all the data should overlap, unless i'm missing sth? [07:33] <ubitux> (for the horizontal one) [09:47] <j-b> 'morning [11:51] <richardus> there's no documentation for the -g flag on the ffmpeg-all page, should i file a big [11:51] <richardus> bug [11:51] <richardus> i'm having trouble searching trac for '-g' :p [11:54] <nevcairiel> g is keyframe interval [11:55] <cone-205> ffmpeg.git 03Michael Niedermayer 07master:e630ca511107: avformat/mpegts: check sl.timestamp_len [12:18] <cone-205> ffmpeg.git 03Diego Biurrun 07master:b83d1ee3b41c: avutil: Move library version related macros to version.h [12:18] <cone-205> ffmpeg.git 03Michael Niedermayer 07master:25b243759cb6: Merge commit 'b83d1ee3b41cfe8357836e2582104db2f3364cb0' [12:42] <saste> richardus, g in the codec options chapter [12:44] <BBB> ubitux: I tried palignr/pshufb, it was slower (see also vp8, it does the same thing, or 8px one, it does the same thing) [12:44] <BBB> ubitux: don't know why tbh [12:45] <ubitux> ah, okay& [12:45] <BBB> I'd expect it to be faster b/c non-i/o but what do I know [12:45] <BBB> maybe once it's cached it doesn't matter [12:46] <BBB> also I'm working on 32x32 again now [12:46] <BBB> (the sub4x4/sub2x2 made no speed diff so I left them aside for now) [12:47] <ubitux> btw, srcq and src4q aren't aligned all the time? [12:48] <cone-205> ffmpeg.git 03Stefano Sabatini 07master:8ea150187856: doc/protocols: fix level of udp examples subsection [12:49] <BBB> no, because a ref pixel in mc can be at any position [12:49] <BBB> (as opposed to a dst pixel, which is always blocksize-aligned) [12:50] <ubitux> ok [12:50] <ubitux> then i guess it LGTM, but i don't know MC enough :p [12:51] <ubitux> the sub func in 16x16 LGTM too btw [12:52] <ubitux> i can ofc reply on the ml but since you're here& [13:10] <BBB> tnx [13:10] <BBB> ok off to 32x32 then [13:10] <cone-205> ffmpeg.git 03Luca Barbato 07master:9ace13db77a2: doxy: Fix link in badge color [13:10] <cone-205> ffmpeg.git 03Michael Niedermayer 07master:8102cdfc04a5: Merge commit '9ace13db77a22fd59c217175596a95775c5d25aa' [13:10] <BBB> ubitux: and the other one (sub8x8 I think) also ok? [13:12] <ubitux> the other one? [13:12] <ubitux> i'm talking about sub8x8 in 16x16 [13:25] <cone-205> ffmpeg.git 03Luca Barbato 07master:1ab91c7d4ac6: doxy: Update the css to have a flat style [13:25] <cone-205> ffmpeg.git 03Michael Niedermayer 07master:7ad6515fd4b4: Merge remote-tracking branch 'qatar/master' [13:32] <BBB> I'm sleepy, just ignore me, it's easier [13:32] <ubitux> :) [13:32] <BBB> I missed that whole setence [13:32] <BBB> michaelni: merge of https://github.com/rbultje/ffmpeg/commits/vp9-simd please? [13:32] <BBB> I'll work on a 32x32 skeleton [13:33] <BBB> maybe in ~2 weeks or so that's finished [13:33] <BBB> how's lf? [13:33] <ubitux> in progress [13:33] <BBB> it's 27.4% of ffmpeg runtime here [13:33] <ubitux> https://github.com/ubitux/FFmpeg/compare/vp9-lpf [13:33] <BBB> where total video is like 70-80% or so [13:33] <BBB> so that's like 1/3rd [13:34] <ubitux> i'm doing filter2()/filter4() [13:34] <ubitux> filter14() is started [13:34] <ubitux> filter6() not started [13:34] <ubitux> rest of the function should be "done" [13:35] <ubitux> the flow can be done in different orders, so it's a bit chaotic right now [13:35] <ubitux> i'm trying to organize it so i can get enough reg when i need it [13:36] <ubitux> right now, i'm going for 1) calc flat8out/flat8in/hev 2) filter2()/filter4() 3) filter6() 4) filter14() [13:36] <BBB> yeah that looks good [13:37] <BBB> I mean we'd have to see the final assembly for the more specific comments, but the organization looks logical [13:38] <ubitux> i really enjoy writing that code btw [13:38] <ubitux> more than idct, because it looks like there are a lot of solution [13:38] <ubitux> it's somehow way more flexible [13:39] <BBB> that's the good and the bad part, right? [13:39] <BBB> it's more compartmentalized [13:39] <ubitux> i think it's a good thing :) [13:39] <BBB> but that also means you sometimes run the risk of doing the same calculation multiple times [13:39] <ubitux> i like that :p [13:40] <BBB> and for the perfect simd, you want to prevent that, but then you sometimes lose the compartmentalization again [13:40] <BBB> if you separate it too much, it becomes hard to do just that ;) [13:40] <ubitux> probably [13:40] <ubitux> but as you told me, it's indeed not really important [13:40] <ubitux> because on a whole 16x16 [13:40] <BBB> so the final code tends to be somewhat "messy" because it started pretty (look at vp8) and then I tried to do the final few instruction losses and then it got a little ugly at times [13:41] <ubitux> you basically can trigger every path [13:41] <ubitux> (even with branching i mean) [13:41] <ubitux> so i don't think it really matters [13:41] <BBB> yes [13:42] <ubitux> i'm looking forward the steps where it will work so i can start making it a spaguetti soup [13:42] <ubitux> :) [13:42] <BBB> e.g. limit() and fhev() both use abs(p1-p0) and abs(q1-q0) [13:42] <BBB> so you don't want to do that twice [13:42] <BBB> in vp8 [13:42] <BBB> vp9 might have something similar, I Don't remember [13:43] <ubitux> i reused a lot such thing already [13:43] <BBB> that's the sort of stuff where you can lose a few instructions but then it becomes a little bit intermingled [13:43] <BBB> ok cool [13:43] <BBB> then it'll be great [13:43] <ubitux> https://github.com/ubitux/FFmpeg/compare/vp9-lpf#diff-651121e4f3585d617f2de3... [13:43] <ubitux> i'm computing flat8in and hev at the same time here for instance [13:43] <BBB> ah yes [13:43] <BBB> nice [13:43] <ubitux> and i'm also reusing a lot the previous calculation [13:43] <BBB> well I'm glad you like it, I remember going quite crazy with lf at the end [13:44] <ubitux> :D [13:44] <ubitux> what i'm afraid of is not having enough reg for the filter14() [13:44] <ubitux> but i've a B plan @_@ [13:45] <ubitux> anyway, it will take me a little more time [13:45] <ubitux> i'll keep you up to date :p [13:45] <nevcairiel> not even enough regs on 64-bit? :p [13:45] <ubitux> not really [13:45] <ubitux> :( [13:46] <ubitux> as the name suggests, filter_14() needs 14 lines [13:46] <ubitux> of course it's possible to re-read N times [13:47] <ubitux> but i'm trying to reuse a maximum of values [13:47] <BBB> I think it's possible, because you need some pixels only for 2 things [13:47] <BBB> for the flat [13:47] <BBB> and then for the actual filter [13:47] <BBB> so you can prioritized these calculations before anything else [13:47] <BBB> and then drop that register [13:47] <BBB> also for intermediates, feel free to use stack, vp8 does that too on x86-32 [13:48] <BBB> using a bit of stack is fine for such things [13:48] <ubitux> no i don't need the stack [13:48] <BBB> ok that's even better [13:48] <ubitux> the plan was to compute the other small filters so i can free the flat8in & hev and just keep the final mask [13:49] <ubitux> but the filters requires some cache [13:49] <ubitux> typically [13:49] <ubitux> dst[stride * -7] = (p7 + p7 + p7 + p7 + p7 + p7 + p7 + p6 * 2 + p5 + p4 + p3 + p2 + p1 + p0 + q0 + 8) >> 4; [13:49] <ubitux> then [13:49] <ubitux> dst[stride * -6] = (p7 + p7 + p7 + p7 + p7 + p7 + p6 + p5 * 2 + p4 + p3 + p2 + p1 + p0 + q0 + q1 + 8) >> 4; [13:50] <ubitux> here i'm reusing the previous calculation without the shift [13:50] <ubitux> and i'm substracting p7 and p6, and adding p5 [13:50] <ubitux> it's nice to have those cached [13:51] <ubitux> also unpack/repack is taking twice the amount of reg [13:51] <ubitux> so it's a bit short sometimes [13:51] <ubitux> but it should be possible :) [13:52] <ubitux> the filter2()/filter4() is not fun though :( [14:05] <cone-205> ffmpeg.git 03Ronald S. Bultje 07master:0d9375fc908c: vp9/x86: 16x16 sub-IDCT for top-left 8x8 subblock (eob <= 38). [14:05] <cone-205> ffmpeg.git 03Ronald S. Bultje 07master:18175baa54ea: vp9/x86: 16px MC functions (64bit only). [14:05] <cone-205> ffmpeg.git 03Michael Niedermayer 07master:c09bb235bf25: Merge remote-tracking branch 'rbultje/vp9-simd' [14:11] <ubitux> BBB: you still haven't uploaded ped1080p.webm btw? [14:13] <ubitux> i realized that the etv* ones are actually pretty bad quality wise [14:13] <ubitux> even the recent etv5k have quite some blocks [14:15] <ubitux> http://i.imgur.com/ogvjRtV.png  like such area [14:15] <ubitux> (it's even worse in etv.webm and etv5000.webm) [14:32] <BBB> ubitux: not yet, will do this weekend [14:32] <ubitux> BBB: did you see my other regression crash btw? :p [14:32] <BBB> yes [14:32] <BBB> will look [14:32] <BBB> filter2/filter4 is similar to vp8, so feel free to look at them [14:33] <BBB> but yes they suck a bit [16:50] <funman> How can I debug this further? http://pastie.org/8580267 [16:50] <funman> ffmpeg version 2.1.1 [16:53] <ubitux> check with the cpuflags [16:53] <ubitux> like, is it reproducible with -cpuflags -mmx? [16:53] <funman> hm well I'm using vlc [16:54] <ubitux> you can't reproduce with ffmpeg/ffplay? [16:54] <funman> didn't try yet [16:54] <funman> I'll remove SWS_CPU_CAPS_MMX for now [16:58] <iive> funman: would you dissassemble a little around the point at fault? [16:58] <iive> actually, there is .c line number. [16:59] <ubitux> which is an inline asm macro [16:59] <funman> http://pastie.org/8580299 [17:00] <funman> http://pastie.org/8580308 [17:01] <ubitux> pointer looks valid [17:02] <ubitux> maybe some overread (odd or weird width maybe?), or a negative linesize somewhere (use of filters like vflip?) [17:06] <funman> http://pastie.org/8580333 [17:06] <funman> that's the context [17:09] <funman> hmm that's a C# app and mono doesn't like valgrind [17:11] <ubitux> VLC is a C# & mono app now? [17:12] <funman> you mean swscale is a C# & mono app [17:13] <funman> vlc has (several) C# bindings and mono is required to run C# afaik [17:14] <funman> ok I found the culprit [17:14] <funman> it's kodab [17:14] <funman> using width instead of coded_width gives me no crash anymore [17:15] <funman> although I wonder why I can't disable mmx code [17:16] <funman> cpu flags aren't given through getContext() anymore? [17:18] <ubitux> av_*_cpu_flags()? [17:18] <funman> how can I change that from vlc? [17:19] <funman> I see there's an av_parse_cpu_flags [17:19] <ubitux> av_force_cpu_flags()? [17:19] <funman> but sws_init_context uses av_get_cpu_flags() [17:19] <funman> ah right [17:19] <ubitux> see how opt_cpuflags() work in cmdutils.c [17:21] <funman> alright now it segfaults in C code [17:21] <ubitux> should be easier to debug :p [17:21] <ubitux> and you know it's a problem in the caller then [17:21] <funman> yeah [17:22] <funman> although it's still weird [17:28] <ubitux> funman: it's a regression? [17:28] <funman> in VLC yes [17:29] <funman> introduced by http://git.videolan.org/?p=vlc.git;a=commitdiff;h=b71c85b3d88b8d0ad2d4a63bf5... [17:32] <funman> and that particular one is fixed by http://git.videolan.org/?p=vlc.git;a=commitdiff;h=983198b0fc68d2e2bcfe98b6fe... [17:32] <funman> i_width = codec_width, i_visible_width = width [17:33] <iive> there is something I don't seem to get [17:33] <iive> the fault is in the last instructions of RGB_PACK16(). [17:34] <iive> they move %mm0 into (%1). but isn't %1 src[] ? [17:34] <iive> shouldn't it be writing packed rgb into the dst? [17:35] <ubitux> one width is larger than the other [17:35] <ubitux> afaiu [17:35] <ubitux> overread, boom [17:37] <iive> look at the fault instruction, is is write. [17:38] <iive> it is write. [17:39] <ubitux> dstw = srcw and src2w > srcw maybe? [17:40] <ubitux> overreading in src might be fine since it's actually src2w large [17:40] <ubitux> but dstw might have a width of the smallest announced size [17:45] <ubitux> iive: ah sorry, misread what you said; i guess it's an inplace thing :p [17:46] <iive> but... Y8->rgb16? [17:46] <iive> or rather yuv420/yv12->rgb16 [23:23] <PwrSurge> hi, anyone here working on MIPS optimization features? [23:23] <ubitux> hi, [23:23] <ubitux> better contact Nedeljko Babic first [23:24] <ubitux> he's the MIPS maintainer, and regularly send a large bunch of optimizations with some other mips folks [23:26] <PwrSurge> i'm doing embedded development on a mipsel board [23:27] <PwrSurge> was hitting my head against my desk as I could simply not understand why I kept getting "Illegal instruction" on my code after compiling for a new kernel version [23:27] <PwrSurge> lol [23:27] <PwrSurge> for a while, thought it was a bug in my new code [23:29] <PwrSurge> debugged with GDB and found out it was crashing when trying to call libavcodec.so [23:30] <PwrSurge> Program terminated with signal 4, Illegal instruction. [23:30] <PwrSurge> #0 0x76ea9f34 in ?? () from /data/buildsystem-cs/root/lib/libavcodec.so.55 [23:44] <cone-820> ffmpeg.git 03Michael Niedermayer 07master:4156df59f596: avformat/mov: check avio_read() return in mov_read_dref() [00:00] --- Sat Dec 28 2013