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

[burek]

[01:57] <cone-372> ffmpeg.git 03Michael Niedermayer 07master:2c635fabbf7e: avformat/isom: check avio_read() result
[01:57] <cone-372> ffmpeg.git 03Michael Niedermayer 07master:9b195dd5793e: avformat/4xm: shrink packet if it was only partially initialized
[04:30] <clever> Compn: and i have colors!
[09:25] <ubitux> erm
[09:25] <ubitux> valgrind is not happy at all&
[09:28] <ubitux> BBB: i think valgrind doesn't like what you did with the stack in 8d4c616fc05f2f3c76d13594788129df72069f30
[09:29] <ubitux> see what happened in c65fe9e..cc0e2ba: http://fate.ffmpeg.org/history.cgi?slot=x86_64-archlinux-gcc-valgrindundef
[09:30] <ubitux> 2089 ’ 1783 tests passing
[09:32] <ubitux> ==16153== Uninitialised value was created by a stack allocation ==16153== at 0xA52F49: ??? (vp9itxfm.asm:600)
[09:38] <ubitux> i don't see the problem, cglobal -512, loop1 +256*2, -512, loop2 +16*2, -32, RET (+512)
[09:40] <nevcairiel> doesnt say it overreads stack, just that it handles uninitialized values
[12:33] <cone-541> ffmpeg.git 03Justin Ruggles 07master:be7c323176e2: Add a libwebp encoder
[12:33] <cone-541> ffmpeg.git 03Michael Niedermayer 07master:6fe5f770db3a: Merge commit 'be7c323176e2e5fcf30e3d2ff20975b2f936811b'
[12:44] <BBB> ubitux: stack? valgrind doesn't check stack, only heap
[12:44] <BBB> ubitux: stack check is done by the other tool
[12:44] <BBB> I forgot its name
[12:46] <BBB> asan
[12:46] <BBB> anyway I can have a look
[12:47] <BBB> it's possible that we read 4 bytes for the dc (instead of 2) and it doesn't like that
[13:16] <cone-541> ffmpeg.git 03Guillaume Martres 07master:7398e0516f7f: hevc: move DSP declarations from hevc.h into hevcdsp.h
[13:16] <cone-541> ffmpeg.git 03Michael Niedermayer 07master:5410a5dc6608: Merge remote-tracking branch 'qatar/master'
[13:38] <BBB> ubitux: oh I have a hunch
[13:38] <BBB> ubitux: let's say I make a register that holds a stack value
[13:38] <BBB> ubitux: and the stack value is undefined
[13:38] <BBB> ubitux: then, let's say that I pxor that register with itself
[13:38] <BBB> ubitux: is the resulting value undefined?
[13:40] <nevcairiel> who knows if such an analyser is smart enough to figure that out
[14:44] <saste> priority=wish and type=enhancement are redundant 
[14:44] <saste> priority=wish IMHO doesn't make much sense
[14:44] <saste> an enhancement request can have a priority level
[15:06] <ubitux> BBB: no valgrind checks the stack as well for uninit
[15:06] <ubitux> BBB: note that the uninit appears in a later function
[15:07] <ubitux> (typically some C in DSP code)
[15:07] <BBB> yes, it's because it thinks we write uninitialized data in blockq, which is then used in the next transform
[15:07] <BBB> but the data is not uninitialized, it is a zero
[15:10] <ubitux> so you think it's a valgrind bug?
[15:10] <ubitux> it's strange that it doesn't spot such similar pattern elsewhere
[15:12] <cone-541> ffmpeg.git 03Mason Carter 07master:ed5bed415220: VC1: Fix intensity compensation performance regression
[15:12] <cone-541> ffmpeg.git 03Michael Niedermayer 07master:64b98df38910: vc1: simplify *_use_ic initialization
[15:12] <ubitux> BBB: are you sure it's not because you write only half of this reg or something?
[15:12] <ubitux> so some part is left uninit
[16:10] <cone-541> ffmpeg.git 03Mason Carter 07release/2.0:aeac212fda1b: VC1: Fix intensity compensation performance regression
[16:10] <cone-541> ffmpeg.git 03Mason Carter 07release/2.1:7eec11463fca: VC1: Fix intensity compensation performance regression
[17:58] <BBB> ubitux: not sure - but regardless, the output is fine so I think valgrind is braindead
[17:58] <ubitux> dunno&
[18:04] <BBB> also first version (not working ofc) of 2x2 16x16 pushed to my github
[18:05] <BBB> should have it working in a few hours or so, then will fix parallelmode bug, then will make a 32x32
[18:06] <ubitux> i'm still progressing on lpf
[18:11] <ubitux> BBB: btw, no faster way than punpcklbw(psraw(paddw(x,8),4), psraw(paddw(y,8),4))?
[18:11] <ubitux> (doing (A+8)>>4 word-wise twice and repack)
[18:14] <BBB> packuswb you mean?
[18:16] <BBB> why not paddsb(x, 4) and then pand(0xfc) and then psraw?
[18:18] <ubitux> oh
[18:18] <ubitux> you can actually do that byte wise?
[18:19] <BBB> that's why you pand
[18:24] <BBB> sorry had a phone call
[18:24] <BBB> the idea is to add in bytes
[18:24] <BBB> then clear the lowest 3 bits
[18:24] <BBB> so pand(0xf8)
[18:24] <BBB> and then shift in any unit (logical, not arithmetic)
[18:24] <BBB> so e.g. psrlw or psrlq or so
[18:25] <BBB> (if the lower bits are cleared, they all do the same thing)
[18:29] <ubitux> that will work with unsigned data right?
[18:31] <ubitux> i'm doing this part typically: dst[strideb * -7] = (p7 + p7 + p7 + p7 + p7 + p7 + p7 + p6 * 2 + p5 + p4 + p3 + p2 + p1 + p0 + q0 + 8) >> 4;
[18:32] <ubitux> i was doing the add word-wise, with the add and shift
[18:32] <ubitux> (and then repack because it doesn't stick in one reg)
[18:32] <ubitux> you're suggesting to do all the add byte-wise (so with saturation, 0xff max)
[18:32] <ubitux> wwww?
[18:32] <ubitux> -wwww
[18:33] <BBB> oh right, you can't do that in bytes
[18:33] <BBB> yes you have to do that in words
[18:34] <BBB> so like you did, just punpcklbw(data, zero) -> paddw(pixels) -> paddw(8) -> psraw(4) -> packuswb
[18:34] <ubitux> (yeah right packuswb for repacking might be better :p)
[18:34] <BBB> ;)
[18:36] <ubitux> por(packuswb(psraw(paddw(paddw(punpckhbw(x, 0), ...), 8), 4)), packuswb(psraw(paddw(paddw(punpcklbw(y, 0), ...), 8), 4)))
[18:36] <ubitux> probably something like that then
[18:40] <BBB> why por?
[18:41] <BBB> well anyway, yes in general something like that
[18:41] <ubitux> to combine the two repacked data
[18:41] <ubitux> but i'm certainly thinking it wrong
[18:41] <ubitux> i'm not familiar enough with those instr.
[18:42] <BBB> doesn't packuswb do that?
[18:42] <ubitux> ah so one packuswb call with the two?
[18:42] <ubitux> mmh makes sense
[18:42] <BBB> x = packuswb(x, y) is like the inverse of x = punpcklbw(data, 0); y = punpckhbw(data, 0)
[18:42] <BBB> or data = packuswb(x, y) is the inverse of x = punpcklbw(data, 0); y = punpckhbw(data, 0)
[18:43] <ubitux> great, then packuswb( psraw(paddw(paddw(punpcklbw(x, 0), ...), 8), 4)), psraw(paddw(paddw(punpckhbw(x, 0), ...), 8), 4)) )
[18:43] <ubitux> so no simpler way? :P
[18:43] <BBB> no sorry :-p
[18:44] <ubitux> :(
[18:44] <ubitux> i would be grateful to have something like 64 or 128 reg
[18:45] <BBB> you'll love pshufb
[18:45] <ubitux> i'm surprised thre is no "round packing" instr
[18:45] <ubitux> i used a lot pshufb in my previous attempt
[18:45] <ubitux> but i don't see much usage here
[18:46] <BBB> and palignr
[18:46] <BBB> look into that
[18:46] <BBB> yes rounded pack woule bs useful I've wondered about that too
[18:46] <BBB> basically a combination of how we use mulhrsw and packuswb
[18:46] <BBB> but maybe just with a shift amount instead of a full multiplier
[18:48] <BBB> suggest that to intel ;)
[18:49] <ubitux> :)
[18:49] <ubitux> i'll suggest plpfvp9 instead
[18:51] <BBB> uhm right
[18:51] <BBB> yes
[18:51] <BBB> that's highly likely to make it
[18:51] <ubitux> :))
[18:52] <BBB> palignr is useful for what you're doing above though
[18:52] <ubitux> i was reading that
[18:52] <BBB> if you have a reg containing p7,6,5,4,3,2,1,0 and another containing q0, 1,2,3,4,5,6,7
[18:53] <BBB> you can shift them into halfcombinations using palignr
[18:54] <ubitux> i think i'm doing it the other way around
[18:55] <ubitux> like doing the line i pasted with all p7 + all p7 + all p7 + ... + all p4 + all p3 ...
[18:55] <ubitux> reg contains only one p/q
[18:55] <ubitux> (or a sum, which i can substract for the later line)
[18:56] <ubitux> but i'm just probably highly confused at what you are trying to tell me :P
[19:00] <ubitux> palignr/pshufb are certainly extremely useful the other way around, like i was doing previously
[19:01] <BBB> hm I guess you're right, yes
[19:02] <BBB> I forgot the adds are vertical
[19:02] <BBB> that's actually useful
[19:02] <BBB> palignr is slow
[19:03] <cone-897> ffmpeg.git 03Michael Niedermayer 07master:de2a2caf4ded: nutenc/write_index: warn if 2 consecutive keyframes have the same PTS and discard the 2nd
[19:31] <j-b> 'morning
[19:45] <michaelni> evening
[19:45] <jnvsor> evening
[19:46] <jnvsor> Ran into a bug where on debian sid when compiled with --enable-libopencv and using a `-f pulse` input ffmpeg doesn't respond to SIGINT
[19:47] <jnvsor> Affects avconv too. Dissapears when run under valgrind. Any ideas?
[20:02] <michaelni> jnvsor, which version of ffmpeg is that ? and how to reproduce ? 
[20:08] <jnvsor> git HEAD - on debian sid, let me make a pastebin
[20:09] <jnvsor> michaelni: http://pastebin.com/0PWKG3fG
[20:10] <jnvsor> q still stops it, and running it in valgrind makes it work too
[20:11] <jnvsor> I wanted to git-bisect it but I keep getting "No rule to make target" on older versions
[20:15] <michaelni> jnvsor, does this also happen without --enable-shared ?
[20:16] <jnvsor> I'll recompile and find out
[20:22] <jnvsor> Yep, still happens
[20:25] <michaelni> probably best if you open a ticket on https://trac.ffmpeg.org/
[20:26] <jnvsor> Righty then
[20:30] <cone-897> ffmpeg.git 03Michael Niedermayer 07master:88956f73f29c: ffmpeg: use timestamp from before and after the decoder to detect backward moving dts for discontinuity detection
[20:30] <cone-897> ffmpeg.git 03Michael Niedermayer 07master:102b794e0948: configure: support raising major version in soname
[21:01] <jnvsor> How long does it usually take for a registration email from trac?
[21:05] <michaelni> should be very quick
[21:05] <ubitux> check your spam
[21:06] <jnvsor> Hmm, I asked for a resend twice - it's been about 30 minutes since registration. I checked spam
[21:07] <michaelni> hmm, beastd, are trac mails working (see above)
[21:07] <ubitux> try to nag beastd 
[21:09] <Timothy_Gu> jnvsor: it shouldn't take very long. 5 minutes max I guess
[21:11] <jnvsor> Well I've even tried the web interface *shudder* - I thought maybe you do mails in a cron job or something
[21:21] <ubitux> any idea how to change an xmm reg value within gdb?
[21:21] <ubitux> (gdb) set $xmm4.uint128 = 0x2a2929282a2b2c2c2c2b2c2f31333536
[21:21] <ubitux> Numeric constant too large.
[21:21] <ubitux> something like that, that works
[21:25] <michaelni> jnvsor, beastd: Dec 22 20:29:31 ... to=<jonathan-vola at ...>, relay=mx2.hotmail.com[65.54.188.110]:25, delay=2.3, delays=1/0/0.53/0.71, dsn=2.0.0, status=sent (250 <BAY0-MC3-F49X1TMgPE00456129 at BAY0-MC3-F49.Bay0.hotmail.com> Queued mail for delivery)
[21:26] <jnvsor> Sent already or just queued? I've still got nothing here
[21:26] <michaelni> iam no mail expert but status=sent to me sounds like it was sent
[21:27] <jnvsor> Yeah, don't suppose you could nab the token so I could activate it?
[21:28] <ubitux> > hotmail
[21:28] <jnvsor> I know, I know :P
[21:29] <Timothy_Gu> Once Hotmail/Outlook ate one of my library overdue notice, and I had to pay $10...
[21:29] <jnvsor> Outlook? Give me a little credit :P
[21:31] <Timothy_Gu> I used Hotmail since I was 5 (seriously) and now I completely dumped that.
[21:32] <jnvsor> Can't think of a good alternative that would warrant the change.
[21:52] <cone-897> ffmpeg.git 03Mason Carter 07master:61ae993957f8: vc1: Fix intensity compensation performance regression
[21:52] <cone-897> ffmpeg.git 03Michael Niedermayer 07master:c19f193c6b23: Merge remote-tracking branch 'qatar/master'
[22:21] <cone-897> ffmpeg.git 03Ivan Kalvachev 07master:1c63aed232fe: Convert XvMC to hwaccel v3
[22:32] <jnvsor> Allrighty, I've narrowed the sigint bug down to a combination of gnutls and libopencv
[22:50] <beastd> jnvsor: Did it arrive in the meantime?
[22:53] <cone-897> ffmpeg.git 03Michael Niedermayer 07master:911676c64374: avutil/avstring: add av_strnlen()
[23:01] <jnvsor> micheal send me the token
[23:01] <jnvsor> I've spent an hour bisecting the configure, now I have an exact list of options - remove any one of these and the bug dissapears...
[23:01] <jnvsor> They seem totally unrelated
[23:03] <beastd> jnvsor: sounds nasty
[23:03] <beastd> jnvsor: still strange that the email didn't arrive...
[23:04] <jnvsor> Yeah, I had it send 3, so 3 in a row didn't arrive
[23:04] <jnvsor> If trac is working it must be hotmail
[23:05] <beastd> worked for at least 3 people today (probably more I did not look that close)
[23:11] <jnvsor> So basically libopencv + gnutls + shlibdir + pulse input = no sigint response
[23:22] <BBB> ubitux: ok that works now, still need to do performance metrics
[23:22] <BBB> ubitux: will try to finish that tonight, submit patches for merge and then work on parallelmode bug
[23:23] <ubitux> OTOH packuswb doesn't work for me :p
[23:23] <BBB> awh
[23:23] <BBB> I'm sorry
[23:23] <BBB> what did it do to you?
[23:23] <ubitux> 13: /x $xmm4.uint128 = 0x0000fc2c0000fcf00000028400000688
[23:23] <ubitux> 12: /x $xmm5.uint128 = 0x0000fa390000f9390000fa1b0000fbdc
[23:23] <ubitux> => 13: /x $xmm4.uint128 = 0x00000000000000000000000000ff00ff
[23:23] <ubitux> not exactly what i expected
[23:23] <ubitux> :D
[23:24] <ubitux> (yes the input values look weird as well)
[23:24] <ubitux> probably a shitload of bugs previously :p
[23:27] <ubitux> (ah i used punpck*wd instead of the bw)
[23:28] <ubitux> actually it works now :p
[23:29] <BBB> lol
[23:29] <BBB> well that's good
[23:30] <ubitux> anyway, WIP still @ https://github.com/ubitux/FFmpeg/compare/vp9-lpf
[23:31] <ubitux> i'm assuming it will be mostly straightforward now until 4w/2w code
[23:31] <ubitux> it's fun
[23:31] <ubitux> i really like that :D
[23:35] <BBB> good :)
[00:00] --- Mon Dec 23 2013