[02:08] <J_Darnley> Dammit! Why does my cursor keep vanishing when ever I cause a segfault in ffmpeg? [02:12] <kierank> does "reset" not help [02:12] <pross-au_> stty sane :) [02:12] <J_Darnley> I'll try that next time [04:20] <cone-435> ffmpeg.git 03Rong Yan 07master:6abeaf2781ce: build sys: enable the decoding_encoding example under the ffmpeg/doc/examples [07:30] <cone-711> ffmpeg.git 03Clément BSsch 07master:e6b125e3be19: avutil/pixelutils: add small buffers tests [07:31] <cone-711> ffmpeg.git 03Mark Harris 07master:4cabee50f624: tools/normalize.py: both input and output file names are required [11:28] <cone-711> ffmpeg.git 03Mika Raento 07master:e48d1ea541be: ismindex: improve diagnostics [11:28] <cone-711> ffmpeg.git 03Michael Niedermayer 07master:35469835bb29: Merge commit 'e48d1ea541be4592ebac89875557407ca958b7a9' [11:43] <cone-711> ffmpeg.git 03Mika Raento 07master:58e0402e02ae: segment: don't access outside seg->frames array [12:03] <cone-711> ffmpeg.git 03Carl Eugen Hoyos 07master:3668168afa1e: Support decoding of ImageJ png in avi. [12:37] <cone-711> ffmpeg.git 03Michael Niedermayer 07master:0ffe32cf8f92: avformat/segment: Use avformat_alloc_output_context2() [12:37] <cone-711> ffmpeg.git 03Mika Raento 07master:413fa76f61f2: segment: use mpegts_flags instead of the deprecated resend_headers option [12:37] <cone-711> ffmpeg.git 03Mika Raento 07master:502fc3b3d4b3: segment: fix copying stream metadata [13:21] <J_Darnley> WTF has happened to my git install? [13:22] <J_Darnley> What do you mean it isn't a repositiory? [13:23] <wm4> is there a .git directory somewhere? [13:24] <J_Darnley> Yes, I'm in my ffmpeg dir [13:25] <J_Darnley> WTF! When did I get version 2 installed? [13:26] <J_Darnley> Oh, actually this is just operator error. [13:26] <J_Darnley> I was trying to fetch from master rather than origin [13:28] <ubitux> BBB_: are you going to submit the vp9 fix? [13:28] <BBB_> ? [13:28] <ubitux> ah it was pushed [13:28] <BBB_> ah, the old one (I wasnt sure which one you meant) [13:29] <BBB_> I have nothing outstanding, indeed [13:29] <ubitux> only the test is missing so? [13:29] <wm4> ubitux: do you think it would be possible to rush the utf-16 sub thing to get it into 2.4? [13:29] <ubitux> wm4: are you asking me to rush it or are you asking me if you are going to have enough time? :) [13:29] <wm4> both [13:30] <ubitux> well if you submit the patch i'll review it asap [13:30] <wm4> ok... what did you say needed to be improved? (sorry, I asked that before already, but I keep forgetting) [13:30] <ubitux> i think i said everything in the thread [13:31] <ubitux> basically apply it to the other sub formats [13:31] <wm4> ok [13:31] <wm4> well let's see [13:31] <ubitux> http://ffmpeg.org/pipermail/ffmpeg-devel/2014-March/156091.html [14:16] <ubitux> where can i get track_ticket_3902.mkv? [14:19] <Daemon404> wow so... i am actually using our .ico encoder in practice [14:19] <Daemon404> what has the world come to [14:19] <Daemon404> decoder too [14:20] <plepere> ubitux, I have a function for a 16 width. for a 64 width, I can either call the 16w 4 times or create a function with %rep 4. which would you rather do ? [14:21] <nevcairiel> less calls, more rep! [14:23] <ubitux> i would guess functions handling larger widths can be cool because if you have an instruction set with something like 2x larger reg size it can be useful [14:26] <ubitux> Daemon404: you mean muxer? [14:26] <Daemon404> same diff [14:27] <nevcairiel> why do you need a ico muxer [14:27] <ubitux> to make a preview of vimeo videos in favicon? [14:27] <nevcairiel> favicon accepts pngs [14:27] <Daemon404> fun fact: all images on vimeo are generated on teh fly and cachd [14:27] <Daemon404> cached* [14:27] <Daemon404> and favicon isnt static [14:27] <Daemon404> (no its not a thumbnail) [14:28] <nevcairiel> if i build a serious .ico i usually use a proper editor, since i want to stuff different resolution images in it [14:29] <Daemon404> this is just a testing thing [14:29] <Daemon404> not in prod [14:30] <Daemon404> we make icos in an eidtor currently [14:30] <Daemon404> downscaled to e.g. 16x16 with bicubic will look like balls [14:30] <Daemon404> you need to edit it manually [14:30] <nevcairiel> yeah i hand-drew a few 16x16 icos because scaling just doesnt work to that size [15:45] <Diaz2691> hi all experts, [15:46] <Diaz2691> I see the mail list about fixed point decoder for AAC, [15:46] <Diaz2691> but when I clone git source, I donot see the code, is it right? [15:50] <ubitux> you're talking about "[FFmpeg-devel] Implementation od fixed point AAC decoder"? [15:50] <ubitux> it's still under review [16:30] <Diaz300> hi [16:30] <Diaz300> compn [16:31] <Diaz300> I see the message from mail list :merging the fixed point decoders from rockbox has been on our todo list for a while [16:31] <Diaz300> Do you have any idea about how to? [16:32] <Diaz300> how to get the patch from mail list ? [16:32] <Diaz300> when I see the subject like "[PATCH 01/14] libavcodec: Implementation of AAC_fixed_decoder (LC-module) [1/5]" [16:33] <Diaz300> because I clone git source , I do not see the patch included [16:33] <Diaz300> HELP ! Any ideas? [16:34] <cone-711> ffmpeg.git 03Michael Niedermayer 07master:1587989518cd: avcodec/rawdec: Support CODEC_CAP_PARAM_CHANGE [16:34] <cone-711> ffmpeg.git 03Michael Niedermayer 07master:1c55d0ff3202: avformat/swfdec: Use side data to communicate w/h changes to the decoder [16:35] <J_Darnley> Diaz300: save the mail and then git am [16:36] <Diaz300> will the patch commit to git? [16:36] <wm4> ubitux: what did we say about microdvd? utf-16 support yes or no? [16:36] <wm4> ubitux: and webvtt is always utf-8 I assume [16:36] <wm4> so: ass, sami, srt [16:36] <J_Darnley> Yes, git will turn the patch into a regular commit [16:37] <ubitux> wm4: well, can't we can handle them for free by updating the builtins? [16:37] <Diaz300> is it possible guide me how to merge fixed point wma decoder from rockbox? [16:37] <ubitux> but anyway, yeah, ass, sami, srt [16:37] <ubitux> Diaz300: 16:35:20 <+J_Darnley> Diaz300: save the mail and then git am [16:39] <J_Darnley> Diaz300: where is this code that you want to merge? [16:40] <Diaz300> https://github.com/Rockbox/rockbox/tree/master/lib/rbcodec/codecs/libwma [16:41] <Diaz300> but compn says: merging the fixed point decoders from rockbox has been on our todo list for a while [16:41] <nevcairiel> unless a developer is actually willing to spend days and days on untangling and updating that, its doubtful it'll happen anytime soon [16:41] <nevcairiel> its easy for compn to say, he doesn't code stuff :P [16:41] <Diaz300> yes [16:42] <Diaz300> hence, I search solution about fixed point wma decoder [16:42] <J_Darnley> That isn't even libavcodec. That will require actual work to port it into FFmpeg. [16:43] <Diaz300> but the code from rockbox seems much different style from ffmpeg decoder [16:43] <Diaz300> yes [16:43] <J_Darnley> You need to get your programmer hat on then. [16:43] <nevcairiel> J_Darnley: its actually the avcodec decoder, ripped out of its shell [16:43] <nevcairiel> but probably a decade old [16:44] <J_Darnley> That doesn't make it possible to add with git though [16:44] <nevcairiel> thats why i said it needs a developer to untangle and update :) [16:44] Action: J_Darnley nods [16:45] <Diaz300> yes [16:45] <nevcairiel> anyhow, unless you are actually capable to do it yourself, I wouldn't hold my breath, wma isnt really a popular codec [16:46] <Diaz300> nevcairiel, so it is possible to ripped out of its shell? [16:48] <wm4> is there a simple, non-convoluted way to setup a freestanding AVIOContext to read out of a static buffer? [16:49] <nevcairiel> wm4: all methods i know include building your own read and seek functions [16:50] <J_Darnley> Diaz300: i'm sure it is possible [16:51] <wm4> this stuff is a bit fat [16:51] <J_Darnley> for someone with enought time, skill, and understanding of the issues involved. [16:51] <wm4> oooh [16:51] <wm4> maybe I can just use ffio_init_context [16:52] <wm4> quite some code in lavf is doing that to read from a memory buffer [16:52] <nevcairiel> internal! internal! [16:52] <nevcairiel> or are you working on internal stuff anyway :D [16:59] <wm4> nevcairiel: yes [17:36] <Diaz4519> hi all experts, [17:37] <Diaz4519> when I post a question , but I can not receive the mail when someone replay the question [17:37] <Diaz4519> does anyone have idea? [17:38] <kepstin-laptop> Diaz4519: the ffmpeg mailing lists are set so responses go only to the list. Make sure you're subscribed, and that your spam filter isn't blocking them [17:40] <Diaz4519> yes I have subscribed, I can see my question from mail list archive, but I do not receive the mail even some reply the question [17:40] <Diaz4519> any settings when I subscribe? [17:42] <kepstin-laptop> it is possible to have disabled mail delivery in the mailing list settings, you could check that. [17:42] <kepstin-laptop> but normally you'd know if you'd done that, since it's kind of tricky to do :) [17:48] <Diaz4519> do you know where I can modify mailing list settings? [17:56] <kepstin-laptop> Diaz4519: http://lists.ffmpeg.org/contact.html#MailingLists links to the management pages to the various lists; you can log in to the preferences interface by entering your email address into the form at the bottom of the page for the list. [17:59] <Diaz4519> ok, I try, but I forget my password [17:59] <Diaz4519> it seems impossible to modify password [17:59] <kepstin-laptop> it should have been mailed to you when you subscribed [17:59] <kepstin-laptop> I think [18:00] <kepstin-laptop> yep, It's in the "Welcome" message that you received when you subscribed [18:01] <kepstin-laptop> if you didn't receive the welcome message, then it's not the list's fault; you either subscribed using the wrong mail address or have a spam filter blocking messages or something like that. [18:06] <kepstin-laptop> (you could try unsubscribing and resubscribing) [18:54] <cone-711> ffmpeg.git 03Tobias Rapp 07master:2c43cfe2d405: cmdutils: Add some whitespace when printing layouts [19:24] <cone-711> ffmpeg.git 03Reimar Döffinger 07master:2ca78936c7d4: rl.h: remove deprecated and now unused vlc member. [19:24] <cone-711> ffmpeg.git 03Reimar Döffinger 07master:e48cd2de98c3: rl.h: Use on-stack temporary VLC tables instead of having them static. [19:24] <cone-711> ffmpeg.git 03Reimar Döffinger 07master:3980ab12b728: rangecoder-test: Allow running with small stack size. [19:24] <cone-711> ffmpeg.git 03Reimar Döffinger 07master:4ea8406e3811: vf_deshake: reduce stack usage. [19:24] <cone-711> ffmpeg.git 03Reimar Döffinger 07master:098af260675b: vf_deshake: Avoid doing a malloc+free for every single frame. [20:13] <wm4> ubitux: is RealText utf-16 a thing? [20:15] <ubitux> no idea but it wouldn't surprise me [20:16] <wm4> from what I can see realtext is almost like sami [20:16] <wm4> except different [20:16] <wm4> (what) [20:19] <ubitux> it's almost like sami in the sense that it's a xml-based soup [20:20] <wm4> so, how do I run fate for subtitles only? [20:21] <ubitux> make fate-subtitles [20:21] <wm4> or do I have to download and run the whole thing [20:21] <wm4> let's see [20:21] <ubitux> ah, you need to rsync the samples yeah [20:22] <ubitux> rsync -vrltLW --timeout=60 --contimeout=60 rsync://fate-suite.ffmpeg.org/fate-suite/sub/ ~/fate-samples/sub/ [20:22] <ubitux> something like this should do the trick [20:22] <ubitux> then SAMPLES=$HOME/fate-samples [20:23] <ubitux> if you can add one or two utf-16 samples that would be great btw [20:23] <wm4> thanks, these exact commands worked [20:24] <wm4> how do I add samples? [20:24] <ubitux> you put them in ~/fate-samples/sub/ for your tests, and when you're done you ask michaelni to upload them [20:24] <ubitux> :p [20:25] <ubitux> michaelni: btw, can we wait for the utf-16 thing from wm4 before 2.4? [20:25] <wm4> well, take a look first [20:25] <wm4> maybe it's too horrible [20:26] <ubitux> wm4: anyway, tests are in tests/fate/subtitles.mak, so you add your entry, and do make fate-sub-utf16shit GEN=1 to generate the ref data [20:26] <wm4> pretty convenient [20:26] <ubitux> wm4: sure, show me [20:27] <wm4> finishing this first [20:27] <ubitux> one thing i don't like with current subs tests is that they output md5 [20:27] <ubitux> they could be stored as text [20:27] <ubitux> because it's a pain to actually see what went wrong [20:28] <ubitux> (you have to make fate-sub-utf16shit V=1, take the command and change the md5 output to check the content) [20:31] <wm4> also, all my utf-16 samples would just be converted from the utf-8 samples [20:31] <wm4> is that ok? maybe I should strip them a bit [20:31] <ubitux> ah really? you don't have a real wild sample? [20:31] <ubitux> i would have take the opportunity to get a different coverage in the decoders [20:31] <wm4> not right now [20:31] <ubitux> mmh [20:32] <wm4> wasn't there one on the bug tracker? [20:32] <wm4> hm I have an EUC-KR .smi file, yummy [20:32] <ubitux> yeah indeed i remember seeing one on the trac [20:32] <ubitux> let me check for that one [20:33] <ubitux> trac is sloooow :( [20:34] <ubitux> wm4: https://trac.ffmpeg.org/ticket/3496 [20:34] <ubitux> wm4: can you take that sample and mention that Ticket in the commit message? [20:37] <ubitux> wm4: https://code.mythtv.org/trac/ticket/9836 [20:37] <ubitux> this one looks nice as well [20:37] <ubitux> (srt) [20:37] <wm4> wow this is trippy [20:37] <wm4> the 3496 one uses some sort of animation [20:37] <wm4> so I guess not just anime shit uses extended ass features [20:37] <ubitux> mythtv/9836 is srt with unclosed font tags and arabic [20:37] <ubitux> that's pretty awesome [20:37] <ubitux> (and utf-16 ofc) [20:37] <wm4> oh, torture [20:37] <ubitux> :D [20:37] <wm4> which one exactly? preferably the actual url [20:38] <ubitux> https://code.mythtv.org/trac/attachment/ticket/9836/Chalet%20Girl%20%282011%... [20:38] <ubitux> https://code.mythtv.org/trac/raw-attachment/ticket/9836/Chalet%20Girl%20(201... [20:39] <ubitux> actually that might not be utf-16 [20:39] <wm4> it's utf-8 [20:40] <ubitux> the ticket was mentioning utf-16, my bad [20:56] <wm4> ubitux: sent, without tests for now [20:58] <ubitux> thx, i'll have a look in about 2 hours [21:21] <wm4> ubitux: oh shit, probetest now reports that srt is the most expensive format to probe [21:21] <wm4> must be because of this read line function [21:33] Action: wm4 wonders what reimar is up to [21:35] <J_Darnley> Super secret embedded programming! [21:54] <cone-711> ffmpeg.git 03Gabriel Dume 07master:74512f7e369d: 8svx: Return proper error codes [21:54] <cone-711> ffmpeg.git 03Michael Niedermayer 07master:50c6bffb67d1: Merge commit '74512f7e369da40e1148c92b58cd8e59f7737b8f' [21:59] <jamrial> J_Darnley: I'll test your XOP stuff later today [22:00] <J_Darnley> Thanks. I already got one test but it failed. I think I'm using vpshaq wrong [22:01] <J_Darnley> Now that I read docs more carefully, I think I need the shift amount for every qword [22:03] <ubitux> wm4: heh that's unfortunate :) [22:04] <wm4> ubitux: it's most likely because of ff_subtitles_read_line [22:04] <ubitux> reimar just went recently very active again indeed, that's quite nice [22:04] <wm4> which reads byte by byte [22:04] <wm4> instead of just running strcspn on memory [22:04] <ubitux> ok [22:05] <cone-711> ffmpeg.git 03Gabriel Dume 07master:f61e47dd6858: asv: K&R formatting cosmetics [22:05] <cone-711> ffmpeg.git 03Michael Niedermayer 07master:4c731233338d: Merge commit 'f61e47dd68582529bcf6d42d861c70a320cd1b67' [22:14] <ubitux> oh ffs they found another k&r guy [22:15] <wm4> :) [22:15] <wm4> it's absurd [22:15] <ubitux> it looks like they seduce new comers with this [22:15] <ubitux> that's insane [22:15] <ubitux> :D [22:15] <Daemon404> but have you heard the word of our Lord and savior, sentient uncrustify script? [22:16] <ubitux> dropping all the { } around if/else wth [22:16] <ubitux> https://lists.libav.org/pipermail/libav-devel/2014-September/062936.html so much sadness :( [22:17] <cone-711> ffmpeg.git 03Gabriel Dume 07master:ff4d1aa8bc3f: flv: K&R formatting cosmetics [22:17] <cone-711> ffmpeg.git 03Michael Niedermayer 07master:c8be5258dec9: Merge commit 'ff4d1aa8bc3f4fe9d1f684f760b29c51adb569ef' [22:17] <Daemon404> wait [22:17] <Daemon404> that contains prettying previous-prettified parts [22:17] <Daemon404> but just in a different way [22:17] <Daemon404> wat [22:17] <ubitux> :D [22:18] <ubitux> remember the k&r dance on flashsv? [22:18] <wm4> didn't I say it's absurd [22:19] <ubitux> https://git.libav.org/?p=libav.git;a=commitdiff;h=293fe6da01b6cb2f85c6551553... ’ https://lists.libav.org/pipermail/libav-devel/2013-October/052569.html ’ https://lists.libav.org/pipermail/libav-devel/2013-October/052591.html [22:19] <ubitux> this one was funny [22:20] <ubitux> first one column align fields, second one added line breaks, and last one reverted align from the first [22:21] <ubitux> wm4: is the utf-16 patch ready to review so? [22:21] <wm4> ubitux: yes [22:22] <wm4> although I already know something should be done about srt probing (but what) [22:51] <cone-711> ffmpeg.git 03Diego Biurrun 07master:91d305790ea0: get_bits: Rename HAVE_BITS_REMAINING --> BITS_AVAILABLE [22:51] <cone-711> ffmpeg.git 03Michael Niedermayer 07master:9e59a7be1cc9: Merge commit '91d305790ea0f6fe0f54b48236da42181c39c18b' [23:04] <mirabilos> hi, when building libpostproc with --enable-pic --enable-shared on x32, I get: [23:04] <mirabilos> /usr/bin/ld: libpostproc/postprocess.o: relocation R_X86_64_32S against `.rodata' can not be used when making a shared object; recompile with -fPIC [23:04] <mirabilos> but it i2s2 using -fPIC& [23:06] <mirabilos> is there a way to figure out which line in the inline asm produces this relocation? [23:10] <michaelni> mirabilos, just tried building ffmpeg including libpostproc with pic for x86_32 and it works fine [23:11] <mirabilos> x32, not i386 [23:12] <mirabilos> hm, objdump -r (.rodata+0xa00) plus nm says they are against deringThreshold [23:12] <mirabilos> (and following) [23:13] <michaelni> and its just libpostproc and nothing else ? [23:14] <mirabilos> the libpostproc debian source package (which strigi depends on, which svn depends on, which git depends on& yak shaving here) [23:14] <mirabilos> with a small patch [23:14] <mirabilos> hold a sec [23:14] <llogan> ubitux, Timothy_Gu: any more comments on GIF demuxer doc? [23:14] <mirabilos> http://sprunge.us/FEWR [23:14] <mirabilos> that's needed because %4 is a pointer, which are 32-bit in x32 [23:15] <mirabilos> (but pushing/popping all 64 bit of the register doesn't hurt) [23:15] <mirabilos> hm ok, x86/asm.h LOCAL_MANGLE does not use rip-relative addressing [23:15] <mirabilos> Ill try to figure out why [23:16] <mirabilos> ah& [23:16] <mirabilos> #define ARCH_X86 1 [23:16] <mirabilos> #define ARCH_X86_32 1 [23:16] <mirabilos> #define ARCH_X86_64 0 [23:16] <mirabilos> this is wrong for x32 [23:17] <michaelni> well, if you get it working (and iam not sure how easy that will be ...) dont forget to submit a patch [23:18] <michaelni> btw, how can the code be build for x32 ? i mean what configure line are you using ? [23:19] <mirabilos> sure [23:19] <mirabilos> I think Debian uses the same configure line for all arches and relies on automatic detection [23:20] <mirabilos> just added set -x to configure ;) [23:21] <mirabilos> ah ok, got it& subarch="x86_32" because the sizeof(pointer) check results in 4 obviously [23:22] <iive> x32 is the 64 bit mode that uses only 32bit addressing, isn't it? [23:23] <J_Darnley> yes [23:24] <kepstin-laptop> yeah, I think the point was that it let you use all the registers from 64bit mode with the code size/cache benefits of 32bit pointers. [23:25] <mirabilos> yeah. [23:25] <kepstin-laptop> I'd be kind of surprised if assembly code written for either x86 or x86_64 would work completely as-is on it... [23:25] <mirabilos> I was waiting for it to became available for a loooong time :) [23:25] <mirabilos> funnily enough, most amd64 asm code _appears_ to work as-is, especially if you can let gcc guess sizes a bit [23:25] <mirabilos> is there any way I can test libpostproc stand-alone? [23:25] <mirabilos> just to see if it explodes [23:27] <J_Darnley> Oh god! Trying to use XOP is making this look even more messy [23:30] <llogan> J_Darnley: do you need more XPO testing? I think I may have a suitable CPU. [23:30] <llogan> *XOP [23:32] Action: mirabilos omg, if this is the amount of fun I get with the smallish libpostproc, how much will it be to port x264 which the nice new ffmpeg debian package depends on& [23:32] <llogan> looks like one machine here has a AMD A10-5800K [23:34] <kepstin-laptop> mirabilos: you could always just disable assembly; it's not like anyone actually uses x32 anyways ;) [23:34] <kepstin-laptop> although, amusingly, video encoding's probably one of the things that would benefit most. [23:37] <mirabilos> kepstin-laptop: meh I do, plus I want my mplayer back ;) [23:37] <mirabilos> tbh right now I miss it most for livestreams (radio), but x264 would be nice occasionally& [23:38] <mirabilos> but then, my orkstation's probably got enough oomph to do it without the asm part [23:38] <kepstin-laptop> I need 64bit for some stuff for the memory space, and 32bit for compatibility, so having a third set of libraries for x32 just seems silly. [23:38] <mirabilos> also, I believe yasm doesn't do x32 yet (ELF32 amd64), so I'll have to do that anyway [23:38] <mirabilos> nah, it's nicer because you get more registers, i386 is rather register-starved [23:39] <mirabilos> it's also not as nice because you do lose some flexibility :| but meh. I like it so far. [23:39] <kepstin-laptop> well, i get the registers in full 64bit mode; and that doesn't help with binary compatibility with existing 32bit apps. [23:39] <J_Darnley> llogan: yes in a short while. I will send a reply on the mailing list to say when. [23:40] <kepstin-laptop> I imagine disabiling assembly in x32 is going to cause a pretty horribly performance loss compared to x64_64 :/ [23:40] <J_Darnley> llogan: if you want to check the capabilities, run: make fate-cpu [23:41] <mirabilos> idc about binary compatibility, that's what open source is for [23:41] <kepstin-laptop> mirabilos: looks like yasm did add x32 support back in 2012. [23:42] <mirabilos> also, I ran i386 before :) not amd64. I only have a small chroot with amd64, for running qemu to run VMs with more than 2047 MiB RAM [23:42] <mirabilos> ah [23:42] <kepstin-laptop> if I didn't care about bin compat, I'd use 64bit only, because I have a few apps that need the big memory space and would want to avoid duplicate copies of libs. [23:43] <mirabilos> I prefer 32bit myself, so& [23:48] <mirabilos> huh, would you look at that, it built! now just to test& [23:48] <mirabilos> nie gesehen [23:48] <mirabilos> oops [23:49] <mirabilos> so, is there a standalone test program for it? [23:54] <AGinsberg> In the LICENSE file it says libfaac and libaacplus are non-free but both of the source files says it's Free, is it or not? [23:57] <BBB_> x32 oh god [23:57] <BBB_> lets create solutions for which no problem exists [23:58] <mirabilos> you need not use it yourself, but please recognise that there are others who wish to use it [23:59] <mirabilos> meh. i'm uploading this now. maybe we can test it as part of the chain later [23:59] <mirabilos> michaelni: where do you want the patch? [00:00] --- Wed Sep 3 2014