[FFmpeg-devel-irc] IRC log for 2010-04-09

[irc at mansr.com]

[00:00:37] <mfg> nm, found it
[00:00:39] <mru> greater than pcr
[00:02:11] <mfg> I think i'm asking the wrong question.  How should I be calculating the current length (in time) of a stream based on the data I've read so far in the http stream?
[00:02:22] <mfg> this is for the shoutcast stuff I'm trying to get in
[01:19:36] <Kovensky> "In  40770 I'm more concerned with ffmpeg's SSSE3 assembly, which should be dispatched to with cpuid" <-- I can't parse this sentence
[01:19:55] <astrange> where?
[01:25:54] <Kovensky> * @peloverde pulls hair at the response to crbug.com/39969
[01:29:54] <peloverde> some people are getting SIGILLs because they compile with "-march=pentium4 -msse2 -mfpmath=sse"
[01:31:58] <Kovensky> lol @ -march=pentium4
[01:32:04] <Kovensky> I thought haruhi had retroactively unreleased it
[01:32:22] * Kovensky pokes pengvado for explanations
[01:33:41] <peloverde> So clearly the natural response is to manually set HAVE_SSSE3 and HAVE_LLRINT to 0
[01:33:59] <Kovensky> lulz
[01:34:37] <janneg> with patches to config.h of course
[01:34:44] * Kovensky wonders what's so hard in just using runtime cpu detect
[01:35:01] <astrange> you can't turn runtime cpu detect off
[01:35:11] <astrange> the configure option doesn't affect it
[01:35:12] <Dark_Shikari> the solution is to be like x264
[01:35:15] <Dark_Shikari> don't have a HAVE_SSSE3
[01:35:17] <Dark_Shikari> then people can't get confused
[01:35:42] <Kovensky> astrange: don't you have to turn it on in the first place (--enable-runtime-cpudetect)
[01:35:56] <Dark_Shikari> that's for swscale
[01:36:01] <peloverde> it says in config.h to not edit it manually
[01:36:05] <astrange> no
[01:36:11] <astrange> lavc does it no matter what
[01:36:15] <Kovensky> oic
[01:36:36] <Kovensky> weird option name / description then :v
[01:38:40] <peloverde> why are the policies different?
[01:40:11] <astrange> they were written separately and the swscale stuff was just stuck in ffmpeg configure at some point
[01:40:14] <astrange> ...i think
[01:40:34] <astrange> it should respect it, people keep trying to make ./configure --cpu disable stuff
[01:40:43] <astrange> which makes no sense as long as runtime detection is on
[01:42:05] <peloverde> it still makes sense
[01:42:14] <peloverde> makes the binary smaller if its features you will never use
[01:42:35] <peloverde> also maybe they are using buggy assemblers that don't support certain instruction sets
[01:43:26] <astrange> you can save a lot more by disabling runtime detect so it only does sse2 instead of mmx+sse2
[01:46:46] <peloverde> can't we just not compile mmx when there is sse or sse2 on x86-64 by default?
[01:47:10] <astrange> just disabling mmx doesn't work because some don't have newer versions
[01:47:20] <astrange> well, and because --disable-mmx disables everything, but even if it didn't do that
[01:48:43] <peloverde> yes, but can't we guard mmx when there is sse with !ARCH_X86_64?
[01:49:21] <astrange> i think disabling cpudetect would be simpler
[01:49:32] <astrange> too bad it depends on compiler optimization to delete the unused dsp functions
[01:49:47] <peloverde> but then you can't use anything newer than sse2 reliably
[01:50:04] <peloverde> I'm thinking about for instance distro packages for amd64
[01:50:32] <peloverde> not someone making an optimized swscale for their own system
[01:50:52] <Dark_Shikari> well I don't think it's very important to care about gentoo users anyways
[01:53:00] <peloverde> but we all know I'm an swscale hater
[01:53:15] <peloverde> so i probably shouldn't be trusted on this manner
[01:53:30] <peloverde> s/manner/matter/
[01:55:15] <peloverde> also the fact that they need sse in general to pass webkit layout tests makes me think they or webkit are doing something very wrong
[01:56:33] <astrange> i thought webkit texts used text dumps and not pixel testing
[01:56:35] <astrange> *tests
[01:56:41] <astrange> maybe they print too much precision
[02:00:33] <peloverde> jai, you were looking for me earlier?
[02:26:34] <Dark_Shikari> what's a good way in bash to pick a random file (recursively) from inside a folder?
[02:30:06] <Dark_Shikari> hmm, sweet, sort -R
[02:35:50] <votz> Dark_Shikari: could also do something like create an array of the files and then index into it randomly
[02:36:27] <Dark_Shikari> now I have a set of files and I need to name them 1.png, 2.png ...
[02:36:28] <votz> something like: set -- *; numfiles = $#; echo ${$((RANDOM%numfiles))}
[02:36:31] <Dark_Shikari> what's the easiest way to do that?
[02:36:33] <votz> or something like that
[02:36:46] <votz> this is why I stopped writing scripts in bash and started writing them in python :)
[02:38:09] <votz> Dark_Shikari:  I would just do this kind of stuff in python
[02:38:27] <votz> I can never remember the syntax for bash and I spend more time looking up stuff exactly like this
[02:38:36] <Dark_Shikari> oh this is fun
[02:38:38] <Dark_Shikari> I can use bc
[02:38:40] <votz> or choose your scripting language of choice
[02:38:49] <votz> bc?
[02:39:26] <Dark_Shikari> a = $(echo $a+1 | bc)
[02:39:30] <Dark_Shikari> i.e. a++
[02:39:32] <Dark_Shikari> lol bash
[02:41:16] <votz> lol
[02:42:10] <relaxed> a=$(($a+1))
[02:43:31] <Dark_Shikari> I love how bash has five billion ways to do every single thing
[02:43:35] <Dark_Shikari> none of which are really very clean
[02:46:32] <relaxed> what are you trying to do?
[02:47:06] <Dark_Shikari> make a loop that renames files to 0.png ... X.png
[02:47:09] <Dark_Shikari> already done though
[02:49:37] <Dark_Shikari> oh.  ugh.  I now need to reorder the frames.  they got inadvertantly "sorted"
[02:49:56] <Dark_Shikari> Guess I can abuse the same script.
[03:14:27] <pengvado> <peloverde> can't we just not compile mmx when there is sse or sse2 on x86-64 by default?
[03:14:30] <pengvado> not in general
[03:15:07] <pengvado> there are plenty of functions for which we have mmx but not sse2 versions
[03:15:32] <pengvado> so you can't globally disable lower levels, it has to be a function by function decision
[03:17:38] <peloverde> that's exactly what I mean
[03:17:40] <peloverde> *meant
[03:17:47] <peloverde> doing it function by function
[03:21:34] <Dark_Shikari> what's a good way to convert, say a 1920x170692 yuv file to bmp?
[03:21:35] <Dark_Shikari> or png
[03:25:01] <pengvado> ffmpeg -s 1920x170692 -i foo.yuv -y foo.png
[03:25:14] <Dark_Shikari> Isn't swscale capped at 4k?
[03:25:48] <Dark_Shikari> Or was that cap removed recently?
[03:25:52] <pengvado> 4k width, and anyway I increase that define for my own builds
[03:25:57] <Dark_Shikari> Aha!
[03:25:59] <Dark_Shikari> it's width-only.
[03:26:01] <Dark_Shikari> Nice.
[03:27:36] <Dark_Shikari> are higher compression levels of zlib slower to decode?
[03:27:38] <Dark_Shikari> or only encode
[03:28:43] <pengvado> higher zlib levels should be faster to decode because bits cost time
[03:29:24] <Dark_Shikari> ah k
[03:30:24] <pengvado> higher png levels might be slower due to the spatial prediction, or not if the fast level consist of always using paeth instead of just sometimes.
[04:44:43] <peloverde> was M_SQRT2 removed in c99?
[04:46:20] <peloverde> I see it listed here: http://www.opengroup.org/onlinepubs/009695399/basedefs/math.h.html
[04:46:33] <peloverde> but a simple test program fails with c99, but compiles fine with cc
[04:47:02] <astrange> M_SQRT2 is in xsi, not c
[04:47:15] <astrange> might need one of those -D_???_SOURCE things
[04:47:38] <peloverde> Ahh, the |XSI> is nested funny
[04:47:56] <peloverde> is there any reason why they couldn't have put it in C99, it's a fricken define
[04:47:59] * peloverde hates C
[04:48:35] <Dark_Shikari> wtf is M_SQRT2?
[04:50:03] <peloverde> 1.4142135623730950488
[04:51:00] <peloverde> A constant in math.h
[04:55:38] <Dark_Shikari> ah
[04:56:05] <peloverde> can I just go and stick it in mathematics.h or do I need to submit a patch?
[05:24:07] <merbzt1> peloverde: add it under ifndef
[05:39:04] <peloverde> Do people want baseline PS first or should I just do the whole thing at once?
[05:39:22] <merbzt1> peloverde: what is most easy for you ?
[05:39:30] <Dark_Shikari> what is baseline ps?
[05:39:36] <av500> peloverde: I never needed PS :)
[05:40:13] <peloverde> baseline ps is ps with the 34 stereo bands tool mode turned off and ipd/opd turned off
[05:40:29] <peloverde> it's more-or-less a strict subset
[05:40:59] <Dark_Shikari> what do encoders actually use?
[05:41:21] <peloverde> there are two ways of decoding the same file
[05:41:53] <peloverde> level 3 decoders only require baseline
[05:42:00] <peloverde> level 4 and 5 require full quality
[05:42:45] <peloverde> i'm sorry 2, 3, 4 are allowed to use baseline
[05:43:02] <peloverde> 5 must use full quality
[05:43:34] <Dark_Shikari> ugh
[05:43:36] <Dark_Shikari> I hate how aac does that
[05:43:54] <peloverde> (there is no level 1)
[05:46:02] <peloverde> AAC doesn't do that
[05:46:07] <peloverde> only HE-AAC
[05:46:22] <peloverde> (v1 and v2)
[05:46:29] <Dark_Shikari> they're still aac though
[05:46:50] <peloverde> then mp3pro is mp3 :)
[05:47:28] <peloverde> AAC is actually a very clean and simple format
[05:47:56] <peloverde> SBR is basically a big messing guided post-processor running in parallel
[05:48:37] <Dark_Shikari> isn't the spec published by the same people?
[05:48:59] <merbzt1> well published by iso, written by many
[05:49:14] <merbzt1> ct did most of sbr iirc
[05:49:53] <Dark_Shikari> I mean that's like saying that h264 high profile isn't h264...
[05:50:08] <Dark_Shikari> just because it was published later under a slightly different nam
[05:50:09] <Dark_Shikari> *name
[05:50:09] <peloverde> no, SBR was developed independently
[05:50:11] <Dark_Shikari> ah
[05:50:43] <peloverde> AAC was mostly Sony, NTT, Dolby, FhG, and AT&T
[05:51:09] <peloverde> Then CT showed up with their codec agnostic SBR
[05:51:31] <merbzt1> NTT added their vqf low bitrate stuff
[05:51:50] <merbzt1> Sony added SSR IIRC, abit like atrac
[05:52:12] <peloverde> yes
[05:52:31] <Dark_Shikari> aac seems like a giant mess
[05:52:38] <merbzt1> ohh, indeed
[05:52:51] <peloverde> AAC not a mess, MPEG-4 audio mess
[05:53:03] <merbzt1> what peloverde said
[05:53:47] <peloverde> there are a two or three awkward things about the AAC bitstream format but nothing seriously messy
[05:54:19] <merbzt1> sbr signaling and what else ?
[05:54:53] <peloverde> the PCE
[05:55:16] <peloverde> zero-sized codebook sections
[05:55:27] <kierank> what about that thing japanese tv does for changing between 2.0 and 5.1?
[05:55:39] <peloverde> that's out of spec
[05:55:47] <kierank> ah
[05:56:49] <peloverde> and it's related to the PCE as well (unless they are using mpeg surround to do it)
[05:57:13] <peloverde> The main profile predictor is messy
[05:57:23] <peloverde> but no one uses main profile
[05:57:49] <kierank> I wonder what the european aac channels do for 5.1->2.0 switching
[05:58:23] <merbzt1> like the sprite thingy in mpeg4 video
[05:58:35] <peloverde> I don't know, maybe send a new pce (out of spec behavior)
[05:59:04] <merbzt1> is there no support for channel reconfiguration ?
[05:59:13] <peloverde> one hack would be to just be to blank out the LFE, second CPE, and center channel
[05:59:35] <peloverde> you can code an empty channel in AAC very efficiently
[06:00:00] <peloverde> they could also use coupling to mix the same CPE into all 5 channels
[06:00:04] <merbzt1> ac3 just change the channel configuration from one frame to another, can't aac do that too ?
[06:07:22] <peloverde> there are some things that look they are there for that purpose, but it says that how to interpret them is undefined
[06:09:42] <peloverde> See section "4.5.1.2 Program config element (PCE)"
[06:12:30] <peloverde> It looks like if all PCEs are sent inband then you can change it with PCEs
[06:12:53] <peloverde> we don't support that feature at the moment
[06:16:32] <peloverde> I really need to look at boradcast use of AAC again at somepoint
[06:16:46] <peloverde> living in the ATSC world it hasn't been a high priority
[06:17:04] <kierank> do you have samples peloverde?
[06:17:19] <saintd3v> wish the FTC would get out of the 90s
[06:17:57] <peloverde> there may be one or two
[06:18:20] <peloverde> some with a country name and the channel count change marked in the name would be good
[06:18:57] <kierank> I have one japanese clip with a channel count change but you might well have fixed that
[06:19:18] <peloverde> e.g. dvb_aac_jp_5.1_to_2.ts
[06:31:55] <pJok> mornings :)
[06:32:41] <kshishkov> goda morgnar
[06:32:48] <kshishkov> (even if you have surgery)
[06:34:03] <pJok> 3½ hours
[06:35:26] <andoma> god morgon alltihopa!
[06:35:44] <kshishkov> hej (-:
[06:41:01] * peloverde pulls hair at crbug.com/39969 again
[06:41:32] <peloverde> "ffmpeg.gyp seems to build sse2 source files unconditionally on ia32/x64 (like source/patched-ffmpeg-mt/libavcodec/x86/idct_sse2_xvid.c and source/patched-ffmpeg-mt/libavcodec/x86/vp3dsp_sse2.c)" REALLY?!
[06:44:35] <aaronl> is this that chromium bug report again?
[06:44:53] <aaronl> that blew my mind
[06:46:49] <peloverde> Especially because runtime CPU check is explained once already in that bug
[06:46:50] <superdump> peloverde: maybe they don't want it to build them if they're patented
[06:46:56] <superdump> because they see xvid and vp3 or so
[06:47:07] <peloverde> vp3 is theora
[06:47:14] <peloverde> and the bug is about SIGILLs
[06:48:19] <peloverde> and the note that it also impacts Celeron makes me think it's not because of extra code in the binary
[06:48:30] <aaronl> i also read the linked bug #9007 report
[06:48:31] <peloverde> (the complaint that is)
[06:48:44] <aaronl> which was about SIGILLs due to -msse2 on ia32, back in march 2009
[06:48:52] <aaronl> and that report was even dumber
[06:49:10] <peloverde> people are getting SIGILLs becasue of "-msse2 -mfpmath=sse", hacking up config.h and the make files wont save them from any of it
[06:49:12] <aaronl> it looks like it took them months to stop blaming the ubuntu package maintainer, figure out that they were forcing -msse2, and decide what to do about it
[06:50:26] <siretart> them?
[06:50:49] <aaronl> the chromium devs
[06:51:18] <peloverde> chromium devs and fta (the ubuntu maintainer)
[06:52:28] <peloverde> basically chromium was SIGILLing on x86_32, so they turned off "-msse" and everyone was happy
[06:52:52] <peloverde> then they started building ffmpeg with the chromium build system and people started getting SIGILLs again
[06:53:13] <peloverde> because they are using the unmodified build system that has "-msse2"
[06:53:40] <aaronl> and apparently they still don't realize it's not because sse asm is turned on in ffmpeg
[06:54:02] <siretart> ah, I see. fun
[06:54:11] <peloverde> so instead of turning that off in the build system again, the ubuntu maintainer started trying to turn off the asm in FFmpeg to fix it
[06:54:19] <peloverde> I don't know whether to laugh or cry
[06:54:25] <siretart> btw, does libswscale properly runtime detect sse2 these days?
[06:55:02] <peloverde> I keep trying to catch the guy on IRC whenever he updates the bug
[06:55:48] <peloverde> I don't know, I know runtime detect is off by default for swscale
[06:56:04] <siretart> oh
[06:56:07] * siretart makes a note
[06:56:37] <peloverde> I don't know why it is off by default
[06:59:27] <peloverde> I try not to think about swscale most of the time
[07:04:13] <peloverde> do you have bugreports about SIGILL? :)
[07:56:16] <KotH> hoi zäme
[07:57:43] <scaphilo> hallo
[07:58:28] <kshishkov> ырфдщь
[07:58:33] <kshishkov> *shalom
[07:58:42] <av500> moin
[07:59:24] <thresh> ырфдщь тоже ничего
[08:00:03] <kshishkov> только слегка по-лошадиному
[08:03:20] <scaphilo> has anyone an idea why my motion compensation does not work anymore when i have dct-values instead of the dequanticed idct values in the picture data? when the motion vecor is zero everything works fine i have no clue why this happens perhaps its the dsputil-function wich changes my block
[08:04:23] <scaphilo> is it possible to remove the averaging function which is used in the b frames (as discussed yesterday)
[08:05:48] <KotH> kshishkov: http://translate.google.com/#auto|en|%D1%8B%D1%80%D1%84%D0%B4%D1%89%D1%8C
[08:07:07] <av500> only slightly on a horse
[08:07:30] <scaphilo> saved block in memory is: 255 128 128 128 128 128 128 128,  128 128 128 128 128 128 128 128 (7 times) white block But the bock i get is: 160 160 128 128 128 128 128 128, 160 160 128 128 128 128 128 128, 128 128 128 128 128 128 128 128 (6 times)
[08:11:01] <kshishkov> KotH: http://translate.google.com/#auto|en|kveldsflyet%20fra%20Oslo
[08:11:47] <KotH> rotfl
[13:18:00] <jai> hey BBB
[13:18:06] <BBB> howdy
[13:18:43] <BBB> ah, audio conversion
[13:18:44] <BBB> good task
[13:18:48] <kshishkov> have you applied as a student yet?
[13:18:57] <BBB> no, I don't think I'll have time
[13:18:57] <jai> kshishkov: yeah :)
[13:19:27] <jai> oh, i didnt know who it was directed towards
[13:19:32] <jai> meh
[13:20:45] <BBB> lol :) neither did I
[13:20:49] <BBB> we have 7 students now
[13:20:53] <BBB> more may come
[13:20:55] <BBB> so that's ok
[15:19:54] <scaphilo> short question: Where does a motionvector[forward][0][0]=-1 and motionvector[forward][0][1]=15 point to? frame based
[15:20:25] <scaphilo> next mb in same row
[15:20:54] <kshishkov> depends on MV resolution
[15:21:17] <scaphilo> oh am i forgott mpeg2
[15:21:30] <kshishkov> could be (-1, 15) or (-1 1/2; 7 1/2)
[15:21:36] <kshishkov> probably the latter
[15:21:59] <kshishkov> err (-1 + 1/2; 7 + 1/2)
[15:22:31] <mru> -1/2
[15:23:23] <scaphilo> i see, its a bit strange because i dont get the correct block back from the motion compensation
[15:23:57] <kshishkov> it's interpolated because of those 1/2
[15:24:26] <scaphilo> oh no, hmm that could be the reason
[15:24:30] <kshishkov> mru: correct, but it's more convenient to represent it that way for MC
[15:25:21] <scaphilo> i dont know what the function in the dsputil.c does
[15:25:37] <scaphilo> pix_op[0][dxy](dest_y, ptr_y, linesize, h);
[15:27:15] <scaphilo> im not enough experienced in c 	unfortunately
[15:28:37] <scaphilo> anyone knows where this interpolation is done? i want to have a look at the algorithm
[15:29:32] <kshishkov> simple averaging IIRC
[15:29:58] <mru> (a+b+1)>>1
[15:30:02] <kshishkov> I suspect it's  OPNAME ## _pixels_xy2_c from dsputil.c in your case but good luck understanding it
[15:32:00] <scaphilo> hmm shit this does not work with dct coefficients of cause
[15:32:12] <scaphilo> hmm i have to finde an other way
[15:32:53] <scaphilo> thx for help
[15:35:14] <kshishkov> well, if you transform those blocks too you can average DCT coeffs ;)
[15:39:57] <av500> kshishkov: its a linear transform, no?
[15:40:44] <kshishkov> whatever, but T(a+b) = T(a) + T(b) in case of FFT and DCT
[15:41:39] <mru> isn't that what linear means?
[15:42:00] <kshishkov> but DCT is curvy
[15:42:11] <mru> yes, linear curves
[15:42:39] <KotH> kshishkov: DCT is just one point in hilbert space :)
[15:42:42] <scaphilo> am yes the thing is you cant average half of a block
[15:43:04] <scaphilo> when this half is empty
[15:43:30] <scaphilo> or do i understand something wrong? its an average of a half block not of a half macroblock
[15:43:51] <kshishkov> KotH: have I mentioned that I've forgotten all math long time ago?
[15:44:07] <kshishkov> nope
[15:44:22] <mru> everybody has
[15:44:25] <mru> no need to mention it
[15:44:26] <kshishkov> it's an average of block and block shifted by one pixel
[15:44:39] * elenril never knew what dct is =p
[15:44:48] <scaphilo> oh my god then its impossible to do with dct's
[15:45:09] <mru> what are you trying to do?
[15:45:11] <scaphilo> just imagin a white block is in dct just one value
[15:45:13] <av500> to do what?
[15:45:24] <scaphilo> well openloop transcoding
[15:45:32] <scaphilo> i just wannet to make the mc
[15:45:40] <scaphilo> no practical use at all
[15:46:06] <KotH> scaphilo: you cannot perform mc on DCT values
[15:46:18] <av500> maybe fc
[15:46:20] <scaphilo> now i know
[15:46:31] <KotH> scaphilo: well, you can.. but the math behind it is more complicated than just doing an iDCT
[15:46:43] <av500> KotH: just redefine "motion"
[15:47:21] <scaphilo> is it possible to only allow the encoder making movings of about 8 pixels or a multiplication of it
[15:47:28] <KotH> av500: i'm not a mathematitian :)
[15:48:03] <KotH> scaphilo: use 16pixel for 4:2:0 subsampled, 8x8 DCT based codecs
[15:48:31] <KotH> scaphilo: otherwise the colour CrCb info will be shifted by 4 pixels
[15:50:37] <scaphilo> ah i see ill try that just for test
[15:50:45] <scaphilo> then it should work for my app
[15:51:41] <KotH> hmm.. you are aware that motion vectors usually do not point to a single 8x8 DCT block?
[15:52:00] * KotH wonders what exactly scaphilo is doing
[15:53:20] <scaphilo> normaly the whole macroblock, right :-). The thing is, i want to test if i correctly made my changes in the code currently i transcode the video without idct dct dequantisation and  quantisation
[15:53:33] <av500> scaphilo: from what to what?
[15:53:34] <scaphilo> to go is still motioncompensation and motionestimation
[15:53:40] <scaphilo> mpeg2 to mpeg4
[15:53:45] <scaphilo> part2
[15:54:39] <scaphilo> dam i studied arround for 16 hours and didnt find out why it didnt work with this motion compensation :-(
[15:54:56] <scaphilo> shit but i couldnt explain it befor
[15:55:15] <KotH> scaphilo: nope, the MV point to a "random" place in half or quater pixel resolution. dh if you start shuffling around MV, you have to be carefull what happens when you involve partial macroblocks
[15:56:12] <av500> KotH: dh?
[15:56:18] <scaphilo> which means
[15:56:24] <scaphilo> german
[15:56:52] * av500 forgot scaphilo was compatible
[15:57:19] <KotH> lol
[15:57:24] <mru> when he's in that mode
[15:57:31] <mru> in native mode he's only somewhat compatible
[15:57:37] <mru> koth, that is
[15:57:38] <KotH> please correct me someone, if i say something wrong
[15:57:42] <scaphilo> :-) hmm ok KotH, ill leave this step and go on to the full open loop implementation
[15:57:55] <mru> omg, someone is wrong on the internet!!!
[15:58:11] <av500> keeps you awake at nights...
[15:58:20] <KotH> scaphilo: die motionvektoren zeigen von ganzen makroblock auf regionen. es sind verschiebungsvektoren die irgendwo hin zeigen können
[15:58:24] <scaphilo> very strange in here :-)
[15:58:42] <KotH> scaphilo: bei mpeg2 haben diese vektoren eine auflösung von einem halben pixel, bei mpeg4/h.264 haben sie viertelpixel
[15:58:49] <mru> motion? not bewegung or something?
[15:59:04] <av500> denglish
[15:59:06] <kshishkov> mru: is KotH summoning Satan or what?
[15:59:15] <scaphilo> exacly
[15:59:25] <KotH> av500: should i have said "bewegungsvektoren" ? :)
[15:59:26] <av500> kshishkov: no, only Dark_Shikari
[15:59:42] <scaphilo> KotH thank you very much, das hat jetzt schon noch geholfen.
[15:59:50] <scaphilo> i have an other problem, the qscale is different
[15:59:58] <scaphilo> but i fixed it to one
[15:59:59] <mru> mpeg4 also allows MVs per block
[16:00:06] <mru> where mpeg2 has them per MB
[16:00:21] <av500> I guess mpeg4 allows all of them to be the same
[16:00:26] <mru> of course it does
[16:00:45] <scaphilo> it should work i think - well i hope it works :-)
[16:01:10] <av500> hoffnung stirbt immer zuletzt...
[16:01:24] <KotH> scaphilo: if you are in zh, you can drop by here and i give you a short tour trough video coding (as far as i know it, which is very little)
[16:01:57] <scaphilo> im sure you know a little ;-) but a very little more than me
[16:02:03] * KotH blames everyone here, including himself, for not working on BoW
[16:02:54] <scaphilo> i think about that KotH thank you for inviting, do you still work on the ETH
[16:03:05] <KotH> hmm.. maybe i should take my laptop with me this weekend and write a few lines during the train trip
[16:03:15] <KotH> scaphilo: nope, i graduated long ago
[16:03:19] * KotH is a very old fart
[16:03:46] <kshishkov> KotH: well, compared to Dark_Shikari (and maybe superdump) we all are
[16:03:58] <scaphilo> i work as an "assistent" at HSR
[16:04:04] <scaphilo> since 2 years
[16:04:10] <KotH> s/since/for/
[16:04:12] <KotH> ;)
[16:04:18] <scaphilo> dam
[16:04:18] <mru> since is correct
[16:04:23] <KotH> is it?
[16:04:30] <mru> oh yes
[16:04:39] <KotH> mru: hmm.. do you want to tell me that all my english teachers were wrong?
[16:04:50] <mru> it implies an ongoing activity that started 2 years ago
[16:05:14] <KotH> hmm... ok
[16:05:18] * KotH takes notes
[16:05:24] <scaphilo> :-) im not
[16:05:30] <mru> if you say "I worked ... for 2 years" it means it lasted for 2 years but is over now
[16:05:30] <kshishkov> with "ago" missing it looks like somebody started working _when_ two years old
[16:05:35] <KotH> scaphilo: you are most probably still younger than i am
[16:05:44] <mru> kshishkov: wrong
[16:05:55] <kshishkov> mru: I'd use "have been working for 2 years"
[16:06:04] <mru> that's also correct
[16:06:11] <av500> kshishkov: in ukraine?
[16:06:17] <scaphilo> well i would really like to talk a little more but i gtg
[16:06:35] <KotH> schös wuchenend und gnüss d'sunne!
[16:06:43] <scaphilo> danke gliichfalls :-)
[16:06:46] <scaphilo> at all
[16:06:53] <scaphilo> or to
[16:06:54] <mru> KotH: guess what, the sun is shining here too
[16:07:03] <KotH> mru: that must be an illusion!
[16:07:11] <KotH> mru: or you're still in .se :)
[16:07:12] <mru> well, this isn't london...
[16:07:18] <kshishkov> av500: that was an example, I have no intent of working here. And I'm not sure local wages justify using verb "working" anyway
[16:07:20] <mru> no, I'm in southampton
[16:07:42] <KotH> kshishkov: slavery?
[16:08:17] <kshishkov> KotH: self-slavery sometimes
[16:08:21] <peloverde> Also with "since" if you are using a duration (vs a specific time) you need an "ago"
[16:09:11] <KotH> peloverde: "since 2 years ago" ? :)
[16:09:23] <peloverde> yes
[16:09:24] <kshishkov> KotH: yes
[16:09:25] <KotH> er.. s/:)//
[16:09:32] * KotH wonders where that smiley came from
[16:10:36] * KotH wonders what he is still doing here
[16:11:01] <Honoome> KotH: avoiding work!
[16:11:07] <Honoome> that was an easy answer :P
[16:11:11] * KotH wonders what effect school uniforms have on children
[16:11:37] * KotH wonders why he is asking himself all these questions
[16:12:04] <mru> uniforms make them all look alike
[16:12:04] <kshishkov> LHC affecting brain cells?
[16:12:11] <Honoome> maybe you considered the fact that female high-school uniforms have effects on adolescents ^^ -- yeah I'm the one avoiding work I guess
[16:12:26] <KotH> mru: that's the outside effect, but what is the psychological effect on them?
[16:12:28] <av500> no, me too
[16:12:34] <mru> KotH: go to japan and see
[16:12:45] <KotH> mru: been there, done that
[16:12:55] <KotH> mru: missing reference schools
[16:13:02] <av500> I thought school uniforms were invented by anime guys, no?
[16:13:13] * KotH doenst know of any schools that do not have school uniforms in .jp
[16:13:21] <KotH> av500: nope, they are older
[16:13:31] <kshishkov> av500: no, Japanese school uniforms were borrowed from pre-WWI Germany
[16:14:09] <KotH> av500: iirc japanese started using school uniforms in early meiji era (1870s), and used the preusian school uniforms as an example
[16:14:11] <kshishkov> then probably Germans decided not to be associated with anime and ditched them (just a guess)
[16:14:54] <KotH> kshishkov: i think it was that the allied forces in WWI forced the dissolution of preussian schools and their uniforms after WWI
[16:15:42] <kshishkov> KotH: they may have anticipated anime and could not stand a thought of kawaii Germans
[16:16:30] <Honoome> kshishkov: isn't that … you know … a oxymoron? :P
[16:16:56] <kshishkov> Honoome: my point exactly
[16:17:22] <Honoome> [quite sure next time Diego is going to kick me hard but … :P]
[16:17:45] <twnqx> what to you think the WWs *really* were about...
[16:17:48] <twnqx> do*
[16:18:10] <kshishkov> "German starts and loses" activity
[16:18:34] <twnqx> true, but there must be areason people are so desperate to start a war!
[16:19:15] <kshishkov> it's called "untermensch" - Serbs and Poles
[16:19:41] <KotH> WWI was all about "HE SHOT MY SON!!!!einself"
[16:22:16] <kshishkov> you know that German occupation plan for Ukraine in WW2 included building autobahns on its territory? Local people could not stand it and that's why Germans eventually lose
[16:23:29] <kshishkov> building good roads in Ukraine is unhuman
[16:36:06] <KotH> kshishkov: http://pics.nase-bohren.de/japan_vs_germany.jpg
[16:37:20] <av500> school uniforms?
[16:37:50] <kshishkov> KotH: be thankful you've not seen Russian cosplay
[16:39:17] * KotH is
[17:31:37] <kshishkov> BBB: haven't changed your mind yet?
[17:31:46] <BBB> no
[17:32:05] <BBB> I don't think I want to commit that much time to it while I should graduate
[17:32:10] <kshishkov> fine
[17:32:11] <BBB> better be a mentor
[17:32:19] <kshishkov> :)
[17:32:50] <jai> heh
[17:33:24] <kshishkov> I admit it was hard to me to finish RTMP support while being in Stockholm
[17:35:27] <kshishkov> still, I think you'll get better student this year
[17:53:37] <CIA-1> ffmpeg: jai_menon * r22823 /trunk/ffplay.c: ffplay : Add 's' to the list of supported commands.
[17:58:05] <BBB> oops
[18:43:37] <nfl> BBB: I've decided to take up amr-wb
[18:47:08] <_av500_> \\\ooo///
[18:47:58] <jai> _av500_: you actually use amrwb?
[18:48:23] <_av500_> no
[18:48:42] <_av500_> but i cheer up all gsoc students
[18:50:52] <Honoome> it's all a revision closer to total world domination ;)
[18:51:24] <jai> _av500_: ah, the burden of a mentor :)
[18:52:26] <nfl> _av500_: thanks :)
[19:11:35] <DonDiego> gtg, cu
[19:12:33] <_av500_> jai: i like to see young innocent people submit themselves to ffpatch review system
[19:13:06] <jai> _av500_: heh :) i see now
[19:15:36] <elenril> av500: i _knew_ you were evil
[19:15:45] <elenril> lol
[19:16:01] <jai> heh
[19:17:20] <drv> it builds character ;)
[19:23:37] <pJok> char build; ?
[19:27:40] <Honoome> build = rand() & 0xff;
[19:32:20] <jai> Honoome: av_lfg_get ;)
[19:36:56] <BBB> where is nfl?
[19:37:06] <BBB> darnit :) we have another student applying for amrwb
[19:37:22] <jai> BBB: mail him perhaps
[19:37:27] <BBB> yeah
[19:38:09] <jai> so how many qualified students so far?
[19:40:19] <BBB> nfl is qualified, I think
[19:40:23] <BBB> and zhentan / josh
[19:40:53] <BBB> then 3 more where the qualification is progressing, afaics
[19:41:30] <BBB> then yours, which I guess doesn't need a qual task
[19:41:41] <BBB> and one more of a student but I don't know who he is, but he claims to be talking to kostya
[19:44:46] <BBB> jai: did you talk to alex
[19:44:47] <BBB> ?
[19:52:30] <_av500_> yes!! http://www.swfme.com/view/1046212
[19:52:35] <_av500_> sorry, bad evil flash
[19:52:56] <mru> hell?
[19:54:39] <elenril> lol
[19:55:44] <_av500_> yes, hell
[19:56:01] <mru> flash sounds suitable for that...
[20:11:02] <_av500_> lol, blink tag of death: http://www.zerodayinitiative.com/advisories/ZDI-10-031/
[21:34:01] <astrange> http://google-opensource.blogspot.com/2010/04/interesting-times-for-video-on-web.html confused strategy there
[21:39:28] <peloverde> How does TheorARM compare to fftheora on arm?
[21:40:23] <astrange> fftheora surely beats regular libtheora on arm
[22:26:34] <bcoudurier> hi guys
[22:37:05] <Tjoppen> evening
[22:40:08] <Tjoppen> bcoudurier: should I simply commit that fixed mov patch on the list? I assume so, since I changed the hexes to decimal
[22:40:21] <bcoudurier> yes go ahead
[22:40:31] <CIA-81> ffmpeg: michael * r22824 /trunk/libavformat/utils.c:
[22:40:31] <CIA-81> ffmpeg: Dont try to compute AVPacket duration for possibly interlaced video codecs
[22:40:31] <CIA-81> ffmpeg: when no parser is available.
[22:40:31] <CIA-81> ffmpeg: This partly fixes the frame rate misdetection in issue1756.
[22:40:34] <Tjoppen> ok. I'll do that tomorrow or monday then
[22:41:01] <Tjoppen> depending on when I feel like going to work :o
[22:45:16] <Tjoppen> btw, anyone have any good ideas of what to do during my visit to london in two weeks? a friend of mine is going over to watch chelsea, so I'm going to join him on a beer trip (and some football I guess)
[22:45:36] <Tjoppen> imperial war museum is a must probably
[23:30:40] <CIA-81> ffmpeg: alexc * r22825 /trunk/libavutil/mathematics.h: Add M_SQRT2 to the constants in mathematics.h.
[23:42:34] <ramiro> Tjoppen: try searching for a british person... you'll see people from all around the world, but brits are hard to find there...