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

[irc at mansr.com]

[00:08:20] <DonDiego> saste: we know that especially the timing was less than perfect
[00:14:26] <saste> DonDiego: but the main problem was not the timing but the fact that it was done like a conspiracy and with an overtake
[00:14:40] <saste> DonDiego: i'm not convinced that there was no way to do it in a different manner
[00:15:08] <saste> and I'm not convinced that this is going to save flamewars
[00:15:17] <saste> i can't just see the "hurry"
[00:15:37] <DonDiego> understandable
[00:15:44] <BBB> it wasn't exactly done in a hurry from our point of view
[00:15:53] <DonDiego> but i did not use that image of a "tidal wave" for nothing
[00:16:07] <DonDiego> this has been brewing for months actually
[00:16:22] <DonDiego> people have been disgruntled for a loooong time
[00:16:38] <DonDiego> it came to a boil with the mans incident
[00:16:48] <saste> i know... yes the problem is that that disgruntling wasn't manifest
[00:16:51] <DonDiego> and the failed attempt to make amends afterwards
[00:17:00] <saste> that was a decision of mans
[00:17:07] <saste> mans was always welcome
[00:17:18] <DonDiego> not by michael
[00:17:28] <saste> michael can't ban anyone
[00:17:33] <DonDiego> no?
[00:17:40] <saste> no
[00:17:55] <saste> and a leader can be changed
[00:18:03] <DonDiego> this has just happened
[00:18:08] <saste> or the leadership system can be changed
[00:18:15] <DonDiego> check
[00:18:39] <DonDiego> the way this was done, hmmm...
[00:18:58] <DonDiego> there surely is room for improvement
[00:19:04] <saste> do you perceive the problem of "legitimation"?
[00:19:08] <DonDiego> yes
[00:19:33] <saste> you say that a vote is not a solution but was the problem
[00:19:56] <DonDiego> i also perceive the problem of lack of empathy with michael's situation
[00:20:00] <saste> i want to know why it is not a solution and if you think that there is a better way to "solve" this problem
[00:20:20] <saste> i'm open to other solutions
[00:20:20] <DonDiego> was the disgruntlement really not noticeable?
[00:20:35] <DonDiego> with people leaving or dropping involvement massively?
[00:21:17] <BBB> saste: because a vote will leave half of the voters, the half whose side was not chosen, unhappy
[00:21:33] <DonDiego> we obviously made some mistakes in our outside communication
[00:21:54] <DonDiego> the motives of our actions and our plans are/were obviously less than clear
[00:21:55] <BBB> saste: say we do a vote, and given how many people signed off on our initial email, I suppose we would win. the vote would say "let's do things differently"... how would that make people like you less unhappy?
[00:22:01] <BBB> saste: the end situation is identical
[00:22:11] <BBB> saste: likewise if the vote turned out the other way
[00:22:21] <BBB> saste: we would be unhappy developers as now, drop our involvement and walk away
[00:22:35] <saste> i don't think everybody has to be happy for the result of a vote
[00:22:36] <BBB> in a vote, everyone loses
[00:22:42] <saste> i'm not happy now
[00:22:46] <saste> and no vote was cast
[00:22:52] <DonDiego> we were not happy before
[00:23:04] <DonDiego> so we forked
[00:23:09] <bryno> "our way or the highway" on both sides
[00:23:52] <Compn> so thats why no messages for 40 mins...
[00:23:53] <DonDiego> saying that a vote leaves devs unhappy does not mean that there is no friction loss with other ways to go about this
[00:24:15] <iive> DonDiego: you didn't fork, you took over.
[00:24:27] <bryno> what happens to the maintainers who sided with michael previously?
[00:24:54] <bryno> now they are disgruntled and mass leaving? :(
[00:25:18] <DonDiego> it is sad to come into such a situation in the first place
[00:25:21] <DonDiego> yes
[00:25:30] <Compn> iive : DonDiego /ignored you a while back methinks
[00:25:54] <Compn> just fyi...
[00:25:56] <bryno> what has fabrice's opinion been on this?
[00:26:13] <Compn> havent seen fabrice in years :P
[00:26:13] <DonDiego> but any which way you go about such a thing, there will always be some bitterness and friction loss
[00:26:17] <DonDiego> :-(
[00:26:35] <DonDiego> Compn: psshht, don't tell the troll
[00:26:47] <bryno> troll?
[00:27:04] <saste> i have no problem at accepting a govern for which I didn't vote and which i dislike at most
[00:27:10] <DonDiego> bryno: we have a household troll in this channel, his nick is iive ...
[00:27:13] <saste> indeed this is what I did in the last ten years
[00:27:20] <DonDiego> :)
[00:27:23] <bryno> ok.
[00:27:56] <DonDiego> saste: nobody is imposing a government on you nor on anybody else
[00:28:21] <saste> i'm aware of it
[00:28:39] <bryno> out of curiosity, how was michael put into the leadership position in the first place?
[00:28:54] <saste> i still want to believe that we can still have just one ffmpeg... and the split can be fixed in an acceptable way
[00:29:01] <Compn> DonDiego : i think some people are upset that the git.videolan is not accessible on the download page of ffmpeg.org . i know someone said they were going to publish all forks, so maybe its included in that list ?
[00:29:06] <mru> bryno: he declared himself leader over and over again
[00:29:09] <iive> bryno: he took the project over after fabrice leaft.
[00:29:11] <mru> eventually people started believing it
[00:29:30] <bryno> how long ago was that?
[00:29:34] <iive> i think he is the oldest developer in it.
[00:29:41] <Compn> 2002/2003 maybe
[00:29:52] <mru> a little later iirc
[00:30:17] <Compn> could be
[00:31:08] <mru> my first patches are from 2002
[00:31:40] <Compn> DonDiego : this might be part of the 'take over' argument, that if git.ffmpeg.org is a fork, then both repos would be on the download page... (not that i'm saying one way or another, i'm neutral at this point :P)
[00:31:41] <mru> most of the others devs from that time are gone
[00:32:06] <mru> Compn: then let's add all known repos to the page
[00:32:13] <Compn> surely
[00:32:21] <mru> with a brief description of each
[00:34:15] <Compn> sounds good
[00:34:24] * Compn sneaks away without writing xml code
[00:49:15] <lu_zero> Compn: say html code =P
[00:55:16] <BBB> lu_zero: reviewing 7/7 now...
[00:55:22] <BBB> almost done
[00:55:33] <BBB> Dark_Shikari: ping
[00:56:52] <lu_zero> BBB: I used that set to play with send-mail and rebase ^^;
[00:57:11] <lu_zero> most of this code should disapear in the next 8 patches (more or less)
[00:58:36] <Dark_Shikari> BBB: pong
[00:59:27] <BBB> please review my patch in the repy to jumpyshoes' patch
[01:01:23] * Compn afk
[01:04:03] <Dark_Shikari> If it's rare, isn't a branch better than a cmov?
[01:04:49] <Dark_Shikari> But it's a nice cleaner approach, I like it
[01:04:50] <mru> how can a branch ever be better than cmov?
[01:04:59] <Dark_Shikari> cmov is 1 cycle, a branch is zero cycles if predicted perfectly
[01:05:04] <Dark_Shikari> er, cmov is at least 1 cycle.
[01:05:08] <Dark_Shikari> More on shittier CPUs.
[01:05:17] <Dark_Shikari> 6 on a pentium 4, but we really don't want to care about that.
[01:05:29] <mru> but every branch consumes branch predictor resources
[01:05:46] <Dark_Shikari> Oh, you mean in terms of the overall program
[01:05:52] <Dark_Shikari> Ah, I see.
[01:05:55] <Dark_Shikari> That's much harder to measure
[01:06:11] <mru> adding a branch anywhere can cause another one to mispredict
[01:07:10] <mru> maybe I should look at the patch before speculating further...
[01:07:41] <BBB> Dark_Shikari: it's unlkely, it's ever only untrue for edges, which is unlikely
[01:08:05] <mru> how often is the code in question run?
[01:08:31] <BBB> so if a branch is cheap enough, then I could add sth. like test r1, r1 jz end_of_func lea r1, default_func .label rest_of_code RET .end_of_func lea r1, special_case jmp rest_of_code label
[01:09:21] <BBB> mru: most programs use dc prediction from what I can see... but basically pred in general is once per MB (or 16x for 4x4 mode, and so on for 8x8), plus twice for chroma
[01:09:41] <BBB> Dark_Shikari: do you think the branch is better as long as the default case is branchless as I just said?
[01:09:49] <DonDiego> i'm fine with adding multiple git trees to the download page or whereever btw
[01:09:52] <Dark_Shikari> mru: probably 10-20% of the time in i8x8 blocks
[01:10:02] <Dark_Shikari> given typical likelihood, that would be... *calculates*...
[01:10:19] <Dark_Shikari> ~0.5% of 8x8 blocks will use this pred mode.
[01:10:30] <Dark_Shikari> So it's not worth optimizing for speed if it'll poison the branch predictor.
[01:10:37] <mru> question is, how much happens in between each encounter with this branch/cmov?
[01:10:53] <Dark_Shikari> I like BBB's approach, run with it
[01:11:10] <mru> will the branch predictor even retain the history between each time?
[01:11:27] <Dark_Shikari> Modern x86 CPUs have a freaking huge branch predictor, but let's stick with cmov
[01:11:48] <mru> roughly how huge?
[01:11:51] * mru is curious
[01:12:37] <BBB> cmov is ok then?
[01:12:38] <BBB> ok
[01:13:20] <BBB> mru: I feel incompetent to review the LOCAL_ALIGNED patch because I don't understand what it fixes... can you provide some example of what goes wrong with the current approach? probably if I see 1 line of code where it would fail (I know the rule that vararg macros need more args then defined in the macro def), I'd approve it
[01:13:37] <Dark_Shikari> mru: according to a technical article on the topic
[01:13:39] <Dark_Shikari> "While Intel did not disclose the number of targets for Nehalem, the P4 BTB had 4K targets, and it seems reasonable that Sandy Bridge has 8K-16K."
[01:16:17] <mru> and the history buffer?
[01:17:45] <Dark_Shikari> It only says that it's now bigger, doesn't say how big it is.
[01:18:04] <mru> a direct branch doesn't use the target buffer
[01:18:08] <Dark_Shikari> Ah
[01:18:19] <Dark_Shikari> I know in the Core 2 they hashed branch information.
[01:18:19] <mru> since the target is known from the instruction
[01:18:28] <Dark_Shikari> i.e. created a hash table of history + branch combinations
[01:18:36] <mru> arm does something similar
[01:18:49] <Dark_Shikari> This stuff is pretty black magic, they don't document the details.
[01:18:50] <mru> they throw the pid in the mix too
[01:19:05] <Dark_Shikari> Which is unusual; most Intel and AMD stuff is documented in pretty heavy detail.
[01:19:12] <Dark_Shikari> Branch prediction... they just give you a few hints on what not to do.
[01:19:19] <Dark_Shikari> Like "don't put more than this many branches in 16 bytes of instructions"
[01:19:29] <Dark_Shikari> I think AMD says not more than 4 or something retardedly large.
[01:20:30] <uau> BBB: about all the current LOCAL_ALIGNED uses look illegal
[01:21:20] <mru> uau: explain
[01:21:45] <uau> mru: i mean the current ones (which you're trying to fix i assume)
[01:22:06] <mru> yes, most of them have too few args
[01:22:11] <mru> the patch fixes it
[01:22:22] <mru> I came across a compiler that choked otherwise
[01:22:49] <uau> BBB: the last from 'git grep LOCAL_ALIGNED':    "LOCAL_ALIGNED_16(float, sumd, [17]);" - this is invalid because "#   define LOCAL_ALIGNED_16(t, v, s, ...)" means at least 4 arguments are required
[01:22:51] <mru> and, yes, I made a mistake writing those macros the first time
[01:23:07] <BBB> Dark_Shikari: please ok it on-list if it looks ok to you, and I'll commit
[01:23:18] <BBB> mru: I see, makes sense then
[01:23:18] <BBB> ok
[01:23:22] <BBB> let me ok on-list
[01:23:41] <mru> uau: feel free to comment on the patch if you like
[01:23:51] <mru> this is the kind if thing you usually have a handle on
[01:24:17] <BBB> right, any person considering himself/herself knowledgeable should help getting this sort of stuff done
[01:24:24] <BBB> the more eyes, the better
[01:24:39] <mru> so I'd appreciate a comment from uau
[01:25:24] <Dark_Shikari> done
[01:26:42] <DonDiego> ok, i'm falling asleep here
[01:26:43] <DonDiego> gnite
[01:30:57] <BBB> uh, I'm no good at this
[01:31:03] <BBB> "fatal: The remote end hung up unexpectedly"
[01:31:35] <Dark_Shikari> same problem I had
[01:31:50] <BBB> did you fix it?
[01:31:52] <Dark_Shikari> yes
[01:31:57] <Dark_Shikari> 1) in your ~/.ssh/config
[01:31:59] <Dark_Shikari> add
[01:32:04] <Dark_Shikari> Host *.ffmpeg.org
[01:32:07] <Dark_Shikari>     Port 2222
[01:32:15] <BBB> I had that
[01:32:19] <BBB> I couldn't check out w/o it
[01:32:25] <Dark_Shikari> in your .git/config
[01:32:30] <Dark_Shikari>        url = git at git.ffmpeg.org:ffmpeg.git
[01:32:35] <Dark_Shikari> should be there under remote "origin"
[01:33:18] <BBB> got it
[01:33:43] <BBB> ok, I'm outdated
[01:33:58] <mru> then you pull --rebase
[01:34:30] * mru suggests doing git config branch.master.rebase true
[01:35:19] <BBB> let's do it manually for now
[01:35:24] <CIA-29> ffmpeg: Ronald S. Bultje <rsbultje at gmail.com> master * rb9c7f66e6d ffmpeg/libavcodec/x86/h264_intrapred.asm:
[01:35:24] <CIA-29> ffmpeg: Fix horizontal/horizontal_up 8x8l intra prediction x86/simd functions.
[01:35:24] <CIA-29> ffmpeg: The original functions did not work correctly for edge pixels, e.g.
[01:35:24] <CIA-29> ffmpeg: when CODEC_FLAG_EMU_EDGE is set, leading to corrupt output in e.g. VLC.
[01:35:24] <CIA-29> ffmpeg: Based on a patch by Daniel Kang <daniel d kang gmail com>.
[01:35:24] <BBB> I'll break tons of stuff in the process anyway
[01:35:25] <CIA-29> ffmpeg: Signed-off-by: Ronald S. Bultje <rsbultje gmail com>
[01:35:28] <BBB> \o/ it worked
[01:37:49] <mru> BBB: so what did this fix?
[01:38:05] <mru> in terms of observed breakage
[01:38:10] <Dark_Shikari> h264 decode with emu edge
[01:38:13] <Dark_Shikari> vlc was crashing
[01:38:40] <BBB> crash or (more likely) corrupt output in vlc
[01:38:48] <BBB> the output isn't correct yet, but it's less corrupt
[01:38:57] <BBB> there's another bug
[01:39:11] <BBB> I don't think it's dc, I think it's h264.c which loads the wrong var in chroma_pred_mode
[01:43:46] <uau> mru: i think it would be more readable to do something like this:
[01:43:47] <BBB> hm... the ref is wrong
[01:43:48] <BBB> omg
[01:43:49] <uau> #define LOCAL_ALIGNED_8_INTERNAL(t, v, s, o, ...) DECLARE_ALIGNED(8, t, v) s o
[01:43:49] <uau> #define LOCAL_ALIGNED_8(t, v, ...) DECLARE_ALIGNED_INTERNAL(t, v, __VA_ARGS__,,)
[01:44:16] <uau> hmm wrong macro name there
[01:44:35] <uau> last one should be LOCAL_ALIGNED_8_INTERNAL of course
[01:45:28] <BBB> Dark_Shikari: I don't think ffh264 handles streams where chroma pred mode is not coded in the stream
[01:45:43] <BBB> it just leaves the predmode to the default (zero), which is of course wrong for edge pixels
[01:45:52] <Dark_Shikari> You mean 4:0:0 streams?
[01:46:11] <BBB> I think the stream has color
[01:46:13] <BBB> or is supposed to have
[01:46:18] <Dark_Shikari> "chroma pred mode is not coded" == "4:0:0
[01:46:27] <BBB> check h264-conformance/FRext/HPCAMOLQ_BRCM_B.264
[01:47:00] <BBB> ok, so I guess we don't handle 4:0:0 streams then, because chroma prediction does run and it has tons of valgrind errors because we run dc on edge blocks
[01:47:34] <Dark_Shikari> Yes we do
[01:47:51] <Dark_Shikari> if there's a bug, fix it
[01:47:58] <Dark_Shikari> I posted a patch  on the ML the other day to make x264 generate 4:0:0 streams
[01:48:01] <Dark_Shikari> for testing
[01:48:11] <BBB> that stream above is 4:0:0 in the reference samples
[01:48:25] <BBB> that's enough for testing for now :-p
[01:50:45] <BBB> the only format I see being output is YUVJ420 btw
[01:50:56] <BBB> where's the 400 handling code?
[01:53:19] <Dark_Shikari> It outputs 4:2:0
[01:53:26] <Dark_Shikari> even when it's 4:0:0
[01:53:29] <Dark_Shikari> but it _supports_ it
[02:06:31] <mru> uau: thanks, that's much better
[02:08:30] <mru> I'll test it with the picky compiler tomorrow just to be sure
[02:08:57] * mru doesn't want to start messing with old sgi machines at this hour
[02:16:39] <BBB> Dark_Shikari: hahaha no it doesn't :-p
[02:16:47] <BBB> dark_shikari: ffplay h264-conformance/FRext/HPCAMOLQ_BRCM_B.264
[02:18:01] <Dark_Shikari> What do you mean, it doesn't?  I tested it the other day.
[02:18:04] <Dark_Shikari> And I even fixed a bug in it.
[02:18:07] <BBB> it's green
[02:18:15] <Dark_Shikari> Er... and?  Look at the Y channel.
[02:18:28] <BBB> it shoudl use dc_128, not dc prediction
[02:18:30] <Dark_Shikari> If you want to fix it, make it output Y8 instead of yuv420p
[02:18:30] <BBB> it uses dc prediction
[02:18:37] <Dark_Shikari> It shouldn't touch chroma at all
[02:18:41] <BBB> I agree
[02:18:45] <Dark_Shikari> This is actually on my list of things to fix for Gaikai.
[02:18:49] <BBB> but you agree that the u/v channels are wrong right? :-p
[02:18:54] <BBB> ah, ok, I'll not touch it then :-D
[02:19:00] <Dark_Shikari> No, you should feel free to fix that.
[02:19:05] <BBB> hehe </lazy>
[02:19:07] <Dark_Shikari> I doubt I'll completely be able to eliminate all references to chroma.
[02:19:07] <BBB> ok, I will
[02:19:22] <BBB> but anyway, I'm glad we agree it's broken
[02:19:27] <mru> BBB: is that what's called chromatic aberration?
[02:19:52] <BBB> I thought that was a microscope term
[02:20:00] <BBB> that was just on the midterm of the class that I lecture
[02:20:06] <BBB> anyway, probably not what you meant
[02:21:03] <mru> it's a general lens term
[02:33:02] <saintdev> someone should probably reply to MN's olive branch
[02:33:28] <mru> olive branch?
[02:35:13] <saintdev> http://thread.gmane.org/gmane.comp.video.ffmpeg.devel/124020
[02:39:13] <BBB> there was no patch posted
[02:40:21] <bryno> lol, that's the reply to the 'olive branch'
[02:40:51] <BBB> oh rly?
[02:42:58] <bryno> yes.
[02:44:23] <BBB> weird, I don't see a reply in my mail client
[02:45:56] <bryno> i think we're in irc
[02:46:13] <mru> there is no reply
[02:46:37] <bryno> bah. nevermind.
[02:58:22] <CIA-29> ffmpeg: Michael Niedermayer master * r45c889a3ad ffmpeg/libavfilter/libmpcodecs/ (vf_detc.c vf_divtc.c vf_palette.c): Add #define _BSD_SOURCE where mplayer is not C99.
[02:58:23] <CIA-29> ffmpeg: Michael Niedermayer master * r3be78f7ecd ffmpeg/libavfilter/libmpcodecs/ (libvo/video_out.h mp_image.c mp_image.h vf.h): Hack libmpcodecs to make it buildable.
[02:58:49] <CIA-29> ffmpeg: Michael Niedermayer master * re4852fb38d ffmpeg/libavfilter/libmpcodecs/ (75 files in 2 dirs): Add MPlayers libmpcodecs, this will be needed for our libavfilter wraper for it.
[02:59:01] <CIA-29> ffmpeg: Michael Niedermayer master * r3aa43978da ffmpeg/libavfilter/vf_mp.c: Add libmpcodecs wrapper for libavfilter, still disabled
[02:59:55] <CIA-29> ffmpeg: Michael Niedermayer master * r8e45c103e9 ffmpeg/libavfilter/libmpcodecs/ (vf_delogo.c vf_eq.c vf_hue.c): Remove dependancy of m_option & m_struct from libmpcodecs.
[02:59:55] <CIA-29> ffmpeg: Michael Niedermayer master * r4d46361425 ffmpeg/libavfilter/libmpcodecs/vf_pullup.c: Avoid dependancy on global variable verbose in libmpcodecs/vf_pullup.c
[03:00:06] <CIA-29> ffmpeg: Michael Niedermayer master * rfd4c59b519 ffmpeg/libavfilter/ (Makefile allfilters.c): Enable libmpcodecs support.
[03:00:21] <CIA-29> ffmpeg: Michael Niedermayer master * r61d7f8fed4 ffmpeg/libavfilter/vf_mp.c: Warn about vf_mp
[03:00:57] <CIA-29> ffmpeg: Michael Niedermayer master * ra61b0df708 ffmpeg/libavfilter/libmpcodecs/mp_image.h: Add ASMALIGN() hack to patch around its recent removial from configure
[03:04:22] <Compn> bryno : iirc stefano is libavfilter maintainer, and he is not currently part of neuteam
[03:05:16] <mru> jannau: can we at least have the videolan cia messages tagged with something to distinguish them from ffmpeg.org?
[03:06:07] <Compn> i'm guessing no, but would git.ffmpeg allow libmpcodecs in ?
[03:06:17] <mru> of course not
[03:06:27] <Compn> just thought i'd ask :P
[03:09:39] <pengvado> several of the recent commit messages contain a "Signed-off-by:", and some of them give the same name there as both the author and committer fields.
[03:09:42] <pengvado> I can understand separating signed-off from committer, if the committer is acting as patch-monkey rather than as reviewer, but why would signed-off ever be equal to author?
[03:18:00] <BBB> uh... that's my mistake, I didn't know we shouldn't if they're different
[03:18:07] <BBB> I'm new to the git way of doing things
[03:18:28] <mru> linux kernel requires one on every commit
[03:20:16] <astrange> perian 1.2.2 ran out of bugs. no time to change the svn externals to a git checkout script, good thing they've hardly diverged yet
[03:24:35] <mru> ran out of bugs?
[03:25:20] <astrange> it's got release milestones and everything
[03:25:54] <mru> bugs are in unlimited supply
[03:25:59] <mru> one cannot run out
[03:26:27] <Plorkyeran> ran out of known bugs
[03:26:52] <mru> so open a random source file and stare at it
[03:26:54] <mru> there will be bugs
[03:26:58] <astrange> well, i haven't imported the h264 crash fix they were talking about up there
[03:27:19] <astrange> but it's run past what anyone cares to fix
[03:33:06] <uau> pengvado: the kernel documentation says "The sign-off is a simple line at the end of the explanation for the patch, which certifies that you wrote it or otherwise have the right to pass it on as a open-source patch."
[03:40:44] <BBB> uau: ianal bullcrap disclaimer but that line has as much legal meaning as the standard email footers that companies put down their emails
[03:42:17] <16SAAYUNZ> The idea is to know who to put on the stand when someone sues you for copyright infringement
[03:43:13] <saintdev> peloverde: you're seriously keeping that nick?
[03:43:25] <16SAAYUNZ> maybe, we'll see
[03:43:30] <saintdev> LOL
[03:59:37] <BBB> wait that's peloverde?
[04:00:07] <BBB> omg he has ops, it really is peloverde
[04:03:07] <saintdev> hurr, lol
[04:05:19] <16SAAYUNZ> Has anyone tested adpcm_ms-in-mov recently? It seems very broken
[04:06:43] <saintdev> all you math peoples: potential proof P=NP (this time with source code!) http://romvf.wordpress.com/2011/01/19/open-letter/
[04:09:46] <16SAAYUNZ> no demuxer except libavf seems to like the output
[04:10:11] <16SAAYUNZ> (segfaults gstreamer; silence with videolan and quicktime)
[04:10:22] <BBB> muxer? might not be tested very much
[04:10:24] <BBB> :(
[04:10:36] <BBB> but gst segfaults :-p
[04:11:08] <16SAAYUNZ> I'm going to be nice and send them a bug report
[04:11:27] <16SAAYUNZ> and then if my gstreamer experience holds it will rot in bugzilla.gnome.org
[04:27:18] <BBB> :-p
[04:29:19] <16SAAYUNZ> we let a lot of bugs rot too so I shouldn
[04:29:24] <16SAAYUNZ> 't complain too much
[04:34:09] <BBB> 16SAAYUNZ: please change your nick, I can't take you seriously with all those caps in your nick
[04:34:14] <BBB> it's like a scriptkiddie
[04:34:19] <BBB> :-p
[04:36:30] <saintdev> should have changed it to 16aayunz
[04:37:34] <Jumpyshoes> ;D
[04:37:47] <saintdev> oops, missed an s
[04:43:09] <BBB> peloverde_: thank you :)
[04:43:11] <astrange> i kept reading it as "16 saiyans"
[04:43:13] * BBB goes sleep
[04:43:23] <BBB> wat does that nick mean anyway
[04:43:31] <saintdev> it was bugging BBB so much he couldn't sleep o.O
[04:43:37] <BBB> true
[04:43:47] <BBB> well, h264 fate failing also bugs me
[04:43:48] <peloverde_> it means freenode nick collision loves me
[04:45:09] <peloverde_> fate isn't very useful right now seeing as half the configs point in different places
[04:46:09] <BBB> indeed
[04:46:44] * BBB hopes we can get a win64 box somewhere for fate...
[04:50:27] <drv> i could probably run one, would need to configure mingw-w64 first though
[05:14:16] <elenril> morning
[05:14:43] <Jumpyshoes> morning~
[05:14:50] * elenril reads all the drama
[05:15:36] <Jumpyshoes> ;)
[05:22:46] * elenril sighs
[05:23:04] * elenril still thinks the announcement should've been made more clear
[05:32:45] * elenril wonders wtf is the point of get_strz returning the buffer which was passed to it instead of number of bytes read
[05:35:06] <andyzweb> will svn.ffmpeg.org become a svn mirrior of git.ffmpeg.org as part of the new source control changes?
[05:47:07] <_av500_> no
[05:48:46] <andyzweb> so if I want to keep current I will have to switch to git?
[05:48:54] <_av500_> yes
[05:49:03] <_av500_> just let svn go
[05:49:37] <andyzweb> git pull, git pull everywhere
[05:49:59] <elenril> git is great
[05:50:44] <andyzweb> I agree, I will just have to get my people to switch over to git, they are all stuck in the windows world.
[05:52:48] <peloverde_> anyone have a gstreamer-0.10-plugins-good more recent than 0.10.25 and willing to test something for me real quick?
[05:54:27] <saintdev> 0.10.23 here :/
[05:54:33] <j45> i have 0.10.25 from ubuntu 10.10
[05:54:49] <elenril> 0.10.26.3-1 in debian experimental
[05:55:02] <saintdev> peloverde_: which plugin are you looking for specifically ?
[05:55:08] <peloverde_> qtdemux
[05:55:40] <peloverde_> I want to see if FFmpeg muxed adpcm_ms crashes a more recent version than what I have
[05:56:41] <saintdev> hmm, seems gentoo doesn't split that one out
[05:57:11] <elenril> peloverde_: so what should i test
[05:58:29] <peloverde_>  /incoming/ff_adpcm_ms.mov.bz2
[05:59:29] <elenril> what was the server name?
[06:00:03] <peloverde_> samples.mplayerhq.hu
[06:00:03] <elenril> nvm, got it
[06:00:32] <peloverde_> gst-launch-0.10 -f --gst-debug=qtdemux:3 filesrc location=ff_adpcm_ms.mov ! decodebin
[06:03:09] <elenril> http://pastebin.com/fYQ749bU
[06:03:18] <elenril> want a backtrace or something?
[06:03:50] <peloverde_> that's pretty much all I need
[06:03:53] <peloverde_> I have the smae crash
[06:04:03] <peloverde_> I just wanted to make sure they hadn't fixed it yet
[06:40:46] <peloverde_> anyone have a sample of MS ADPCM muxed by quicktime
[06:52:10] <ch3rryc0ke> Hello-- I've built ffmpeg version 26326, and I'm wondering if I need to manually install the RTP H264 patch talked about in this thread: https://lists.mplayerhq.hu/pipermail/ffmpeg-devel/2010-June/090821.html
[06:52:22] <ch3rryc0ke> Was it ever committed?
[07:03:15] <astrange> peloverde: i can make one
[07:03:45] <peloverde_> that would be awesome
[07:04:36] <astrange> http://astrange.ithinksw.net/ffmpeg/scatter.wav.mov resaved from the sample wav on mphq
[07:05:09] <KotH> moin
[07:05:20] <peloverde_> ch3rryc0ke: supposedly it was commited in june
[07:05:26] <KotH> jannau: hmm?
[07:05:36] <peloverde_> astrange: thanks
[07:05:40] <thresh> how do you guys plan using one ML for two projects? ;o
[07:05:53] <ch3rryc0ke> peloverde_: thanks!
[07:07:00] <elenril> thresh: we'll pretend the other is not there
[07:07:21] <thresh> pfft
[07:07:32] <thresh> .procmailrc ftw ;P
[07:07:35] <elenril> it has many advantages
[07:07:59] <elenril> michael might review our patches assuming they're meant for his part of the ML ;)
[07:08:01] <thresh> yay for people wanting their patches to get in
[07:08:04] <thresh> haha yeah
[07:19:27] <jannau> KotH: http://twitter.com/bash_vi/statuses/27828217876324352
[07:21:49] <jannau> mru: I've nothing to do with the cia notifies from git.v.o
[07:22:52] <j-b> good moroning
[07:34:22] <cartman> moin
[07:54:20] <spaam> God morgon :)
[07:54:28] <cartman> elow spaam
[07:54:36] <spaam> wzup?
[07:56:13] <cartman> messing with Android
[07:56:58] <cartman> I/OMAPFBPLAY( 3286): Decoder '(null)' not found.
[07:57:00] <kierank> TurkDroid (tm)
[07:57:01] <cartman> is the summary :D
[07:57:12] <cartman> kierank: there is a TrDroid project for real :D
[08:00:10] <spaam> cartman: kierank made it
[08:00:25] <cartman> spaam: whoa :P
[08:00:44] <spaam> cartman: he is a wannabe turk ;)
[08:00:57] * cartman is The Turl
[08:00:59] <cartman> Turk too
[08:01:00] <cartman> :P
[08:01:38] <wbs> av500: about the rtsp/mpegts/latm stream you mentioned yesterday, is the sample still up for grabbing somewhere?
[08:03:04] <peloverde_> hmm, fixed gstreamer vlc is still misbehaving
[08:04:11] <peloverde_> and if i remux through wav it's all kinds of messed up
[08:16:10] <av500> wbs: yes, the pcap stuff is still there and the ts to
[08:16:17] <av500> as said, ff plays the ts fine
[08:16:23] <av500> but fails to play the live stream
[08:16:58] <kierank> av500: "fine"
[08:17:01] <kierank> it blocks like crazyt
[08:17:11] <av500> :)
[08:17:13] <av500> well yes
[08:17:23] <av500> but i dont want to debug bad wifi
[08:17:44] <av500> I also got a clean stream from the free.fr headend
[08:17:48] <av500> that plays fine too
[08:17:55] <av500> only over rtsp it fails to have audio
[08:18:02] <wbs> av500: hmm, I only saw an url to 0x.deadba.be/~tom/freebox_dump.tar.gz which gives me 404 now
[08:18:20] <av500> yes, its a dsl upload thus slow
[08:18:25] <av500> I can robot it for you
[08:28:25] <wbs> robot it?
[08:29:04] <cartman> av500 is a robot
[08:29:10] <cartman> mankind's life is at stake
[08:30:21] <j-b> robots are nicer than human
[08:30:25] <av500> wbs: we have a webservice that we use to up/download stuff with 3rd parties
[08:30:34] <av500> and its called "robot" :)
[08:30:37] <av500> so we robot things
[08:30:41] <wbs> av500: I see :-)
[08:31:05] <spaam> ISO Media, MPEG v4 system, part 12 revision  .. is that a .mp4 file?
[08:31:21] <kierank> yes
[08:31:34] <spaam> great :)
[08:31:50] <av500> spaam: beware, its patented!
[08:31:52] <spaam> i saw a file with  ismv extenstion.
[08:32:10] <peloverde_> ok, copying adpcm from wav to mov was always broken
[08:32:23] <kierank> spaam: maybe some weird varianr
[08:32:33] <spaam> kierank: blame netflix :)
[08:33:22] <j-b> ismv is Microsoft smooth streaming
[08:33:43] <spaam> maybe i need to download more then 1.7mb of the file
[08:34:04] <av500> spaam: you need to download it smoothly
[08:34:09] <j-b> BBB: awesome... I can release now...
[08:34:26] <spaam> av500: i will try.  i hope wget can do it
[08:34:33] <av500> --smooth
[08:36:43] <spaam> great.
[08:36:48] <spaam> i found this: http://pastie.org/private/kx8zalnm4rgwyl8ivto99w
[08:37:19] <spaam> about that .ismv file :)
[08:37:24] <j-b> 52.103.1 << isn't that a bit a weird numbering
[08:37:36] <thresh> why?
[08:37:41] <av500> is that dewey decimal?
[08:43:20] <kierank> av500: nah, library of congress
[08:58:15] <av500> elenril: if I have a format that supports having images (as stream) inside, how would I mux a jpg into the id3v2 tag of that same format?
[08:58:41] <elenril> av500: easy, we only write id3v2 into mp3s =p
[08:58:52] <elenril> everything else is an evil hack
[08:58:53] <av500> harhar
[08:58:59] <elenril> (actually, id3v2 is an evil hack)
[08:59:24] <av500> elenril: I have nice asfs with id3v2 and album art inside
[08:59:39] * elenril burns av500 with fire
[08:59:47] <elenril> we might want to support reading such files
[08:59:53] <elenril> but certainly not muxing them
[08:59:59] <av500> elenril: I will work on that :)
[09:00:32] <av500> elenril: but my question is still valid
[09:00:42] <av500> album art can be outside of od3v2
[09:00:45] <av500> id3v2
[09:01:08] <elenril> my question is still valid too
[09:01:16] <elenril> why would you want to do that
[09:01:25] <av500> do what? add album art to a flac file?
[09:01:28] <av500> or ogg
[09:01:30] <av500> or mp4
[09:01:39] <elenril> if the format supports proper images, why write it into id3
[09:02:10] <av500> I removed the id3v2 from the question
[09:02:49] <av500> I have a format that supports having images (as stream) inside, how would I mux a jpg into the metadata part of that same format?
[09:03:16] <elenril> why would you want to do that
[09:03:33] <av500> ok, so album art will be read only...
[09:03:54] <av500> I put mine into the folder anyway :)
[09:04:09] <av500> saves me from retagging every file
[09:06:51] <elenril> well suggestions welcome
[09:06:58] <elenril> make it an avoption or something
[09:07:09] <elenril> (patches welcome of course =p )
[09:09:42] <av500> :)
[09:10:58] <kshishkov> bink-b support patch is extremely welcome too
[09:11:29] * elenril hopes kshishkov is not working in wavpack multichannel in the meantime
[09:12:10] <kshishkov> elenril: don't worry, I don't work at all meantime (except at $DAYJOB)
[09:12:31] * elenril should get a $DAYJOB so he can not work on stuff
[09:13:18] <cartman> av500: would uyou happen to know magic-head.S and magic-tail.S? Need some help debugging it.
[09:13:34] <kshishkov> elenril: well, once I had dayjob, was working on my bachelor degree thesis and REing RV3 all in the same time
[09:14:02] <av500> cartman: its magic
[09:14:11] <KotH> jannau: ROTFL
[09:14:13] <cartman> av500: apparently :D
[09:14:22] <kierank> kshishkov: I like the way REing RV3 is up there with the other two
[09:15:22] <cartman> I'll wait for mru then
[09:15:24] <kshishkov> kierank: well, at uni they relaxed me a bit since I was working for their company, at company they relaxed me since I had to graduate, so I had time for RV3 ;)
[09:15:49] <kshishkov> KotH: I decided to try German chocolate
[09:15:53] <cartman> there seems to be a problem when you wrap omapfbplay in a shared library as opposed to being a standalone executable
[09:16:16] <kierank> kshishkov: I still don't understand the major question. WHY?
[09:16:21] <kierank> why realvideo
[09:16:27] <cartman> kierank: Anime
[09:16:30] <elenril> masochism
[09:16:38] <kshishkov> kierank: because Mike and Benjamin wanted it
[09:16:43] <kshishkov> kierank: ask them
[09:18:58] <cartman> yes, some bastards took over the ffmpeg project yesterday and fscked up the svn...
[09:19:00] <cartman> LOL
[09:19:51] <av500> gazillions of chinese need realvideo
[09:20:04] <cartman> stop pleasing Chinese
[09:20:18] <kshishkov> av500: if you don't know my favourite toast is "what it has to do with us"
[09:20:44] * av500 prefers "mighty white"
[09:21:11] <kshishkov> av500: sounds like ElenrilTropes entry
[09:27:36] <elenril> kshishkov: http://tvtropes.org/pmwiki/pmwiki.php/Main/MightyWhitey
[09:27:46] <kshishkov> elenril: thought so
[09:28:34] <av500> kshishkov: it is also a defunct toast brand :)
[09:29:31] <kshishkov> av500: could be, I have little interest in toasts
[09:30:34] <av500> kshishkov: what else do you put peanut butter and jam on?
[09:30:46] * elenril wonders why didn't he buy more ram years ago
[09:31:09] <av500> elenril: and now its hard to get?
[09:31:17] <av500> pre-DDR?
[09:31:21] <elenril> av500: no, i bought it yesterday
[09:31:36] <elenril> just should've done that much sooner
[09:31:45] <elenril> living with just 1GB was a major PITA
[09:31:52] <av500> oh
[09:31:53] <av500> yes
[09:32:42] <kshishkov> av500: I prefer to put my hjortronsylt on smörgåsran
[09:33:23] <kshishkov> av500: "pre-DDR" sounds a bit ambiguous concerning your location
[09:34:16] <av500> kshishkov: I did not assume elenril runs a 1940's machine
[09:41:35] <ohsix> edo or fpm
[09:42:08] <kierank> kshishkov: dance dance revolution?
[09:42:57] <kshishkov> kierank: what's that? For me DDR will always stand for "Deutsche Demokratische Kommierespublik"
[09:43:14] <kierank> some game
[09:43:19] <kierank> arcade game where you dance
[09:43:33] <av500> kierank: kshishkov's favorite game
[09:43:48] <kierank> asians are well known for playing it
[09:43:55] <spaam> kierank: come on.. you didnt know what DDR was? :P
[09:44:15] <kshishkov> av500: in my case it's "stomp heavily on other people's feet" game
[09:44:31] <av500> kshishkov: thats what dancing is about, no?
[09:45:28] <superdump> for me DDR used to be double data rate (ram)
[09:45:36] <kshishkov> av500: there's another type - being jammed in the crowd - quite popular in disco and night clubs
[09:45:48] <av500> thats where you can stomp best
[09:45:51] <superdump> but people rarely say ddr in that context anymore
[09:46:26] <kshishkov> superdump: and next you'll say "GB" doesn't mean "Chinese standard" for you
[09:47:24] <superdump> certainly doesn't
[09:47:29] <superdump> i didn't even know that
[09:47:35] <av500> BIG5 ftw!
[09:47:37] <ohsix> yea the distinction was with rambus at the time
[09:48:07] <ohsix> now it's just stuff that transfers on either side of the clock and standard bus rates/arrangements/jedec stuff
[09:52:16] <cartman> av500: look at /private :P
[09:52:36] <kshishkov> merbzt: can you explain to kierank why I had to work on RV4?
[09:53:01] <merbzt> coz we tricked you that is
[09:53:14] <merbzt> :)
[09:53:33] <DonDiego> BBB: i wonder if it was good to answer michael's question in public
[09:53:49] <cartman> av500: you got mail too (unrelated to my question :P)
[09:53:54] <KotH> kshishkov: well... just let me tell you taht most german choco is edible, but far from being good
[09:54:31] <kierank> kshishkov: here is a swedish residence visa if you finish rv4 ?
[09:54:59] <kshishkov> merbzt: no, why you needed it REd
[09:55:18] <DonDiego> there is more stuff that one could add, but i'm afraid this could spiral downwards as usual...
[09:55:43] <kshishkov> KotH: edible - yes, but lacks taste. I had to resort to Läderach after that
[09:56:01] <thresh> "Алёнка" ftw
[09:56:05] <merbzt> kshishkov: because you where supposed to implement a decoder for soc
[09:56:57] <kshishkov> merbzt: could be some other decoder but you've asked for this one
[09:57:17] <KotH> kshishkov: hehe
[09:57:41] <KotH> kshishkov: läderach is cool... but where did you get it? i've never seen it outside .ch
[09:57:52] <av500> smugglers!
[09:58:03] <av500> KotH: and he admitted he was in .ch
[09:58:33] <kshishkov> KotH: we have their shop at Marktplatz
[09:58:40] <KotH> o_0
[09:58:44] * KotH is astonished
[09:58:57] <lyakh> can anyone tell me what that "runcmd" in fate / ffmpeg configs is?
[09:58:59] <av500> KotH: swiss export control is getting lax?
[09:59:03] <merbzt> kshishkov: I ask about lots of things
[09:59:07] <kshishkov> KotH: don't forget that we also have direct connection to Basle and even our own railroad station there
[09:59:30] <KotH> av500: more like "i didnt know they have such a large production now that they can open shops in other countries"
[09:59:59] <KotH> kshishkov: basel is way of from where läderach comes from
[10:00:25] * elenril looks at his covert art hack and is tempted to git reset --hard again
[10:00:34] <kshishkov> KotH: look at http://www.laederach.ch/de/shop/shopfinder/welt.php?showAddress=deutschland
[10:00:49] <av500> "...Läderach opens second shop in South Korea.."
[10:00:50] * KotH looks
[10:01:03] <cartman> av500: at least not the North
[10:01:25] <kshishkov> KotH: also it's funny that half of places are in Baden
[10:01:45] <KotH> hey, they have two in tokyo as well
[10:02:31] <av500> and MUC and I will be there soon</plan>
[10:02:36] <kshishkov> hey, they have even shops in Zürich!
[10:02:42] <av500> wow
[10:02:43] <KotH> lol
[10:04:28] <kshishkov> av500: it's a wonder how Switzerland manages to grow that much cocoa
[10:04:43] <av500> kshishkov: they have those large caverns in the alps
[10:04:53] <av500> and lots of UV lighty
[10:04:55] <kshishkov> av500: filled with gold?
[10:05:22] <av500> kshishkov: dunno, does cocoa grow on gold?
[10:05:39] <kshishkov> av500: only corn does
[10:06:06] <lu_zero> 10:53 <@DonDiego> BBB: i wonder if it was good to answer michael's question in  public
[10:06:21] <kshishkov> av500: but while corn extracts gold from soil it can't beat lawyers and wives
[10:06:58] <lu_zero> I was undecided as well
[10:07:31] <wbs> lu_zero: I do think it's good to explain it in public
[10:07:57] <av500> well, the cabal was critisized to have been too secret....
[10:07:57] <kshishkov> we have nothing to hide now, don't we?
[10:08:57] <DonDiego> one could start explaining, yes, but part of it could get ugly
[10:09:41] <elenril> it'll get more ugly if it's not clear what our motivation was
[10:09:41] <kierank> someone would have leaked it anyway
[10:09:43] <wbs> lu_zero: a lot of people have been unaware of the extent of the issue, and the nonpublic discussions between BBB, michael, diego and mru(?)
[10:09:49] <elenril> and apparrently it's not clear to many
[10:11:07] <KotH> wbs: you can add a few names more there
[10:11:56] <wbs> KotH: ah, yes
[10:12:32] <wbs> that's probably one of the larger parts of the confusion, people not aware of all that history, and then trying to understand wtf and why
[10:13:14] <{V}> does it really matter? it's not like those who undersigned the Announcement are strangers
[10:13:59] <KotH> {V}: well... people dont know whether these are strangers or not
[10:14:16] <KotH> {V}: there is a lot of misunderstanding due to that
[10:14:27] <KotH> {V}: heck, i've been even labled as the leader of the revolution
[10:14:57] <elenril> you're not? =p
[10:15:20] * KotH configures natsuki to reject all mails from elenril 
[10:15:23] <{V}> probably just based on that you were the unforunate one to actually send the email
[10:15:31] <Kovensky> Attila the Chocolate Hun
[10:15:49] <elenril> KotH: how not nice
[10:15:56] <KotH> {V}: me sending the mail was a decision we took, there is nothing unfortunate about it
[10:16:04] * elenril considers joining michael's fork in revenge
[10:16:05] <kshishkov> {V}: that was only because he's True Neutral (from very neutral country too except when you speak about chocolate)
[10:17:50] <kshishkov> elenril: at least you can have a lot of metadata with git commits
[10:26:11] <kshishkov> mate!
[10:26:40] * kshishkov reminds that whatever happens FFmpeg should get Bink-b support
[10:27:02] <kierank> http://software.solidot.org/article.pl?sid=11/01/20/0759213
[10:27:13] <kierank> chinese seem to be interested
[10:27:54] <pross-au> Wilco
[10:28:33] <kshishkov> kierank: why does that site look like Chinese Slashdot ripoff?
[10:28:46] <kierank> because it is
[10:29:06] <mmu_man> plop
[10:29:12] <av500> "The reason is to unify the revolution, FFmpeg serious split the community they have not watch."
[10:29:14] <mmu_man> anyone looked into the ARF format yet ? https://intercallcenters.webex.com/docs/T26L/common_docs/en_US/record/man/wx_playARF_ug.pdf
[10:29:36] * mmu_man throws some tunisians in
[10:30:05] <cartman> av500: google translate? :P
[10:30:08] <av500> mmu_man: patches welcome
[10:30:21] <kshishkov> mmu_man: better Tunisians than BeOS users
[10:30:24] <mmu_man> just asking, too busy.
[10:30:34] <av500> cartman: yup
[10:30:43] <mmu_man> kshishkov: well BeOS users freed themselves with Haiku long ago :p
[10:30:47] <mmu_man> :^)
[10:31:44] <mmu_man> "Converting recordings to Flash format"
[10:31:46] <mmu_man> OMFG
[10:31:54] <mmu_man> Why would one want to ?
[10:32:05] <mmu_man> convert from a proprietary format to yet another proprietary format ?
[10:32:11] <kshishkov> probably it's remuxing MP3 stream into WMV or SWF
[10:32:36] <mmu_man> guess so, ah yes it exports to WMV too...
[10:32:46] <mmu_man> but well that means you need their player first anyway
[10:32:47] <mmu_man> sux
[10:33:05] <kshishkov> mmu_man: there's one Wikipedia article that makes me laugh really hard - http://en.wikipedia.org/wiki/List_of_BeOS_programs
[10:33:13] <mmu_man> "ARF recordings are a proprietary WebEx ARF format" << oh, in case I wasn't sure
[10:33:51] <kierank> mmu_man: clearly a french person thought of the name arf
[10:34:11] <mmu_man> kshishkov: there are some more on http://bebits.com/
[10:34:19] <mmu_man> kierank: arf, oui :)
[10:34:53] <av500> kshishkov: it has vlc, thus it is complete
[10:34:57] <kshishkov> mmu: that reminds me - what's the difference between your words "loup" and "garou"?
[10:35:12] <kshishkov> av500: unlike your company products
[10:35:22] <mmu_man> bleh, stupid player app installs an icon on my desktop
[10:35:26] <mmu_man> who told it to ?
[10:35:31] <av500> you
[10:36:05] <mmu_man> kshishkov: loup == wolf
[10:36:25] <mmu_man> the loup garou is more a mythical beast
[10:36:37] <mmu_man> that eats bad behaving children
[10:36:55] * elenril recalls seein a loup garou in baldur's gate 2
[10:36:57] <mmu_man> the magical one that is actually human during the day
[10:37:12] <kshishkov> werewolf?
[10:37:15] <elenril> it was an upgraded werewolf iirc
[10:37:16] <mmu_man> well looks human
[10:37:17] <mmu_man> yeah
[10:37:43] <mmu_man> then there is the bête du gévaudan
[10:37:48] <kshishkov> and is word "garou" ever used separately?
[10:37:56] <mmu_man> don't think so
[10:38:20] <kshishkov> mmu_man: never heard of that beast from Gevaudan forest too
[10:38:28] <mmu_man> appart as the scene name of a quebec singer
[10:38:57] <DonDiego> btw, i think one of the problems in the announcement was that we overloaded the word "maintainer"
[10:39:13] <DonDiego> it has a well-known and fixed meaning in the ffmpeg community
[10:39:29] <DonDiego> trying to use it for something else is bound to cause confusion...
[10:40:04] <Dark_Shikari> agreed
[10:40:08] <Dark_Shikari> you should mention that
[10:40:24] <DonDiego> i would like to note that there is a lesson here:
[10:40:36] <DonDiego> not every discussion about words and little things is a bikeshed
[10:42:33] <Dark_Shikari> heh
[10:43:38] <kshishkov> DonDiego: I call it "defining terms", without it you usually have bikesheds because of misinterpretations
[10:51:54] <thresh> kshishkov: http://img89.imageshack.us/img89/5259/1295486824752.jpg
[10:53:41] <kshishkov> thresh: поскорей бы
[10:54:21] <merbzt> oh the poor car
[10:54:27] <merbzt> I can't watch anymore
[10:56:31] <DonDiego> reynaldo: aren't you the WTV guy?
[10:56:43] <DonDiego> reynaldo: peter ross is pinging a patch
[10:58:10] <mru> moroning
[10:58:41] <cartman> mru: morning
[10:59:03] <kierank> kshishkov: ever been on a train ferry?
[10:59:06] <cartman> mru: having some problems with magic-{head,tail}.S if you have some time
[10:59:22] <mmu_man> plop
[11:00:21] <mru> cartman: they're magic
[11:01:03] <kshishkov> kierank: nope, only on ordinary one (Stockholm-Ã…bo)
[11:01:04] <cartman> mru: yup
[11:01:27] <cartman> mru: find_driver returns NULL for ofbp_codec_start, so its not finding avcodec
[11:01:34] <kierank> kshishkov: you'd enjoy that. I can tell
[11:01:47] <cartman> mru: objdump on avcodec.o shows me that it has .ofbp_codec defined
[11:02:15] <cartman> mru: but there is one "tiny" problem, in Android I am wrapping omapfbplay in a shared library, not an executable
[11:02:20] <kshishkov> kierank: well, there's one on the route Berlin-Stockholm but I had no reason to go anywhere via Berlin
[11:02:22] <cartman> mru: does that make a difference?
[11:02:36] <in3xes> Can anyone tell me what FFV1 is?
[11:02:37] <mru> no idea
[11:02:42] <cartman> mru: good
[11:02:44] <mru> try linking with -Bsymbolic
[11:02:55] <cartman> mru: ok
[11:03:03] <kshishkov> in3xes: FOURCC for video codec known as FFV1
[11:05:32] <in3xes> How difficult is this http://goo.gl/kEfnX for a starter?
[11:05:54] <kshishkov> should not be very hard
[11:06:10] <in3xes> Ok.
[11:07:03] <kshishkov> especially since it supports RGB32 already
[11:07:12] <in3xes> What is the easiest in that list?
[11:07:25] <av500> why the easiest?
[11:07:33] <av500> you give up so early? :)
[11:08:03] <in3xes> No
[11:08:05] <cartman> mru: -Wl,-Bsymbolic is the right one I guess?
[11:08:46] <kshishkov> in3xes: whatever you feel you'd like to do
[11:10:10] <in3xes> I'll try, I still have many thing to understand.
[11:10:11] <lyakh> for all the fate-experts here: what is http://pastebin.com/n3KxrT50 supposed to mean?...
[11:11:51] <cartman> mru: one more thing is that neon_pixconv.S doesn't like Android toolchain: http://ffmpeg.pastebin.com/raw.php?i=rnVpGFba
[11:12:04] <kshishkov> lyakh: probably you've forgotten to download some files or so
[11:16:14] <mru> cartman: wrong -mcpu or -march
[11:16:32] <mru> I suppose adding overrides in the .S file would make sense
[11:18:42] <cartman> mru: it passes -march=armv5te by default
[11:19:16] <mmu_man> But, I thought -march was to specify which of the 4 daughters... !? :p
[11:20:10] <lyakh> kshishkov: that was an empty (actually non-existent) directory, the fate.sh script has created it from svn
[11:20:28] <cartman> mru: -march=armv7-a fixes it indeed
[11:20:31] <cartman> thanks
[11:22:16] <mru> lyakh: svn? you should be using git by now
[11:22:29] <cartman> mru: Shall I pass -mfpu=neon too?
[11:22:38] <kierank> astrange: any idea why version.h doesn't appear in latest ffmpeg-mt
[11:22:41] <mru> in other news, I've removed the fate slots using the wrong git repo from the view
[11:22:53] <cartman> mru: I fixed mine
[11:22:57] <mru> kierank: version.h is a generated file
[11:23:04] <cartman> ah mine is there ;)
[11:23:11] <lyakh> mru: thanks. that's what I use... ah, ok, maybe I should replace that in the fate config file... let me try
[11:23:15] <kierank> mru: yeah, i mean it's generation
[11:23:35] <kierank> its*
[11:23:42] <mru> kierank: it's created when you run make
[11:23:49] <mru> or is that what it's not for you?
[11:24:02] <kierank> it's not created for some reason and make fails
[11:24:08] <mru> hmm
[11:24:13] <kierank> in ffmpeg-mt
[11:24:17] <kierank> dunno about main
[11:24:17] <mru> odd
[11:24:22] <mru> main obviously works
[11:24:26] <kierank> it was working yesterday
[11:24:28] <mru> fate would complain otherwise
[11:25:03] <mru> did you do something unusual?
[11:25:10] <kierank> nope
[11:25:11] <mru> like deleting files other than by make clean?
[11:25:29] <lyakh> mru: kshishkov: same with git
[11:25:45] <kierank> mru: sometimes i do a make distclean in windows, then compile the same repo in a linux vm
[11:25:59] <kshishkov> git status
[11:26:14] <mru> kierank: I strongly recommend building in a different directory than the source
[11:26:42] <lyakh> ah, I think, those messages is not the actual problem...
[11:26:45] <mmu_man> # Untracked IRC channel modified by a bunch of people.
[11:28:18] <kierank> mru: ok
[11:29:33] <DonDiego> should we call for more/new fate machines
[11:29:55] <mru> let me see what I can rustle up at home
[11:30:17] <mru> some virtual machines on the spare quad-core should do the trick
[11:30:53] <mru> I'd rather not deal with windows though
[11:31:01] <mru> so if someone can help out with that I'd be happy
[11:31:40] <KotH> mru: what do you need?
[11:31:51] * KotH has a xeon dualcore lying around, doing nothing
[11:32:04] <superdump> mmu_man: ?
[11:32:16] <mru> KotH: I need someone else to run fate on windows
[11:32:24] <KotH> uh...
[11:32:50] <KotH> if someone can tell me how to get a compilation enviroment on windows ... than i could do it
[11:32:50] <mru> as I said, I can install some BSDs etc on a spare quad-core I have
[11:32:58] <mru> KotH: therein lies the problem
[11:32:59] <mmu_man> superdump: j/k on git status
[11:33:01] <mru> it's a world of pain
[11:33:06] <KotH> exactly
[11:33:38] <mmu_man> KotH: actually I think it might be much simpler to crosscompile with mingw :D
[11:33:42] * KotH wonders how people write code on windows w/o stabbing their eyes out, hacking their hands of and continusly banging their had against the desk
[11:33:49] <mmu_man> at least this I managed to do for NetSurf once
[11:34:12] <av500> I can donate a P3 laptop for some SSE0.5 testing
[11:34:31] <thresh> i have a celeron laptop lying around as well
[11:34:45] <mru> I have an old celeron desktop
[11:34:47] * cartman already donates his MacBook Pro Corei7 2.66 
[11:34:48] <mru> and a P4
[11:34:56] <mru> and a macbook
[11:34:58] <av500> and I'm throwing away a K6-2 right now :)
[11:35:12] <mmu_man> even managed to build Caloric, an ORIC emulator using SDL as a .exe
[11:35:21] * kierank donates a calculator
[11:35:55] <mmu_man> kierank: which model ? some are rare :p
[11:36:10] <kierank> yeah i have a rare one
[11:36:42] <spaam> av500: whY? give it to DonDiego .. he likes does amd k6 cpus..
[11:38:43] <{V}> KotH, one TCHAR at a time?
[11:39:33] * av500 can donate http://www.vintagecalculators.com/html/sharp_qt-8d.html
[11:39:49] <av500> it even has C style += -= etc..
[11:39:55] <mmu_man> gee, nice one
[11:40:26] <av500> I bet mike will want to encode vp8 on it by hand....
[11:41:33] <kshishkov> it's faster than with xvp8 anyway
[11:42:43] <mru> elenril: ping
[11:42:58] <av500> mru: you need to meta-ping hime
[11:43:00] <av500> -e
[11:43:09] <mru> elenril: meta-ping
[11:45:50] <in3xes> Ah, porting must be simpler.
[11:46:07] <cartman> Android emulator is killing me
[11:46:30] <av500> cartman: with -9?
[11:46:45] <cartman> av500: yes :P
[11:51:03] <Dark_Shikari> superdump: awesome email fyi
[11:51:17] <superdump> thanks
[11:51:25] <wbs> superdump: yes, very well written indeed
[11:51:51] <cartman> av500: I guess the Android emulator doesn't support armv7 instructions
[11:52:01] <wbs> cartman: don't think so
[11:52:18] <cartman> it just hangs up loading
[11:52:22] <cartman> gotta love Google
[11:52:55] <av500> cartman: yep
[11:53:01] <av500> emu is an armv5
[11:53:14] <mru> how useful
[11:53:24] <cartman> bleh
[11:53:25] <cartman> :(
[11:53:52] <lu_zero> isn't possible to update to a more recent arm-qemu?
[11:54:08] <cartman> they still ship gdb 6.x too ;)
[11:54:35] <lu_zero> doesn't sound that up to date...
[11:55:05] <mru> qemu is horribly broken for v7 anyway
[11:55:28] <lu_zero> mru: less broken than before ^^;
[11:55:35] <lu_zero> nearly usable
[11:55:49] <mru> yeah, I suppose it's slowly getting fixed
[11:55:54] <mru> but I still wouldn't trust it
[11:55:58] <av500> mru: most ppl have given up on the emu as starting an app on a connected device is way faster
[11:56:08] <thresh> +1
[11:56:15] <thresh> same for maemo/meego
[11:56:22] <cartman> av500: the boss stole my tablet :P
[11:56:26] <av500> thresh: its also emulated?
[11:56:30] <mru> thresh: do you have access to the commit hooks on videolan.org?
[11:56:42] <thresh> av500: yep, in Nokia Qt SDK for instance or Meego SDK.
[11:56:48] <thresh> mru: I do
[11:56:50] <av500> thresh: ic
[11:56:57] <mru> cartman: tell your boss you can't do any work until you get it back
[11:57:14] <mru> thresh: then can you please stop sending cia notices here for the ffmpeg repo there?
[11:57:29] <mru> michael isn't in this channel anyway
[11:57:40] <thresh> for maemo they had an abomination called scratchbox, but we call 'срачбокс' or shitbox as it what it really is
[11:57:47] <cartman> mru: he already knows that :)
[11:57:52] <cartman> thats how I slack :P
[11:57:59] <thresh> mru: is there any othe place that uses CIA notifications except this channel?
[11:58:06] <KotH> cartman: you're a true turkish! :)
[11:58:14] <mru> thresh: scarebox is the canonical name for that thing
[11:58:14] <cartman> KotH: lol
[11:58:20] <cartman> KotH: I guess so :P
[11:58:29] <cartman> KotH: if you treat me bad I slack :P
[11:58:50] <KotH> cartman: if my boss would tread me bad, i'd be gone ;)
[11:58:50] <mru> thresh: now we're getting cia notices from two repos here
[11:58:52] <mru> it's confusing
[11:58:58] <cartman> KotH: I am going man :)
[11:58:58] <kshishkov> thresh: /dev/null, /dev/ass, #ffmpeg-devel-for-mn
[11:58:59] <mru> KotH: +1
[11:59:07] <mru> cartman: :)
[11:59:07] <cartman> things take time
[11:59:27] <cartman> I'll be av500's neighbour
[11:59:30] <cartman> possibly :P
[11:59:35] * KotH quit his last job for exactly that reason.. before having a new one
[12:01:19] <Compn> arpi makes his appearance
[12:01:25] <Compn> on mplayer-dev-eng
[12:01:31] <cartman> Compn: for the lolz
[12:01:50] <KotH> cartman: taht's "lulz" :)
[12:01:56] <cartman> KotH: doh
[12:01:56] <cartman> :D
[12:02:51] <mru> it's "for teh lulz"
[12:03:04] <av500> does mplayer have another list for flames or is it all in irc?
[12:03:18] <mru> there was an mplayer-flames list at some point
[12:03:27] <kshishkov> Compn: if his replies are always that correct no wonder he's not missed
[12:05:30] <thresh> mru: done
[12:06:26] <Compn> kshishkov : well, breaking mplayer compilation is against mplayer policy. probably DonDiego knows this ... :p
[12:06:27] <Compn> ehe
[12:06:55] <kshishkov> Compn: I thought that's the thing you should do regularly
[12:07:05] <Compn> huh?
[12:07:20] <mru> Compn: DonDiego replaced an svn external with the real deal
[12:07:25] <mru> that broke svn up in existing checkouts
[12:07:29] <mru> another weakness of svn
[12:07:32] <Compn> ah
[12:07:52] <Compn> yes, that would be the problem then
[12:08:12] <mru> svn can't cope with a directory being anything other than created or deleted in a single commit
[12:08:16] <Compn> would keeping a read only libswscale svn open for older revisions work ?
[12:08:23] <mru> replacinga  dir witha  file is impossible and vice versa
[12:08:32] <mru> and apparently the same holds for externals
[12:08:54] <mru> Compn: waste of effort
[12:09:01] <mru> ffmpeg svn will go away
[12:09:33] * lu_zero is back
[12:09:39] <lu_zero> anything happened lately?
[12:09:51] <mru> patches, reviews, nothing exciting
[12:09:52] <Compn> lu_zero : arpi commented on dev-eng
[12:10:00] <kshishkov> mru: why? You can keep it somewhere in museum
[12:10:01] <cartman> does emu supports OpenGL ES?
[12:10:09] <wbs> cartman: 1.x yes
[12:10:29] <mru> how useful
[12:10:37] <cartman> wbs: if I crash the emu I guess its not 1.x :D
[12:10:56] <mru> 1.x is barely usable
[12:11:00] <mru> if that
[12:11:09] <lu_zero> s/barely/non/
[12:11:12] <wbs> cartman: there were some quite basic bugs with lighting and such that I fixed (fixed in the eclair emulator iirc), but if you're not actually doing 3d stuff I don't think you'll run into those issues :-)
[12:11:17] <mru> so if your code does anything useful, it's 2.x
[12:11:40] <cartman> mru: yeah
[12:11:44] <cartman> man Android is a joke :D
[12:11:48] <cartman> mostly :P
[12:12:00] * mru as usual pretends to know stuff
[12:12:10] <mru> one day I'll be found out...
[12:12:25] <mru> but by then I'll _rich_, mwaahahahahaha
[12:12:38] <lu_zero> mru: 1.0 is useful to port stuff from old opengl
[12:12:39] <kshishkov> mru: I won't live till FFmpeg 2.x I fear :(
[12:13:03] <lu_zero> under the hood gles 1 uses gles 2 in most implementations
[12:13:29] <mru> anything else would insane
[12:13:32] <mru> +be
[12:13:43] <cartman> mru: lol
[12:13:50] <lu_zero> and gles 2 uses some kind of online shader compiler written in C++ making your whole application funny if you are using C++ already
[12:13:59] <lu_zero> </rant>
[12:14:23] <mru> lu_zero: the sgx gles you mean?
[12:14:29] <lu_zero> any
[12:14:32] <lu_zero> mesa included now
[12:14:39] <mru> surely it's possible to implement gles without using c++
[12:14:59] <mru> what of nvidia?
[12:15:01] * lu_zero should find a month or two to rewrite the mesa compiler in plain C ...
[12:15:08] <lu_zero> C++ iirc
[12:15:13] <mru> probably c++ too, but I bet it's a different one
[12:15:18] <lu_zero> C++ as well for AMD
[12:15:27] <wbs> lu_zero: in which way does that interfer with your own app?
[12:15:45] <mru> wbs: poorly written in some way I guess
[12:15:55] <lu_zero> wbs: if you have your app using C++ already (think Qt)
[12:15:56] <mru> allowing c++ uglies to leak outside the api
[12:16:06] <lu_zero> mru: worse
[12:16:20] <wbs> lu_zero: yes, but what would the problem be? clashes with different c++ runtimes, or what?
[12:16:27] <lu_zero> wbs: yup
[12:16:33] <wbs> mmkay
[12:16:37] <lu_zero> and if you are using link-once stuff
[12:16:52] <lu_zero> you might get some _really_ fun stuff
[12:16:58] <mru> they include their own runtime and export the symbols?
[12:17:17] <lu_zero> mru: by definition C++ doesn't have the problem of exported symbols
[12:17:26] <mru> of course it does
[12:17:33] <lu_zero> the problem is the runtime
[12:17:33] <mru> names can always clash
[12:18:04] <lu_zero> mru: you can have fun ABI stuff due libstdc++ being not always perfectly versioned
[12:18:24] <cartman> so I can't really work without a real device
[12:18:32] <cartman> sob no more, slack++
[12:18:33] <mru> if a .so included an entirely self-contained runtime with nothing visible from the outside, only exposing a C api, the rest of the app can safely use another c++ runtime
[12:18:43] <lu_zero> mru: nope
[12:18:50] <mru> why not?
[12:18:58] <mru> c++ is not magic
[12:18:58] <lu_zero> because internally the C++ runtimes will stomp on each other
[12:19:03] <mru> how can they?
[12:19:09] <mru> they exist in different realities
[12:19:33] <lu_zero> link-once (so Diego explained me) would override stuff
[12:19:37] <mru> it _could_ be done that way
[12:19:44] <mru> not saying it is
[12:19:55] <mru> since you have problems, it is obviously not
[12:20:20] <lu_zero> and there are some details regarding stuff it should be unique e.g. exception handler and vtable things
[12:20:34] <lu_zero> I didn't want to touch nor be aware of those stuff
[12:20:38] <mru> lu_zero: all that can be done internally in the .so
[12:20:44] <mru> nothing magical
[12:21:05] <lu_zero> the problem isn't if your C app uses the gles that has a compiler written in C++
[12:21:09] <mru> when linking the .so, you'd have to use the static libgcc, libgcc_eh etc
[12:21:16] <mru> and libstdc++
[12:21:29] <mru> then make sure _nothing_ from those make it into the symbol table
[12:21:36] <lu_zero> or you build everything shared and link your C++ app with the same C++ runtime used
[12:21:37] <mru> and use -Bsymbolic on the whole thing
[12:21:37] <cartman> -ffreestanding ?
[12:21:57] <lu_zero> mru: that was what I considered the solution
[12:22:17] <lu_zero> asked to C++/ABI informed people and they told me it would have issues =|
[12:22:34] <mru> what they've probably done is include a c++ runtime and exported its symbols
[12:23:02] <mru> or rather, they included the subset of the c++ runtime the need and export it
[12:23:22] <mru> so when you then pick up the system shared c++ runtime, you get a frankenlink
[12:23:49] <mru> due to some symbols being versioned or named differently and some not
[12:24:15] <mru> the same could happen with any library
[12:24:54] <lu_zero> anyway at least for mesa I hope it could be solved =P
[12:25:13] <mru> there are two solutions
[12:25:29] <mru> 1) use only the shared system runtime
[12:25:37] <mru> 2) fully internalise the one in the lib
[12:25:55] <mru> 1 is not viable for binary distribution onto different systems of course
[12:29:55] <lu_zero> 1 is what is used right now ^^;
[12:31:45] <superdump> i don't know if it's been discussed but is there any chance of doing some kind of quick port of the soc svn repos to git?
[12:32:34] <kshishkov> quick - yes, proper - no
[12:32:34] <superdump> or getting the svn web interface back online :)
[12:32:49] <kshishkov> harddrives would be against that
[12:33:23] <lu_zero> superdump: which soc are you interested in?
[12:33:40] <mru> a quick git-svn conversion of just the soc bits shouldn't take too long
[12:33:46] <andoma> mru: i'm compiling ffmpeg with the ps3 homebrew toolchain (gcc 4.5.2 with newlib 19.0) the aixdesc ABI prefixes external functions with a '.' but does not do anything with data, so ffmpeg's configure misdetects stuff in the symbol mangling check
[12:34:14] <mru> andoma: it's more complicated than that
[12:34:17] <andoma> ugh
[12:34:26] <andoma> ?
[12:34:27] <superdump> lu_zero: aac - a guy just emailed me about working on LTP for a small task for qualification for this year's google soc
[12:34:30] <superdump> peloverde: ^
[12:34:48] <mru> andoma: the detection might be broken though
[12:35:18] <superdump> andoma: you have a ps3 now?
[12:35:23] <andoma> superdump: yup
[12:35:28] <superdump> hehe
[12:35:33] <cartman> andoma: r00ted yet?
[12:35:35] <andoma> no games, just jailbreaked :)
[12:35:38] <andoma> cartman: ofcourse
[12:35:42] <mru> andoma: can you please post config.log and full nm output from the .o used for detecting prefixes?
[12:35:44] <DonDiego> should i write a reply to michael as well?
[12:36:05] <superdump> if you feel you have something to say, sure
[12:36:18] <kierank> how did michael become leader anyway?
[12:36:25] <andoma> mru: i'll do that once I get home to my desktop (don't have the setup here at work)
[12:36:27] <mru> andoma: ppc64 functions export two names, one with ., the other w/o
[12:36:30] <superdump> it just kind of happened i think
[12:36:32] <superdump> over time
[12:36:50] <superdump> but maybe he was leader before i started working on ffmpeg so i don't really know
[12:36:53] <mru> the dotless one includes full gp setup
[12:36:59] <andoma> ah
[12:36:59] <mru> the dotted one skips that
[12:37:21] <mru> when linking, the linker chooses one depending on whether the gp needs updating or not
[12:37:37] <mru> so no prefix is correct
[12:38:25] <lu_zero> superdump: I'd forward them on gitorious or github
[12:38:38] <lu_zero> probably github or gitorious might even help us to set it up
[12:38:45] <mru> superdump: most of the devs active around 2002-2003 are gone
[12:38:51] <andoma> mru: sounds like the linker is broken then?
[12:39:03] <mru> andoma: no, just the detection in the configure script
[12:39:09] <mru> I'll need to improve it
[12:39:26] <lu_zero> andoma: ffmpeg on ps3 bare metal (lv1?)?
[12:39:36] <andoma> lu_zero: yupp
[12:39:43] <lu_zero> sounds... gory
[12:39:45] <andoma> well not exactly ffmpeg binary
[12:39:50] <andoma> but rather a mediaplayer
[12:40:08] <mru> superdump: there was a transition and michael was probably the most active (and generally knowledgable about ffmpeg) to bridge the gap
[12:40:22] <mru> superdump: so the new devs just assumed he was some kind of leader
[12:40:23] <mru> more or less
[12:40:27] <superdump> mru: i had that impression
[12:40:37] <mru> at least that's how I remember things
[12:40:42] <kierank> did you consider asking him to take a sabattical from leading
[12:40:47] <cartman> mru: I also remember so...
[12:40:49] <superdump> i did
[12:41:07] <mru> cartman: you were around back then too?
[12:41:18] <cartman> mru: I was lurking since 2001
[12:41:19] <cartman> :P
[12:41:19] <superdump> or well, i considered presenting the situation to him basically as i stated in the last paragraph of my mail
[12:41:21] <thresh> andoma: which firmware and toolchain you're using?
[12:41:40] <superdump> as well as the support for the new way to run things
[12:41:59] <andoma> thresh: 3.55 + geohot jailbreak w/ ps1lght
[12:42:09] <thresh> i see
[12:42:15] <superdump> i hoped he would see the support, accept the situation and maybe even embrace it to do some stuff he found interesting
[12:42:18] <cartman> andoma: does it run homebrew yet?
[12:42:21] <superdump> but i have rose-tinted glasses
[12:42:34] <andoma> cartman: i'm porting my mediaplayer (http://www.lonelycoder.com/showtime)
[12:42:35] <superdump> or so i'm lead to believe sometimes :)
[12:42:45] <andoma> it kinda works ...  it can stream music from the network ..
[12:43:03] <andoma> i've got some of the GPU things wokring.. framebuffer works. Vertex-shaders ..
[12:43:08] <cartman> andoma: nice
[12:43:10] <andoma> but it needs a bit more work
[12:43:34] <andoma> pslight recently got support for fragmentshaders so i started on that yesterday night
[12:45:13] <lu_zero> andoma: linux / x11 support got improved?
[12:45:24] <andoma> lu_zero: on the ps3?
[12:45:36] <lu_zero> yup
[12:45:38] <kierank> is the ps3 fully rooted or do you still run on top of the hypervisor?
[12:46:10] <spaam> andoma: can you use spotify with it?
[12:46:12] <andoma> no idea .. i don't follow the linux track thay close
[12:46:24] <lu_zero> had been ages since I booted the ps3 ...
[12:46:28] <lu_zero> (too busy)
[12:46:38] * thresh only uses one application on PS3 since november
[12:46:55] <andoma> spaam: yeah.. i theory .. although i find it hard that spotify would release a binary version of libspotify for ps3 homebrew
[12:47:10] <andoma> sony (the record label) might not like that
[12:47:16] <kierank> lol
[12:47:44] <mru> sony music and SCE are totally different companies really
[12:47:45] <andoma> kierank: the app runs with lv2 as a kernel
[12:47:51] <andoma> mru: yeah i know . but still :)
[12:48:00] <andoma> they can probably talk to each other if need may be
[12:48:06] <mru> yeah
[12:48:28] <mru> console and games divisions are closer though iiuc
[12:48:39] <mru> they're both SCE, I think
[12:49:56] <andoma> the lv2 kernel provides threads, mutexes, etc and io/network access .. but when it comes to the RSX (the GPU) you're down right to the metal
[12:50:29] <cartman> mru: btw, I found some code for YUV420->RGB565, see https://github.com/cartman/glbuffer/blob/master/jni/colorconvert.c
[12:50:52] <mru> ugh, .c
[12:51:05] <cartman> straight out of Google's opencore :)
[12:52:02] <kierank> lol namtrac heavy industries
[12:52:06] <cartman> kierank: :D
[12:52:12] <superdump> are there any distributions of ffmpeg dll binaries for windows?
[12:52:17] <cartman> man I was heavy :P
[12:52:32] <lu_zero> cartman: looks normal unaccelerated code?
[12:52:39] <lu_zero> superdump: ramiro's I think
[12:52:41] <superdump> http://ffmpeg.arrozcru.org/ <--- there perhaps?
[12:53:02] <cartman> lu_zero: I am not sure if it does what its supposed to do but some Google search gave me that :)
[12:53:06] * mru looks at the code and weeps
[12:53:12] <mru> .j
[12:53:16] <mru> oops
[12:53:24] <mru> lu_zero: that looks worse than unaccelerated
[12:53:32] <mru> it's _unoptimised_
[12:54:26] <cartman> for now its OK if it does the conversion without a bug :)
[12:57:02] <cartman> just one question
[12:57:18] <cartman> yuv data is in uint8_t** src and rgb data is uint8_t* dst
[12:57:19] <lu_zero> which one?
[12:57:29] <cartman> how do I know what size dst must be?
[12:57:34] <cartman> for memory allocation
[12:57:39] <kshishkov> depends on rgb format
[12:57:44] <cartman> kshishkov: 565
[12:57:46] <cartman> in my case
[12:57:55] <lu_zero> each pixel 16bit ?
[12:57:55] <kshishkov> 2*stride*height
[12:58:17] <cartman> lu_zero: that I am not sure
[12:58:19] <kshishkov> or even simply stride*height
[12:58:33] <lu_zero> 565 should ^^;
[12:58:40] <lu_zero> btw
[12:58:54] <lu_zero> why aren't you using swscale?
[12:59:11] <kshishkov> because omapfbplay doesn't
[12:59:32] <cartman> lu_zero: I failed to find an example conversion too, also what kshishkov said :)
[12:59:38] <lu_zero> omapfbplay does use anything?
[12:59:44] <cartman> ffmpeg ;>
[12:59:51] <lu_zero> cartman: ffplay should give you an example
[12:59:52] <kshishkov> lu_zero: it uses mru's knowledge
[13:00:16] <cartman> is "stride" == line size?
[13:00:50] <kshishkov> yep, in bytes
[13:01:00] <cartman> ok, thanks :)
[13:01:33] <cartman> kshishkov: looking at frame.h in omapfbplay linesize is a 3 element array, each component has its own linesize?
[13:02:19] <mru> yes
[13:02:39] <cartman> mru: which one do I use to calculate the destionation RGB buffer? :)
[13:02:52] <kshishkov> the zeroeth one, of course
[13:03:03] <mru> ack
[13:03:16] <cartman> okies
[13:03:22] <mru> but you're doing it wrong
[13:03:29] <cartman> mru: why?
[13:03:44] <mru> you should allocate anything you need in open() or enable()
[13:03:52] <cartman> mru: I'll do so :)
[13:04:00] <cartman> I am not allocating anything atm. :)
[13:04:28] <mru> then why are you asking how much to allocate?
[13:04:32] <cartman> mru: how would I go around calculating frame height?
[13:04:38] <cartman> mru: because I'll add allocation now :)
[13:04:50] <cartman> the other find_driver bug didn't let me move forward yet
[13:06:03] <cartman> mru: ah frame_format have it all
[13:06:46] <mru> it's a bit of a tangle, I admit
[13:07:11] <cartman> looks good in _enable
[13:07:20] <cartman> ff->height*ff_ystride
[13:07:26] <cartman> s/_/->
[13:07:39] <elenril> mru: meta-pong
[13:08:06] <cartman> kshishkov, mru , lu_zero thanks (another round of questions :))
[13:08:21] <mru> elenril: mumble mumble id3 patches mumble
[13:08:33] <mru> elenril: let me remind myself what I wanted to ask
[13:09:27] <elenril> yes, i fail at english
[13:09:31] <elenril> i meant prepend
[13:09:54] <mru> and the first patch, is that function not useful at all outside that file?
[13:09:57] <kshishkov> elenril: you fail English? That's unpossible!
[13:10:01] <mru> or why was it external in the first place?
[13:10:07] <elenril> no idea
[13:10:15] <elenril> it might've been used somewhere at some point
[13:10:23] <elenril> but now it's only used in id3v2.c
[13:10:28] <elenril> feel free to git grep
[13:10:51] <lu_zero> Dark_Shikari: which x264 preset works better on arm in your experience?
[13:11:01] <cartman> lu_zero, wbs any idea why ndk-build doesn't respect the order of files in LOCAL_SRC_FILES while _linking_ ?
[13:11:10] <lu_zero> the superfast preset is enough
[13:11:18] <lu_zero> cartman: how are you linking?
[13:11:33] <cartman> lu_zero: it just orders the object unrelated to the src order
[13:11:34] <wbs> cartman: hmm, does the order of object files matter?
[13:11:36] <mru> elenril: I trust you if you say it's not used
[13:11:44] <cartman> wbs: yes, for mru's magic it does :)
[13:11:49] * elenril wouldn't trust himself
[13:11:51] <mru> elenril: I was just wondering if it was meaningless to use it directly
[13:11:57] <elenril> but it compiles
[13:12:03] <cartman> lu_zero: I am not doing anything special
[13:12:09] <cartman> it just links to a shared lib.
[13:12:25] <mru> cartman: are you not using my makefile?
[13:12:32] <cartman> mru: nope
[13:12:32] <mru> you _must_ use my makefile
[13:12:36] <mru> otherwise it will fail
[13:12:43] <mru> it has the magic
[13:12:52] <cartman> mru: the order of objects is the magic, no?
[13:13:03] <mru> yes
[13:13:07] <cartman> see :)
[13:13:15] <mru> I suppose replicating the exact order is enough
[13:13:18] <cartman> ndk-build is getting in my though
[13:13:23] <cartman> mru: I manually link atm.
[13:13:24] <mru> but apparently droidmake doesn't let you do that
[13:13:27] <cartman> to workaround ndk crap
[13:13:37] <kshishkov> lu_zero: got myself efika-mx, any tips about it?
[13:13:46] <cartman> mru: seems so it puts assembly files at the end
[13:14:30] <mru> do droidmakefiles list source files rather than objects?
[13:14:38] <mru> that is so stupid
[13:14:42] <_av500_> lu_zero: wrt efika
[13:14:47] <cartman> mru: wut?
[13:14:50] <lu_zero> kshishkov: do you have already the updated u-boot
[13:15:07] <_av500_> lu_zero: lol
[13:15:17] <lu_zero> I'm running to have lunch now I can give you a walkthrough
[13:15:20] <kshishkov> lu_zero: nope, I'm going to play with it at weekend
[13:15:26] <_av500_> that is so #beagle
[13:15:26] <lu_zero> it should be pretty straightforward
[13:15:42] <lu_zero> and I could send you my gentoo image if you want
[13:15:59] <lu_zero> (and point you to the kernel sources and such)
[13:16:00] <mru> cartman: in the android build system, do you give it a list of source files to build?
[13:16:03] <lu_zero> brb
[13:16:07] <cartman> mru: yes
[13:16:09] <mru> cartman: and not a list of object files it should build
[13:16:12] <mru> cartman: that's stupid
[13:16:19] <cartman> mru: yes again
[13:16:20] <_av500_> yes
[13:16:28] <_av500_> stoopid
[13:16:46] <mru> it means there has to some convoluted make variable munging to turn source names into object names so make can figure out the reverse and build them
[13:16:47] <cartman> why does it reorder shit I don't know
[13:17:11] <cartman> mru: ah so I should say give it *.o files instead of *.c or *.S ?
[13:17:33] <mru> because there's probably something like C_OBJS = $(patsubst $(filter $(SRC),%.c),%.c,%.o) somewhere
[13:17:38] <mru> etc for other suffixes
[13:18:01] <kshishkov> lu_zero: thanks, I can figure out that stuff by myself. But I guess from your reply it's not something outstandingly bad ;).
[13:18:49] <cartman> /usr/local/android-ndk-r5/build/core/definitions.mk:  _OBJ_ASM_ORIGINAL := $$(patsubst %.o,%.s,$$(_ORG_OBJ))
[13:18:52] <cartman> /usr/local/android-ndk-r5/build/core/definitions.mk:  _OBJ_ASM_FILTERED := $$(patsubst %.o,%.filtered.s,$$(_ORG_OBJ))
[13:18:55] <cartman> mru: ^^
[13:20:37] <mru> and then OBJS = $(C_OBJS) $(S_OBJS) ...
[13:20:37] <mru> make then takes this list and searches for pattern rules and corresponding source files until it finds a match
[13:20:37] <mru> so it's much simpler to just list the object files directly
[13:20:38] <mru> cartman: if the build system is set up to take lists of source files there's nothing _you_ can do
[13:20:38] <mru> short of replacing the whole thing
[13:20:38] <mru> or working on something less annoying entirely
[13:20:58] <cartman> mru: I see
[13:21:17] <mru> oooh, worse than I imagined
[13:21:35] <mru> there's an eval somewhere in there too
[13:21:46] <cartman> mru: add magic-head.S to ffmpeg so they'll have to fix their crap to support it ;)
[13:21:55] <mru> and gratuituous _ prefixes
[13:23:30] <cartman> I will use my relink.sh crap for now
[13:23:53] <mru> at least you found the cause of the problem
[13:24:01] <cartman> mru: and reported too but
[13:24:12] <cartman> David Turner says it won't reorder them
[13:24:29] <cartman> contary to what I see
[13:25:00] <mru> it probably doesn't reorder .c files relative to each other
[13:25:17] <cartman> moves the *.S files at the end
[13:25:32] <cartman> yeah *.c files are ordered but not .S
[13:25:46] <mru> it orders *.c before *.S
[13:25:55] <mru> relative order within those groups is probably maintained
[13:26:01] <cartman> seems so
[13:27:25] <mru> btw, notice how michael goes on a rampage against me
[13:27:54] <cartman> I noticed how he dumped mplayer filter code in ffmpeg
[13:28:06] <mru> I knew that was coming
[13:28:21] * elenril sighs
[13:29:39] <kshishkov> mru: you can just ignore his mails without patches attached, procmail is your friend ;)
[13:29:43] <BBB> mru: let it go, for now... the comment was unnecessary
[13:30:07] <mru> I'm not going to reply
[13:30:55] <kshishkov> maybe you shouldn't have read it too
[13:33:03] <kshishkov> mru: obligatory non-XKCD quote http://dilbert.com/strips/comic/2010-12-13/
[13:33:53] <mru> kshishkov: oh please, use dilbert.com/fast
[13:34:15] <kshishkov> mru: noted
[13:44:20] <cartman> didn't know about /fast, no Flash yey
[13:45:16] <mru> http://news.ycombinator.com/item?id=2123511
[13:45:20] * kshishkov has Flash installed only one one of his computers so almost no concern
[13:45:44] <cartman> I knew there is a reason to hate Uncle Sam
[13:46:13] <kshishkov> thresh: http://static.businessinsider.com/image/4d382fad49e2aec008100000-590/the-peoples-standard.jpg
[13:46:28] <thresh> kshishkov: Мицгольщиной попахивает.
[13:47:10] <kshishkov> cartman: there's none. He's your best friend. US even produces Camel cigarettes to commemorate American-Turkish friendship (really!)
[13:47:35] <kshishkov> thresh: а ты официальное лого видел? Оно не просто попахивает
[13:48:39] <cartman> kshishkov: bleh :P
[13:49:18] <kshishkov> cartman: well, it improves official logo a bit
[13:49:43] <cartman> http://wikileaks.ch/static/gfx/graphic.png
[13:49:52] <cartman> Check the second embassy on the left
[13:50:25] <CIA-29> ffmpeg: Anton Khirnov <anton at khirnov.net> master * r75aded8328 ffmpeg/libavformat/id3v2.c:
[13:50:25] <CIA-29> ffmpeg: id3v2: don't overwrite existing tags
[13:50:25] <CIA-29> ffmpeg: Apparently some broken taggers prepend a new ID3v2 tag leaving the
[13:50:25] <CIA-29> ffmpeg: existing one intact. Our parser currently reads all tags and overwrites
[13:50:25] <CIA-29> ffmpeg: existing values with supposedly outdated ones.
[13:50:26] <CIA-29> ffmpeg: fixes issue2419
[13:50:27] <CIA-29> ffmpeg: Signed-off-by: Mans Rullgard <mans at mansr.com>
[13:50:27] <CIA-29> ffmpeg: Anton Khirnov <anton at khirnov.net> master * r46a2da7698 ffmpeg/libavformat/ (id3v2.c id3v2.h):
[13:50:28] <CIA-29> ffmpeg: id3v2: make ff_id3v2_parse static
[13:50:28] <CIA-29> ffmpeg: Signed-off-by: Mans Rullgard <mans at mansr.com>
[13:50:29] <CIA-29> ffmpeg: Georgi Chorbadzhiyski <gf at unixsol.org> master * rc0dd565304 ffmpeg/cmdutils.c: (log message trimmed)
[13:50:31] <CIA-29> ffmpeg: libavcodec minor version is > 99 so fix the formating
[13:50:31] <CIA-29> ffmpeg: libavcodec minor version is > 99 so when printing the library versions
[13:50:32] <CIA-29> ffmpeg: the output is a little bit broken:
[13:50:32] <CIA-29> ffmpeg:  libavutil 50. 36. 0 / 50.36. 0
[13:50:33] <CIA-29> ffmpeg:  libavcore 0. 16. 1 / 0.16. 1
[13:50:34] <CIA-29> ffmpeg:  libavcodec 52.108. 0 / 52.108. 0
[13:59:22] <cartman> mru: since the boss still didn't give me my tablet back, let me ask you how is Bsymbolic will help with my ofbp_codec_start problem?
[13:59:34] <cartman> mru: google is not helpful I tried
[13:59:35] <mru> it won't
[13:59:50] <cartman> mru: why do I use it then? :)
[13:59:53] <mru> I was just stabbing in the dark
[14:00:03] <mru> but it's a good thing to use regardless
[14:00:23] <mru> the real problem turned out to be object order, no?
[14:00:23] <cartman> mru: might it be due to the fact that I build a shared library not an application?
[14:00:32] <cartman> mru: nope, object order was fine :)
[14:00:36] <cartman> I manually fixed that
[14:00:39] <mru> oh, it's still not working?
[14:00:52] <cartman> mru: it wasn't working after I fixed the order
[14:00:56] <cartman> didn't try Bsymbolic yet
[14:01:23] <cartman> but avcodec.o has ofbp_codec section
[14:02:10] <wbs> anyone who happens to have a htc desire Z or HD (not the normal desire) that I could do some remote testing on?
[14:02:49] <mru> cartman: pastebin readelf -a on your .so
[14:03:00] <cartman> mru: ok
[14:05:32] <cartman> mru: http://cekirdek.pardus.org.tr/~ismail/readelf.txt
[14:05:54] <mru> ouch, that includes all of ffmpeg
[14:06:05] <cartman> static linking *cough*
[14:06:09] <mru> yeah
[14:06:19] <cartman>   1114: 006556f8     0 OBJECT  GLOBAL DEFAULT   16 ofbp_codec_start
[14:06:21] <mru> oh well, the info I was looking for is still in there
[14:08:21] <cartman> mru: and? :)
[14:10:51] <mru> cartman: looks like your compiler is ignoring attribute(used)
[14:11:03] <cartman> hmmm
[14:11:40] <cartman> mru: I see you use it in util.h
[14:11:48] <cartman> but this is just gcc hmmpf
[14:11:59] <mru> no, it's _android_ gcc
[14:12:14] <mru> do a normal arm build and compare the symbol tables
[14:12:24] <mru> you'll see ofbp_codec_avcodec in there too then
[14:12:41] <cartman> mru: ah so I am missing ofbp_codec_avcodec symbol?
[14:12:42] <cartman> only
[14:13:07] <mru> and the other magic ones
[14:13:35] <cartman> mru: allright
[14:13:37] <cartman> thanks
[14:13:54] <mru> try removing the static keywords in the DRIVER macro
[14:14:11] <mru> at least the middle one
[14:14:52] <cartman> mru: yep works
[14:15:06] <cartman> mru: shall I scream that such a basic thing doesn't work?
[14:15:14] <mru> yes
[14:15:33] <cartman> mru: thank you :)
[14:15:48] <mru> np
[14:16:05] <cartman> mru: ah Android also doesn't have posix_memalign, I replaced it with a memalign call fwiw
[14:16:24] <mru> that should be detected by configure
[14:16:35] <mru> oh, in omapfbplay
[14:16:41] <mru> I forgot I used it there
[14:16:50] <mru> and this is #ffmpeg-devel ...
[14:17:06] <mru> I suggest you bitch about that as well
[14:17:13] <cartman> mru: #omapfbplay-dev ? :)
[14:17:39] <mru> I've been thinking of renaming the thing actually
[14:17:43] <mru> call it ofbp or something
[14:17:53] <mru> it's not at all omap-specific anymore
[14:17:55] <cartman> mru: makes sense :)
[14:18:28] <cartman> now hopefully this thing will crash somewhere in my code now :D
[14:20:19] <cartman> I guess CodeSourcery gcc could be made to work on Android
[14:20:45] <mru> any gcc will work
[14:21:00] <cartman> mru: any gcc with arm support will do?
[14:21:05] <mru> should
[14:21:08] <mru> android uses eabi
[14:21:22] <cartman> hmmpf :(
[14:21:23] <cartman> :)
[14:21:27] <merbzt1> jannau: you drive a train? neat
[14:21:29] <mru> use their linker though
[14:22:08] <cartman> mru: okies
[14:22:32] <kshishkov> merbzt1: probably it's calced from their expression "fahren mit" but you don't care ;)
[14:23:58] <kshishkov> now to find an hotel there and get a briefcase of money and platinum credit card somewhere - it's Brussels after all
[14:41:38] <cartman> mru: indeed CodeSourcery gcc works as expected with the static keyword
[14:48:09] <jannau> av500: full of fail: http://www.heise.de/newsticker/meldung/Entwicklung-der-Codec-Bibliothek-FFmpeg-unter-neuer-Fuehrung-1172693.html
[14:48:40] <jannau> "Hinweis auf Stefan Niedermayer als Projektleiter"
[14:48:47] <mru> lol
[14:49:18] <av500> we all know that attila is bundesprojektkanzler now
[14:49:28] <thresh> yeah, everyone know he was a ProjektFuehrer
[14:50:01] <lyakh> ok, got fate running... so far all tests fail:) I think, I'll document fate setup for cross-build / cross-testing, do we want it somewhere centrally, or I can just post it to my blog;)
[14:50:19] <mru> lyakh: what are you running it on?
[14:50:31] <lyakh> mru: sh7724
[14:50:44] <mru> hmm, sh4 isn't very well tested I guess
[14:50:44] <av500> lyakh: I have some SH1 EVMs :)
[14:50:55] <mru> I have an sh4 board but no jtag to get it running
[14:51:07] <lyakh> mru: I guess your guess is right;)
[14:51:07] <mru> st7109 chip
[14:51:20] <av500> mru: I have that
[14:51:23] <av500> and the jtag
[14:51:27] <lyakh> av500: sh1... don't think it's going to help much here;)
[14:51:36] <av500> lyakh: cmon, be creative
[14:51:42] <lyakh> lol
[14:51:47] <mru> lyakh: use 4 of them
[14:51:55] <mru> then you'll have an shshshsh4
[14:52:00] <av500> mru: for a combined 1MB of ram, yes
[14:52:03] <mru> or is that an sssshhhh4
[14:52:14] <lyakh> sh4^4
[14:52:19] <mru> the successor to ssssssse3
[14:52:48] <mru> av500: you have an st microconnect or similar?
[14:52:58] <av500> mru: er, no idea
[14:53:01] <av500> I have something
[14:53:28] <lyakh> so, why are they failing? is there a timeout? or precision insufficient? or little RAM?
[14:53:32] <lyakh> error 127
[14:53:43] <mru> that's command not found
[14:53:57] <lyakh> EKEYEXPIRED:)
[14:54:04] <mru> what command is it actually trying to run?
[14:54:07] <mru> make fate V=1
[14:54:38] <lyakh> what command not found?... what PATH is it getting? not like for the usual shell? /usr/local/bin?
[14:54:50] <mru> that's what I'm trying to figure out
[14:54:53] <av500> mru: yup, microconnect
[14:55:00] <mru> but I need the output of "make fate V=1"
[14:55:02] <mru> av500: v2?
[14:55:14] <mru> iirc that's required for the 7109
[14:55:30] <av500> well, it was given with the 7109
[14:55:44] <lyakh> yes, but wait... I have an idea...:)
[14:55:59] <mru> av500: what does it look like? grey plastic or white metal with black front panel?
[14:56:10] <av500> metal
[14:56:35] <thresh> av500: so, what about 101? :)
[14:56:36] <mru> what kind of connector? IDC or something scsi-like?
[14:57:13] <av500> for jtag? 29pin idc
[14:57:16] <av500> 28
[14:57:31] <mru> huge brick of a psu?
[14:57:36] <av500> u bet
[14:57:41] <mru> it's a v1 then
[14:57:54] <av500> :(
[14:57:59] <av500> 8.5A
[14:58:11] <mru> if it came with the board, it must be good enough
[14:59:09] <av500> we never even powered it
[14:59:14] <cartman> wbs: could you remind me where was AOSP bugzilla?
[14:59:23] <mru> av500: wtf do you have it for then?
[14:59:29] <av500> mru: flickr?
[14:59:35] <mru> fair enough
[14:59:42] <av500> mru: remeber the tale of the 2 laptops
[14:59:46] <av500> ppl tend to leave stuff here
[14:59:49] <wbs> cartman: http://code.google.com/p/android/issues/list
[15:00:07] <cartman> wbs: thanks
[15:00:18] <av500> wbs: for iOS is ../plist?
[15:00:28] <wbs> av500: lol
[15:00:29] <cartman> wbs: ah I was looking for something NDK specific one
[15:00:54] <wbs> cartman: dunno if that fits there.. or just mail to android-ndk and nag, or submit a patch in gerrit
[15:01:05] <cartman> wbs: I see
[15:01:08] <cartman> good old ways :p
[15:01:49] <lyakh> does it need samples on the host and transfers them to the target, or do they have to be on the target?
[15:02:27] * kierank lols at michaels fork
[15:02:33] <mru> lyakh: simplest is to nfs-mount build and samples dirs from host to target
[15:02:47] <mru> lyakh: at the same path
[15:03:01] <lyakh> aha, so, samples too... but that path in the config - is it for both?... oooh....
[15:03:22] <mru> if you mount the samples at the same location on both it will work
[15:03:35] <lyakh> can it work if locations differ?;)
[15:03:35] <mru> the target also needs r/w access to the build dir
[15:03:43] <lyakh> damn...
[15:03:44] <mru> lyakh: not presently
[15:03:51] <lyakh> that's all dead-obvious
[15:04:13] <mru> the build tree can be mounted at different paths
[15:04:20] <benoit-> moin
[15:04:25] <mru> hi benoit-
[15:05:12] <benoit-> wow... It's been a while since I last came.
[15:05:32] * mru chooses not to interpret that imaginatively
[15:05:36] <benoit-> I totally missed everything in the last months... at least I had things to read when I came back!
[15:05:38] <benoit-> heh
[15:05:38] <andoma> lol
[15:05:41] <benoit-> hehe
[15:06:34] <DonDiego> benoit-: hi
[15:06:45] <DonDiego> benoit-: well, i guess there are news...
[15:07:21] <benoit-> I'm trying to integrate them
[15:10:56] <lyakh> ok, so, I need the install path, build dir, and samples nfs-mounted. install path is ok, samples have to be at the same location and specified in "samples=" config var. build on host is specified in "work_dir=", where is it specified for the target?
[15:11:18] <mru> you don't need to install at all
[15:11:29] <mru> the tests run out of the build tree
[15:11:46] <mru> I suggest starting w/o shared libs as they complicate things a bit
[15:12:11] <KotH> .o0(i should get my subject to pay taxes to me... in swiss chocolate)
[15:12:19] <KotH> s/subject/subjects/
[15:13:32] <lyakh> mru: huh... but running tests/fate.sh does a "make install"
[15:13:39] <lyakh> and I do use shared libs
[15:14:12] <lyakh> if I use "make fate" - how do I specify the config-file?
[15:14:18] <mru> it does a make install a) to make sure this works, and b) because it makes shared libs easier to use
[15:14:20] <lyakh> will it then skip install?
[15:14:41] <mru> you don't need to use the fate.sh script at all if you run make fate manually
[15:15:09] <mru> the fate.sh script is mostly intended for automatic runs reporting to a server
[15:15:16] <lyakh> ok, so, as long as those shared libs end up under /usr/local/lib and ld.so finds them, then it's ok
[15:15:35] <mru> do yourself a favour and skip the shared libs for now
[15:15:48] <lyakh> ok, how do I specify the config to "make fate" then?
[15:16:22] <mru> you run configure with whatever arguments necessary
[15:19:42] <av500> why does mp still use libmpeg2?
[15:21:32] <lu_zero> because this way you can do stuff with libmpeg2 only
[15:21:34] <lu_zero> and nothing else
[15:22:00] <av500> lu_zero: ah, for fedora :)
[15:28:22] <j-b> av500: many people complain since we've moved from libmpeg2 to lavc
[15:28:34] * lu_zero reads the emails
[15:28:37] <lu_zero> j-b: why?
[15:28:42] <kshishkov> j-b: why?
[15:28:51] <lu_zero> beside the small glitches you fixed and I reported in rtsp?
[15:28:52] <j-b> video quality, sharpness
[15:29:06] <lu_zero> really?
[15:29:10] <j-b> many more issues with DVDs
[15:29:17] <bilboed-pi> same thing for gst. Switched to the ffmpeg dec being the default, and had to quickly switch back to libmpeg2
[15:29:18] <j-b> and those are remarks from broadcasters and so on
[15:29:35] <j-b> but we keep lavc, because it doesn't crash
[15:30:10] <mru> seeing as both are allegedly conforming decoders, my first suspicion would be the idct
[15:30:15] <kshishkov> do you mean lavc does not decode mpeg2 properly or that libmpeg2 has videophile mode?
[15:30:20] <mru> since that's the only part allowed to vary
[15:30:24] <kierank> kshishkov: I was thinking latter
[15:30:37] <mru> lavc does have a shitty mmx2 idct
[15:30:45] <mru> if that one is chosen you might get bad picture
[15:31:03] <j-b> I don't know
[15:31:13] <mru> the one that does everything in 16-bit all the way
[15:31:23] <mru> that obviously loses precision
[15:31:27] <j-b> but seeing the user base of VLC, and the complaints, it isn't just one guy, but quite a common reproach
[15:31:41] <mru> I'd like to see some actual images
[15:31:46] <mru> pix or it didn't happen
[15:31:49] <cartman> need bugreports ;)
[15:31:58] <av500> j-b: find some user with a clue and have him report here
[15:31:59] <j-b> exactly why you haven't seen one
[15:32:09] <j-b> too afraid to post
[15:32:13] <kierank> mru: or in x264, samples and/or command line or it doesn't happen
[15:32:13] <av500> j-b: we promise not to eat him
[15:32:28] <j-b> av500: but, over the last year, I've seen quite a number of people
[15:32:37] <j-b> many people use older version, or bump back the libmpeg2 module
[15:32:44] <av500> "seen" does not count
[15:33:09] <av500> we can only sit here and believe our code is da greatest until you tell us
[15:33:34] <kshishkov> kierank: since we don't encode command line is not necessary
[15:33:41] <j-b> you know me, if I had time+screenshots, the bug would be posted already...
[15:33:49] <kierank> kshishkov:
[15:33:52] <j-b> av500: I am just reporting something that many people complained about.
[15:33:56] <kierank> kshishkov: that's the rule for x264 crashes/bugs
[15:34:01] <cartman> j-b: a buggy sample would be enough actually
[15:34:05] <mru> j-b: we're not accusing you of anything
[15:34:05] <j-b> av500: and I had my last fight with walken one year ago
[15:34:11] <kshishkov> av500: may I also say that I found lavc MP3 decoder to decode MPEG-2/2.5 audio wrongly?
[15:34:14] <av500> christopher?
[15:34:23] <mru> j-b: but this is the first I've heard of this issue
[15:34:37] <j-b> and I'll take back the maintainership of those libs anyway (beside)
[15:34:43] <j-b> av500: yes, I think so
[15:34:44] <kshishkov> kierank: I believe you (and that's quite reasonable rule too)
[15:34:55] <j-b> I am glad bilboed-pi has seen the same
[15:34:57] <thresh> :)
[15:35:41] <kierank> speaking of -philes this is the greatest audiophile thread ever http://forum.doom9.org/showthread.php?p=1472980#post1472980
[15:36:08] <kshishkov> j-b: ask thresh, what proverb "не трожь говно - вонять не будет" means and how it applies to Walken
[15:36:28] <j-b> kshishkov: I will
[15:36:29] <KSHawkEye> Hey, what is this I hear about a ffmpeg mutiny?
[15:36:53] <thresh> haha
[15:37:20] <KSHawkEye> ?
[15:37:21] <kierank> yarrr
[15:38:44] <lyakh> ok, now it seems to be doing something...
[15:40:02] <lyakh> hey, any specific event planned at FOSDEM?
[15:40:47] <av500> theres no ff booth this year
[15:40:56] <av500> mru and me will be at the beagle booth
[15:41:30] <kshishkov> well, mru is synonimous both with BB and FF :)
[15:41:35] <DonDiego> bbl
[15:41:39] <lyakh> is Diego Biurrun around?
[15:41:47] <av500> not any more
[15:41:54] <lyakh> that was him then? ok:)
[15:42:10] <lyakh> he asked about anyone passing via Aachen...;)
[15:42:12] * cartman goes to FOSDEM to snag a beagleboard xM from av500 
[15:42:22] <av500> lyakh: ah right
[15:42:37] <lyakh> shall I bring my bbxm to demonstrate video?...
[15:42:54] <av500> lyakh: we'll have plenty of them
[15:42:56] <thresh> so you're going to start the ffparty in the train
[15:43:12] <cartman> av500: send one my way
[15:43:21] <kierank> [15:42] cartman goes to FOSDEM to snag a beagleboard xM from av500  --> is this true
[15:43:27] <lyakh> av500: don't think you have that many of them doing _direct_ (not USB) video...;)
[15:43:40] <cartman> kierank: nah I am not coming you can relax
[15:43:41] <cartman> :p
[15:43:41] <av500> ah, video in
[15:43:46] <lyakh> yep
[15:43:48] <av500> lyakh: sure bring one
[15:43:55] <kierank> cartman: i don't care about you. i care about the free beagleboards ;)
[15:44:07] <av500> kierank: cartman's wet dreams
[15:44:24] <cartman> kierank: av500 and free is just an oxymoron
[15:44:39] <kierank> cartman: does he charge for air?
[15:44:48] <av500> 50% off
[15:44:59] <cartman> kierank: you'll need air when you run away from him :P
[15:45:00] <av500> unless you want it "fresh"
[15:45:09] <kierank> lol
[15:46:24] <kshishkov> av500: please reserve a pandaboard for me then ("free" is not necessary)
[15:46:43] <av500> kshishkov: I wish I could
[15:46:46] * kierank is considering going because of cheap eurostar
[15:47:06] <av500> so, the less booth we have, the more ffdevs come....
[15:47:28] <j-b> of course
[15:47:36] <j-b> because noone wants to do the boring work
[15:47:42] <j-b> and booths are boring
[15:47:51] <av500> you need boothbabes
[15:47:53] <kierank> or maybe cebit will be more interesting
[15:48:01] <j-b> people attending fosdem already know the project
[15:48:03] <av500> kierank: wear a suit
[15:48:10] <thresh> there could be a GwOC task for a booth
[15:48:13] <j-b> and you are not a distro to fight with the next one over CD
[15:48:14] <kierank> av500: for cebit?
[15:48:28] <kshishkov> j-b: compared to VLC booth, FFmpeg booth at LT was overstaffed. Even you hired somebody to go there instead of you!
[15:48:29] <kierank> or for fosdem
[15:48:30] <andoma> are there places at fosdem to sit and hack if you wanna do that?
[15:48:43] <av500> andoma: yes
[15:49:05] <kshishkov> av500: can I get free axe for that there?
[15:49:41] <kierank> av500: why wear suit?
[15:49:53] <av500> its a suits thing
[15:50:16] <cartman> mru: yay now it crashes somewhere else :D
[15:50:26] <spaam> arpi on the ml ;DD
[15:50:43] <kierank> av500: k
[15:50:52] <av500> kierank: well, you can do without
[15:51:06] <av500> havent been to cebit since 2001 or so
[15:51:11] <av500> or 02
[15:51:16] <kierank> someone told me there are lots of chinese that tell you they can do what you're doing for 10 times cheaper
[15:51:20] <kierank> at cebit
[15:51:23] <j-b> kshishkov: LT and FOSDEM are not the same
[15:51:45] <av500> kierank: yes, huge chinese presense
[15:52:05] <kierank> many women?
[15:53:09] <av500> chinese booth babes
[15:53:22] <kshishkov> "ffmpeg and mplayer should be merged completely together" <- I've talked about making FFplayG2 out of MPlayer for ages!
[15:53:38] <av500> +1
[15:54:33] * kierank will dress up like he is a ceo then
[15:55:15] <thresh> Ж))
[15:56:14] <kshishkov> kierank: and I'll dress like ordinary FFmpeg dev :P
[15:56:57] <kierank> i'll pretend to be your boss kshishkov
[15:57:03] <av500> kierank: http://img.hexus.net/v2/internationalevents/cebit_hannover_2005/store/cebit38.jpg
[15:57:23] <av500> it was obviously a cold year
[15:57:37] <kshishkov> av500: judging from Intel logo they really need babes to sell their products
[15:58:49] <av500> serbian babes are more modest: http://www.sol.rs/images/photos/cebit2004_crowd_front-big.jpg
[15:59:04] <kierank> lol
[15:59:38] <thresh> lol @ a'rpi mail
[15:59:48] <thresh> the second one
[15:59:50] <bilboed-pi> :)
[15:59:55] <lu_zero> where?
[16:00:11] <thresh> the same place
[16:00:25] <thresh> FFMMppeegg devel mailing list
[16:00:47] <thresh> or should I say ffmpeg and ffmpeg development mailing list? :)
[16:01:06] <kshishkov> still, Arpi+MN ~= binary codec loader and libmpeg2 in lavc (may be "revolting" instead of "revolutionary" though)
[16:01:33] <av500> one more time he says leader and I will leave for good....
[16:01:48] <lyakh> ok, there are even not too many errors so far;)
[16:01:53] <j-b> av500: leave where?
[16:02:04] <thresh> gst, obviously
[16:02:06] <thresh> what else!
[16:02:13] <av500> j-b: no idea, does vlc take ppl
[16:02:15] <av500> ?
[16:02:26] <av500> i could work on libmpeg2...
[16:02:27] <kshishkov> av500: what do you have against our Josip Broz Micho?
[16:02:55] <j-b> av500: we do. and libmpeg2 is not even a VideoLAN project... Walken forbids us to work on it...
[16:03:08] <thresh> i have a cunning plan
[16:03:11] <cartman> mru: I/OMAPFBPLAY( 3708): Error allocating frame buffers: 67043328 bytes.
[16:03:17] <cartman> mru: too many bytes? :D
[16:03:25] <av500> cartman: 64MB?
[16:03:26] * kshishkov renames thresh to baldrick
[16:03:30] <cartman> av500: yeah
[16:03:33] <thresh> what if we import libmpeg2 into git, host it on videolan and change the URL in website's svn?
[16:03:34] <cartman> mru: I/OMAPFBPLAY( 3708): Using 124 frame buffers, frame_size=540672.
[16:03:40] <thresh> kshishkov: yes, milord!
[16:03:45] <av500> thresh: let mn invade in winter and wait for spring?
[16:04:08] <cartman> looks wrong
[16:04:28] <lu_zero> 17:01 <+av500> one more time he says leader and I will leave for good....
[16:04:30] <lu_zero>  uh?
[16:04:36] <cartman> 0.5mb for each frame
[16:05:18] <av500> lu_zero: personally, I find michael referring to himself as "leader" all the time the most offensive...
[16:05:49] <kshishkov> av500: do you think he should assume proper German title instead?
[16:06:05] <lu_zero> I feel that arpi should just shut up btw
[16:06:14] <av500> kshishkov: I think he does not need to use that term at all
[16:06:27] * j-b is trying to not reply
[16:06:53] <kshishkov> av500: well, MÃ¥ns told him that few times, see the result
[16:07:20] <kshishkov> lu_zero: who cares about him? Or who has heard anything about him?
[16:07:21] <bilboed-pi> is libmpeg2 being maintained ?
[16:07:29] <kshishkov> lu_zero: for the last N years?
[16:08:07] <kshishkov> bilboed-pi: we call it a guard dog on haystack situation - maintainer only prevents everybody else from touching it and does nothing else
[16:08:19] <bilboed-pi> reminds me of another project
[16:08:29] <bilboed-pi> +1 for a git libmpeg2 mirror though
[16:08:37] <kshishkov> which one?
[16:09:02] <j-b> bilboed-pi: yes, it is maintained, more or less
[16:09:28] <j-b> bilboed-pi: and we'll switch it to git, sometime soon... When I can take the time to tell walken "fuck"
[16:10:04] <kierank> who's walken
[16:10:09] <kierank> also j-b how do i get a ticket to cebit
[16:10:10] <bilboed-pi> last modification... 210days ago
[16:10:24] <lyakh> is Luca Barbato here?
[16:10:36] <lu_zero> lyakh: hi
[16:10:36] <av500> lyakh: yep
[16:10:50] <kshishkov> kierank: the guy who complicated situation with yuv2rgb for us
[16:10:53] <lyakh> lu_zero: hi, sorry, didn't understand your question...
[16:11:05] <lu_zero> which one?
[16:11:17] <lyakh> those macros _are_ of course sh4-specific - their implementation that is
[16:11:23] <j-b> bilboed-pi: of course, do you have any patches and complaints?
[16:11:27] <lyakh> lu_zero: regarding the sh4 mp3 optimization
[16:11:34] <j-b> bilboed-pi: it applies patches when patches come
[16:11:45] <thresh> so walken is not human
[16:11:55] <j-b> he isn't
[16:12:10] <lu_zero> lyakh: ah
[16:12:13] <lyakh> lu_zero: but the addition of those macros to the decoder file doesn't break anything - any other platform
[16:12:16] <bilboed-pi> j-b, just wondering that's all
[16:12:17] <kshishkov> kierank: http://www.fosdem.org/2011/faq I can sell you Fosdem ticked for fifty quid though
[16:12:38] <lu_zero> lyakh: yes, the question is if those are so useful it would be better to implement them on the other arches
[16:12:56] <cartman> memalign fails
[16:12:56] <j-b> bilboed-pi: it decodes mpeg2 quite well, and has one major issue, that is still not fixed, but appart from that, i don't know what would need to be in.
[16:12:57] <lu_zero> since from what I read those are just specializations of the generic macro
[16:12:58] <cartman> hmmpf
[16:13:17] <lyakh> lu_zero: whether anyone else can benefit from them - maybe, if there are arches, that have similar multiply-and-accumulate instructions
[16:13:50] <peloverde_> bilboed-pi: thanks for thw quick response on qtdemux
[16:14:09] <bilboed-pi> peloverde_, it'll be in the release also :)
[16:14:28] <lyakh> lu_zero: implement for other arches - well, if anyone has those arches and is interested in doing that... sure, why not?;)
[16:14:37] <mru> lyakh: I think that approach to optimising the mp3 decoder is a dead end
[16:14:48] <lyakh> mru: why?
[16:15:18] <mru> you'd get better results by writing the entire windowing loop in asm
[16:15:27] <mru> and the dct
[16:15:38] <lyakh> mru: I cannot say about this specific loop
[16:15:51] <lyakh> but from what I've seen why trying to optimize some other paths
[16:16:00] <lyakh> the gcc is pretty damn good at that
[16:16:06] <mru> I've been toying with that loop in the past
[16:16:06] <lyakh> or I am way too bad...
[16:16:11] <mru> and gcc is pretty fucking shit at it
[16:16:41] <lyakh> mru: what specifically does it screw up?
[16:16:55] <lu_zero> mru: maybe gcc for sh4 isn't that bad nowadasy
[16:16:56] <cartman> mru: why would memalign return errno 25?
[16:17:07] <lu_zero> nowadays =P
[16:17:55] <cartman> mru: and error 25 is "Not a typewriter"
[16:17:56] <cartman> wtf lol
[16:18:07] <lyakh> it is a bog-standard "for" loop... what can be so special about it?
[16:18:27] <mru> lyakh: gcc can mess up in any number of ways
[16:18:51] <mru> most common are excessive stack load/store and piss-poor insn scheduling
[16:19:29] <lyakh> mru: yes, I thought the same about other paths...
[16:19:40] <mru> I don't know about sh4, but on both arm and ppc gcc compiles that loop into utter crap
[16:19:43] <lyakh> but optimizing them didn't bring a 1% improvement, really...
[16:19:53] <lyakh> ok, so, what I could do
[16:20:16] <lyakh> I could extract the content of that loop into a function in a separate file
[16:20:21] <lyakh> to prevent inlining;)
[16:20:28] <lyakh> and then look at asm...
[16:20:40] <lyakh> and also look at it with the normal version
[16:21:23] <lyakh> but I really don't think saving a couple of loads / stores would bring any significant result...
[16:21:37] <mru> I'm not talking about a couple
[16:21:48] <mru> I'm talking about reducing the code size by 50%
[16:22:34] <lyakh> mru: sorry, don't think this would work. Looking at that loop - apart from those two macros, that already are asm, there's very little C left...
[16:22:41] <lyakh> ok, let me have a look at the asm...
[16:22:47] <mru> enough for gcc to mess up
[16:22:57] <mru> and gcc tends to mess up worse around inline asm
[16:25:35] <mru> lyakh: I don't mean to criticize what you've done, but I think if we worked together we could make it even better
[16:25:37] <kshishkov> you still can't forgive that little trick GCC plays on storing float into indexed array, do you?
[16:25:50] <mru> grr
[16:26:25] <kshishkov> just don't say you want GCC devs to work on Hurd instead
[16:26:59] <mru> hmm, I'm not sure who'd be most punished by that
[16:28:09] <kshishkov> weren't you saying Hurd is a kind of bit-bucket for devs who could cause harm elsewhere?
[16:28:26] <mru> I may have said something to that effect
[16:29:43] <kshishkov> so it's not punishment, it's win-win-gnu situation
[16:30:57] <lyakh> mru: ok, even if you're right and that loop can be optimized (no, I haven't found anything wrong in the asm yet) - can we not first commit the first step - as in my patch but with a copy for sh4, and then look at that loop in the second step?
[16:32:20] <lu_zero> lyakh: the idea is that might be a quick win
[16:33:22] <lyakh> lu_zero: it's not _that_ quick, with all those round-samples...
[16:34:21] <mru> the whole apply_window_mp3_c function is easy enough to write entirely in asm
[16:36:25] <lyakh> sure, why don't we rewrite the complete ffmpeg in asm?;)
[16:36:35] <mru> that's not trivial
[16:36:41] <mru> but it would be 50% faster
[16:37:04] <mru> there are even hooks in place to write that very function in asm
[16:37:13] <lyakh> CPU time is cheap, developer time is expensive...
[16:37:34] <mru> cpu time happens every time you play a song, dev time happens once
[16:37:46] <superdump> such functions as windowing are just begging for asm
[16:38:53] <lu_zero> let me see better
[16:39:53] * lu_zero wonders why ff_mpa_synth_filter does call apply_window_mp3_c
[16:40:01] * mru was just looking at that too
[16:40:19] <lu_zero> lyakh: you made us discover _lots_ of stuff ^^;
[16:40:25] <mru> I remember michael rushing in the float stuff without doing everything properly
[16:40:55] <lyakh> lu_zero: you're welcome, where can I send the bill?;)
[16:41:10] <mru> lyakh: to renesas
[16:41:42] <lyakh> mru: hm, I'll think about it;)
[16:42:04] <mru> seriously, if they care they should
[16:42:39] <mru> ARM does...
[16:44:03] <av500> too bad goog did not pick sh4 for android...
[16:44:19] <lu_zero> apply_window_mp3 is just implemented for ppc and x86 ....
[16:45:34] <lyakh> av500: there's android on sh...
[16:45:47] <mru> and only float version
[16:47:56] <av500> lyakh: I know
[16:48:02] <av500> its there on mips too
[16:52:28] * lu_zero will port it on amd64 just to make the world more weird
[16:53:31] <lu_zero> or not
[16:54:10] <lyakh> better to atmega;)
[16:54:29] <mru> ugh, this is not pretty
[16:54:56] <lu_zero> mru: MPA_INT?
[16:55:09] <mru> no, that's just a minor blemish
[16:55:28] <mru> the int and float versions of ff_mpa_synth_filter have different prototypes
[16:55:30] <lu_zero> DonDiego: do you remember which was last year hotel?
[16:55:53] <DonDiego> i was in a youth hostel
[16:56:00] <mru> one takes an MPADecodeContext*, the other does not
[16:56:01] <DonDiego> forgot the name of course
[16:56:07] <lyakh> DonDiego: hi, so, you're in AC too?
[16:56:22] <lu_zero>             RENAME(ff_mpa_synth_filter)(
[16:56:30] <lu_zero> why that makes me shiver?
[16:56:33] <DonDiego> lyakh: yes, why?
[16:56:45] <lyakh> DonDiego: I just replied to your mail on the list
[16:57:05] <lyakh> I'll (probably) also be going to FOSDEM from AC (and back)
[16:57:11] <mru> DonDiego: http://maps.google.co.uk/?ie=UTF8&ll=50.853046,4.358246&spn=0.006184,0.01339&z=17&iwloc=lyrftr:m,8831955899299500395,50.853039,4.358225
[16:57:11] <lyakh> I _might_ be driving...
[16:57:12] <jannau> lu_zero: it gives you libswscale nightmares?
[16:57:15] <mru> that's the place you were in
[16:57:21] <lu_zero> jannau: yup
[16:57:26] <lyakh> DonDiego: don't know the times yet...
[16:57:51] <lyakh> DonDiego: do you want to be there from hour 1 to hour last?
[16:58:06] <av500> DonDiego: get on the beer train!
[16:58:17] <mru> the friday beer event is not to be missed
[16:58:27] <mru> that's half the reason for going at all
[16:58:28] <lyakh> heh, yeah, sure, that's a choice;)
[16:58:46] <DonDiego> cool
[16:58:56] <DonDiego> but yes, the beer event is not to be missed
[16:59:06] <lyakh> ok, then we'll meet there;)
[16:59:20] <mru> delirium ftw
[16:59:50] <thresh> mru: when are you coming to Brussels?
[16:59:57] <mru> on the friday
[17:00:05] <DonDiego> hmm
[17:00:14] <mru> thresh: where are you staying?
[17:00:27] <DonDiego> michael claims to always follow the rules now...
[17:00:35] <thresh> mru: the same hotel as all videolaners, http://www.accorhotels.com/gb/hotel-7863-mercure-brussels-center-louise/index.shtml
[17:00:49] <thresh> i'm coming on Thursday
[17:00:58] <DonDiego> lyakh: where are you staying?
[17:01:07] <lyakh> no idea yet...
[17:01:09] <thresh> that reminds me i need to book it :)
[17:01:14] <jannau> can anyone please proof read http://pastie.org/1481354
[17:01:18] <lyakh> I was waiting for the time-table
[17:02:09] <DonDiego> oh, arpi posting
[17:02:16] <BBB> hm... so now two h264 files give different output in emu_edge vs. normal decoding
[17:02:17] <DonDiego> shall i skip reading?
[17:02:22] <BBB> and both re 4:0:0 files
[17:02:25] <DonDiego> nah, it will be the usual flames :)
[17:02:25] <BBB> DonDiego: please do
[17:03:01] <mru> thresh: that's not very central...
[17:03:28] <DonDiego> BBB: skip reading?
[17:03:32] <lu_zero> the price is comparable to mru's
[17:03:32] <BBB> DonDiego: yes
[17:03:42] <lu_zero> mru: remind me yours
[17:03:42] <DonDiego> too late, but it's amusing in any case..
[17:03:56] <lu_zero> DonDiego: he didn't meant to send it to the list
[17:03:56] <DonDiego> arpi back, michael will love that...
[17:03:57] <mru> lu_zero: st nicolas, 75EUR per night
[17:03:59] <BBB> a simple way to "support" 4:0:0 files is to simply set DC_128 pred mode to be defined as zero, because then all chroma samples are sety to 128 by default = gray
[17:04:03] <BBB> what do people think of that?
[17:04:05] <BBB> it's a hack, I admit
[17:04:10] <BBB> but who cares :-p
[17:04:34] <lu_zero> in fact it is arpi in the email is less caustic than usual
[17:04:56] <lu_zero> s/it is//
[17:05:04] <BBB> hm, maybe I can fix it some other way
[17:05:19] <mru> lu_zero: where are you staying?
[17:05:55] <mru> jannau: didn't you post that on the ml already?
[17:06:10] <lu_zero> st nicolas seems overall better
[17:06:19] <thresh> mru: but should be pretty close to fosdem place
[17:06:31] <mru> distance to delirium is more important
[17:06:46] <lu_zero> DonDiego: single and double cost the same, want to share?
[17:07:04] <BBB> mru: any more comments on ruggles' patches? I'm about to commit them
[17:07:08] <thresh> haha
[17:07:16] <BBB> (want to get used to being a patch monkey, so need to figure out how that works)
[17:07:19] <mru> BBB: reading them now
[17:07:29] <jannau> mru: yes, but now hopefully without spelling errors
[17:07:44] <mru> BBB: my mail reader can pipe the message directly to git am
[17:07:47] <mru> or any other command
[17:07:48] <av500> thresh: fosdem is one shared taxi away
[17:07:50] <mru> very useful
[17:08:04] <DonDiego> lu_zero: yes, arpi is surprisingly calm - probably because he thought he was not writing to the list ;)
[17:08:13] <av500> crawling to hotel after beer, priceless
[17:08:19] <mru> jannau: looks good
[17:08:32] <thresh> av500: mmm true
[17:08:45] <thresh> and cheaper than that mercure
[17:08:46] <mru> to finish off with another beer in the hotel bar
[17:08:59] <lu_zero> BBB: I think mr queues patches in a mail box and then issues git-am over it
[17:09:01] <av500> thresh: at least in paris, mercure is expensive
[17:09:03] <lu_zero> mru
[17:09:14] <DonDiego> lu_zero: share a room, sure, why not...
[17:09:16] <j-b> av500: it is expensive.
[17:09:17] <mru> no
[17:09:24] <DonDiego> lyakh: you sure you will drive?
[17:09:37] <lyakh> DonDiego: not yet
[17:09:40] <j-b> av500: but was the first hotel, near ULB, where we could get easily 10 people and under 75EUR
[17:09:40] <mru> I git am them directly from mail reader into staging branch
[17:09:42] <DonDiego> maybe we can pick up reinhard if he comes to aachen by train
[17:09:45] <av500> thresh: but I saw j-b has a nice credit card
[17:09:55] <thresh> av500: i'm paying for my hotels
[17:09:59] <av500> j-b: under75 is cheap
[17:09:59] <lu_zero> j-b: under 75eur/night?
[17:10:01] <mru> when I say "queued" it means I've applied it to my repo but not pushed yet
[17:10:07] <lu_zero> ah
[17:10:07] <thresh> j-b only pays for my plane tickets :)
[17:10:08] <jannau> should we added: another signed-off-by: or reviewed-by line for commits reviewed by somebody else?
[17:10:13] <BBB> mru: can gmail do that?
[17:10:24] <av500> BBB: mru and gmail?
[17:10:26] <mru> BBB: wishful thinking
[17:10:27] <jannau> should we add
[17:10:42] <lu_zero> hi j0sh_
[17:10:44] <BBB> hi j0sh_ - we should update you on some stuff :-p
[17:10:57] <lu_zero> a _small_ number of details ^^;
[17:11:02] <av500> j0sh_: you now report to KotH
[17:11:29] <BBB> can I c/p the patch from a patch file into a vim termianl window and then run git-am on that?
[17:11:29] <j-b> av500: I paid 75EUR for the double queen beds and 68EUR for the king bed
[17:11:36] <BBB> what is git-am anyway
[17:11:38] <av500> j-b: cool
[17:11:45] <j-b> av500: and I paid for all travels, of course
[17:11:45] <mru> it's cool
[17:11:54] <av500> j-b: you are a great "leader"
[17:11:57] <lu_zero> BBB: git am and git format-patch
[17:11:58] <thresh> j-b, the millionaire
[17:12:10] <j-b> av500: but the hotel is on a 10minutes ride on the tram94 to ULB
[17:12:22] <j-b> so it was the best solution
[17:12:24] <lu_zero> so if you can manage to get the emails in a mbox
[17:12:50] <lu_zero> git am mbox applies all of them
[17:12:53] <BBB> Patch does not have a valid e-mail address....
[17:12:56] <BBB> what does that mean
[17:13:02] <BBB> should I use git format-patch?
[17:13:04] <mru> it means you got only the attachment
[17:13:06] <j-b> BBB: git am -s or, if doesn't work, edit patch git apply  and then git commit -s --author
[17:13:22] <mru> ruggles seems to be sending the comment as email body and the diff as attachment
[17:13:23] <lu_zero> BBB: do you have imap configured on your gmail?
[17:13:30] <BBB> yes
[17:13:40] <mru> I can take care of this patch
[17:13:41] <BBB> but I use the web-interface
[17:13:41] <lu_zero> so you can access gmail through imap
[17:13:47] <BBB> ok, I'll let mru do it for now
[17:14:04] <mru> BBB: no more comments from you either?
[17:14:12] <lu_zero> use a label for the emails and then configure a client like imapsync to monitor that label/directory
[17:14:12] <BBB> both are good
[17:14:23] <BBB> I'll comment on 1/2 but it's a question, it should be queued anyway
[17:14:28] <CIA-29> ffmpeg: Janne Grunau <janne-ffmpeg at jannau.net> master * re5fe65512b ffmpeg/libavformat/mpegtsenc.c:
[17:14:28] <CIA-29> ffmpeg: mpegtsenc: prefer metadata keyed with "service_name"
[17:14:28] <CIA-29> ffmpeg: title metadata is only used as fallback if no service_name is available.
[17:14:28] <CIA-29> ffmpeg: Signed-off-by: Janne Grunau <janne-ffmpeg at jannau.net>
[17:15:40] <DonDiego> lu_zero: what sort of room do you want to share?
[17:15:56] <mru> the presidential suite of course
[17:16:08] <DonDiego> this channel is getting busy - because of the news?
[17:16:08] <av500> DonDiego: one with large dressing mirror
[17:16:21] <lu_zero> looking at the options now ^^
[17:16:30] * lu_zero always mixes up double and twin
[17:16:35] <av500> http://www.flickr.com/photos/av500/4767108775/
[17:16:38] <DonDiego> av500: for guys with long hair? :)
[17:17:18] <av500> :)
[17:17:40] <ruggles> mru: what i really wanted was the whole commit message in the body rather than (or in addition to) the subject, but i couldn't figure out how to get git send-email to do that.
[17:17:44] <mru> lu_zero: double is for sharing with girls
[17:18:18] <mru> ruggles: I get conflicts applying that diff
[17:18:35] <lu_zero> mru: eh eh
[17:18:40] <lu_zero> so twin is the right one
[17:18:44] <av500> yes
[17:18:50] <mru> ruggles: it's the sstep/dstep fix
[17:19:03] <mru> your patch includes that but it was already pushed
[17:19:05] <av500> lu_zero: but the hotel will mess it up anyway
[17:19:08] <ruggles> mru: oh, ok. i'll pull again.
[17:19:14] <lu_zero> av500: iknow
[17:19:26] <av500> the ui is only to make people happy :)
[17:19:34] <mru> hmm, what if sharing with two girls?
[17:19:45] <av500> double->trouble
[17:19:57] <mru> double trouble
[17:20:02] <av500> ask for a trouble room
[17:21:13] <lu_zero> mru: the right answer is a double queen room with middle door
[17:21:37] <lu_zero> DonDiego: how many days?
[17:22:08] <ruggles> BBB: i did comment on the celp filters
[17:23:32] <DonDiego> lu_zero: two nights i guess, fr/sa, sa/su
[17:23:53] <BBB> oh there, different thread
[17:23:55] <BBB> ruggles: sorry
[17:23:58] * BBB reads
[17:24:21] <ruggles> mru: just sent new patch rebased to master
[17:24:40] <mru> ruggles: fwiw, plain git send-email without attachment works fine for me
[17:24:44] <mru> don't know about others
[17:24:54] * lu_zero checks his flight
[17:24:58] <BBB> ruggles: ok that answers my question, let's leave it separate then
[17:25:01] <BBB> ruggles: patch itself is ok
[17:25:22] <mru> lu_zero, DonDiego: I'm staying until monday
[17:25:28] <mru> the only flight home on sunday is too early
[17:25:35] <lu_zero> Probably I'll have to do that as well
[17:25:53] <ruggles> mru: i think thunderbird was screwing something up so i changed my global settings. i don't remember for sure.
[17:26:23] <lu_zero> ruggles: do you send them with git send-email or thunderbird?
[17:26:34] <ruggles> git send-email
[17:26:44] <mru> there's nothing in the path between ffmpeg.org and my git repo that mangles patches
[17:26:55] <mru> others may be using less careful mail readers
[17:28:21] <CIA-29> ffmpeg: Justin Ruggles <justin.ruggles at gmail.com> master * r0a3d7697b4 ffmpeg/libavcodec/ (iirfilter.c iirfilter.h):
[17:28:21] <CIA-29> ffmpeg: Add function ff_iir_filter_flt() to accept floating-point input and output.
[17:28:21] <CIA-29> ffmpeg: Signed-off-by: Mans Rullgard <mans at mansr.com>
[17:28:23] <CIA-29> ffmpeg: Justin Ruggles <justin.ruggles at gmail.com> master * rebb230279a ffmpeg/libavcodec/iirfilter.c:
[17:28:23] <CIA-29> ffmpeg: cosmetics: wrap long line
[17:28:23] <CIA-29> ffmpeg: Signed-off-by: Mans Rullgard <mans at mansr.com>
[17:30:07] <ruggles> now i remember. it think it was for svn. i wanted to be able to use "git format-patch --no-prefix" and then be able save the patch separately from the email to apply it to svn.
[17:31:15] <mru> it's all the same to me
[17:31:21] <mru> I can accept anything send-email spits out
[17:31:30] <ruggles> ok
[17:31:52] <mru> more primitive mail readers may prefer either all in the body or all as attachment
[17:32:20] <av500> time for ffmail
[17:32:30] <DonDiego> lyakh: when will you decide if you go or not?
[17:33:08] <lyakh> DonDiego: I most likely will go, just not sure by car or train... I'll try to clarify this tonight
[17:34:13] <BBB> also, Dark_Shikari, warning on x86-64 with your changes: /Users/ronaldbultje/Projects/ffmpeg-git/libavcodec/h264.c:1204: warning: passing argument 2 of ‘h->h264dsp.h264_chroma_dc_dequant_idct’ from incompatible pointer type
[17:34:19] <BBB> Dark_Shikari: can you fix that? (I can too if you're busy)
[17:35:17] <DonDiego> lyakh: ok, cool, let me know
[17:35:24] <lyakh> DonDiego: ok, will do
[17:35:55] <funm4n> hello
[17:36:39] <lyakh> DonDiego: but also when... as I said, I won't be going on Friday almost for sure, Saturday - well, some time in the morning, leaving some time in the afternoon / evening on Sunday... I mean, if you're specifically interested in any early / late sessions - let me know
[17:36:40] <funm4n> should http://ffmpeg.org/download.html be updated to remove svn mention?
[17:37:08] <BBB> probably, yes
[17:37:12] <BBB> didn't we already?
[17:37:15] <BBB> I thought I grepped for it
[17:37:23] <BBB> I think the website isn't updating automatically atm
[17:37:38] <BBB> oh no it is
[17:37:39] <funm4n> ah perhaps there is a proxy between me and the site also
[17:37:54] <lyakh> damn:(
[17:37:54] <lyakh> TEST    lavf-png
[17:37:54] <lyakh> diff: tests/data/regression/lavf/png: No such file or directory
[17:37:54] <lyakh> make: *** [fate-lavf-png] Error 1
[17:38:06] <mru> I see the svn repo still mentioned after the git stuff and with a big warning that it's going away
[17:38:24] <BBB> lyakh: update your fate samples collection
[17:38:26] <mru> lyakh: you probably don't have zlib for the target
[17:38:36] <BBB> or that
[17:38:40] <mru> BBB: that test doesn't need the samples
[17:38:42] <lyakh> BBB: just have done that
[17:38:46] <lyakh> (updated)
[17:38:47] <siretart> it seems that the new -commits mailing list is not available via gmane yet. Could someone please have a look into this?
[17:38:58] <BBB> siretart: dondiego filed a request
[17:38:59] <mru> siretart: I sent a request
[17:39:04] <BBB> damnit I'm always wrong
[17:39:05] <siretart> thanks!
[17:39:09] * BBB shuts up
[17:39:19] * BBB goes fix the h264 4:0:0 thing again
[17:39:31] <lyakh> zlib or zlib-dev?
[17:39:46] <mru> lyakh: whatever is needed to build stuff against it
[17:40:32] <mru> the exact answer depends on what system/distro/environment you're using
[17:40:44] <lyakh> it's doing some building on the target???.....
[17:40:46] <lu_zero> btw lyakh the beer event is worthy
[17:40:57] <siretart> oh, and it seems that -devel-irc is missing as well
[17:41:02] <lyakh> what if I don't have any cc on it at all???...
[17:41:36] <lyakh> lu_zero: what's so worthy about it? apart from beer:)
[17:41:52] <mru> it's not just any beer
[17:42:25] <mru> lyakh: no, you don't need a compiler on the target
[17:42:26] * lyakh dares a remark, that he's in Germany;)
[17:42:38] <mru> but your cross-compiler must find zlib headers and libs somehow
[17:42:40] <lyakh> mru: so, why building against zlib?
[17:42:42] <thresh> german beer < *
[17:42:57] <funm4n> didn't you taste french beer yet?
[17:43:08] <mru> funm4n: there is no such thing
[17:43:13] <av500> +1
[17:43:29] <thresh> I think i tried kroenenbug
[17:43:33] <av500> the last time a frenchman praised a beer, I told him it was belgian
[17:43:35] <mru> that's not beer
[17:43:37] <lyakh> mru: sorry, don't understand... the build stage has completed. it's not running tests, why does it need libs for that?
[17:43:54] <mru> it needs zlib to build the png decoder
[17:44:00] <funm4n> i plan to taste north american french beer soon
[17:44:07] <av500> mru: didnt you have a zlib :)
[17:44:10] <mru> if you don't have zlib, png is excluded from the build and the png test fails
[17:44:24] <mru> av500: only a decoder and there's one bug remaining
[17:44:32] <lyakh> mru: but then not on the target, but on the host? in the cross-build env?
[17:44:42] <mru> yes
[17:44:54] <lyakh> ic...
[17:45:07] <lyakh> is there a way to exclude the png test?
[17:45:37] <ruggles> that reminds me. should not having a test component make the test fail or not run?
[17:45:53] <mru> ruggles: yes, the deps are incomplete
[17:46:20] <av500> but then ppl could cheat on fate by not enabling anything...
[17:46:34] <ruggles> mru: ok. nobody ever commented on my test deps patch... is why i ask. thought maybe i was on the wrong track.
[17:46:35] <mru> av500: that would show fewer tests in total
[17:46:35] <av500> "my Z80 port is all green"
[17:46:54] <mru> ruggles: I'll have a look at it, but I have the feeling it could be done simpler
[17:50:02] <ruggles> thanks
[17:52:49] <av500> who is flvdec maintainer?
[17:54:16] <lu_zero> av500: uhmmm, I'm looking the pcap dumps
[17:54:29] <lu_zero> dump/from_archos/ld_fr2.pcap <- no audio at all
[17:54:53] <av500> ic
[17:55:02] <av500> but there is audio in the .ts, no?
[17:56:04] <lu_zero> uhm
[17:56:05] <lu_zero> wait
[17:56:13] <lu_zero> rtp/avp 33
[17:56:21] <lu_zero> mpegts in rtp....
[17:57:23] <av500> yes
[17:57:51] <lu_zero> then isn't rtp support for aac
[17:58:00] <lu_zero> it should be a chained demuxer
[17:58:29] <av500> but why does video work?
[17:59:26] <av500> lu_zero: could I make lavf rtp to give me the whole ts stream?
[18:00:06] * elenril starts reading arpi's response
[18:00:06] <elenril> wait, WHAT?
[18:02:09] <CIA-29> ffmpeg: Mans Rullgard <mans at mansr.com> master * rf0f54c297f ffmpeg/configure:
[18:02:09] <CIA-29> ffmpeg: Make PNG test depend on PNG codec
[18:02:09] <CIA-29> ffmpeg: Signed-off-by: Mans Rullgard <mans at mansr.com>
[18:03:34] <mru> ruggles: btw, any idea why the ac3 test uses rm container?
[18:03:39] <mru> ac3 works just fine raw...
[18:04:11] <lu_zero> av500: it should do that
[18:04:15] <lu_zero> let me re-read the code ^^;
[18:04:31] <av500> and as said, video works
[18:04:32] <ruggles> mru: historical. i'd be happy changing it.
[18:04:43] <mru> ruggles: me too
[18:05:06] <lu_zero> and if you copy to mpegts works as well?
[18:05:09] <ruggles> probably someone wanted to cover more things in a single test. but lavf-rm uses ac3 too so that covers it.
[18:05:31] <mru> ac3 is one of the oldest parts of ffmpeg
[18:05:49] <mru> ruggles: btw, nice work on the encoder
[18:05:53] <ruggles> thanks :)
[18:06:00] <mru> I'll be optimising it for arm soon
[18:06:54] <ruggles> yay. i was hoping for that. there are more things in the ac3 encoder i want to dsputil-ize as well, but other things come first.
[18:07:30] <mru> they're paying me for it
[18:07:51] <ruggles> cool. arm probably already has a better mdct.
[18:08:04] <mru> it has a good float mdct
[18:08:18] <lu_zero>         ret = ff_mpegts_parse_packet(s->ts, pkt, buf, len);
[18:08:19] <mru> probably the best there is
[18:08:21] <lu_zero> meh
[18:08:23] <ruggles> yeah. since you wrote the whole thing in asm, not just the fft.
[18:08:36] <mru> some arm dude did the fft core
[18:08:38] <mru> or most of it
[18:08:45] <mru> I did the mdct wrapper
[18:08:52] <lu_zero> av500: it directly call the ts parser
[18:09:14] <av500> lu_zero: ok, and that means?
[18:09:42] <mru> ruggles: is it safe to assume the already pointerized functions will stay the way they are?
[18:10:08] <lu_zero> av500: that there isn't _that_ simple way
[18:10:14] <av500> lu_zero: so its already chained?
[18:10:15] <lu_zero> still copy should work fine
[18:10:59] <av500> lu_zero: see here:
[18:11:04] <ruggles> mru: most, but possibly not all. channel coupling will be a pretty significant change.
[18:11:05] <av500> [13:54:49] <wbs> quick verdict on the mpegts/rtp stuff: they way rtp/mpegts is interconnected, the normal mpegts_read_header never is called
[18:11:09] <av500> [13:55:22] <wbs> which means streams/codecs aren't set up properly by reading the PMT(?) (I've got no clue on mpegts details)
[18:11:14] <av500> [13:55:54] <wbs> which means they're assigned CODEC_ID_PROBE, which tries to probe the codec but apparently doesn't succeed, taking half an eternity to bail out
[18:11:28] <mru> ruggles: ok, I'll check back with you before I do any real work
[18:11:49] <lu_zero> av500: agreed
[18:11:54] <ruggles> mru: that's one of the problems i had with aften. it was micro-optimized, then when i tried to add channel coupling it was a pain. i tried several times but never completely finished it.
[18:12:30] <lu_zero> av500: you need that working soon?
[18:13:45] <ruggles> mru: and the AC3 256-point MDCT is a weird one.  before i used the vorbis mdct in aften, i split up the mdct into a dct-iv to simplify the 256-point case.
[18:14:01] <av500> aften?
[18:14:13] <av500> ah got iz
[18:14:15] <av500> it
[18:22:15] <lu_zero> BBB: poing
[18:25:24] <BBB> piong
[18:28:35] <BBB> lu_zero: piong
[18:30:52] <BBB> mru: next two of ruggles' patches are ok also, if you want to queue more
[18:31:03] <Compn> funny that arpi and i think mplayer + ffmpeg should be merged :D
[18:31:11] * Compn thought he was alone
[18:31:33] <Compn> everyone seems to hate mplayer now :(
[18:31:50] <mru> I don't hate mplayer, but I think it should be separate from ffmpeg
[18:32:23] <iive> Compn: haven't you noticed that most of mplayer development now is removing stuff and using it from ffmpeg?
[18:33:05] <Compn> iive : yes , i have :)
[18:33:14] <Compn> but thats the smart way to do it
[18:33:20] <Compn> e.g. no more faad
[18:33:38] <lu_zero> BBB: you have experience with chained demuxer
[18:33:50] <BBB> a little
[18:33:58] <BBB> \o/ fate/h264 works with -flags emu_edge
[18:34:01] <lu_zero> to fix av500 problem we need to move mpegts to that
[18:34:02] <BBB> j-b: you owe me beer
[18:34:52] <lu_zero> =)
[18:35:05] <lu_zero> I'm looking at the asf and the qt one
[18:35:23] <lu_zero> the question is, how do you add streams properly?
[18:36:16] <CIA-29> ffmpeg: Justin Ruggles <justin.ruggles at gmail.com> master * r75b98610a7 ffmpeg/libavcodec/ (iirfilter.c iirfilter.h psymodel.c):
[18:36:16] <CIA-29> ffmpeg: cosmetics: vertical alignment and line wrap
[18:36:16] <CIA-29> ffmpeg: Signed-off-by: Mans Rullgard <mans at mansr.com>
[18:36:26] <iive> Compn: haven't you noticed that most of mplayer development now is removing stuff and using it from ffmpeg?
[18:36:27] <CIA-29> ffmpeg: Justin Ruggles <justin.ruggles at gmail.com> master * rd42dc217ed ffmpeg/libavcodec/ (iirfilter.c iirfilter.h psymodel.c):
[18:36:27] <CIA-29> ffmpeg: Add memory allocation failure checks to ff_iir_filter_init_coeffs().
[18:36:27] <CIA-29> ffmpeg: Signed-off-by: Mans Rullgard <mans at mansr.com>
[18:37:26] <BBB> lu_zero: for (n=0;n<subctx->nb_streams;n++) { av_new_stream(my_ctx, -1);} etc.
[18:38:50] <lu_zero> BBB: let me dig a bit more
[18:39:05] <BBB> soryr, there isn't really a nice convenience function
[18:39:14] <BBB> but the asf in rtp is completely chained, it's quite nice
[18:39:18] <BBB> look at that as an example
[18:39:40] <BBB> but then again all streams exist already in rtsp so I don't need this hack
[18:39:44] <BBB> rdt uses it though
[18:39:50] <BBB> maybe look at that
[18:42:49] <BBB> Dark_Shikari: also, patch to review for you on ML
[18:42:55] * BBB will figure out soon how git send-email works
[18:43:03] <BBB> do I need a local mailserver for that?
[18:43:54] <jannau> BBB: no, git send-mail --help
[18:44:05] <lu_zero> you can configure it to use gmail =P
[18:44:13] <lu_zero> (or any other smtp)
[18:45:53] <lu_zero> ok, time to run back home ^^
[18:47:45] <lu_zero> btw
[18:48:22] <BBB> ah I did
[18:48:54] <lu_zero> oh
[18:48:58] <lu_zero> interesting
[18:49:12] <lu_zero> michael branch has the value added of libmpcodecs
[18:53:03] * Compn still waiting for valid reasons to reject libmpcodecs
[18:53:14] <Compn> aside from it being fugly code
[18:56:18] <BBB> git send-email --compose 75b98610a7ce7acf34f583a04aaccd8c619947fe
[18:56:20] <BBB> why does that not work?
[18:56:25] <BBB> it says "no patch file specified"
[18:56:50] <elenril> it takes a range of commits
[18:56:51] <BBB> "No patch files specified!"
[18:57:00] <BBB> I don't know what that means
[18:57:08] <elenril> git send-email -1 to send the  last commit
[18:57:25] <elenril> git send email <some hash>^..<some hash> to send a specific commit
[18:57:44] <elenril> git send-email origin/master to send the whole branch
[18:57:48] <BBB> that sends justin's patch
[18:57:52] <BBB> I want to send my own patch
[18:58:16] <elenril> git send-email --compose 75b98610a7ce7acf34f583a04aaccd8c619947fe^..75b98610a7ce7acf34f583a04aaccd8c619947fe
[18:58:31] <BBB> hm...
[18:58:41] <BBB> can I see the revlist in some graphical way?
[18:58:52] <elenril> (i suspect there's an easier way to say that)
[18:58:55] <elenril> gitk
[18:58:56] <lu_zero> elenril: git send-email --compose master.. might be a nice shortcut
[18:59:29] <lu_zero> gitview as well
[18:59:50] <BBB> omg it threw out my changes
[18:59:51] <BBB> wtf
[19:01:00] <elenril> what threw out your changes?
[19:01:35] <BBB> git pull --rebase
[19:02:05] <elenril> well yes, it does a reset --hard
[19:02:23] <bilboed> unstashed data is consider as irelevant by git
[19:02:39] <bilboed> s/stash/stag/
[19:03:05] <elenril> BBB: do you know about git stash?
[19:03:37] <Compn> BBB : when you figure how to commit, add it to the githowto will ya? :)
[19:04:31] <BBB> huh? no the patch was committed
[19:04:43] <BBB> I had it committed locally, then ran git pull --rebase
[19:04:49] <BBB> so I can push or send-email or so
[19:04:52] <BBB> and then it threw it out
[19:04:53] <BBB> wtf
[19:04:55] <bilboed> that means a similar patch was already present upstream
[19:05:44] <bilboed> s/patch/commit/
[19:05:45] <BBB> I can assure you it wasn't, because my patch is not present in the code anymore
[19:05:49] <BBB> the code I wrote is gone
[19:05:52] <BBB> gone
[19:05:52] <BBB> gone
[19:05:55] <bilboed> no it's not
[19:05:55] <BBB> grmbl
[19:05:57] <bilboed> chill
[19:05:58] <bilboed> git reflog
[19:06:06] <BBB> git getabrain
[19:06:24] <superdump> git unshootfoot
[19:06:32] <BBB> that would be wonderfulk
[19:06:42] <bilboed> BBB, git reflog will show you the previous states you were in
[19:06:47] <elenril> if you committed it then it's not lost
[19:06:51] <elenril> git log -g
[19:07:06] * elenril wonders how could that have happened though
[19:07:18] <BBB> I already rewrote the patch
[19:07:22] <BBB> I already have a headache
[19:07:54] * elenril applauds superdump's speech
[19:08:43] <bilboed> elenril, nice trick with the git log -g, much more useful than git reflog
[19:09:04] <BBB> superdump: uh yeah that email is long
[19:09:07] <BBB> I'm not evenhalfway it
[19:09:21] <superdump> sorry for the length
[19:09:29] <superdump> i hope the content is worth reading
[19:09:40] <BBB> we'll see in about an hour :-p
[19:09:45] * elenril thinks more people should reply and ask michael to stay
[19:09:56] <superdump> i know i find gettys' blog posts too long to be bothered to read them...
[19:11:36] <superdump> time for more food
[19:13:40] <superdump> BBB: maybe take comfort in the fact that it took me longer to write it...? :)
[19:13:45] <superdump> back in a bit
[19:13:58] <uau> i thought it was kind of rambling
[19:14:39] <BBB> \o/ it worked
[19:17:01] <ubitux> I don't know if Rob is here on IRC, but I'd like to say I really appreciate what he says and the way he says them ('referring to the "Preliminary announcement about the current situation" thread)
[19:17:57] <BBB> rob=superdump, he's here
[19:18:01] * mru discovers that lossless h264 is broken
[19:18:07] <uau> just quit actually
[19:20:36] <Compn> mru : no fate test for it ?
[19:20:44] <mru> apparently not
[19:20:56] * mru bisects
[19:21:14] <Compn> is it hard to make fate tests? is there a way to script up an easier run script && its done ?
[19:21:33] <BBB> mru: yeah, add more fate tests
[19:21:47] <Compn> so you just ./fate-add -vd file.avi , and it adds file.avi for that video decoder ?
[19:21:47] <BBB> mru: do you want the IDs of those fate tests I want to run with -flags emu_edge?
[19:30:18] * _av500_ wonders if thresh already went drinking for the night
[19:36:15] <saintd3v> michael was actually planning on getting on irc o.O
[19:36:34] <mru> so he says
[19:36:50] <iive> he's been on irc before, not big deal.
[19:37:12] <mru> twice in 10 years hardly counts
[19:37:34] <saintd3v> iive: except that he's publicly stated he doesn't like irc =P
[19:37:39] <vipw> irc is full of trolls anyway
[19:37:57] <vipw> kind of like mailing lists
[19:38:04] <BBB> omg he talked about the gst indent script
[19:38:10] <BBB> I remember how that fucked up tables :-p
[19:38:12] <BBB> anyway...
[19:38:15] <BBB> </flame>
[19:38:30] <bilboed> *cough*
[19:38:37] <iive> saintd3v: i guess he have reason not to like it.
[19:38:53] <bilboed> BBB, sure, it's not perfect... but at least we don't have to give a $#@*(%$# about indentation. Just hack :)
[19:39:11] <bilboed> </nonflame>
[19:39:18] <BBB> I think we should give dondiego free commit access to fix _anything_ indentation-wise
[19:39:58] <iive> BBB: he can give it himself.
[19:41:17] <DonDiego> oh wow, there it is
[19:41:29] <j-b> BBB: no pb, you awe me more
[19:41:36] <j-b> *oweù
[19:41:37] <DonDiego> i'm surprised it took so long to spiral down into personal attacks against me
[19:41:38] <j-b> rah
[19:41:42] <BBB> j-b: indeed :-p
[19:42:13] <spaam> DonDiego: the new expert maintainer? :) nice
[19:42:39] <DonDiego> well, coming from the expert leader...
[19:43:09] <BBB> enough...
[19:43:15] <BBB> at least people have opinions now
[19:43:17] <BBB> :)
[19:43:25] <spaam> :)
[19:43:40] <BBB> oh also I've seen more mailinglist activity than ever
[19:45:20] <mru> Dark_Shikari: 2a1f431d38ea9c05abb215d70c7dc09cdb6888ab broke lossless h264
[19:46:01] <mru> http://git.ffmpeg.org/?p=ffmpeg.git;a=commitdiff;h=2a1f431d38ea9c05abb215d70c7dc09cdb6888ab
[19:46:45] <mru> or it was broken before and that fixed it
[19:47:26] <lyakh> DonDiego: so, looks like indeed I'll have the car at my disposal - of course, modulo I get ill, the car breaks down, the German-Belgian border closes etc;)
[19:47:31] <j-b> BBB: the latest patch on the ml ?
[19:47:42] <BBB> j-b: yeah, that fixes most remaining issues for me
[19:47:46] <BBB> let me try with valgrind to make sure
[19:48:37] <BBB> yeah it's clean now
[19:50:51] <_av500_> lyakh: but u drive on friday!
[19:52:52] * Compn confused about lack of transportation, thought euro was full of trains
[19:53:13] <lyakh> _av500_: nooo, you haven't convinced me, that that beer's worth it;)
[19:54:02] <roxfan> trains can be a bit on expensive side when crossing borders
[19:54:52] <Compn> ah
[19:57:44] <Dark_Shikari> mru: oh.  oops.  you're right.
[19:57:45] <Dark_Shikari> shit, I'm stupid
[19:58:02] <thresh> _av500_: nop, i'm here
[19:58:05] <Dark_Shikari> wait why is there no lossless h264 in fate
[19:58:07] <Dark_Shikari> what the christ
[19:58:13] <roxfan> hmm, cheapest thalys aachen-brussels is 23 euro
[19:58:17] <roxfan> not bad
[19:58:19] <Dark_Shikari> mru: can you just revert that, I'll fix it later
[19:58:23] <mru> Dark_Shikari: I's as baffled as you are
[19:58:37] <Dark_Shikari> It's not important for speed so it's not important for it to be in
[19:58:42] <Dark_Shikari> and it was the last of my  patches
[20:00:00] <roxfan> oh hm even 15 eur
[20:00:48] <Dark_Shikari> please note in the revert something about no lossless fate sample
[20:01:59] <lyakh> hm, how long does fate take on a "moderate ARM?"
[20:02:21] <mru> define moderate
[20:02:28] <mru> 600MHz omap3 takes ~50min
[20:02:52] <mru> it's spending stupid amounts of time in the filter tests
[20:02:56] <Dark_Shikari> mru: does it work with lossless without that patch?
[20:02:59] <mru> I have an idea to speed those up
[20:03:20] <lyakh> mru: with VFPU?
[20:03:43] <mru> the problem with those tests is that they produce huge output files
[20:03:47] <mru> several GB of data
[20:03:53] <lyakh> wow...
[20:03:57] <mru> sending that over slow comms takes a while
[20:04:16] <mru> I think simply checksumming it on the fly might speed it up
[20:04:18] <lyakh> all under tests/data?
[20:04:22] <roxfan> compress them?
[20:04:34] <mru> roxfan: no point
[20:04:41] <mru> all the host does is do an md5sum anyway
[20:04:57] <roxfan> ah
[20:05:18] <roxfan> yeah then it makes sense to do it on the device
[20:05:23] <mru> the files are deleted after each test so the free space needed to run isn't too bad though
[20:06:02] <lyakh> 50min with FPU?
[20:06:16] <mru> with everything
[20:07:39] <Dark_Shikari> mru: ok, I'll revert it
[20:07:54] <_av500_> lyakh: yep, omap3 has afpu
[20:08:11] <mru> of sorts
[20:08:27] <lyakh> _av500_: I knew it had it, I didn't know whether it was used in that 50min test...
[20:10:54] <BBB> Dark_Shikari: what's the problem? I can look into fixing it if you want
[20:10:59] <BBB> I don't see the issue right now though
[20:11:56] <Dark_Shikari> Oh, you want to fix it correctly
[20:11:58] <Dark_Shikari> it's not hard
[20:12:02] <Dark_Shikari> ok, let me explain:
[20:12:08] <Dark_Shikari> 1) I converted luma dc to work A Better Way
[20:12:21] <Dark_Shikari> 2) This involved adding a line or two of code to copy over luma "dc" coefficients in the case of lossless mode.
[20:12:25] <Dark_Shikari> to put them in their place
[20:12:30] <Dark_Shikari> 3) I did the same to chroma dc
[20:12:32] <Dark_Shikari> 4) and I forgot step 2.
[20:12:53] <astrange> 06:22 < kierank> astrange: any idea why version.h doesn't appear in latest ffmpeg-mt <- hmm? wfm after configuring
[20:13:00] <Dark_Shikari> in short, in lossless, we don't run chroma_idct_dequant
[20:13:13] <Dark_Shikari> instead we just copy the "dc coefficients" into the dct data
[20:13:18] <Dark_Shikari> because they're really just one pixel each
[20:13:48] <Dark_Shikari> See what luma does and it should be obvious.
[20:13:56] <Dark_Shikari> If you don't want to do it today, say so and I'll revert my patch instead.
[20:16:59] <BBB> where do I find the luma code? I'll see if I can decipher it
[20:17:05] <BBB> also need a testcase that fails
[20:17:48] <lyakh> so, guys, is there going to be any kind of an ff-meeting at fosdem?
[20:18:01] <mru> a bunch of ffpeople will be there
[20:18:06] <mru> meetings are bound to take place
[20:18:49] <BBB> Dark_Shikari: dcmapping[]?
[20:18:50] <lyakh> mru: heh, yeah, I meant like something more organised with a _certain_ time and place
[20:19:05] <mru> friday night, delirium cafe
[20:19:19] <mru> saturday night, $bar
[20:20:02] <lyakh> ok, spontaneous and flexible;)
[20:20:53] <Compn> Dark_Shikari : michael said to ping him on mails he missed if you were interested in doing that...
[20:21:00] * Compn wonders why hes playing telephone to people
[20:21:32] <lyakh> wooow, cool, the test has just completed!:)
[20:21:41] <lyakh> 2h15'
[20:22:11] <mru> what speed is that cpu?
[20:23:55] <lyakh> mru: I think 500MHz
[20:24:07] <pasteeater> where can i get the web site sources to patch some little html errors?
[20:24:55] <mru> pasteeater: svn://svn.ffmpeg.org/ffmpeg.org/trunk
[20:24:56] <BBB> mru: please send me a sample
[20:24:56] <lyakh> so, where's the report and how do I submit it? I only see separate .rep files
[20:25:19] <mru> lyakh: that's where the fate.sh scripts comes in
[20:26:02] <pasteeater> mru: thanks.
[20:26:12] <lyakh> so, having run "make fate" manually I cannot get such a report? have to re-run with fate.sh?
[20:26:51] <Dark_Shikari> BBB: yes, dcmapping[]
[20:27:03] <Dark_Shikari> Compn: ?
[20:28:27] <mru> lyakh: the final report is made by catting all the .rep files with a header created by fate.sh, then tarring it up together with various logs of the build and test outputs
[20:28:42] <mru> you could piece one together manually but I see no point
[20:28:54] <lyakh> ic, nice...
[20:29:01] <lu_zero> Dark_Shikari, Comp what was the question?
[20:29:14] <mru> you can see what happens in the report() function in fate.sh
[20:29:18] <BBB> Dark_Shikari: what is the array? 0*16 1*16 2*16 3*16? or are 1 and 2 inverted?
[20:29:26] <BBB> Dark_Shikari: too lzy to look up
[20:29:40] <BBB> mru: can you send me a lossless h264 sample?
[20:29:46] <mru> lyakh: now there's not much point submitting a report unless you tend to run it regularly
[20:29:52] <mru> BBB: yes, I will
[20:29:54] <BBB> thnx
[20:30:05] <mru> lyakh: and then you might as well use the proper script
[20:30:24] <lyakh> mru: well, I could do it from time to time like weekly or biweekly...
[20:30:43] <lyakh> but yes, will try to re-run with the script tomorrow
[20:30:45] * mru should get that microconnect off av500...
[20:31:14] <mru> I could have it running continuously
[20:31:29] <Compn> Dark_Shikari : last reply from michael to -devel
[20:32:42] <CIA-29> ffmpeg: Justin Ruggles <justin.ruggles at gmail.com> master * r30112adadf ffmpeg/libavcodec/iirfilter.c:
[20:32:42] <CIA-29> ffmpeg: Split out Butterworth filter coeff init to a separate function.
[20:32:42] <CIA-29> ffmpeg: Signed-off-by: Mans Rullgard <mans at mansr.com>
[20:35:36] <Dark_Shikari> BBB: Just use the start of the array, the first 4 items
[20:35:42] <DonDiego> lyakh: so we have a plan?
[20:35:47] <Dark_Shikari> BBB: jus tmake one with x264
[20:35:50] <Dark_Shikari> x264 input --qp 0 -o output
[20:36:25] <Dark_Shikari> Compn: I know, I did ping him, and it worked
[20:36:27] <Dark_Shikari> it was successful in the past
[20:37:28] <lyakh> DonDiego: well, if you don't have to be there on Friday or on Saturday before 10a.m., and do not have to stay after Sunday, say, 6p.m., sure, I can give you a lift:)
[20:37:39] <mru> aren't there any lossless samples in the official conformance suite?
[20:38:04] <BBB> Dark_Shikari: that would overflow
[20:38:15] <Dark_Shikari> BBB: ?
[20:38:18] <Dark_Shikari> There are only 4 entries for chroma.
[20:38:24] <BBB> Dark_Shikari: the array should be filled 4*16 entries, and the dc_mapping[] = 0*16, 1*16, 4*16, 5*16, 2*16, 3*16, [..]
[20:38:24] <mru> lyakh: what, you're skipping the beer event?
[20:38:33] <Dark_Shikari> BBB: um...
[20:38:36] <Dark_Shikari> you're copying over 4 values.
[20:38:39] <Dark_Shikari> why do you need 64 entries?
[20:39:14] <j0sh_> hi guys
[20:39:18] <j0sh_> lu_zero: did you ping earlier?
[20:39:30] <lyakh> mru: I'm not that much interested in the "beer" part, and noone managed to justify, why I need the "event" part;)
[20:39:54] <mru> lyakh: suit yourself
[20:40:02] <lyakh> sure:)
[20:44:04] <j0sh_> is there any interest in a composition filter
[20:44:28] <j0sh_> eg, taking two (or more) streams and outputting them side-by-side
[20:44:43] <merbanan> j0sh_: sure that would be nice
[20:45:09] <merbanan> some 3d film folks would be happy then
[20:45:19] <j0sh_> hmm didn't think of that case
[20:45:21] <relaxed> j0sh_: isn't that possible with the movie and overlay filters?
[20:45:55] <j0sh_> relaxed: i'll look into those
[20:45:55] <BBB> Dark_Shikari: dc_mapping[] in luma puts it in 0*16, 1*16, 2*16, i.e. the DC of the coefficients, I should do the same thing here, no? the question is in what order do I place them
[20:45:59] <DonDiego> mru: do you want a sparc for running fate on?
[20:46:05] <Dark_Shikari> BBB: Exactly the same
[20:46:10] <Dark_Shikari> for each chroma channel:
[20:46:14] <Dark_Shikari>    for each DC coefficient:
[20:46:25] <DonDiego> lyakh: i'd like to be there on friday
[20:46:26] <Dark_Shikari>       place the DC coefficient in dc_mapping[dc coeff index] (index goes from 0 to 3)
[20:46:34] <DonDiego> lyakh: but maybe we can share the commute home..
[20:46:38] <BBB> that's what I asked :) ok so it's 0,1,2,3 :)
[20:46:40] <BBB> got it
[20:46:42] <BBB> thanks
[20:46:46] <relaxed> j0sh_: I don't know why I formed that as a question. It is possible with those filters. :)
[20:46:46] <Dark_Shikari> oh, then you don't need dc mapping
[20:47:03] <Dark_Shikari> so you do h->mb[256+c*64+idx*16] = chroma_dc[c][idx];
[20:47:28] <BBB> I just wrote that myself :-p
[20:47:37] <j0sh_> relaxed: what is the 'movie' filter called? i don't see it
[20:48:08] <relaxed> j0sh_: It's in the libavfilter soc branch on svn.
[20:48:25] <lyakh> DonDiego: sure, you've got my email address, right? or let me pm you my mobile coordinates, in case we don't meet personally before Sunday and I don't find a way to check my main mail
[20:48:36] <relaxed> j0sh_: http://ffmpeg.org/libavfilter.html
[20:49:21] <DonDiego> lyakh: ok, fine
[20:49:28] <relaxed> j0sh_: It's the testing ground for new filters.
[20:49:49] <j0sh_> relaxed: got it, thanks
[20:50:23] <astrange> Dark_Shikari: can you still get google to host a conf?
[20:51:44] <Dark_Shikari> astrange: talk to BBB
[20:51:47] <Dark_Shikari> it's his responsibility
[20:52:13] <BBB> huh? :-p
[20:52:20] <BBB> omg I haven't even started yet
[20:52:23] <BBB> but yes
[21:00:03] <merbanan> BBB: can you get us those unicorns also ?
[21:03:02] <BBB> I will try
[21:03:05] <lyakh> regarding fate: it would be nice to have some unoptimized reference for all single benchmarks just to be able to compare - which of them run way too slow on this arch, and which one benefit from optimizations...
[21:03:12] <BBB> so far they weren't sure if google could afford them
[21:03:25] <BBB> but if the profits for this year are as they should be, they will consider donating one
[21:03:33] <BBB> then we'll have to vote (!!!!!) over who gets it
[21:03:40] <BBB> or do a timeshare
[21:04:14] <DonDiego> what are you talking about?
[21:04:25] <merbanan> I'm going to have sex with it
[21:04:36] <mru> with a unicorn?
[21:04:53] <lyakh> DonDiego: whom are you asking?
[21:05:09] <BBB> someone is drunk here
[21:05:12] <BBB> :-p
[21:05:13] <mru> merbanan: I didn't know you were a mythozoophiliac
[21:05:48] <merbanan> well I'm a complex man
[21:06:11] <lyakh> wow! that's a new perversion!;)
[21:06:22] <DonDiego> lyakh: i want to know what this unicorn thing is all about...
[21:06:29] <merbanan> BBB: but seriously we need some Android phones
[21:06:29] <lyakh> ic
[21:06:37] <merbanan> we have no fate test for it yet
[21:06:38] <mru> lyakh: at least nobody is harmed by it
[21:06:51] <j-b> was someone working on WVPK 5.1 ?
[21:06:51] <mru> merbanan: for the unicorn?
[21:06:51] <merbanan> except maybe me
[21:07:31] <merbanan> mru: yes for the unicorn, how else are we going to talk to it
[21:07:49] <merbanan> j-b: kostya was somewhat doing that
[21:08:01] <j-b> merbanan: do we meet at FOSDEM?
[21:08:16] <mru> j-b: we will find you
[21:08:22] <mru> j-b: don't bother trying to hide
[21:08:31] <merbanan> yes I will be there
[21:08:33] <mru> we'll just follow the smell of frogs and cheese
[21:08:37] <j-b> mru: :)
[21:08:52] <j-b> mru: I have things to discuss with merbanan especially
[21:08:57] <j-b> merbanan: great.
[21:09:05] <superdump> i will be there too :)
[21:09:32] <j-b> I'll see if Michael from linux-md will be there
[21:09:43] <mru> md?
[21:10:17] <lu_zero> what's that?
[21:10:48] <merbanan> legacy boys
[21:11:23] <mru> what's that?  a 60s-style boy band?
[21:11:37] <bilboed> manual decoders
[21:11:37] <BBB> damnit everyone except for me goes to fosdem
[21:11:43] <merbanan> http://en.wikipedia.org/wiki/MD
[21:11:44] <BBB> why are there no free software conferences in the US?
[21:11:54] <merbanan> pick your poison
[21:11:55] <BBB> mru: still waiting for sample :-p
[21:11:57] <mru> BBB: because americans are all about money
[21:12:02] <pasteeater> should my web site cleanup patch include all changed pages, or do you prefer 1 patch for each updated page file?
[21:12:03] <j-b> because US visa and imagration laws are fuck?
[21:12:09] <BBB> yes they are
[21:12:18] <j-b> +fixes
[21:12:42] <lu_zero> BBB: there are
[21:12:45] <bilboed> j-b, not for going to a conf. Try getting a long stay visa in Europe if you're american : bonne chance
[21:12:46] <lu_zero> SCALE is great
[21:12:56] <Dark_Shikari> BBB: ping me when it's fixed
[21:13:03] <j-b> bilboed: oh, never tried the other way
[21:13:13] <bilboed> j-b, it's... a clusterfuck
[21:13:39] <lu_zero> bilboed: oh well you have enough country to get a turist visa cycle nearby ...
[21:13:58] <bilboed> lu_zero, well... Schengen zone == 1 visa
[21:14:01] <bilboed> lu_zero, but yes
[21:14:09] <thresh> try getting any visa if you're russian
[21:14:18] <bilboed> visa gets you in russia
[21:14:20] <bilboed> (sorry)
[21:14:24] <lu_zero> bilboed: still closer than australia vs nz vs japan vs china
[21:14:25] <thresh> even funnier, try staying in Moscow if you're russian
[21:14:30] <bilboed> lu_zero, totally
[21:14:33] <thresh> (you need a registration and a couple of bribes)
[21:14:49] <BBB> Dark_Shikari: it is, I need a test and am too lazy to make one myself
[21:14:53] <lu_zero> (common "turist cycle" done by foreingers not will to bother about long term visas)
[21:15:01] <BBB> Dark_Shikari: but I'll make one myself in a few minutes though
[21:15:19] <bilboed> lu_zero, but I heard rumors advising against doing the 6 months in UK / 6 months in Schengen trick
[21:15:29] <bilboed> lu_zero, they spot that pretty quickly
[21:15:50] <lu_zero> bilboed: the trick requires at least 3-4 countries
[21:16:07] <bilboed> lu_zero, yes, it's called jet-setting, but then you do that for another reason :)
[21:16:21] <lu_zero> and even in that case it's better get some good excuse
[21:16:22] <thresh> why would anyone want to go to europe from US anyway
[21:16:32] <lu_zero> thresh: _many_ reasons
[21:16:46] <bilboed> lu_zero, I've got ants in my pants so I need to ... hmm... switch countries ? :)
[21:16:55] <mru> BBB: sent
[21:17:23] <mru> moving around a lot can have tax benefits
[21:17:37] <mru> play it right, and you won't be considered resident anywhere
[21:17:49] <lu_zero> bilboed: "ants in my pants" means something specific or is just itching to move around?
[21:17:55] <bilboed> mru, ... and won't have any country protecting your ass when you get in trouble
[21:18:08] <merbanan> thresh: I've experienced Russian bureaucracy, can't believe they run a complete country like that
[21:18:13] <bilboed> lu_zero, the second meaning + the title of a James Brown tune
[21:18:15] <mru> bilboed: a citizenship still counts for something
[21:18:18] <thresh> country? protecting its citizen? sounds sooo untrue :)
[21:18:35] <thresh> merbanan: well the trick is they dont really
[21:18:44] <bilboed> mru, riiiiight : "so, you want protection ? Right, so you owe us XXX XXX XXX EUR of unpaid taxes, cough up"
[21:19:01] <mru> bilboed: I'm talking about _legally_ not paying tax
[21:19:06] <bilboed> sure
[21:19:08] <thresh> merbanan: all that 'power vertical' Putin built is shaky
[21:19:17] <mru> at least in the UK, you only pay tax if you're resident or ordinarily resident
[21:19:39] <bilboed> mru, same for all (?) EU countries
[21:19:44] <mru> the meanings of which are a bit fuzzy
[21:20:06] <mru> but if you spend less than 180 days per year in any one country for a few years it should work
[21:20:32] <merbanan> thresh: my exwife had the pleasant experience of changing her last name in her passports, turns out you cant do that abroad ...
[21:20:33] <lu_zero> mru: you still have one that you should mark as residential place
[21:20:36] <bilboed> mru, the opposite is fun. Reminds me of the owner of a certain linux distro who wasn't staying long enough in his 'official' place of residence to benefit the tax exemptions. He uses his jet a lot less nowadays :)
[21:20:44] <mru> lu_zero: and that can be a tax haven
[21:20:46] <thresh> merbanan: bah
[21:21:28] <lu_zero> mru: but then you might get people interested on you
[21:21:29] <spaam> mru: so. if you stay more then 180days. they say that you live there?
[21:21:32] <lu_zero> anyway
[21:21:50] <bilboed> spaam, problem is proving you're living there 180 days
[21:22:01] <mru> spaam: in are in the uk more than 180 days in one year you are considered resident for that year
[21:22:08] <lu_zero> given how much costs travelling it might be worthy only if you like travel that much, have a job that needs
[21:22:16] <lu_zero> travelling
[21:22:21] <mru> but if that's a one-off and you normally live elsewhere, you're not "ordinarily resident" and don't have to pay tax
[21:22:25] <mru> uk tax
[21:22:31] <mru> you have to pay tax in the other country of course
[21:22:40] <BBB> mru: expected md5?
[21:23:02] <mru> 3ae12544549f3fcfb363694f9b23c32b
[21:23:04] <BBB> MD5=42aabc74089e547a29030e071f8162d9 is what I get
[21:23:07] <BBB> damnit :p
[21:23:18] <mru> 42... is the bad one
[21:23:20] <superdump> i think the uk rule is a little more complex
[21:23:28] <superdump> there's some kind of average over four years
[21:23:28] <mru> superdump: it's a lot more complex
[21:23:43] <mru> there's also the question of where you are domiciled
[21:23:49] <mru> which can be a third place
[21:24:04] <mru> and also where the income originates
[21:25:43] <mru> if you have family their location also matters
[21:25:59] <mru> I wonder what they'd do if you had two separate families
[21:26:08] <mru> obviously not knowing about each other
[21:26:26] <mru> the taxman in each country would be told about the other one
[21:26:47] <BBB> mru: oh I did sth. stupid
[21:28:24] <lu_zero> mru: still, the best is picking a good place in australia, make it your own country hail the queen and live happy
[21:32:26] <superdump> or be a completely crazy person and pay taxes...
[21:32:51] <mru> or be a stark raving mad person, move to sweden, and pay taxes
[21:33:52] <lu_zero> mru: I'd do
[21:34:07] <mru> what, move to sweden?
[21:34:08] * lu_zero is paying more than he'd pay in Sweden
[21:34:14] <mru> oh
[21:34:16] <lu_zero> eh
[21:34:24] <mru> uk is less than sweden
[21:34:48] <lu_zero> and at least in Sweden there are good services given for the taxes paid
[21:35:00] <pJok> sweden has low taxes
[21:35:06] <mru> lu_zero: that's what they want you to believe
[21:35:20] <pJok> except the 30% fee that the employer has to pay the state directly
[21:35:29] <mru> sure, healthcare is decent, provided you make it through the queues before you die
[21:35:38] <mru> pJok: that's also tax
[21:35:44] <pJok> mru, no no... its a fee!
[21:35:46] <pJok> ;)
[21:35:58] <mru> uk has "employer's national insurance" though
[21:36:04] <mru> which is roughly the same thing
[21:36:36] <mru> if it's a percentage of income, it's a tax
[21:36:46] <lu_zero> pJok: that 30% what would encompass?
[21:36:59] <pJok> lu_zero, its actually a tax, but its not sold as one
[21:37:01] <mru> also don't forget the 25% VAT
[21:37:02] <thresh> hehe, some say we Russians pay a lot of taxes as well. Though our taxes are mostly bribes.
[21:37:14] <mru> and the property tax
[21:37:16] <pJok> mru, food has lower VAT unlike denmark
[21:37:25] <mru> food as zero VAT in uk
[21:37:28] <mru> has
[21:37:45] <mru> food really is much cheaper here
[21:37:46] <lu_zero> here is a flat 20% over almost everything ^^;
[21:37:55] <thresh> imagine every time you are stopped by the road police, you have to pay him. true story.
[21:38:25] <pJok> thresh, you'd be stopped a lot more often then
[21:38:46] <BBB> blegh I keep getting different output
[21:39:09] * pJok ponders on working in sweden now that the advantage of getting a higher pay in denmark is shrinking
[21:41:40] <superdump> i'm inclined to think sweden is generally expensive, but it's difficult for me to tell living in stockholm
[21:41:45] <thresh> pJok: well they know places with non-obvious or erroneus traffic lane markings where you are doomed to violate it (especially on federal highways etc).. that's where they feed
[21:42:07] <spaam> superdump: everything is expensive in fjollträsk
[21:42:14] <superdump> i lived in the countryside in england the the nearby town wasn't so big
[21:42:57] <spaam> but you can earn more $$$ in stockholm then rest of sweden.
[21:43:35] <superdump> but the total cost of employing someone for the same money for them after tax is a lot higher than in the uk
[21:43:37] <mru> property is very expensive in stockholm
[21:43:49] <mru> public transportation is cheap
[21:43:57] <mru> and actually quite good
[21:44:03] <superdump> sl card for one month is 670kr methinks
[21:44:12] <mru> that's very cheap
[21:44:20] <lu_zero> that's something I don't like much about sweden
[21:44:23] <lu_zero> non-euro
[21:44:31] <mru> non-euro is cool
[21:44:34] <spaam> yeah
[21:44:34] <lu_zero> depends
[21:44:37] <superdump> i don't give a crap, but then uk uses gbp anyway
[21:44:37] <mru> all hail the queen
[21:44:40] <superdump> :)
[21:45:22] <BBB> I think I do the same as luma, but output is still different from what mru just said
[21:45:32] <BBB> Dark_Shikari: probably best to revert until I get a better handle of this shit
[21:45:48] <lu_zero> BBB: shift it on a branch
[21:45:54] <Dark_Shikari> BBB: before you do that
[21:46:04] * Dark_Shikari quickly checks, one moment
[21:47:13] <Dark_Shikari> Oh hmm, nevermind.  Show me the patch and I can look at it
[21:47:25] <Dark_Shikari> actually can you PM me the patch?  wireless is horribly broken atm
[21:47:32] <BBB> ok
[21:47:32] <Dark_Shikari> so I can't open new connections
[21:48:19] <superdump> mru: i do wonder where the money goes though
[21:48:29] <superdump> sweden has better internet infrastructure from what i can tell
[21:48:40] <superdump> seems cleaner and greener
[21:48:54] <mru> much of the internet infrastructure is privately funded
[21:48:56] <superdump> healthcare is more expensive :)
[21:49:26] <superdump> perhaps pensions and unemployment benefits are better
[21:49:41] <mru> I'm not afraid of unemployment
[21:49:52] <superdump> you grab it by the horns
[21:50:02] <mru> no, by the ARMs
[21:50:06] <superdump> hehehe
[21:52:50] <pasteeater> superdump: what do you think should be done to the site to make it not "in the dark ages"?
[21:53:07] * mru likes it the way it is
[21:53:17] <mru> we don't need no stinkin web 2.0
[21:53:29] <kierank> needs more <video> tag
[21:53:31] <kierank> dih
[21:53:32] <kierank> duh*
[21:54:53] <superdump> pasteeater: well i'm no web developer and i did the current CSS and stuff :)
[21:55:32] <pasteeater> i was just wondering what you didn't like about it.
[21:56:07] <superdump> i think it's more about the content than the pages themselves i guess
[21:56:18] <superdump> plus i still hate the makefile crap
[21:56:31] <astrange> ffmpeg.org isn't going to be used for much anyway
[21:56:40] <mru> huh?
[21:56:56] <superdump> mostly i think effort needs to be put into documentation and what information is where
[21:57:03] <astrange> well i see http://ffmpeg.org/projects.html is a useful page and the text is rather off-center, that's something
[21:57:25] <superdump> i think it should be structured according to the viewers interests
[21:57:30] <mru> yeah, those columns should be centred
[21:58:09] <astrange> there's a pr problem with the hall of shame page, eg for mediacoder it links to the bug tracker entry which mostly contains the author of mediacoder complaining about it
[21:58:17] <astrange> people read it and don't see what the problem is or think he's right
[21:59:07] <superdump> as i recall i split the content into four main sections - obtaining ffmpeg (source/binaries), using ffmpeg command line utilities, developing using libav* apis and contributing to ffmpeg development
[21:59:48] <superdump> last time i looked there were multiple help documents covering the same topics
[21:59:55] <BBB> mru: MD5=3ae12544549f3fcfb363694f9b23c32b after revert... ok to commit that?
[22:00:15] <mru> BBB: you gave up fixing?
[22:00:22] <superdump> and i really think something like a wiki, on ffmpeg.org, would be good for managing documentation so that non-coders could contribute
[22:00:59] <superdump> we could use the multimediawiki, but i really think it should be on ffmpeg.org so that it is easily accessible and easy to find
[22:01:02] <spaam> hey and welcome spam spam spam
[22:01:09] <kierank> yeah wiki = spam spam spam
[22:01:23] <lu_zero> reg only wiki -> fine
[22:01:36] <mru> superdump: we could point wiki.ffmpeg.org at multimediawiki easily enough
[22:01:57] <spaam> still you can get some spam there lu_zero ;) we have that problem sometimes on redmine.lighttpd.net ;D
[22:01:58] <BBB> mru: yes... I tried the same as luma but it didn't fix it correctly...
[22:02:05] <BBB> so D_S suggests just reverting for now
[22:02:21] <spaam> lu_zero: but sure. its not that much.
[22:02:23] <mru> let's do that then
[22:02:29] <mru> I'll add a test
[22:04:24] <superdump> mru: or a subsection of mm.cx... yeah
[22:05:46] <lu_zero> spaam: I'd say redmine is at fault
[22:06:18] <lu_zero> but I'm not sure it is really redmine fault since I hadn't read its code
[22:06:34] <superdump> heading off now
[22:06:36] <superdump> have fun
[22:25:30] * BBB tries another round of git send-email
[22:25:43] <BBB> how do I push one patch that I committed but not another?
[22:26:47] <mru> where is the commit you want to push in relation to origin?
[22:27:40] <mru> here's a method that always works:
[22:27:44] <mru> git checkout -b tmp
[22:27:49] <mru> git rebase -i origin
[22:27:59] <mru>  [remove anything not ready for push]
[22:28:05] <mru> git push origin tmp:master
[22:28:30] <mru> git rebase origin master
[22:28:37] <mru> git branch -d tmp
[22:29:05] <mru> that's often overkill though
[22:29:31] <mru> if you just want to push a single commit immediately following origin, you simply
[22:29:38] <mru> git push origin $hash:master
[22:29:48] <mru> where $hash is the rev hash of the commit in question
[22:29:58] <mru> that works for any sequence on top of origin of course
[22:30:24] <BBB> ok
[22:30:26] <BBB> I'll try that
[22:30:32] <BBB> I think my email didn't arrive this time
[22:33:24] <jannau> michael asked what's the best way of importing changes from git.ffmpeg.org into git.videolan.org
[22:34:46] <jannau> git merge would be currently the cleanest solution except that merge commits are disallowed
[22:34:54] <j-b> cherry-pick ?
[22:34:54] <BBB> ah there it is
[22:35:15] <mru> lots of cherries
[22:35:25] <BBB> that's because we finally develop again
[22:35:29] <BBB> mru: can you ok the patch?
[22:35:31] <jannau> but I guess it will get ugly once we cherry pick from git.videolan.org
[22:35:32] <BBB> then add a fate test?
[22:35:44] <mru> fate test is already written
[22:36:03] <mru> I'll send it for review and push it tomorrow when fate servers have synced
[22:36:12] <jannau> so I think git cherry-pick -x is best the solution
[22:40:53] <_av500_> mru: about the 7109, it sits unused here
[22:41:04] <_av500_> id be glad to have it run fata
[22:41:08] <_av500_> fate too
[22:42:02] <mru> _av500_: let's put it to use then
[22:42:19] <_av500_> i just have 0 st knowledge
[22:42:27] <mru> I have some
[22:42:28] <lyakh> damn, just realised - that 2h15' was a bs - I used a config for profiling...
[22:42:41] <lyakh> with all optimizations off etc;)
[22:42:45] <Dark_Shikari> yay, we're in a contest to out-commit michael
[22:43:11] <_av500_> Dark_Shikari: remember, we are polite and friendly too now
[22:43:40] <mru> _av500_: you can either "lend" me the board, or I can drop by when convenient and set it up if you don't know how
[22:43:51] <_av500_> mru: both will work
[22:44:07] <mru> handover at fosdem?
[22:44:13] <_av500_> its huge
[22:44:17] <mru> how huge?
[22:44:23] <_av500_> [             ]
[22:44:40] <_av500_> mru: ill have a look
[22:44:46] <_av500_> the box is huge
[22:44:53] <mru> the box is always huge
[22:45:41] <_av500_> ok
[22:46:16] <mru> if it really is too big for a standard plane cabin case, we'll do something else of course
[22:46:17] <_av500_> mru: i have a corporate fedex account :)
[22:46:20] <mru> ah
[22:46:24] <mru> works for me
[22:46:34] <CIA-29> ffmpeg: Ronald S. Bultje <rsbultje at gmail.com> master * r8bcfe7f7fd ffmpeg/libavcodec/ (h264_cabac.c h264_cavlc.c):
[22:46:34] <CIA-29> ffmpeg: Set gray (128) U/V planes for chroma-less samples. Fixes two fate samples
[22:46:34] <CIA-29> ffmpeg: when played with -flags emu_edge.
[22:46:41] <lyakh> yeeks... no... it was "-g -O3"... hmmm
[22:46:45] <mru> I do have a 7109 board already
[22:46:48] <BBB> shit
[22:46:50] <BBB> it committed both
[22:46:53] <BBB> sorry guys
[22:46:54] <mru> but I'm not entirely sure it works
[22:46:55] <CIA-29> ffmpeg: Ronald S. Bultje <rsbultje at gmail.com> master * r66c6b5e2a5 ffmpeg/libavcodec/ (10 files): Revert 2a1f431d38ea9c05abb215d70c7dc09cdb6888ab, it broke H264 lossless.
[22:47:01] <BBB> now what do I do?
[22:47:15] <mru> nothing
[22:47:16] <Dark_Shikari> Isn't that fine?
[22:47:17] <_av500_> undi
[22:47:19] <_av500_> undo
[22:47:28] <mru> the other patch looked fine to me
[22:47:31] <BBB> the first patch wasn't approved yet I think
[22:47:33] <mru> but I'd rather have Dark_Shikari say so
[22:47:59] <mru> it's the patch you mailed, right?
[22:47:59] <Dark_Shikari> Now it's approved.
[22:48:07] <Dark_Shikari> BBB: in the future, push pushes ALL your patches.
[22:48:31] <BBB> yes it's the one I mailed
[22:48:34] <mru> oh well, no harm done
[22:48:49] <BBB> Dark_Shikari: so how do I push just one? mru said origin hash:master, I did that but it pushed both
[22:49:03] <mru> that pushes everything between origin and $hash
[22:49:09] <BBB> oh
[22:49:14] <mru> I said do that if $hash immediately follows origin
[22:49:21] <mru> and you have more work on top that's not ready
[22:49:26] <BBB> oh, I thought origin was my local head
[22:49:35] <BBB> I'm confused by these terms
[22:49:37] <mru> origin is remote head, give or take
[22:53:14] <BBB> got it
[22:57:36] <DonDiego> pasteeater: what about the website?
[23:02:19] <DonDiego> omg, libmpcodecs...
[23:02:31] <DonDiego> mru: what's the status of zlib?
[23:02:34] <Dark_Shikari> lol yes he merged it
[23:03:09] <mru> DonDiego: I need to fix a bug
[23:03:19] <mru> and I will fix it, but not tonight
[23:03:27] <DonDiego> sure
[23:03:28] * Compn still wants valid reasons to nix libmpcodecs :P
[23:03:33] * Compn afk now tho
[23:03:43] <DonDiego> we should look out for distinctive features
[23:06:00] <DonDiego> should i make the ffmpeg.org commits go to -commits?
[23:09:58] <DonDiego> mru: i'll look at build system stuff tomorrow when i'm properly awake
[23:10:01] <DonDiego> gnite guys
[23:18:08] <saste> hi all
[23:18:31] <mru> hi saste
[23:18:37] <saste> hi mans
[23:30:53] <lyakh> wow... just noticed and read that "maintenance" thread... seems like a tough time for the project...
[23:32:09] <lyakh> ok, gn8 all
[23:47:26] <mru> http://gmane.org/
[23:47:30] <mru> look at the top 10
[23:57:55] <CIA-29> ffmpeg: Justin Ruggles <justin.ruggles at gmail.com> master * rfcdf0a43cd ffmpeg/libavcodec/ (iirfilter.c iirfilter.h):
[23:57:55] <CIA-29> ffmpeg: Add biquad high-pass and low-pass IIR filters.
[23:57:55] <CIA-29> ffmpeg: Signed-off-by: Mans Rullgard <mans at mansr.com>
[23:58:03] <CIA-29> ffmpeg: Justin Ruggles <justin.ruggles at gmail.com> master * r0361d13cf3 ffmpeg/libavcodec/iirfilter.c:
[23:58:03] <CIA-29> ffmpeg: iir: change filter type if/else to a switch.
[23:58:03] <CIA-29> ffmpeg: Simplifies error handling and makes it easier to add additional filter types.
[23:58:03] <CIA-29> ffmpeg: Signed-off-by: Mans Rullgard <mans at mansr.com>