[FFmpeg-devel-irc] IRC log for 2010-03-18

[irc at mansr.com]

[05:43:37] <duncan__> ok
[05:43:39] <duncan__> hello
[05:43:50] <duncan__> question about j2k codec
[06:30:47] <thresh> mourning
[06:30:55] <kshishkov> whom?
[06:33:36] <thresh> my whole life
[06:34:22] <kshishkov> agreed
[06:34:32] <kshishkov> maybe you should move to Switzerland?
[06:35:46] <av500> or sealand
[06:36:13] <thresh> switzerland suits me landscape-wise
[06:38:56] <kshishkov> it's not all about you, someone should convince KotH that life may be not so bright
[06:39:35] <pJok> god morgon :)
[06:39:37] <kshishkov> I don't mind if your life becomes better though
[06:39:46] <kshishkov> goda morgnar, pJok
[07:15:03] <KotH> a wonderfull, beautifully sunny good morning! (modulo ukranians)
[07:15:27] <kshishkov> x % 0 = ?
[07:15:38] <KotH> \inf
[07:16:27] <kshishkov> no, it's 0. You should've said "modulo civilised world"
[07:16:50] <kshishkov> which also excludes wonderful London mornings though
[07:17:05] * KotH has never seen a wonderful morning in london
[07:17:30] <kshishkov> you don't like fog, smog and rain?
[07:18:29] <KotH> nope, i dont
[07:18:52] <kshishkov> ok, not wonderful London mornings for you either
[07:18:55] <kshishkov> *no
[07:22:13] <av500> kshishkov: there is no more fog in london
[07:22:59] <kshishkov> never?
[07:23:15] <av500> not as much as there used to be...
[07:23:28] <kshishkov> it's not a pity
[07:23:46] <av500> and I saw nice mornings there too :)
[07:24:00] <thresh> no such thing as nice morning
[07:24:09] <kshishkov> in Russia
[08:23:43] <kshishkov> http://www.engrish.com//wp-content/uploads/2010/03/tiny-grass-is-dreaming.jpg - it may be even funnier for mru/thresh
[08:26:24] <thresh> yeah
[08:28:49] <av500> http://briancrescimanno.com/2010/03/17/dear-mozilla-please-dont-kill-html5-video/
[08:28:53] <av500> some ppl have sense left...
[08:30:49] <kshishkov> you mean those? http://openvideoalliance.org/2010/03/lets-get-video-on-wikipedia/
[08:31:33] <KotH> kshishkov: i think i'm too used to jenglish to find it that funny ^^'
[08:32:07] <kshishkov> KotH: compare English and Japanese translations for example
[08:32:15] <kshishkov> and Russian is most hilarious
[08:32:16] <thresh> and a russian one
[08:32:58] <kshishkov> it's correct though
[08:33:01] <KotH> kshishkov: they match quite well :)
[08:33:51] <av500> kshishkov: with the given trend of replacing written internet editorial content with blurry shaky boring yutube videos, I think it is a perfect thing for wikipedia - no more edit wars over spelling and puctuation...
[08:35:49] <elenril> KotH: the correct term is engrish =p
[08:36:15] <kshishkov> especially since that example is from Chinese
[08:38:59] <KotH> elenril: no, engrish is what usians speak ;-)
[08:39:15] <KotH> elenril: in contrast to the japanese jenglish and the german denglish
[08:40:14] <kshishkov> KotH: Denglis_c_h
[08:41:01] <av500> kshishkov: that still misses _a_
[08:41:24] <KotH> dänglisch?
[08:41:34] * elenril throws some more utf-8 at KotH 
[08:41:41] <av500> well, it needs to have _d_, _a_ and _ch-
[08:42:17] <KotH> chum etz! d'schwyzer chöi es ganz guets englisch
[08:42:30] <kshishkov> av500: you should have roof by now
[08:42:43] <av500> indeed
[08:43:50] <kshishkov> av500: for some reason Ukrainian word for roof sounds the same as German one
[08:44:15] <thresh> крiiiiша?
[08:44:32] <kshishkov> дах
[09:13:23] <kshishkov> mate!
[09:13:28] <pross-au> Hey
[09:14:30] <kshishkov> what're you going to do when all multimedia from EA games can be played with FFmpeg?
[09:15:38] <av500> elenril: nice!
[09:16:45] <pross-au> I will join the RE-holics anonymous
[09:17:14] <kshishkov> and IIRC you had only two codecs left
[09:18:24] <pross-au> Your IIRC is wrong
[09:18:32] <twnqx> pross-au: you could hack sane to support my scanner, should only be minor changes :P
[09:21:07] <kshishkov> twnqx: a block of wood should be enough
[09:32:58] <elenril> av500: it'd be nice if you could test it
[09:33:27] <elenril> i'm still not sure i got timestamp transformations right
[09:34:28] <av500> that would assume I would know how to use ffmpeg with more than one in and out file... :)
[09:34:48] <kshishkov> consequently!
[09:35:29] <kshishkov> ffmpeg -i in1 -i in2 ... out1; ffmpeg -i in1 -i in2 ... out2
[13:22:21] <sh311> jai: hi this is naufal. can i pm you?
[13:41:18] <twnqx> janneg: how i get the resulting pics to you? :P
[13:43:44] <peloverde> BBB, I can look at that stuff today
[13:43:52] <BBB> yay
[13:43:58] <BBB> you want me to send it per email?
[13:44:09] <peloverde> yeah, that will work
[13:45:02] <BBB> sent
[13:46:50] <dgt84> Anyone know if new libavfilter filters are welcome? I see a lot are still stuck in the SoC repo. I wrote a quick one to modify brightness yesterday to try and learn how it all works and am porting MPlayer's vf_unsharp for a project.
[13:47:59] <KotH> if you are porting over filters, make sure you either make them GPL or rewrite them from scratch and make them LGPL (which is preferred)
[13:48:32] <KotH> or ask the orignal author whether he minds if you use his code as lgpl
[13:50:58] <Dark_Shikari> There are tons of avisynth filters you can probably port
[13:51:18] <dgt84> KotH, looks like the original is GPL 2+, but I can email him and see what he says. I'm not sure about a reimplementation, that unsharp filter is a pretty close 1:1 implementation of a paper on the subject, same variables and everything
[13:52:56] <merbzt> dgt84: post to ffmpeg-dev
[13:53:10] <dgt84> afaict this is the paper: https://docs.google.com/viewer?url=http://www.engin.umd.umich.edu/~jwvm/ece581/21_GBlur.pdf
[13:53:10] <merbzt> stefano and michael will probanbly care
[13:54:50] <KotH> dgt84: it doesnt matter on what it is based, copyright still applies
[13:55:05] <thresh> __gb__: could i poke you with some patches for libva-sds?
[13:57:45] <dgt84> KotH, yeah, will contact the author then
[13:58:05] <dgt84> merbzt, alright, will go get flamed
[13:58:13] <merbzt> :)
[13:58:39] <dgt84> Dark_Shikari, if you have any avisynth filters in mind let me know, I'll throw the list on the wiki or something and then others will know what is worth porting over.
[13:59:02] <Dark_Shikari> dgt84: the real problem is a lot of the best "filters" are scripts involving other filters
[13:59:10] <Dark_Shikari> e.g. masktools, mvtools, all combined to make a big fancy filter
[13:59:12] <justlooking> KotH, your saying you can copyright an algorithm in some countrys ?
[13:59:15] <Dark_Shikari> like tempgaussmc, the world's best deinterlacer
[13:59:29] <twnqx> s/best/best and slowest/
[13:59:31] <KotH> justlooking: not the algorithm, but its implementation
[13:59:48] <KotH> justlooking: if you base your implementation on another, you have to abide copyright
[14:00:07] <KotH> justlooking: if you base your implementation only on the description of the algorithm, copyright doesnt apply
[14:02:53] <dgt84> Dark_Shikari, ah yeah, I've seen some of the more complex things. I think I used mvtools to deshake some video a while back and it was fairly complicated. I'll probably only be paid to port sharpening, deinterlacer like yadif, and maybe some postproc stuff. The rest I'd have to do outside of work.
[14:04:41] <twnqx> ugh
[14:04:50] <twnqx> i just stab() the video in such cases :P
[14:05:10] * KotH stabs some randome mere mortals in the channel
[14:05:51] <siretart`> sorry, german only, but did you already notice this: http://www.heise.de/newsticker/meldung/Aldi-und-Lidl-wegen-MPEG-Patentverletzungen-verklagt-957555.html?
[14:06:28] <siretart`> english: the supermarkets 'aldi' and 'lidl' (both *very* polular in german) are being sued by MPEGLA
[14:06:40] <twnqx> could be interesting
[14:06:46] <twnqx> since software patents are not legal in .de
[14:06:47] <twnqx> :>
[14:06:50] <dgt84> oh noes, I actually bought a computer at Aldi Sued once
[14:07:04] * twnqx reports dgt84 to the MPEGLA
[14:07:16] <dgt84> :-P
[14:08:37] <siretart`> they are being sued for selling dvd players, btw.
[14:09:15] <KotH> siretart`: wtf?
[14:09:17] <twnqx> among other things
[14:09:22] <KotH> siretart`: do you know how the medion case ended?
[14:09:25] <twnqx> no mpeg2 license.
[14:16:46] <siretart`> KotH: no idea
[14:17:08] <KotH> siretart`: would be interesting to know
[14:17:15] <siretart`> indeed
[14:17:54] <J_Darnley> Were medion sued too?  For DVD players?
[14:18:27] <siretart`> J_Darnley: there is not much practical difference between aldi and medion in this case
[14:20:58] <J_Darnley> Right.  That explains why aldi has so much medion-branded stuff
[14:27:34] <janneg> twnqx: if there is web/ftp server running tar them without compression and I'll download them. otherwise I'll set a ftp server up
[14:27:35] <siretart`> it's their "house brand" after all
[14:28:33] <kshishkov> siretart`: knowing Lidl they must sell some Chinese players (i.e. no licenses whatsoever)
[14:33:35] <twnqx> janneg: link in pm
[14:42:42] <peloverde> BBB: I your description seems correct
[14:42:44] <__gb__> thresh, sure
[14:44:38] <BBB> peloverde: I peeked repeatedly at the paper to make sure I had it correct
[14:44:42] <BBB> ;)
[14:44:47] <kshishkov> good
[14:44:54] <BBB> but the technique makes sense now that I see theory + implementation next to each other
[14:45:11] <BBB> I'll submit later today I guess
[14:45:36] <peloverde> It's pretty intense, especially considering you have no formal background in signals :)
[14:45:54] <BBB> that's why I'm doing this :)
[14:45:57] <BBB> I want to learn
[14:46:15] <kshishkov> peloverde: you and Swedes may be the only guys who have such formal background
[14:46:26] <BBB> kshishkov: how did you learn?
[14:46:32] <BBB> by doing, by teaching or something else?
[14:47:13] <kshishkov> my teaching skills are nonexistent and nobody at the university bothered to tell us anything about it
[14:47:16] <peloverde> you may want to reference the paper somewhere in the comments
[14:47:58] <kshishkov> BBB: so probably it was doing and some papers I found and read (and maybe even understood one or two of them)
[14:51:33] <BBB> kshishkov: in ida, if I know a particular register that holds the main structure ("this") in a function, how can I tell it to use a particular "structure" for this?
[14:51:41] <BBB> I'd like to make better use of ida but it's a bit incomprehensible
[14:52:09] <kshishkov> right-click menu and select "structure pointer"
[14:53:08] <BBB> I don't have that, can I use edit->struct var?
[14:53:21] <BBB> looks like it does what I awnt
[14:53:48] <kshishkov> probably, what I said works only in decompiled code
[14:54:05] <kshishkov> I've never bothered with structures in plain asm
[15:00:29] <BBB> bleh, the whole thing is crapping out and has no undo
[15:00:30] <BBB> darnit
[15:16:29] <av500> siretart`: yes, had much fun in the heise comments thread today...
[15:20:13] <ramiro> BBB: ctrl+w every time you do something important. close (don't save or pack) and reopen when you screw up.
[15:20:38] <BBB> too late :)
[15:20:48] * BBB suddenly dislikes ida
[15:21:35] <jai> BBB: you need to spend some more time with it :)
[15:21:57] <BBB> I suppose
[15:22:23] <ramiro> it takes a couple of lost hours of work to get used to it =)
[15:23:35] <jai> hehe
[15:23:39] <BBB> it's like MS Word in college
[15:23:47] <BBB> \o/ ...
[15:23:57] <av500> U had to learn word in college?
[15:24:11] <jai> we had to learn wordstar in school iirc
[15:24:25] <av500> we had to learn words iirc
[15:25:02] <kshishkov> BBB: but you have "don't save database" flag during closing
[15:25:24] <BBB> I'll get the hang of this
[15:25:31] <BBB> I now know I hate the struct defs in ida
[15:25:34] <BBB> so not going to use that
[15:25:39] <kshishkov> jai: we had to learn both some Soviet word processor for DOS and Word
[15:25:42] <BBB> it made the code a struct instead of the register a pointer to struct
[15:25:51] <ramiro> BBB: I hate them too, but what are you going to use instead?
[15:25:54] <BBB> I couldn't undo that
[15:26:03] <astrange> i found some ida plugin that reads C files for struct definitions
[15:26:12] <BBB> ramiro: gdb? ;)
[15:26:17] <astrange> but it only sort of worked
[15:26:20] <kierank> ollydbg...
[15:28:19] <jai> the olly disasm engine isnt nearly that good
[15:28:27] <kshishkov> objdump :)
[15:31:52] <BBB> now I'm trying to create a struct with 10kB in it
[15:31:56] <BBB> and default all to an int
[15:31:58] <BBB> this is so painful
[15:32:24] <merbzt> why not an array ?
[15:32:55] <BBB> I want to give each individual names
[15:33:04] <BBB> like val_000 could be a counter, while val_004 could be a function pointer
[15:33:05] <BBB> etc.
[15:33:28] <merbzt> 10kb of struct members
[15:33:36] <merbzt> I don't think so
[15:33:46] <merbzt> must be some arrays in there
[15:33:48] <BBB> part of it is likely an array
[15:33:52] <BBB> but not all of it
[15:34:16] <BBB> I guess you're saying "start with a array", "add individual members as you figure them out"?
[15:34:46] <merbzt> something like that
[15:35:05] <merbzt> but you can read structs from h files
[15:35:23] <merbzt> and those you can generate
[15:36:56] <kshishkov> does anyone know an easy way to find decoder function in DShow/DMO?
[15:38:09] <BBB> do a call tree and find the one at the base of most calls?
[15:38:17] <merbzt> I would like to have a tool that would trap call instruction and then generate a code coverage report from it
[15:38:30] <astrange> valgrind --tool=callgrind wine ...
[15:38:45] <merbzt> neat
[15:38:58] <astrange> well, if it works
[15:39:01] <kshishkov> BBB: no, it's all COM - i.e. factories, function pointers embedded devil knows where and IIDs
[15:39:32] <merbzt> astrange: does it work with mplayer and dlls ?
[15:40:19] <kshishkov> it should
[15:40:53] <merbzt> that would be awesome
[15:40:58] <merbzt> gotta try it at home
[15:41:13] <kshishkov> gotta try it in a minute
[15:41:28] <mru> what are you guys REing?
[15:41:34] <merbzt> everything
[15:41:37] <av500> VP8
[15:41:51] <mru> I know everything is the ultimate goal
[15:42:08] <mru> and vp8 doesn't exist...
[15:42:17] * BBB is having a quick look at wvp2
[15:42:49] <mru> but vp7 exists
[15:42:49] <kshishkov> mru: but it's true - I try to RE everything and just pick what REs easier
[15:43:10] <mru> wouldn't it be cool if we had an opensource decoder before google _maybe_ releases it
[15:43:45] <BBB> what if google is also doing that?
[15:43:50] <BBB> would be a waste of time
[15:44:14] <astrange> apple icodec and prores shouldn'
[15:44:16] <kshishkov> can somebody ask Google for TrueMotion 2X?
[15:44:17] <mru> we'd have to RE whatever code they release anyway
[15:44:18] <astrange> t be too hard to RE
[15:44:31] <kshishkov> astrange: why haven't you done them yet?
[15:44:56] <kshishkov> I verified by myself - AIC is easy to RE
[15:45:18] <astrange> hmm i made a struct definition file for it then lost it
[15:46:13] <kshishkov> and I made http://wiki.multimedia.cx/index.php?title=Apple_Intermediate_Codec and then lost interest
[15:49:06] <kshishkov> callgrind works fine
[15:49:11] <kshishkov> with MPlayer and dlls
[15:49:44] <merbzt> can you show a report it generates ?
[15:50:12] <kshishkov> it's text file with functions and calls
[15:50:31] <merbzt> can you post a link to one ?
[15:50:32] <kshishkov> I see one small flaw though - for DLL funcs it does not print function addresses
[15:50:46] <merbzt> :/ ie no use
[15:51:29] <kshishkov> could be, I just haven't converted it into something more useful
[15:51:40] <av500> http://www.catonmat.net/blog/top-ten-one-liners-from-commandlinefu-explained/  ffmpeg is #10...
[15:52:36] <merbzt> KCachegrind should be able to visuausize it well
[15:54:16] <merbzt> the address space looks really strange
[15:54:23] <kshishkov> no KDE on my x86 box
[15:54:34] <kshishkov> (not on any other box too)
[15:54:36] <BBB> I may be looking wrongly here
[15:54:42] <BBB> but this dll handles WMVP
[15:54:47] <astrange> i'm not sure -sameq does what he wants
[15:54:50] <BBB> I don't see too many references to WVP2 in the .text segment
[15:54:51] <BBB> hmm...
[15:54:54] <BBB> what's WMVP?
[15:55:06] <kshishkov> first version of WVP2
[15:55:13] <BBB> and what's WMVA?
[15:55:37] <kshishkov> VC-1
[15:56:01] <kshishkov> bitstream format is the same at least
[15:57:44] <kshishkov> not to mention the only change needed for FFmpeg to support it was adding fourcc to libavformat/riff.c
[15:58:16] <BBB> hmm...
[15:58:22] * BBB ditches dll and goes look for correct one
[15:58:51] <kshishkov> what're you looking for?
[15:58:56] <BBB> the WVP2 DLL
[15:59:01] <BBB> I don't think I had the correct one
[15:59:08] <kshishkov> but it is
[15:59:24] <BBB> it isn't, the fourccs handled by it in the list were WMVA, WMV1/2/3 and WMVP
[16:00:04] <BBB> grep WVP2 gives a match, but a quick look for the text in it reveals nothing
[16:00:19] <kshishkov> in what text?
[16:00:32] <BBB> whole binary?
[16:00:40] <BBB> "search for text" in ida
[16:00:48] <kshishkov> it's numeric constant
[16:00:57] <kshishkov> try in hex view first
[16:01:15] <BBB> all others are strings
[16:01:19] <BBB> zero-terminated, etc.
[16:01:26] <BBB> and with actual names
[16:01:29] <BBB> aWmv1
[16:01:31] <BBB> aWmv2
[16:01:33] <BBB> etc.
[16:01:35] <kshishkov> ignore those
[16:02:00] <ramiro> mru: help me out here, does this reply make any sense?: http://sourceforge.net/mailarchive/message.php?msg_name=20100317215845.GA20646%40cooker.entropywave.com
[16:02:19] <BBB> oh!
[16:02:27] <BBB> i failed to parse one string
[16:02:33] <BBB> I can see it in the binary between the others
[16:02:35] <BBB> funny
[16:03:20] <kshishkov> BBB: guess who disasmed that DLL before you?
[16:03:46] <BBB> hence my asking ;)
[16:03:51] <BBB> why didn't you complete it?
[16:04:13] * kshishkov is verry lazy
[16:05:33] <roozhou> Question on AVI muxer ---- nBlockAlign in WAVEFORMATEX should be size of uncompressed pcm data in bytes of one frame for compressed audio codec
[16:05:48] <roozhou> ??
[16:05:59] <BBB> no, size of one block of compressed data
[16:06:12] <BBB> at least in asf, if you don't have it you can't decode most wma formats
[16:06:42] <roozhou> for AAC, what value?
[16:07:25] <kshishkov> BBB: please do the following - go to the instruction at address 8c46b32, move cursor to number and press 'r'
[16:07:59] <roozhou> ffmpeg writes 4, and it results in A/V async
[16:08:15] <BBB> you are scary
[16:08:37] <kshishkov> isn't A/V sync a good thing to have?
[16:08:55] <merbzt> sync v= async
[16:09:22] <jai> roozhou: should be set to max frame size possible
[16:09:28] <mru> ramiro: they're idiots, you might as well give up
[16:09:36] <roozhou> AVI_Mux_GUI writes 4096
[16:09:50] <mru> ramiro: how are orcc and liborc related?
[16:10:03] <jai> well, yeah, if you are muxing from raw aac
[16:10:06] <jai> 1024 samples
[16:10:15] <roozhou> i am muxing from mp4
[16:10:29] <roozhou> each aac frame has 1024 samples
[16:10:44] <kshishkov> BBB: any result?
[16:10:54] <BBB> kshishkov: I did it, as I said, you are scary
[16:11:11] <BBB> very scary
[16:11:23] <kshishkov> why? because it's written backwards?
[16:11:31] <jai> roozhou: yeah, are you saying that the it isnt calculated correctly in out muxer?
[16:11:34] <jai> *our
[16:11:38] <BBB> kshishkov: you are just plain scary :)
[16:11:53] <roozhou> jai: right
[16:12:11] <jai> roozhou: hmm, weird. never heard this before, let me check
[16:12:24] <kshishkov> BBB: ask mru or merbzt - they've seen me in real life. Twice.
[16:12:37] <mru> and lived to tell the tale
[16:12:46] <roozhou> once i modify nBlockAlign in hex editor to 4096, it plays ok
[16:13:42] <roozhou> ffmpeg produces broken aac in avi for years, because of this bug
[16:15:04] <jai> roozhou: is there a bugreport on our tracker for this?
[16:15:36] <BBB> mru: is he scary?
[16:15:41] <BBB> mru: he certainly sounds scary :)
[16:15:42] <roozhou> i don't know
[16:16:24] <kshishkov> BBB: in any case I probably the scariest Ukrainian you know
[16:16:39] <BBB> unlikely, I know another one and he's pretty scary also
[16:19:32] <jai> also, the 3guys with the infamous hammer
[16:19:50] <roozhou> jai: it seems aac parser does not set blockalign so ff_put_wav_header use the default value enc->channels*bps >> 3
[16:20:24] <jai> peloverde: ^
[16:20:47] <BBB> kshishkov: I'm imagining where I'm randomly rambling about this dll in this channel while at the same time you're probably having it in front of you right now, steering me from this to that point, like me being a strawman
[16:21:17] <av500> BBB: you see strings attached to your hands and head?
[16:21:25] <BBB> yes
[16:21:28] <BBB> and they're moving
[16:21:28] <kshishkov> BBB: no, told you - IDA database with it is on SATA HDD which I can't connect.
[16:21:44] <BBB> kshishkov: the fact that you remember the address is scarier
[16:22:27] <kshishkov> BBB: objdump -d and quick grepping
[16:27:38] <jai> roozhou: i dunno why the mp4 demuxer didnt set block_align properly
[16:29:47] <jai> roozhou: can you test a patch for me?
[16:30:03] <roozhou> jai: of course
[16:35:59] <roozhou> jai: where is the patch?
[16:37:34] <jai> roozhou: just a sec, i need to pastebin it
[16:40:12] <roozhou> i did a modification in riff.c and it is working for me
[16:41:00] <jai> roozhou: riff.c?
[16:41:04] <jai> why
[16:42:12] <roozhou> blkalign = 1;
[16:42:13] <roozhou> } else if (enc->block_align != 0) { /* specified by the codec */
[16:42:13] <roozhou> blkalign = enc->block_align;
[16:42:13] <roozhou> +    } else if (enc->codec_id == CODEC_ID_AAC) {
[16:42:13] <roozhou> +        blkalign = enc->frame_size*enc->channels*bps >> 3;
[16:42:13] <roozhou> } else
[16:42:13] <roozhou> blkalign = enc->channels*bps >> 3;
[16:42:14] <roozhou> if (enc->codec_id == CODEC_ID_PCM_U8 ||
[16:53:09] <mru> ramiro: I had a quick look, and I can't see a way to configure orcc as a cross-compiler
[18:00:55] <peloverde> I can't believe I find myself agreeing with Joel: "If you are using Subversion, stop it. Just stop. Subversion = Leeches. Mercurial and Git = Antibiotics. /We have better technology now./"
[18:01:15] <mru> yeah, read that
[18:02:08] <elenril> did that flame about git on -cvslog a few days ago go anywhere?
[18:03:17] <mru> of course not
[18:03:45] <mru> michael insists on "svn cp", diego insists on making up history, we're not going anywhere
[18:04:29] <peloverde> I think we will wind up on git soon or later, and I think there will be a less painful transition if we side with sooner
[18:04:41] * kshishkov wonders why his SheevaPlug hangs but still responds to pings - faster than other hw on LAN
[18:04:41] <peloverde> Git notes allows you to add footnotes to the history
[18:05:25] <mru> rewriting history is a bad idea, get over it
[18:05:55] <peloverde> I think git-notes is a good compromise
[18:06:16] <mru> I've never felt a need for it
[18:06:48] * thresh did
[18:06:58] <thresh> but still, you can re-read before you push
[18:07:00] <astrange> it's somewhat annoying that git log libavcodec/h264_cabac.c doesn't see through the copy
[18:07:08] <astrange> seems like you can't adjust rename detection for that
[18:07:45] <peloverde> Diego likes to make the wrong contributor argument, suppose person 1 sends a patchset and you misattribute it to person 2
[18:08:06] <thresh> no such problem for git
[18:08:12] <thresh> you just git am
[18:08:14] <peloverde> however requiring git formatted patches could solve that problem much more easily
[18:08:40] <mru> astrange: try git gui blame
[18:09:07] <peloverde> thresh, what about changes from a hostile downstream?
[18:09:14] <mru> and misattributions are such a HUGE problem???
[18:09:26] <mru> we have my shotgut for that
[18:09:44] <DonDiego> i arrive at an interesting moment?
[18:09:47] <peloverde> speak of the devil :)
[18:09:51] <_av500_> i have one patch to defend with my life!
[18:09:59] * DonDiego hears talk of mans' shotgun..
[18:10:35] * DonDiego is on the lookout should the devil sneak around
[18:11:13] <DonDiego> anyway, i have noticed some issues with libswscale on powerpc
[18:11:29] <mru> go on
[18:11:30] <DonDiego> lu_zero, ramiro, siretart`, you around?
[18:11:48] <DonDiego> compilation fails with the following combination of configure flags:
[18:12:12] <DonDiego> --enable-gpl --enable-swscale --enable-runtime-cpudetect --disable-altivec
[18:12:27] <DonDiego> (--enable-gpl is probably not necessary to trigger the failure)
[18:12:51] <kshishkov> try compiling it with --disable-swscale
[18:12:52] <mru> --enable-swscale is no more
[18:13:04] <mru> are you talking about the release branch?
[18:13:19] <peloverde> I wish it were un-no-more, svn:externals are annoying
[18:13:45] <DonDiego> no, i'm talking about trunk
[18:13:45] <mru> svn externals are a work of the devil
[18:13:51] <kshishkov> peloverde: when it's fully LGPL we can put it into main repo and screw that history
[18:14:07] <peloverde> kshishkov, we've had GPL code in trunk before
[18:14:18] <mru> we have gpl code in trunk now
[18:14:21] <peloverde> I don't understand why pure LGPL is a prereq for merging
[18:14:23] <DonDiego> utils.c, lines 1024 and 1528
[18:14:24] <mru> and ffmpeg doesn't work w/o it
[18:14:46] <DonDiego> back to topic please..
[18:14:49] <kshishkov> peloverde: someone likes history
[18:14:50] <astrange> you can merge it into svn with history, just turn off cvslog for the 100000 commits
[18:14:53] <mru> failure confirmed
[18:15:01] <DonDiego> the preprocessor condition reads
[18:15:03] <DonDiego> -#if ARCH_PPC && (HAVE_ALTIVEC || CONFIG_RUNTIME_CPUDETECT)
[18:15:24] <DonDiego> that won't work if you disable altivec
[18:15:32] <kshishkov> astrange: and bad CIA bot too
[18:15:35] <kshishkov> *ban
[18:16:02] <DonDiego> i think the 0.5 branch is fine
[18:16:15] <mru> astrange: have you ever tried following its history all the way back?
[18:16:45] <astrange> not aside from having a git checkout of it
[18:17:05] <mru> it's been moved around and renamed several times
[18:17:26] * kshishkov is proud to shorten yuv2rgb.c history a bit
[18:17:58] <mru> history is append-only
[18:18:05] <peloverde> pointing to the old history in the commit message should be viable
[18:18:39] <mru> just dumping it in and ditching the history will totally break bisecting before that point
[18:18:54] <mru> it's broken now too, but let's not make it permanent
[18:19:02] <mru> if it is at all fixable
[18:19:08] <peloverde> bisecting is already broken
[18:19:18] <mru> so fix it, don't break it more
[18:19:20] <peloverde> then let's start a new repo and interleave them
[18:19:29] <mru> how do you do that?
[18:19:44] <peloverde> play back both histories simultaneously
[18:19:48] <mru> how?
[18:20:25] <peloverde> how would you commit it all on top of what we have in ffmpeg/trunk?
[18:20:35] <peloverde> just do that with two instead of one
[18:20:48] <mru> that would break bisecting
[18:20:52] <mru> even more than it is now
[18:21:03] <peloverde> how would that break bisecting?
[18:21:22] <mru> a checkout of an old rev/date would give no libswscale at all
[18:21:46] <mru> now you can at least do an svn checkout by date
[18:21:51] <peloverde> you misunderstand me
[18:22:05] <peloverde> A) do a full history checkout of both
[18:22:11] <peloverde> B) set up a new repository
[18:22:13] <mru> what does that mean?
[18:22:24] <peloverde> mru, git svn clone
[18:22:56] <peloverde> set up two pointers one to r1 of both swscale and ffmpeg
[18:23:08] <mru> pointers?
[18:23:22] <peloverde> variables holding revision numbers
[18:23:25] <peloverde> D) compare dates, apply the older and advance the pointer
[18:24:22] <janneg> the svn commit dates are sane?
[18:24:35] <mru> should be
[18:25:46] <peloverde> or we could wait until the magical svn fairies bless us with a merge-o-matic... some time after we are all dead
[18:27:50] <ramiro> mru: apparently orcc doesn't have to be built as cross-compiler. any build supports all targets. but schroedinger uses the same PKG_CONFIG to get orcc and liborc. it must link to liborc (for mingw32), and run orcc on build machine.
[18:28:24] <ramiro> but then he says "This is pretty normal practice for packages that create build tools." (that you should build the package twice and somehow set ORCC even thought it's undocumented)
[18:28:30] <mru> ramiro: that's not what I saw
[18:28:37] <DonDiego> any suggestions what the correct condition for libswscale is?
[18:28:39] <_av500_> mru: like ogg strict interleaving :)
[18:28:43] <mru> it is not possible to build it on x86 to target arm
[18:28:45] <mru> eg
[18:29:37] <ramiro> http://bugs.freedesktop.org/show_bug.cgi?id=27103#c1 he says "There's no target dependency in orcc"
[18:29:48] <mru> is a lie
[18:29:54] <mru> I looked at the code today
[18:30:08] <mru> if you build on x86, all non-x86 targets are disabled
[18:30:15] <mru> etc.
[18:31:27] <DonDiego> also
[18:32:11] <DonDiego> in swscale.c the COMPILE_TEMPLATE_foo tokens are defined to 1, but the COMPILE_foo tokens are just defined
[18:33:01] <DonDiego> but we have the following in there:
[18:33:09] <DonDiego> #if ARCH_PPC && COMPILE_ALTIVEC
[18:33:14] <DonDiego> that's broken..
[18:33:30] <BBB> oh, we're in gsoc
[18:33:31] <BBB> yay
[18:33:59] <DonDiego> ramiro: you created libswscale/utils.c i think..
[18:34:48] <BBB> I wonder why they sent that to me
[18:34:55] <BBB> maybe mike made my email address co-admin?
[18:35:33] <kshishkov> BBB: not all of us but still yay
[18:36:03] <ramiro> DonDiego: just svn cp'd it. what's the issue?
[18:36:14] <peloverde> A binary w32 loader is back on the table?
[18:36:17] <DonDiego> ramiro: scroll up :)
[18:36:36] <DonDiego> peloverde: the faq says another thing, but michael seems to like the idea
[18:36:37] <peloverde> BBB, hurrah!
[18:36:47] <BBB> we should not put it in svn
[18:36:50] <mru> ugh for win32 loader
[18:36:53] <DonDiego> i think he wants ffplay to put mplayer out of business
[18:36:56] <BBB> but it'd be useful for us while RE'ing codecs
[18:37:01] <mru> ffplay is a toy
[18:37:05] <DonDiego> a waste of effort better spent elsewhere imo
[18:37:07] <BBB> does anyone use ffplay?
[18:37:10] <peloverde> DonDiego, I'd rather have vo_gl
[18:37:20] <DonDiego> i use ffplay to test samples, nothing more
[18:37:43] <DonDiego> BBB: you can use mplayer while REing codecs...
[18:37:57] <BBB> ffmpeg is smaller codebase
[18:37:59] <BBB> makes it simpler
[18:38:04] * BBB very stubborn
[18:38:20] <DonDiego> bbl
[18:38:38] <DonDiego> mplayer is not a particularly big codebase
[18:38:49] <DonDiego> probably smaller if you take away the embedded libs
[18:38:52] <kshishkov> but particularly hacky
[18:39:20] <BBB> ohwell
[18:39:22] * BBB goes work
[18:39:24] <elenril> only some parts
[18:39:40] <jai> most parts
[18:40:30] <mru> the core parts
[18:41:37] <DonDiego> getting better :)
[18:42:48] * jai waits for uoti to comment ;)
[18:42:53] <jai> oh wait, he isnt here
[18:43:23] <mru> he got banned for bad behaviour
[18:43:40] <jai> oh
[18:44:23] <Compn> ehe win32 loader in ffmpeg
[18:44:32] <mru> where's this being discussed?
[18:44:41] <astrange> mplayer list
[18:44:49] <kshishkov> mru: I gave you link once
[18:45:33] <peloverde> mru: [MPlayer-dev-eng] [PATCH] Fix return values of WaitForSingleObject when checking an event
[18:45:43] <BBB> astrange: if you want a w32 loader in ffmpeg, shouldn't it be discussed on ffmpeg-devel?
[18:47:00] * _av500_ uses ffplay to RE lavc/lavf
[18:47:43] <mru> BBB: maybe they fear too much resistance there
[18:48:02] <astrange> it's not being discussed yet, michael just suggested it
[18:48:31] <mru> shouldn't ffmpeg changes be _suggested_ on ffmpeg-devel?
[18:48:41] <BBB> probably
[18:48:50] <BBB> anyway, I for one am dead-on against such a loader in ffmpeg
[18:49:01] * mru too
[18:49:05] <ramiro> DonDiego: open a bug on the bug tracker and I'll take a look later
[18:49:53] <Compn> BBB : you could change ffmpeg from a set of decoder and encoders into a unified wrapper for all codecs, ever made!
[18:49:54] <Compn> ;p
[18:50:05] <mru> sounds like mplayer
[18:52:16] <BBB> if I wanted to develop mplayer, I'd subscribe to a mplayter ML
[18:52:23] <BBB> surprise, surprise, I'm not on the list :)
[18:53:06] <jai> same here, though i read archives
[18:53:19] <peloverde> I wound up subscribing to m-d-e just because ffaac periodically comes up
[18:58:58] <jai> kshishkov: btw, apparently i _can_ participate in gsoc this year :)
[18:59:29] <kshishkov> good for you
[19:03:10] <BBB> Compn: somehow that sounds like gstreamer ;)
[19:03:12] <BBB> </late>
[19:03:19] <BBB> jai: go do ralf :)
[19:03:38] <BBB> kshishkov: I wish you could participate, would be good... you could do vc-interlaced
[19:03:41] <thresh> ffmpeg is in GSOC 2010, congrats
[19:03:50] <BBB> my wife tried to convince me to participate as student
[19:04:04] * kshishkov always though they called it Ralf so because codec devs had the brains of Ralf Wiggum
[19:04:06] <BBB> which, if I jump through some hoops, might in fact be possible
[19:04:19] <ramiro> mru: it seemed to work fine to call "orcc --target arm" to cross-compile.
[19:04:38] <mru> well, *something* is disabled
[19:04:43] <kshishkov> BBB: do it, it has nothing to do with university anyway ;)
[19:05:01] <mru> http://code.entropywave.com/git?p=orc.git;a=blob;f=orc/Makefile.am;h=3799dd0c0c757ddf120941543f006f06b190deb1;hb=HEAD#l41
[19:05:03] <BBB> it involves doing stuff
[19:05:23] <ramiro> mru: I think it's the code that gets information from cpuid and such.
[19:06:29] <kshishkov> BBB: it's nothing hard
[19:07:23] <kshishkov> BBB: learn from my example - I did RV4 decoder (REing and implementing) during exams and finishing thesis for bachelor degree
[19:08:14] <BBB> I still don't know which function is the main decoding function :)
[19:08:32] <kshishkov> where?
[19:08:40] <BBB> wvp2
[19:08:45] <kshishkov> neither do I
[19:08:48] <BBB> I'm sort of browsing through it, little by little
[19:08:57] <BBB> I hate that com-style stuff
[19:09:08] <kshishkov> I just found functions used for decoding
[19:09:15] <kshishkov> that's enough even without main
[19:09:16] <BBB> I'm now going through it using the mplayer/gstreamer win32 loader code, so at least I know the offset of vfuncs in structs
[19:09:40] <kshishkov> eww
[19:09:59] <BBB> don't ask ;)
[19:10:04] <BBB> I told you I have no idea what I'm doing
[19:10:06] <BBB> just trying random things
[19:10:40] <ramiro> bbl
[19:10:54] <kshishkov> you know, those offsets are stored in data segment (I think), you just need to find correct array of function pointers ;)
[19:10:56] <bcoudurier> hi guys
[19:11:24] <BBB> I noticed
[19:11:29] <BBB> I already figured out a whole bunch of 'em
[19:11:32] <BBB> just not the main one yet
[19:11:57] <jai> BBB: which codec is this?
[19:12:08] <Compn> wvp2
[19:12:18] <Compn> aka wmv3 slideshow + text
[19:12:20] <kshishkov> BBB: you can try my way
[19:14:23] * kierank would also like to hear about the "kshishkov way"
[19:14:53] <kshishkov> it won't work for you since you don't know much about your codec
[19:15:02] <kshishkov> but for WVP2 it's easy
[19:15:19] <kshishkov> easier at least
[19:16:15] <kshishkov> I know how to find extradata parsing function, from it one can trace up more decoding functions
[19:16:36] <kshishkov> not mentioning that other functions using get_bits() will belong to decoding ones
[19:18:11] <kierank> I started from startcode parsing and worked my way up until I found the gui calling the api
[19:19:17] <kierank> though i still haven't figured out why startcodes are parsed in some functions when they don't need to be
[19:21:38] <kshishkov> yes, unless it's simple interface like VfW it may be better to pick some function in the middle or end of calling chain and unravel it
[19:23:17] <BBB> kshishkov: so how do you do that?
[19:23:28] <BBB> load in debugger and put a watchpoint on extradat?
[19:23:31] <kshishkov> no
[19:23:42] <kshishkov> I just happen to know how it works
[19:23:43] <BBB> don't forget I'm still learning
[19:23:51] <BBB> wmavoice was easy b/c it had symbols
[19:23:57] <BBB> this is the second time I touch something w/o symbols
[19:24:08] <BBB> the first one was when I RE'ed SVQ3/QDM2 RTP payload formats
[19:24:21] <kshishkov> so if some code calls function with argument 3 then with argument 5 then it must be get_bits() in wmv2 or wmv3 extradata parsing
[19:25:55] <BBB> ?
[19:27:12] <kshishkov> just a sec...
[19:32:22] <kshishkov> 8c5de0a seems to be a good candidate for either wmv2 or wmv3/wvp2 extradata parsing
[19:33:03] <kshishkov> also remember that condition I've told you to convert earlier? It also should belong to codec initialization
[19:35:01] <mru> ok, here's one for the svn historians
[19:35:20] <mru> look at r151 in ffmpeg and r2159 in libswscale
[19:38:28] <DonDiego> mru: what about it?
[19:38:39] <mru> same files in different places
[19:39:19] <mru> the following commits are also duplicated in both places
[19:39:21] <BBB> kshishkov: so how do you know?
[19:40:35] <DonDiego> that's because postproc started out in mplayer
[19:40:48] <DonDiego> i think arpi just moved the cvs directory
[19:40:51] <DonDiego> physically
[19:41:01] <mru> ah, good old cvs
[19:41:23] <DonDiego> the world is so much better now..
[19:41:31] <mru> now we only have svn to kill
[19:41:46] <j-b> and bzr
[19:42:02] <mru> you can't kill something if it ain't alive
[19:42:20] <kshishkov> BBB: told you, objdump -d and grepping
[19:42:43] <DonDiego> i use bzr at work now
[19:42:49] <DonDiego> (along with svn)
[19:43:01] <kshishkov> mru: what about zombies?
[19:43:10] <mru> DonDiego: masochistic tendencies?
[19:43:12] <DonDiego> it's such an immense step up from tla, which was used previously..
[19:43:23] <mru> or machosistic?
[19:43:32] <mru> -h
[19:44:00] <kshishkov> mru: Germans even wrote _network_ version of M$ Source Safe which is damn inconvenient to use even by single developer
[19:44:30] <mru> broadcom uses sourcesafe
[19:44:35] <mru> it shows in the result
[19:44:48] <DonDiego> bzr is ok, it gets the job done
[19:45:00] * BBB hugs kshishkov
[19:45:05] <BBB> kshishkov: unfortunately, that's the wmv3 code
[19:45:12] <mru> it's just a bit clunky and doesn't scale very well
[19:45:14] <kshishkov> mru: looks like my SheevaPlug is pining to the fjords. Any advise?
[19:45:18] <DonDiego> the two drawbacks i noticed are not being able to edit log messages and lack of copy support (with history)
[19:45:22] <mru> kshishkov: reboot?
[19:45:28] <BBB> I already saw the caller function earlier, it handles seprarate call paths for wmv1, wmv and wmv3/a/r
[19:45:32] <BBB> but it doesn't handle wvp2
[19:45:36] <BBB> which appears to be done elsewhere
[19:45:42] <kshishkov> mru: done cold reboot, does not help
[19:45:42] <mru> DonDiego: you do have strange requirements
[19:45:49] <mru> kshishkov: what does it do?
[19:45:52] <elenril> hey, metadata writing for flac still isn't applied?
[19:45:55] <mru> anything on serial console?
[19:45:56] <DonDiego> have you ever used tla_
[19:45:59] <DonDiego> ?
[19:45:59] <elenril> J_Darnley: you should complain more ;)
[19:46:02] <mru> goodness no
[19:46:02] <kshishkov> BBB: wvp2 is handled as wmv3, believe me
[19:46:11] <BBB> ok
[19:46:19] <BBB> but the switch/case in the caller doesn't handle wvp2
[19:46:32] <kshishkov> mru: no, forums suggest it may be power supply melted
[19:46:33] <mru> http://changelog.complete.org/archives/698-if-version-control-systems-were-airlines
[19:46:34] <BBB> so it might be that the *extra* code that handles wvp2, specifically, is elsewhere
[19:46:42] <mru> kshishkov: the PSU in mine died a while back
[19:46:45] <mru> busted cap
[19:46:47] <mru> easy fix
[19:46:57] <kshishkov> now only to find tools
[19:47:44] <kshishkov> mru: I remember similar text about OSes
[19:48:03] <mru> about tla: you arrive as your destination terminal, you see it too is full of philosophers, most of them dining.
[19:48:25] <kshishkov> BBB: one of those conditions comparing FOURCCs used "if codec is WVP2 set some flag and go by WMV3 path"
[19:48:40] <BBB> that's true
[19:48:48] <BBB> it did it really weirdly also
[19:49:00] <kshishkov> is that an allusion to fmaous resource allocation/deadlock problem?
[19:49:16] <BBB> (fourcc==WVP2)-1&0xE000000+ fourcc(WMV3)
[19:49:17] <mru> I would presume so
[19:49:17] <BBB> or so
[19:49:22] <kshishkov> yes
[19:49:35] <kshishkov> it just does ?'WMV3':'WMVA'
[19:49:37] <mru> and of bzr: Main competitor: BeOS Airlines
[19:50:51] <kshishkov> better than Hurd Airlines
[19:51:15] <mru> what's that?  a gnu with painted-on wings?
[19:51:38] <kshishkov> yes
[19:52:03] <kshishkov> flies as well as accountants from the top floor
[19:53:23] <BBB> kshishkov: hm, is that the same function I'm talking about?
[19:53:25] * BBB checks again
[19:53:38] <BBB> maybe it's because it does a direct fourcc calc that I misinterpreted the 0xE0000000000000
[19:53:45] <kshishkov> yes, the same code you copypasted
[19:53:48] <BBB> ok
[19:53:53] <BBB> I misinterpreted that then
[19:54:06] <BBB> so then wvp2 ====== wmv3 in all practical senses
[19:54:09] <BBB> except for that one flag
[19:54:25] <kshishkov> yes, and some flags set to zero in wmv3
[19:54:31] <BBB> 8c4cec6
[19:54:37] <BBB> hm, no
[19:54:40] <kshishkov> i.e. end of sequence header parsing differs for them
[19:55:22] <BBB> shit I can't find it anymore
[19:57:14] <BBB> 8c47f60
[19:59:10] <BBB> so WVP2 -> WMVa, and WMVP -> WMV3?
[20:00:27] <kshishkov> probably both are WMV3
[20:00:55] <kshishkov> if extradata and frame start with NAL code (00 00 01) then it's WMVA
[20:01:16] <BBB> the code triggers for WMVP/WVP2
[20:01:22] <BBB> test fourcc, WVP2
[20:01:26] <BBB> setnz ecx
[20:01:29] <BBB> dec ecx
[20:01:32] <BBB> and ecx, 0xE
[20:01:35] <BBB> add ecx, WMV3
[20:01:54] <BBB> so WVP2->0->-1->E->WMVA
[20:01:58] <BBB> WMVP->WMV3
[20:02:17] <BBB> interesting code btw
[20:02:22] <BBB> is gcc that good?>
[20:02:58] <kshishkov> unlikely
[20:04:16] <kshishkov> for all practical reasons you can treat them as WMV3 for now
[20:04:26] <kshishkov> I've looked into actual WMVP and WVP2 file
[20:04:57] <BBB> ok
[20:08:36] <Compn> wouldnt the easier way be to just encode the same video in wvp2 and wmv3 and compare them? :P
[20:08:49] <kshishkov> go on
[20:38:25] <mru> http://daringfireball.net/2010/03/mozilla_video_mobile
[20:42:17] <BBB> nice post
[20:59:44] <DonDiego> hey, why hasn't anybody informed me about the html 5 situation?
[20:59:46] <DonDiego> :)
[21:00:07] <mru> DonDiego: you can read news/blogs just like the rest of us, no?
[21:00:29] <DonDiego> no, i'm supposed to do other things and sometimes i actually do ;)
[21:06:24] <BBB> hml5 is simple: as predicted, theora lost
[21:06:32] <BBB> I don't see any news there
[21:06:59] * mru hopes this will be another nail in mozilla's coffin
[21:07:06] <BBB> mozilla is cool
[21:07:15] <BBB> those involved in video should be fired
[21:07:16] <mru> errr, no
[21:07:22] <mru> firefox sucks
[21:07:43] <mru> I only use it because the alternatives so far have sucked more
[21:07:48] <mru> and because of inertia
[21:07:54] <BBB> I think you're too much a hardliner, sorry, but within the mozilla foundation, I know for a fact there are many different opinion on how video should be handled
[21:07:54] <bcoudurier> what's the news ?
[21:08:01] <mru> there is no news
[21:08:18] <mru> of course there are differing opinions inside mozilla
[21:08:21] <bcoudurier> what is diego talking about ?
[21:08:24] <mru> it's large enough an organisation for that
[21:08:26] <BBB> it's unfortunate that those with bad, poor and uninformed opinions, the freetards as you'd call them, are most vocal
[21:08:35] <BBB> chris blizzard, for example
[21:08:36] <mru> bcoudurier: ms announced that ie9 will support h264
[21:08:40] <BBB> he's an absolute idiot
[21:08:45] <bcoudurier> haha
[21:08:47] <BBB> many others are quite smart
[21:09:00] <bcoudurier> I don't use firefox anymore
[21:09:08] <mru> what do you use?
[21:09:09] <bcoudurier> chrome works a lot better IMHO
[21:09:22] <mru> does it have an addon like stylish for firefox?
[21:09:25] <bcoudurier> and on osx I use safari because I'm lazy
[21:09:32] <bcoudurier> stylish ?
[21:09:43] <mru> custom per-site/page css overrides
[21:09:46] <mru> I use it all the time
[21:09:52] <bcoudurier> oh I don't use that
[21:09:58] <bcoudurier> I don't use any plugin
[21:10:15] <mru> it lets me adjust the look of sites I visit often
[21:10:22] <mru> make them more readable
[21:10:36] <bcoudurier> my eyes works nicely
[21:10:42] <mru> mine too
[21:10:46] <mru> but some fonts are just too ugly
[21:10:49] <mru> and some colours
[21:10:52] <mru> and some layouts
[21:11:46] <mru> like who the hell sets a long text in a sans-serif font?
[21:12:29] <DonDiego> bcoudurier: you browse without adblock?
[21:12:34] <bcoudurier> I guess it's only a matter of bad taste
[21:12:34] <DonDiego> wow, go figure..
[21:12:43] <bcoudurier> yes I see adds
[21:12:47] <bcoudurier> ads
[21:12:49] <DonDiego> geez
[21:12:56] * DonDiego shrieks
[21:12:58] * mru thanks bcoudurier for sponsoring the web for the rest of us
[21:13:06] <bcoudurier> no pb
[21:13:15] <DonDiego> doesn't you brain get fried after a while
[21:13:27] <bcoudurier> well, I like the news websites
[21:13:33] <DonDiego> sometimes i approach slot machines
[21:13:34] <bcoudurier> I don't buy the papers
[21:13:48] <bcoudurier> that's the only way I can give them money ;)
[21:14:00] <DonDiego> only to notice that they are some other person's computer showing the web in all it's ad-enabled furor...
[21:14:26] <bcoudurier> I wonder where you guys are surfing
[21:14:31] <bcoudurier> you do too much pron
[21:14:42] <DonDiego> generic news sites
[21:14:58] <DonDiego> leo.org, anything really...
[21:16:22] <DonDiego> i do wonder if mozilla has a fallback plan..
[21:16:41] <mru> stick fingers in ears and mumble "patents, patents, patents"
[21:16:54] <DonDiego> mru: i need to send a mail to alp toker about his firefox with webkit backend...
[21:17:14] <iive> DonDiego: i think mozilla fallback plan is to use gstreamer.
[21:17:58] <iive> bcoudurier: i'm yet to see news site that deserves my 2 cents.
[21:18:18] <BBB> I think they use gstreamer in their mobile firefox version, no?
[21:18:30] <DonDiego> in any case, i'm looking soooo forward to the demise of flash...
[21:18:31] <ramiro> how many distro packagers do we have around here? siretart`, lu_zero, Rathann, ...?
[21:18:38] <BBB> integrating that code into main mozilla has been on hold for ... 2 years or so?
[21:19:12] <astrange> i could take over the fink packaging for ffmpeg and co, but i haven't done it just yet
[21:19:19] <ramiro> regarding http://sourceforge.net/mailarchive/message.php?msg_name=20100317215845.GA20646%40cooker.entropywave.com and his followup http://ffmpeg.pastebin.com/Cbe6hHXt . It would be nice if distro packagers could each file a bug report about this.
[21:19:45] <BBB> dondiego: do you need more help with the invoicing?
[21:20:21] <DonDiego> i'm at my parent's house right now
[21:20:26] <BBB> oh, n/m then
[21:20:27] <DonDiego> my dad hasn
[21:20:32] <DonDiego> 't been well
[21:20:38] <Rathann> ramiro: what's the issue?
[21:20:49] <DonDiego> i'm going home and will look at it again then
[21:21:05] <BBB> ok
[21:21:13] <DonDiego> either i find a template that produces better results in >1h or i send it off as-is
[21:21:17] <ramiro> Rathann: http://bugs.freedesktop.org/show_bug.cgi?id=27103
[21:21:21] <DonDiego> they will likely have comments anyway
[21:21:47] <DonDiego> ok, i'm out now
[21:21:48] <DonDiego> bbl
[21:22:33] <ramiro> Rathann: and libschroedinger depends on liborc. it is not possible to cross compile libschroedinger with a simple configure. you *must* (after some time asking why) hardcode a variable inside configure so that it does not use pkg-config to fetch a wrong variable.
[21:23:10] <ramiro> more specifically you must set ORCC to the native orcc
[21:23:23] <peloverde> Solution: Ignore their silly fringe format if they are unwilling to be reasonable about it
[21:23:37] <ramiro> he insists that's the correct way to do things, and that there are no bugs or misdesigns.
[21:23:56] <mru> ignore and move along
[21:24:07] <mru> who needs that stuff anyway?
[21:24:27] <ramiro> peloverde: I thought about that, really... but then someone came up with a patch fixing another windows issue with libschroedinger and people are asking for it.
[21:24:46] <Rathann> or whip up a patch that doesn't change their defaults but allows you to do what you want
[21:24:52] <Rathann> and post it
[21:24:52] <ramiro> (people who use the builds at ffmpeg.arrozcru.org )
[21:24:58] <Rathann> see if they accept
[21:25:20] <ramiro> Rathann: I could, but that should be their work after I reported the bug =)
[21:25:39] <Rathann> in an ideal world
[21:25:46] <thresh> you can compile liboil in x-compile
[21:25:54] <thresh> at least VLC has patches in its tree to do that
[21:25:57] <ramiro> thresh: the new fad is liborc, not liboil =)
[21:26:01] <thresh> okay
[21:26:17] <ramiro> btw they're all written by the same guy.
[21:26:38] <ramiro> who also insists that we shouldn't want to compile his code statically.
[21:27:08] <thresh> weird
[21:27:33] <thresh> last time i checked Schleef was sane
[21:28:04] <mru> doesn't look like it to me
[21:28:33] <thresh> things couldve changed since Sep
[21:29:04] <thresh> some people get crazier in autumn and spring
[21:30:06] <bcoudurier> flowers ?
[21:30:35] <peloverde> Long term exposure to ogg is known to cause brain damage
[21:31:19] <BBB> I thought dave was pretty normal
[21:31:39] <BBB> although he openly admits ffmpeg's hand-optimized code is better than the oil/orc/... autogenerated code
[21:32:51] <thresh> 'although' ?
[21:33:59] <ohsix> point is behind the chinese wall things can get better
[21:34:36] <BBB> http://www.schleef.org/blog/2009/09/19/cog-in-gst-plugins-bad/
[21:35:12] <BBB> hm, in fact that's ffmpeg's C against his automatically crafted asm
[21:35:23] <BBB> oddly, ffmpeg's C is faster for the most interesting codepaths than his asm
[21:35:26] * BBB wonders
[21:37:08] <thresh> wait, this blog post says cog is faster than ffmpeg
[21:37:28] <astrange> ffmpegcolorspace doesn't use ffmpeg anymore
[21:37:36] <astrange> since imgconvert was removed
[21:37:40] <BBB> "a few cases (which, not coincidentally, are the most heavily used cases) ffmpegcolorspace is slightly faster than cogcolorspace."
[21:37:42] <mru> it may well be for combinations we don't have direct paths for
[21:37:46] <thresh> ah, most heavily used use cases are faster in ffmpeg
[21:37:47] <thresh> right
[21:37:56] <BBB> mru: that's indeed the case
[21:38:03] <BBB> the typical ones is where ffmpeg's C is faster
[21:38:12] <mru> we end up going over an intermediate format
[21:38:21] <BBB> I think I copied ffmpeg's imgconvert.c /- 6 years ago
[21:38:27] <BBB> ffmpegcolorspace still uses that version
[21:38:29] <BBB> it's C-only
[21:38:33] <BBB> it was never updated
[21:38:53] * BBB feels bad for all the code-forking he did back then
[21:38:59] <BBB> ahwell, anyway
[21:39:30] * mru orders BBB to locate and destroy every fork he made during his time of sin
[21:39:35] <BBB> I think for a while there were two ffmpegcolorspace elements
[21:39:39] <BBB> one inside gst-ffmpeg
[21:39:42] <BBB> which was not to be used
[21:39:47] <BBB> and one inside gst-plugins-something
[21:39:50] <KotH> janneg: i just rebooted fogir
[21:39:52] <BBB> which we were supposed to use
[21:39:59] <BBB> because we couldn't depend on ffmpeg
[21:40:04] <KotH> janneg: because the oom killer fucked up the machine somewhen this afternoon
[21:40:08] <BBB> of course, the one in gst-ffmpeg was using asm and the other one was not
[21:42:05] <peloverde> Does modern gst-ffmpeg use sws?
[21:43:03] <twnqx> janneg: i suppose the server is gone more permanently...
[21:43:16] <twnqx> can i give you the image by another means? :S
[21:43:54] <BBB> peloverde: I suppose they use "cogcolorspace" now?
[21:44:05] <BBB> not sure
[21:44:07] * BBB not involved
[21:44:58] <astrange> that reminds me, sws should maybe print a warning if it was built without asm
[21:45:32] <janneg> KotH: oh, I noticed that my ssh connection was stuck but was to busy to reconnect
[21:45:44] <janneg> twnqx: I giot the tarballs
[21:45:48] <twnqx> oh ok
[21:45:50] <twnqx> lucky you.
[21:46:02] <twnqx> while adding the two missing disks to the raid 6
[21:46:21] <twnqx> i had 92 read errors on one of the active drives
[21:46:27] <janneg> it was only a matter of a couple of minutes
[21:46:32] <peloverde> gstffmpegscale.c: #include <libswscale/swscale.h> :)
[21:46:38] <twnqx> which now means 3 missing with only two survivable.
[21:46:57] <twnqx> and a server that doesn't give me an ssh shell.
[21:47:03] <KotH> janneg: yeah
[21:47:28] <janneg> KotH: last frame finished at 13:47
[21:47:35] <KotH> janneg: i just went trough my emails and saw oom messages from fogir in my inbox and wanted to check... and wasnt able to log in anymore..not even from console
[21:47:51] <twnqx> janneg: however, the rendering box is still alive, so i'll finish the block
[21:48:42] <janneg> KotH: I'll start a different job
[21:50:06] <KotH> twnqx: bad luck with your machines? ^^'
[21:50:17] <twnqx> one of them
[21:50:29] <twnqx> i'll just throw that piece of junk away
[21:50:38] <janneg> was there something else running on fogir? the OOM killer was always precise and killed only blender
[21:51:40] <KotH> no, i've nothing running on it at all
[21:51:54] <KotH> it's just rendering
[21:52:00] * twnqx throws his dual opteron minus ram and harddisks at koth
[21:52:35] <KotH> hmm... if it would be with ram, i'd take it
[21:53:18] <twnqx> nah
[21:53:28] <twnqx> the 16G will complement the 16 in the quad
[21:53:46] <KotH> bäh!
[21:54:04] <twnqx> yeah, 1G/core is not quite enough
[21:54:11] <KotH> lol
[21:54:43] <mru> some of my machines have 4G per core
[21:54:48] <mru> (single-core)
[21:57:06] <KotH> janneg: according to the logs, the oom killed bender... three times ^^'
[22:02:52] <janneg> with a couple of minutes between? I restarted the job after frame 97
[22:06:22] <KotH> there were quite a few minutes in between
[22:09:49] <janneg> so it doesn't like to get OOM-killed repeatedly
[23:30:49] <ramiro> why is it that autogen scripts insist on calling configure? it's annoying...
[23:31:30] <mru> cargo cult at its best
[23:31:43] <mru> orc?
[23:31:53] * mru noticed it had one of those
[23:33:15] <ramiro> how did you guess? =)
[23:34:59] <ramiro> oh, that's very safe. allocate SIZE bytes to write code to be executed. SIZE is hardcoded to 65536. I wonder if it's ever checked before actual writing...
[23:35:24] <mru> and even if, how is an overflow handled?
[23:55:55] <ohsix> ramiro: releases include generated files, from source control you generate those same files with your distro bits first, you can pass parameters to autogen
[23:56:41] <ramiro> ohsix: sure, but I don't *want* to pass parameters to autogen =)
[23:56:56] <ohsix> but you want to generate configure :>
[23:59:30] <ramiro> yep... and only that.