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

[burek]

[00:01] <kierank> there is no interlaced coding mode
[00:15] <iive> hevc doesn't have interlaced coding mode?! Now i'm liking it even more.
[00:17] <Compn> it means non standard interlacing
[00:17] <Compn> vendor specific
[00:17] <Compn> bwahahaha
[00:25] <gnafu> Compn: http://www.reactiongifs.com/r/jZ2J5Yv.gif
[01:05] <michaelni> kierank, i didnt mean hevc, but in general that i think as soon as interlaced was invented it was hated ...
[01:06] <michaelni> but i could be wrong, iam no archeologist ...
[01:07] <kierank> michaelni: yes exactly
[01:07] <kierank> that's why the sample is just 2x 1920x544
[01:07] <kierank> there is no mbaff
[01:07] <kierank> nor paff (mv chroma compensation part)
[03:02] <cone-393> ffmpeg.git 03Michael Niedermayer 07master:9f9440bd8122: avcodec/hevc_ps: Check return code from pps_range_extensions()
[10:57] <ubitux> http://lists.libav.org/pipermail/libav-devel/2014-November/065317.html any idea from where this was taken? oO
[10:57] <ubitux> git log -p --author=dericed libavformat/mov.c raises nothing
[10:59] <nevcairiel> the change isnt in ffmpeg
[10:59] <ubitux> yes
[11:00] <ubitux> and knowing Dave a bit, he probably didn't do that on libav tree
[11:16] <anshul_mahe> Do we have some parity check function that use processor power to do it rather then using bitwise operator
[11:27] <BtbN> Which C standard does ffmpeg use? Can i use variable-length automatic arrays? As in C99
[11:28] <kierank> No you can't use vla
[11:29] <anshul_mahe> for eg in x86 it use pushf for parity flag
[11:29] <BtbN> hm, that makes the code quite a bit more inefficient
[11:30] <cone-146> ffmpeg.git 03Martin Storsjö 07master:9326d64ed1ba: Share the utf8 to wchar conversion routine between lavf and lavu
[11:30] <cone-146> ffmpeg.git 03Michael Niedermayer 07master:097de4d1d68f: Merge commit '9326d64ed1baadd7af60df6bbcc59cf1fefede48'
[11:43] <cone-146> ffmpeg.git 03Martin Storsjö 07master:79fd186a5035: lavf: Use MoveFileEx instead of rename/_wrename on windows
[11:44] <cone-146> ffmpeg.git 03Michael Niedermayer 07master:cc663bd13a97: Merge commit '79fd186a5035cf16fc0ab288d8f59da8b1ba2c0e'
[12:35] <cone-146> ffmpeg.git 03Martin Storsjö 07master:675ac56b7ee0: Revert "lavf: Don't try to update files atomically with renames on windows"
[12:35] <cone-146> ffmpeg.git 03Michael Niedermayer 07master:4ae1d6021be9: Merge commit '675ac56b7ee0f204963fde55295197c5df80aa91'
[12:35] <cone-146> ffmpeg.git 03Rong Yan 07master:22e557917d08: libavutil/ppc/util_altivec.h : fix load_with_perm_vec() add marcos vcswapi2s() vcswapc() VEC_SPLAT16() VEC_SLD16() for POWER LE
[12:50] <cone-146> ffmpeg.git 03Matthew Oliver 07master:0167fa006044: msvc: Fix compilation errors due to header include order.
[14:06] <BtbN> Does ffmpeg realy run the init_static_data function just when enumerating the encoders? I'm not quite sure if i should use it for my nvenc encoder, or just make assumptions about which format(s) are supported.
[14:15] <Compn> good question, but i think many devels are asleep right now
[14:15] <Compn> BtbN : and i dunno the answer
[14:15] <Compn> :)
[14:16] <BtbN> The problem is, finding out the supported pixel format involves initializing CUDA and NVENC, and is quite costly and can cause troubles.
[14:17] <BtbN> Just assuming it's NV12 works for all hardware that currently exists, but it's far from ideal.
[14:17] <BtbN> And i can't see any other option
[14:22] <j-b> why far from ideal?
[14:22] <j-b> All hw decoders and encoders are using it.
[14:22] <j-b> x264 uses it internally.
[14:22] <BtbN> Because NVENC does not guarantee that it's supported
[14:23] <j-b> oh lol
[14:23] <BtbN> It's the assuming that's not ideal. NV12 itself is fine
[14:23] <BtbN> It's propably fine to just hardcode it to NV12, as they won't ever drop it.
[14:30] <j-b> WTF is this license
[14:30] <j-b> are they stupid or what?
[14:31] <BtbN> Which license exactly?
[14:32] <j-b> nvenc one
[14:33] <BtbN> There are 2 which apply to the header
[14:33] <j-b> https://developer.nvidia.com/nvidia-video-codec-sdk-license-agreement
[14:34] <BtbN> Yeah, that one's pretty annoying
[14:34] <BtbN> The one in the headers also is
[14:38] <j-b> wow, indeed
[14:38] <BtbN> Now the question is.. does it make the ffmpeg binaries nonfree or not?
[14:41] <j-b> BtbN: yes, it does
[14:43] <cone-146> ffmpeg.git 03Stefano Sabatini 07master:29208e6dcf94: lavu/imgutils: remove redundant and wrong check in av_image_fill_arrays
[14:51] <BtbN> Is it ok to call ff_lock_avcodec? Can't see it beeing used anywhere
[14:53] <wm4> what are you trying to do?
[14:54] <BtbN> I have to do non-threadsafe initialization
[14:54] <wm4> <j-b> are they stupid or what? <- it's nvidia
[14:54] <BtbN> Like loading the cuda and nvenc library
[14:54] <wm4> BtbN: what for? usually this is only needed for stupid global tables
[14:54] <BtbN> Yes, i load the nvenc library globaly
[14:54] <wm4> is the library always the same? or can the user specify which one to use?
[14:54] <BtbN> With a reference counter, to avoid loading it multiple time
[14:55] <BtbN> It's allways the very same library
[14:55] <wm4> the OS should be doing the refcounting for you
[14:55] <BtbN> The OS doesn't know how many times the avcodec codec is in use
[14:56] <wm4> BtbN: seems ff_lock_avcodec is already held during init
[14:57] <wm4> so codec->init is always restricted to 1 thread in the process
[14:57] <Compn> BtbN : where is the api header license ?
[14:57] <j-b> wm4: I hate hardware vendors when they do software. It makes no sense, their headers are crap, the API very bad, and their licenses are always "you're not allowed to use this".
[14:57] <BtbN> Compn, in the nvEncodeAPI.h
[14:57] <BtbN> and at https://developer.nvidia.com/nvidia-video-codec-sdk-license-agreement
[14:57] <BtbN> but they are not the same
[14:57] <Compn> thx
[14:57] <wm4> j-b: isn't that normal? they got to protect their IP!!!!!!11111111111111111111
[14:58] <BtbN> j-b, the NVENC api is actualy quite nice
[15:00] <Compn> probably we should just ask nvidia to relicense this header for us :P
[15:00] <Compn> since we used to have contacts with them...
[15:06] <Daemon404> i wonder whats the use case of nvenc?
[15:06] <Daemon404> isnt it quite bad
[15:06] <BtbN> It's encoding with nearly no cpu usage.
[15:07] <Daemon404> of course
[15:22] <nevcairiel> the quality is OKish on recent GPUs
[15:22] <nevcairiel> for realtime streaming things or so
[15:24] <nevcairiel> its been a todo for me to offer nvenc and quicksync for real-time transcoding uses
[15:25] <nevcairiel> but the timetable doesnt have that in it until next year, soo
[15:25] <BtbN> The quality is the exact same on all GPUs
[15:25] <BtbN> Maxwell just got faster, quality is unchanged
[15:26] <BtbN> QSV on linux is horrible
[15:26] <nevcairiel> 1hm oh well, then it was just intel that increased quality as well
[15:26] <BtbN> There is only libva, and libva has the most horrible api i have ever seen
[15:26] <BtbN> You have to manualy generate the h264 nal
[15:26] <nevcairiel> i only need windows for now
[15:26] <BtbN> but only parts of it
[16:01] <cone-146> ffmpeg.git 03Michael Niedermayer 07master:57e5812198aa: avcodec/hevc_ps: More complete window reset
[16:01] <cone-146> ffmpeg.git 03Michael Niedermayer 07master:98e8a9e2f238: ffmpeg: Print a debug message if the frame parameters mismatch the context
[16:20] <BtbN> Is it ok to av_assert0 after av_malloc, or does the code have to continue eben when oom?
[16:22] <j-b> don't assert, just properly quit
[16:22] <j-b> assert should be for impossible code-path.
[16:23] <BtbN> Hm
[16:23] <BtbN> so i need to refactor half my code, just because of that
[16:52] <b_jonas> BtbN: beware of http://xkcd.com/292/
[16:52] <BtbN> Well, i'm using goto anyway. Best way to do error handling.
[16:53] <BtbN> Better than a growing list of deinitializations in every error case
[16:53] <Daemon404> it is standard in most c codebases to use goto error
[16:54] <Daemon404> including ours
[16:54] <BtbN> It's basicaly the C version of exception handling
[16:55] <BtbN> At least i got rid of any non-constant static global variable while i was on it
[16:55] <rcombs> yeah, goto is only really considered harmful in languages that _do_ have higher-level exception handling
[16:55] <Daemon404> i wouldnt call it the same as exception handling
[16:56] <b_jonas> I'm not saying you can't use goto, just be careful with it
[16:56] <nevcairiel> Just don't goto upwards
[16:56] <Daemon404> i.e. you dont accidentally let a goto slip through 3 calls up
[16:56] <Daemon404> and be uncaught
[16:56] <Daemon404> ;)
[16:56] <nevcairiel> goto fail is common practice in C
[16:56] <BtbN> Could be avoided if you realy want to, but that would involve ugly wrapping of every function
[16:56] <BtbN> so you return from the inner function instead of goto error
[16:57] <BtbN> and the outer function does the cleanup
[16:57] <rcombs> nevcairiel: which makes it quite funny to hear people talk about "the goto fail bug" (and mean that one Apple TLS one)
[16:57] <Daemon404> rcombs, yeah but goto didnt cause that one
[16:57] <Daemon404> allowance of lack of { did
[16:57] <nevcairiel> Well if you forget the actual error handler...
[17:05] <wm4> rcombs: "goto considered harmful" is often mistaken as a complete damnation of goto
[17:05] <wm4> rcombs: but actually this was just to contrast goto spaghetti programming to structured programming, when structured programming was still new
[17:06] <kepstin-laptop> my understanding was that it was referring to how people learned to program in older basic variants which had very limited flow control, and mostly relied on goto
[17:06] <wm4> there's nothing wrong with simple gotos, they're probably less error prone than "break" or "continue"
[17:07] <Daemon404> yes it refers to loops using goto ala BASIC
[17:07] <Daemon404> and such
[17:07] <Daemon404> anyone who takes any essay as Pure Truth should probably not be programming anyway.
[17:09] <rcombs> Daemon404: you should write an essay on that :3
[17:09] Action: wm4 goes writing a function that uses 10 gotos
[17:09] <rcombs> it'd be delightfully meta
[17:09] <b_jonas> wm4: no, that's a different strip, http://www.xkcd.com/148/
[17:09] <b_jonas> um
[17:09] <b_jonas> sorry, I mena 
[17:09] <b_jonas> rcombs: that's a different strip
[17:43] <koda> hey ubitux 
[17:43] <koda> i got your question on the other chan
[17:43] <koda> i took the additional metadata info from https://github.com/l-smash/l-smash/blob/master/lsmash.h#L3861
[18:07] <ubitux> koda: what do you mean "additional"? i don't even see what was the original commit
[18:08] <koda> the original commit is the one you pointed me? or i don understand the question
[18:08] <ubitux> the author is dericed in your patch
[18:08] <ubitux> so i'm wondering where this comes from
[18:10] <koda> oh the other one, right
[18:10] <koda> i think i saw something on a github pull request that got ignored for a few years
[18:12] <ubitux> ok
[18:20] <cone-146> ffmpeg.git 03Clément BSsch 07master:5ab882d7283f: avformat/mov: strengthen some table allocations
[18:20] <cone-146> ffmpeg.git 03Clément BSsch 07master:92fa1d9231b8: avformat/mov: change conjugation for "Duplicate"
[19:21] <cehoyos> Hi! Has anybody here ever compiled x265 on msys? How is it supposed to work?
[19:23] <rcombs> ow
[19:24] <Daemon404> i think you mean mingw via msys, and its on the wiki
[19:24] <Daemon404> https://bitbucket.org/multicoreware/x265/wiki/CrossCompile
[19:25] <cehoyos> I don't want to crosscompile, I want to build on msys
[19:25] <Daemon404> its the same whether you compile natively with mingw or cross-compile from linux
[19:25] <Daemon404> ^^^^^^^6
[19:25] <cehoyos> Ok, so I have cmake in my path and gcc.exe
[19:25] <cehoyos> the gcc is able to compile ffmpeg (and passes fate)
[19:26] <Daemon404> you might not need a toolchain file for windows, iirc there is an option in cmake-gui if you compile it natively, to use mingw
[19:26] <cehoyos> If I run ./make-Makefiles.sh it finds gcc.exe but claims "is not able to compile a simple test program."
[19:26] <Daemon404> eh
[19:26] <jamrial> x265 has a script to run cmake with the correct arguments depending on you using x86 or x86_64
[19:26] <Daemon404> to quote myself from earlier today, elsewhere
[19:26] <jamrial> check build/msys
[19:26] <Daemon404> [15:36] < Daemon404> dont use their shell script
[19:26] <Daemon404> [15:36] < Daemon404> ever.
[19:26] <Daemon404> [15:36] < Daemon404> just use cmake
[19:26] <Daemon404> [15:36] < Daemon404> their shell script is for the benefit of their outsourced developers.
[19:27] <cehoyos> I originally wanted to build x86_64 (I have a compiler that succeds FFmpeg fate) but atm, I can neither build x86 nor x86_64
[19:27] <cehoyos> What means "just use cmake"? (Sorry, I never used it)
[19:27] <Daemon404> cmake-gui.exe is pretty straight forward
[19:27] <rcombs> this all looks way more complicated than it should have to be
[19:27] <Daemon404> you point it at a build and source dir
[19:27] <Daemon404> and select your toolchain
[19:28] <Daemon404> rcombs, the gist is: people dont like learning new tools (cmake)
[19:28] <Daemon404> (also cmake is bad, but thats orthogonal)
[19:28] <cehoyos> Who invented this... (sorry): What is the "source code" is it /x265? or /x265/build? or /x265/source?
[19:28] <jamrial> the latter
[19:28] <Daemon404> x265/source
[19:29] <rcombs> `cd build; cmake "-GUnix Makefiles" ../source; make; make install`
[19:29] <rcombs> alternately, -GNinja if you've got that
[19:29] Action: Daemon404 barfs
[19:29] <jamrial> well no, not for msys
[19:29] <jamrial> cmake -G "MSYS Makefiles"
[19:29] <rcombs> oh, is that a thing
[19:29] <rcombs> why is it different :|
[19:30] Action: jamrial shrugs
[19:30] <Daemon404> i dont know
[19:30] <Daemon404> i hate cmake.
[19:30] <Daemon404> a lot.
[19:30] <rcombs> well, either MSYS or MinGW or UNIX depending on fuckall, try until one works
[19:31] <rcombs> or just cross-compile and maintain some semblance of sanity
[19:31] <Daemon404> i run nightly builds of x265, but with msvc and icl
[19:31] <jamrial> cross-compiling with cmake sucks
[19:31] <cehoyos> cmake-gui now asks for a generator: Which one should I choose: mingw or msys?
[19:31] <Daemon404> jamrial, i used to work on openembedded as my job. 
[19:31] <Daemon404> guess why i hate cmake?
[19:32] <Daemon404> cehoyos, good question. it's... unclear
[19:32] <jamrial> haha
[19:32] <rcombs> I hate MinGW/MSYS
[19:32] <rcombs> "it's like cygwin, but half-assed!"
[19:32] <cehoyos> Error in configuration
[19:33] <jamrial> rcombs: try msys2. it's like cygwin, but not half assed
[19:33] <cehoyos> Ok, I chose "mingw" which was wrong, how can I change what I chose?
[19:33] <jamrial> clean the build folder
[19:33] <rcombs> jamrial: maybe one day the differences will be documented!
[19:34] <jamrial> well, for starters, it's in active development :p
[19:35] <Daemon404> cehoyos, it worked here by using msys makefiles and choosing to specify native compiler location
[19:35] <Daemon404> and pointing it at gcc and g++
[19:35] <Daemon404> and specifying yasm iin the config of course
[19:36] <cehoyos> I chose "Msys makefiles" now and I get the identical error as with the shell scripts.
[19:36] <cehoyos> gcc.exe not able to compile a simple test program.
[19:36] <rcombs> "paths are POSIX-style except when they're not!"
[19:36] <jamrial> maybe your msys environment is broken
[19:36] <rcombs> "drive letters may or may not be required!"
[19:37] <Daemon404> rcombs, thats untrue
[19:37] <cehoyos> http://pastebin.com/vJ7MKyU9
[19:37] <cone-146> ffmpeg.git 03Michael Niedermayer 07master:970a8f1c256f: avcodec/mjpegdec: Fix integer overflow in shift
[19:38] <Daemon404> cehoyos, works here with msys+mingw for me...
[19:39] <cehoyos> What did you do?
[19:39] <cehoyos> I mean, did you run cmake-gui from msys?
[19:39] <cehoyos> Or from cmd.exe?
[19:39] <Daemon404> i double clicked it.
[19:40] <Daemon404> x265 [info]: build info [Windows][GCC 4.9.1][64 bit] 8bpp
[19:40] <jamrial> does it not work if you run 'cmake -G "MSYS Makefiles" <path to source>' first, then 'cmake-gui <path to source>'? both on msys and in the build folder
[19:40] <cehoyos> How did you pass the path to the toolchain to cmake-gui
[19:40] <cehoyos> ?
[19:41] <cehoyos> Assuming you are using Hendriks compiler or aren't you?
[19:41] <Daemon404> shouldnt matter
[19:41] <Daemon404> you select 'specify native toolchain' in the wizard thing
[19:41] <cehoyos> The toolchain doesn't matter?
[19:41] <Daemon404> and you get file open dialogs to specify teh paths to gcc and g++
[19:42] <Daemon404> jamrial, that should work too
[19:43] <cehoyos> jamrial: I get the identical output as above: gcc is not able to compile a simple test program.
[19:43] <cehoyos> See http://pastebin.com/vJ7MKyU9
[19:44] <jamrial> then there's something wrong with your gcc toolchain or msys environment
[19:44] <cehoyos> The same toolchain passes fate for FFmpeg...
[19:44] <cehoyos> Of course, you are right, I just wonder what I should do.
[19:45] <cehoyos> My msys is antique, I just wonder how this affects cmake-gui...
[19:45] <Daemon404> it works without gui too
[19:45] <Daemon404> running cmake -G "MSYS Makefiles" in msys works fine
[19:47] <cehoyos> The following shows if I run cmake-gui with a double-click:
[19:47] <cehoyos> CMake Error: CMake was unable to find a build program corresponding to "MSYS Makefiles".  CMAKE_MAKE_PROGRAM is not set.  You probably need to select a different build tool.
[19:47] <Daemon404> ... is gcc even in your path
[19:47] <Daemon404> actually it doesnt need to be
[19:48] <Daemon404> because you specify the toolchain path
[19:48] <cehoyos> It is in my msys path, if I double-click cmake-gui, how can gcc be in my path?
[19:48] <jamrial> cmake doesn't recognize "MSYS Makefiles"?
[19:48] <cehoyos> Or do I just misunderstand?
[19:48] <cehoyos> Where can I specify the toolchain path (I believe I asked that above)?
[19:49] <Daemon404> there is an option to specify it when you set the generator
[19:49] <Daemon404> but as i said, you can just 'cmake -G "MSYS Makefiles"' from the same msys prompt you bult ffmpeg in
[19:52] <cehoyos> Daemon404: http://pastebin.com/cXvyDcyC
[19:53] <Daemon404> your environment seems broken then...
[19:53] <cehoyos> Ok (of course), but how can I proceed?
[19:53] <cehoyos> And why does fate succeed?
[19:54] <Daemon404> i have no idea how your stuff is set up
[19:54] <cehoyos> A very old msys installer
[19:55] <jamrial> did you successfully compile ffmpeg on this environment?
[19:56] <Daemon404> he said he did
[19:56] <cehoyos> No, I mean yes, as said above, fate passes both for the native (old) compiler on my msys environment and with Hendrik's current compiler.
[19:56] <cehoyos> I have a second Windows box, which version of msys should I install there?
[19:56] <Daemon404> idea: make sure your build directory is empty
[19:57] <Daemon404> especially no *.cache files
[19:57] <cehoyos> I removed it after every try.
[19:57] <jamrial> latest msys using their installer, or just use msys2
[19:57] <cehoyos> That is my question.
[19:57] <jamrial> both should work. but if you want something in active development, go with msys2
[20:01] <cehoyos> Allow me to try again: What did you use when you did a successful install last time, and would you recommend it?
[20:01] <cehoyos> Daemon404: Would you mind uploading a 64bit x265.a with 10bit support?
[20:03] <jamrial> i used msys until a month or so ago, then switched to msys2. i compiled x265 successfully with both
[20:04] <jamrial> and i'd say use msys2
[20:05] <cehoyos> Ok, thank you. If you can upload a x265.a (64bit, 10bit), I would be grateful.
[20:08] <cone-146> ffmpeg.git 03Vincent Bernat 07master:5269cef4087f: avformat/udp: Allow to specify DSCP class
[20:08] <cone-146> ffmpeg.git 03Vincent Bernat 07master:d0f8b94b432e: avformat/rtpproto: Allow to specify DSCP class
[20:16] <Daemon404> cehoyos, why 10bit?
[20:17] <Daemon404> x265 RD currently has issues in 10bit mode
[20:17] <cehoyos> TherAk
[20:17] <Daemon404> ?
[20:18] <cehoyos> wrong window
[20:18] <cehoyos> what is rd?
[20:18] <Daemon404> rate distortion
[20:18] <Daemon404> basically, 10bit is not prod-ready.
[20:18] <cehoyos> So there is no reason to test it?
[20:19] <Daemon404> i dont think so, yet
[20:19] <cehoyos> Ok, Thank you.
[20:19] <Daemon404> its on their list to work on
[20:19] <cehoyos> Any news from the prores file? Where you able to run ffmpeg -i on it?
[20:19] <cehoyos> Were...
[20:20] <Daemon404> koda has it, i never remembered to poke him
[20:20] <cehoyos> Perhaps you could do so now?
[20:20] <Daemon404> he's not around, it's dinner time here
[20:20] <Daemon404> ill just leave a message.
[20:20] <cehoyos> I will ask again, thank you!
[20:20] <cehoyos> gtg
[20:35] <Daemon404> maybe in 2025 the aac patch will be pused
[20:51] <rcombs> is there any need for more samples that have trouble on the current AAC encoder but work with the patch (and don't give assertion failures)?
[20:51] <rcombs> 'cause I've got one
[21:12] <nevcairiel> We don't need any proof that the old one sucks, we know! :P
[21:12] <rcombs> nevcairiel: do you need more easily-noticeable proof that it's better now?
[22:22] <cone-146> ffmpeg.git 03Anton Khirnov 07master:2443e522f005: lavu: add wrappers for the pthreads mutex API
[22:22] <cone-146> ffmpeg.git 03Michael Niedermayer 07master:476027800721: Merge commit '2443e522f0059176ff8717c9c753eb6fe7e7bbf1'
[23:00] <Zeranoe> ramiro: Any progress on that DeckLink issue?
[23:21] <cone-146> ffmpeg.git 03Lukasz Marek 07master:568853b8f533: lavf/ffmdec: add common options to recommended encoder configuration
[23:21] <cone-146> ffmpeg.git 03Lukasz Marek 07master:500d6088618a: lavf/ffmenc: store recommended encoder configuration
[23:22] <cone-146> ffmpeg.git 03Lukasz Marek 07master:3ff39901049f: ffmpeg_opt: make use of recommended encoder configuration
[23:30] <cone-146> ffmpeg.git 03Lukasz Marek 07master:f00e9c4b10f5: lavu/opt: add consts where possible
[23:42] <cone-146> ffmpeg.git 03wm4 07master:fbd6c97f9ca8: lavu: fix memory leaks by using a mutex instead of atomics
[23:43] <cone-146> ffmpeg.git 03Michael Niedermayer 07master:6db8cd8f37b7: Merge commit 'fbd6c97f9ca858140df16dd07200ea0d4bdc1a83'
[23:59] <cone-146> ffmpeg.git 03Kieran Kunhya 07master:96fda42a8f9b: vf_interlace: get rid of useless loads
[00:00] --- Fri Nov 28 2014