[FFmpeg-devel-irc] IRC log for 2010-07-21

[irc at mansr.com]

[00:01:17] <BBB> feel free to help also btw
[00:01:32] <BBB> since I have to ssh into someone else's computer, I'll probably be slower at this
[00:02:07] <Dark_Shikari> ok
[00:08:25] <Honoome> BBB: learn the pleasure of emacs for writing code remotely :D
[00:08:25] <Dark_Shikari> BBB: you should be specific
[00:08:27] <Dark_Shikari> "x86_64" is not a cpu
[00:08:39] <BBB> oh
[00:08:58] <BBB> model name	: Intel(R) Xeon(R) CPU           L5520  @ 2.27GHz
[00:09:33] <BBB> it's a quadcore
[00:09:36] <Dark_Shikari> does it have sse4?
[00:09:39] <BBB> we should abuse that and do threading
[00:09:50] <BBB> yes
[00:09:51] <BBB> fpu de tsc msr pae cx8 sep cmov pat clflush mmx fxsr sse sse2 ss ht syscall nx lm constant_tsc rep_good nonstop_tsc pni ssse3 cx16 sse4_1 sse4_2 popcnt hypervisor lahf_lm
[00:10:05] <Dark_Shikari> that's a Core i7
[00:10:39] <Dark_Shikari> BBB: is this all committed now?
[00:10:40] <Dark_Shikari> if not, commit it
[00:10:46] <BBB> it's all committed
[00:10:51] <BBB> my patchqueue is empty regarding vp8
[00:11:01] <BBB> I have a lot of uncommitted stuff, but nothing for vp8 ;)
[00:11:07] <Dark_Shikari> ok, great
[00:11:15] <Dark_Shikari> now you need to get Yuvi to commit his deblocking changes
[00:11:19] <Dark_Shikari> and emulated edge
[00:12:44] <Honoome> BBB: I could set up a container for an 8-core if you wanted to abuse threading :P
[00:12:46] <BBB> I want to test how well his decode_block_coeffs changes speed it up, is that noticeable at all?
[00:13:07] <BBB> Honoome: I don't know shit about video decoding and threading yet, so give me some time to get used to it :)
[00:13:25] <Honoome> okay, with a bit of luck it might turn into a 12-core by that time :P
[00:14:48] <BBB> first going home for dinner :)
[00:16:06] <Dark_Shikari> merge ffmpeg-mt
[00:16:10] <Dark_Shikari> then we will beat the crap out of vpx
[01:48:49] <saintdev> peloverde: is a long_start followed by a only_long valid?
[02:37:53] <saintdev> otherwise, seems to work \o/
[02:38:41] <saintdev> onto band info
[02:44:24] <saintdev> peloverde: what information does band_info() need to fill out?
[02:45:11] <funman> hi
[03:15:50] <saintdev> peloverde: all we get for a commit message on the addition of the 350 is "optimizations on mask_add and L3psycho_anal_ns"
[03:20:26] <saintdev> anybody here familiar with mp3?
[03:23:31] <UKCoder> quick question...  does anyone know where I can get a copy of the aac/mp4 spec without having to pay ISO?
[03:34:47] <astrange> search for the standard numbers
[03:34:50] <astrange> http://neuron2.net/library/mpeg2/iso13818-7.pdf
[03:35:09] <astrange> that's not the most up to date one of course
[03:39:16] <Compn> UKCoder : http://wiki.multimedia.cx has links to it
[03:47:33] <UKCoder> thanks
[03:54:04] <peloverde> long_start followed by only_log is not legal
[03:54:04] <peloverde> If you look at the window shapes it's pretty clear
[04:54:30] <funman> kshishkov: ping
[05:02:06] <kshishkov> whut?
[05:03:10] <funman> i have the rso/adpcm decoder working but there's one step i don't understand, can you shed some light?
[05:03:36] * kshishkov readies flashlight
[05:05:22] <funman> http://pastie.org/1053198 <- why is the shift needed?
[05:06:42] <kshishkov> you know, in reality output is in U8 format, so you can indicate that and output without any shifts or subtractions
[05:06:56] <funman> http://pastie.org/1053201 <- the pascal decoder calculates a 16 bits sample and outputs only 8 bits
[05:07:25] <funman> hm ok
[05:09:15] <kshishkov> but since existing ADPCM decoders in FFmpeg output S16 it's fine to convert output to s16
[05:09:25] <kshishkov> (I think)
[05:09:39] <funman> i can ask the guru
[05:10:03] <funman> also since the format is a bit different i added a new codec
[05:10:12] <josh> speaking of the guru
[05:10:17] <kshishkov> that's right
[05:10:22] <josh> mn has a new blog post up :)
[05:10:42] <kshishkov> funman: just submit and the guru will say how to improve/change it
[05:10:43] <josh> i love reading those, always learn a lot
[05:13:13] <kshishkov> indeed
[05:23:18] <CIA-99> ffmpeg: rbultje * r24378 /trunk/libavcodec/x86/ (vc1dsp_mmx.c vp8dsp.asm dsputil_mmx.c vp8dsp-init.c):
[05:23:18] <CIA-99> ffmpeg: VP8 MBedge loopfilter MMX/MMX2/SSE2 functions for both luma (width=16)
[05:23:18] <CIA-99> ffmpeg: and chroma (width=8).
[06:11:50] <thresh> moroning
[06:11:52] <UKCoder> any aac whizzes around tonight?
[06:14:01] <kshishkov> it's not evening here
[06:14:08] <kshishkov> thresh: morning
[06:16:01] <av500> morgen
[06:16:15] <kshishkov> god morgon
[06:17:08] <funman> mâtin
[06:19:00] <saintdev> UKCoder: you probably want peloverde, he left a little earlier
[06:20:53] <UKCoder> thanks saintdev
[06:21:23] <kshishkov> what's the question anyway?
[06:22:55] <UKCoder> I'm looking at programmatically concatenating two aac file (of the same bitrate, same number of channels) and I'm getting hung up on what needs to be altered in the headers
[06:23:03] <UKCoder> file=files
[06:23:29] <saintdev> oh yeah, kshishkov may be able to answer also, he wrote the encoder :P
[06:23:39] <UKCoder> :)
[06:24:19] <av500> UKCoder: aac files as in?
[06:24:41] <av500> what file format?
[06:25:15] <UKCoder> av500: a couple of WAV files encoded with neroAacEnc
[06:25:17] <av500> and isnt this a #ffmpeg type of question?
[06:25:27] <pJok> god morgon :)
[06:25:43] <av500> UKCoder: encoded into what? raw AAC, ADTS? ADIF? MP4?
[06:25:50] <UKCoder> av500: I'm not trying to achieve it with ffmpeg, just trying to understand how it's done
[06:26:04] <av500> UKCoder: encoded into what? raw AAC, ADTS? ADIF? MP4?
[06:26:45] <saintdev> LATM
[06:26:51] <UKCoder> av500: I'm guessing raw AAC (it's whatever output format comes out of neroAacEnc, not entirely sure)
[06:27:03] <saintdev> nero outputs mp4
[06:27:39] <UKCoder> thanks saintdev, I did notice a bunch of mp4 strings when I opened it up with mc
[06:27:52] <av500> UKCoder: well, then you cannot tweak the headers
[06:27:59] <av500> you need to demux and remux
[06:28:17] <av500> i bet ffmpeg can do that
[06:29:41] <UKCoder> av500: hmm... I really have to go through all that?  I'm trying to put together a simple program that dumps the contents of a few files concatenated together, to put a seemless stream.
[06:30:03] <av500> you? no, use ffmpeg
[06:30:20] <av500> and complain to apple for inventing mov/mp4
[06:30:39] <mru> mornings
[06:31:05] <UKCoder> av500: I wish I could use ffmpeg, but I'm writing this in java.  I figured ffmpeg devs would have done this already so I came here to see if I could pick some brains :)
[06:31:19] <mru> use xuggle then
[06:31:38] <av500> UKCoder: yes, ffmpeg devs did that, the results are inside ffmpeg
[06:32:24] <av500> UKCoder: can you tell me how to join 2 word documents in a simple java program?
[06:32:32] <UKCoder> av500
[06:32:55] <UKCoder> : actually yes :)  I've done that and painfully many other office formats before now for my day time job
[06:33:22] <UKCoder> audio tinkering is my spare time hobby (kinda)
[06:33:26] <av500> cool, so join in, we can make ffoffice :)
[06:33:41] <mru> Dark_Shikari: BBB: you broke icc
[06:33:45] <UKCoder> lol... I'd rather have hot pokers rammed inside me
[06:33:57] * mru rams a poker inside UKCoder 
[06:33:57] <av500> we can arange that too
[06:34:09] <UKCoder> you guys first :)
[06:34:18] <av500> you asked for pain, not us
[06:34:37] <Dark_Shikari> mru: I didn't do anything
[06:35:27] <kshishkov> Dark_Shikari: then stop being lazy and do something
[06:35:32] <mru> Dark_Shikari: you approved the patch
[06:35:46] <funman> av500: oFFice ? :)
[06:35:59] <mru> libavcodec/x86/vc1dsp_mmx.o:(.rodata+0x10): multiple definition of `ff_pw_18'
[06:36:10] <mru> libavcodec/x86/dsputil_mmx.o:(.rodata+0x160): first defined here
[06:36:10] <mru> ld: Warning: size of symbol `ff_pw_18' changed from 16 in libavcodec/x86/dsputil_mmx.o to 8 in libavcodec/x86/vc1dsp_mmx.o
[06:36:34] <Dark_Shikari> that wasn't me
[06:36:36] <Dark_Shikari> that was vc-1
[06:36:44] <Dark_Shikari> I think that was Yuvi's patch
[06:36:54] <kshishkov> anyway, feel free to fix it
[06:36:58] <mru> there were vc1 commits last night?
[06:37:10] <UKCoder> mru: have you used xuggle?
[06:37:13] <kshishkov> yes, loop filter for VP8 touched that file
[06:37:28] <mru> UKCoder: no, I wouldn't touch java with a pointed stick
[06:37:39] <votz> Anybody know what the variable name 'pb' (member of AVFormatContext of type ByteIOContext) stands for?
[06:37:45] <Dark_Shikari> I investigated that problem earlier
[06:37:47] <kshishkov> put bytes
[06:37:50] <votz> ah
[06:37:52] <Dark_Shikari> I have no idea what it is, because ff_pw_18 doesn't _exist_ in dsputil_mmx.c
[06:38:06] <mru> then it must be in some file it includes
[06:38:35] <mru> libavcodec/x86/dsputil_mmx.c:DECLARE_ALIGNED(16, const xmm_reg,  ff_pw_18 ) = {0x0012001200120012ULL, 0x0012001200120012ULL};
[06:38:42] <Dark_Shikari> oh.  yuvi screwed up
[06:38:49] <Dark_Shikari> he dedclared it twice
[06:38:51] <Dark_Shikari> or wait, did BBB add it?
[06:39:05] <av500> are you all just going to shuffle the blame all morning?
[06:39:06] <mru> libavcodec/x86/vc1dsp_mmx.c:DECLARE_ASM_CONST(16, uint64_t, ff_pw_18) = 0x0012001200120012ULL;
[06:39:28] <votz> kshishkov: ah, thanks
[06:39:29] <mru> so which one should be deleted?
[06:39:32] <funman> are fate builds triggered by svn post-commit hook ?
[06:39:46] <mru> funman: most of them are just polling
[06:39:47] <Dark_Shikari> mru: delete the vc1 one, expand the original to an xmmreg
[06:39:53] <kshishkov> av500: why not? it was very popular in bureaucratic countries (like USSR)
[06:39:57] <Dark_Shikari> and add it to dsputil_mmx.h if it isn't already there
[06:40:10] <mru> Dark_Shikari: the dsputil one is xmm_reg
[06:40:10] <saintdev> peloverde: think i can use the mdct coeffs in place of a fft for analysis?
[06:40:11] <funman> on #rockbox the CIA bot announces warnings/errors after each commit
[06:40:49] <peloverde> saintdev: That's what kostya's 3GPP-derived model does
[06:41:01] <peloverde> OTOH, one extra FFT isn't going to kill us
[06:41:14] <peloverde> IIRC psytel discussed this
[06:42:01] <peloverde> http://www.mp3-tech.org/programmer/docs/di042001.pdf
[06:42:17] <Dark_Shikari> mru: then delete the vc1 one
[06:42:31] <av500> ah, all the good research comes from belgrade!
[06:43:12] <peloverde> "Our improved coder is using MDCT for the psychoacoustic analysis, too. This way we are performing accurate estimate of the energy and also we are reducing complexity because MDCT output could also be used for the codec thus avoiding one transform. However, we also need complex values (imaginary part) of the transform in order to estimate tonality."
[06:43:42] <UKCoder> av500: I'm a lil confused about comment you made about having to mux and demux to join the two aac files together.  Not questioning the validity of the statement, just wondering how say a streaming server that's trying to concatentate content to a live stream would do that.  It seems like the first file would be transmitted and so couldn't be de/remuxed to the latter
[06:43:49] <peloverde> Anything from Ivan Dimkovic/PsyTEL should be treated as expert advice
[06:44:13] <mru> I can ask ivan dimkovic in person if you want...
[06:44:23] <saintdev> huh, i wonder how it compares then. there's a comment in the lame source that mentions using a shorter fft to match the mp3 window size may be better
[06:44:27] <av500> UKCoder: it cant
[06:44:30] <peloverde> I think his paper is very clear here
[06:44:53] <av500> UKCoder: this is the "beaty" of mp4
[06:44:56] <saintdev> peloverde: again, like he states in that quote they use the imaginary part for calculation
[06:45:00] <peloverde> "One of the possible solutions is using of CMDCT filterbank (Complex Modified Discrete Cosine Transform) that outputs MDCT as real part and MDST as imaginary part. CMDCT is also very good choice for LSI/DSP solutions because of reduced complexity when compared to ISO Model II approach (MDCT + FFT in parallel)."
[06:45:34] <UKCoder> av500: huh? I've seen dynamic source clients feed streaming servers where the files are added dynamically...
[06:45:58] <UKCoder> av500: things like edcast
[06:46:07] <av500> yes, but the resulting file sent to the client is not MP4
[06:47:11] <peloverde> saintdev: For now I would add a slow MDST and we can work on an optimized MDCT/MDST pair later
[06:47:41] <saintdev> peloverde: so i guess i'll just do fft for now, and maybe look into that later when i'm a little more knowledgeable ;)
[06:47:45] <UKCoder> av500: does that hold true for aac+ aldo?
[06:47:47] <UKCoder> also
[06:48:11] <av500> it does not depend on aac at all
[06:49:09] <peloverde> saintdev: OK, use FFT for now... one of the many DSP gurus can provide you with an MDST later
[06:50:59] <UKCoder> av500: k, now you've really confused me.
[06:51:19] <av500> UKCoder: the MP4 file format is not easily concatenable
[06:51:19] <mru> can one of the x86 guys please fix the ff_pw_18 error?
[06:51:36] <av500> UKCoder: regardless of which codecs are used
[06:51:54] <funman> use ogg
[06:52:12] <av500> yes, but make sure the stream ids are really random!
[06:52:17] <UKCoder> funman: I currently do, but it's lack of support on mobile devices is forcing me to look elsewhere
[06:52:43] <av500> use rtsp
[06:53:48] <funman> sandisk audio players support ogg vorbis but i don't know about video players
[06:54:06] <av500> sandisk audio players support streaming?
[06:54:28] <UKCoder> av500: so I could wrap the aac content in RTP (rather than RTSP) and use RTP as the glue?
[06:54:37] <mru> av500: yes, streaming off sd card
[06:54:40] <av500> yes, rtp/rtsp
[06:54:54] <UKCoder> av500: hmmm... that sounds promising
[06:54:56] <av500> mru: ah, Streaming Data card
[06:54:58] <funman> av500: not really
[06:55:32] <funman> though you could stream audio over usb
[06:55:43] <av500> funman: iKnow :)
[06:56:23] <av500> funman: I made the JB6000 stream music from a hard disk :)
[06:56:49] <funman> the sansa connect has wifi but i don't know how the firmware looks
[06:57:23] <UKCoder> av500: rfc3016 to the rescue then :)
[06:57:45] <funman> av500: nice, how/where did you send the stream?
[06:59:37] <av500> to the MAS of course :)
[06:59:42] <funman> bleh
[07:00:06] <av500> you dont like the MAS?
[07:00:11] <funman> no i don't
[07:00:39] <funman> (i was speaking about USB audio card btw)
[07:00:50] <av500> funman: ?
[07:01:42] <funman> av500: the archos jukebox is the single reason to keep a lot of old unmaintained code in rockbox source so i don't like anything related to this player :)
[07:01:57] <av500> but its the one that started it all!
[07:02:42] <funman> true
[07:02:48] <av500> I made a deliberately bad UI so that you could come along and fix it!
[07:03:41] <funman> noooooo
[07:04:10] * kshishkov asks jbr20 to write twenty FLAC encoders
[07:05:01] <jbr20> kshishkov: I'm not into flacellation
[07:05:43] * kshishkov now realizes that Vladimir's nick would make a nice library name
[07:06:02] <av500> av500? the 500th ffmpeg library?
[07:06:11] <mru> libav500, hmm...
[07:06:19] <funman> not the 501st?
[07:06:29] <kshishkov> should be good for tables
[07:06:29] <av500> like Heinz 57 sauce....
[07:07:46] <av500> funman: but i dont get why rb does not make one last jb/jbr release and then drops it....
[07:09:21] <funman> it has been mentioned already, so 'why?', because there was no consensus already
[07:09:38] <funman> rb has no leader who can make votes/decisions
[07:10:11] <av500> funman: you need more votes!
[07:10:46] <funman> unfortunately i don't know of a vote-counting fixed-point app!
[07:12:05] <kshishkov> try fixed-voting counting app then
[07:12:27] <av500> kshishkov: you have experience?
[07:12:38] <kshishkov> av500: I lived in Ukraine
[07:13:24] <av500> right
[07:13:34] <av500> do they now adjust the fixed vote count since you left?
[07:13:56] <kshishkov> I suspect it will be so for decades
[07:46:55] <CIA-99> ffmpeg: mstorsjo * r24379 /trunk/ (libavformat/gxfenc.c tests/ref/lavf/gxf):
[07:46:55] <CIA-99> ffmpeg: gxfenc: Fix ES name in the UMF media description, by using strlen instead of sizeof
[07:46:55] <CIA-99> ffmpeg: Patch by Thierry Foucu, tfoucu at gmail
[09:00:00] <av500> webm attracts very strange people: http://groups.google.com/a/webmproject.org/group/apps-devel/browse_thread/thread/5c1049b5a8b6d9cd?hl=en#
[09:00:16] <mru> I thought that was a property of the internet in general
[09:00:53] <cartman> av500: how is your Google today?
[09:00:55] <cartman> :p
[09:00:57] * mru fails to find connection between phone and guitar
[09:01:08] <av500> there is a fender labeled g1 or so
[09:01:21] <mru> the things people will pay for...
[09:01:56] <cartman> people would pay for ffmpeg on Android ;)
[09:02:08] <av500> it exists already
[09:02:17] <g0th> rock playerr
[09:02:25] <mru> and others I'm sure
[09:02:26] <av500> yup
[09:02:29] <g0th> btw they now released some sources
[09:02:34] <mru> yes, I know
[09:02:36] <g0th> but only of ffmpeg (standard sources)
[09:02:46] <g0th> and it is not clear how it fits into rockplayer etc
[09:02:56] <av500> lgpl
[09:03:01] <cartman> violation :)
[09:03:04] <mru> I suppose swapping out the .so is enough
[09:03:26] <g0th> I am happy that they deal with the problem at all
[09:03:27] <mru> they should of course provide source for any changes they made
[09:03:33] <mru> and the configuration they used
[09:03:33] <g0th> I am unhappy how they do it though
[09:03:48] <mru> but they seem to be trying to do the right thing at leasat
[09:03:50] <mru> -a
[09:03:54] <g0th> yes :)
[09:04:09] <av500> mru: dont assume they made changes
[09:04:30] <g0th> but afaics they simply took the standard sources and license files and put them somewhere on their webpage ^^
[09:04:39] <mru> statistically, the change they did is overwhelming
[09:04:57] <mru> and they still need say how they built it
[09:05:05] <cartman> wohoooo
[09:05:09] <cartman>  /usr/bin/ld: fatal error: out of file descriptors and couldn't close any
[09:05:19] <mru> too much ulimit?
[09:05:22] <av500> no OOFD killer?
[09:05:27] <cartman> too crap linker?
[09:05:29] <cartman> all of above
[09:05:35] <mru> try an incremental link
[09:05:46] <cartman> this is the so called "gold" linker
[09:05:47] <mru> ld -r groups of 100 objects or so
[09:05:49] <cartman> normal ld works fine
[09:05:52] <mru> oh
[09:05:53] <mru> gold..
[09:05:55] <mru> lol
[09:05:57] <cartman> ;)
[09:06:29] <av500> linking what?
[09:06:33] <av500> silverlight?
[09:07:04] <cartman> WebKitty
[09:07:08] <cartman> ;)
[09:08:39] <mru> did you try linking hno3.o and hcl.o?
[09:08:50] <cartman> dunnow those
[09:09:04] <mru> HNO3 + HCl = aqua regia
[09:09:11] <mru> dissolves gold
[09:11:47] <cartman> lol
[09:12:05] <kshishkov> it's called "Tsar's vodka" in Russian for some reason
[09:12:20] <av500> it dissolves the tsar as well
[09:36:10] <benoit-> mru: too bad this one's locked, you would have loved it: http://www.diffthink.com/forum/viewtopic.php?f=2&t=34
[09:38:21] <mru> I don't post on web forums anyway
[09:38:23] <mru> to much hassle
[09:40:02] <kshishkov> you posted on NVidia forum or so I heard
[09:40:21] <mru> there were good trolling opportunities there
[09:49:30] <Yuvi> wasn't there a discussion about getting rid of DECLARE_ASM_CONST?
[09:49:43] <mru> I tried
[09:50:09] <mru> why bundle used-by-asm with const?
[09:50:23] <mru> and with aligned
[09:50:35] <mru> don't we have av_used already?
[09:50:50] <mru> so DECLARE_ALIGNED(16, const av_used foo)
[09:51:27] <Yuvi> do you even need av_used on non-static global vars?
[09:51:40] <mru> never on non-static
[09:51:42] <mru> obviously
[09:51:55] <Yuvi> oh DECLARE_ASM_CONST is static
[09:52:13] <mru> yeah, so add static to my line above
[09:53:34] <Yuvi> so isn't icc's compilation failure their bug?
[09:53:34] <Yuvi> not that all the asm constants shouldn't be gathered in one place
[09:54:16] <Yuvi> or I guess it'd be weird either way
[09:54:27] <mru> it's a duplicate symbol
[09:54:34] <mru> how gcc doesn't fail is a mystery
[09:54:51] <Yuvi> ff_pw_18 isn't declared in any headers actually
[09:55:07] <Yuvi> so from vc1dsp_mmx.c's perspective, its static ff_pw_18 is the only one
[09:55:31] <mru> oh, I see what's going on
[09:55:39] <mru> for icc DECLARE_ASM_CONST _isn't_ static
[09:56:01] <mru> doesn't icc support attribute(used)?
[09:56:13] <Yuvi> no clue, never used it
[10:02:57] <CIA-99> ffmpeg: conrad * r24380 /trunk/libavcodec/x86/ (vc1dsp_mmx.c dsputil_mmx.c):
[10:02:57] <CIA-99> ffmpeg: Move ff_pw_* from vc1dsp_mmx.c to dsputil_mmx.c
[10:02:57] <CIA-99> ffmpeg: Should fix compilation with icc and should help prevent any future duplicates
[10:02:57] <CIA-99> ffmpeg: conrad * r24381 /trunk/libavcodec/x86/dsputil_mmx.h: Add header declarations for mmx/sse constants missing them
[10:03:28] <mru> thanks
[10:07:12] <CIA-99> ffmpeg: mru * r24382 /trunk/Makefile: Enable lavfi test in "make test"
[10:12:42] <Yuvi> hm, using multiple threads for libvpx decode appears to add 60% to user time while not affecting wall clock time at all
[10:13:23] <mru> heh
[10:13:28] <mru> that's called scalability
[10:13:31] <kshishkov> can you use enough threads to make user time > real time?
[10:13:41] <mru> you see, they do 60% more work in the same time
[10:13:44] <mru> so it's quite good
[10:14:07] <mru> kshishkov: with thread user time usually is > real time
[10:14:15] <mru> user time being sum of time by all threads
[10:14:49] <Yuvi> oh whoops, I was comparing the timing of two completely different videos
[10:15:47] <spaam> good job
[10:16:03] <Yuvi> with 2 threads, 40% more user time for 16% faster real time
[10:16:39] <mru> not impressive
[10:17:36] <Yuvi> yeah, they don't do frame multithreading and slice multithreading is limited to decoding coeffs *iff* the video is encoded with multiple partitions
[10:17:43] <kshishkov> mru: I know,  but it's be hilarious to see that most time spent on decoding is actually thread switching overhead
[11:30:46] <av500> finally RMS found a welcoming place: http://www.computerworlduk.com/community/blogs/index.cfm?entryid=3083
[11:31:17] <mru> "year of the GNU/Linux smartphone"
[11:31:23] <mru> there's nothing gnu in android
[11:31:25] <mru> only linux
[11:31:29] <mru> and android
[11:31:35] <mru> so it's android/linux
[11:32:36] <av500> since he uses a chinese laptop already, i thought he would maybe defect
[11:32:50] <mru> one can always hope
[11:34:17] <av500> maybe if the chinese firewall starts filtering closed source java script....
[11:34:41] <mru> that story about his laptop is just too funny
[11:34:52] <mru> why doesn't he just put seabios on a normal pc
[11:35:12] <av500> closed src gfx drivers?
[11:35:19] <mru> intel
[11:35:27] <mru> as open as they come
[11:35:30] <thresh> so, non-working gfx drivers
[11:35:38] <mru> works for me
[11:35:38] <av500> mru: poulsbo?
[11:35:40] <thresh> although I though he doesn't use X
[11:35:44] <thresh> thought
[11:35:46] <mru> av500: so don't get that one then
[11:35:50] <mru> arrandale works fine
[11:35:58] <av500> mru: same here :)
[11:36:12] <mru> haven't bothered with the nvidia chip
[11:36:18] <av500> idont have one
[11:36:30] <mru> I switched it off in bios
[11:36:33] <mru> saves power
[11:36:42] <av500> mine has only intel
[11:36:52] <mru> what machine?
[11:36:56] <av500> x210
[11:36:58] <av500> x201
[11:37:05] <mru> who makes?
[11:37:09] <thresh> mru: have you tried switching on-the-fly?
[11:37:11] <av500> lenovo
[11:37:58] <mru> thresh: no
[12:38:35] <CIA-99> ffmpeg: flameeyes * r24383 /trunk/ (5 files in 2 dirs): (log message trimmed)
[12:38:35] <CIA-99> ffmpeg: Make ff_inverse stay with libavutil, and optional copy it to libavcodec.
[12:38:35] <CIA-99> ffmpeg: The ff_inverse table is used by FASTDIV macro, defined in libavutil, but up
[12:38:35] <CIA-99> ffmpeg: to now the table was defined only in libavcodec.
[12:38:35] <CIA-99> ffmpeg: After this change, the main copy of ff_inverse is part of libavutil (just
[12:38:35] <CIA-99> ffmpeg: like FASTDIV), but if CONFIG_SMALL is unset, then a different copy is made
[12:38:36] <CIA-99> ffmpeg: available to libavcodec, to avoid the performance penalty of using an
[12:51:18] <benoit-> mru: do you have any plan to making config target use the 'quiet' output mode too ?
[12:52:01] <mru> now I do
[12:52:08] <mru> how would you like it?
[12:52:58] <benoit-> I don't really know
[12:53:16] <benoit-> mru: that's even "I really don't know" :)
[12:54:11] <benoit-> CONFIG would do I guess, maybe also having the configure options would be cool
[13:07:34] <Honoome> mru: is it wanted that the tablegen stuff is not in svn:ignore?
[13:09:17] <mru> Honoome: I don't maintain svn:ignore
[13:09:33] <mru> but anything generated during a build should be there I guess
[13:09:35] <Honoome> I think Diego is coming this way and probably unreachable :P
[13:11:02] <mru> aren't you also a diego?