[FFmpeg-devel-irc] IRC log for 2011-02-08

[irc at mansr.com]

[00:10:13] * lu_zero is eventually back
[00:10:35] <mru> wb
[00:10:46] <lu_zero> did I miss anything?
[00:10:56] <mru> only gabu
[00:11:08] <Sean_McG> killed the channel dead :|
[00:11:33] <mru> he is a bit toxic
[00:11:48] <jannau> at least he admits it
[00:12:09] <lu_zero> interesting
[00:12:29] <lu_zero> btw good news, I still have 3 months of applecare!
[00:12:45] * lu_zero tomorrow will have his laptop sent to repair...
[00:12:58] <Sean_McG> lu_zero: what happened?
[00:13:08] <mru> it turned into cider
[00:13:16] <Sean_McG> oh, lovely
[00:13:19] <lu_zero> Sean_McG: no clue at all
[00:13:31] <mru> indeed, a miracle
[00:13:37] <ohsix> just didn't power on one day?
[00:14:04] <lu_zero> basically we went having dinner and once in the room it couldn't boot anymore...
[00:14:13] <Sean_McG> my MBP seems OK... wish it was one of the Nehalem ones though
[00:14:40] <Sean_McG> I might get one of the Nehalem iMacs when this kicks the bucket
[00:14:44] <Sean_McG> spendy though
[00:14:48] <ohsix> Sean_McG: the cpu is socketed :D
[00:15:10] <Sean_McG> this is a 2008 15" C2D 2.4
[00:15:20] <Sean_McG> wow, alphabet soup
[00:15:50] <iive> lu_zero: it doesn't show any post or just can't boot from disk?
[00:16:44] <ohsix> dead, usually
[00:17:29] <ohsix> they service it as a "logic board" problem, but the efi update process they use can brick it in some cases
[00:18:28] <ohsix> (to update the bios w/system updates they put it in the efi system partition then bless it; interrupting it in any phase after that is big trouble)
[01:19:54] <BBB> astrange: split is fine
[01:20:03] <BBB> astrange: but the non-vp3 parts werent' posted yet ;)
[01:20:08] <BBB> astrange: also, I don't care about whitespace
[01:20:15] <BBB> astrange: 80% performance improvement!!! :-p
[01:20:18] <BBB> astrange: anyway
[01:20:30] <BBB> astrange: point was, are you OK with me committing the threading framework, patch 2/6?
[01:20:33] <Dark_Shikari> oh yeah, is someone with bigendian support ever going to bench my patch?
[01:20:35] <Dark_Shikari> or should I just commit?
[01:20:37] <BBB> astrange: or do you want ot do more work?
[01:20:44] <BBB> Dark_Shikari: just commit if nobody did it
[01:20:52] <BBB> Dark_Shikari: I tried, that's all I could do :-p if it sucks, their own fault
[01:21:22] <Dark_Shikari> could you bench it?
[01:21:35] <Dark_Shikari> BBB: ETA for Sandy Bridge is march btw
[01:22:34] <BBB> do I get one for free in my new, free laptop?
[01:22:44] <Compn> someone giving away laptops? :P
[01:23:17] <Compn> i'm actually kinda surprised no hardware guys have tried to bribe ffmpeg project with free swag
[01:23:27] <Compn> i guess maybe some companies have given away stuff at conferences
[01:23:34] * Compn wonders what went on at the webm-summit
[01:24:21] <kierank> Compn: don't understand why they can't live stream it
[01:27:34] <astrange> BBB: updated 2/6, and 3-6/6, are fine by me
[01:28:21] <BBB> I already applied 3-4/6
[01:28:25] <BBB> I believe
[01:28:38] <BBB> the vp3 table init -> new func and simplification something ones
[01:28:43] <BBB> they were rather simple
[01:28:46] <astrange> looks like it
[01:29:10] <astrange> outstanding ones are mt, deprecate avcodec_thread_init, vp3
[01:31:18] <astrange> er, don't apply the second one
[01:32:07] <astrange> it removes avcodec_thread_free() entirely, because i found no callers of it outside lavc (using google code search)
[01:32:17] <astrange> but this might be one http://google.com/codesearch/p?hl=en#uIdZ2LsHk6E/trunk/libraries/FFMpeg/src/main/java/com/nativelibs4java/ffmpeg/avcodec/AvcodecLibrary.java&q=avcodec_thread_free&sa=N&cd=66&ct=rc
[01:32:59] <astrange> i'll send an updated version. it's not important for anything anyway
[01:33:57] <ohsix> astrange: ooh good idea with google code search
[01:34:10] <ohsix> need to remember that :]
[01:41:12] <BBB> astrange: send new set and I'll apply all, has been out for review long enough; how long until you'll send the h264/h263 ones?
[01:54:14] <astrange> RFC rsn, appliable after i finish debugging it
[01:55:52] * Orphis hates debugging bash and make files
[01:56:13] <Orphis> It's blocking on fate-vsynth1-error
[01:56:53] <Orphis> Is there a way to run only this test through the makefile ?
[01:57:02] <BBB> make fate-vsynth1-error
[01:57:13] <astrange> with V=1 to show the command you want
[02:03:18] <Orphis> That's way better to debug :p
[02:04:14] <Orphis> I see the problem, alright
[02:09:33] <mru> "No trolls were harmed in the making of this movie."
[02:10:24] <Orphis> I see the problem in the command line, now I have to find where it is called...
[02:10:48] <mru> what's the problem?
[02:11:47] <Orphis> "/cygdrive/d/Programming/ffmpeg"/tests/fate-run.sh fate-vsynth1-error "/home/fate/samples" "" "/cygdrive/d/Programming/ffmpeg" 'codectest vsynth1' '' '' ''
[02:11:47] <Orphis> /cygdrive/d/Programming/ffmpeg/ffmpeg -v 0 -y -flags +bitexact -dct fastint -idct simple -sws_flags +accurate_rnd+bitexact -qscale 7 -flags +mv4+part+aic -mbd rd -ps 250 -error 10 -f image2 -vcodec pgmyuv -i /cygdrive/d/Programming/ffmpeg/tests/vsynth1/%02d.pgm -an -vcodec mpeg4 /cygdrive/d/Programming/ffmpeg/./tests/data/vsynth1/error-mpeg4-adv.avi
[02:12:06] <mru> and what is the problem?
[02:12:19] <Orphis> It's calling ffmpeg (that doesn't understand cygwin paths) with a cygwin path
[02:12:42] <Orphis>  /cygdrive/d/Programming/ffmpeg
[02:12:54] <mru> bad mix of cygwin and non-cygwin parts
[02:13:05] <Orphis> I know
[02:13:42] <Orphis> I could make some tests to run with : make fate TARGET_PATH=`cygpath -am .`
[02:15:37] <Orphis> Oh no, I forgot to run the test with the TARGET_PATH
[02:15:57] <Orphis> Then it runs the following line that looks correct : D:/Programming/ffmpeg/ffmpeg -v 0 -y -flags +bitexact -dct fastint -idct simple -sws_flags +accurate_rnd+bitexact -qscale 7 -flags +mv4+part+aic -mbd rd -ps 250 -error 10 -f image2 -vcodec pgmyuv -i D:/Programming/ffmpeg/tests/vsynth1/%02d.pgm -an -vcodec mpeg4 D:/Programming/ffmpeg/./tests/data/vsynth1/error-mpeg4-adv.avi
[02:16:02] <astrange> resent
[02:20:07] <BBB> ty
[02:38:03] <bcoudurier> astrange, what's the reason to extend AVCodec instead of putting the functions in AVCodecContext ?
[02:41:02] <astrange> they're codec specific
[02:41:16] <astrange> but not more specific than that
[02:46:41] <Orphis> The problem seems to come from the glob
[06:46:58] <elenril> morning
[06:52:18] <_av500_> +1
[06:53:51] <Sean_McG> +/- inf
[06:55:20] <saintdev> -0
[07:06:22] <ggergely> hello
[07:24:54] <KotH> salut
[07:25:10] <spaam> good morning :)
[07:26:56] <benoit-> good morning
[07:27:05] <elenril> :/ exactly what i expected
[07:27:16] * benoit- too
[07:28:01] <elenril> how about people stop feeding them?
[07:30:52] <benoit-> elenril: it seems people cannot do that, I was told yesterday
[07:37:11] <peloverde> I don't see what the harm in banning them is. It's not like they intend to contribute.
[07:39:02] <ggergely> welcome to the world of FREE software. ban everyone. for FREEDOM :)
[07:39:26] * elenril troll detected
[07:39:35] <ggergely> yeah.
[07:40:03] <peloverde> anyone is welcome to use the software for any purpose
[07:40:33] <ggergely> homoz detected. but put  my natural disgust for them aside, i want to see what will come out of the whole coup soap-opera. and i have heard that this new fron t has also been opened
[07:41:09] <elenril> :(
[07:41:23] <elenril> i always wanted to ban somebody
[07:41:29] <peloverde> homophobic language is not cool, this isn't xbox live
[07:41:42] <ggergely> yeah. you have to love everyone
[07:43:22] * bilboed-tp found it sad not all parties were at fosdem despite being invited/sponsored :(
[07:44:06] <ggergely> criticizsmpfobic language, calling everyone trolls is also not welcome. in the name of freedom :) actually on irc i can understand, but on a mailing list. it is extremely funny. to censor a mailing list. as we could just learn on the Egyptian example: censoring will not work
[07:44:51] <ggergely> mostly in case if the one being censored has right point, apart from the style
[07:44:59] <ggergely> *points
[07:45:24] * elenril yawns
[07:45:44] <elenril> i've seen better trolls
[07:45:49] <elenril> go do something useful
[07:45:52] <ggergely> sure.
[07:45:55] <ggergely> i'm doing
[07:46:04] <ggergely> you are only for my entertainment meanwhile
[07:47:01] <cartman> moin
[07:47:17] <Sho_> pretty broad ban mask there, remember to remove that at some point
[07:47:29] <KotH> hoi cartman
[07:47:47] <KotH> Sho_: we're generally annoyed by the behavoir of hungarian people
[07:48:13] <cartman> and the Hungarian coding style too
[07:48:25] <KotH> Sho_: considering how many of them have anything constructive to say, it's a wonder that .hu isn't already banned completely
[07:49:07] <Sho_> KotH: per-ISP bans just rub me the wrong way considering I couldn't access the ffmpeg SVN repo for months from Arcor/Vodafone due to something similar ;)
[07:49:24] <KotH> Sho_: i'm sorry for that, but it was necessary
[07:49:43] <Sho_> it's alright, there ware useful git mirrors around ..
[07:49:54] <KotH> Sho_: the alternative would have been shuting down mphq completely because we would have been kicked out from our current hoster
[07:52:17] <peloverde> If someone wants to unban him or do a narrower ban go for it, i'm not really an IRC expert, just sick of him
[07:54:24] * elenril kicks his isp
[08:05:12] <Dark_Shikari> Oh wow, this is brilliant.
[08:05:14] <Dark_Shikari> http://www.ykombinator.com/
[08:05:19] <Dark_Shikari> Random startup generator.
[08:05:37] <Dark_Shikari> The funniest part is that it could _completely_ fool many of the web 2.0 people.
[08:07:15] <peloverde> I feel like some of the web 2.0 startups these days are the pets.com of this bubble
[08:07:48] <Dark_Shikari> I don't think any are quite the same.
[08:07:53] <Dark_Shikari> We seem to have two categories this time:
[08:08:04] <Tjoppen> the scroll-down spoiller ruins it a bit though
[08:08:07] <Dark_Shikari> 1) Large-scale things that *make mone*, but people put way too much stock into.
[08:08:11] <Dark_Shikari> *money
[08:08:15] <Dark_Shikari> for example, Groupon
[08:08:26] <Dark_Shikari> 2) Smaller-scale things that are just pants-on-head retarded.
[08:08:39] <elenril> like playing video games over the network
[08:08:58] <Dark_Shikari> Yeah, what a dumb idea that one is.
[08:09:36] <Dark_Shikari> I think this is better than the 2005-ish bubble though, because that one was all about startups with no business model at all.
[08:09:45] <Dark_Shikari> At least this time they're trying.  Somewhat.
[08:09:52] <peloverde> I don't quite get quora
[08:10:01] <Dark_Shikari> isn't quora just a stackoverflow knockoff thing?
[08:11:07] <peloverde> quora seems to be trying to carve out of the same space as stack*, expersexchange, and yahoo answers
[08:11:44] <Dark_Shikari> Also, the top comment on HN about this site:
[08:11:46] <Dark_Shikari> "
[08:11:47] <Dark_Shikari> I propose the ycombinator turing test. Can you generate an application which will get accepted by ycombinator? This may require generating additional content to establish team credibility including twitter posts, blog posts, etc.
[08:11:52] <Dark_Shikari> "
[08:12:14] <Dark_Shikari> i.e. can someone get a randomly-generated startup accepted by VCs.
[08:17:35] <peloverde> I constantly read about the tech pundits talking about quora but I don't know anyone who actually uses quora
[08:17:58] <Dark_Shikari> Replace Quora with anything in that sentence.
[08:18:03] <Dark_Shikari> Bubble 3.0 described in one sentence.
[08:18:55] <peloverde> I think twitter and groupon are overhyped but i know people that use the services
[08:18:58] <votz> Dark_Shikari: reminds me of http://itsthisforthat.com/, which I think we lol'd at before when it came out last year
[08:19:38] <peloverde> It seems like everyone is jumping on the quora bandwagon because the guy behind it was CTO of facebook and they are scared of missing the next-big-thing
[08:21:06] <Tjoppen> votz: awesome
[08:21:59] <votz> Tjoppen: haha ya, some of the generated ideas are just brilliant
[08:22:25] <Tjoppen> I got "CPA ad network for Erlang enthusiasts", but then I reaslized that anything aimed solely at them would be hilarious
[08:22:35] <votz> lol
[08:22:44] <peloverde> "Flickr for adult dancers" actually sounds like a good idea
[08:23:08] <votz> That's the genius of it
[08:59:11] <av500> Dark_Shikari: "i.e. can someone get a randomly-generated startup accepted by VCs."
[08:59:20] <av500> Dark_Shikari: if you manage that, you have generated a startup
[09:00:10] <Dark_Shikari> av500: of course, a randomly-generated startup is still a startup.
[09:01:24] <peloverde> http://www.xkcd.com/810/
[09:03:47] <DonDiego> peloverde: inspired by hungarian trolls? :)
[09:04:18] <peloverde> That was when I originally thought of it
[09:04:41] <peloverde> but I think it also applies to the random startup generator or the random IEEE paper generator
[09:05:33] <av500> random generator, then peer review, then feed that back into the generator :)
[09:05:39] <av500> iterate
[09:05:47] <j-b> 'moroning
[09:06:08] <av500> j-b: how was the döner?
[09:06:32] <cartman> köfte!
[09:06:57] * kshishkov would like start up PDP-10 but he doesn't have any
[09:10:05] * cartman finally FATEs again
[09:13:13] <spaam> cartman: yoyoy
[09:13:23] <spaam> cartman: they fixed the bug ;D
[09:13:54] <cartman> yes, with my cool bisect & reduce skillz
[09:13:59] <cartman> I sent them teh codez
[09:14:30] <merbzt> when remuxing h264 in mov the payload is changed slightly for some reason what could be the problem ?
[09:14:46] <spaam> cartman: zomg .. _awesome_
[09:14:51] <Dark_Shikari> Remuxing in mov -> You mean 「mov -> mov」?
[09:16:37] <merbzt> mov->mov
[09:16:47] <cartman> mov eax,eax
[09:17:06] <Dark_Shikari> Have you tried doing 「mov -> mov -> h264」and comparing to 「mov -> h264」?
[09:17:36] <Dark_Shikari> You might also want to try demuxing with something else and comparing.
[09:17:40] <Dark_Shikari> Such as gpac.
[09:17:41] <merbzt> hmm, think I found the issue
[09:18:44] <av500> cartman: here: http://www.flickr.com/photos/av500/5427778410/
[09:19:00] <cartman> av500: \o/
[09:19:12] <cartman> absolutely Turkish
[09:19:13] <cartman> awesome
[09:20:20] <spaam> av500: what is that?
[09:20:33] <cartman> spaam: "Urfa" as we call it
[09:20:34] <cartman> yummy
[09:23:16] <kshishkov> spaam: looks like a thing people invent när de har ingen riktiga köttbullar med potatismos
[09:23:42] <spaam> kshishkov: verkar som så :)
[09:37:51] * pross-au is in floating point hell
[09:38:29] <cartman> I bet its hard
[09:38:53] <merbzt> pross-au: is it x87 floating point ?
[09:40:20] <pross-au> Yaaa
[09:41:07] <kshishkov> as in "here is some Bink IDCT asm with x87 instructions" hell?
[09:41:09] <pross-au> i want to retain bit-exactness on x86
[09:41:20] <pross-au> kshishkov: Yes
[09:41:53] <Dark_Shikari> Bink itself doesn't have an SSE one that's auto-loaded based on CPU capabilities?
[09:42:18] <Dark_Shikari> I don't think bit-exactness for idcts is that critical when the difference is going to be in the 10th decimal of rounding error.
[09:42:54] <Dark_Shikari> For MPEG-2 it's a significant issue because the error is in the ~16th decimal point (measured in binary)
[09:43:05] <Dark_Shikari> But with "double", the error will be something like the 40th or 50th.
[09:43:21] <kshishkov> so it drifts
[09:43:32] <Dark_Shikari> The drift should be basically minimal unless Bink doesn't have keyframes.
[09:43:36] <kshishkov> and is that bitexact IDCT standardised yet?
[09:43:48] <pross-au> Dark_Shikari: bink doesnt have keyframes
[09:44:00] <Dark_Shikari> What do we do for Bink IDCT currently?
[09:44:07] <kshishkov> new Bink uses integer IDCT anyway
[09:44:21] <kshishkov> but version b had floating-point IDCT
[09:44:51] <Dark_Shikari> Suggestion: write x87 softfloat lib for libavutil.  Use this for Lagarith (replace current code).
[09:45:08] <Dark_Shikari> On actual x86, write an asm version of the idct that's bit-exact.  Use this when available.
[09:45:13] <pross-au> man that sounds fun
[09:45:15] <Dark_Shikari> On non-x86, call the x87 softfloat lib if +bitexact is enabled.
[09:45:33] <Dark_Shikari> Or maybe if it's not, because of the drift issue.
[09:45:37] <kshishkov> Dark_Shikari: okay, libavemu is on you
[09:45:42] <Dark_Shikari> I don't think it's very difficult if you only do arithmetic.
[09:45:51] <Dark_Shikari> It would be much more difficult if you did transcendental functions.
[09:46:01] <Dark_Shikari> But I don't think an iDCT uses sqrt, sin, pow, exp, cos, etc.
[09:46:12] <Dark_Shikari> Lagarith already has at least one op implemented for you to start with.
[09:49:58] * elenril wonders how much is microsoft's asf specs licence valid in eu
[09:56:45] <peloverde> USAC is getting a new (M)PS? decorator, just what I needed
[09:56:56] <peloverde> I really hope USAC does not take off
[10:00:40] <kshishkov> what does that mean? That future audio working draft now has some parametric stereo shit?
[10:08:32] <peloverde> it means that it has a new implementation of the same parametric stereo shit
[10:08:42] <peloverde> easier to implement but harder to reuse
[10:10:50] * kshishkov dislikes word "parametric" when applied to audio
[10:11:42] <peloverde> I prefer the name "placebo stereo"
[10:12:10] <kshishkov> SOAL
[10:12:14] <Dark_Shikari> peloverde: An interesting note is that, IIRC, listening tests showed that PS didn't help perceptual quality.
[10:12:23] <Dark_Shikari> And sometimes even hurt.
[10:12:29] <kshishkov> *SAOL
[10:12:34] <Dark_Shikari> (Unlike SBR, which helped greatly.)
[10:12:50] <kshishkov> Dark_Shikari: who cares, it's patents we're talking about
[10:13:04] <peloverde> do you mean listening tests of real encoders or of the reference encoder?
[10:13:09] <Dark_Shikari> Real encoders.
[10:13:22] <superdump> and at what bitrates?
[10:13:33] <Dark_Shikari> The bitrates that HE-AACv2 was supposed to do well at (e.g. 16-32kbps).
[10:13:40] <peloverde> see that's the problem, the listening test that mpeg uses are based on the reference encoder which had super shitty LC but reasonable SBR and PS
[10:13:52] <Dark_Shikari> We were discussing this in #celt a while back -- they encountered the same problem when working on CELT.
[10:13:59] <Dark_Shikari> That is, really *terrible* emulated stereo is worse than mono.
[10:14:16] <Dark_Shikari> If you don't have a sufficient amount of stereo information, it's actually counterproductive.
[10:15:53] <Dark_Shikari> (Note: this might not be true in the general case.  It is of course possible that someone simply hasn't discovered a very good way of doing it.)
[10:16:30] <Dark_Shikari> It could be exacerbated by the fact that mid/side coding is not a very good way of representing stereo differences due to issues such as time delays.
[10:17:34] <peloverde> Do you have any reasonably sized, non-ABX perceptual tests you can link?
[10:18:29] <Dark_Shikari> I'll ask the CELT guys for the link, I don't think I have it anymore.
[10:19:41] <Dark_Shikari> http://www.mp3-tech.org/tests/aac_48/results.html  I think this is it?
[10:20:15] <Dark_Shikari> http://www.mp3-tech.org/tests/aac_48/plot_overall_zoomed.png
[10:20:25] <peloverde> That's ABX
[10:20:34] <Dark_Shikari> What's the problem with AVX?
[10:20:35] <Dark_Shikari> er, ABX?
[10:20:40] <Dark_Shikari> Aren't basically all tests done as ABX?
[10:20:51] <peloverde> that's also at the top of the PS range
[10:20:54] <Dark_Shikari> True.
[10:21:12] <peloverde> there is a certain point where quality is so distorted that no one is going to confuse it with the original
[10:21:30] <Dark_Shikari> I don't think the purpose of the test is to see whether people can tell it apart from the original.
[10:21:45] <Dark_Shikari> I can see your point if you're worried about "If you don't have the context of the original, the results might change."
[10:22:33] <peloverde> "The ABX mode is meant to allow the listener to identify subtle differences between any two samples. Typically, one of the samples will be the original file. One of the samples is assigned to be 'A' and the other is assigned to be 'B'. Either sample A or Sample B is randomly assigned to be 'X'. The listener must determine whether X is the same as A or B. By performing this test multiple times, the listener can show with a speci
[10:22:34] <peloverde> fied level of confidence that his results are not by chance alone."
[10:22:53] <Dark_Shikari> That's not what that test is.
[10:23:01] <Dark_Shikari> The listeners were told to rate them from 1 to 5.
[10:25:28] <peloverde> ok
[10:25:38] <Dark_Shikari> I agree that 48kbps is a bit high for v2.
[10:26:15] <merbzt> ok, there is a regression or bug in the mov stream remux for h264
[10:26:19] <peloverde> indeed: http://ctaacplus.com/products/aacPlus.htm
[10:26:23] <bgmarete> Hello. A fix for https://roundup.ffmpeg.org/issue481 would also fix a bug in which one cannot use .sdp file to to access a stream that another app on the local machine is also accessing -- One cannot pass reuse=1 to an SDP url. Can anyone help?
[10:26:51] <peloverde> 48 is where CT claims V1 reaches parity with V2, V2 is "supposed to" win below
[10:26:56] <wbs> bgmarete: I posted a polished up patch for that yesterday evening
[10:26:57] <merbzt> bgmarete: talk to luca and wbs about that
[10:27:03] <Dark_Shikari> The test suggests that v2 still loses to v1 at 48kbps.
[10:27:27] <bgmarete> wbs: Thanks a lot. Will check the mailing list. merbzt: Much obliged.
[10:27:56] <peloverde> which really isn't surprising if you allocate 10% to marketing hype
[10:27:58] <merbzt> bgmarete: luca -> lu_zero
[10:28:08] <Dark_Shikari> peloverde: True indeed~
[10:28:26] <bgmarete> merbzt: Thanks.
[10:29:00] <peloverde> Now 24 kpbs is where the two curves really separate according to CT so that would be a slightly more interesting test to see if PS is at all useful
[10:30:38] <peloverde> Still in general i don't think PS is worth the hassle, at 24k both signals were substantially degraded
[10:30:59] <Dark_Shikari> I think someone needs to come up with a stereo coding method better than mid/side.
[10:31:04] <Dark_Shikari> For example, something that codes delays for each band.
[10:31:44] <peloverde> Dark_Shikari: that's actually more-or-less what PS is based on
[10:31:56] <Dark_Shikari> Ah, interesting.
[10:32:06] <Dark_Shikari> But what about using it for _normal_ stereo coding?
[10:32:11] <Dark_Shikari> i.e. with the intent of being near-transparent?
[10:32:18] <Dark_Shikari> instead of just using it to emulate stereo with few bits.
[10:32:19] <peloverde> of course PS has a fixed band-delay curve, and allocates very few bits to describing anything
[10:32:21] <peloverde> indeed
[10:32:39] <peloverde> It might be interesting, but I imagine CT probably already tried that
[10:32:41] <Dark_Shikari> CELT can't do this because its frame sizes are too small for the overhead to be worth it, iirc.
[10:32:47] <Dark_Shikari> So they haven't investigated it.
[10:33:09] <peloverde> seeing as they pretty much had a solution looking for a problem
[10:36:23] <peloverde> I think something that attempts to integrate with the core-coder's TF model may have more luck
[10:43:44] <Flameeyes> mru: okay I've got the tinderbox working again, will rebuild all ffmpeg deps in a bit
[11:14:20] <Dark_Shikari> peloverde: interesting comment.
[11:14:21] <Dark_Shikari> 22:13 < jmspeex> What I suspect is that v2 may not sound *that* bad with speakers instead of headphones
[11:15:04] <kshishkov> especially with shitty speakers and Gduim audio output device
[11:17:43] <merbzt> k, I found the code that messes up mov->mov remux
[11:18:10] <av500> <drumroll>
[11:18:12] <merbzt> if (enc->codec_id == CODEC_ID_H264) size = ff_avc_parse_nal_units(pb, pkt->data, pkt->size);
[11:18:50] <cartman> and?
[11:18:50] <merbzt> how do I detect when the stream is already from a proper container ?
[11:19:32] <av500> so h264 can be both raw and in NALs?
[11:19:54] <Dark_Shikari> It's always in NALs.
[11:20:12] <lu_zero> av500: that reminds me
[11:20:19] <av500> lu_zero: yeah
[11:20:53] * lu_zero will have to bring his laptop to the store at 1.40pm
[11:21:09] <kshishkov> lu_zero: use your sister's ;)
[11:21:29] <lu_zero> kshishkov: she doesn't have a laptop yet
[11:21:41] <lu_zero> and right now I'm using the efikasb
[11:21:42] <cartman> buy one
[11:21:55] <kshishkov> lu_zero: that's what you showed to me.
[11:22:06] <kshishkov> lu_zero: it has display, keyboard and portable
[11:22:18] <lu_zero> works almost fine even if I should update the software to the latest
[11:23:13] <kshishkov> to the latest Gentoo?
[11:24:12] <merbzt> http://git.ffmpeg.org/?p=ffmpeg.git;a=blob;f=libavformat/movenc.c;h=0949d294571e7be5a8ebda3f3d731f9fff122a24;hb=HEAD#l1944
[11:25:13] <merbzt> that parsing messes up the stream when I remux mov->mov
[11:25:35] <lu_zero> kshishkov: latest sources for x11
[11:26:46] <av500> lu_zero: I fail to install the efika here
[11:26:52] <lu_zero> merbzt: that code shouldn't be there...
[11:26:56] <lu_zero> how so?
[11:26:57] <av500> the ubuntu image starts but then looses display
[11:27:20] <lu_zero> which kernel does it sport?
[11:27:58] <lu_zero> it is a to2 device so it has a number of glitches
[11:28:21] * lu_zero thought you were just collecting it
[11:28:30] <av500> :)
[11:28:38] <av500> lu_zero: no idea
[11:28:52] <av500> i followed the instructions, upgrade uboot and then maverick
[11:29:11] <av500> ubu boots and as soon as it asks me for language, the display is off ...
[11:29:17] <lu_zero> =|
[11:29:21] <kshishkov> lu_zero: how do you distinguish them?
[11:29:32] <lu_zero> kshishkov: different labelling
[11:30:10] <kshishkov> lu_zero: without disassembly. I got two and one had only half disk space. Also it required upgrading OS.
[11:30:23] <lu_zero> check the back
[11:30:28] * av500 glares at lu_zero
[11:30:41] <lu_zero> av500: ^^?
[11:30:54] <av500> for givin me broken stuffz
[11:31:14] <lu_zero> av500: it was among the rarest item
[11:31:26] <lu_zero> s/broken/quirky/
[11:31:36] <av500> lu_zero: well, got more
[11:31:39] <av500> get more
[11:31:41] <av500> get working ones
[11:31:49] <lu_zero> =P
[11:31:52] <kshishkov> lu_zero: mine has serial 09BPEX213828
[11:32:06] <lu_zero> this summer will do ^^
[11:32:22] <av500> lu_zero: what is your connection to efika?
[11:32:47] <lu_zero> I hack on it and I know the people from Genesi since ages
[11:32:55] <av500> ic
[11:33:30] <av500> why does it come up in 1280x800 and not 1280x720?
[11:35:05] <lu_zero> interesting question, which monitor are you using?
[11:35:11] <lu_zero> hdmi or dvi?
[11:36:27] <av500> er
[11:36:30] <av500> both
[11:36:35] <av500> let me try the other one
[11:36:44] <Flameeyes> lu_zero: was it in warranty then?
[11:37:44] <av500> lu_zero: ah, its 720 on the hdmi input
[11:38:24] <lu_zero> Flameeyes: yup
[11:38:31] <Flameeyes> lu_zero: poor support centre
[11:38:49] <lu_zero> Flameeyes: why?
[11:39:00] <Flameeyes> you abuse them! :P
[11:39:27] <lu_zero> Flameeyes: apparently there were already a recall regarding the nvidia chip that I somehow missed
[11:39:27] <av500> lu_zero: same thing, as soon as i click on the lang selection, it goes boom
[11:39:49] <Flameeyes> lu_zero: ... you got the faulty nvidia laptop and _never got it replaced_?
[11:40:15] <lu_zero> av500: makes no sense, it should have issue only with neon
[11:40:23] <kshishkov> Flameeyes: "faulty", "nvidia" <- I smell redundancy here
[11:40:49] <lu_zero> Flameeyes: it should had been the other times and/or I did not have the issue
[11:40:50] <Flameeyes> I'm surprised it lasted this long, two friends of mine had the same issue and it was dead on its step after no longer than an year and a half
[11:42:02] <Flameeyes> uhm I think I need to make sure my VMs are updated.. I had Ubuntu 9.10 still =_=
[11:42:47] <spaam> what software do you use for VM stuff? kvm? virtualbox?
[11:42:53] <spaam> other?
[11:42:56] <Flameeyes> libvirt&&kvm
[11:43:19] <Flameeyes> but only for unices.. Windows it's on Parallels
[11:44:02] <spaam> ok :)
[11:44:43] <av500> lu_zero: ah, its only the display that goes away, unplug and replug of hdmi "fixes" it....
[11:44:44] <Flameeyes> and of course it's always a question of whether kvm decides to boot up a given non-Linux target or not
[11:45:01] <Flameeyes> so latest version works fine with Solaris... but fails with FreeBSD
[11:45:04] <lu_zero> av500: ahh...
[11:45:10] <spaam> Flameeyes: =/
[11:45:13] <lu_zero> which display is it?
[11:45:22] <av500> some samsung 1080p monitor
[11:45:27] <av500> it might be picky....
[11:45:33] <av500> will connect something else
[11:45:51] <lu_zero> av500: I have one as well
[11:45:54] <Flameeyes> spaam: the solution would probably be asking the qemu/kvm maintainers to ensure we have the latest version/patchset...
[11:45:57] * Flameeyes looks at lu_zero
[11:46:09] <lu_zero> the latest kernel should fix it
[11:46:47] <Flameeyes> lu_zero: define "latest"
[11:46:47] <lu_zero> Flameeyes: let me first fix evas, get the desktop working, sort out what to do with timeshift and get my laptop repaired
[11:47:12] <lu_zero> Flameeyes: latest -> latest kernel fixes the av500 issue with samsung monitors...
[11:47:14] <Flameeyes> lu_zero: I'd change the priority of desktop and evas
[11:47:25] <Flameeyes> ah okay for a moment I thought you were telling me to update for kvm :P
[11:47:36] <lu_zero> Flameeyes: evas is part of getting the desktop working...
[11:47:41] <Flameeyes> [which was possible given I got "not implemented" dmesg when starting Solaris]
[11:48:17] * thresh had a lot of fun with kvm-based "enterprise cloud solutions"
[11:48:37] <thresh> xen, otoh, is even worse
[11:48:47] <thresh> worse as in enteprisy
[11:49:15] <Flameeyes> thresh: don't get me started, I have had to work with ec2
[11:49:51] <av500> lu_zero: I connected a LG 720p tv, no signal at all :(
[11:49:57] <thresh> Flameeyes: ehehe me too
[11:50:30] <thresh> the worst thing ever is Ubuntu Cloud, though
[11:50:38] <kshishkov> av500: worked fine with DVI for me
[11:50:43] <thresh> 'bringing the enterprise solutions to cooks'
[11:50:51] <kshishkov> thresh: nope, Russian NanoCloud
[11:50:54] <av500> kshishkov: what res?
[11:51:11] <kshishkov> av500: 1280xsomething
[11:51:19] <av500> kshishkov: ok, lets try that
[11:52:05] <kshishkov> av500: I think it was 1280x720
[11:52:25] <thresh> kshishkov: ну, учитывая что НацОС будет делаться из ALT Linux, не всё так плохо -- могло быть и хуже
[11:53:02] <kshishkov> thresh: например, ОС вооруженных сил
[11:53:46] <lu_zero> av500: I'd say outdated kernel...
[11:55:46] <av500> lu_zero: /me too
[11:55:49] <wbs> jannau: care to queue/push the libavfilter movie video source filter? from the "[PATCH] movie video source" thread, ok'd by michael on february 1st
[11:55:58] <av500> now i got it running 1280x958....
[11:57:30] <kshishkov> av500: maybe you should try different display
[11:57:34] <lu_zero> how O_o?
[11:57:35] <av500> kshishkov: i did
[11:57:52] <av500> and now i get 1280x958
[11:57:56] <jannau> wbs: which patch? stefano's comment in the ping mail is confusing
[11:58:05] <av500> on a 1680x1050 monitor
[11:58:17] <kshishkov> av500: I got 1280x720 on my 1920x1200 monitor
[11:58:17] <av500> lu_zero: is there a newer ubu kernel?
[11:58:45] <av500> kshishkov: yes, I get that too, it just loses picture every 10s
[11:59:36] <pross-au> 'x = a + b; y = x + c'  !=  'y = (a + b) + c'
[11:59:57] <wbs> jannau: probably one of the patches from 30th january, and the confusing comment probably concerns updating minor numbers and such, depending on what base repo it is applied on...
[12:00:37] <kshishkov> pross-au: but it is in math and ~= in FPU calculations
[12:01:08] <pross-au> im liking the idea of libavfpu
[12:01:16] <av500> lu_zero: this stock ubu image, does it have 3d accel enabled?
[12:01:22] <pross-au> av_pushf(1.2f);
[12:01:23] <av500> coz the desktop is rather slow
[12:01:34] <kshishkov> of course not
[12:01:42] <kshishkov> you need stuff from BSP
[12:02:10] <av500> kshishkov: hey, it feels like working with TI :)
[12:02:24] <kshishkov> av500: ah, that homely feeling :)
[12:03:47] <av500> yes
[12:05:12] <kshishkov> that's why I'm going to finally install Gentoo on mine and enjoy the latest stuff Luca can provide
[12:06:01] <jannau> wbs: queued
[12:06:54] <av500> kshishkov: i will follow in your footsteps
[12:07:29] <av500> lu_zero: and the 720p hw decoding is done how?
[12:07:32] <wbs> jannau: \o/
[12:18:29] <lu_zero> av500: vpu/ipu
[12:18:34] * lu_zero runs
[12:18:57] <lu_zero> brb
[12:24:43] <CIA-38> ffmpeg: Stefano Sabatini <stefano.sabatini-lala at poste.it> master * rf4acb837eb ffmpeg/doc/muxers.texi:
[12:24:44] <CIA-38> ffmpeg: Document null muxer.
[12:24:44] <CIA-38> ffmpeg: Signed-off-by: Janne Grunau <janne-ffmpeg at jannau.net>
[12:24:55] <CIA-38> ffmpeg: Stefano Sabatini <stefano.sabatini-lala at poste.it> master * r77d4ed7a12 ffmpeg/doc/muxers.texi:
[12:24:55] <CIA-38> ffmpeg: Add documentation for the framecrc muxer.
[12:24:55] <CIA-38> ffmpeg: Signed-off-by: Janne Grunau <janne-ffmpeg at jannau.net>
[12:24:58] <CIA-38> ffmpeg: Stefano Sabatini <stefano.sabatini-lala at poste.it> master * ra4effe432f ffmpeg/doc/muxers.texi:
[12:24:58] <CIA-38> ffmpeg: Add documentation for the crc muxer.
[12:24:58] <CIA-38> ffmpeg: Signed-off-by: Janne Grunau <janne-ffmpeg at jannau.net>
[12:25:03] <CIA-38> ffmpeg: Stefano Sabatini <stefano.sabatini-lala at poste.it> master * r0cad24ce9b ffmpeg/doc/muxers.texi:
[12:25:03] <CIA-38> ffmpeg: Apply misc fixes to the image2 muxer documentation.
[12:25:03] <CIA-38> ffmpeg: The fixes were pointed out by Diego.
[12:25:03] <CIA-38> ffmpeg: Signed-off-by: Janne Grunau <janne-ffmpeg at jannau.net>
[12:25:07] <CIA-38> ffmpeg: Stefano Sabatini <stefano.sabatini-lala at poste.it> master * r9409c3811c ffmpeg/ (6 files in 3 dirs):
[12:25:07] <CIA-38> ffmpeg: libavfilter: add video movie source
[12:25:07] <CIA-38> ffmpeg: See thread:
[12:25:07] <CIA-38> ffmpeg: Subject: [PATCH] movie video source
[12:25:08] <CIA-38> ffmpeg: Date: 2010-12-31 15:35:30 GMT
[12:25:08] <CIA-38> ffmpeg: Signed-off-by: Janne Grunau <janne-ffmpeg at jannau.net>
[12:50:22] <wbs> jannau: thanks for merging that, that was a quite much requested feature (for overlaying watermarks and such)
[12:50:40] <wbs> I worked on that in may 2009 sometime, it's nice to have it all merged into the normal repo now :-)
[12:50:53] <mru> now we only need to add a logo removal filter and we'll be complete
[12:51:54] * elenril wonders what mushrooms was the person who wrote asfdec smoking
[12:52:08] <mru> microsoft ones?
[12:52:36] <cartman> elenril: magical ones
[12:53:07] <Flameeyes> okay the good thing is that at least Ubuntu detected the virtio disk this time
[12:54:37] <Dark_Shikari> jannau: what do you mean by an "include/source command"?
[12:57:21] <jannau> Dark_Shikari: source libx264-common-options.ffpreset instead of duplicating all common options in each preset
[12:57:36] <Dark_Shikari> You can do that?
[12:58:16] <jannau> not now and I'm not sure if implementing is worth it
[12:58:37] <Dark_Shikari> k
[12:58:54] <av500> elenril: why?
[12:59:04] <Dark_Shikari> jannau: I think it turned out that patch was unnecessary btw
[12:59:17] <spaam> av500: maybe he want some of it :)
[12:59:21] <Dark_Shikari> int qp_max = h->param.rc.i_qp_max == QP_MAX_SPEC ? QP_MAX : h->param.rc.i_qp_max;
[12:59:43] <Dark_Shikari> Or... hmm.  that might not actually be doing what I thought it was doing.
[12:59:48] * Dark_Shikari makes a TODO to investigate this.
[12:59:58] <elenril> av500: just look at it
[13:01:15] <av500> elenril: it goes back to mr bellard
[13:01:35] <elenril> so i'm destroying a piece of history
[13:02:02] <spaam> noooo :(
[13:02:23] <kshishkov> well, Fabrice is not Michael Kalvachev
[13:02:35] <spaam> who is that?
[13:02:39] <cartman> lol
[13:02:55] <elenril> lol
[13:03:04] <kshishkov> spaam: certain Michael mutating into certain Kalvachev
[13:03:17] <kshishkov> 1) useful contributions in the past - check
[13:03:19] <elenril> kshishkov: your obscure references to obscure trolls are lost here
[13:03:50] <spaam> kshishkov: ok
[13:04:04] <kshishkov> 2) agressive reaction when someone touches their code (even for formatting) - check
[13:04:26] <cartman> now look at that, http://web.archiveorange.com/archive/v/yR2T41Zix9x6zC4jCdX5
[13:04:59] <kshishkov> 3) defending each other - check
[13:05:26] <av500> keeping kshishkov entertained on a slow day, priceless
[13:05:57] <cartman> its not a slow day I finished all my Android work
[13:06:00] <cartman> time to slack
[13:06:01] <cartman> :p
[13:07:04] <kshishkov> cartman: how do you manage to do work in that short break between slack allowed by Turkish law
[13:07:19] <cartman> kshishkov: my magic fingers does it
[13:07:40] <cartman> I got it all working on molasses slow ARMv5
[13:07:43] * kshishkov still has to publish a photo with ArchosNote and av500 magic fingers
[13:08:59] <av500> kshishkov: please submit to censor 1st
[13:09:05] <cartman> lol
[13:10:31] <kshishkov> av500: don't worry, I'll censor it myself
[13:15:15] * cartman notes that av500 has lots of circuit pr0n
[13:32:02] <pJok> mru, what about an ffmpeg-drama mailing list?
[13:38:57] <cartman> pJok: ffmpeg-kindergarden
[13:43:25] <bgmarete> Hello. I am receiving an H.264 RTP stream with the data encoded in Annex B Byte Stream, but I am stumbling on: http://permalink.gmane.org/gmane.comp.video.ffmpeg.devel/117195 every time. What is the recommended work-around? Is the attached patch okay? I noticed that there were some objections to it when it was proposed. Thanks!
[13:44:27] <pJok> cartman, or that
[13:45:07] <kshishkov> pJok: there's only one proper name for such channel
[13:45:55] <cartman> bgmarete: looks like you'll have to fix the muxer instead
[13:47:00] <kierank> cartman: you mean the demuxer
[13:47:07] <cartman> kierank: yes
[13:47:12] <bgmarete> cartman: Isn't that what that patch does?
[13:47:24] <cartman> bgmarete: no idea, I am just replaying bcoudurier :P
[13:47:43] <bgmarete> Ah, I see. Any hints? I am happy to do that since I have got to get this working :)
[13:48:04] <cartman> bgmarete: he is the TS maintainer afaik, you could send an email to that thread or start a new one
[13:48:16] <cartman> kierank will help you too
[13:48:25] <wbs> btw, nice with the gmane page above, it only specifies month and date, but not which year...
[13:48:29] <kierank> cartman: I will?
[13:48:39] <cartman> kierank: you should :P
[13:48:51] * kierank knows nothing about rtp
[13:49:05] <av500> kierank: time to learn!
[13:49:25] <bgmarete> cartman: Thanks. So bcoudurier then?
[13:49:26] <kierank> av500: I would but the rtp spec uses a font i don't like
[13:49:41] <wbs> that one doesn't have anything to do with rtp. if streamcopying h264 where 3-byte startcodes are used into the mpegts muxer, it doesn work, since it expects 4-byte startcodes
[13:49:42] <av500> kierank: nice one, noted :)
[13:49:55] <cartman> bgmarete: no try ffmpeg-devel, say this fixes a bug etc. Look for comments, fix the patch & submit :)
[13:50:07] <wbs> the patch looks sane to me, but I'm not familiar with h264 in detail
[13:50:20] <cartman> see wbs will help
[13:50:59] <bgmarete> wbs, cartman: Thanks. I will test patch and reply to that thread if it works. Many thanks.
[13:51:38] <bgmarete> wbs: BTW, the patch re: SO_REUSEADDR works fine here. Will also note that on mailing list on relevant thread. Thanks!
[13:51:50] <wbs> bgmarete: good :-)
[13:59:25] <Tjoppen> is there a way for a demuxer to signal lavfi to do cropping?
[14:02:26] <Tjoppen> I remember it being discussed for mov.c, but I don't see anything in the code about it
[14:05:40] <ruggles> Tjoppen: i don't think so. maybe something could be implement using AVPanScan or even just metadata? other filter / transformation hints would be useful too though.
[14:07:02] <Tjoppen> the archives have baptiste taking a shot at it using metadata
[14:07:39] <ruggles> maybe bcoudurier implemented it in ffmbc?
[14:10:12] <Tjoppen> using AVPanScan sounds like a decent solution, however there doesn't seem to be any way to pass such information from demuxer to decoder atm
[14:11:12] <Tjoppen> for now I think I'll just hack a bit since the only thing I need to do is crop VBI lines from raw video
[14:11:20] * av500 wonders if we will one day transport video in metadata
[14:11:34] <cartman> in elenril's dreams
[14:13:15] * elenril stabs cartman 
[14:13:19] * elenril also stabs microsoft
[14:13:37] * cartman is unstabbable
[14:13:41] <elenril> wtf is this mirror-endian notation
[14:14:01] <av500> where?
[14:14:11] <av500> asf
[14:14:15] <elenril> 30 26 b2 75 8e 66 cf 11  a6 d9 00 aa 00 62 ce 6c
[14:14:19] <elenril> this is hexdump
[14:14:39] <elenril> 75B22630-668E-11CF-A6D9-00AA0062CE6C
[14:14:44] <av500> ah
[14:14:45] <elenril> this is microsoft specs
[14:14:48] <av500> GUID
[14:14:51] <av500> yes, its crazy
[14:15:07] <av500> I copy pasted all my GUIDs from hexdump
[14:15:33] <wbs> oh, lovely
[14:15:36] <kierank> cartman: wearing a stab proof vest?
[14:15:42] <cartman> kierank: always
[14:15:45] <av500> couldnt be bothered to learn how the mirroring works
[14:15:51] <wbs> wtf does one have to interpret guids as a bunch of separate values when it just could be a byte array? ;P
[14:15:51] <cartman> you never know when an ambush is coming up
[14:16:23] <cartman> wbs: errr you'll need those to look up registry and such
[14:16:28] <cartman> you need the representation
[14:16:43] <wbs> cartman: yes, but why did they have to be designed that way in the first place?
[14:16:54] <cartman> wbs: that you ask to Raymond Chen
[14:17:09] <av500> the new old thing
[14:17:12] <cartman> right
[14:17:23] <wbs> 128 bit, interpreted as 32 bit little endian, 16 bit LE, 16 bit LE, 64 bit as 8 consecutive bytes
[14:17:29] <wbs> instead of just 16 consecutive bytes
[14:17:43] <j-b> wbs: because they have a patent on it?
[14:17:49] <wbs> j-b: obviously
[14:17:50] <cartman> remember DOS compatibility and such :P
[14:18:03] <av500> dos could support 16 consecutive bytes?
[14:18:16] <cartman> apparently not :P
[14:18:41] * cartman notes that Windows has 2 notepad.exe for compatibility
[14:18:45] <cartman> since they lack symlinks
[14:19:09] * lu_zero notes that windows has symlinks but the aren't used
[14:19:16] <cartman> only NTFS
[14:19:25] <lu_zero> cartman: yup
[14:19:39] <cartman> most of the world is still FAT16/32
[14:25:45] <kierank> gah aac specs have to use a different profile/level identifier and mp4 and ts for no reason
[14:34:29] <mru> lu_zero: windows has symlinks?
[14:34:37] <elenril> yes
[14:34:41] <mru> ntfs has hardlinks but not easy way to create them
[14:34:42] <elenril> since ntfs iirc
[14:34:55] <mru> I never saw a true symlink on windows
[14:35:04] <mru> only the ones cygwin emulates
[14:35:04] <Flameeyes> junctions
[14:35:18] <Flameeyes> junctions cross filesystem boundaries
[14:35:26] <Flameeyes> so they are in all effects symlinks
[14:35:30] <DonDiego> i remember installing a windows nt resource kit to have a tool for creating such links
[14:35:40] <Flameeyes> only works since nt5 though
[14:35:40] <kierank> iirc the x264 buildscript make cygwin create a file called "NUL" that's a nightmare to remove
[14:35:50] <mru> windows makes everything so convoluted
[14:36:17] <mru> kierank: heh, those magic names are fun
[14:38:20] <kierank> also means you can't delete the directory
[14:39:07] <kurosu> funny as the '-rf' file, too (in a college humor kind)
[14:40:24] <TheFluff> 15:34:55 <@mru> I never saw a true symlink on windows <--- I don't know the definition of a "true" symlink but they do exist on vista+ and are created with the mklink commandline tool
[14:40:41] * mru hasn't used vista or win7
[14:40:42] <Compn> winnt has them too
[14:40:45] <Compn> win2k/xp
[14:40:51] <merbzt> I used it on xp
[14:40:54] <TheFluff> which annoyingly a) takes its arguments in reverse order compared to ln(1) and b) requires admin privileges by default
[14:40:55] <j-b> TheFluff: aren't those hardlinks?
[14:40:56] <merbzt> flaky at best
[14:40:59] <KotH> TheFluff: links on windows are of the kind of short scripts
[14:41:18] <KotH> TheFluff: horribly complex and prone to fail if anything unexpected happens
[14:41:21] <mru> cygwin uses .lnk "shortcuts" for symlink emulation
[14:41:24] <TheFluff> j-b: no
[14:41:31] <TheFluff> you can create hard links with mklink too
[14:41:39] <TheFluff> but by default it creates soft ones
[14:41:42] <KotH> TheFluff: while symlinks on unix are just a special file type that contains a path as data
[14:41:52] <j-b> TheFluff: winsxs are hardlinks though, right?
[14:42:00] <Compn> there is 'junction' tool too
[14:42:04] <Compn> but what it does i have no idea :)
[14:42:12] <TheFluff> I dunno about that, I try to avoid winsxs
[14:42:44] <TheFluff> Compn: NTFS junctions support only absolute paths on local paths
[14:43:08] <TheFluff> s/local paths/local disks/
[14:43:26] <Compn> hokay
[14:43:42] <TheFluff> other than that I don't know the technical difference either :V
[14:44:42] <TheFluff> oh and apparently junctions can only link to directories too
[14:45:27] <mru> so it's more like a linux bind mount
[14:45:29] <TheFluff> most tools seem to treat junction points as hardlinks too
[14:45:34] <TheFluff> yeah
[14:45:45] <TheFluff> actually that's a better analogy than a hard link
[14:46:57] <TheFluff> junctions seem to have a lot of potential for Surprise and Confusion
[14:47:31] <TheFluff> for example if you put a junction point in the recycle bin with explorer, the folder it points to will look normal, but when you empty the recycle bin it's deleted
[14:49:41] <JEEB> yah
[14:50:00] <mru> now that sounds like fun
[14:50:26] <JEEB> Yah, it's the reason why I use msys' /etc/fstab to switch around mingw packages instead of "just using junction"
[14:58:56] <pJok> ntfs supports symlinks... shame there is no tools for it though
[14:59:22] <pJok> but many tools that dedupe on ntfs just hardlink files
[14:59:46] <mru> filesystem support isn't everything
[15:00:00] <pJok> the os supports them too
[15:00:05] <mru> how do standard tools and syscalls deal with them?
[15:00:10] <pJok> but as i said, lack of tools for actually creating them...
[15:00:32] <mru> many 'open file' dialogs fail miserably on certain perfectly valid constructs
[15:00:49] <mru> like creating a non-alphabetic "drive"
[15:00:57] <pJok> well
[15:01:04] <pJok> drive letters under windows is really just a relic
[15:01:12] <pJok> behind the scenes, its block devices like everything else
[15:01:12] <mru> yet they are there
[15:01:26] <pJok> for historic and compatibility reasons, i guess
[15:01:48] <mru> and pretty much any printable ascii character except \ and : are valid drive designators
[15:02:01] * mru has fooled around with subst too much
[15:02:39] <mru> I've seen other instances too where apps try to be clever and validate filenames
[15:02:46] <mru> with much too strict rules
[15:02:57] <TheFluff> 16:00:05 <@mru> how do standard tools and syscalls deal with them? <--- if you use the syscalls, msdn claims they should treat it just like a normal file
[15:17:44] <wbs> always wonderful with bounties on resolving completely bogus bug reports
[15:18:10] <mru> mark it closed/invalid and collect :)
[15:18:14] <wbs> lol
[15:18:43] <av500> so ffmpeg is a flash player now
[15:20:08] <kshishkov> av500: didn't you know that?
[15:20:37] <kshishkov> av500: otherwise why I've tried to add RTMP support as well?
[15:47:18] <uau> libavcodec/audioconvert.c uses AV_SAMPLE_FMT_NB which is defined libavcore
[15:47:42] <uau> that's very likely to break if library majors are changed
[15:50:44] <siretart> uau: I'm working on a patch to merge libavutil and libavcore
[15:50:59] <siretart> that should solve this issue
[15:51:29] <uau> solve? how so? i don't see how that'd be of any help if libavutil and libavcodec are still separate
[15:51:55] <av500> merge != separate
[15:52:00] <av500> no?
[15:52:17] <siretart> I guess I misunderstood the issue uau's pointing out
[15:52:36] <uau> av500: merge *libavutil and libavcore*, *libavutil and libcodec* separate
[15:52:56] <av500> uau: my bad :)
[15:53:00] <mru> merging libavutil and libavcore has no impact on libavcodec
[15:53:17] <mru> both are separate from lavc both before and after
[15:53:22] <lu_zero> and that should happen on the major bump
[15:53:37] <av500> libavcore/samplefmt.h:34:    AV_SAMPLE_FMT_NB           ///< Number of sample formats. DO NOT USE if dynamically linking to libavcore
[15:53:45] <av500> libavcodec/audioconvert.c:99:    ctx->fmt_pair = out_fmt + AV_SAMPLE_FMT_NB*in_fmt;
[15:53:56] <mru> yes, that's a problem
[15:54:05] <av500> so one cannot dynlink codec to util/core
[15:54:19] <lu_zero> btw with siretart we discussed a bit about keep an uniform version
[15:54:21] <mru> it's a problem now, and it will remain after the merge
[15:54:35] <mru> it has nothing to do with the merge
[15:54:44] <av500> mru: yes, I understand that :)
[15:55:24] <av500> lu_zero: and the outcome?
[15:56:46] <uau> btw the reason i noticed that was that i want to support versions without AV_ versions of SAMPLE_FMT_foo in mplayer2 (those AV_ versions were only added 3 months ago)
[15:57:34] <uau> however there doesn't seem to be a particularly nice way to do that - the version that added them only bumped avcore version, so if that gets removed any tests against avcore version would fail (unless there will be a compatibility define for those?)
[15:57:52] <uau> testing some other lib version could work in practice but be kind of ugly
[15:58:09] <uau> i guess the best practical choice is to just use the deprecated SAMPLE_FMT_FOO
[15:59:18] <lu_zero> av500: we went over thinking about grouping changes so the version number won't go up that much
[16:00:05] <lu_zero> (e.g. minor bump at earliest every week grouping all the changes happened during that week)
[16:00:23] <uau> lu_zero: what benefit would that have?
[16:00:29] <av500> lu_zero: so version is lib.year.week :)
[16:00:52] <av500> make it lib.year.month.day :)
[16:00:56] <lu_zero> uau: just reduce the bumps
[16:01:01] <lu_zero> drop lib
[16:01:14] <lu_zero> since the version would be the same for all the libs
[16:01:15] <uau> well what benefit would reducing the bumps of minor version have?
[16:01:20] <av500> lu_zero: thats what I meant
[16:02:04] <lu_zero> uau: for us just having to prepare the abichanges once per week instead of twice per day
[16:02:06] <av500> lu_zero: benefit is that you can use the revlog as calender, weekends are easy to spot :)
[16:02:24] <uau> "prepare the abichanges"?
[16:02:32] <uau> what do you mean by that?
[16:02:40] <lu_zero> uau: the api changes document
[16:02:47] <lu_zero> (and the abi changes as well)
[16:03:15] <lu_zero> it started with the idea of keeping only a single version number across the ffmpeg libraries
[16:03:29] <uau> i don't really see the benefit here...
[16:03:29] <lu_zero> (iirc you were one of the ones proposing it)
[16:04:06] <uau> so you mean that as a way to have a single version?
[16:04:33] <uau> i don't see how delaying the update of the abi changes document would help
[16:04:45] <av500> lu_zero: if we have many changes, it means the project is doing well, why not expose that :)
[16:05:19] <lu_zero> uau: the question that came up is that we already have a quick increase of the version numbers
[16:05:45] <av500> lu_zero: call it "build" :)
[16:05:45] <lu_zero> so just grouping the changes would make the numbers grow slowly
[16:06:03] <uau> lu_zero: yes, but what's the problem with them growing quickly?
[16:06:08] <av500> +1
[16:06:11] <av500> let em grow
[16:07:30] <lu_zero> just slightly more work
[16:12:54] <jannau> most annoying are conflicts in patches both increasing minor
[16:14:58] <av500> increasing minor should be automatic from the commit msg: ".... MINOR_BUMP..." :)
[16:15:06] <lu_zero> jannau: that's why I'd rather have the commits marked with tags and autogenerate it
[16:15:07] <av500> post commit hook does it then :)
[16:15:15] <lu_zero> av500: better using tags
[16:15:19] <lu_zero> but you got the idea
[16:15:23] <av500> :)
[16:16:23] <Loco89> Hey
[16:16:31] <kshishkov> hey what?
[16:16:38] <kierank> hey jude
[16:16:39] <mru> hey ho
[16:16:52] <Loco89> Any Girls from Germany here..?
[16:17:27] <mru> wtf
[16:17:56] <spaam> Loretta: asl?
[16:17:56] <kshishkov> probably he realised how stupid his question was
[16:18:05] <spaam> :(
[16:18:36] <av500> kshishkov: no, it was from iphone and had no multitasking
[16:19:16] <kierankette> :/
[16:19:41] <kshishkov> spaam: should be kieranketteCDGS
[16:20:49] <kierank> spaam: the correct name is kiera
[16:21:00] <kierank> i mean keira
[16:21:11] <spaam> keiraCDGS
[16:21:17] <kshishkov> kierank: nobodyCares^TM
[16:21:27] <spaam> kshishkov: we need avseq..
[16:33:43] <av500> hmm, this mp3 bitstream parser is wierd
[16:34:42] <av500> in a valid mp3 file, it manages to output 3265 bytes of non mp3 frames
[16:43:51] <Orphis> Yay, lots of fate tests are now running on Win 64 :)
[16:44:58] <Orphis> And some aren't still running because of one common problem I guess
[16:52:53] <lu_zero> great
[16:53:24] <av500> Orphis: thanks!!!
[17:41:08] <CIA-38> ffmpeg: Janne Grunau <janne-ffmpeg at jannau.net> master * r440b61691d ffmpeg/libavcodec/ (avcodec.h h264.c):
[17:41:08] <CIA-38> ffmpeg: h264: define FF_PROFILE_H264_HIGH_444 to the correct value
[17:41:08] <CIA-38> ffmpeg: It was removed in fe9a3fb since it had the wrong value. Add profile name
[17:41:08] <CIA-38> ffmpeg: for it.
[17:41:20] <CIA-38> ffmpeg: Janne Grunau <janne-ffmpeg at jannau.net> master * r7ab8758baf ffmpeg/doc/APIchanges: add APIChanges entry for fe9a3fb
[17:50:18] <CIA-38> ffmpeg: Stefan Kost <ensonic at users.sf.net> master * rae2104791f ffmpeg/libavcodec/ (mpeg4videodec.c vc1.c):
[17:50:18] <CIA-38> ffmpeg: logging: downgrade recoverable errors to warnings
[17:50:18] <CIA-38> ffmpeg: In all 3 cases, the decoding continues and thus a warning would be sufficient.
[17:50:18] <CIA-38> ffmpeg: Helps application that catch them with own log handers to handle them
[17:50:18] <CIA-38> ffmpeg: accordingly.
[17:50:18] <CIA-38> ffmpeg: Signed-off-by: Mans Rullgard <mans at mansr.com>
[17:56:42] <lu_zero> mmu: I watched some haiku in action at the fosdem, looks really great =)
[17:56:53] <mmu> cool
[17:56:58] <lu_zero> (and we found other ffmpeg-haiku users!)
[17:57:09] <mmu> really ? :p
[17:57:10] <mru> s/users/user/
[17:57:16] <mmu> LOL
[17:57:29] * mmu throws a Haiku CD over mru
[17:57:48] * mru uses it as a beer coaster
[17:57:53] <mmu> ok do I have enough disk space for FATE...
[17:58:05] <mmu> 1.1G
[17:58:25] <lu_zero> =)
[17:58:42] <mru> you need some working space too
[17:59:05] <mru> I'd set aside 1GB to be on the safe side
[17:59:08] <mmu> yeah, plus it's the disk with all the sources on ...
[17:59:14] <mru> not sure exactly how much is needed
[18:01:44] <Orphis> For those who care : http://orphis.free.fr/fate.out
[18:02:13] <Orphis> It's the output of make fate V=1 on Win64
[18:02:29] * kierank considers the building of networking on mingw magic
[18:02:53] <Orphis> It's not perfect yet, some tests can't be run, but some other run and show interesting results
[18:02:55] <mru> Orphis: that would be easier to read w/o V=1
[18:04:01] <Orphis> Use some grep voodoo then ;)
[18:04:12] <mru> Orphis: for every failed test there is a foo.err file saved somewhere under tests/
[18:04:13] <mmu> need to do some more cleanup I suppose
[18:04:24] <mmu> hmm did I ever touch these elinks sources anyway
[18:04:45] <Orphis> Except the err file doesn't have the command line in it
[18:05:25] <Orphis> I found it easier for me to find the common points between the failing command lines this way
[18:05:53] <mru> just saying in case you hadn't noticed them
[18:06:06] <mru> they occasionally contain useful diagnostics
[18:06:16] <Orphis> I've seen a few yes
[18:07:18] <Orphis> BBB have access to the computer, so he'll be able to make a cleaner output if you want
[18:08:50] <Orphis> I'm going out now, I'll continue to debug this later
[18:49:34] <elenril> anyone can comment on lavf renaming patches please?
[18:58:50] <Compn> hmm, any tips for getting a usable license plate out of this security footage? http://dl.dropbox.com/u/17424360/camera1-20110203173710%5B1%5D.avi
[18:58:57] <Compn> h264 even :P
[18:59:13] <Compn> from 00:25 to 00:40 the car reverses
[18:59:23] <Compn> jams the plate right up to the screen
[18:59:48] <elenril> enhance()
[19:00:47] <Compn> of course, why didnt i think of it
[19:01:18] <Compn> more talking h264 deblocking filter, uspp, etc
[19:02:00] <mru> http://www.youtube.com/watch?v=KUFkb0d1kbU
[19:07:01] <Compn> so gigo then
[19:08:03] <Compn> lol
[19:08:26] <iive> Compn: to me it looks like the plate is in arabic.
[19:09:35] * elenril wonders if the person writing asf specs ever heard of this thing called 'consistency'
[19:10:40] <Compn> iive : well thanks for looking at it :)
[19:11:21] <elenril> how nice of them to first store size in 64 bits, then store the same size - small constant in 32 bits
[19:11:40] <iive> Compn: is that original footage? there seems too much aliasing and flickering, like it have been deinterlaced with tfields.
[19:12:21] <iive> dropping one field.
[19:12:25] <Compn> its from a dvr, the source was unclear how he grabbed it from there
[19:20:05] <iive> Compn: what kind of combinations are there, aka how many symbols, letter, numbers, at what possition.
[19:22:05] <Compn> one sec i'll find ref
[19:22:31] <Compn> http://www.aaroads.com/license_plates/images/wa-337-kyj.jpg
[19:23:25] <Compn> hopefully like that iive
[19:24:33] <iive> my second guess was something like ?CD 26?, but that looks backwards...
[19:26:29] <Compn> my guess was omd 287
[19:26:32] <Compn> ehe
[19:26:48] <Compn> i'll ask the guy if he has a better quality video
[19:26:56] <iive> ??2 -???"
[19:33:43] * Compn goes afk
[19:34:10] <BBB> drv: hah you are on IRC (you're daniel right?) - so will you try to set up a fate box?
[19:50:35] <mmu_man> hmm didn't we have a FATE tutorial ?
[19:50:45] <mmu_man> I recall seeing the insn somewhere
[19:50:54] <mmu_man> on the ml ?
[19:52:40] <mmu_man> ah doc/build_system.txt :))
[19:56:20] <mmu_man> ah that's the one I was seeking http://wiki.multimedia.cx/index.php?title=Running_FATE
[20:07:38] <Kovensky> mmu_man: it needs to be updated for git =p
[20:07:46] <Kovensky> also, several of the variables should be commented out or filled with the defaults
[20:07:55] <Kovensky> if you forget to fill in anything, the build WILL fail
[20:08:29] <mru> already updated for git
[20:09:09] <Kovensky> I see, it wasn't a few days ago :>
[20:12:08] <elenril> does anybody mind if i download all the asf samples at high speed?
[20:12:10] <mmu> mru do I have to set up this config file the wiki talks about ?
[20:12:14] <elenril> KotH: ^
[20:12:21] <mmu> hmm rsync could be more verbose about how much it does
[20:12:34] <mru> rsync --progress is
[20:13:52] <mmu> yeah but I don't care how much it does of each file
[20:14:00] <mmu> just want to know the ETA
[20:14:07] <mmu> oh well
[20:14:09] <mmu> let it run
[20:14:36] <mru> ETA: later
[20:14:45] <mmu> :)
[20:15:07] <kierank> same as the eta for BeOS to become a real os ;)
[20:16:59] <mru> elenril: I think you can go ahead and grab the asf samples if you need them
[20:17:10] <mmu> !kick kierank
[20:17:32] <kierank> ENOTIMPLEMENTED
[20:17:51] <mmu> BeOS was a real OS way before Linux even could play a video
[20:22:04] <thresh> yeah so why bother now
[20:22:18] <mmu> because Haiku is out there
[20:22:37] * thresh sends H1N1 to Haiku
[20:24:50] <mmu> are you sponsored by M$ like FOSDEM thresh ?
[20:26:15] <mmu> ok 403MB for fate data
[20:26:46] <mru> sounds about right
[20:27:43] <mmu> just need to finish the build on this box
[20:28:15] <thresh> mmu: I wish I was!
[20:28:22] <mmu> bleh
[20:28:43] * mmu installs Windows Vista on all thresh's computers
[20:29:12] * Kovensky gives mmu a windows me disc
[20:29:28] <mmu> aw, won't even touch it
[20:29:32] <Kovensky> now, where was that microsoft bob disc...
[20:29:43] <_av500_> thresh: u better now?
[20:31:17] <thresh> _av500_: feeling tired and sleepy for a couple of days, looks like almost ok now
[20:31:55] <thresh> no stupid swine flu could kill vodka drinkers
[20:32:58] <_av500_> right
[20:33:38] <mru> thresh: the swine flu doesn't kill the swine, so you're safe
[20:35:12] <wbs> re dropping libavcore - strictly speaking, it's breaking ABI comparing to earlier svn/git versions, but combined with a major bump would probably be ABI-safe
[20:35:40] <wbs> and that of course depends if ABI compatibility with svn/git versions is desired or ignored
[20:36:28] <vipw> wbs: ever heard of oipf HTTP Adaptive streaming?
[20:36:32] <elenril> well we _are_ claiming that git master is stable
[20:36:35] <mru> we're breaking compatibility with lots of things anyway
[20:36:51] <mru> elenril: git master is stable most of the time
[20:37:13] <elenril> but if it's to be merged, than the bump must be immediately before or after
[20:37:37] <mru> it'll be in close proximity
[20:38:04] <wbs> vipw: hmmm, don't remember all the names, is that microsoft's or adobe's abomination?
[20:38:21] <vipw> it looks a lot like apple's HLS, but with multiple bitrates
[20:38:32] <wbs> apple's HLS supports multiple bitrates, too
[20:38:46] <vipw> i honestly can't tell who is behind it, i see samsung pushing it for on their tvs
[20:38:58] <vipw> http://www.oipf.tv/specifications.html
[20:39:00] <wbs> both microsoft and adobe built similar-looking variants, but based on xml instead of m3u playlists, and on mp4 fragment files instead of mpeg2ts
[20:40:14] <vipw> this is xml playlist and has either mp4 or mpeg2ts
[20:40:30] <wbs> uh, weird, is it yet another variant of the same thing? sigh
[20:40:49] <wbs> looks like some 3gpp spec (some of the xml namespaces point in that direction at least)
[20:44:51] <mmu>     Run the fate test suite, note you must have installed it
[20:45:02] <mmu> ^^ note it doesn't say a word about how to install it
[20:46:17] <mmu> ld: cannot find -lm
[20:46:23] <mmu> bleh
[20:47:06] <mmu> HOSTLIBS=-lm
[20:47:18] <mmu> ^^ where does this crap come from ? there is libm in Haiku
[20:47:23] <mru> configure
[20:47:52] <mru> fix whatever you need in the haiku section of configure
[20:47:55] <mru> send a patch
[20:47:58] <mru> we'll apply
[20:48:29] <mmu_man> hmm it only has -lm by default but what if it gets another stuff, will need to filter it out
[20:48:41] <mmu_man> actually all platforms using it should add it for themselves
[20:48:52] <mru> the majority needs it
[20:48:59] <mru> easier to clear it for those that don't
[20:49:02] <mmu_man> the majority is not always right
[20:49:06] <mmu_man> ask Windows users
[20:49:27] <mru> just add host_libs= to the haiku section and stop complaining
[20:50:14] <mmu_man> why couldn't I do both adding it and still complaining ? :D
[20:51:37] <mmu_man> why does ff* not use host_libs for linking ??
[20:52:22] <mmu_man> or rather, why does configure test for it but it's still hardcoded elsewhere
[20:52:36] <mru> host != target
[20:52:59] <mmu_man> well the test would only work when host == target anyway
[20:53:08] <mru> the test is for the target
[20:53:13] <mru> and uses the target cc
[20:53:17] <mmu_man> hmm right
[20:53:23] <mru> trust me, it works
[20:53:32] <mmu_man> best would be to test for the host one too, but I'm too lazy
[20:53:37] <Dark_Shikari> mru: while you're banning people on the ML, how about we ban the anti-GPL troll from ffmpeg-users?
[20:53:38] <mru> the host settings could use some more detection though
[20:53:53] <mru> Dark_Shikari: I'm not on -users
[20:54:04] <mru> I can still ban trolls of course
[20:54:17] <mru> but I won't notice them
[20:54:43] <Dark_Shikari> This one is a guy who's been around for months posting to every single thread that's remotely legalities-related about how evil the GPL is
[20:54:47] <Dark_Shikari> and how we're out to screw everyone
[20:54:48] <elenril> hah, phil rhodes again?
[20:54:50] <Dark_Shikari> yes
[20:55:06] <Kovensky> hfuy?
[20:55:15] <elenril> yeah
[20:55:21] <Dark_Shikari> phil rhodes yes
[20:55:30] * Kovensky doesn't like the GPL either but doesn't hate on people using it
[20:55:41] <Dark_Shikari> Oh he's anti-LGPL too.
[20:55:48] <Dark_Shikari> In fact I'm pretty sure if ffmpeg went BSD, he'd be anti-BSD.
[20:56:13] <Kovensky> I just hate on people that are fanatic about it like libsamplerate's author which forbid anyone from making a foobar2000 plugin because it'd be a "pluging for an evil non-GPL program and since you're using GPL code foobar2000 would have to be GPLed too"
[20:56:30] <mru> for some people being anti is more important than what they are against
[20:56:40] <Kovensky> in fact a plugin was made but he forced it to be discontinued
[20:57:05] <elenril> Kovensky: well...foobar _is_ an evil non-gpl closed proprietary evil program =p
[20:57:19] <mru> perhaps, but that's irrelevant
[20:58:13] <Dark_Shikari> Let's not flame over this and get the troll banned instead.
[20:58:28] * Kovensky usually licenses his stuff under ISC
[20:59:27] <Kovensky> btw, the code I wrote for x264 has to be in that GPL-proprietary dual-license, right? since it includes x264cli.h which is under that license
[20:59:47] <Dark_Shikari> If you want to get it committed, it does.
[21:00:00] <Dark_Shikari> However, x264 is available under two licenses, so for now it's just GPL.
[21:00:08] <elenril> Kovensky actually writes patches? wow
[21:00:10] * elenril ducks
[21:00:15] <Dark_Shikari> No, he just pretends to.
[21:01:16] <Kovensky> well, it's written, kinda, just needs polish and finishing ._.
[21:01:32] <Kovensky> I need to get someone to review it so I know what to do next and then sit and actually do it
[21:01:38] <Dark_Shikari> "It needs finishing" doesn't sound very promising.
[21:02:03] <Kovensky> "finishing" because I'm also counting the DSP filters as part of it, if you don't count then yes it just needs final touches
[21:02:40] <Dark_Shikari> On an unrelated note, http://whartoniteseekscodemonkey.tumblr.com/
[21:02:55] <KotH> elenril: tell me your ip and use rsync
[21:03:04] <BBB> Dark_Shikari: please review my win64 emu_edge patch
[21:03:07] <elenril> KotH: too late :)
[21:03:55] <bcoudurier> closed = evil
[21:04:17] <bcoudurier> foobar2k = closed, foobar2k = evil
[21:04:24] <elenril> \o/
[21:04:32] <mmu_man> bleh, of course there is no man in Haiku so git fails to display the help
[21:04:33] <mmu_man> stupid
[21:04:59] <Kovensky> no man? lol
[21:04:59] <saintdev> -h will just print usage
[21:05:22] * Kovensky never remembers the -h and uses --usage
[21:05:32] <Kovensky> while not actually a flag to display usage, it works because it's not a valid flag in any command
[21:05:38] * saintdev just uses --help because his OS has man
[21:05:49] * Kovensky doesn't always want to see the full manpage
[21:05:56] <mmu_man> hmm it fails anyway, seems it misses some non portable perl module
[21:06:13] <Kovensky> you mean a perl module that isn't in haiku's default install
[21:06:15] <Kovensky> lrn2cpan
[21:06:54] * mru runs fate on qnx with no git
[21:07:13] <mmu_man> won't work anyway for sending...
[21:07:22] * mmu_man slaps mru 
[21:07:29] <mmu_man> you "only" need to port git :D
[21:08:01] <BBB> Daty
[21:08:01] <mru> I run a separate cron job on a linux machine updating the git tree which the qnx machine then accesses over nfs
[21:08:02] <BBB> oops
[21:08:05] <BBB> tab completion sucks
[21:08:07] <BBB> Dark_Shikari: ty
[21:08:24] <CIA-38> ffmpeg: Reinhard Tartler <siretart at tauware.de> master * r87800dc2bf ffmpeg/doc/ (TODO developer.texi optimization.txt soc.txt):
[21:08:24] <CIA-38> ffmpeg: Documentation updates for the git migration
[21:08:24] <CIA-38> ffmpeg: This cleanup patch updates the developer documentation with respect to
[21:08:24] <CIA-38> ffmpeg: the migration to the git scm.
[21:08:48] <BBB> did astrange say I could push -mt patch 2/6?
[21:08:51] <BBB> he did right?
[21:09:16] <siretart> BBB: do you consider the -mt patch ready for 0.7?
[21:10:01] <mmu_man> sent
[21:11:21] <mmu_man> do I need to use tests/fate.sh or make fate ??
[21:11:58] <mru> fate.sh is for fully automated checkout/test/report
[21:12:09] <mru> make fate just runs the tests
[21:12:12] <mmu_man> looked like
[21:12:18] <BBB> siretart: yes
[21:12:23] <BBB> siretart: it passes make fate
[21:12:29] <BBB> siretart: I don't know what else it should do
[21:12:32] <BBB> look pretty?
[21:12:38] <BBB> speedy code always looks pretty
[21:14:08] <siretart> BBB: I'm only concerned about regressions in the various codecs. but I have no reason to not trust your confidence in it!
[21:14:21] <BBB> it should work
[21:14:23] <BBB> I think it's fine
[21:14:42] <mru> I want it to work, therefor it must work
[21:14:44] <Dark_Shikari> make sure fate is modified to test threading
[21:14:45] <mru> </religion>
[21:15:09] <mru> Dark_Shikari: sure
[21:16:23] <CIA-38> ffmpeg: François Revol <revol at free.fr> master * rf59c4bd625 ffmpeg/configure:
[21:16:23] <CIA-38> ffmpeg: Fix HOSTLIBS on Haiku
[21:16:23] <CIA-38> ffmpeg: Haiku does not have a separate libm, so do not try to link to it.
[21:16:23] <CIA-38> ffmpeg: Signed-off-by: François Revol <revol at free.fr>
[21:16:23] <CIA-38> ffmpeg: Signed-off-by: Mans Rullgard <mans at mansr.com>
[21:17:43] <mru> mmu_man: see how easy it is to simply send a patch and have it applied
[21:19:18] <mmu_man> mru: when the committers don't make it a <religion /> to reject things for no reason :D
[21:19:39] <mru> I've always given a reason for rejecting things
[21:19:50] <mmu_man> s/no /no valid /
[21:20:22] <mmu> TEST    vsynth2-mpeg1b
[21:20:23] <mmu> ...
[21:20:43] <mmu> (how many years does it run ? :p)
[21:20:59] <elenril> mru: naively rewriting ff_guidcmp as a macro breaks thigs like
[21:21:00] <elenril> !ff_guidcmp(g, /* DSATTRIB_CAPTURE_STREAMTIME */ (const ff_asf_guid){0x14,0x56,0x1A,0x0C,0xCD,0x30,0x40,0x4F,0xBC,0xBF,0xD0,0x3E,0x52,0x30,0x62,0x07})
[21:21:13] <elenril> in wtv.x
[21:21:16] <elenril> s/x/c
[21:21:21] <mru> elenril: how so?
[21:21:23] <wbs> Anssi: btw, you did the patches for showing h264 profile info in the normal startup info, right? I love it :-)
[21:21:33] <elenril> clang says libavformat/wtv.c:886:87: error: too many arguments provided to function-like macro invocation
[21:22:54] <mru> mmu: make fate takes about 20s here
[21:23:47] <mmu_man> hmm ?
[21:24:00] <mru> make -j8 fate on i7 cpu
[21:24:02] <mmu_man> I know it's just an AthlonXP but...
[21:24:27] <mru> expect at least 10m there
[21:25:19] * mmu_man multithreads mru and knits a nice pullover with him
[21:26:07] <mmu> anyway, need to eat now, let it run
[21:27:06] <mmu_man> don't we have a fate config template in git ?
[21:27:23] <uau> mru: surrounding braces don't prevent breaking things into separate arguments in a macro like parentheses do
[21:27:54] <mru> uau: I realised that as I hit enter
[21:28:40] <mru> anyhow, the callers could have more () added, or it could be made an inline function
[21:29:24] <elenril> or somebody could eliminate those inline abominations from wtv.c
[21:29:45] <mru> or that
[21:29:47] <elenril> ...later
[21:41:20] <DonDiego> gnite
[21:41:30] <_av500_> elenril: nice asf work
[21:41:40] <_av500_> you even moved my 20 lines :)
[21:41:44] <CIA-38> ffmpeg: Reimar Döffinger <Reimar.Doeffinger at gmx.de> master * r6bd69e6ada ffmpeg/libavformat/oggdec.c: (log message trimmed)
[21:41:44] <CIA-38> ffmpeg: oggdec: Fix incorrect assumption about header/data interleaving
[21:41:44] <CIA-38> ffmpeg: Currently (since the data_offset fix) the ogg demuxer assumes that
[21:41:44] <CIA-38> ffmpeg: after the first non-header packets in any stream no more header packets
[21:41:44] <CIA-38> ffmpeg: will follow.
[21:41:45] <CIA-38> ffmpeg: This is not guaranteed, so change the code back again to wait until it
[21:41:46] <CIA-38> ffmpeg: has finished the headers for all streams before returning from ogg_get_headers.
[21:42:13] <elenril> _av500_: i'm whoring git blame points ;)
[21:42:49] <elenril> now your 20 lines are MINE. bwahahaha
[21:43:20] <jannau> even with --find-copies-harder?
[21:44:22] * elenril casts Greater Silence on jannau 
[21:48:02] <mmu> cross_prefix= ?? how can it test for crossbuilds ?? or does it just test the buidl itself ?
[21:48:16] <mmu> (hmm I suppose one could actually use qemu-user-* though :)
[21:48:30] <mru> ssh
[21:48:53] <mmu> ah, like you cheating with QNX ? :p
[21:49:04] <mru> the qnx is a native build actually
[21:49:22] <mru> but all the arm, mips etc are cross-builds
[21:50:25] <mmu> ok
[21:50:32] <mmu> didn't try with qemu ? :D
[21:50:39] <mmu> ok make fate ran ok
[21:50:43] <mmu> let's try the script
[21:50:50] <mru> qemu is useless for validation purposes
[21:50:56] <mru> much too buggy
[21:52:30] <roxfan> arm has a new thing called ds-5, which has a simulator
[21:52:38] <elenril> mru: http://pastebin.com/bMA7cmeZ like this?
[21:52:48] <Flameeyes> mru: running the gentoo tinderbox through ffmpeg dependencies, finally
[21:55:08] <mmu_man> mru: you can send patches
[21:58:38] <mru> roxfan: your point?
[21:59:10] <michaelni> BBB, mru, i just wanted to make it clear that you guys cant kick me out of every position and then ask me to reconcile. I was trying to find a compromise with you and reconcile but you just without the slightest reason kicked me out of the ML admin position
[21:59:15] <roxfan> well, you could try it instead of qemu i guess
[21:59:28] <petrvlasic> Hello. Probably, I found a bug in ffserver. But I'm not sure if it relates directly ffmpeg or if have to annoy someone else on live555 forum/irc.
[21:59:38] <mru> roxfan: real hardware is still faster and more correct
[21:59:51] <BBB> michaelni: i have no idea what you're talking about, seriously
[21:59:52] <mru> and even if buggy, it's still the real thing
[22:00:07] <michaelni> BBB, iam no longer ffmpeg-devel ML admin i was before
[22:00:19] <BBB> i didn't change anything
[22:00:22] <BBB> i don't even know how to
[22:00:30] <michaelni> BBB ok, so who did it?
[22:00:39] <michaelni> and why?
[22:00:56] * BBB doesn't know
[22:03:19] <mmu> mru you've got my ssh pubkey already ?
[22:03:23] <michaelni> mru? your name is on the ML admin list now and i dont think it was before so who and why did remove me?
[22:04:08] <mru> my name is there because benoit- thought it should be since I was anyone doing most of the moderating
[22:04:12] <mru> anyway
[22:04:34] <michaelni> ok, so why have i been removed?
[22:05:04] <mru> one good reason would be to stop you unblocking gabu
[22:05:29] <michaelni> mru, you might not belive me but i would not have unblocked gabu
[22:05:37] <Dark_Shikari> btw, mru, if you're doing ip range blocks, have you considered whitelisting people who should have access but are in those ranges?
[22:05:41] <Dark_Shikari> e.g. arpi
[22:05:44] <michaelni> i would have unblocked arpi but he wasnt baned
[22:06:01] <Dark_Shikari> This would probably be useful in general, I think we had range blocks beforehand too?
[22:06:01] <bcoudurier> well taking over ml admin is one thing, but not mailing the password to the others is another
[22:06:04] <mru> Dark_Shikari: arpi should not have access
[22:06:10] <Dark_Shikari> he isn't trolling, iirc?
[22:06:12] <mru> he helps gabu bypass the blocks
[22:06:14] <bcoudurier> mru, why didn't you send the new password to the others ?
[22:06:16] <Dark_Shikari> ah.
[22:06:22] <mmu> aw, politics
[22:06:25] * mmu hides away
[22:06:26] <Dark_Shikari> then unfortunately he's shot himself in the foot.
[22:06:29] <Dark_Shikari> sucks, he's a good guy.
[22:06:36] <mru> bcoudurier: I thought mailman did that automatically
[22:06:57] <mru> I've certainly seen it do so in the past
[22:06:59] <mru> maybe it changed
[22:07:38] <mmu>  install: missing file operand
[22:07:38] <mmu>  Try `install --help' for more information.
[22:07:47] <bcoudurier> I didn't receive anything
[22:08:23] <bcoudurier> mailman sending clear text password in mails like this ?
[22:08:27] <bcoudurier> this is fucked up anyway
[22:08:40] <mru> it is
[22:08:51] <j-b> mailman is broken beyond fixable
[22:08:57] <michaelni> so could someone add me back as ML admin? i promise not to unblock gabu which i wouldnt have done anyway
[22:09:04] <mru> j-b: got better alternative?
[22:09:18] <kierank> ffmailman
[22:09:20] <j-b> mru: tried ecartis... It was actually worse, with no web interface...
[22:09:36] <j-b> mru: Google groups is not compatible with my idea of free software
[22:11:43] <mru> google groups is plain annoying regardless
[22:15:43] <Kovensky> yahoo groups then!
[22:15:44] * Kovensky runs
[22:22:05] <mru> siretart: ping
[22:26:46] <mmu> mru ssh key ?
[22:27:16] <mru> mmu: I don't think I have yours
[22:27:36] <mru> and for fate you should probably not be using your regular ssh key
[22:28:08] <mmu> well the one I sent for svn (eh) was already generated for it with mmu_man at ffmpeg as comment
[22:28:51] <mru> for svn?
[22:29:44] <siretart> mru: yes? (but I'm almost away for today)
[22:29:46] <mmu> before the <politics><strike unwanted options>schisma|split|coup</strike></politics>
[22:30:06] <mmu> for commit access
[22:30:14] <jannau> mmu: you mean for git at videolan
[22:30:30] <mru> siretart: in your libavcore merge patch, why do you mess with libavutil/internal.h?
[22:30:36] <mru> there should be no need for that
[22:32:33] <siretart> mru: I'll check that tomorrow. I think it was necessary for ff_set_systematic_pal2, which I moved to imgutil.h on your request
[22:32:47] <mmu> jannau yeah that one
[22:32:55] <mru> mmu: I don't have access to that
[22:33:09] <mru> siretart: so #include <libavutil/imgutil.h> where needed
[22:33:12] <mmu_man> dcc ?
[22:33:19] <mru> email please
[22:33:22] <mmu_man> ok
[22:34:06] <mmu_man> actually http://thread.gmane.org/gmane.comp.video.ffmpeg.devel/122142/focus=123805
[22:34:12] <siretart> mru: ok. I'll check that
[22:34:42] <mmu_man> it's attached there mru
[22:35:30] <mru> mmu_man: added
[22:38:27] <siretart> mru: you're right, the change to libavutil/internal.h is not necessary and can be dropped without further changes
[22:39:22] <mru> siretart: also, you should never #include internal.h from another lib
[22:42:59] <siretart> ok, I'll check/fix that tomorrow
[22:44:26] <mmu_man> I suppose I have to use fate_recv="ssh mmu_man at ..."
[22:44:36] <mru> no
[22:45:02] <mru> "ssh -i /the/private/key fate at fate.ffmpeg.org" should do it
[22:45:09] <mru> run it from a shell first
[22:45:29] <mru> you'll probably need to accept the host key once
[22:47:09] <mmu_man> yep
[22:51:06] <Dark_Shikari> https://www.bids.tswg.gov/TSWG/bids.nsf/0/9FEB7174D58D16B085257817004BA951/$FILE/11-Q-3830_BAA_02+February+2011.pdf
[22:51:09] <Dark_Shikari> check the top of page 42.
[22:52:08] <mru> Dark_Shikari: :)
[22:54:14] <_av500_> mil grade ftw
[22:56:32] <Flameeyes> okay do I have a 32-bit vm to try verify-lfs over ffmpeg? hm? :|
[23:10:29] <uau> does having libavcore merged in libavutil somehow make it harder to use for other projects?
[23:11:24] <uau> people seem to implicitly assume that it having it in one lib would prevent use outside ffmpeg, and only argue about whether such use could occur at all in any library configuration
[23:12:20] <uau> but would having the extra stuff in the same lib actually cause any significant problems?
[23:12:47] <_av500_> not for me
[23:13:00] <_av500_> gn
[23:13:04] <kierank> bye
[23:25:45] <CIA-38> ffmpeg: Anssi Hannula <anssi.hannula at iki.fi> master * raad216fd7e ffmpeg/libavformat/ (internal.h utils.c):
[23:25:45] <CIA-38> ffmpeg: lavf: simplify pb parameter of ff_probe_input_buffer
[23:25:45] <CIA-38> ffmpeg: There is no need to pass the ByteIOContext via a pointer to a pointer
[23:25:45] <CIA-38> ffmpeg: anymore.
[23:25:45] <CIA-38> ffmpeg: Signed-off-by: Ronald S. Bultje <rsbultje at gmail.com>
[23:25:56] <CIA-38> ffmpeg: Anssi Hannula <anssi.hannula at iki.fi> master * r4d016dd4e5 ffmpeg/libavformat/internal.h:
[23:25:56] <CIA-38> ffmpeg: lavf: update ff_probe_input_buffer documentation
[23:25:56] <CIA-38> ffmpeg: It never reopens the bytestream anymore.
[23:25:56] <CIA-38> ffmpeg: Signed-off-by: Ronald S. Bultje <rsbultje at gmail.com>
[23:25:58] <CIA-38> ffmpeg: Anssi Hannula <anssi.hannula at iki.fi> master * r3940caad02 ffmpeg/ (5 files in 2 dirs):
[23:25:58] <CIA-38> ffmpeg: lavf: rename ff_probe_input_buffer to make it public
[23:25:58] <CIA-38> ffmpeg: It is useful for applications that hand input data directly to lavf via
[23:25:58] <CIA-38> ffmpeg: a ByteIOContext.
[23:25:59] <CIA-38> ffmpeg: Signed-off-by: Ronald S. Bultje <rsbultje at gmail.com>
[23:26:02] <CIA-38> ffmpeg: Ronald S. Bultje <rsbultje at gmail.com> master * r17cf7c68ed ffmpeg/libavcodec/x86/dsputil_yasm.asm:
[23:26:02] <CIA-38> ffmpeg: Fix ff_emu_edge_core_sse() on Win64.
[23:26:02] <CIA-38> ffmpeg: Fix emu_edge_v_extend_15 to be <128 bytes on Win64, by being more strict
[23:26:41] <CIA-38> ffmpeg: on the size of registers and which registers are being used for operations
[23:26:41] <CIA-38> ffmpeg: where multiple are available. This fixes segfaults in emulated_edge()
[23:26:41] <CIA-38> ffmpeg: function calls on Win64.
[23:38:20] <Flameeyes> does somebody have an x86 FFmpeg build directory at hand?
[23:40:08] <jannau> x86_64
[23:40:21] <Flameeyes> nope, that I have as well :)
[23:40:28] * Flameeyes needs to try his verify-lfs script with improvements
[23:40:32] <Flameeyes> I guess I should start up a 32-bit vm