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

[burek]

[01:16:48 CEST] <DHE> Fixing #4900 wasn't too hard actually... testing it, then I'm submitting to the list
[01:22:21 CEST] <cone-099> ffmpeg 03Carl Eugen Hoyos 07master:ac7b1f742324: lavfi/mandelbrot: Output RGB0 instead of RGBA.
[01:26:59 CEST] <J_Darnley> What is the point of this fate-source test?  Won't that just always fail when ever someone adds something?
[01:30:56 CEST] <J_Darnley> Oh it is isn't very helpful when it says "see somefile.err for details" but that file is empty.
[01:31:57 CEST] <J_Darnley> Oh
[01:32:08 CEST] <J_Darnley> that's the new license header check
[02:08:59 CEST] <atomnuker> a pic32f running at 70 Mhz can decode mp3s
[02:09:13 CEST] <atomnuker> an ARM compared to that is a supercomputer
[02:09:36 CEST] <atomnuker> yet mobile phones nowadays ship and use hardware decoders for a few audio formats
[02:10:55 CEST] <atomnuker> I doubt many manufacturers actually measure if this saves battery life, they just do it because it's become a de-facto standard
[02:19:01 CEST] <cone-099> ffmpeg 03Michael Niedermayer 07master:94d50b5d00ce: avformat/rtmpproto: Fix 2 more cases of the 2nd packet size being wrong
[02:20:02 CEST] <wm4> atomnuker: maybe even to simplify firmware
[03:33:27 CEST] <cone-099> ffmpeg 03Carl Eugen Hoyos 07master:da767f06f50f: lavf/rawdec: Autodetect raw TrueHD streams.
[03:41:55 CEST] <cone-099> ffmpeg 03James Almer 07master:acdd6725065b: x86/audio_convert: fix clobbering of xmm registers
[04:53:27 CEST] <cone-099> ffmpeg 03Christophe Gisquet 07master:562ba4a827ce: blockdsp: remove high bitdepth parameter
[07:37:34 CEST] <qrtt1> hello, good evening (from +8)
[09:22:35 CEST] <qrtt1> I compile the seek_print.c, and try to run it, then get the "seek:stream:min_ts:ts:max_ts:flags". Is there an example to use it ?
[09:40:23 CEST] <durandal_1707> atomnuker: how is assim going?
[09:40:59 CEST] <durandal_1707> gonna write apsnr?
[10:38:37 CEST] <cone-132> ffmpeg 03Paul B Mahol 07master:1d7d8244943c: avfilter/af_rubberband: add process_command()
[11:20:56 CEST] <durandal_1707> so is it ok to push tinterlace patch?
[12:40:35 CEST] <wm4> nevcairiel, michaelni__: so are you ok with my videotoolbox patches?
[12:45:22 CEST] <durandal_1707> is it ok to push maskedmerge asm?
[13:13:00 CEST] <michaelni__> wm4, iam no videotoolbox dev so no objection from me. about the h264 patch, the 1 << 16 is a bit big, i hope that could be made smaller but no real objection either
[13:14:44 CEST] <wm4> michaelni__: it's relatively bug, but I didn't find a real upper bound, other than the 16 bit per-sps/pps length fields in the mp4-style extradata, so I went with that
[13:14:48 CEST] <wm4> *big
[13:15:04 CEST] <wm4> also the SPS/PPS structs are allocated dynamically, so I'm thinking it's not so bad
[13:17:24 CEST] <michaelni__> to find a good upper bound someone probably would have to calculate it from the h264 spec ... not really fun work
[13:20:53 CEST] <michaelni__> but my feeling says that it should be alot smaller than 64k
[13:21:21 CEST] <J_Darnley> durandal_1707: is your latest patch on the ml?
[13:22:56 CEST] <durandal_1707> J_Darnley: no, I have some changes locally
[13:23:51 CEST] <J_Darnley> Did you get anywhere with using newer than sse2 instructions?
[13:28:51 CEST] <J_Darnley> If you didn't and your changes are the changes mentioned on the ML in reply to other people's comments then I think the patch was okay to push.
[13:30:21 CEST] <durandal_1707> I didnt tried newer instructions
[13:30:58 CEST] <durandal_1707> J_Darnley: do you see easy way to add them?
[13:31:35 CEST] <durandal_1707> for example instruction that do mul and shift at once
[13:31:47 CEST] <J_Darnley> No but them I'm not very good at using the "fancy" instructions.
[13:33:04 CEST] <J_Darnley> The only one I can immediately tell you how to use is pmovzxbw which Henrik mentioned.
[13:33:53 CEST] <J_Darnley> Even then I'm not sure its worth it.
[13:59:50 CEST] <Daemon405> michaelni__ / wm4 / nevcairiel - any opinion on my locking patch? Luca is going to push the version I sent to libav soon (i wasn't aware until today).
[14:00:01 CEST] <Daemon405> i would like to stop him if there's any concerns
[14:00:16 CEST] <nevcairiel> i'll give it another look
[14:00:20 CEST] <Daemon405> plus ffmpeg's version is quite different, and we should push that + skip the merge of the libav one
[14:06:10 CEST] <wm4> Daemon405: took another look (at luca's new libav patch), seems ok
[14:07:22 CEST] <Daemon405> wm4, peek at ffmpeg's too
[14:07:23 CEST] <Daemon405> it differs
[14:07:28 CEST] <Daemon405> due to the locking functions in ffmpeg
[14:07:31 CEST] <Daemon405> and that recursive open func
[14:07:50 CEST] <Daemon405> mostly to double check.
[14:08:53 CEST] <nevcairiel> looks fine to me
[14:09:13 CEST] <nevcairiel> next up, going through all the codecs and flag threadsafe if appropriate? =p
[14:09:21 CEST] <nevcairiel> most of them probably are
[14:12:12 CEST] <Daemon405> nevcairiel, yes
[14:12:17 CEST] <Daemon405> i have h264 and aac threadsafe locally
[14:12:25 CEST] <Daemon405> and it's been tested at work for a few days without issue
[14:12:44 CEST] <Daemon404> eventually the lock can be killed
[14:12:45 CEST] <Daemon404> i hope.
[14:12:57 CEST] <nevcairiel> maybe, maybe not
[14:13:08 CEST] <nevcairiel> depends on external libraries being not so crazy
[14:13:21 CEST] <Daemon404> pthread_once bruh
[14:13:32 CEST] <nevcairiel> that still assumes the library is somewhat sane
[14:13:32 CEST] <nevcairiel> :D
[14:13:36 CEST] <Daemon404> lol
[14:13:42 CEST] <Daemon404> how would they even break that?
[14:13:56 CEST] <nevcairiel> closing context deletes global state, what do i know
[14:13:58 CEST] <nevcairiel> they find a way
[14:14:18 CEST] <Daemon404> oh.
[14:14:20 CEST] <Daemon404> you made me sad.
[14:14:40 CEST] <nevcairiel> (although that particular example would just crash today as well)
[14:14:49 CEST] <nevcairiel> when used in parallel
[14:15:03 CEST] <Daemon404> it *might* crash
[14:15:09 CEST] <Daemon404> ;)
[14:16:25 CEST] <wm4> hm, ffmpeg always locked?
[14:16:29 CEST] <wm4> even for thread-safe codecs
[14:16:34 CEST] <nevcairiel> so did libav
[14:16:38 CEST] <nevcairiel> but yes
[14:17:07 CEST] <wm4> oh right, libav also does
[14:17:16 CEST] <wm4> so I wonder what other hidden thread-unsafe things there might be
[14:17:24 CEST] <nevcairiel> all the flag did was suppress the error if no lockmgr was available
[14:17:40 CEST] <nevcairiel> which is kind of a weird idea
[14:18:01 CEST] <Daemon404> wm4, very few codecs have that flag right now
[14:18:09 CEST] <Daemon404> and theyre all simple ones
[14:18:11 CEST] <Daemon404> should be pretty safe
[14:18:20 CEST] <Daemon404> nevcairiel, yeah
[14:18:49 CEST] <wbs> nevcairiel: it was only added as a fix for the case when one codec internally opens another one, which failed previosuly (due to the engangled thread counter), but was skipped with this flag
[14:19:11 CEST] <Daemon404> wbs, ffmpeg has some separate func for that too
[14:19:15 CEST] <wm4> well looks ok to me then
[14:19:17 CEST] <Daemon404> ff_open_recursive or something
[14:19:23 CEST] <wbs> Daemon404: I see
[14:19:41 CEST] <Daemon404> wbs, btw while lookign at this, i noticed libav does not use atomics for the entangled trhead counter
[14:19:44 CEST] <Daemon404> probably should
[14:19:48 CEST] <Daemon404> i can backport that fix i gues
[14:19:49 CEST] <Daemon404> s
[14:20:34 CEST] <nevcairiel> i always forget the rules, isnt a volatile int supposed to be accessed atomicly on x86 anyway?
[14:20:40 CEST] <nevcairiel> (i know, other platforms)
[14:20:47 CEST] <kierank> nevcairiel: from what I understand it is legal to put an sps/pps in the previous ts packet
[14:20:56 CEST] <Daemon404> nevcairiel, one arch isnt good enough
[14:20:59 CEST] <Daemon404> also i forget too
[14:21:19 CEST] <nevcairiel> kierank: why not, it just screws up the parser right now :d
[14:21:43 CEST] <wm4> I think volatile barely means anything on x86
[14:21:53 CEST] <wm4> you are encouraged to use weak atomics instead
[14:22:15 CEST] <wm4> volatile has a special meaning wrt. signals and also longjmp
[14:24:58 CEST] <nevcairiel> apparently reads of native-sized elements are just always atomic, screw volatile
[14:27:10 CEST] <DHE> volatile was meant to inform the compiler that it should not cache variables in registers or make assumptions that they won't change outside its knowledge.
[14:27:32 CEST] <DHE> in theory anyway... with threading, etc being normal I don't know how much that still stands
[14:27:44 CEST] <wm4> nevcairiel: btw. your opinion about my videotoolbox patch?
[14:29:29 CEST] <atomnuker> durandal_1707: not much point in apsnr since tiny_psnr is useless for making quality comparisons, which is what I'm interested in
[14:30:09 CEST] <nevcairiel> wm4: all i know is that I would like to hurt apple for building something thats different to everything else in the world ... again
[14:30:45 CEST] <wm4> isn't it wonderful
[14:31:10 CEST] <wm4> (but to be honest, this whole mp4 and evne h264 sps/pps thing is crap in the first place)
[14:32:02 CEST] <Daemon404> BBB, ping when around, re: date for dinner.
[14:32:06 CEST] <BBB> pong
[14:32:13 CEST] <Daemon404> ohai
[14:32:22 CEST] <Daemon404> PM
[14:35:40 CEST] <ubitux> 14:24 <@nevcairiel> apparently reads of native-sized elements are just always atomic, screw volatile // on every arch? iirc using the atomic gcc builtin do not generate the same code on arm (even read) 
[14:35:59 CEST] <ubitux> (what about mips & friends?)
[14:36:07 CEST] <nevcairiel> mips has no friends
[14:36:20 CEST] <ubitux> :D
[14:36:27 CEST] <ubitux> btw, helgrind doesn't like unprotected read
[14:37:10 CEST] <ubitux> but well, we've already thousands of "errors" in that spirit
[14:37:18 CEST] <BBB> helgrind doesnt find real bugs
[14:37:20 CEST] <BBB> :-p
[14:37:48 CEST] <nevcairiel> wm4: i think you could limit the max size of the sps/pps fields quite a bit though, its never possible to be that large
[14:38:10 CEST] <nevcairiel> use 1024 or something, thats already way larger then possible
[14:38:26 CEST] <ubitux> BBB: it does
[14:38:38 CEST] <J_Darnley> A quick patch policy question:
[14:38:38 CEST] <J_Darnley> I want to create a new header file for assembly constants. Using this in the existing files will require adding one line and removing some now redundant others.
[14:38:38 CEST] <J_Darnley> A quick search tells me that I will touch 41 files in libavcodec alone. Should I commit each file separately, them all together, or group them slightly (perhaps by codec)?
[14:38:38 CEST] <ubitux> BBB: but it hides them too
[14:38:47 CEST] <BBB> yikes
[14:39:14 CEST] <ubitux> J_Darnley: squash them
[14:39:50 CEST] <J_Darnley> All into one patch you mean?
[14:40:07 CEST] <ubitux> yeah, it's simpler
[14:40:14 CEST] <wm4> nevcairiel: looking at the standard, this seems a bit conservative, though I find that part hard to read
[14:40:33 CEST] <nevcairiel> the only "hard" part is that there are variable length codes in the sps/pps
[14:40:35 CEST] <ubitux> (but feel free to split)
[14:40:54 CEST] <nevcairiel> but even those have somewhat of a upper limit, otherwise the ffmpeg parser just fails on them
[14:42:09 CEST] <wm4> michaelni__: do you give an ok for an upper limit of 1024 bytes for sps/pps NAL units?
[14:47:15 CEST] <michaelni__> wm4, sure
[14:47:35 CEST] <nevcairiel> apparently the exp-golomb codes use up to 31 bits max, so even if i count 4 bytes for every variable-length code, thats still way big
[14:47:45 CEST] <wm4> then I'll push these patches with the data fields changed to 1024
[14:48:03 CEST] <wm4> nevcairiel: to me it looks like these scaling matrices can have 480 values in total
[14:48:13 CEST] <nevcairiel> lets see
[14:49:55 CEST] <nevcairiel> guess that could be the case
[14:50:16 CEST] <nevcairiel> would be one odd scaling list to code all values in 31 bit symbols, but i guess
[14:50:22 CEST] <nevcairiel> make it 4k then for paranoia
[14:50:41 CEST] <wm4> I'm content with this
[14:50:55 CEST] <michaelni__> +1
[15:08:07 CEST] <cone-712> ffmpeg 03Derek Buitenhuis 07master:abaa12263e08: avcodec: Don't lock during open if the codec has threadsafe init
[15:13:51 CEST] <BBB> Gramner: do you also feel like reviewing my other intra pred simd patch (dc/tm/h/v)?
[15:14:00 CEST] <BBB> Gramner: that one is a lot simpler so it shouldnt take terribly long
[15:19:27 CEST] <BBB> Gramner: and lastly, thanks for review!
[15:19:36 CEST] <BBB> (youre the only one reviewing my crazy asm patches :/)
[15:41:37 CEST] <durandal_1707> looks like dcaenc and ffdcaenc disappeared from internet
[15:42:39 CEST] <nevcairiel> someone naming their standalone thing ffdcaenc was total fail anyway
[15:42:50 CEST] <nevcairiel> i always thought he was walking about the ffmpeg version
[16:15:01 CEST] <BBB> durandal_1707: internetarchive?
[16:25:48 CEST] <durandal_1707> dcaenc page is still available but not with google results
[17:04:12 CEST] <Daemon404> does ffmepg github no longer sync?
[17:07:04 CEST] <durandal_1707> I think michaelni manually pushes
[17:07:16 CEST] <Daemon404> what happened to the sync script?
[17:07:35 CEST] <Daemon404> and maybe make it a git post-push hook?
[17:45:57 CEST] <cone-712> ffmpeg 03Paul B Mahol 07master:160556c9ad16: avfilter/vf_maskedmerge: add SIMD for maskedmerge with 8 bit depth input
[18:12:14 CEST] <cone-712> ffmpeg 03Christophe Gisquet 07master:7e4070d2e70b: dnxhddec: initialize with mb-aligned dimensions
[18:12:15 CEST] <cone-712> ffmpeg 03Christophe Gisquet 07master:c7e14a279fa7: dnxhddec: use dequantization formula from specs
[18:12:16 CEST] <cone-712> ffmpeg 03Christophe Gisquet 07master:74ef5449a6fb: dnxhddec: init scantable once permutation is set
[18:15:46 CEST] <durandal_1707> 200fps -> 600fps
[18:17:53 CEST] <BBB> librtmpf!
[18:17:56 CEST] <BBB> I KNEW IT!
[18:18:09 CEST] <BBB> muhahahahahhahahahahahahha
[18:18:24 CEST] <BBB> this whole bullcrap rant I did a few years ago when librtmp came about
[18:18:58 CEST] <BBB> durandal_1707: btw nice job on your first simd! (I should say something nice every time I rant)
[18:21:13 CEST] <wm4> BBB: well, the lavf rtmp code isn't really beautiful either (why the fuck does it mux to flv)
[18:21:31 CEST] <BBB> Im sure it isn't
[18:21:52 CEST] <BBB> and Im also quite sure that reimplementing it from scratch outside lavf A) doesnt fix it and B) isnt right
[18:22:24 CEST] <wm4> don't know, what are its goals?
[18:22:36 CEST] <BBB> maybe the goals are wrong and we should delete the code
[18:22:47 CEST] <BBB> x264 was done outside ffmpeg and it did quite well for itself
[18:23:03 CEST] <wm4> I mean rtmpf's
[18:23:13 CEST] <Daemon404> where are you guys seeing this
[18:23:20 CEST] <wm4> ML
[18:23:28 CEST] Action: Daemon404 didnt see it
[18:23:31 CEST] <BtbN> What even is rtmfp?
[18:23:43 CEST] <wm4> "I am working on a new library that will implements the RTMFP protocol's client part. "
[18:23:49 CEST] <wm4> so maybe it's a new protocol?
[18:23:56 CEST] <Daemon404> o there it is
[18:24:29 CEST] <Daemon404> https://en.wikipedia.org/wiki/Real_Time_Media_Flow_Protocol
[18:24:46 CEST] <Daemon404> basically a udp rtmp
[18:25:35 CEST] <Daemon404> also he stated why it was separate
[18:25:38 CEST] <wm4> sounds "great"
[18:25:40 CEST] <Daemon404> business reasons
[18:25:41 CEST] <Daemon404> afaict
[18:26:08 CEST] <wm4> why isn't there a streaming protocol that actually works
[18:28:57 CEST] <kierank> there is
[18:28:59 CEST] <kierank> it's called udp
[18:29:24 CEST] <kierank> I can understand separate libs if the libs have functionality not available in the ffmpeg API
[18:29:57 CEST] <BtbN> so far rtmp did a good job for me.
[18:30:16 CEST] Action: kierank is going to write a paper soon about why rtmp sucks
[18:30:22 CEST] <wm4> kierank: udp/ip? that's too low level to be called a streaming protocol at all
[18:30:35 CEST] <kierank> just send mpegts over udp
[18:30:37 CEST] <kierank> ...done
[18:30:41 CEST] <kierank> add rtp header if you wish
[18:31:18 CEST] <BtbN> That can't prioritize I frames though
[18:31:20 CEST] <durandal_1707> what is ABS instruction in sse2
[18:31:36 CEST] <kierank> BtbN: yes it can with DSCP
[18:32:11 CEST] <wm4> what about seeking
[18:32:39 CEST] <kierank> there's an rtp protocol for that
[18:33:09 CEST] <kierank> the only thing it lacks is proxy server support
[18:33:11 CEST] <kierank> but meh tcp
[18:39:00 CEST] <Compn> kierank :  your paper does not have to be long "rtmp sucks" . :)
[18:43:01 CEST] <J_Darnley> durandal_1707: there isn't one
[18:43:38 CEST] <J_Darnley> uh well, I assume you mean equivalent of C's abs()
[18:44:27 CEST] <J_Darnley> Look at what I did in removegrain, I used many in there
[19:12:49 CEST] <wm4> videotoolbox is weird, it still refuses the decode a specific mkv sample via hardware
[19:12:55 CEST] <wm4> but if you allow sw decoding, it works
[19:13:11 CEST] <wm4> (of course the sample works perfectly fine on other OSes with the same hw)
[19:14:04 CEST] <wm4> and it fails already at decoder creation, so it has something to do with extradata
[19:14:47 CEST] <J_Darnley> durandal_1707: in your blend SIMD you can use paddusb and psubusb to add and subtract with saturation.
[19:15:46 CEST] <cone-712> ffmpeg 03wm4 07master:069190f7078e: avcodec/h264: keep SPS and PPS bitstream data
[19:15:47 CEST] <cone-712> ffmpeg 03wm4 07master:16aac9a35919: avcodec/videotoolbox: fix decoding of some h264 bitstreams
[19:19:09 CEST] <BBB> durandal_1707: pabsw is a ssse3 instruction
[19:19:44 CEST] <BBB> durandal_1707: so ABS is a compat thing for sse2
[19:19:53 CEST] <BBB> durandal_1707: we have multiple of these types of macros in x86util.asm
[19:20:20 CEST] <BBB> durandal_1707: its totally ok to not care and just say my code is ssse3 btw, dont feel force to use these macros unless sse2 compat is a requirement for you
[19:24:32 CEST] <jamrial> BBB: it's worth having an sse2 version if the only change needed is using any of the ABS macros
[19:25:03 CEST] <BBB> sure, but it can always be done later as a separate patch
[19:26:59 CEST] <durandal_1707> J_Darnley: done
[19:38:36 CEST] <andrewrk> did everybody see FLIF in the news today?
[19:38:44 CEST] <andrewrk> pretty intriguing
[19:39:06 CEST] <wm4> we laughed at the source code
[19:39:21 CEST] <wm4> (let's say they're not really following good practices)
[19:45:48 CEST] <jamrial> durandal_1707: see https://github.com/jamrial/FFmpeg/commit/40fc73db28cd9a0fd4aff4284b23a3f5350490f5
[19:45:57 CEST] <jamrial> what i'm doing here is making the function access most linesize, width and height arguments directly from stack
[19:46:19 CEST] <jamrial> that way the function can work with only 7 gprs
[19:46:54 CEST] <jamrial> you can do the same with the blend stuff you sent a few minutes ago. but again you need to make the pointers the first couple arguments for those
[19:48:35 CEST] <andrewrk> wm4, if the DSP is sound it should be fine
[19:48:39 CEST] <andrewrk> bad source code can be fixed
[19:48:42 CEST] <andrewrk> easy
[19:49:39 CEST] <wm4> well, at this quality level, I wouldn't be surprised if it's not actually lossless
[19:49:43 CEST] <wm4> but yeah, we'll see
[19:50:11 CEST] <andrewrk> what's actually the problem?
[19:50:17 CEST] <andrewrk> I'm looking at it right now
[19:50:36 CEST] <andrewrk> it looks pretty straightforwar
[19:50:42 CEST] <andrewrk> *straightforward
[19:51:30 CEST] <andrewrk> I guess more c++ than this crowd (including me) would care for
[19:55:27 CEST] <atomnuker> goddamnit
[19:55:38 CEST] <atomnuker> max_samples isn't respected for multiple input filters
[19:56:32 CEST] <atomnuker> any other way to force filtering only N amount of samples per frame?
[19:56:39 CEST] <wm4> andrewrk: no, it's awful beyond that
[19:57:13 CEST] <wm4> but yeah, maybe the algorithms are fine (apart from the fact that it uses patented algorithms, despite claiming otherwise)
[19:58:16 CEST] <durandal_1707> atomnuker: see what sidechaincompress does, also amerge IIRC
[20:06:00 CEST] <Daemon404> [18:51] < andrewrk> I guess more c++ than this crowd (including me) would care for <-- mixing c/c++ strings, using a vector of strings for stuff, pollutes the global namespace with generic names
[20:06:11 CEST] <Daemon404> mixes_snake_case_andCamel_case
[20:06:16 CEST] <Daemon404> (within teh same func names)
[20:06:21 CEST] <Daemon404> in general it's all over the place
[20:06:46 CEST] <andrewrk> ehh that stuff isn't really a big deal
[20:06:58 CEST] <Daemon404> there's one part where it just copypastes the same code 3-4 times in a row because "it seems to fix it"
[20:07:09 CEST] <andrewrk> especially mixing case convention. who cares? the CPU doesn't
[20:07:25 CEST] <andrewrk> ok that last thing is suspicious.
[20:07:32 CEST] <Daemon404> look at its commit log.
[20:07:37 CEST] <Daemon404> also i certainly care that it has an actually usable library interface
[20:07:52 CEST] <Daemon404> and has actual checks for failure
[20:09:01 CEST] <Daemon404> VLAs initialized with user provided sizes
[20:09:44 CEST] <Daemon404> asserts used instead of ifs
[20:09:49 CEST] <Daemon404> (im just looking over random files atm)
[20:09:59 CEST] <andrewrk> I care about that too, but the guy admits it's work in progress
[20:10:14 CEST] <Daemon404> also the format is not patent free
[20:10:16 CEST] <Daemon404> as the page claims
[20:10:20 CEST] <andrewrk> yes that is a big problem
[20:10:58 CEST] <Daemon404> there's a difference between WIP and complete lack of any standard IMO
[20:11:03 CEST] <Daemon404> but i guess i have different standards
[20:11:26 CEST] <Daemon404> im also very iffy on the whole "hey lets make yet another new lossless image format" thing
[20:11:42 CEST] <Daemon404> history shows: compression gains simply are not enough to drive adoption.
[20:12:45 CEST] <Daemon404> next thing i notice: a library that prints to stderr (bad)
[20:13:28 CEST] <Daemon404> skeptical would be the right word for me.
[20:13:32 CEST] <andrewrk> fair enough
[20:13:46 CEST] <andrewrk> I get the impression that the author is in a "research" phase and plans to make a cleaner and more optimized version once that phase is done
[20:13:56 CEST] <Daemon404> youve never worked in academia have you
[20:14:02 CEST] <Daemon404> that 2nd phase never happens
[20:14:03 CEST] <andrewrk> actually I have
[20:14:04 CEST] <Daemon404> you cant publish that
[20:14:27 CEST] <Daemon404> (ok, extremely rarely, it does)
[20:17:23 CEST] <Daemon404> (and i'd be thrilled to be wrong here, fwiw)
[20:17:31 CEST] <andrewrk> :)
[20:19:29 CEST] <Daemon404> also it could be worse
[20:19:34 CEST] <Daemon404> could be another lossless audio codec :D
[20:20:22 CEST] <andrewrk> ha
[20:40:05 CEST] <J_Darnley> Wait a minute... what's not "another lossless audio codec"?
[20:41:31 CEST] <jamrial> J_Darnley: FLIF, another lossless image format
[20:41:50 CEST] <J_Darnley> oh yay!  *thumbs up*
[20:44:57 CEST] <J_Darnley> Of course half the comments on HN are "but its GPL!"
[20:45:33 CEST] <Daemon404> there are already two bugs open for that
[20:45:43 CEST] <Daemon404> i must say though, gplv3 is a dead sentence for a library
[20:45:58 CEST] <J_Darnley> I reality that is probably true.
[20:46:08 CEST] <wm4> not as bad as AGPL
[20:46:12 CEST] <wm4> (yes there are such libs)
[20:46:41 CEST] <J_Darnley> That is a thread where they should enforce their "no negative comments" policy more strictly.
[20:46:42 CEST] <Daemon404> J_Darnley, well especially if you want browser adoption
[20:50:01 CEST] <Daemon404> anywyay, biggest deal: it's patent encumbered (and claims otherwise)
[20:53:42 CEST] <wm4> surely there's some very similar coding that performs about the same, and that isn't encumbered?
[20:55:00 CEST] <Compn> when do png patents expire? :P
[21:01:36 CEST] <DHE> is there any system for what patches get accepted/reviewed first? (I ask because I have two that I feel are being neglected, but I'm new to the project so...)
[21:01:57 CEST] <Daemon404> reply with a ping
[21:02:21 CEST] <DHE> is there an appropriate time to wait before pinging? it's only been a day
[21:02:33 CEST] <Compn> 2 weeks is usually the thing 
[21:02:48 CEST] <Compn> if its security or important issue, then ping immediately of course
[21:03:10 CEST] <Compn> DHE : whats thread title? ask us to review your patch :)
[21:06:21 CEST] <J_Darnley> How high can the constant A go in this type of x86 memory argument: [r0 + A * r1 + B]
[21:06:36 CEST] <jamrial> a week is enough to ping
[21:07:00 CEST] <DHE> Compn: [PATCH] libavformat/hlsenc: Use of uninitialized memory unlinking old files
[21:08:03 CEST] <DHE> I don't think it's exploitable or likely to crash the app because of the structure of the struct involved,  but it will make a mess of your terminal
[21:08:33 CEST] <jamrial> J_Darnley: 8 i think
[21:09:24 CEST] <J_Darnley> Thanks.  I better finish this function and see whether yasm complains about 32
[21:12:52 CEST] <DHE> so probably not security, but definitely a pretty big "oh sh--"
[21:17:17 CEST] <BBB> J_Darnley: 1,2,4 or 8
[21:19:53 CEST] <J_Darnley> thanks
[21:27:36 CEST] <BBB> J_Darnley: btw I really like the idea of constants in yasm style (instead of in c), maybe requiring yasm/nasm in x86 isnt a bad idea (x264 does that also)
[21:30:52 CEST] <Gramner> compiling with inline assembly but without yasm seems like a really odd use case and if you compile without yasm you obviously don't care about performance at all so no harm in disabling inline asm too
[21:33:38 CEST] <BBB> right
[21:33:50 CEST] <BBB> Gramner: any more comments on the intra pred simd or loopfilter simd, or ok to commit?
[21:33:59 CEST] <BBB> Gramner: and can I somehow trick you in reviewing h/v/tm/dc asm also?
[21:34:08 CEST] <Gramner> currently doing the latter
[21:34:14 CEST] <BBB> \o/
[21:34:17 CEST] <BBB> youre awesome
[21:34:18 CEST] <BBB> thank you
[21:36:17 CEST] <Gramner> i haven't looked at the new versions of the already reviewed ones you posted but if you addressed my comments then feel free to push them
[21:40:12 CEST] <cone-712> ffmpeg 03Michael Niedermayer 07master:14f6c4356b4a: avformat/flvdec: accept sizes if they are off by 11
[21:50:56 CEST] <wm4> michaelni__: should I write and submit a patch to dynamically allocate the sps/pps data?
[21:54:27 CEST] <BBB> accept sizes if they are off by 11
[21:54:50 CEST] <BBB> Im seriously questioning that commit message
[21:54:59 CEST] <wm4> packet sizes
[21:55:06 CEST] <michaelni__> wm4, iam slightly tending toward, no, to avoid any risks of double frees when it gets copied around
[21:55:11 CEST] <wm4> BBB: because the rtmp protocol produced garbage
[21:55:25 CEST] <wm4> michaelni__: yeah, it's messy
[22:18:41 CEST] Action: rcombs throws together a chromaprint "muxer" because why not
[22:19:17 CEST] <BtbN> A play-to-cups muxer would also be extremely usefull.
[22:19:31 CEST] <BtbN> 60 Pages per second printer required though
[22:19:50 CEST] <rcombs> chromaprint is an audio fingerprinter
[22:20:05 CEST] <rcombs> muxer works like crcenc
[22:22:30 CEST] <Daemon404> sounds nefarious
[22:38:10 CEST] <J_Darnley> WTF?  How can I possibly create a linking error by adding a function to a completely different file?
[22:40:54 CEST] <atomnuker> durandal_1707: can I safely assume that the number of samples per frame will remain constant except for the very last sample?
[22:46:07 CEST] <rcombs> wm4: whoops `git add` is hard
[22:48:29 CEST] <JEEB> `git status` is your friend
[22:49:27 CEST] <nevcairiel> atomnuker: in general? not on every audio codec, no
[22:50:09 CEST] <rcombs> you can in BRSTM files!
[22:50:58 CEST] <wm4> atomnuker: are you asking this in context of lavfi?
[22:51:48 CEST] <atomnuker> wm4: yep
[22:52:08 CEST] <wm4> atomnuker: the API user can pass it whatever he/she/it pleases
[22:52:15 CEST] <atomnuker> the problem is that a paper I read suggests to use a standard overlap for SSIM
[22:52:34 CEST] <nevcairiel> we have a audio queue for things that require constant frame size, i thinkj
[22:52:45 CEST] <wm4> and some codecs in fact produce variable length frames
[22:52:58 CEST] <wm4> (which also causes the framepool to realloc on every frame... whatever.)
[23:11:01 CEST] <Gramner> BBB: I got a bit bored of just reading asm so I rewrote some of your ipred code to make it twice as fast. I hope you don't mind
[23:11:10 CEST] <BBB> lol
[23:11:21 CEST] <J_Darnley> hehheh
[23:11:33 CEST] <BBB> was my dc that bad?
[23:11:50 CEST] <BBB> (unless you wrote avx2)
[23:11:56 CEST] <Gramner> it was the h actually
[23:11:59 CEST] <Gramner> ans no, sse2
[23:12:02 CEST] <Gramner> and*
[23:12:37 CEST] <BBB> pshufb?
[23:12:42 CEST] <BBB> hm, sse2
[23:13:05 CEST] <J_Darnley> How do I call avcodec's ff_add_pixels_clamped function pointer from assembly?  I've declared it with "cextern add_pixels_clamped" but what kind of operand do I need to give to "call"?
[23:13:06 CEST] <Gramner> the changes I did applies to parts of tm as well, but I'll leave that as an excercise to you
[23:13:16 CEST] <BBB> oh
[23:13:24 CEST] <BBB> I suppose you can punpcklwd the input
[23:13:26 CEST] <BBB> and then pshufdx4
[23:13:36 CEST] <BBB> instead of pshuflw x4 + punpcklqdqx4
[23:13:37 CEST] <BBB> ?
[23:13:38 CEST] <nevcairiel> J_Darnley: calling proper functions is hard work
[23:13:44 CEST] <Gramner> punpckhwd, but yes. bingo
[23:13:48 CEST] <nevcairiel> J_Darnley: better dont
[23:14:15 CEST] <BBB> nice!
[23:14:20 CEST] <J_Darnley> perhaps but then I need a wrapper around my DSP function (or I can duplicate the code).
[23:14:32 CEST] <BBB> well thats not twice as fast, but ok, it saves 3/8th shuffles
[23:14:39 CEST] <BBB> so you get a medal for that
[23:15:09 CEST] <BBB> J_Darnley: just duplicate it
[23:15:11 CEST] <Gramner> ~15 -> ~8 clocks
[23:15:12 CEST] <BBB> add_pixels is trivial
[23:15:24 CEST] <BBB> Gramner: ok cool, want me to incorporate it in my patch?
[23:15:38 CEST] <Gramner> yes, that's fine. I'll post on the ML in a while
[23:18:47 CEST] <BBB> ty, Ill wait
[23:19:18 CEST] <Gramner> BBB: in general I think you're interleaving to much stuff which increases register pressure and also reduces the efficiency of the µop cache in some cases
[23:19:45 CEST] <BBB> interleaving was a big thing back when I learned this
[23:19:47 CEST] <Gramner> interleaving 1-cycle instructions 4 at a time is overkill, 2 is enough
[23:19:49 CEST] <BBB> I guess it isnt anymore
[23:20:00 CEST] <BBB> oh I see
[23:21:02 CEST] <Gramner> if you can reuse the exact same instructions (including the same registers) multiple times the cpu wont have to decode it again. this sis beneficial sometimes
[23:21:42 CEST] <Gramner> that's not part of asm 101 though! it's an extra course ;)
[23:22:29 CEST] <rcombs> huh, interesting
[23:23:04 CEST] <BBB> sounds complicated :-p
[00:00:00 CEST] --- Sat Oct  3 2015