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

[irc at mansr.com]

[00:06:29] <lu_zero> uh
[00:06:31] <lu_zero> interesting
[00:06:43] <lu_zero> I got a sample file for mpegts
[00:06:48] <lu_zero> vlc plays it right
[00:06:53] <lu_zero> ffplay/ffmpeg puke on it
[00:07:47] <mru> you know what to do
[00:08:07] <kierank> lu_zero: is it h264?
[00:11:35] <lu_zero> kierank: mpeg4
[00:11:37] <lu_zero> and yes
[00:11:40] <lu_zero> I know what to do
[00:11:49] <lu_zero> comment out something in libavformat/utils.c
[00:11:59] <kierank> might be one of those ones where the pps is in the next frame
[00:15:42] <lu_zero> eh eh...
[00:15:45] <lu_zero> obviously...
[00:37:30] <spaam> mru: hard to commit a !git-formated-patch ?
[00:37:39] <mru> lazy
[00:37:55] <mru> properly formatted takes one keystroke
[00:39:10] <twnqx> are there known issues with framerate detection for MJPG in avi?
[00:39:33] <twnqx> i kinda have the feeling it plays too fast
[00:40:08] <twnqx> on the other hand...     Stream #0.0: Video: mjpeg, yuvj422p, 640x480, 30 tbr, 30 tbn, 30 tbc
[00:43:22] <twnqx> hm, fps = "auto"
[00:43:26] <twnqx> (in the cam)
[01:26:38] <CIA-38> ffmpeg: Takashi Mochizuki <mochi at da2.so-net.ne.jp> master * r44b1120724 ffmpeg/libavformat/movenc.c:
[01:26:38] <CIA-38> ffmpeg: movenc: Force first sample as SYNC
[01:26:38] <CIA-38> ffmpeg: Signed-off-by: Mans Rullgard <mans at mansr.com>
[01:37:59] <mru> BBB: ping
[01:38:07] <BBB> pong
[01:38:13] <mru> that swscale patch
[01:38:20] <BBB> I just said ok
[01:38:23] <mru> I know
[01:38:29] <BBB> what's wrong with it?
[01:38:32] <BBB> it looked ok to me
[01:38:33] <mru> I don't know
[01:38:38] <BBB> ?
[01:38:49] <BBB> fate broke?
[01:38:55] <mru> I expected someone to object against using another register or whatever
[01:39:04] <BBB> it only uses 4 or 5
[01:39:10] <BBB> x86 always has 6
[01:39:27] <mru> I didn't say I expected the objection to be rational
[01:39:29] <BBB> we don't care about pow(broken,3) systems that sometimes have 5 or 4 for particular compilers
[01:39:29] <BBB> :)
[01:39:38] <BBB> mru: I think the trolls are gone for now
[01:39:53] <mru> I also don't trust myself with x86 asm
[01:41:28] <mru> I don't suppose the extra instruction needed to load the address into a register is anything to worry about
[01:43:40] <CIA-38> ffmpeg: Mans Rullgard <mans at mansr.com> master * rf344903ca5 ffmpeg/libswscale/swscale_template.c:
[01:43:40] <CIA-38> ffmpeg: Fix MMX rgb24 to yuv conversion with gcc 4.6
[01:43:40] <CIA-38> ffmpeg: When built with gcc 4.6, the MMX rgb24 to yuv conversion gives
[01:43:40] <CIA-38> ffmpeg: wrong output. The compiler produces this warning:
[01:43:40] <CIA-38> ffmpeg: libswscale/swscale_template.c:1885:5: warning: use of memory input without lvalue in asm operand 4 is deprecated
[01:43:41] <CIA-38> ffmpeg: Changing the memory operand to a register makes it work.
[01:43:42] <CIA-38> ffmpeg: Signed-off-by: Mans Rullgard <mans at mansr.com>
[01:43:59] <mru> now we wait
[01:47:47] <spaam> mru: you say that libavformat is a messs. why dont you fix it then?
[01:48:01] <spaam> or are you to lazy for that also? :P
[01:49:39] <BBB> mru: well, it's the same thing actually
[01:50:01] <BBB> mru: as in, both take a register
[01:50:26] <BBB> you change a mov %4 with "m"(*memory) to a mov(%4) with "r"(memory)
[01:50:48] <BBB> mru: in the end, the memory is loaded as a memory argument, which it loads from a register, and thus it takes a register anyway
[01:50:53] <bcoudu> BBB and mru, can we please stop this nonsensical discussion
[01:50:54] <BBB> mru: so the code is actually identical
[01:50:58] <bcoudu> about timestamps
[01:51:04] <BBB> bcoudu: ok
[01:51:06] <bcoudu> BBB you have no clue as to why dts are needed
[01:51:11] <mru> wouldn't the "m" turn into an immediate address?
[01:51:27] <bcoudu> and why TS has them since 20 years
[01:51:42] <ohsix> i know i have no clue, where can i familiarize myself
[01:51:44] <mru> dts are needed in buffer-constrained synchronous systems
[01:51:45] <bcoudu> more than this actually
[01:51:46] <BBB> mru: (%4) with "r" is an immediate address as much as %4 is with "m"
[01:51:47] <mru> not on a pc
[01:51:49] <BBB> mru: both are
[01:51:58] <mru> no
[01:52:07] <mru> (reg) is a register indirect address
[01:52:29] <mru> immediate means the absolute address is part of the opcode
[01:52:37] <BBB> oh like that
[01:52:55] <BBB> I don't think gcc would compile it as such
[01:53:09] <mru> I admit I didn't check
[01:53:11] <BBB> it's not something like ff_pw, which is actually a memory location
[01:53:19] <mru> it is a memory location
[01:53:23] <BBB> it's more like &ff_pw[x==1?5:7]
[01:53:31] <mru> the index is constant
[01:53:45] <BBB> the few times when I looked at this, gcc would put it in a register
[01:53:49] <BBB> which is kinda stupid, admittedly
[01:53:49] <mru> ok
[01:54:00] <BBB> might be apple's gcc version being dumb
[01:54:33] <BBB> "m"(ff_bgr24toUV[srcFormat == PIX_FMT_RGB24][0]) <- that's the one you change, right?
[01:54:39] <mru> yes
[01:54:41] <BBB> there is a conditional in it
[01:54:47] <BBB> so I'm quite sure gcc would put it in a register
[01:54:48] <mru> srcFormat is constant
[01:54:54] <BBB> ah, I didn't know
[01:55:07] <mru> it's inlined into two places with a different constant
[01:55:15] <BBB> got it
[01:55:49] <BBB> I guess if you want to make sure gcc does the right thing, you should MANGLE(absolute_address) it
[01:56:01] <BBB> but as you remember from a few months ago, that'd fail on gcc 3.x
[01:56:10] <BBB> (with the loopstrengthfilter inline asm code)
[01:56:26] <mru> and that doesn't work with the conditional, even though compile-time constant
[01:56:36] <BBB> exactly
[01:58:08] <BBB> but as I said, I think even gcc4.x puts it in a register anyway
[01:58:15] <BBB> not because it's necessary, but just because that's what gcc does
[01:58:25] <mru> got it
[01:58:28] <BBB> if you want to be absolutely sure it doesn't do that, you unfortunately have to rewrite it in asm
[01:58:40] <BBB> (external asm, i.e. yasm)
[01:59:48] <BBB> bcoudu: I'll cut the discussion... I would like to have a more constructive discussion at some point on all the timestamp hacks in lav[fc]/{cmdutils,ffmpeg,ffplay}.c, because it's a mess, and if michael got hit by a bus, we'd be in a deep pile of shit because nobody understands any of that code
[02:00:31] <ohsix> time os for jerks
[02:00:43] <ohsix> is. not os; that would be dirty
[02:02:48] <BBB> mru: "[PATCH] faster SSE FFT" is ok also, can you push?
[02:03:10] <BBB> didn't dondiego have push rights also?
[02:03:17] <BBB> he hasn't committed anything yet
[02:13:58] <ohsix> mru: how do you feel about enums with switches & all labels
[02:14:22] <ohsix> and default
[02:14:28] <mru> ridiculous
[02:14:31] <bcoudu> it's hard to have a constructive discussion about this
[02:14:54] <lu_zero> ^^?
[02:14:57] <mru> it's just noise
[02:15:00] <mru> best case
[02:15:00] <lu_zero> bcoudu: what do you mean?
[02:15:10] <mru> worst case it turns into actual dead code
[02:15:13] <ohsix> i like em, if you add something to the enum you can get the compiler to complain where it's likely used
[02:19:47] <bcoudu> I can't see how a constructive discussion can happen given the current situation
[02:22:01] <lu_zero> why?
[02:23:18] <ohsix> people litigating over stuff they partially understand?
[02:23:53] <BBB> bcoudu: I'll shut up if that helps - but eventually at some point a constructive discussion would be needed
[02:24:25] <ohsix> from not knowing anything about pts/dts/whatever, mans has a good point about messing with information you might need to filter to make useful
[02:24:46] <BBB> mru: I was thinking, perhaps one way of making this work is by using four memory arguments, %4 being table[0/1][0], %5 being table[0/1][4], and so on for %6/%7
[02:25:05] <BBB> mru: I'd have to look at the disassembly to see whether gcc-4.x and 3.x actually do the right thing, but they might
[02:30:42] <BBB> [0/1][0/1/2/3], actually, I didn't realize they're uint64_t already
[02:32:11] <uau> ff_bgr24toUV[srcFormat == PIX_FMT_RGB24][0]  looks like it should be an lvalue
[02:38:33] <mru> it does
[02:39:05] <mru> BBB: I wouldn't bother with that function
[02:43:38] <BBB> I'll just give it a quick try
[02:46:15] <BBB> hm, it actually works
[02:46:19] <BBB> mru: see new patch on IRC
[02:46:25] <BBB> "MASSIVE PERFORMANCE IMPROVEMENT"
[02:46:32] <BBB> (or so... ... ...)
[02:46:47] <peloverde> Even on a mov to mov stream copy where we have frame_size set correctly, we still wind up with a broken stsz box because frame_size > pkt->size
[02:55:33] <peloverde> bcoudu: I'm sorry I called you names, can you please elaborate on how this is supposed to work?
[02:56:56] <ohsix> you called him names?!
[02:58:09] <Compn> BBB : btw , rejecting a patch because you want the rest of ffmpeg fixed first sounds like a dumb argument
[02:58:41] <Compn> maybe i'm misunderstanding the situation of course ;)
[02:58:42] <mru> from what I can tell, the patch doesn't improve anything
[02:58:51] <Compn> does it fix some sample s?
[02:59:00] <mru> none that anyone cared to mention
[02:59:12] * Compn will ask on list for samples it fixes then
[02:59:21] <mru> what it does is embed the hacks in the external api
[02:59:23] <mru> and that is a bad
[03:05:12] <peloverde> encoding adpcm_ms to mov is also broken?
[03:05:23] <peloverde> what was that patch tested with?
[03:09:59] <Compn> hmm, whos the master at reverse engineering game codecs?
[04:15:03] <peloverde> ugh, I've wasted the entire day and ms adpcm in mov is still broken
[04:15:17] <mru> does anyone even use that?
[04:16:46] <peloverde> i don't know, but it is a crasher
[04:17:22] <ohsix> add an error message that tells them to stuff it
[04:18:12] <peloverde> that's dumb, let's just fix the bug(s)
[04:18:21] <mru> compress it with stuffit instead?
[04:28:27] <peloverde> interesting, i have it working with one block per packet
[05:28:50] <Sean_McG> heh, does anyone actually use stuffit anymore?
[05:31:18] * saintdev expands Sean_McG 
[05:32:50] <Sean_McG> I mean, hell, I have a Mac and even I don't
[05:42:24] <astrange> the built in zip replaced stuffit on OS X a few years ago
[05:42:35] <Sean_McG> basically
[05:42:46] <Sean_McG> I used to use stuffit when I had my G4
[07:33:53] <cryptw> what's the abuild command
[07:34:01] <cryptw> to just do the final step in actually
[07:34:07] <cryptw> creating/signing the package?
[09:33:19] <elenril> KotH: do you mind a 700mb sample in incoming?
[10:55:37] <lu_zero> what happened to the yadif filter?
[12:09:37] <lu_zero> yawn
[12:15:37] <kierank> i wonder why nobody trolled the webm list about patents
[12:30:15] <mru> morning
[12:33:30] <jannau> kierank: nobody cares enough about webm
[12:33:34] <jannau> morning
[13:25:16] <CIA-38> ffmpeg: Peter Ross <pross at xvid.org> master * rcb62510cab ffmpeg/libavcodec/bink.c:
[13:25:16] <CIA-38> ffmpeg: bink: simplify how quantization matrices are passed to read_dct_coeffs()
[13:25:16] <CIA-38> ffmpeg: Signed-off-by: Mans Rullgard <mans at mansr.com>
[13:29:48] <spaam> omg  a normal mail from arpi :D
[13:29:58] <mru> and it's not insulting
[13:30:03] <mru> that's the real surprise
[13:30:24] <mru> he's wrong of course, but that's a different matter
[13:33:06] <mru> _av500_: http://www.engadget.com/2011/02/12/eighth-circuit-declares-razr-a-computer-under-federal-law/
[13:48:29] <divVerent> as this is a big topic on the mailing list (again, I suppose)... is there any documentation HOW an application calling ffmpeg should fill out dts?
[13:48:55] <divVerent> currently, I simply choose to not fill it out and have libavformat calculate dts from pts, pts coming from coded_frame->pts from libavcodec
[13:49:48] <divVerent> from Dark_Shikari I at another time I got the info (I probably misunderstood it) to just use "pts minus encoding delay", but this makes no sense
[13:49:58] <divVerent> as if ordered by dts, pts are not monotonous, and vice versa
[13:50:22] <mru> for software decoding on a pc-like system dts is irrelevant
[13:50:31] <divVerent> sure
[13:50:38] <divVerent> but what is "proper" use of libavcodec/libavformat?
[13:50:49] <mru> depends on what you're doing
[13:50:55] <divVerent> "I want to encode video"
[13:51:21] <divVerent> seriously... assume this:
[13:51:32] <divVerent> my input is "I want to show this video frame at this time"
[13:51:40] <divVerent> I even know display duration, I think, not 100% sure about it
[13:51:50] <mru> when _encoding_ you should give the encoder pts of each input frame and the encoder should then assign correct dts to encoded output frames
[13:51:55] <divVerent> I want to use the encoder "transparently"
[13:51:56] <mru> in an ideal world
[13:52:00] <mru> that's how x264 works
[13:52:17] <divVerent> so I don't want to know implementation details like how many b-frames the encoder happens to be using right now
[13:52:38] <divVerent> my current code just sets pts, and ignores dts
[13:52:50] <divVerent> which triggers libavutil's dts-from-pts-by-sorting-and-some-magic code
[13:53:16] <divVerent> which fails for the first frames of a video if the time base is <1ms (VFR)
[13:53:20] <twnqx> i think mplayer gets wrong data from my vfr .avi
[13:53:25] <divVerent> so as workaround, my application sets a duration of 1 for the very first frame
[13:53:32] <divVerent> to make the libavformat code not fail
[13:53:34] <twnqx> via libavcodec/libavformat
[13:53:46] <divVerent> but - this can't be the right way to use the API
[13:54:06] <mru> twnqx: avi doesn't support vfr
[13:54:24] <twnqx> but the player for this cam gets the speed right
[13:54:29] <mru> divVerent: I'm afraid there is no sane way to use lavf with timestamps
[13:54:44] <divVerent> mru: I mean... what is the -correct- way?
[13:54:48] <divVerent> let's ignore "sane" for now :P
[13:55:08] <divVerent> one possibly correct way would be easy if I had the dts for the video strea
[13:55:15] <divVerent> but libavcodec does not provide it, so that possibility is out
[13:55:28] <mru> divVerent: same answer
[13:55:36] <divVerent> Dark_Shikari's suggestion "pts minus encoding delay" actually may be ambigous
[13:55:42] <mru> libavcodec is broken
[13:55:50] <divVerent> is it "pts of coded_frame minus enoding delay"
[13:56:01] <divVerent> or "pts of frame I passed to avcodec_encode_video minus encoding delay"
[13:56:03] <mru> it's not that simple
[13:56:07] <divVerent> subtly different, but the latter may even be correct
[13:56:15] <divVerent> the former is obviously wrong
[13:56:21] <divVerent> the latter is "maybe correct, but insane if it is"
[13:57:03] <mru> dts increases with one frame period per coded frame
[13:57:04] <divVerent> mru: are there any plans on fixing libavcodec for VFR?
[13:57:17] <divVerent> yes, but I am encoding VFR :P
[13:57:24] <BBB> I like mru's last suggestion to remove all pts/dts adjustment code and fix it back from scratch
[13:57:27] <divVerent> I suppose, libavformat's reordering logic is even MOSTLY correct
[13:57:37] <divVerent> BBB: and how would that go?
[13:57:50] <mru> that's not a correct assumption
[13:58:00] <BBB> you select the code in a editor, then you hit "delete"
[13:58:02] <mru> the timestamp logic in lavf is 10 years of hacks
[13:58:08] <divVerent> BBB: I mean, from application view
[13:58:12] <divVerent> how would the final API look
[13:58:19] <BBB> divVerent: api looks same as now
[13:58:19] <mru> more or less the same
[13:58:27] <mru> but it would do the right thing
[13:58:28] <BBB> except that it works and needs no hacks app-side
[13:58:29] <divVerent> personally, I'd prefer "coded_frame provided by libavcodec contains dts, application copies it to AVPacket"
[13:58:36] <mru> instead of randomly guessing
[13:58:37] <divVerent> BBB: cannot be the same :P
[13:58:45] <divVerent> BBB: because currently libavcodec provides no dts
[13:58:50] <mru> that should be fixed
[13:58:53] <divVerent> and I suppose, providing the dts from there is the only sane solution
[13:59:00] <divVerent> libx264 provides it, IIRC
[13:59:02] <mru> yes
[13:59:07] <mru> x264 works very well
[13:59:35] <divVerent> another issue is the duration :P
[13:59:58] <divVerent> AVPacket contains "packet duration", whatever that is
[14:00:28] <divVerent> but FF_COMMON_FRAME does not
[14:00:35] <divVerent> so, if I treat libavcodec as blackbox, which I have to
[14:00:45] <divVerent> then I do not know which input frame coded_frame actually contains
[14:00:50] <divVerent> so how am I supposed to know its duration?
[14:01:19] <divVerent> of course, I could have my own array of pts<->duration assignment, and search for coded_frame's pts in that array, and get the duration from there
[14:01:22] <divVerent> but that would be insanity
[14:02:19] <mru> I'd just use x264 for encoding
[14:02:23] <mru> much simpler
[14:02:30] <divVerent> I want to support other codecs too
[14:02:34] <divVerent> not be fixated on a single one
[14:02:41] <divVerent> especially given that there may be multiple upcoming codecs
[14:02:48] <divVerent> this is what an abstraction layer like libavcodec is for, anyway
[14:02:49] <mru> add support for them to x264 :)
[14:02:52] <divVerent> haha
[14:03:14] <divVerent> to actually "nicely" solve this from the app: assume I use the "opaque" field in AVFrame passed to avcodec_encode_video
[14:03:24] <divVerent> will the coded_frame later contain that field too?
[14:03:29] <mru> probably not
[14:03:31] <divVerent> i.e. is coded_frame a copy of the one I passed, with the data encoded
[14:03:37] <divVerent> or is it a "new" one made by the encoder?
[14:03:41] <mru> the encoding api sucks
[14:04:31] <divVerent> then it needs fixing :P
[14:04:46] <divVerent> IMHO it needs two things urgently:
[14:04:53] <divVerent> - dts passing from codec to format
[14:05:04] <divVerent> - "arbitrary option string" processing for codec libraries
[14:05:23] <divVerent> so e.g. libx264 could provide ALL x264 options as an option namespace, e.g. libx264_ref
[14:05:33] <divVerent> (so if x264 adds its own new option, lavc won't need any change for it)
[14:06:00] <mru> nobody is disagreeing
[14:06:06] <divVerent> would also allow a codec to e.g. support stuff like --preset in x264
[14:06:21] <divVerent> if these two are solved, I'd actually consider it sane
[14:06:34] <divVerent> as these seem to be the only design flaws there
[14:07:57] <CIA-38> ffmpeg: Peter Ross <pross at xvid.org> master * r2315392174 ffmpeg/libavcodec/bink.c:
[14:07:57] <CIA-38> ffmpeg: bink: permute Bink version 'b' quant matrices by inverse scan order
[14:07:57] <CIA-38> ffmpeg: This fixes visual glitches in Bink version 'b' files, as the quantization
[14:07:57] <CIA-38> ffmpeg: tables were not being permuted.
[14:07:57] <CIA-38> ffmpeg: Signed-off-by: Mans Rullgard <mans at mansr.com>
[14:26:58] <BBB> peloverde: ping
[14:27:05] <BBB> peloverde: is the LTP patch fine to apply now?
[14:29:48] <kshishkov> BBB: not until he says so on ML
[14:29:58] <BBB> I think he did already
[14:57:02] <BBB> astrange: should I start pushing h264 etc. patches?
[14:58:05] <jannau> wtf apple! Apple Mail (2.1082) doesn't set references and in-reply-to headers
[14:58:22] <BBB> mru: did you test that my alternative swscale patch fixes gcc-4.6 compile?
[14:58:31] <BBB> mru: the patch is better and should probabyl be used instead
[14:58:57] <mru> why is it better?
[14:59:10] <BBB> saves 1 instruction with some gcc versions
[14:59:49] <mru> how does it behave with PIC and such nasties?
[14:59:56] <BBB> works
[14:59:59] <BBB> I tested that yesterday
[15:00:06] <mru> I wouldn't be surprised if some gcc version allocated 4 registers
[15:00:12] <BBB> I was hoping you could test with gcc-4.6 and 3.x and make sure it works
[15:00:36] <BBB> if it works with 3.x, I trust it (just see if it compiles)
[15:23:15] <Sean_McG> do you folks have requirements for the earliest version of gcc it should be compiled with? are they enforced?
[15:23:48] <mru> depends a bit on the target
[15:25:16] <spaam> kshishkov: you can write that bink encoder ;)
[15:29:00] <kshishkov> spaam: why?
[15:29:23] <Kovensky> Sean_McG: propbably x.y.1+, with the biggest possible x and then the biggest possible y :)
[15:29:59] <Sean_McG> Kovensky: would be nice
[15:30:00] <mru> x and y should have odd parity
[15:30:27] <spaam> kshishkov: bink is great.
[15:30:31] <spaam> ;)
[15:30:34] <Sean_McG> I think D_S told me he uses 3.4.5 ;)
[15:30:55] <mru> 3.4 does a decent job on x86
[15:31:06] <kshishkov> spaam: so push it for next generation patent-free codec. It has patents on encoder though IIRC
[15:31:10] <mru> on other targets anything older than 4.3 is likely useless
[15:33:33] <Sean_McG> anyways, I'mma go fix myself up and head out for late breakfast
[15:34:11] <Kovensky> < Sean_McG> I think D_S told me he uses 3.4.5 ;) <-- which is cygwin's default
[15:34:33] <kshishkov> Kovensky: and D_S is using Windows. Coincidence?
[15:34:42] * mru submits a gcc bug report
[15:34:56] <Kovensky> <@mru> on other targets anything older than 4.3 is likely useless <-- gcc propably did well on m68k before 4.3 too :)
[15:35:22] <kshishkov> Kovensky: ask hyc when he's around, he claimed to work on that backend long ago
[15:35:34] <Sean_McG> I dunno about that... I think vendor compilers were so compelling when compared to gcc that no one cared if it wasn't x86
[15:35:55] <Kovensky> IIRC gcc was written for m68k, then ported to everything else
[15:36:14] <Sean_McG> really? what was the first target... Sun boxen?
[15:36:24] <mru> it was started in the 80s
[15:36:29] <mru> PCs barely existed
[15:36:45] <mru> when did the 386 come out?
[15:36:50] <kshishkov> later
[15:36:56] <Sean_McG> early 90's methinks
[15:37:15] <kshishkov> 1985
[15:37:17] <Kovensky> the GNU OS targeted m68k
[15:37:23] <Sean_McG> oh, wow
[15:37:28] <Kovensky> but it didn't get the opportunity because GNU Turd is still not ready
[15:37:31] <kshishkov> Kovensky: Hurd?
[15:37:42] <kshishkov> Kovensky: it's Hurd NG now!
[15:37:48] <Sean_McG> hahahah Turd
[15:37:54] <mru> I remember 486 was commonplace in 93
[15:38:08] * Kovensky had one from 1994 to 1997
[15:38:28] <Sean_McG> yeah I was in highschool back then and we'd just got a whole fleet of new 486's in 95
[15:38:49] <mru> and everybody was excited about the glorious pentium about to be launched
[15:38:58] * Kovensky started elementary in 1996
[15:39:09] <Sean_McG> yeah, I'm old :(
[15:39:25] <Kovensky> actually, at the time, elementary started in 1997
[15:39:25] <mru> in 96 most of the school machines were 486, with a few pentiums around
[15:39:45] <Compn> all our schools were mac , the whole way
[15:39:52] <Sean_McG> we had both
[15:39:55] <Sean_McG> Macs and PCs
[15:39:55] <kshishkov> Compn: you're US guy
[15:40:06] <Kovensky> but ~3 years ago the government decided to retroactively make the last year of kindergarten the first of elem
[15:40:09] <Compn> kindergarden = apple 2
[15:40:16] <kshishkov> my school still had 386+486s till 99 I think
[15:40:18] <Kovensky> garden*
[15:40:31] <Kovensky> my high school still used win98 when I studied there
[15:40:33] <Sean_McG> and I always gravitated towards the Mac labs, but the programming courses were all Visual BASIC (although we did do a smattering of Delphi *gasp*)
[15:40:59] * Kovensky used anything mac for the first time last november when he decided to do a hackintosh
[15:41:18] * mru was never formally taught a programming language
[15:41:35] * Kovensky was formally taught a programming language now in uni
[15:41:36] <mru> apart from perhaps java in uni
[15:41:38] <kshishkov> mru: so you're untainted
[15:41:46] <Kovensky> they were all terribly taught though and I already knew anything useful before anyway
[15:42:22] <Sean_McG> think at home I still had a C=64 back then
[15:42:49] * mru never owned a C64
[15:42:51] <mru> nor amiga
[15:42:59] <kshishkov> mruCDGS: too bad
[15:42:59] <Sean_McG> and I kept bugging my dad to get us an Amiga
[15:42:59] <mru> some friends had them
[15:43:06] <mru> I never "got it"
[15:43:07] <Kovensky> Sean_McG: my trauma: a version of pascal with syntax in portuguese and with several builtin functions moved to global namespace and also translated to portuguese, and a "C++" class that actually used the borland C++-Delphi chimera and claimed that everything in there was C++ itself, not C++ with Delphi's API
[15:43:31] <Sean_McG> Kovensky: I just remember how incredibly picky about syntax it was
[15:43:36] <kshishkov> people in .su started with ZX Spectrums, my first computer was AMD-166
[15:43:56] <Kovensky> the first time I even saw an AMD was a 750MHz Duron
[15:44:21] <mru> iirc a classmate had a k5 at some point
[15:45:30] <mru> kshishkov: reading your notes about countries...
[15:45:37] <mru> kshishkov: did you visit vigelandparken in oslo?
[15:45:52] <kshishkov> mru: nope, does it has statues?
[15:45:57] <mru> you could say that
[15:46:05] <mru> overdone doesn't even begin to describe it
[15:46:22] * kshishkov is not surprised
[15:46:50] <kshishkov> well, compare RÃ¥dhus in Oslo vs. Stadthus in Stockholm
[15:47:16] <mru> http://www.google.co.uk/images?q=vigeland
[15:47:28] <mru> that's all the work of one man
[15:49:14] <kshishkov> just compare common look of http://sv.wikipedia.org/wiki/Stockholms_stadshus and http://no.wikipedia.org/wiki/Oslo_r%C3%A5dhus
[16:08:44] <CIA-38> ffmpeg: Anssi Hannula <anssi.hannula at iki.fi> master * r482d98f69b ffmpeg/ (Changelog libavformat/spdifenc.c libavformat/version.h):
[16:08:44] <CIA-38> ffmpeg: spdifenc: IEC 61937 encapsulation of DTS-HD for HDMI
[16:08:44] <CIA-38> ffmpeg: Signed-off-by: Janne Grunau <janne-ffmpeg at jannau.net>
[16:08:55] <CIA-38> ffmpeg: Anssi Hannula <anssi.hannula at iki.fi> master * r57f2c9aed9 ffmpeg/libavformat/spdifenc.c: (log message trimmed)
[16:08:55] <CIA-38> ffmpeg: spdifenc: fix byte order on big-endian systems
[16:08:55] <CIA-38> ffmpeg: There is a check for HAVE_BIGENDIAN when outputting the IEC 61937
[16:08:55] <CIA-38> ffmpeg: stream. On big-endian systems the payload data is not byteswapped,
[16:08:56] <CIA-38> ffmpeg: causing in effect the outputted payload data to be in a different byte
[16:08:56] <CIA-38> ffmpeg: order on big-endian than on little-endian systems.
[16:08:57] <CIA-38> ffmpeg: However, the IEC 61937 preamble (and the final odd byte if present) is
[16:08:57] <CIA-38> ffmpeg: Anssi Hannula <anssi.hannula at iki.fi> master * r3c33c0e263 ffmpeg/libavformat/utils.c:
[16:08:58] <CIA-38> ffmpeg: lavf: print stream disposition in dump_stream_format
[16:08:58] <CIA-38> ffmpeg: Signed-off-by: Janne Grunau <janne-ffmpeg at jannau.net>
[16:08:59] <CIA-38> ffmpeg: Loren Merritt <lorenm at u.washington.edu> master * re6b1ed693a ffmpeg/libavcodec/ (6 files in 3 dirs):
[16:09:25] <CIA-38> ffmpeg: FFT: factor a shuffle out of the inner loop and merge it into fft_permute.
[16:09:25] <CIA-38> ffmpeg: 6% faster SSE FFT on Conroe, 2.5% on Penryn.
[16:09:25] <CIA-38> ffmpeg: Signed-off-by: Janne Grunau <janne-ffmpeg at jannau.net>
[16:23:07] <CIA-38> ffmpeg: Mans Rullgard <mans at mansr.com> master * rbb7a22b584 ffmpeg/configure:
[16:23:07] <CIA-38> ffmpeg: configure: add cleanws() function
[16:23:07] <CIA-38> ffmpeg: This function removes leading and trailing spaces and collapses
[16:23:07] <CIA-38> ffmpeg: multiple spaces into one.
[16:23:07] <CIA-38> ffmpeg: Signed-off-by: Mans Rullgard <mans at mansr.com>
[16:23:09] <CIA-38> ffmpeg: Mans Rullgard <mans at mansr.com> master * r5d57846bba ffmpeg/configure:
[16:23:09] <CIA-38> ffmpeg: configure: report full gcc version string
[16:23:09] <CIA-38> ffmpeg: This makes the cc_ident value, which is used in FATE reports, include
[16:23:09] <CIA-38> ffmpeg: all interesting parts of the gcc version string.
[16:23:10] <CIA-38> ffmpeg: Signed-off-by: Mans Rullgard <mans at mansr.com>
[16:35:16] <Kovensky> < CIA-38> ffmpeg: configure: add cleanws() function <-- I remember I + several other people in another channel did several implementations of that each in a different language
[16:35:21] <Kovensky> lol
[16:35:41] * Kovensky did one in C and one in Perl
[16:36:21] <mru> I could do it in pure shell script, but that wouldn't be very efficient
[16:39:14] <divVerent> how does cleanws() differ from "xargs echo"?
[16:39:16] <divVerent> ;)
[16:39:39] <mru> embedded whitespace
[16:40:18] <mru> foo=' foo < bar   ( $baz    '
[16:40:19] <divVerent> looks like the ffmpeg git repo I use doesn't have this commit yet...
[16:40:30] <divVerent> I would say you want 'foo < bar ( $baz' then?
[16:40:34] <mru> yes
[16:40:43] <Kovensky> http://www.cracktwo.com/2011/02/what-if-worlds-most-influential-tyrant.html
[16:40:52] <divVerent> [rpolzer at grawp ~]$ echo ' foo < bar   ( $baz    ' | xargs echo
[16:40:54] <divVerent> foo < bar ( $baz
[16:41:13] <divVerent> my main objection against xargs echo is nasty platforms where echo is weird
[16:41:25] <mru> precisely
[16:41:32] <mru> echo is often very weird
[16:41:35] <divVerent> but, simulating xargs echo is simple anyway
[16:41:53] <divVerent> out=""; for x in $string; do out="$out $x"; done; out=${out# }
[16:42:22] <divVerent> or, if you are allowed to mess up the positional parameters:
[16:42:31] <divVerent> set -- $string; out=$*
[16:42:47] <divVerent> (e.g. safe to do in a function specially made for it)
[16:43:30] <divVerent> wouldn't be 100% sure about THAT latter one though, as THAT might fail on nasty platforms
[16:43:38] <divVerent> (but if it works on Solaris, it works everywhere)
[16:44:27] <divVerent> one shell where this sure fails, is zsh, BTW, which generally assumes that you don't want to word-split variables
[16:44:44] <divVerent> in a script I made, I thus have a hack:
[16:44:47] <mru> xargs echo fails if string contains quotes
[16:44:53] <divVerent> if [ -n "$ZSH_VERSION" ]; then setopt SH_WORD_SPLIT; fi
[16:45:29] <divVerent> http://paste.pocoo.org/show/337761/ - I currently have this portability hack... which is annoying
[16:45:49] <divVerent> this echo test fails on MSYS
[16:46:07] <divVerent> no idea what they did to their shell
[16:47:01] <divVerent> but well, this cleanws() isn't that bad even
[16:47:02] <mru> 16:40 < divVerent> looks like the ffmpeg git repo I use doesn't have this commit yet... <-- what repo do you use?
[16:47:09] <divVerent> except if the first arg happens to be, e.g., -E
[16:47:28] <mru> I suppose it could use printf instead
[16:47:41] <divVerent> git://repo.or.cz/FFMpeg-mirror/mplayer-patches.git - managed by uau
[16:47:47] <divVerent> no idea how its merging policy is, though
[16:48:02] <divVerent> but I am basically forced to use this one as mplayer2's build system uses it as a submodule
[16:48:22] <divVerent> as for that cleanws() function...
[16:48:29] <divVerent> I suppose, with a small change it should be portable
[16:48:43] <divVerent> change echo "$@" to either echo "" "$*" or printf "%s\n" "$*"
[16:48:59] <divVerent> both should reliably prevent echo option parsing mess
[16:49:01] <mru> yes, I know
[16:49:06] <divVerent> but the backslash issue... printf should fix that
[16:49:55] <uau> divVerent: the submodule part shouldn't really force that
[16:49:58] <divVerent> set -- "$*"; printf "%s" "$*" is "neater" though
[16:50:09] <uau> however there's no newer ffmpeg-mt version (so you'll lose mt if you use something else)
[16:50:17] <mru> I'm tempted to override echo with something like that actually
[16:50:19] <mru> just to be safe
[16:50:37] <divVerent> printf "%s\n" "$*" should be a pretty good echo override
[16:50:54] <uau> and i think nobody has yet fixed the .pc errors in main ffmpeg repo(s), so static linking against those might fail
[16:50:56] <divVerent> maybe also detect the -n option of echo if you need it :P
[16:50:58] <mru> yes, that should be equivalent to the posix echo
[16:51:05] <mru> -n is not part of the standard
[16:51:12] <divVerent> but needed very often
[16:51:16] <divVerent> but sure
[16:51:22] <mru> printf w/o \n does same
[16:51:28] <divVerent> sure
[16:51:35] <mru> I always use printf if I need anything special
[16:51:36] <divVerent> personally, I'd probably name one of them echo() and the other echo_n()
[16:51:42] <divVerent> always printf is ugly :P
[16:51:48] <divVerent> lots of "%s" for unformatted raw strings
[16:51:56] <divVerent> as printf "Hello World" is considered evil ;)
[16:52:11] <divVerent> ("what happens if someone later changes the string and adds a percent sign")
[16:52:36] <divVerent> but this is what shell functions are for
[17:15:06] <lu_zero> uhmm
[17:15:18] <lu_zero> cross compiling on mingw32 seems to not link anymore?
[17:35:39] <lu_zero> uhm
[17:35:47] <lu_zero> --enable-shared was needed...
[17:36:05] <lu_zero> btw why aren't we using dlltool from mingw32 instead of lib.exe?
[17:38:22] <spaam> ramiro maybe know?
[17:40:52] <kshishkov> yes, FFmpeg needs devil's advocate^W^W Windows porting guy
[18:01:03] <lu_zero> spaam: apparently we got the .lib equivalent as side effect of linking
[18:01:11] * lu_zero dug a bit of mingw32 documentation
[18:01:31] <lu_zero> so I'm not really understanding why those are with different extension and how they should work
[18:01:50] <kshishkov> lu_zero: swscaler is more important
[18:02:07] <lu_zero> kshishkov: let me bisect to see where I did wrong so far =P
[18:02:07] <kshishkov> and if it's clean we may get NEON opts for it
[18:02:42] <kshishkov> lu_zero: take all time you need, just don't be distracted on less important things ;)
[18:03:03] <mru> neon libswscale is something I could probably find a sponsor for
[18:03:11] <mru> but only once the task is palatable
[18:03:22] <mru> or rather, I won't offer to do it until then
[18:03:34] <mru> libjpeg is bad enough
[18:03:37] <kshishkov> iKnow
[18:04:07] <kshishkov> mru: at least you seemed to like those libjpeg7 ideas like scalable coding
[18:26:24] <CIA-38> ffmpeg: Anatoly Nenashev <anatoly.nenashev at ovsoft.ru> master * r7a4abe5912 ffmpeg/libavcodec/mpeg4videodec.c:
[18:26:24] <CIA-38> ffmpeg: mpeg4video: ignore broken GOP headers
[18:26:24] <CIA-38> ffmpeg: Some MPEG4 cameras produce files with empty GOP headers.
[18:26:24] <CIA-38> ffmpeg: This patch makes the decoder ignore such broken headers and proceed
[18:26:24] <CIA-38> ffmpeg: with the following I-frame. Without this change, the following
[18:26:25] <CIA-38> ffmpeg: start code is missed resulting in the entire I-frame being skipped.
[18:26:26] <CIA-38> ffmpeg: Signed-off-by: Mans Rullgard <mans at mansr.com>
[18:28:34] <_av500_> kshishkov: nice one about the sculpting!
[18:28:58] <kshishkov> _av500_: have you been to Oslo too?
[18:29:17] <_av500_> nope
[18:29:17] <mru> seriously, oslo isn't _that_ bad
[18:29:25] <mru> a bit expensive, but not a bad place
[18:29:36] <_av500_> mru: oh, so somebody is wrong on the internet?
[18:29:38] <kshishkov> but it tasteless as Belgian sausages
[18:29:55] <mru> and I don't find brussels all too awful either
[18:30:22] <kshishkov> you live in Britain for too long
[18:30:36] * kshishkov uses Stockholm for reference point
[18:31:38] <kshishkov> mru: and my main point against Brussels is that it reminds me Ukraine too much
[18:32:04] <kshishkov> mru: and I don't know if it's me being lucky but hotel where I stayed at was idiotic
[18:32:20] <mru> which hotel were you in?
[18:32:28] <kshishkov> Mercur
[18:32:55] <mru> mercur are usual alright
[18:33:13] <mru> at least the ones in paris and tokyo were
[18:33:20] <kshishkov> well, I like to have free Internet
[18:33:28] <mru> pick a cheaper hotel then
[18:33:45] <kshishkov> and paying separately for breakfast was something new for me too
[18:34:07] <Flameeyes> kshishkov: hey last year lu_zero had to pay for the towels :P
[18:34:31] <kshishkov> Flameeyes: well, this year they provided paper towels
[18:35:31] <mru> the more expensive the hotel, the more things they charge separately
[18:35:38] <mru> like internet and breakfast
[18:35:51] <kierank> hehe, hotel internet
[18:36:21] <kshishkov> mru: does it have something to do with stars or just country?
[18:36:31] <Flameeyes> yeah last year I spent less by allowing 3 to charge me for the roaming traffic than I would have to get it from the hotel
[18:36:39] <mru> some even charge for shampoo
[18:37:00] <kshishkov> where?
[18:37:09] <mru> I saw that in some 5-star in seoul
[18:37:14] <Flameeyes> (London was more friendly on that note... 3-on-3 → no roaming charges, free internet :D)
[18:37:47] <kshishkov> mru: the only four-star hotel I've ever stayed at was in Sundsvall, every other were three-star
[18:38:13] <kshishkov> mru: and separately paid Internet was in .no, .fi and .be
[18:39:02] <pJok> the hotels i've been to in riga didn't charge extra for wifi
[18:39:29] <mru> up to 3-star it's usually free
[18:39:47] <mru> the more expensive ones figure if you can afford to stay there at all, you can afford to pay for _everything_
[18:39:58] <kshishkov> i.e. RyanAir model
[18:40:07] <mru> not quite
[18:40:08] * pJok isn't going to stay at something higher than 3 stars anyways
[18:40:18] <mru> ryanair at least starts out with a low base price
[18:40:21] <pJok> if you are only going to sleep there, why pay for more than you have to anyways
[18:40:31] <mru> pJok: someone else might be paying
[18:41:07] <pJok> mru, that might change the game.... if you can get them to pay everything including a rental car at least
[18:41:21] <kshishkov> pJok: well, you may find that 4-star hotels abroad may be cheaper than 3-star in København
[18:41:39] <mru> aforementioned korean 5-star wasn't very expensive
[18:41:51] <mru> about £75 per night iirc
[18:41:59] <mru> hotels are cheap in korea
[18:42:12] <pJok> kshishkov, nothing is cheap in copenhagen... though, i've never stayed at a hotel in copenhagen
[18:42:28] <kshishkov> mru: about the same for that hotel in .be
[18:42:37] <pJok> mru, sounds reasonable for a 5 star hotel room
[18:42:52] <pJok> considering that you probably pay that for a 3 star in copenhagen
[18:42:54] <kshishkov> and I payed ~100€ for one night at 3-star hotel in Copenhagen
[18:42:57] <mru> pJok: exactly
[18:43:03] <mru> very central location too
[18:43:28] <pJok> kshishkov, i have at least three places i can sleep in copenhagen if needed
[18:43:46] <mru> the metro station, the park bench, and the police cell?
[18:43:55] <pJok> something like that :D
[18:44:12] <kshishkov> mru: not metro
[18:44:21] <pJok> work has some nice couches, the hackerspace has some couches and friends
[18:44:31] <kshishkov> they have toy metro without benches at stations
[18:44:31] <pJok> in the metro you just get kicked out
[18:44:46] <mru> that's when you move to the park bench
[18:45:51] <kshishkov> and there's Christiania
[20:16:04] <BBB> mru: it seems patchwork doesn't update a patch if I reply a counterpatch in a thread, but also doesn't create a new patch ID
[20:16:17] <mru> it's a bit weird sometimes
[20:17:02] <BBB> can someone review the patch in mmst 2/2 that I wrote?
[20:17:08] <BBB> would be nice to apply that
[20:17:13] <BBB> also the patch in swscale needs review
[20:17:27] <BBB> and my patch to fix compile id 3dnow is not supported by clang
[20:17:30] <BBB> s/id/if/
[20:17:44] <mru> you never updated that after I fixed the deps in configure
[20:17:52] <Sean_McG> how new a version of clang do you need for 3dnow support?
[20:18:05] <mru> 2.9 seems to do the trick
[20:18:29] <Sean_McG> I don't have any AMDs so the question is really just out of curiosity
[20:19:07] <ohsix> they have a simulator
[20:22:44] <mru> there, another compiler bug tracked down
[20:23:13] <mru> av_open_input_stream() of all places
[20:24:53] <Sean_McG> oooh qnx... is this new mru?
[20:25:01] <mru> been there a week or so
[20:25:08] <Sean_McG> must've missed it
[20:26:51] <BBB> mru: I tohught I did... at least locally
[20:26:54] <BBB> I'll resend
[20:29:39] <Sean_McG> it's nice having my gcc version detail on fate
[20:29:42] <Sean_McG> s/my/more/
[20:41:57] <Kovensky> oh, you are running patchwork?
[20:42:38] <Sean_McG> me no, I was just talking about patches.ffmpeg
[20:44:12] <Sean_McG> mru: would I be welcome to join fate.ffmpeg for sunos-gcc-4.6 on i386/x86_64 ? I'd offer sparc too but I tend to shut it down for days at a time (usually only power it on when there's an x264 build to be done)
[20:44:42] <mru> Sean_McG: every contribution is welcome
[20:45:01] <Kovensky> < Sean_McG> me no <-- you_(plural)
[20:45:10] <Sean_McG> OK... who should I talk to for a key?
[20:45:19] <Kovensky> reminds me, I forgot to send my key to mru
[20:45:20] <Kovensky> orz
[20:45:23] <Kovensky> should do that when I'm at home
[20:45:57] <Kovensky> my patchwork question was about <@BBB> mru: it seems patchwork doesn't update a patch if I reply a counterpatch in a thread, but also doesn't create a new patch ID
[20:46:14] <mru> Sean_McG: talk to me
[20:46:19] <Kovensky> are you running patchwork on production, in some closed test or just exploring docs?
[20:46:28] <BBB> I'm not running patchwork
[20:46:31] <mru> Kovensky: patches.ffmpeg.org
[20:47:00] <Kovensky> BBB: damn english language for not having a plural you
[20:47:09] <Kovensky> or for having but being identical to the singular
[20:47:11] <BBB> hh :)
[20:47:15] * Kovensky proclaims the invention of the "yous" word
[20:47:59] <_av500_> ffyou
[20:48:56] <drv> y'all ;)
[20:49:41] <{V}> Kovensky, I think some new york gangsters beat you to that
[20:50:17] <kshishkov> drv: where's our FSV2 decoder?
[20:50:43] <drv> in some git tree on my old disk, rotting away
[20:50:51] <drv> still haven't gotten a real sample yet
[20:51:49] <kshishkov> IIRC it's used for shared screen feature
[20:52:05] <kshishkov> and probably meant for direct streaming from one computer to another
[20:54:01] <drv> yes, i think the ffmpeg encoder patch was based on network dumps of some kind
[20:54:53] <Sean_McG> I was mildly surprised to see the other day that Adobe makes Flash plugin for Solaris... and current builds as well
[21:03:37] <mru> Kovensky: the singular is thou
[21:04:21] * elenril wonders why is his hovercraft full of eels
[21:16:24] <Sean_McG> hmmm I was gonna learn some more Cocoa this afternoon but I think I should try to build ccache first
[21:16:59] <mru> my computer builds glibc in <5min, I don't need ccache
[21:17:06] * _av500_ thinks all cocoa should be shipped to switzerland
[21:17:18] <Sean_McG> ffmpeg build takes over 5 minutes and all the while my fan runs at full crank :P~
[21:17:35] <_av500_> i had a pc like that once too
[21:18:25] <mru> the noisiest parts here are the hard drives and some caps that make noises on usb and/or eth traffic
[21:38:11] <Sean_McG> LOL... "I've had mono so many times it turned into stereo"... Glee is a riot
[21:41:31] <jannau> _av500_: the belgian chocolate wasn't good?
[21:41:50] <mru> ah.. new armcc, new bugs
[21:41:57] <mru> but the old ones are gone
[21:42:01] <Sean_McG> mru: party time! :D
[21:42:14] <mru> now amr and dv are failing
[21:42:25] <mru> used to be vp[56] and roq
[21:42:37] <spaam> Nice
[21:42:47] <spaam> fix some stuff.. get new ones
[21:42:54] <mru> the dv bug isn't actually new
[21:43:57] <CIA-38> ffmpeg: Mans Rullgard <mans at mansr.com> master * r3ad464bfc7 ffmpeg/configure:
[21:43:57] <CIA-38> ffmpeg: configure: fix non-standard regex used with expr
[21:43:57] <CIA-38> ffmpeg: The colon operator of expr always anchors the pattern at the start
[21:43:57] <CIA-38> ffmpeg: of the string. An explicit ^ in the pattern has unspecified
[21:43:57] <CIA-38> ffmpeg: behaviour, so remove it.
[21:43:58] <CIA-38> ffmpeg: Signed-off-by: Mans Rullgard <mans at mansr.com>
[21:45:04] <spaam> segv in  mpeg4als
[21:45:09] <mru> yeah, that too
[21:50:21] <CIA-38> ffmpeg: Francesco Cosoleto <cosoleto at gmail.com> master * r70630e35a4 ffmpeg/libavformat/mmst.c:
[21:50:21] <CIA-38> ffmpeg: mmst: print packet type with error status code message
[21:50:21] <CIA-38> ffmpeg: Signed-off-by: Francesco Cosoleto <cosoleto at gmail.com>
[21:50:21] <CIA-38> ffmpeg: Signed-off-by: Ronald S. Bultje <rsbultje at gmail.com>
[21:50:27] <CIA-38> ffmpeg: Anton Khirnov <anton at khirnov.net> master * r8bf6db1b29 ffmpeg/libavformat/asfdec.c:
[21:50:27] <CIA-38> ffmpeg: asfdec: split reading stream properties out of asf_read_header()
[21:50:27] <CIA-38> ffmpeg: This contains a rename from gsize->size
[21:50:27] <CIA-38> ffmpeg: Signed-off-by: Ronald S. Bultje <rsbultje at gmail.com>
[21:50:29] <CIA-38> ffmpeg: Anton Khirnov <anton at khirnov.net> master * r5cbd3b5d91 ffmpeg/libavformat/asfdec.c:
[21:50:29] <CIA-38> ffmpeg: asfdec: don't export empty metadata
[21:50:29] <CIA-38> ffmpeg: Signed-off-by: Ronald S. Bultje <rsbultje at gmail.com>
[21:50:31] <CIA-38> ffmpeg: Peter Ross <pross at xvid.org> master * r1a973feb45 ffmpeg/libavformat/wtv.c:
[21:50:31] <CIA-38> ffmpeg: wtv: ignore empty data_guid chunks
[21:50:31] <CIA-38> ffmpeg: Signed-off-by: Ronald S. Bultje <rsbultje at gmail.com>
[21:50:35] <CIA-38> ffmpeg: Justin Ruggles <justin.ruggles at gmail.com> master * rfbb6b49dab ffmpeg/libavcodec/ (5 files in 2 dirs):
[21:50:35] <CIA-38> ffmpeg: ac3enc: Add x86-optimized function to speed up log2_tab().
[21:50:35] <CIA-38> ffmpeg: AC3DSPContext.ac3_max_msb_abs_int16() finds the maximum MSB of the absolute
[21:50:35] <CIA-38> ffmpeg: value of each element in an array of int16_t.
[21:50:36] <CIA-38> ffmpeg: Signed-off-by: Ronald S. Bultje <rsbultje at gmail.com>
[22:03:40] <astrange> lu_zero: what threading abstraction?
[22:04:26] * mru shouts at elenril 
[22:25:49] <lu_zero> astrange: w32thread and friends
[22:28:51] <astrange> i'd like w32thraed to go away and be replaced by an implementation of pthread in osdep
[22:29:11] <astrange> but yeah, avcodec_thread_execute doesn't make much sense being in AVCodecContext or lavc
[22:29:19] <mru> I tried to get rid of it a while back but the windows users fought back
[22:29:45] <Sean_McG> fun fun
[22:32:22] <lu_zero> mru: move, not remove =P
[22:33:29] <mru> lu_zero: I know
[22:33:39] <mru> but w32threads should still go
[22:33:46] <mru> there are nice pthreads implementations for windows
[22:34:58] <Sean_McG> having to ship that extra DLL can be a contention point for some
[22:35:20] <mru> they should've thought about that before making a windows app
[22:35:25] <Sean_McG> agreed
[22:35:37] <mru> it comes with the territory
[22:36:09] <astrange> nothing requires them to use a dll, a version with working statics libs is available
[22:36:13] <astrange> -s
[22:36:47] <CIA-38> ffmpeg: Frank Barchard <fbarchard at google.com> release/0.5 * r329e816ed7 ffmpeg/libavcodec/vorbis_dec.c: (log message trimmed)
[22:36:47] <CIA-38> ffmpeg: Check rangebits to avoid a possible crash.
[22:36:47] <CIA-38> ffmpeg: Fixes issue 2548 (and Chrome issue 68115 and unknown CERT issues).
[22:36:47] <CIA-38> ffmpeg: Originally committed as revision 26365 to svn://svn.ffmpeg.org/ffmpeg/trunk
[22:36:47] <CIA-38> ffmpeg: (cherry picked from commit 13184036a6b1b1d4b61c91118c0896e9ad4634c3)
[22:36:48] <CIA-38> ffmpeg: Addresses: CVE-2011-0480
[22:36:49] <CIA-38> ffmpeg: Conflicts:
[22:36:50] <CIA-38> ffmpeg: Reinhard Tartler <siretart at tauware.de> release/0.5 * r04847a06c2 ffmpeg/Changelog: Update Changelog for 0.5.4 release.
[22:36:55] <CIA-38> ffmpeg: Jason Garrett-Glaser <darkshikari at gmail.com> release/0.5 * rd6860fb653 ffmpeg/libavcodec/vorbis_dec.c:
[22:36:55] <CIA-38> ffmpeg: Fix crashes in vorbis decoding found by zzuf
[22:36:55] <CIA-38> ffmpeg: Fixes issue 2322.
[22:36:55] <CIA-38> ffmpeg: Originally committed as revision 25591 to svn://svn.ffmpeg.org/ffmpeg/trunk
[22:36:55] <CIA-38> ffmpeg: (cherry picked from commit 3dde66752d59dfdd0f3727efd66e7202b3c75078)
[22:36:55] <CIA-38> ffmpeg: Addresses: CVE-2010-4704
[22:37:52] <mru> can someone please ack or nak my asfdec fix?
[22:38:44] <siretart> DonDiego: I'd like to do a 0.5.4 release next week. Please let me know if you have anything to add and I missed
[22:40:21] <Dark_Shikari> When will 0.5 die?
[22:40:39] <mru> Dark_Shikari: when siretart no longer wants to maintain it
[22:40:41] <Sean_McG> ask the magic 8ball? ;)
[22:40:57] <Dark_Shikari> Is this like the Windows API?
[22:41:00] <Dark_Shikari> It'll never, ever, die?
[22:41:43] <ohsix> at least they version t heir structures
[22:42:01] <mru> ohsix: you call appending "ex" versioning?
[22:42:12] <Sean_McG> I was gonna say...
[22:43:48] <Dark_Shikari> ohsix: it doesn't actually work that well though.
[22:43:52] <Dark_Shikari> see for example http://git.videolan.org/?p=x264.git;a=commitdiff;h=49e2d55b5834318a4e370dde8829b2e991752bc7
[22:44:06] <ohsix> mru: they added a size field too!
[22:44:30] <Dark_Shikari> In that example, on win64, the wrong struct definition gets used.
[22:44:34] <mru> since when does size matter?
[22:44:45] <ohsix> since windows
[22:45:12] <ohsix> they have fixed packing for the interfaces so size changes are added members
[22:45:23] <ohsix> they add a bunch of padding in real troublesome ones too
[22:45:45] <ohsix> and some of that padding is gr8stuff, used as hidden handles, if you touch them bad things happen
[22:47:26] <DonDiego> siretart: i have nothing queued
[22:47:30] <siretart> Dark_Shikari: it might very well be possible that 0.5.4 will be the last one. mainly depends on how downstreams react and contribute to it
[22:47:38] <DonDiego> gnite
[22:47:44] <siretart> DonDiego: sleep well!
[22:47:49] <Sean_McG> aye, sleep well
[22:48:20] <ohsix> on balance, sleep awful, or don't sleep :D
[22:49:11] <siretart> unbelievable. ffmpeg 0.6.1 did built on the hurd successfully: https://buildd.debian.org/fetch.cgi?pkg=ffmpeg&arch=hurd-i386&ver=4:0.6.1-5&stamp=1297634433&file=log&as=raw
[22:49:48] <ohsix> one less hurdle for its world domination
[22:50:03] <mru> aren't hurd and success mutually exclusive?
[22:50:23] <pJok> siretart, that just means it entered bikeshed country
[22:50:36] <Flameeyes> mru: no that's hurd and usefulness
[22:50:42] <Sean_McG> what does that term mean, "bikeshed"?
[22:50:52] <pJok> you really don't wanna be in bikeshed country once the shed hits the fan
[22:50:54] <mru> Sean_McG: bikeshed.org
[22:50:54] <ohsix> obvious troll is obvious
[22:50:57] <lu_zero> hurd can be a successful playground for concepts
[22:51:18] <lu_zero> so hurd has at least an use
[22:51:33] <ohsix> so does rtems and freertos
[22:52:04] <mru> or L4 or minix or any other such system
[22:52:20] <Sean_McG> or plan9? ;)
[22:52:24] <mru> lol
[22:52:27] <ohsix> l4 is closest
[22:52:43] <ohsix> replacing parts for an experiment is ez
[22:53:12] <mru> that's a nice aspect of microkernels
[22:53:25] <mru> at least if they're done right
[22:53:44] <mru> hmm, what were Kovensky and ruggles doing over there?
[22:54:16] <ruggles> hm?
[22:54:34] <mru> ruggles: you both dropped out and rejoined at the same time
[22:54:40] <mru> probably using the same server
[22:54:54] <ruggles> got a notice to reconnect due to server maintenance
[22:54:55] <Kovensky> 19:51.58 [freenode] -Martinp23(martinp23 at freenode/staff/wikimedia.martinp23)- [Server Notice] Hi everyone! The server you are on (card) will be going down for maintenance in the next few days. This is early warning that you might want to switch to another server in the chat.freenode.net rotation by simply reconnecting to chat.freenode.net. Thanks for using freenode, and if you've any questions join #freenode.
[22:54:59] <ruggles> yeah, that one
[22:55:01] * Kovensky just did /reconnect
[22:55:10] <CIA-38> ffmpeg: Mans Rullgard <mans at mansr.com> master * raabc2682fc ffmpeg/libavformat/asfdec.c:
[22:55:10] <CIA-38> ffmpeg: asfdec: fix build for big endian targets
[22:55:10] <CIA-38> ffmpeg: Signed-off-by: Mans Rullgard <mans at mansr.com>
[22:56:00] <mru> ruggles: I'm losing track of your patch versions
[22:56:21] <mru> could you mark the old ones as superseded on patchwork?
[22:56:56] <Kovensky> is patchwork doing the monkeying or is it just for keeping track of things?
[22:57:00] <ruggles> mru: yes. and one still needs to be resent in order to apply cleanly now.
[22:57:31] <mru> Kovensky: just tracking
[22:57:40] <siretart> good night
[22:57:55] <Kovensky> do you intend to use it for monkeying later on?
[22:59:24] <Sean_McG> night
[23:02:53] <Sean_McG> ooo, looks like vc1 started failing on icc
[23:03:18] <mru> always has
[23:03:22] <Sean_McG> or has this been ... ah OK
[23:03:36] <ruggles> mru: patchwork updated. the only one left has to be updated since the other ac3dsp patch was committed.
[23:03:40] <mru> lines in red have more failures than the previous report
[23:03:52] <mru> ruggles: thanks
[23:17:08] <mru> (gdb) quit
[23:17:09] <mru> Cannot access memory at address 0x7f8
[23:17:11] * mru curses
[23:20:27] * Kovensky ncurses