[FFmpeg-devel-irc] IRC log for 2010-02-02

[irc at mansr.com]

[00:02:22] <iive> is this sws thing?
[00:03:40] <ramiro> yes
[00:03:42] <Yuvi> gcc sign-extends signed 32-bit array indexes on x86-64
[00:03:55] <Dark_Shikari> oh, this is why there's so much movsxd shit
[00:05:30] <iive> ramiro: i think michael says in the text " you are having gain, when not only index is in native size, but also the variables that are used to calculate it"
[00:05:40] <iive> does this make more sense?
[00:05:58] <ramiro> hmmm, not for me.
[00:06:05] <Dark_Shikari> which thread is this in?
[00:06:23] <ramiro> Dark_Shikari: [PATCH] Fix function parameters for rgb48 to YV12 functions.
[00:06:41] <aclarke_> question: should we clean up any per-codec options on close, or create a special avcodec_context_free(...) method?
[00:06:42] <iive> well, i guess you have something like table[index]
[00:06:51] <iive> and there is something like index=a*b+c
[00:07:16] <iive> now, on 64 bit cpu it would be better to have int64_t index,
[00:07:36] <iive> but you'd get some (small) speedup gain if you also have int64_t a,b,c;
[00:07:45] <mru> not all 64-bit cpus
[00:07:49] <mru> x86 perhaps
[00:08:04] <Dark_Shikari> "have I mentioned that I hate x86"
[00:08:05] <Dark_Shikari> "yes"
[00:08:05] <iive> it's not my claim :|
[00:08:13] <mru> mips64 and ppc64 are often run with 32-bit pointers
[00:09:12] <ramiro> iive: and what we (mru and I) is to remove this x86-specific hack in the function declarations.
[00:09:38] <iive> what is this hack like?
[00:09:38] <ramiro> long has been misused because it meant 64-bit on 64-bit unix, but it's 32-bit in mingw-w64
[00:09:53] <ramiro> the function declaration is someFunc(long width, whatever...)
[00:10:05] <ramiro> while it makes sense that width is int
[00:10:07] <mru> maybe intptr_t is what you really want
[00:10:38] <iive> well, isn't intptr supposed to be 1 bit (sign) bigger than ptr?
[00:10:49] <mru> lol no
[00:11:14] <mru> intptr_t is an integer type such that casting a pointer to it and back gives the same pointer
[00:11:51] <iive> then this must be what you want to use.
[00:12:03] <ramiro> it still looks ugly in the function definition.
[00:12:17] <iive> hum... it sound so good that i may do #define int intptr_t
[00:15:03] <ramiro> oh, this chat is now publicly logged? where?
[00:15:34] <mru> ramiro: http://lists.mplayerhq.hu/pipermail/ffmpeg-devel-irc/
[00:22:23] <Compn> i guess you could put it in the topic
[00:22:26] <Compn> so lazy
[00:24:08] <aclarke> convention question: what's the right method naming: avcodec_context_free, avcodec_free_context, avcodec_destroy_context or avcodec_destruct_context
[00:24:15] <aclarke> i see all conventions in use for different structures
[00:24:17] <ramiro> mru: but is there a relation to what a pointer size is and what the register size is?
[00:24:25] <mru> not really
[00:24:31] <ramiro> so intptr_t seem wrong...
[00:24:32] <mru> pointer <= register
[00:25:30] <ramiro> aclarke: stefano tried cleaning that up some time ago but it didn't go very far.
[00:25:31] <mru> 64-bit systems with 32-bit pointers generally have automatic sign/zero-extension
[00:26:39] <aclarke> ramiro: yeah, i'm not talking about cleaning up; I need to introduce a new free method for AVCodecContext though and am trying to figure out right convention
[00:26:59] <ramiro> aclarke: it's probably up to what michael finds best. I personally prefer avcodec_free_context(), because of avcodec_alloc_context().
[00:27:07] <Dark_Shikari> mru: what's the point of such a system?
[00:27:15] <aclarke> i'll start with that and wait for the revisions on the list
[00:27:17] <Dark_Shikari> 64-bit math is not very useful
[00:27:49] <aclarke> of course, I could do avcodecContextFreeMemoryFromUseInOrderToMakeItAvailableForOtherAreas(AVCodecContext* thingYouWantToFreeButAreAfraidToDoYourself);
[00:28:05] <aclarke> just to get diego's comment
[00:28:08] <mru> Dark_Shikari: 4G address space per process is usually enough
[00:28:10] <peloverde> aclarke, you've been doing java too long :)
[00:28:21] <mru> and 64-bit maths is useful
[00:28:21] <Dark_Shikari> mru: but you don't need a 64-bit CPU for that
[00:28:27] <ramiro> aclarke: and the doxy would be /** avcodec_free_context() */ ?
[00:28:33] <Dark_Shikari> PAE on x86 for example
[00:28:35] * mru points at mpegaudiodec.c
[00:28:52] <Dark_Shikari> 32x32 -> upper 32 is not 64-bit math
[00:28:55] <aclarke> @peloverde tell me about it.
[00:29:11] <mru> mpegaudio does more 64-bit than that
[00:29:17] <Dark_Shikari> like what?
[00:29:18] <mru> maybe it doesn't need to
[00:29:21] <Dark_Shikari> Probably
[00:29:24] <mru> but it's full of 64-bit stuff
[00:29:26] <mru> flac too
[00:30:00] <mru> also, 64-bit mips and ppc can easily run some processes with 32-bit pointers and others with 64-bit if you choose
[00:30:17] <mru> suppose you have that one app that really eats memory
[00:30:22] <mru> gcc...
[00:30:56] <Dark_Shikari> gcc hardly needs that much
[00:30:58] <peloverde> ld eats far more memory than gcc in my experience
[00:31:04] <Dark_Shikari> you could probably compile all of ffmpeg as a single c file
[00:31:09] <Dark_Shikari> without exceeding 32bit address space
[00:31:18] <mru> it was a joke
[00:31:24] <mru> take matlab or something then
[00:31:30] <peloverde> I can build chromium in parallel but have to link it serially if I don't want to swap like crazy
[00:31:43] <mru> or any large simulation software
[00:31:51] <Yuvi> gcc easily eats up 2GB of ram compiling single C++ files
[00:32:32] <Dark_Shikari> yes but that's C++
[00:32:41] <mru> still gcc
[00:32:45] <Dark_Shikari> no, g++
[00:32:51] <Dark_Shikari> yes yes yes gnu compiler collection
[00:32:51] <mru> same thing
[00:32:52] <peloverde> I haven't run into that problem and I only have 2GB ram
[00:32:52] <Dark_Shikari> fuck that shit
[00:33:06] <mru> the only difference between gcc and g++ is the default linker flags
[00:33:45] <peloverde> int *foo = malloc(sizeof(int));
[00:33:51] <Yuvi> peloverde: it might limit itself to 1/2 of your total ram, at least 2GB is the max I've seen even when I encountered a bug where gcc ran out of memory compiling 400 lines of altivec
[00:34:29] <Yuvi> and I have 4gb
[00:34:34] <Dark_Shikari> Yuvi: that's standard on windows
[00:34:37] <Dark_Shikari> dunno what linux does
[00:35:05] <Yuvi> OS X and linux both only reserve 1gb of the space per app for the kernel I think
[00:35:33] <mru> depends on configuration
[00:35:42] <mru> 3+1 is the default on x86
[00:35:48] <mru> you can run 2+2 or 4+4 too
[00:36:00] <mru> 4+4 doing a full switch
[00:36:02] <mru> not recommended
[01:02:59] <mru> I have a gcc process using 300MB here right now
[01:03:14] <mru> building something in ffmpeg
[01:07:49] <Dark_Shikari> is it linking?
[01:10:36] <mru> no, that was cc1
[02:20:39] <ramiro> mru: on http://fate.multimedia.cx/index.php?build_record=174000 , --target-exec=/misc/fate/redpole/run--prefix=/misc/fate. There's no space between run and --prefix, is that a bug in the FATE page or in your config?
[02:20:54] <mru> bug in my config
[02:20:55] <mru> fixed
[02:21:10] <mru> just taking forever to run the next iteration
[02:22:04] <ramiro> well, it's blackfin...
[02:22:40] <mru> the stupid thing is I have to reboot it between each test
[02:22:54] <mru> and it takes 10-15 seconds to boot
[02:23:57] <mru> now I'm curious why that svq3 test printing junk suddenly decided to bite all configs
[02:24:58] <ramiro> why do you have to reboot it?
[02:25:22] <mru> otherwise the memory fragments too much
[02:25:38] <mru> and kills the network
[02:26:11] <mru> that was after I already moved ffmpeg's bss and heap to dedicated areas
[02:33:07] <mru> maybe I can reduce the reboot frequency a bit
[02:36:20] <ramiro> if I change long (or x86_reg) in the declaration to int and make an "x86_reg width = dstWidth;", nothing changes in relation to how gcc indexes the arrays in the loop.
[02:36:47] <ramiro> it only changes one mov from int to x86_reg, either in the caller or the callee...
[02:37:02] <ramiro> it doesn't help in any swscale function I've tested so far.
[02:37:42] <ramiro> not even the C code, nor the mmx2, nor the x86, or mmx...
[02:39:28] <Dark_Shikari> hmm, I need to calculate a rough closed form for this expression
[02:39:29] <Dark_Shikari> X(n) = (X(n-1) + I) * R
[02:39:29] <Dark_Shikari> where 0 < R < 1
[02:39:35] <Dark_Shikari> I'm looking for X(inf)
[02:40:07] <mru> and I is what?
[02:40:11] <Dark_Shikari> Some value.
[02:40:13] <Dark_Shikari> Positive.
[02:40:21] <Dark_Shikari> (intra SATD, but that's not important)
[02:40:30] <mru> X(0)?
[02:40:35] <Dark_Shikari> Not actually important.
[02:40:42] <Dark_Shikari> No matter what it is, it will converge to the same value.
[02:41:15] <Dark_Shikari> also, it might be useful to get an approximation for X(largenum), like X(50)
[02:41:24] <mru> not if I==inf or X(0)==inf
[02:41:28] <Dark_Shikari> well yes
[02:41:33] <Dark_Shikari> X(0) = Some Finite Number
[02:41:54] <mru> then it converges
[02:41:59] <mru> intuitively at least
[02:42:17] <Dark_Shikari> Yeah, but I need to figure out what it converges to
[02:42:34] <pengvado> dimensional analysis says I/(1-R)
[02:42:44] <mru> sounds plausible
[02:42:52] <Dark_Shikari> wait, how the hell do you use dimensional analysis there?
[02:43:32] <pengvado> * linear in I
[02:43:32] <pengvado> * blows up when R->1
[02:43:33] <pengvado> * =I when R=0
[02:44:03] <pengvado> oops, skipped a factor
[02:44:18] <Dark_Shikari> oh you mean X(n-1)+I = I/(1-R)
[02:44:23] <Dark_Shikari> right?
[02:46:08] <Dark_Shikari> in that case:
[02:46:09] <Dark_Shikari> 0.100000: 111.111111
[02:46:09] <Dark_Shikari> 0.200000: 125.000000
[02:46:10] <Dark_Shikari> 0.300000: 142.857143
[02:46:10] <Dark_Shikari> 0.400000: 166.666667
[02:46:12] <Dark_Shikari> 0.500000: 200.000000
[02:46:14] <Dark_Shikari> 0.600000: 250.000000
[02:46:17] <Dark_Shikari> 0.700000: 333.333333
[02:46:19] <Dark_Shikari> 0.800000: 500.000000
[02:46:22] <Dark_Shikari> 0.900000: 1000.000000
[02:46:24] <Dark_Shikari> Dimensional analysis is correct.
[02:49:15] <pengvado> I*R/(1-R)
[02:49:28] <Dark_Shikari> Yeah
[02:49:40] <Dark_Shikari> I'm trying to make a lookaheadless approximation of MB-tree
[02:49:57] <Dark_Shikari> i.e. "assume frame N+1 is to N as frame N is to frame N-1"
[02:50:09] <Dark_Shikari> and ignore motion vectors
[02:50:33] <Dark_Shikari> or, well, consider them, but don't extrapolate
[02:51:54] <Dark_Shikari> mru: -O11, awesome
[02:59:13] <Dark_Shikari> ok, magic formula derived: ( N + (I - N) ) / N, where N = inter cost, I = intra cost
[02:59:23] <Dark_Shikari> that approximates an infinite-frame MB-tree lookahead
[03:00:08] <pengvado> N+I-N ...
[03:00:20] <Dark_Shikari> er, yeah
[03:00:36] <Dark_Shikari> .... that simplifies to I / N?
[03:00:39] <Dark_Shikari> .....
[03:00:41] <Dark_Shikari> That's it?
[03:00:52] <Dark_Shikari> qscale /= (I/N)
[03:01:04] <Dark_Shikari> I guess that means mbtree's algorithm is actually more rigorously sensible now
[03:01:09] <Dark_Shikari> because it converges to something that simple
[03:10:38] <Dark_Shikari> hmm, the problem that comes up is "what to do in I-frames?"
[04:23:30] <peloverde> Do we really not have a plain vector_add for floats?
[04:24:39] <Compn> whats this demi thing ?
[05:03:17] <peloverde> Why are ff_cos_tabs always positive?
[06:21:36] <siretart> morning
[06:23:17] <jai> morning
[06:30:50] <kshishkov> as you say
[06:59:27] <benoit-> good morning
[06:59:38] <kshishkov> not here
[06:59:52] <benoit-> kshishkov: not good ? or not morning ?
[07:00:05] <kshishkov> not good at all
[07:00:29] <benoit-> what's happening to you ?
[07:00:50] <kshishkov> yesterday I tried to go outside
[07:01:02] <kshishkov> today the weather seems to be the same
[07:01:12] <thresh> moroning
[07:47:54] <KotH> grüezi
[07:50:54] <kshishkov> whatever!
[07:52:27] <pJok> god morgon, kshishkov
[07:52:27] <pJok> :)
[07:52:38] <kshishkov> god morgon
[07:54:06] <astrange> rm doc/ffserver.pod ffmpeg.o doc/ffmpeg.pod doc/ffplay.pod ffserver.o <- why does the last step of make delete ffmpeg.o...
[07:54:13] <superdump> morning
[07:54:32] <kshishkov> morrow
[07:54:53] <kshishkov> astrange: interrogate mru
[07:57:46] <astrange> seems like it's a make "feature"
[08:04:13] <KotH> juup
[08:04:27] <KotH> make deletes "temporary" files after building
[08:04:36] <kshishkov> KotH: wanna fix it?
[08:04:52] <KotH> no, i have to go out and buy chocolate :)
[08:07:03] <jai> living up to the swiss stereotype :)
[08:07:22] * superdump wants chocolate
[08:07:27] <kshishkov> jai: made abroad too
[08:07:33] <KotH> jai: lol
[08:07:40] <KotH> jai: no, i have an order for fosdem :)
[08:07:49] <jai> KotH: oh, nice
[08:08:10] <KotH> jai: if you make it to fosdem, you can have some too ;-)
[08:08:54] <jai> KotH: sure, someday before the swines go airborne
[08:09:04] <kshishkov> superdump: I can tell you the address in Kharkov where you can buy chocolate and not the stuff mistakenly called so
[08:09:04] <jai> KotH: thanks though ;)
[08:09:28] <KotH> jai: linuxtag?
[08:09:29] <superdump> probably a little too far for a brief morning stroll before work
[08:09:41] <KotH> jai: ffmeeting?
[08:09:48] <kshishkov> superdump: where are you?
[08:09:59] <superdump> kshishkov: stockholm
[08:10:13] <kshishkov> superdump: and where is your work?
[08:10:21] <jai> KotH: i would love to come over for a meet, but the cost will kill me, not to mention getting a visa is probably tough :|
[08:10:24] <superdump> right where i'm sitting
[08:10:41] <kshishkov> superdump: and where is that more specifically?
[08:10:42] <KotH> jai: it cannot be as bad as with kshishkov
[08:10:46] <superdump> (and that applies wherever i am as long as i have an internet connection and a phone with me)
[08:10:56] <KotH> jai: at least we've a lot of guys from india here
[08:11:02] <KotH> actually.. too many ;)
[08:11:06] <jai> KotH: well atleast kshishkov is in the vicinity of europe ;)
[08:11:22] <superdump> kshishkov: in an apartment in enskede
[08:11:33] <kshishkov> jai: yep but if you are student, it's easier to you to get visa anyway
[08:12:13] <kshishkov> superdump: ok, just the closest shop would do then :P
[08:12:42] <jai> kshishkov: hmm, i heard that elsewhere too ...
[08:12:53] <superdump> there's a kiosk just outside
[08:12:59] <superdump> but i think the best they have is marabou
[08:13:08] <kshishkov> quite good for me
[08:41:30] <Yuvi> ugh, in theora an uncoded block cannot have a mv
[08:41:30] <Yuvi> even if the rest of the mb has a mv
[08:42:18] <Dark_Shikari> yup
[08:42:46] <Yuvi> that makes per-mb mc harder than it needs to be...
[08:42:54] <Dark_Shikari> it's even worse on the encoder-side
[08:42:55] <kshishkov> did somebody imply Theora was sane?
[08:43:06] <Dark_Shikari> Actually, here's a good way to work around that:
[08:43:13] <Dark_Shikari> if you have a whole MB that isn't coded but needs an MV
[08:43:22] <Yuvi> and if the mb is using the golden ref, uncoded blocks still use the last ref
[08:43:25] <Dark_Shikari> set the quantizer extremely low, and code one +1 dc coeff for each block
[08:43:45] <Dark_Shikari> since at very low quants,+1 dc rounds to nothing
[08:43:56] <Dark_Shikari> (would require dedicating one of the 3 global frame quants to this)
[08:44:36] <Yuvi> probably a better use of the quants than trying to do proper AQ
[08:44:44] <Dark_Shikari> well, they just implemented adaptive lambda in trunk
[08:44:52] <Dark_Shikari> I wonder if they've changed the quantizer selection to match it
[08:45:10] <Dark_Shikari> since adaptive lambda without adaptive quant is not as good
[09:28:11] <kshishkov> cobber!
[09:28:27] <pross-au> Hey, was gonna ask. Wheres the bink video decoder at
[09:28:50] <pross-au> (i added it to the wiki list of interesting patches, because *i* found it interesting)
[09:29:13] <superdump> :)
[09:29:32] <pross-au> hi rob
[09:30:02] <superdump> yo
[09:31:28] <kshishkov> pross-au: at FFmpeg-devel ML in a few mins
[09:32:03] <pross-au> Great
[09:34:11] <kshishkov> http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/2010-February/082665.html
[09:39:10] <pross-au> Did you get further with those bad block that would appear in some videos?
[09:39:24] <kshishkov> no
[09:40:02] <pross-au> ill have a play with it this weekend
[09:40:11] <kshishkov> fine
[09:40:35] * jai should send a patch too
[09:40:55] <kshishkov> patch for what?
[09:41:13] <jai> kshishkov: alac 24 bit
[09:41:19] <jai> never got around to posting
[09:41:29] <kshishkov> ah
[09:41:36] * kshishkov has some patches rotting too
[09:44:50] <jai> same here
[09:45:03] <jai> i'll start looking over my tree in a bit
[09:45:06] <kshishkov> too many codecs to RE as well
[09:45:17] <jai> let the kids do it in gsoc ;)
[09:45:21] <av500> VP8 ftw!
[09:45:53] <jai> i assume vp8 binaries are now available>
[09:45:56] <pross-au> too many! pftt, there will come a day when ya'll are begging for new stuff to r.e.
[09:45:58] <jai> s/>/?
[09:46:25] <kshishkov> pross-au: sometimes I do. You still have 1.5 EA codecs left to RE
[09:46:37] <av500> jai: no idea?
[09:47:15] <pross-au> i like low hanging fruit
[09:47:39] <pross-au> speex is pretty low, btw
[09:47:51] <kshishkov> leave it to gsoc kids
[09:48:21] * kshishkov feels a bit old even he is not even 26
[09:48:26] <kshishkov> bbl
[09:51:11] <astrange> vp8 isn't out
[09:51:23] <astrange> there are some things using vp7 though
[09:51:39] <Dark_Shikari> lol vp8
[09:51:43] <Dark_Shikari> they supposedly have an sdk
[09:53:40] <Yuvi> supposedly they gave it to google in 2008 but they never used it beyond the evaluation
[09:56:09] <av500> supposedly that is why gg bought them, no? :)
[09:56:21] <astrange> http://github.com/astrange/ffmpeg/commit/337aca4b3b1b6554f3024ff22ec760a413bc39f5 23.8->23.38s on losslesstouhou, i'll send it tomorrow
[09:56:38] <av500> gg saw the codec and decided that the only way to make sure nobody ever uses was to buy (and bury) ON2
[09:56:56] <twnqx> lol
[09:57:19] <astrange> we can always hope they want to release it as theora II and they ask ffmpeg-devel for comments first
[09:57:27] <av500> pity they did not buy them for vp3...
[09:58:03] <merbzt> astrange: do you know how much faster the H264 decoder has gotten in the last 2 months ?
[09:59:23] <astrange> between 1 and 15% depending on interlaced or not and x86 or not
[10:01:05] <astrange> try: for n in 1 2 3 4 5; do for f in ffmpeg-0.5 ffmpeg-now; do echo $f; time $f -i something.mp4 -an -f framecrc -vsync 0 -y crc`basename $f` >/dev/null 2>&1; done; done;md5 crc*
[10:01:39] <astrange> i don't keep old binaries around, personally i don't try to measure how much better it is as long as it is better
[10:10:52] <astrange> http://github.com/astrange/ffmpeg/blob/master/libavcodec/h264.h#L861 profiling hotspot here, should be easy to skip if 1 frame = 1 slice
[11:47:45] <kierank> What does LoRo stand for?
[11:48:14] <av500> low robustness?
[11:48:32] <kierank> nm found it. It's Left only, right only
[12:06:23] <siretart`> does stefano irc?
[12:07:08] <mru> siretart`: saste
[12:07:15] <siretart`> thanks
[12:08:12] <siretart`> mru: I wonder what to do in 0.5 about vhook and symbol versioning. what do you think about disabling versioning if vhook is enabled?
[12:09:05] <mru> siretart`: do the packages have vhook enabled?
[12:09:35] <siretart`> mru: 'my' packages don't
[12:10:03] <mru> it shouldn't be hard to fix it
[12:10:33] <siretart`> fix in the sense of "enable both vhook and symbol versioning"?
[12:10:58] <mru> yes
[12:36:46] <ohsix> anyone use oprofile much with the cache counters?
[12:39:29] <mattg> does anyone know why with libavcodec h264 decoding, even with error_concealment = FF_EC_GUESS_MVS | FF_EC_DEBLOCK i'm getting completely green frames after getting "number of reference frames exceeds max" error?
[12:40:00] <kshishkov> completely green frame = completely not decoded, I think
[12:41:41] <mattg> well there's a completely green frame and then the next frame is green but with bits of what looks like the correct frame. i guess that it's using the green frame as a reference frame?
[12:42:40] <kshishkov> could be reference frame lost -> green
[12:42:49] <kshishkov> it's exceeding max anyway
[12:46:05] <mattg> playing the same stream through ffplay doesn't give the greenness, so i'm assuming that i'm not setting some error concealment values somewhere - but can't seem to find where
[12:47:14] <av500> mattg: could it be that ffplay just plays it correctly?
[12:47:35] <av500> or do you get the same error msg?
[12:47:46] <mattg> ffplay also indicates that it's concealing errors, so yes same error msg
[12:51:23] <mattg> just it seems to do it right, whereas through libavcodec it's just not working
[12:52:01] <av500> could it be that it drops frames that are not decoded OK?
[12:53:00] <ShadowJK> the last nokia ad I remember is the one for 8800 or something... the one Neo uses in Matrix 1.. and in that ad it was hidden behind a banana
[12:53:05] <ShadowJK> uh
[12:53:09] <ShadowJK> wrong chasnnell
[12:53:20] <kshishkov> very wrong indeed
[12:53:23] <pross-au> still funny
[13:05:58] <mattg> av500: not sure what you mean :-S. ffplay plays it fine, but my app through libavcodec doesn't. presumably it's a setting but i can't figure out which one
[13:09:13] <superdump> if it works in ffplay but not in your code using libav* then i think your question is a user question
[13:10:38] <mattg> ah huge apologies yes wrong channel indeed
[16:02:10] <CIA-17> ffmpeg: michael * r21603 /trunk/ffplay.c: Fix seek flags
[16:23:15] <mru> we have fosdem t-shirts
[16:23:49] <kshishkov> for very limited number of "we"
[16:24:20] <mru> those coming to fosdem of course
[16:24:46] <mru> we'll have to organise something in sweden some time
[16:24:51] <mru> so you can join
[16:25:02] <kshishkov> now it's the same thing
[16:25:19] <mru> what is?
[16:25:30] <kshishkov> next to impossible to get visa
[16:25:42] <mru> sweden too?
[16:25:47] <mru> how'd you get it before?
[16:25:55] <kshishkov> I was a student
[16:25:55] <elenril> even for a RE guru?
[16:26:31] <kshishkov> elenril: most RE gurus live in Europe or USA so no troubles for them
[16:27:18] <kshishkov> so unless I can somehow get employed abroad, I won't be able to go there
[16:27:39] <thresh> seriously, get a travel visa already
[16:27:58] <thresh> book a hotel and then decline the booking after you got visa
[16:28:00] <thresh> etc
[16:29:08] <kshishkov> thresh: the trickiest part is to prove I won't stay in Europe after I get visa
[16:37:42] <BBB> kshishkov, :(
[16:38:26] <kshishkov> do you think I posted that "looking for a job" only because of sheer will to work?
[16:40:09] <thresh> kshishkov: the plain tickets are enough.
[16:40:23] <thresh> i'm not a student as well...
[16:40:58] <kshishkov> thresh: really? what about references from work?
[16:42:15] <thresh> a simple 'this guy works here' with signs by some CTO is enough
[16:42:25] <thresh> you don't even have to provide the real salary
[16:42:37] <kshishkov> I don't have even that to provide
[16:42:44] <thresh> do you have a job?
[16:42:50] <kshishkov> no
[16:43:00] <kshishkov> I'm selfunemployed
[16:43:04] <mru> lol
[16:43:21] <thresh> well, it lowers your chances to get a visa, but still
[16:43:45] <kshishkov> the fact I don't have friends to fake one for me lowers it even more
[16:43:47] <thresh> what will probably ruin it is if you were to prison :)
[16:45:04] <kshishkov> thresh: actually I am. The fact it's called "Ukraine" does not change much...
[16:46:00] <thresh> :)
[16:48:40] <CIA-17> ffmpeg: michael * r21604 /trunk/ (libavformat/mpeg.c tests/seek.regression.ref): Set AVPacket.pos in MPEG-PS demuxer.
[16:51:49] <CIA-17> ffmpeg: michael * r21605 /trunk/ffplay.c:
[16:51:49] <CIA-17> ffmpeg: Use currently displayed file position instead of just url_ftell() for seeking by bytes.
[16:51:49] <CIA-17> ffmpeg: This fixes seeking back with the cursor keys and -bytes.
[17:23:03] <BBB> is 1 << 32 0 or undefined?
[17:24:20] <mru> undefined
[17:24:53] <DonDiego> has anybody played around with gnash?
[17:26:16] <kshishkov> what's that?
[17:26:21] <iive> i tried it 1 or 2 years ago
[17:26:21] <kshishkov> Flash Player?
[17:26:32] <BBB> gnu flash right?
[17:26:37] <iive> the ffmpeg plugin didn't produce anything but black picture.
[17:26:39] <BBB> like a free flash player
[17:26:55] <iive> GNuflASH
[17:27:54] <iive> I even reported some issues related to gnash and boost...
[17:27:59] <jai> lol gnash
[17:28:20] <mru> iive: that they exist?
[17:28:37] <kshishkov> yuck! boost as in "C++ libraries with size of whole WinXP distribution"?
[17:28:56] <iive> well, boost were changing their api... something with threading ...
[17:29:28] <iive> and I was very happy when i get rid of it...
[17:31:17] <BBB> is the use of __builtin_* discouraged?
[17:31:23] <BBB> or disallowed?
[17:31:25] <kshishkov> IIRC, gnash is used in GLinux (i.e. Mandrake on Gdium). Outdated version, can't play newer YouTube.
[17:31:29] <BBB> or is someone going to shoot me now?
[17:31:33] <kshishkov> disallowed
[17:31:35] <mru> BBB: it's gcc-specific
[17:31:40] <BBB> aha
[17:31:41] <BBB> ok
[17:31:52] <mru> which builtin do you want to use?
[17:32:17] <jai> kshishkov: also takes ages to compile
[17:32:35] <iive> Well, about gnash, i decided to give it more time. maybe i should check it again.
[17:32:45] <kshishkov> jai: yep, reminds me of my experience with compiling Firefox
[17:32:56] <kshishkov> jai: IOW never again
[17:33:40] <jai> kshishkov: heh, wise decision
[17:33:47] <ohsix> mru used __builtin_clz with proper bumpers
[17:34:01] <mru> yes
[17:34:11] <mru> after thoroughly checking that it did the right thing too
[17:34:11] <ohsix> for some stuff its great, as long as you have an alternate, go nuts
[17:34:16] <ohsix> nod
[17:34:48] <ohsix> iirc they're weak too, so if you define them yourself the compiler wont add them
[17:35:08] <ohsix> then you can just do that when its not gcc
[17:35:30] <mru> there's usually a better way than defining a function
[17:35:39] <mru> and not all systems have weak symbols
[17:36:46] <BBB> is 1 << -1 defined?
[17:36:56] <ohsix> in c?
[17:36:59] <BBB> ys
[17:37:09] <BBB> or int x = -1; 1 << x;?
[17:37:20] <BBB> probably not right?
[17:38:23] <ohsix> dont know, sorry; 2s compliment should keep it the "same" with shifts
[17:39:33] <mru> negative shifts are not defined
[17:40:32] <ohsix> they depart from c but they work as you'd expect, right?
[17:40:36] <mru> no
[17:40:38] <mru> they do not work
[17:40:40] <mru> at all
[17:40:44] <mru> or very rarely
[17:41:04] <mru> shifting negative numbers usually works as you'd expect
[17:41:09] <ohsix> what of 0xff... in an unsigned integer
[17:41:11] <mru> although that's not defined by the spec either
[17:41:25] <ohsix> ic ic
[17:41:41] <mru> you're only allowed to shift by a non-negative amount smaller than the width of the shifted operand
[17:42:21] <ohsix> OH, SHIFTING by a negative number, not the shift-ee
[17:42:27] <ohsix> i read that wrong
[18:03:07] <CIA-17> ffmpeg: michael * r21606 /trunk/ffplay.c:
[18:03:07] <CIA-17> ffmpeg: Autodetect when byte based seeking is better (that is for all formats that allow
[18:03:07] <CIA-17> ffmpeg: discontinuities)
[18:03:07] <CIA-17> ffmpeg: Fixes issue1090
[19:36:44] <CIA-17> ffmpeg: cehoyos * r21607 /trunk/libpostproc/postprocess_template.c:
[19:36:44] <CIA-17> ffmpeg: Fix warnings about redefining constants when compiling libpostproc.
[19:36:44] <CIA-17> ffmpeg: Patch by Yuriy Kaminskiy, yumkam mail ru
[19:58:30] <CIA-17> ffmpeg: siretart * r21608 /branches/0.5/subdir.mak:
[19:58:30] <CIA-17> ffmpeg: missing hunk to unbreak linking with symbol versioning
[19:58:30] <CIA-17> ffmpeg: this hunk is does not apply in trunk/ because there the dependencies for
[19:58:30] <CIA-17> ffmpeg: this rule was reworked
[19:58:30] <CIA-17> ffmpeg: siretart * r21609 /branches/0.5/configure:
[19:58:31] <CIA-17> ffmpeg: unbreak compilation with vhook enabled
[19:58:32] <CIA-17> ffmpeg: the backported introduced a regression that prevents successfully
[19:58:32] <CIA-17> ffmpeg: linking vhook shared objects on systems with gnu linkers. As the version
[19:58:33] <CIA-17> ffmpeg: scripts only apply to shared objects against that applications are being
[19:58:33] <CIA-17> ffmpeg: linked, this commit unties the VHOOKSHFLAGS and SHFLAGS variable.
[20:14:49] <BBB> mru: oops forgot to cut tables bla bla etc. too big please allow ffmpeg-devel blieb
[20:15:03] <BBB> (maybe I should just cut them and then resubmit)
[20:17:37] <CIA-17> ffmpeg: siretart * r21610 /branches/0.5/libswscale/libswscale.v: fix version script for libswscale
[20:18:18] <siretart> DonDiego: don't ask. I owe you at least one beer, probably more...
[20:18:36] <Dark_Shikari> BBB: any update on that patent?
[20:18:44] <BBB> didn't ask yet, I
[20:18:48] <BBB> 'm going on vacation first
[20:18:50] <Dark_Shikari> lol
[20:18:52] <BBB> -newline
[20:18:54] <DonDiego> hehe, i was about to..
[20:19:01] <DonDiego> well, beer event on friday..
[20:19:04] <DonDiego> :)
[20:19:17] <BBB> didn't mru look at billions of nokia patents?
[20:19:36] <mru> I only flipped through a couple of pages of hits at google
[20:19:37] <DonDiego> wasn't it Dark_Shikari ?
[20:19:44] <mru> Dark_Shikari looked more iirc
[20:19:54] <DonDiego> anything that might apply to theora?
[20:19:57] <BBB> I didn't erally pay attention :)
[20:20:07] <BBB> the quant patents looked generic enough to apply to anything
[20:20:13] <BBB> literally
[20:20:20] <mru> almost all patents look like that
[20:20:30] <DonDiego> are they part of the mpeg la portfolio?
[20:20:48] <DonDiego> btw: http://mplayerhq.hu/~diego/avc_license.html
[20:20:58] <Dark_Shikari> I looked at 280 patents
[20:21:09] <Dark_Shikari> everything with "assignee: nokia" in it or whatnot
[20:21:21] <Dark_Shikari> that may not cover them all, due to buyouts/etc
[20:21:46] <DonDiego> did you find anything?
[20:22:40] <Dark_Shikari> I pasted them here earlier when you asked
[20:23:04] * DonDiego must have missed that..
[20:23:46] <Dark_Shikari> gle.com/patents/about?id=Ic0CAAAAEBAJ
[20:23:53] <Dark_Shikari> er http://www.google.com/patents/about?id=Ic0CAAAAEBAJ
[20:24:00] <Dark_Shikari> http://www.google.com/patents/about?id=ieIVAAAAEBAJ <--this patent is a huge wtf
[20:24:06] <Dark_Shikari> http://www.google.com/patents/about?id=zGWBAAAAEBAJ
[20:31:13] <CIA-17> ffmpeg: siretart * r21611 /branches/ (5 files in 5 dirs): backport cpu runtime detection for libpostproc and libswscale
[20:34:01] <BBB> huh?
[20:34:15] <BBB> maybe we should just forget about 0.5 and release a 0.6?
[20:34:23] <DonDiego> nonsense
[20:34:32] <mru> that's not how distros operate
[20:34:33] <DonDiego> the 0.5 branch is being tracked by distros
[20:34:56] <DonDiego> siretart himself is the debian/ubuntu packager
[20:34:56] <siretart> BBB: I disagree. I'm currently 'just' upstreaming the pile of patches that have accumulated in the distro package
[20:35:31] <siretart> BBB: while planning 0.6 is certainly a great idea
[20:35:35] <BBB> cpu detection is a new feature
[20:35:45] <Dark_Shikari> just pick a revision and call it 0.6
[20:35:46] <Dark_Shikari> done
[20:35:50] <BBB> or is it considered a bugfix? in which case, what bug does it fix without adding a new feature?
[20:36:05] <siretart> BBB: oh, you're right, that is a bit misleading. only the configure parts are backported, not the feature itself
[20:36:09] <BBB> (the feature that it adds being: "cpu runtime detection")
[20:36:38] <BBB> hmk, then change the revision msg, this is confusing
[20:36:41] <BBB> as you can see :)
[20:37:38] <siretart> are log edits announced by CIA as well?
[20:38:13] <siretart> wow. I didn't know that emacs makes editing commit logs *that* easy...
[20:38:29] <Dark_Shikari> it's the only good thing about svn
[20:38:31] <Dark_Shikari> editing commit logs is easy
[20:38:37] <Dark_Shikari> well, along with the other good thing: it's not cvs
[20:39:47] <siretart> *shrug*
[20:40:04] <BBB> I see it on the mailinglist
[20:40:05] <BBB> so it's ok
[20:40:07] <BBB> thanks
[20:45:39] <CIA-17> ffmpeg: siretart * r21612 /branches/ (0.5 0.5/configure):
[20:45:40] <CIA-17> ffmpeg: Add gnu/kfreebsd to list of recognized operating systems.
[20:45:40] <CIA-17> ffmpeg: patch by Andres Mejia, mcitadel gmail com
[20:46:18] <DonDiego> bye, cu
[20:47:20] <siretart> byebye
[20:49:11] <CIA-17> ffmpeg: siretart * r21613 /branches/0.5/configure: build PIC code on G3 macs
[20:50:41] <mru> siretart: that builds pic on *all* ppc
[20:50:57] <mru> maybe that's what you want, I don't know
[20:52:57] <siretart> mru: at least on debian ppc system, linking against shared libraries fails. and I would be quite surprised if this was a debian speciality...
[20:53:11] <mru> so why mention g3?
[20:53:21] <mru> there is nothing g3-specific in the commit
[20:53:38] <siretart> oh, if that's your objection, I'll fix the commit message
[20:54:14] <mru> I also doubt that PIC is real issue here
[20:55:00] <mru> not that it really matters
[20:56:16] <siretart> hm. no, this wasn't a link issue, but rather a runtime issue: /usr/lib/libavformat.so.52: R_PPC_REL24 relocation at 0x0d925f74 for
[20:56:19] <siretart> /usr/lib/libavformat.so.52: R_PPC_REL24 relocation at 0x0d925f74 for
[20:56:41] <mru> that's a linker problem
[20:56:59] <siretart> indeed, I was wrong
[20:57:04] <mru> something used a 24-bit relocation and the dynlinker decided to put the libs more than 24 bits apart
[20:57:24] <mru> pic only solves that as a side-effect
[20:57:55] <siretart> the next line was: 'symbol `fcntl' out of range'
[20:58:01] <mru> with pic, all external references go through a per-library GOT
[20:58:13] <mru> and the GOT has 32-bit relocations
[20:58:47] <mru> it could still fail if a single lib grew larger than 1<<24 bytes
[20:58:54] <siretart> how can this issue be prevented without pic?
[20:58:56] <mru> or maybe it's x4 on top of that
[21:00:58] <mru> -mlongcall would probably fix it
[21:01:26] <mru> the linker could also add trampolines as necessary
[21:01:29] <mru> but it doesn't
[21:09:15] <siretart> log message updated
[21:32:16] <CIA-17> ffmpeg: michael * r21614 /trunk/ffplay.c:
[21:32:16] <CIA-17> ffmpeg: Commit disapeared hunk, must have editied this out by mistake between local debug statements.
[21:32:16] <CIA-17> ffmpeg: This should fix seeking in TS.
[22:23:58] <CIA-17> ffmpeg: cehoyos * r21615 /trunk/ (libavformat/flvenc.c ffmpeg.c):
[22:23:58] <CIA-17> ffmpeg: Guess the duration before converting video and write guessed duration
[22:23:58] <CIA-17> ffmpeg: into flv header.
[22:23:58] <CIA-17> ffmpeg: Patch by Justin Johnson, justin D johnson3 A gmail
[22:44:00] <CIA-17> ffmpeg: michael * r21616 /trunk/ffplay.c:
[22:44:01] <CIA-17> ffmpeg: Move the initial refresh scheduling for audio display away from where it
[22:44:01] <CIA-17> ffmpeg: can interfere with video.
[22:58:45] <CIA-17> ffmpeg: cehoyos * r21617 /trunk/libavcodec/rawdec.c: Fix r21223: AVup samples (issue 1685) need a buf offset like AV1x (issue 1684).
[23:09:22] <ramiro> hi
[23:10:53] <ramiro> is a movslq from 32-bit to the same 64-bit register any kind of speed penalty?
[23:11:38] <Dark_Shikari> you mean movsxd?
[23:11:43] <Dark_Shikari> it takes one uop
[23:13:06] <ramiro> hmm... I'm wasting so much time because of 1 uop...
[23:23:23] <CIA-17> ffmpeg: michael * r21618 /trunk/ffplay.c:
[23:23:23] <CIA-17> ffmpeg: Compare the correct clocks for syncing video to audio/ext.
[23:23:23] <CIA-17> ffmpeg: Fixes initial delay on video from issue1134.
[23:54:27] <CIA-17> ffmpeg: michael * r21619 /trunk/libavformat/avidec.c: Set nb_frames.