[FFmpeg-devel-irc] IRC log for 2011-01-26

[irc at mansr.com]

[00:05:54] <CIA-43> ffmpeg: Georgi Chorbadzhiyski <gf at unixsol.org> master * r535638b55f ffmpeg/ (libavformat/mpegtsenc.c tests/ref/lavf/ts):
[00:05:54] <CIA-43> ffmpeg: mpegtsenc: set reserved bits to 1 in PCR field
[00:05:54] <CIA-43> ffmpeg: The reserved bits between PCR base and extension fields must be
[00:05:54] <CIA-43> ffmpeg: set to 1.
[00:05:54] <CIA-43> ffmpeg: Signed-off-by: Mans Rullgard <mans at mansr.com>
[00:39:50] <BBB> mru: can you send me a backtrace?
[00:39:58] <BBB> mru: I don't have oenbsd at sparc so it's hard to debug
[00:39:58] <BBB> :-p
[00:40:08] <mru> me neither
[00:40:15] <BBB> whose box is it?
[00:40:27] <BBB> you need a maintainer contact info entry there
[00:40:28] <mru> kostylev I think
[00:41:29] <BBB> ok I'll email him
[00:44:01] <BBB> astrange: anything else I can do to help you debug it? :-p otherwise I'll continue looking either at other samples that fail, or I'll look at this one if you're not looking into it
[00:47:14] <astrange> i have to do some non-ffmpeg work tonight but i'll look at it half-paying attention
[00:47:27] <astrange> you can see if other samples have different problems
[00:50:24] <BBB> astrange: ok - I hope we can get this moving
[00:51:41] <astrange> and then keep going after that if they do. or if they don't
[00:55:27] <Anaerin> I'm getting an interesting output from the latest ffprobe for a stream: http://pastebin.com/Tir2JR7g
[00:57:46] <BBB> it's rtp - don't you need a sdp or rtsp-with-a-sdp?
[00:58:02] <Anaerin> Nope, not always.
[01:00:03] <Anaerin> It's an IPTV stream from Microsoft's Mediaroom system.
[01:00:45] <Anaerin> It should be h.264 Video, and several AAC audio streams, and possibly a closed caption stream as well.
[01:02:04] <Anaerin> As it's multicast, it's difficult to get a sample, but I have a few grabbed with rtpdump (That can be played back over a network interface to simulate the live stream) if that would help.
[01:02:53] <Anaerin> If this can be figured out and decoded, it'll help a lot with streaming U-Verse (among other IPTV systems) directly to computers without a set-top-box in the way.
[01:12:52] <Anaerin> The pastebin (http://pastebin.com/h2HPjbKi) has been updated with the -loglevel debug output
[01:14:48] <BBB> you probably want to put this on roundup
[01:14:52] <BBB> I have no time to look today
[01:14:54] <BBB> sorry
[01:15:26] <Anaerin> No problem.
[01:16:17] <BBB> astrange: I think all h264 bugs are this one
[01:16:24] <BBB> astrange: have you looked at the vsynth fate problems?
[01:16:29] <BBB> that's the only ones I see
[01:17:10] <astrange> i wrote down that it had to do with draw_edges, but i forgot my reasoning
[01:17:31] <astrange> i changed mpeg* decoding so it runs that in ff_draw_horiz_band, in mainline it does that in MPV_decode_end
[01:22:25] <BBB> after we've got this fixed, I'd like to do at least one round of review, some of the code in h264.c looked wrong so I want to make sure I get it (review = you explain me what it does so I know what it does, not review = I tell you what's wrong, you change it and resubmit)
[01:29:51] <BBB> I'm confused though, it seems the encoded file is different also
[01:29:55] <BBB> did you change anything in the encoders?
[02:08:07] <astrange> they share a lot of code and both call draw_edges()
[02:08:45] <CIA-43> ffmpeg: Marco Gittler <marco at gitma.de> master * rb09f548285 ffmpeg/libavcodec/libx264.c:
[02:08:45] <CIA-43> ffmpeg: Pass field order flag to libx264
[02:08:45] <CIA-43> ffmpeg: Signed-off-by: Jason Garrett-Glaser <jason at x264.com>
[02:12:44] <BBB> astrange: ok, I'll look
[02:45:53] <BBB> astrange: you only draw top/bottom, not left/right, edges, is that correct? why?
[03:00:05] <BBB> astrange: also, if I encode a wmv2 file (for example, fate fails for that) using ffmpeg-old and compare output of mt and old, they're identical
[03:00:13] <BBB> astrange: I think only encoding is broken, decoding seems fine
[03:27:09] <BBB> astrange: encoding of interframes seems broken, specifically, at the edges :) my rough guess is that you not drawing edges at the correct places in the "last" buffer causes motion estimation to give different results around the edges
[03:27:47] <BBB> astrange: decoding is fine afaics, I'll see if I can figure out the encoding paths, getting to know a whole new piece of codebase here that I was hoping not to have to look at...
[04:25:14] <peloverde> BBB: consider it reviewed
[05:20:20] <astrange> BBB: it certainly should end up with all of them drawn
[05:21:02] <astrange> BBB: in decode it draws top/bottom if the top/bottom parts of the video were decoded, and left/right of the decoded parts
[05:21:22] <astrange> and then draws everything at the end if the frame was damaged or draw_horiz_band was ever not called
[05:21:25] <astrange> iirc
[05:42:45] <peloverde> Is anyone planning on looking at anatoly's MxPEG patch?
[07:52:18] <cartman> moin
[07:53:12] <spaam> God morgon
[07:53:39] <cartman> or moroning
[07:58:20] <spaam> cartman: how is your $WIFE[2] today? :)
[08:02:36] <cartman> spaam: non-existent :P
[08:02:48] <superdump> morning
[08:03:03] <cartman> moin superdump
[08:03:31] <peloverde> greetings
[08:08:49] <andoma> morning
[08:14:38] <_av500_> gm
[08:15:32] <Sean_McG> idkfa
[08:17:35] <kshishkov> goda morgnar alla
[08:19:38] <spaam> kshishkov: allt bra?
[08:20:15] <kshishkov> spaam: javisst (utan Trocadero, jag har bara Trocadero bara i karamell)
[08:32:01] <siretart> lu_zero: sorry, I hope you didn't book the room for me yet, I've now learned that I cannot possibly make it to fosdem this year :-(
[08:40:13] <siretart> hm. I could take the night train.
[08:42:24] <kshishkov> where are you going from? Frankonia?
[08:42:30] <siretart> yes
[08:43:39] <siretart> hm. there doesn't seem to be any suitable connection
[08:44:03] <siretart> the problem is that I have a workshop here until ~5pm, where I must attend
[08:44:04] <kshishkov> yes, any connection via Stuttgart is definitely unsuitable
[08:45:27] <kshishkov> personally I'll go with train at 3:30 AM
[08:45:47] <siretart> 3:30am on saturday morning?
[08:45:53] <kshishkov> yes
[08:46:11] <kshishkov> hope it makes you feel better
[09:04:02] <pross-au> kshishkov: are you staying up late for that one, or getting up early??
[09:05:00] <spaam> pross-au: he wanted to be the first to see your patch for bink-b
[09:06:24] <pross-au> tossing up whether to tackle that, or mess around with bayer8
[09:06:54] <ubitux> btw, about the ff_ unexport patches
[09:07:06] <kshishkov> pross-au: it's 10AM here
[09:07:10] <ubitux> maybe those should not get exported right now: http://pastie.org/1498657
[09:07:17] <ubitux> they seem to be in used in mplayer
[09:07:38] <ubitux> (at least those, grabbed from a quick grep)
[09:08:01] <kshishkov> that's MPlayer, it likes to reuse internals of any project it assimilates
[09:10:21] <ubitux> :)
[09:13:42] * kshishkov wonders if DonDiego can give a lecture on clean pluggable modular design of MPlayer
[09:15:35] <DonDiego> what internals are you talking about?
[09:16:15] <jannau> DonDiego: http://pastie.org/1498657
[09:31:27] <DonDiego> i think those symbols might actually come from the copied mjpeg encoder in mplayer
[09:36:13] <Dark_Shikari> "clean pluggable modular design"
[09:36:15] <Dark_Shikari> "mplayer"
[09:37:01] <av500> </troll>
[09:39:11] <kshishkov> Dark_Shikari: there are still people that think so
[09:39:42] <kshishkov> Dark_Shikari: they alsoo see nothing wrong with mencoder.c
[09:40:17] <ubitux> (mencoder.c is no more in mplayer2)
[09:40:25] <ubitux> +present
[09:40:30] <superdump> mplayer2? :o
[09:40:37] <ubitux> (and no, it's not called mencoder2.c)
[09:41:36] <ubitux> superdump: Uoti's MPlayer if you prefer, but it's actually called mplayer2
[09:41:37] <kshishkov> superdump: aka uau-mplayer
[09:42:20] <merbzt> Dark_Shikari: awake ?
[09:42:50] <superdump> out of curiosity, where does it live?
[09:42:58] <superdump> (mplayer-uau)
[09:43:24] <kshishkov> repo.or.cz, I think
[09:44:30] <kshishkov> superdump: http://repo.or.cz/w/mplayer.git it seems
[09:44:47] <ubitux> s/mplayer/mplayer-build/
[09:45:03] <Dark_Shikari> merbzt: yes
[09:45:10] <ubitux> mplayer-build uses mplayer
[09:57:01] <merbzt> Dark_Shikari: I have some hardware that decodes some fragments of the clip distorted
[09:58:14] <merbzt> http://pastebin.com/48rQ4R6p
[09:58:21] <merbzt> that is the encode log
[09:58:26] <andoma> av500: package arrived on my desk
[09:58:38] <andoma> IRC is faster than mail
[09:59:23] <merbzt> Dark_Shikari: do you have any hint on what features that I can disable to pinpoint what causes decode corruption
[09:59:39] <merbzt> I tried lowering the bitrate and set the refs to 3
[09:59:43] <kierank> merbzt: weightp
[10:00:21] <spaam> those p frames..
[10:02:57] <cartman> lonely p frames
[10:03:34] <av500> andoma: nice
[10:12:00] <Dark_Shikari> merbzt: disable weightp
[10:27:10] <Tjoppen> interesting.. I just figured out a major difference between avid's opatoms and the standard
[10:27:45] <Tjoppen> they've worked around a retarded limitation in the standard, namely that of indexes not being allowed to be larger than 64k
[10:28:12] <merbzt> no change :/
[10:28:15] <merbzt> http://pastebin.com/yd96kHie
[10:28:21] <merbzt> any other suggestions ?
[10:28:32] <merbzt> Dark_Shikari / kierank ?
[10:31:04] <Dark_Shikari> what if bframes are off?
[10:31:15] <saste> michaelni: hi michael :)!
[10:31:24] <Dark_Shikari> he seems pretty quiet sadly
[10:31:46] <merbzt> think he is meeting ramiro
[10:32:50] <kshishkov> anybody knows why?
[10:32:57] <saste> anyway nice to see him online
[10:33:04] <kshishkov> I thought he's not into meeting people
[10:33:20] <saste> I believe ramiro was preparing himself for carnival...
[10:33:23] <kshishkov> saste: you're pathetic liar
[10:33:41] <saste> kshishkov: ?
[10:37:08] <lu_zero> good morning
[10:37:20] <DonDiego> saste: ramiro is travelling around europe
[10:37:39] <lu_zero> j-b: is there a way to make cvlc - close once the file is complete?
[10:38:20] <j-b> lu_zero: you mean like cvlc pr0n.avi vlc://quit
[10:38:42] <j-b> lu_zero: or you mean cvlc pr0n2.avi --play-and-exit ?
[10:39:15] <av500> j-b: is there a way to get pr0n.avi?
[10:39:31] <kshishkov> saste: "always nice to see him online" - I doubt you had much experience seeing him online. And since he doesn't talk it makes no difference.
[10:39:43] <j-b> av500: http://streams.videolan.org/misc/untriaged/ probably :)
[10:40:06] <av500> hmm, akiyo...
[10:40:12] <lu_zero> j-b: nc6 --continous --exec='cvlc - stuff'
[10:40:38] * kshishkov sees http://streams.videolan.org/misc/untriaged/lossless_touhou.snow-crash-vlc-1.0.0-git-20090310.nut and wonders who would produce such file
[10:40:40] <merbzt> av500: search for it on the pirate bay
[10:41:17] <av500> isnt that illegal?
[10:42:28] <kshishkov> av500: stop whining and do it!
[10:42:32] <iive> kshishkov:  it may be possible for michael to talk while sleeping, but I doubt he can type :P
[10:42:49] <saste> kshiskov: give him more time
[10:43:38] <kshishkov> saste: of course, but so far you can also say "it's always nice to see fftrollbot online"
[10:43:51] <j-b> Waouw, michaelni is on the chan? That _is_ cool.
[10:44:59] <merbzt> well now the error in one place disappeared but another one appeared instead
[10:47:19] <merbzt> http://pastebin.com/uqqpzDuG
[10:47:46] <merbzt> Dark_Shikari / kierank: any more suggestions ?
[10:48:14] <Dark_Shikari> try baseline profile?
[10:57:30] <lu_zero> siretart: where do you live exactly?
[10:58:11] <siretart> lu_zero: near nueremberg, that's the airport or trainstation I would use
[10:59:18] <merbzt> http://pastebin.com/Jx7TZuZy
[10:59:25] <merbzt> still distortions :/
[10:59:56] <lu_zero> so in the middle of Germany
[11:01:10] <DonDiego> siretart: if you can get to frankfurt you can likely share commute with stefan gehrer
[11:03:33] <kshishkov> DonDiego: if you can get to Bankstadt-am-Lufthafen you can get almost anywhere by train
[11:03:40] <merbzt> Dark_Shikari: this line has some low values, how do I disable whatever those are ?-> mb P  I16..4:  3.7%  0.0%  0.9%  P16..4: 24.5%  3.8%  0.8%  0.0%  0.0%    skip:66.3%
[11:03:48] <thresh> kshishkov: you're coming as wel?
[11:03:53] <Dark_Shikari> you don't
[11:03:54] <kshishkov> thresh: yes
[11:04:00] <thresh> kshishkov: ha nice
[11:04:26] <av500> kostya overload
[11:04:32] <thresh> :)
[11:04:44] <kshishkov> thresh: saturday morning so probably I'll be as nice as Edinaya Rossiya symbol after premature hybernation end
[11:05:16] <kshishkov> av500: when I was a student there were 3,5 Kostyas in our group and it still survived
[11:05:38] <av500> 3+0.5 or 2+1.5?
[11:05:53] <kshishkov> av500: what a silly question, you've seen me
[11:06:01] <thresh> kshishkov: у нас тут был прикол -- в компании работают 3.5 Павловых
[11:06:57] <cartman> what was the thing to send patches with git? git-send-patch something
[11:07:17] <pross-au> git send-email
[11:07:24] <av500> cartman: libswscale patches?
[11:07:25] <cartman> thanks pross-au :)
[11:07:25] <kshishkov> thresh: я как-то работал на кафедре где было два Ивановых (не родственники), а в дирекции Укртелекома вообще "работают" кланами
[11:07:32] <cartman> av500: snowdsp_mmx :P
[11:11:05] <kshishkov> cartman: Snow+lossy Sonic in NUT for the pure FFmpeg solution ;)
[11:13:36] <cartman> kshishkov: NUT is vapurware, even more now that Duke Nukem Forever is coming.
[11:13:44] <Cyril__> Hi
[11:13:53] <Cyril__> I was wondering what is the timebase used for AVStream's index_entries[].timestamp
[11:14:05] <Cyril__> From a logical point of view, I think it should be AVStream's timebase, but I've found such code in the mov.c file, so I'm having doubts
[11:14:12] <Cyril__> AVIndexEntry *current_sample = &avst->index_entries[msc->current_sample];
[11:14:18] <Cyril__> int64_t dts = av_rescale(current_sample->timestamp, AV_TIME_BASE, msc->time_scale);
[11:14:27] <Cyril__> So, is it AV_TIME_BASE or the streams's base ?
[11:15:06] <Cyril__> I can propose a patch adding the @doxy for this field in the documentation
[11:17:09] <DonDiego> please send that patch to the ml
[11:17:37] <Cyril__> Yes, once I know what is the "expeced" time base for the field, I'll
[11:18:45] <kshishkov> cartman: well, Nut is usable, it's just not very popular
[11:18:58] <cartman> kshishkov: never heard anyone using it.
[11:19:24] <cartman> Why does git format-patch doesn't extract my local commit as a patch :S
[11:19:46] <kshishkov> cartman: lu_zero claimed something like that
[11:20:06] <cartman> kshishkov: claimed what? :)
[11:20:26] <kshishkov> cartman: using NUT of course!
[11:20:29] <cartman> lol
[11:20:59] <lu_zero> cartman: did you commit?
[11:21:03] <cartman> lu_zero: yeah
[11:21:07] <cartman> lu_zero: git log shows it
[11:21:11] <lu_zero> your command line?
[11:21:19] <cartman> git format-patch <commit hash>
[11:21:29] <lu_zero> git format-patch <commit hash>^
[11:21:35] <cartman> hmm
[11:21:58] <av500> hmm^
[11:21:58] <cartman> lu_zero: thanks! it silently ignored the first one then :)
[11:22:59] <cartman> From: =?UTF-8?q?=C4=B0smail=20D=C3=B6nmez?= <ismail at namtrac.org>
[11:23:03] <cartman> UTF-8 fsck
[11:23:35] <siretart> DonDiego: yes, but I will likley make it to frankfurt by about 7 to 8pm. I doubt that Stefan is going to wait that long
[11:25:59] <DonDiego> when will you arrive in brussels?
[11:26:06] <DonDiego> will you stay until monday?
[11:26:08] <Flameeyes> cartman: if you just want the latest, simply use "git format-patch -1" :)
[11:26:11] <lu_zero> 4+ hours
[11:26:29] <cartman> Flameeyes: is there a syntax to format all local patches?
[11:26:37] <Flameeyes> cartman: git format-patch master..
[11:26:42] <cartman> Flameeyes: ah thanks
[11:26:42] <cartman> :)
[11:26:44] <Flameeyes> [including the two final dots]
[11:26:51] <Flameeyes> works fine even if you do "merge master" a few times btw
[11:26:59] <cartman> nice
[11:29:22] <Flameeyes> uhm new nvidia driver, I wonder if it's going to work with suspension on my laptop
[11:29:49] <Kovensky> 08:26.44 Flameeyes: [including the two final dots] <-- I thought they were implicit on format-patch?
[11:30:08] <Kovensky> which is why when you do git format-patch <some commit> it makes a patch for all commits since <some commit> until HEAD
[11:30:30] <Flameeyes> Kovensky: if they are they added it afterwards, used not to work
[11:33:14] * cartman hugs CPAN
[11:45:04] <spaam> cartman: perl user;SSSSS
[11:45:44] <cartman> spaam: git still uses perl :)
[11:46:04] <spaam> i know.  i use it at work too.
[11:46:16] <spaam> so i can read some pcaps better ;D
[11:46:18] <cartman> spaam: intall Net::SMTP::SSL and done :D
[11:46:27] <cartman> install*
[11:47:39] <kierank2> i tried doing that once
[11:47:45] <kierank2> didn't install and i gave up#
[11:47:55] <cartman> kierank2: must have failed automated tests
[11:51:42] <av500> köfte!
[11:51:44] <siretart> DonDiego: If I manage to go, I'd most probably stay until monday
[11:53:27] <DonDiego> cool, time to talk then
[11:53:40] <DonDiego> i'm already looking forward to the beer event on friday :)
[11:54:30] <lu_zero> so...
[11:54:34] <lu_zero> what to book?
[11:56:01] <cartman> av500: möhte
[11:56:14] <lu_zero> (meanwhile we got more options regarding rooms =))
[11:59:26] <DonDiego> lu_zero: what did you find out?
[11:59:39] <DonDiego> maybe post about it, easier to have everybody see the info in this way
[12:14:16] <BBB> mru: I've traced the bsd/sparc bugs, fix should be pretty easy
[12:15:25] <lu_zero> DonDiego: just got more rooms available
[12:15:57] <lu_zero> apparently somebody rescinded the booking
[12:17:21] <DonDiego> siretart: i'm confused now, coming or not?
[12:18:57] <siretart> DonDiego: do you think stefan will wait until 8pm for me?
[12:27:18] <pross-au> Q: How would i describe an 8-bit bayer pxlfmt using AVPixFmtDescriptor
[12:28:49] <BBB> A: you might have to change AVPixFmtDescriptor a bit...?
[12:29:08] <BBB> (is bayer really a pixfmt, or is it a codec? or "in between"?)
[12:29:23] <pross-au> the later
[12:30:48] <DonDiego> siretart: ask him, that would mean arriving in brussels around 00:00 i think...
[12:37:43] <siretart> I too modest to set him on pressure with such a question. I've explained my situation in the mail, either he answers or he doesn't
[12:40:13] <lu_zero> uhm
[12:42:30] <Kovensky> http://i.remotehost.co/images/d5acdbbb6cea90e6f7513a26844ef8b1.jpg
[13:10:02] <wbs> cartman: sure you're not indian?
[13:12:12] <DonDiego> siretart: if you can catch the thalys somewhere you should be able to go to brussels quickly
[13:12:48] <av500> thalys goes from cologne afaik
[13:13:41] <siretart> what's thalys?
[13:13:52] <cartman> wbs: why would you think that?
[13:14:04] <cartman> wbs: did I ask for teh codez? :p
[13:14:17] <wbs> cartman: on android-ndk, yes ;P
[13:14:22] <cartman> wbs: ah lol
[13:14:27] <cartman> wbs: thats well deserved
[13:14:29] <kshishkov> siretart: French train going to Netherlands or Belgium and Germany
[13:14:37] <cartman> wbs: stupid shit is not documented somewhere
[13:14:49] <wbs> cartman: well, JNI is well documented in itself IMO
[13:15:00] <kshishkov> siretart: French variant of ICE if you like ;)
[13:15:10] <wbs> cartman: no need to have a specified "how do I use class X through JNI" document when you can read the JNI spec and use that to access whatever api you want ;P
[13:15:23] <siretart> I thought they call it TGV. ok
[13:15:27] <cartman> wbs: the only docs I found explains using C++ code inside Java
[13:15:32] <cartman> wbs: not the other way
[13:15:45] <cartman> wbs: please feel free to redirect to a RTFM for that :)
[13:15:51] <wbs> cartman: the docs aren't NDK specific, just read the normal JNI docs
[13:15:59] <cartman> wbs: ah
[13:16:05] <wbs> cartman: http://download.oracle.com/javase/1.5.0/docs/guide/jni/spec/jniTOC.html
[13:16:09] <wbs> cartman: there you go, RTFM
[13:16:11] <cartman> ooops
[13:16:22] * cartman will act like an Indian in ndk list from now on
[13:16:28] <cartman> Hello, thank you, come back again.
[13:16:32] <cartman> </simpsons>
[13:16:45] <cartman> mv cartman apu
[13:17:32] <lu_zero> ^^;
[13:24:01] <kshishkov> siretart: yes, but they all have fancy names for international routes
[13:33:01] <cartman> wbs: is there a way to get javah to create the header for you?
[13:33:31] <wbs> cartman: yes, if you've got the normal eclipse setup where binaries are built under $proj/bin, do javah -classpath $proj/bin com.foo.MyClass
[13:33:51] <cartman> wbs: right but the class is android.media.MediaPlayer :)
[13:34:08] <wbs> cartman: why would you need a header for that?
[13:34:14] <wbs> cartman: you're doing it wrong
[13:34:33] <cartman> wbs: ok I could just write the method declerations by hand I guess
[13:34:43] <wbs> cartman: what method declarations do you need?
[13:35:00] <cartman> wbs: MediaPlayer.create
[13:35:13] <cartman> and start()
[13:35:37] <wbs> cartman: yes, and in order to call that from JNI, you don't use a JNI header, that's for calling native functions from java (javah creates such headers only for the methods declared with native)
[13:35:59] <cartman> argh
[13:36:00] <cartman> ok
[13:36:18] <wbs> cartman: you use FindClass and GetMethodID and CallVoidMethod etc for calling java methods from native
[13:36:30] <cartman> ok
[13:36:40] * mru has disturbing memories of implementing that shit in a jvm
[13:36:42] <wbs> ... all of that exactly as you do in every other JNI environment, none of that is android specific
[13:43:32] <wbs> mru: btw, I'm getting "Error: bad instruction stm" (and the same for ldm) on some ancient gcc/binutils - is that some meta-instruction that newer binutils expands into longer instructions?
[13:44:04] <mru> no
[13:44:12] <mru> just update binutils
[13:44:25] <mru> old ones might insist on stmia/ldmia
[13:44:45] <mru> even without base reg writeback
[14:14:54] <BBB> Dark_Shikari: please review the C patch also when you wake up
[14:15:33] <j-b> good morning BBB
[14:16:33] <BBB> hi j-b
[14:38:57] <kierank> http://forum.doom9.org/showthread.php?p=1474381#post1474381
[14:39:51] <kshishkov> so?
[14:40:39] <cartman> wbs: ok got Hello World working :P
[14:40:48] <kierank> kshishkov: just saying
[14:40:48] <wbs> cartman: congrats :-)
[14:40:51] <cartman> wbs: in desktop jni :P
[14:41:11] <av500> cartman: so now you can publish ffmpeg in google market?
[14:41:25] <kierank> av500: maybe he's more chinese then
[14:42:00] <cartman> wbs: but the normal (desktop) examples use JNI_CreateJavaVM but I think I should just use JNI_onLoad to get a VM pointer, right?
[14:42:25] <j-b> av500: btw, vlc works on the Archos 32 on 2.2
[14:42:34] <cartman> j-b: how? :D
[14:42:37] <cartman> where :D
[14:42:37] <wbs> cartman: uh.. that depends on where you want your code to be called
[14:42:43] <av500> j-b: nice
[14:42:44] <j-b> cartman: how? with C++ code
[14:42:51] <cartman> j-b: nice nice.
[14:42:52] <j-b> cartman: where? on the Archos 32
[14:42:53] <wbs> cartman: normally, you mark a method native in java, then implement that in JNI
[14:42:59] <cartman> j-b: send me the apk :P
[14:43:23] <j-b> cartman: well, it is a bit too early for that :)
[14:43:23] <wbs> cartman: but if you don't want to go via java at all, you'd better just look at the nativeactivity stuff from 2.3
[14:43:33] <cartman> wbs: hmm in this case I want to call arbitrary Java methods
[14:43:41] <cartman> wbs: nope we only have 2.2 atm.
[14:43:49] <j-b> cartman: we started as 2.3, and we are going back to 2.2
[14:43:52] <cartman> j-b: congrats! :)
[14:44:00] <wbs> cartman: yes, but the native code that calls java methods, who calls that?
[14:44:18] <cartman> wbs: a library loaded via JNI
[14:44:36] <cartman> Java -> libmyapp.so -> calls Java method
[14:44:46] <wbs> yes
[14:44:55] <j-b> cartman: the vout was 2.3 (native only) and now is 2.2 too ( jni)
[14:45:00] <wbs> but why do you need to get a VM pointer at all? isn't JNIEnv enough?
[14:45:14] <cartman> j-b: very nice :)
[14:45:38] <cartman> wbs: I only need JNIEnv yes, but where does Android pass that to me? :)
[14:46:00] <wbs> cartman: it passes it as the first argument to every single JNI method that java calls in your .so
[14:46:15] <wbs> cartman: you've never ever done this before, and still you talk so much on all the android-ndk lists? ;P
[14:46:27] <j-b> cartman: the apk we have is not-NEON enabled yet
[14:56:16] <lu_zero> BBB: what about soc11?
[14:58:10] <Compn> DonDiego : you alive ?
[14:58:35] <Compn> i plan to commit that ffmpeg.org download patch today unless you want to reword somethin
[14:58:46] <Compn> i think lu_zero said something about it too ?
[14:59:11] <Compn> lu_zero , DonDiego : any rewording ideas ?
[14:59:29] <Compn> the second one, with the 'mean, dirty,' line michael came up with
[15:00:01] <DonDiego> i will suggest marking it as private dev tree
[15:00:06] <mru> Compn: do not commit that
[15:00:20] <Compn> DonDiego : but its open to whomever
[15:00:30] <Compn> mru : suggestions welcome
[15:00:40] <lu_zero> Compn:
[15:00:45] <mru> I'll do something today
[15:00:52] <Compn> ....
[15:01:06] <Compn> thought you werent going to do anything for michael :)
[15:01:06] <merbzt> Compn: I agree abit with you here, but I want a neutral name for both repos
[15:01:07] <Compn> ehe
[15:01:08] <lu_zero> repo ${foo}, tree maintained by ${person}
[15:01:36] <lu_zero> possibly
[15:01:38] <Compn> merbzt : yeah, well get the tree listed, then you can bikeshed your names later
[15:01:54] <lu_zero>  repo ${foo}, tree maintained by ${person}, mirror(s) : ...
[15:02:04] <mru> lu_zero: that's what I had in mind
[15:02:16] <lu_zero> mru: =)
[15:02:18] <mru> and throw in some more trees too
[15:02:21] <Compn> lu_zero : sure sounds fine, whos the new tree maintained by $person ?
[15:02:22] <mru> like mine
[15:02:37] <lu_zero> I should push mine somewhere
[15:02:53] <Compn> but the description should stay, at least its accurate
[15:03:02] <merbzt> lu_zero: I like that idea
[15:03:26] <DonDiego> Compn: open to whomever?
[15:03:42] <DonDiego> i haven't sent in my ssh key yet, high time to try i guess...
[15:03:50] <Compn> DonDiego : yes, michael has said a few times if anyone wants commit access...
[15:04:10] * Compn chortles
[15:04:16] <Compn> well, be interesting at least
[15:04:26] <Compn> :)
[15:05:22] <kshishkov> Compn: I'm too lazy to generate it. And I've forgotten passphrase for my GPG key minutes after I generated it
[15:05:55] <spaam> kshishkov: fail
[15:05:55] <Compn> kshishkov : you should have id_rsa or some kind of file, or if you sent it into ffmpeg repo, someone else may have it for you
[15:06:03] <pJok> kshishkov, are you sure you just didn't one-way encrypt it? ;)
[15:06:13] <Compn> we can pass around your key even if you cant generate it again
[15:06:15] <mru> kshishkov: try bits of the swedish national anthem
[15:06:46] <kshishkov> mru: in my case too obvious and not all keyboards have åäö
[15:06:49] <Compn> so wait, isnt it the same passphrase as your ssh password ?
[15:07:13] <Compn> how would you login... if you dont have the ...
[15:07:15] <{V}> since file maintainers can get (and some have) commit access on the videolan repo, maybe "lead by" rather than "maintained by" ?
[15:07:16] <Compn> anyway you can generate a new one :P
[15:07:34] <Compn> {V} : still waiting to know who 'leads' the new tree...
[15:07:35] <spaam> {V}++
[15:07:53] <spaam> Compn: "The new maintiners"..
[15:07:56] <Compn> lol
[15:07:56] <kshishkov> Compn: where to?
[15:08:20] <lu_zero> uhm
[15:08:30] <Compn> kshishkov : where to send key? you could reply to michaels last mail i guess?
[15:09:50] <Compn> anyways, must go afk now
[15:10:03] <Compn> mru has 24 hours :P
[15:10:30] <Compn> or maybe 12hr who knows
[15:10:50] <lu_zero> yawn
[15:21:00] <superdump> BBB: have you started on xvp8 yet? :)
[15:21:37] <BBB> a little, but only in private
[15:22:12] <mru> when do you start at google?
[15:22:35] <BBB> end of march
[15:23:00] <kierank> is it true that you'll be working full time on xvp8 then?
[15:23:01] <superdump> and when is xvp8 due?
[15:23:14] <kshishkov> "when it's done"
[15:23:19] <kierank> superdump: day after x262's done ;)
[15:23:22] <BBB> "when it's done":)
[15:23:33] <kshishkov> like DNF before it was completely spoiled
[15:24:25] <av500> BBB: btw, the guy that hired you got kicked out
[15:24:30] <av500> that schmitt guy
[15:24:50] <kshishkov> av500: are you going to remind him every week?
[15:24:55] <superdump> :)
[15:25:01] <superdump> 'that schmidt guy'
[15:26:03] <kshishkov> for av500 there's only one guy from M$ exists
[15:26:41] <kierank> Ballmer writes all the code
[15:26:44] <kierank> throws all the chairs
[15:26:53] <av500> kshishkov: there is one guy I have worked with for years, he is now at m$, its the only guy I know *exists* :)
[15:27:30] <kshishkov> av500: hmm, such guy would rather unexist for me
[15:27:38] <av500> he is bored
[15:27:50] <av500> so he will ununexists soon
[15:27:57] <mru> reexist
[15:28:13] <kierank> ctrl-alt-exist
[15:31:09] <kierank> I saw a car registration plate the other day. "10l"
[15:31:37] <andoma> hum hum .. a bit OT but starting with gcc 4.4.x it seems that it emits less warnings for uninitialized variables
[15:32:07] <andoma> i can compile some code in 4.4.x with no warnings.. and then when trying with 4.3.x I get (correct) warning about uninitialized vars
[15:32:45] <andoma> i was just wondering if anyone else have seen the same thing
[15:34:29] <kshishkov> not FATE
[15:35:27] <iive> kierank: really?
[15:36:58] <mru> andoma: that's not unreasonable
[15:37:14] <mru> presumably gcc got better at tracking data dependencies
[15:37:39] <kierank> iive: yes and I lol'd and people were looking at me weird
[15:37:56] <CIA-43> ffmpeg: Justin Ruggles <justin.ruggles at gmail.com> master * r4c57cde942 ffmpeg/libavcodec/ (ac3.c ac3.h ac3dec.c ac3enc.c):
[15:37:56] <CIA-43> ffmpeg: Add ff_ prefix to ac3_common_init().
[15:37:56] <CIA-43> ffmpeg: Signed-off-by: Mans Rullgard <mans at mansr.com>
[15:37:59] <CIA-43> ffmpeg: Diego Elio Pettenò <flameeyes at gmail.com> master * r7767d8d361 ffmpeg/libavcodec/ (fft.c fft.h):
[15:37:59] <CIA-43> ffmpeg: Mark C base versions of FFT functions static to fft.c
[15:37:59] <CIA-43> ffmpeg: Signed-off-by: Mans Rullgard <mans at mansr.com>
[15:38:07] <mru> there's a car in my street with X268 on the licence place
[15:38:12] <CIA-43> ffmpeg: Diego Elio Pettenò <flameeyes at gmail.com> master * reb7ccf8f33 ffmpeg/libavfilter/ (avfilter.c internal.h):
[15:38:12] <CIA-43> ffmpeg: Make the avfilter debug functions and macros static to avfilter.c
[15:38:12] <CIA-43> ffmpeg: This removes ff_get_ref_perms_string, ff_dprintf_ref and ff_dprintf_link
[15:38:12] <CIA-43> ffmpeg: fro the interface of libavfilter.
[15:38:12] <CIA-43> ffmpeg: Signed-off-by: Mans Rullgard <mans at mansr.com>
[15:38:14] <CIA-43> ffmpeg: Justin Ruggles <justin.ruggles at gmail.com> master * r24e3ad3031 ffmpeg/libavcodec/ac3.c:
[15:38:14] <CIA-43> ffmpeg: ac3: Remove ff_ac3_critical_band_size_tab.
[15:38:14] <CIA-43> ffmpeg: It is only used to generate band_start_tab, which about the same size, at
[15:38:14] <CIA-43> ffmpeg: runtime, so it's simpler just to always hardcode band_start_tab.
[15:38:14] <CIA-43> ffmpeg: Signed-off-by: Mans Rullgard <mans at mansr.com>
[15:38:27] <kshishkov> mru: too early for that
[15:40:19] <mru> siretart: ping
[15:41:53] <siretart> mru: pong
[15:42:07] <mru> siretart: please comment on http://patches.ffmpeg.org/patch/528/
[15:43:15] <siretart> on my way
[15:43:56] <mru> thanks
[15:44:30] <siretart> anyone feeling to share a room with me from *sat* -> *mon*? (I could take the plane on sat morning)
[15:44:52] <mru> you'll miss friday beer
[15:44:59] <siretart> indeed
[15:45:20] <Compn> ok iz back, i miss anything
[15:46:24] <uau> cartman: does clang do its own parsing for asm or use a custom assembler? it doesn't just pass inline asm to an underlying 'as' command?
[15:47:00] <lu_zero> siretart: me and Diego could book 1 day for the twin and then switch for the triple
[15:47:07] <cartman> uau: it has its own assembler
[15:47:30] * lu_zero re-checks about availabilities
[15:47:45] <kshishkov> mru: so I won't spoil your Friday evening with my sober face too
[15:49:46] <DonDiego> siretart: we'll miss you for friday beer :-(
[15:50:03] <av500> We will drink his share
[15:50:22] <DonDiego> av500: you drink it, you're twice my size...
[15:50:28] <superdump> i should check what time i arrive on friday
[15:51:36] <lu_zero> may I book now?
[15:52:56] * mru updates to clang head
[16:01:43] <cartman> mru: good :p
[16:02:02] <mru> is this a very recent thing in clang?
[16:02:08] <cartman> ~1 month
[16:02:09] <cartman> or so
[16:02:19] <mru> I may have just missed it then
[16:02:32] <BBB> anyone have a ppc?
[16:03:09] <BBB> I want someone on a ppc+altivec to try a patch for me
[16:03:10] <BBB> brb
[16:03:43] <mru> BBB: /me has
[16:03:49] <mru> and you may have an account on it
[16:16:50] <mru> cartman: now on clang rev 124291
[16:17:52] <cartman> mru: still works? (MPlayer)
[16:18:07] <mru> fate will test ffmpeg in a moment
[16:18:31] <cartman> ffmpeg works here, only MPlayer
[16:18:46] <mru> so find out what's different
[16:18:51] <mru> compare cflags etc
[16:18:59] <cartman> ok
[16:31:59] * kierank curses libsndfile
[16:32:15] <spaam> why?
[16:32:40] <kierank> doesn't build and it just a silly wrapper
[16:33:04] <spaam> wrap a wrapper round it
[16:33:23] <mru> wrap it around itself
[16:33:23] <spaam> mru know how to do that i have heard.
[16:33:35] <kierank> might end up doing that in fact
[16:33:50] <kierank> adding twolame to ffmpeg :/
[16:35:10] <cartman> toolame
[16:35:38] <CIA-43> ffmpeg: Diego Elio Pettenò <flameeyes at gmail.com> master * r2d162e3825 ffmpeg/ (libavcodec/iff.c libavcodec/iff.h libavformat/iff.c):
[16:35:38] <CIA-43> ffmpeg: Make ff_cmap_read_palette static to libavcodec/iff.c. Delete iff.h.
[16:35:38] <CIA-43> ffmpeg: The iff.h header only declared one function that is now static, the
[16:35:38] <CIA-43> ffmpeg: libavformat/iff.c source file wasn't using it before. Drop the file
[16:35:38] <CIA-43> ffmpeg: entirely.
[16:35:38] <CIA-43> ffmpeg: Signed-off-by: Mans Rullgard <mans at mansr.com>
[16:35:42] <CIA-43> ffmpeg: Diego Elio Pettenò <flameeyes at gmail.com> master * rd36beb3f69 ffmpeg/libavcodec/ (268 files):
[16:35:42] <CIA-43> ffmpeg: Add ff_ prefix to data symbols of encoders, decoders, hwaccel, parsers, bsf.
[16:35:42] <CIA-43> ffmpeg: None of these symbols should be accessed directly, so declare them as
[16:35:42] <CIA-43> ffmpeg: hidden.
[16:35:42] <CIA-43> ffmpeg: Signed-off-by: Mans Rullgard <mans at mansr.com>
[16:36:05] <spaam> kierank: why do you want twolame?
[16:36:35] <kierank> mp2 encoding of course
[16:36:48] <mru> how 1993
[16:37:14] <spaam> kierank: something wrong with mp3? acc? wv? .amr ?
[16:38:21] <kierank> need to test it on this stb
[16:38:35] * kierank agrees with mru about 1993ness
[16:39:00] <kierank> oh finally autotools picked it up
[16:48:12] <mru> hmm, new unused function warning: http://fate.ffmpeg.org/armv5te-linux-armcc-4.0/20110126164053/compile/20110126070634
[17:01:10] <lu_zero> roundup nas back online...
[17:02:29] <BBB> mru: can I send you a patch and you tell me if it fixes make fate-vp8 on it?
[17:02:44] <mru> BBB: I can give you an ssh login on the ppc
[17:02:48] <BBB> ok
[17:02:59] <mru> but it's not broken there, so what's to fix?
[17:03:00] <BBB> lu_zero: \o/ so comments work again?
[17:03:13] <BBB> mru: it crashes on a few samples on one of the fate machines, and I think I know the bug
[17:03:20] <mru> not mine
[17:03:22] <BBB> (since a few days - not the other ppc that always has different output)
[17:03:22] <siretart> lu_zero: okay, I think I found a connection to attent. not exactly inexpensive, but anyway
[17:03:30] <BBB> can I test the patch anyway?
[17:03:34] <BBB> if it doesn't break I'll commit it
[17:03:37] <BBB> it's more correct
[17:03:41] <mru> BBB: can't you test it yourself?
[17:03:46] <siretart> lu_zero: in that case I'd stay 2 nights: saturday night and sunday night
[17:03:49] <BBB> don't have a ppc with altivec
[17:03:55] <mru> the crashing machine is a sparc belonging to kostylev
[17:03:56] <siretart> lu_zero: did you already order the rooms?
[17:04:05] <siretart> err, book, even
[17:04:11] <lu_zero> still waiting ^^;
[17:04:11] <BBB> mru: that one is fixed, but crash is in c code; I think the crash on ppc is in altivec code
[17:04:35] <mru> BBB: oh, it's failing on ppc/darwin
[17:04:40] <mru> that's not mine either
[17:12:19] <siretart> lu_zero: okay, tell/mail me if you booked the room. I'll then order the flight tickets
[17:14:02] <BBB> mru: yeah that one is the one I mean
[17:14:14] <BBB> astrange: ping
[17:15:18] <lu_zero> av500, wbs do you have an rtp-ts source around?
[17:15:35] <av500> no
[17:15:41] <av500> its the free.fr box
[17:15:44] <av500> in france only
[17:15:51] <av500> but I have a login
[17:15:58] <av500> I can check patches tonight or so
[17:20:37] <astrange> pong
[17:30:11] <BBB> astrange: any ideas on the mpeg/wmv/etc encoding? the problem is encoding only, decoding is fine
[17:30:20] <BBB> astrange: the problem is related to ME around the edges, I think
[17:30:34] <BBB> astrange: is it posible that the encoder doesnt' draw edges around the prev frame (used for ME) at all?
[17:30:53] <BBB> astrange: that is my rough guess looking at the changes observed
[17:31:08] <BBB> (i.e. it used to, but somehow that code got disabled in ffmpeg-mt)
[17:33:50] <astrange> it's possible
[17:36:02] <BBB> that's about as far as I've gotten
[17:36:08] <BBB> that's also the only two bugs I see
[17:36:24] <BBB> all other test failures can be reduced to either the h264 bug you are hopefully working on, or this one
[17:36:34] <BBB> which one would you like me to work on?
[17:36:37] <BBB> and can you work on the other?
[17:42:36] <astrange> you can take the make test one, try reverting ff_draw_horiz_band and MPV_frame_end in mpegvideo.c
[17:45:20] <lu_zero> av500: since I have a _really_ ugly thing to try
[17:45:50] <av500> lu_zero: and you think I would refuse that?
[17:45:51] * lu_zero is thinking about optimizations
[17:46:34] <lu_zero> av500: it's basically hack some code that fill a buffer and then runs the normal mpegts functions as they would over it
[17:46:54] <lu_zero> all of it placed in the codepath currently present
[17:47:04] <lu_zero> and I'm still dubious about it =P
[17:47:14] <Sean_McG> I really need to swap in that faster processor module on my SPARC... it's still building gcc trunk (well, running the testsuite anyways) after 15 hours
[17:47:48] <mru> Sean_McG: what cpu is that?
[17:48:23] <Sean_McG> mru: I have a Sun Blade 1000 with a 750MHz US3... but I got a 900MHz module for it off of eBay but I'm missing the torque tool to put it in
[17:54:05] <av500> [18:43:48] <coppolla> i heve a probleme with this command "sudo chown <your login> /usr/src/android"
[17:54:10] <av500> [18:49:48] <akk> What problem?
[17:54:16] <av500> [18:52:19] <coppolla> bash: your: No such file or directory
[17:54:27] <mru> :)
[17:54:42] <mru> there is one word for such people: *plonk*
[17:58:01] <Sean_McG> hahahahah
[18:01:46] <BBB> Dark_Shikari: ping please review vp8 patch :-p
[18:02:14] <wbs> lu_zero: I've got one
[18:02:34] <BBB> mru: can you say that timebase-unreliable in the 0/2 thread? there it's explained better and I think you and I basically agree on the same thing
[18:02:40] <BBB> mru: at least I think what you say makes sense
[18:03:05] <mru> yes, I'm pretty sure we agree
[18:03:24] <mru> the problem is that 80% of numbers from lavf are pure fiction
[18:04:46] <kshishkov> mru: you insult BBB. RM demuxer has higher rate of fictious numbers
[18:04:46] <BBB> indeed
[18:04:49] <lu_zero> wbs: where =) ?
[18:09:16] <wbs> lu_zero: http://albin.abo.fi/~mstorsjo/RTP_mpegts_sample.{cap,rtpdump} - it's from some roundup case a few months back
[18:11:00] <Sean_McG> ooo yay roundup works today
[18:11:28] <mru> yeah, it's round-to-even, works on even days
[18:11:38] <Sean_McG> heheheh
[18:18:49] <lu_zero> Sean_McG: hopefully
[18:19:20] <Sean_McG> ah so it's still a fingers-crossed kinda thing
[18:20:31] <lu_zero> Sean_McG: I don't have control over the nas
[18:20:34] <lu_zero> nor the hardware
[18:20:49] <lu_zero> the software now seems properly working
[18:25:03] <Sean_McG> ah
[19:21:18] <mru> re commit rules, I never liked the 48h commit ultimatum method
[19:21:27] <av500> 54h ftw
[19:22:04] <mru> it's simple a matter of quality control
[19:34:44] <DonDiego> gtg, cu
[19:35:08] <mru> lu_zero: ping
[19:36:45] <uau> Flameeyes: re your mail, that "if the upgrade happens at the same time" argument doesn't always work because of the library major version issue i mentioned yesterday
[19:36:59] <Flameeyes> uau: which one?
[19:37:37] <uau> which main? the latest on ffmpeg-devel, where the quote is from
[19:37:44] <uau> /main/mail/
[19:37:53] <uau> or which argument?
[19:38:00] <Flameeyes> which argument
[19:38:32] <uau> you can't rely on ffmpeg libraries having matching versions if their major version numbers change independently
[19:38:38] <Flameeyes> doesn't matter
[19:38:59] <uau> why wouldn't it?
[19:39:45] <Flameeyes> the original problem with ABI and Debian (and other binary distros), for which siretart pushed for versioned libraries relates to projects that link more than one FFmpeg library
[19:40:26] <Flameeyes> in that situation, the fact that the ABI version of the libav* set differ, is the root cause, but it's relieved by the presence of ABI versions so that symbols don't clash with one deptree to the other
[19:40:56] <Flameeyes> so you can have a process loading both a libavutil.so.50 and a libavutil.so.49, but only a libavcodec.so.52
[19:41:03] <uau> your symbol rename _would_ cause breakage with suitable major changes  - do you not see that, or are you saying it doesn't matter?
[19:41:37] <siretart> who uses that particular symbol?
[19:41:38] <Flameeyes> how would it, assuming no ABI version change
[19:41:44] <Flameeyes> siretart: only libavformat.so.52
[19:42:02] <uau> Flameeyes: here's an example where things would break
[19:42:10] <siretart> so it is a purely internal symbol. great!
[19:42:20] <uau> suppose a symbol is defined in libavcodec and used by libavformat
[19:42:22] <Flameeyes> so if you replace _both_ libavformat.so.52 and libavutil.so.52 at the same time, you will _not_ feel any breakage
[19:42:42] <Flameeyes> siretart: no, it's libavcodec→libavformat, it's an interlib symbol the one in the example
[19:42:45] <mru> that symbol was only used by lavf for a short time
[19:42:55] <siretart> Flameeyes: oh, I see
[19:42:56] <Flameeyes> the one Ronald asked about is purely internal one so the original problem is moot
[19:43:11] <Flameeyes> uau: sure like the one I used as an example
[19:43:48] <uau> your example only mentioned a case where use doesn't install all new ffmpeg libraries
[19:43:58] <uau> use/user
[19:44:31] <Flameeyes> if you drop it with an ABI bump, you'll have libavcodec.so.50 with symbol, libavcodec.so.51 without it, old libavformat.so.52 uses it and links to the former; new libavformat.so.52 uses it and links to the newer → you have no issue at all
[19:45:19] <uau> yes if you DO change major version at the rename then things work
[19:45:41] <Flameeyes> if you drop it without ABI bump, you'll have old libavcodec.so.50 with symbol, new libavcodec.so.50 without it; old libavformat.so.52 using it, new libavformat.so.52 not using it it; software started before update uses the old (unlinked) version, software started afterwards will use the new versions
[19:45:57] <Flameeyes> the only case you have where it will go wrong is if you mix new libavformat and old libavcodec
[19:46:12] <Flameeyes> but that situation only happens if you _don't_ do a whole-package update of ffmpeg per each build
[19:46:21] <Flameeyes> [which as far as I can tell is not the case for Debian]
[19:46:25] <uau> Flameeyes: that "without ABI bump" case is not so simple
[19:46:40] <Flameeyes> uau: note what I wrote in my mail: "if they are upgraded at the same time"
[19:46:43] <Flameeyes> in that case yes, it is so simple
[19:46:50] <uau> no it isn't :)
[19:46:56] <Flameeyes> why it isn't?
[19:47:10] <uau> if there's an unrelated ABI bump of _libavformat_ then things break
[19:47:11] <Flameeyes> [which is what I asked you a 15 minutes ago]
[19:47:27] <Flameeyes> uau: "wow" you just came up with a _different_ situation than what I described
[19:48:27] <uau> different? not really IMO - the case your claimed to work actually doesn't without _additional_ assumptions about libavformat ABI not changing
[19:49:16] <Flameeyes> yes it is different, because I explicitly work in my "not so simple" example, .so.52
[19:49:34] <Flameeyes> yes it _is_ different if you end up mixing and matching more between sonames
[19:50:00] <Flameeyes> but whether that works or not, at all, is up for discussion IMHO
[19:50:50] <Flameeyes> also note I'm not expecting upgrades to always happen synchronously, so I'm _not_ advocating changing the interlib dependencies without keeping compatibility symbols
[19:50:53] <Sean_McG> yikes, library versioning
[19:51:16] <uau> well let's say that it was the "you'll have ... old libavformat.so.52 using it, new libavformat.so.52 not using it it" that was inaccurate then (you need the _additional_ assumptions for that to be true "if you drop it without ABI bump")
[19:51:56] <Flameeyes> uau: I wrote the bloody version numbers of both libraries out in full. THAT was your damn assumption "without ABI bump"
[19:54:14] <uau> come on, your line was "if you drop it without ABI bump, you'll have..."; i think it's reasonable to interpret the rest as what you claim would happen in the "without ABI bump" case
[19:55:05] <uau> so anyway, "drop it without ABI bump" is NOT safe if you just install new versions simultaneously
[19:56:23] <uau> you'd at still at least need to ensure that the ABI bump _does_ happen some time before (or at the same time as) libavformat ABI is next bumped
[19:56:42] <Flameeyes> *shrug* there isn't really any difference in "safety" between _removing_ and _adding_ interlib symbols
[19:57:31] <Flameeyes> so one way or another, the solution is *not* to have them, bump all the bloody sonames, and possibly either bump all of them at once, or start a realistic procedure for bumping them on a watefall model
[19:58:04] <av500> are there projects/distros that do not update all ff libs at the same time?
[19:58:25] <uau> how so? removing has the problem above; i don't immediately see how adding them could cause similar problems
[19:58:33] <Flameeyes> [i.e. you change the soname of the consumer libraries when the provider library changes soname]
[19:59:32] <Dark_Shikari> BBB: it looks to be duplicating information in the macro args...
[19:59:37] <Flameeyes> uau: your problem above happens only if one library renames a symbol, and the other one bumps ABI; the same applies in the case a new symbol is added to the former and used in the latter
[20:00:12] <Flameeyes> but I really have better things to do than trying to come up with theoretical situation caused by async upgrades (which are, by large, a bad thing to do)
[20:00:31] <uau> async? there was nothing "async" about the case i mentioned above
[20:01:47] <Flameeyes> it only happens if one of the ABI-slotted libraries doesn't get upgraded
[20:01:52] <Flameeyes> for me that's an async update
[20:01:52] <uau> i don't see how your addition problem case would work (unless you assume async for that case)
[20:03:07] <Flameeyes> av500: most binary distribution "slot" libraries by soname
[20:03:31] <uau> the problem i described can happen if you install newest major versions of all the libraries
[20:04:07] <uau> if you mean that leaving older sonames at their previous version would be "async" i don't agree with that - IMO that's something that _will_ happen in practice
[20:04:25] <Flameeyes> since – this is the part uau definitely got right – ffmpeg doesn't use the same ABI version for all libraries, it is possible that it it would mix a libavutil.so.50 (without the symbol), a libavformat.so.52 (using the symbol) and a libavformat.so.53 (not using it)
[20:04:56] <Flameeyes> but in that case to me that counts exactly as an async because libavformat.so.52 is not built against the latest libavutil.so.50
[20:05:48] <av500> Flameeyes: that answer confused me even more :)
[20:05:52] <uau> Flameeyes: eh? you CAN'T possibly build it against the "latest" version
[20:06:31] <Flameeyes> uau: sure you can — it is a mess, it is long, boring and generally speaking not worth the time spent on it, but you can
[20:06:42] <uau> since the only the newest ffmpeg version produces that libavutil, and it doesn't produce libavformat 52 any more
[20:07:09] <Flameeyes>  do agree that it's much better to have the versions all together at the next bump
[20:07:12] <uau> well if you mean hacking ffmpeg build system to do something completely different, maybe for those values of "can", but IMO that's pretty unrealistic
[20:07:12] <Flameeyes> *I do
[20:07:47] <BBB> Dark_Shikari: will look, sec
[20:08:25] <Flameeyes> uau: I don't think you have to go much far about the FFmpeg build system to do that.. pretty sure it is designed to allow that being done easily
[20:09:05] <uau> i do not believe it's designed to allow compiling libavformat against an older libavutil already found on the system
[20:09:44] <Flameeyes> other way around, older libavformat against new libavutil is what I meant
[20:10:01] <uau> and i haven't heard of distros doing anything like that in practice
[20:10:44] <uau> i'm pretty sure most would not consider that to be something normally needed to get packages to work
[20:10:46] <Flameeyes> ask that to siretart, but sincerely my solution is much easier (I don't deal with slots)
[20:11:14] <Flameeyes> tell me another multi-library, async ABI package han FFmpeg
[20:12:05] <BBB> Dark_Shikari: http://pastebin.com/PsR7W6Sc better?
[20:12:44] <Dark_Shikari>  FILTER_4TAP and FILTER_6TAP still seem redundant?
[20:12:49] <Dark_Shikari> can those not be eliminated given gcc macro syntax?
[20:13:21] <BBB> I can try inlining them under an if (HTAPS==6) or so
[20:13:30] <BBB> that's what the ppc optimizations do
[20:13:36] <BBB> should be same speed
[20:13:38] <BBB> let me check
[20:13:45] <Dark_Shikari> how about FILTER_##HTAPS##TAP?
[20:14:28] <uau> Flameeyes: the expectation is for all multi-library packages (so they would not have async ABI if there are such issues; your implicit assumption about the scope of the expectation - that it only applies if it's already know to have async ABI - is too narrow)
[20:14:46] <BBB> Dark_Shikari: does that work?
[20:14:48] <BBB> Dark_Shikari: let me try
[20:15:10] <Dark_Shikari> No idea
[20:15:43] <Flameeyes> uau: really we're debating theoretical versus real-world.. and I'm sick tired of theoretical right now
[20:15:54] <BBB> Dark_Shikari: trying... switching git branches takes forever
[20:16:41] <uau> Flameeyes: IMO the "without ABI bump" case above is a completely real-world thing
[20:18:04] <uau> if you remove "internal" symbols like that and then somewhat later bump ABI of the depending lib only, it's quite possible it _will_ break installations in practice
[20:18:29] <Flameeyes> uau: which is why I'm NOT suggesting removing them!
[20:18:46] <Flameeyes> I'm suggesting removing INTERNAL symbols and not INTERLIB symbols
[20:18:58] <Flameeyes> INTERLIB symbols should be migrated and then both libraries' ABIs bumped
[20:19:02] <Flameeyes> so that they can go away
[20:27:36] <BBB> Dark_Shikari: yeah, works
[20:27:41] <BBB> much easier
[20:32:58] <BBB> Dark_Shikari: please re-review, let's see if this is better
[20:33:00] <BBB> works for me
[20:33:09] <BBB> (only compile-tested of course)
[20:33:28] <Dark_Shikari> what?  you just resent the same mail
[20:33:36] <BBB> no it has a different attachment
[20:33:43] <Dark_Shikari> attachment?
[20:33:45] <Dark_Shikari> what attachment
[20:33:53] <BBB> wait it didn't
[20:33:54] <BBB> damnit
[20:34:45] <Dark_Shikari> Still no patch.
[20:35:01] <BBB> patch is inlined in the email
[20:35:18] <BBB> is that better?
[20:36:21] <BBB> ty
[20:36:39] <lu_zero> michaelni: are you eventually out of mind or you consider wishing suicide/death a normal behaviour?
[20:37:32] <michaelni> lu_zero, iam sorry this joke really misfired
[20:37:42] <michaelni> i just tried to be funny
[20:39:00] <CIA-38> ffmpeg: Ronald S. Bultje <rsbultje at gmail.com> master * r22893e10ae ffmpeg/libavcodec/vp8dsp.c:
[20:39:00] <CIA-38> ffmpeg: VP8: don't overread edges on fourtap MC.
[20:39:00] <CIA-38> ffmpeg: Fix C VP8 H+V MC functions which do two-dimensional 4/6-tap filters to
[20:39:00] <CIA-38> ffmpeg: not overread beyond their edges if the second filter is 4-tap, since
[20:39:00] <CIA-38> ffmpeg: the outer pixels aren't there anymore since
[20:39:00] <CIA-38> ffmpeg: 44002d8323023c35f51d523a7d305e45103ba7a1.
[20:39:28] <kierank> lu_zero: committing seppuku doesn't mean suicide literally.
[20:39:55] <mru> BBB: what does that change mean for asm versions?
[20:40:07] <mru> it's often _very_ useful to load a few pixels more than you need
[20:40:20] <mru> like loading a full 8-byte register even if you only need 5 pixels
[20:41:10] <michaelni> and besides trying to be funny, the recent events have been quite a bit stressfull
[20:43:24] <lu_zero> michaelni: you are using quite strong words and some are really ticking me off
[20:44:01] <michaelni> iam sorry
[20:44:17] <michaelni> i felt it would be funny when i write it
[20:44:33] <michaelni> but later realized it was a very bad idea especially now
[20:44:55] * michaelni uses strong words in jokes in real life too 
[20:45:12] * michaelni is rarely misunderstood
[20:45:41] <michaelni> people know iam joking when i wish them to .. well ...
[20:46:10] <BBB> mru: it's padded at the end of the buffer
[20:46:18] <BBB> mru: but these are reading before the buffer start
[20:46:35] <BBB> mru: which used to work fine by accident for fourtapfilters using sixtap-padding, but now doesn't work anymore
[20:46:50] <BBB> mru: so you can do the 5/8 by reading 3 extra pixels at the end, but not at the start
[20:47:03] <kierank> michaelni: are you going to join #x264dev
[20:48:27] <Compn> hey its michael1
[20:48:52] <Compn> oh i'm slow
[20:49:00] <kierank> hey it's Compn
[20:49:04] <Compn> hey its me
[20:49:17] * kierank is reminded to upload some more samples
[20:50:04] <Compn> upload them directly into samples
[20:50:09] <Compn> you know how to do it kierank ?
[20:50:10] <Compn> :P
[20:50:29] * kierank doesn't have login
[20:50:42] <Compn> the devel login ?
[20:50:55] <Compn> to access incoming
[20:51:04] <Compn> just cd samples instead
[20:51:18] <Compn> or you dont have that either ?
[20:51:35] <kierank> lemme see
[20:51:51] <Compn> if not i can pm it to you
[20:54:40] <michaelni> kierank, remind me 5 times a day and ill join in a month :)
[20:55:02] <kierank> ok
[20:55:13] <kierank> you seem to be of the same mindset of pengvado and patch reviews
[21:18:29] <elenril> jannau: ping
[21:18:59] <elenril> c34461b35b68ff1f3d04540e0279383c51be8cee/ 'mov: simplify mov_read_chapters() by using avio_get_str16be' is wrong version of the patch
[21:22:06] <elenril> also michaelni, what happened to the playlists patch?
[21:26:10] <spaam> kierank: haha. maybe pengvado have alot of things to do ;)
[21:27:15] <kierank> spaam: you've seen patch review on #x264dev
[21:27:25] <Sean_McG> still, I'm surprised the water from my fishtank doesn't help to keep the air humid
[21:27:29] <Sean_McG> ewps, ww
[21:28:07] <spaam> kierank: maybe. i dont follow that channel so much.. why? beacuse its in window 56
[21:28:35] <elenril> you people are a bad influence
[21:28:56] <elenril> now my window count got to 17
[21:29:39] <wbs> I try to keep it below 20, too, to be able to access them with numbers/letters in irssi ;P
[21:30:20] <Sean_McG> and here I am having trouble with 4.
[21:30:20] <spaam> wbs: i changed so i can have it up 28..
[21:30:31] <wbs> spaam: oh, how's that done?
[21:31:23] <spaam> wbs: /bind meta-a change_window 20
[21:31:30] <spaam>  /help bind
[21:31:34] <wbs> oh, nice :-)
[21:31:48] <spaam> yeah :)
[21:31:52] <mru> the default action of meta-a is nice though
[21:32:01] <mru> could go on another key of course
[21:32:30] * elenril tries meta-a
[21:32:36] <elenril> wow
[21:32:38] <elenril> nice
[21:32:45] <mru> goes to the next window with activity
[21:32:53] <elenril> yeah, already noticed
[21:33:00] <Sean_McG> hmmm how do I change the colours git uses?
[21:33:02] <mru> with priority to ones with a highlight
[21:37:10] <bilboed> Sean_McG, search for "color" in man git-config
[21:37:45] <Sean_McG> ah... yeah Google was my friend too
[21:50:31] * elenril summons somebody with commit powers
[21:51:05] <mru> elenril: which patch?
[21:51:27] <elenril> please revert c34461b35b68ff1f3d04540e0279383c51be8cee and apply the correct version
[21:52:01] <elenril> the correct one is Message-ID 20110123200301.GA18725 at zohar.khirnov.net
[21:52:02] <mru> and which is that?
[21:52:22] <mru> got a patchwork link?
[21:52:40] <elenril> sec
[21:52:54] <BBB> Re: [FFmpeg-devel] [PATCH 4/4] mov: simplify mov_read_chapters() by using avio_get_str16be
[21:53:38] <BBB> hm, it's off patchwork already
[21:53:44] <BBB> maybe it was marked as applied?
[21:54:21] <elenril> yeah, seems so
[21:55:25] <BBB> I can't find it in patchwork, I can find the wrong one and another one in that thread, but not this one
[21:55:39] <mru> so like this? http://git.mansr.com/?p=ffmpeg;a=shortlog;h=master;hp=origin/master
[21:56:57] <mru> or do just the total diff as a new commit?
[21:57:14] <mru> it's easier to see what's going on that way
[21:57:24] <elenril> i prefer the revert+reapply
[21:57:40] <elenril> but whatever you think is cleaner
[21:59:23] <mru> so what's in my 'master' branch now is correct?
[21:59:34] <elenril> yes
[21:59:40] <elenril> you could mention the reason for revert
[21:59:52] <mru> I thought I did
[22:00:03] <mru> you might need to reload for that
[22:01:01] <elenril> yeah, looks fine
[22:07:28] <CIA-38> ffmpeg: Mans Rullgard <mans at mansr.com> master * rc4f8765ac5 ffmpeg/libavformat/mov.c:
[22:07:28] <CIA-38> ffmpeg: Revert "mov: simplify mov_read_chapters() by using avio_get_str16be"
[22:07:28] <CIA-38> ffmpeg: This reverts commit c34461b35b68ff1f3d04540e0279383c51be8cee.
[22:07:28] <CIA-38> ffmpeg: The wrong version of the patch was committed.
[22:07:36] <CIA-38> ffmpeg: Anton Khirnov <anton at khirnov.net> master * r225b6d7fde ffmpeg/libavformat/mov.c:
[22:07:36] <CIA-38> ffmpeg: mov: simplify mov_read_chapters() by using avio_get_str16be
[22:07:36] <CIA-38> ffmpeg: It probably also fixes a memleak or two.
[22:07:36] <CIA-38> ffmpeg: Signed-off-by: Mans Rullgard <mans at mansr.com>
[22:12:53] <CIA-38> ffmpeg: Diego Elio Pettenò <flameeyes at gmail.com> master * rc6610a216e ffmpeg/ (186 files in 2 dirs):
[22:12:53] <CIA-38> ffmpeg: Prefix all _demuxer, _muxer, _protocol from libavformat and libavdevice.
[22:12:53] <CIA-38> ffmpeg: This also lists the objects from those two libraries as internal (by adding
[22:12:53] <CIA-38> ffmpeg: the ff_ prefix) so that they can then be hidden via linker scripts.
[22:19:12] <elenril> haha, ff_ffmeta
[22:19:16] <elenril> how meta
[22:19:29] <mru> how ff
[22:19:49] <saintd3v> ff_ffmeta_meta
[22:19:53] <Sean_McG> !!
[22:20:18] <Dark_Shikari> ff_ff_ffffmeta_ffmeta_meta
[22:20:21] <elenril> we should nominate this for some postmodernism award
[22:20:30] <elenril> Dark_Shikari: fffffffffffffffu
[22:21:25] <Flameeyes> mru: if we do set out to fix the bloody ABI, could we get an ABI bump for all the libs (minus avdevice, maybe filter?) before 0.7 release?
[22:21:40] <mru> Flameeyes: I'm all for it
[22:21:48] <mru> we'd get rid of piles of cruft in the process
[22:22:18] <spaam> Dark_Shikari: yo dawg. i heard you like ff
[22:22:37] <Flameeyes> oh crap.. I just updated the laptop for the past ten days.. and now a new chromium? :|
[22:23:09] <elenril> shouldn't we wait for -mt?
[22:23:26] <Sean_McG> definitely noticed that a lot of the software I've used in the past couple of years has updates *very often*
[22:23:30] <spaam> elenril: that can be in *drums*  0.8
[22:26:05] <lu_zero> Flameeyes: now parsing tex as well html-next?
[22:27:19] <Flameeyes> lu_zero: no clue...
[22:29:09] <lu_zero> _av500_: send me again your pcap dump please
[22:29:13] * lu_zero lost it
[22:31:33] <mru> BBB: ping
[22:31:42] <BBB> mru: pong
[22:32:11] <mru> why do the vp8 bilinear mc functions take an argument they don't use?
[22:32:45] <BBB> so the func prototype is identical to 6/4tap and we can use them interchangeably in the same calling code?
[22:32:55] <mru> that makes sense
[22:33:05] <mru> just making sure I'm not crazy
[22:33:10] <BBB> you're not :)
[22:33:35] <mru> and is the source guaranteed to have some horizontal padding?
[22:33:48] <mru> for the horizontal variants
[22:35:38] <BBB> not necessarily; this could be emu_edge or so where the source is quite literally just that exact block
[22:35:48] <mru> that's annoying
[22:35:54] <mru> can we please allocate some padding?
[22:36:04] <mru> up to a multiple of 8
[22:36:14] <BBB> for emu_edge I believe there's always 16 bytes padding
[22:36:39] <BBB> if you remind me I can add a if() for emu_edge so that it also copies into the temp buffer if there's no 16 pixels left on the bttomright
[22:36:44] <BBB> I wouldn't mind
[22:36:49] <BBB> emu_edge isn't that important anyway
[22:36:56] <mru> the padding doesn't need to be initialised
[22:37:02] <mru> just not fault on read
[22:37:04] <BBB> right
[22:37:24] <Sean_McG> I'd love to see someone test this on an IA64 :>
[22:37:32] <mru> Sean_McG: http://fate.ffmpeg.org/
[22:37:34] <BBB> fate has ia64
[22:37:37] <BBB> oh
[22:37:40] <Sean_McG> doh!
[22:37:47] * Sean_McG didn't know that
[22:38:09] <mru> why ia64 specifically?
[22:38:27] <Sean_McG> because they seem to be the ugliest when it comes to unaligned reads
[22:38:45] <mru> are they any worse than alpha or mips?
[22:39:08] <Sean_McG> good question... I've neither owned nor used either
[22:39:30] <mru> of the machines on fate, only x86, ppc, and armv7 support unaligned accesses
[22:39:38] <roxfan> ia64 is worse than about anything
[22:39:50] <mru> either it supports unaligned or it doesn't
[22:39:56] <mru> there are no levels
[22:40:04] <Sean_McG> fair point
[22:40:08] <BBB> av_default_get_buffer() always adds 16 bytes extra buffer
[22:40:18] <BBB> custom get_buffer implementations may not do that
[22:40:19] <BBB> not sure
[22:40:29] <mru> we should require that of them
[22:40:41] <BBB> feel free to add it
[22:40:46] <mru> doing two loads when one is enough is annoying
[22:40:48] <BBB> I think in practice we already do require it
[22:41:03] <mru> oh, there's lots of code that overreads a little
[22:41:05] <Sean_McG> is anybody able to contribute to fate? I have a SPARC running Solaris 10... it's not fast though
[22:41:32] <BBB> mru: exactly
[22:42:09] <mru> we need more obscure systems on fate
[22:42:19] <mru> if my octane weren't so noisy I'd put it on there
[22:48:20] <saintd3v> we need a Cray on there
[22:48:30] <Sean_McG> that would be neat
[22:48:38] * mru doesn't have one
[22:50:02] <kierank> http://ccore.sourceforge.net/
[22:50:27] * kierank wonders if n64 runs linux
[22:50:58] <roxfan> it's a mips, so should be possible
[22:51:27] <saintd3v> kierank: http://www.linux-mips.org/wiki/Nintendo_64
[22:51:31] <roxfan> at least uclinux
[22:51:41] <mru> ffmpeg works on uclinux
[22:51:47] <mru> for certain values of work
[22:52:02] <roxfan> hmm 4MB of ram
[22:52:12] <mru> not enough
[22:52:24] <Sean_McG> "oh shit I'm hitting swap"
[22:52:43] <mru> you can't have swap w/o mmu
[22:53:10] <roxfan> you can use overlays \o/
[22:53:19] <roxfan> good old dos had them
[22:53:39] <mru> and have fun swapping overlays if your mv points too far out
[22:53:46] <roxfan> hehe
[22:54:08] <roxfan> http://www.uclinux.org/pub/uCsimm/archive/0011.html  says 1MB should be enough, but this was in 2K
[22:55:53] <mru> 4M isn't enough for ffmpeg
[22:56:03] <mru> at least not all of it
[22:56:10] <mru> heck, the binary is bigger than that
[22:56:42] <mru> on the blackfin I've set aside 32M for ffmpeg bss+heap, and that's not enough for some tests
[22:59:48] <mmu> mru therefore you need me :p
[23:00:21] <mru> mmu: are you offering to run fate on haiku?
[23:03:41] <mmu> could be arranged
[23:03:48] <mmu> don't have time to install it yet
[23:04:27] <mru> if vmware fucking esxi didn't require a windows app to configure it, I'd set up some virtual machines
[23:04:45] <mmu> virtualbox ?
[23:04:50] <mmu> Haiku runs fine in vbox
[23:05:06] <Sean_McG> yeah I dunno what vmware is smoking not having a Linux binary for the vmware console
[23:05:11] <mru> I don't like virtualbox
[23:05:28] <mru> Sean_McG: there's no mac version either, I take it?
[23:05:43] <mru> there is an old macbook here, but no windows
[23:06:42] <Sean_McG> mru: aye, for Mac, there's Fusion but that's a desktop product
[23:06:47] * Sean_McG uses and likes Fusion
[23:07:27] <mru> I'm talking about the vsphere console or whatever it's called
[23:07:35] <Sean_McG> aye... I know what you mean
[23:07:42] <Sean_McG> I use vsphere at work
[23:08:07] <mru> there is the cli that runs on linux, but that only lets you make minor changes to existing vms
[23:08:31] <Flameeyes> mru: don't virt-manager allow at least partial control of those?
[23:08:36] <Sean_McG> vmrun would be more useful if it didn't require a plaintext password
[23:08:47] <Sean_McG> which makes it annoying to script
[23:08:50] <mru> Flameeyes: there's apparently no way whatsoever to create a new vm without the windows console
[23:08:56] <Flameeyes> terrific
[23:08:57] <Sean_McG> yup
[23:12:20] <mru> Flameeyes: any idea why vmware workstation/server/player ebuilds pull in half of gnome and other nasties?
[23:19:28] <{V}> I thought for vmware player one could use qemu-img to create a vmdk file and a text editor to copy-edit an existing vmx file to point to your new vmdk file. Are things different for the cli on linux? Or have things changed from the last time I played with vmware?
[23:19:40] <Flameeyes> mru: they used to depend on esd and other crap like that
[23:19:59] <kierank> mru: what's wrong with virtualbox
[23:20:13] <mru> kierank: last time I tried to use it, it locked up my computer
[23:20:15] <kierank> it's gotten very good lately
[23:20:27] <mru> and was generally annoying to use
[23:20:49] <Flameeyes> I agree with mru's dislike for vbox honestly
[23:21:31] <mru> I like the way vmware hosted emulators are structured
[23:21:36] <mru> it's clear what's what
[23:21:41] <mru> and there's no hidden state
[23:22:32] <mru> close the app and it's all gone
[23:39:49] <Compn> mru : hows download page coming ?
[23:40:12] <mru> you said 24h
[23:47:29] <Compn> yes but that wasnt my question
[23:47:42] <Compn> still have whatever hours left :P