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

[burek]

[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%29%20BluRay.edited.srt
[20:38] <ubitux> https://code.mythtv.org/trac/raw-attachment/ticket/9836/Chalet%20Girl%20(2011)%20BluRay.edited.srt
[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=293fe6da01b6cb2f85c6551553ed765a7408ca23 ’ 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