[00:05:54] <CIA-43> ffmpeg: Georgi Chorbadzhiyski <gf@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@mansr.com> [00:39:50] <BBB> mru: can you send me a backtrace? [00:39:58] <BBB> mru: I don't have oenbsd@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@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@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.... 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@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@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@mansr.com> [15:37:59] <CIA-43> ffmpeg: Diego Elio Pettenò <flameeyes@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@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@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@mansr.com> [15:38:14] <CIA-43> ffmpeg: Justin Ruggles <justin.ruggles@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@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@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@mansr.com> [16:35:42] <CIA-43> ffmpeg: Diego Elio Pettenò <flameeyes@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@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/201101... [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@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@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@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@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@mansr.com> [22:12:53] <CIA-38> ffmpeg: Diego Elio Pettenò <flameeyes@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