Ffmpeg-devel-irc

Download

ffmpeg-devel-irc@ffmpeg.org

May 2010

1 participants
29 discussions

IRC log for 2010-05-30
by irc＠mansr.com 30 May '10

30 May '10

[00:08:09] <mru> extra blank line and space before ; [00:11:03] <lu_zero> http://pastie.org/983808 this way? [00:14:01] <mru> drop space before ; [00:15:09] <lu_zero> if check_header netinet/sctp.h; then [00:15:11] <lu_zero> this way? [00:16:29] <lu_zero> the lines below made me think that was the style ^^; [00:54:35] <mru> if you see bad style, send a patch to fix it [00:55:00] <mru> why do people _always_ copy the bad parts [00:55:02] <mru> ? [00:58:27] <Kovensky> at least it isn't a style completely unrelated to the other two :P [01:01:41] <Compn> mru : put it in the developer policy [01:01:49] <Compn> developer rules or whatnot in ffmpeg doc [01:02:25] <lu_zero> mru: I usually keep locality ^^; [01:05:13] <mru> you should FIX locality [01:05:34] <mru> a few lines up it's correct [01:11:14] <lu_zero> I directly looked for netinet so that was my window ^^; [01:11:28] <lu_zero> anyway that like is fixed now [08:32:23] <CIA-93> ffmpeg: diego * r23387 /trunk/LICENSE: The GPL-licensed optimizations in libswscale have been replaced. [09:21:33] <CIA-93> libswscale: diego * r31278 /trunk/libswscale/x86/ (yuv2rgb_mmx.c yuv2rgb_template.c): [09:21:34] <CIA-93> libswscale: Remove GPL-licensed YUV to RGB MMX routines. [09:21:34] <CIA-93> libswscale: We now have an LGPL replacement that is at least equally fast. [09:21:34] <CIA-93> libswscale: diego * r31279 /trunk/libswscale/x86/ (yuv2rgb_mmx.c yuv2rgb_template.c yuv2rgb_template2.c): Rename yuv2rgb_template2.c --> yuv2rgb_template.c now that the other is gone. [11:06:50] <j-b> why isn't 0.6 with libvpx marked as non-free? [11:11:12] <janneg> j-b: siretart wanted to discuss backporting that change first with diego [11:11:52] <j-b> right... [11:11:53] <janneg> I think he hopes that google changes the licence soon [11:12:02] <j-b> and now libvpx is packaged in debian [11:12:08] <j-b> with gstreamer [11:14:54] <janneg> as long as the livpx licence is considered (l)gpl incompatible he can't enable libvpx in debian's ffmpeg [11:25:22] <j^> is there some link to a page outlining what is incompatible? [11:27:00] <j-b> http://mailman.videolan.org/pipermail/vlc-devel/2010-May/075102.html [11:32:15] <lu_zero> uhm [11:32:23] <lu_zero> gst+libvpx is nonfreee... [11:32:37] <lu_zero> I still wonder why those doublestandards... [11:41:24] <j-b> gstreamer0.10-plugins-bad install libvpx [11:44:21] <mru> lu_zero: double standards are the hallmark of freetardism [11:45:58] <lu_zero> well -bad is considered nonfree [11:46:46] <mru> there's a distinction between non-freetard-approved, which can still be distributable, and legally non-redistributable [11:46:47] <lu_zero> or at least the description states that... [11:46:57] <mru> vpx+gpl falls in the latter category [11:47:15] <lu_zero> even vpx+lgpl IF not lgpl3 [11:47:31] <ohsix> only the individual modules need to be internally consistent [11:47:52] <lu_zero> I'm quite sure the version 3 of gpl and lgpl might be considered compatible with vpx [11:47:56] <mru> is gst lgpl or bsd? [11:48:03] <lu_zero> lgpl iirc [11:49:15] <ohsix> then its up to the user to play a file that brings in elements with clashing licenses :D [11:49:44] <mru> freetards usually scream bloody murder over such schemes [11:50:33] <lu_zero> that's why I said double standards [11:50:37] <mru> but I guess somehow vp8 has been declared infallible [11:50:41] <ohsix> that's nothing i've seen [11:50:44] <pross-au> mru: already?! [11:50:52] <mru> it's FREEEEEEEEEEEEEEEE [11:51:03] <mru> google said so, so it has to be true [11:51:03] <pross-au> its no more Free or Free then x264 [11:51:11] <lu_zero> mru: it's better than theora [11:51:15] <mru> and jason is an x264 dev so he can't be trusted [11:51:23] <mru> lu_zero: it is that [11:51:32] <lu_zero> that's important [11:51:45] <lu_zero> and it's not from xiph [11:51:59] <pross-au> any one with half a brain can see that this is an attempt by a company (Google) to own some influence over multimedia standards [11:52:02] <j-b> xiph' vorbis and flac are cool [11:52:15] <mru> flac isn't xiph [11:52:17] <lu_zero> and vpx devs are so far quite open to suggestions and humble [11:52:18] <ohsix> HALF A BRANE!111 [11:52:23] <mru> it was developed outside xiph [11:52:28] <mru> they merely endorse it [11:52:29] <lu_zero> speex and flac got in later [11:52:31] <j-b> vorbis is [11:52:41] <lu_zero> vorbis isn't half bad [11:52:45] <mru> vorbis is pretty good [11:52:48] <j-b> anyway, I don't see why you don't backport the nonfree part [11:52:49] <mru> but it has rough edges [11:52:49] <lu_zero> beside the extradata layout... [11:52:51] <pross-au> at least the xiph promoted codecs are 'open-standards' [11:53:02] <j-b> either it is free for master and 0.6 or it isn't [11:53:11] <lu_zero> pross-au: open-defactowannabe-standard [11:53:12] <j-b> it cannot be free in 0.6 and not in master [11:53:19] <mru> the huge vorbis setup data is annoying [11:53:24] <mru> and the unbounded table sizes [11:55:41] <pross-au> as crap as theora is, at least they tried to improve vp3. [11:55:52] <mru> futile [11:56:01] <pross-au> looks like vp8 is provided as-is. [11:56:05] <mru> a turd is turd no matter how well polished [11:57:04] <pross-au> in that case vp8 is turd? [11:57:15] <pross-au> no bidir frames [11:57:23] <mru> I meant vp3 [11:57:27] <mru> but maybe vp8 is one too [11:57:34] <pross-au> yeah i know. but i am saying the same applies to vp8 [11:57:51] <pross-au> why settle for something less then the best [11:57:51] <ohsix> a turd can be art though http://www.dorodango.com/ [11:57:59] <pross-au> not clicking on that [11:58:26] <ohsix> heh, its just polished mud [11:58:40] <pross-au> dung bettles like turds [11:59:42] <lu_zero> ... [11:59:58] <lu_zero> with vp8 I think the attitude is correct [12:00:28] <pross-au> what attitude might that be? [12:01:30] <lu_zero> they are open to confront and they aren't railing lemmings at you if you say something that's critic towards their work [12:02:30] <jai> pross-au: arent all au supported samplefmts present in av_get_bits_per_sample [12:04:12] <pross-au> jai: it has nothing to do with sample formats, rather bits per sample for a given CODEC_ID [12:04:31] <pross-au> if you try and play a G.721 .au file, ffmpeg just locks up [12:05:01] <mru> your patch looks good [12:05:32] <pross-au> mru: .au one or the configure one [12:05:38] <mru> .au [12:05:49] <mru> I'm not sure about the ffmpeg filter thing [12:06:09] <av500> pross-au: is .au popular in .au? [12:06:17] <pross-au> yeah ill leave that to those more popular with the filtering system [12:06:30] <pross-au> *acquainted [12:06:43] <mru> I don't quite understand what the actual requirement is [12:06:46] <pross-au> av500: you bet [12:07:16] <mru> without the buffer_filter it fails miserably [12:07:18] <av500> mv pross-au pross.au [12:07:21] <pross-au> mru: try ./configure --disable-filters && make [12:07:29] <mru> that won't link [12:07:31] <pross-au> ffmpeg.c does not compile [12:07:35] <mru> I know that much [12:07:54] <jai> hmm [12:08:20] <pross-au> but ./configure --disable-avfilter && make should work [12:08:26] <mru> ok [12:08:26] <jai> pross-au: s/samplefmts/codec ids [12:08:32] <mru> then your patch is probably correct [12:08:42] <mru> although that's debatable [12:08:45] <jai> i guess i'm not reading the code correctly [12:09:33] <mru> but auto-enabling it seems like a good choice [12:09:51] <pross-au> jai: if your still interested, look at libavcodec/utils.c::get_bits_per_sample() [12:10:47] <pross-au> mru: i think michael said he wanted to make libavfilter mandatory to compile ffmpeg. in which case, libavfilter should be added to deps [12:11:04] <mru> we can do that later [12:11:25] <mru> does your patch result in a working ffmpeg in all/most cases? [12:11:40] <pross-au> yes [12:11:48] <mru> then apply it [12:11:58] <pross-au> i am on a slow box and disable everything except the formats/codecs that im working on [12:12:29] <mru> devs need fast machines [12:12:39] <pross-au> 400Mhz is fast [12:12:39] <mru> go get yourself an i7 [12:13:51] <pross-au> is that what you have? [12:14:08] <pross-au> explains your productivity mru [12:14:26] <av500> damn, i have i7 too and not that productivity [12:14:47] <av500> mru must have tuned it [12:14:55] <pross-au> uninstall the games [12:14:59] <jai> pross-au: yeah, i did look at that, i just couldn't understand when exactly the new check you added would be triggered [12:15:10] <pross-au> jai: when the codec is open [12:15:18] <pross-au> jai: when the *FORMAT* is opened [12:19:40] <pross-au> cya (bed) [12:20:17] <CIA-93> ffmpeg: pross * r23388 /trunk/configure: automatically enable buffer_filter when compiling ffmpeg [13:16:00] <siretart> j-b: filed http://bugs.debian.org/583758 [13:16:30] <j-b> k :'( [13:16:51] <j-b> I hate legal [14:51:29] <mru> urgh, these damn MIPS manuals aren't consistent [14:52:56] <mru> at least one of them appears to match the actual hardware [14:54:36] <pJok> if you interleave them, you might be lucky and get something that matches up [16:35:13] <Vitor1001> Dark_Shikari: Any time for a ASM noob? [16:38:28] <Vitor1001> I hacked a SSE float version of dct32() in mpegaudiodec.c. See http://ffmpeg.pastebin.ca/1874356 ... [16:41:32] <Dark_Shikari> Vitor1001: float is boring and hard to do anything really interesting with [16:41:37] <Dark_Shikari> Also, that's a lot of mova/shuf [16:43:49] <pengvado> dct is fft + O(N). any reason you're not delegating to existing code? [16:46:42] <Vitor1001> pengvado: Yes, it's faster in C [16:47:08] <Vitor1001> for size=32, the pre- and post-processing is not negligeble [16:47:46] <Vitor1001> Dark_Shikari: It's always hard to avoid reads and shuffles... [16:47:59] <Dark_Shikari> what are all the shuffles doing, transposes? [16:48:33] <Dark_Shikari> and why do you shuffle twice in each butterfly? [16:50:25] <Dark_Shikari> "01b" looks like a reversal or something? [16:50:29] <Dark_Shikari> *0x1b [16:51:50] <Vitor1001> Dark_Shikari: Yes, it is reversal. [16:52:09] <Vitor1001> Maybe you are right and I can shuffle once... [16:52:14] <Vitor1001> I'll give a second look [16:52:57] <Dark_Shikari> er [16:53:03] <Dark_Shikari> movaps val -> tmp [16:53:06] <Dark_Shikari> shufps tmp -> tmp [16:53:09] <Dark_Shikari> why not do shufps val -> tmp [16:53:45] <Vitor1001> shufps does that? [16:53:57] <pengvado> pshufd does that [16:54:00] <Vitor1001> I think it takes two inputs from the first reg and two from the second. [16:54:32] <Dark_Shikari> Oh [16:54:33] <Dark_Shikari> fuck [16:54:37] <Vitor1001> pengvado: does it works with mmx registers? [16:54:40] <Dark_Shikari> I hate that thing. [16:55:05] <pengvado> no, pshufw works with mmx registers [16:55:06] <Dark_Shikari> pshufd might work [16:55:11] <Dark_Shikari> but time it, it isn't a float op [16:55:51] <Vitor1001> ok, will see. [16:56:48] <Dark_Shikari> Also, you can remove most of your loads from memory [16:56:52] <Dark_Shikari> they're only used for multiply [16:56:55] <Dark_Shikari> so just mulps directly with memory [16:57:29] <Dark_Shikari> the loads from cosine table that is. [16:58:07] <Vitor1001> I see. How much slower is a mul from memory than from a reg? [16:58:28] <Vitor1001> In the second pass I reuse a value twice, so it might not be worth. [16:58:29] <Dark_Shikari> why does that matter? [16:58:31] <Dark_Shikari> oh [16:58:34] <Dark_Shikari> in that case, reuse it [16:58:41] <Dark_Shikari> only do it from mem if there's one load [16:58:44] <Dark_Shikari> er, one multiply per load [16:58:49] <Vitor1001> ok [16:59:28] <Vitor1001> For the parts written in C, I see no obvious way of using sse [16:59:49] <Vitor1001> but the C code is reloading values that are already in registers :p [17:13:39] <CIA-93> ffmpeg: maxim * r23389 /trunk/libavcodec/ivi_common.h: Remove unused variables. [19:00:42] <BBB> how do I see what git push will do? [19:01:07] <BBB> (i.e. how do I do a "svn diff" of my committed changes?) [19:01:16] <twnqx> git diff? [19:01:23] <mru> git log origin..HEAD [19:01:37] <twnqx> oh, locally committed [19:01:47] <mru> that lists the commits that you have but are not in 'origin' [19:04:56] <BBB> mru: thanks (and sorry for my crappy network connection here) [19:05:18] <mru> add -p to see diffs as well [19:05:22] <BBB> git is very interesting, I keep thinking of it as this swiss armyknife that I'm gonna cut myself with repeatedly before getting it [19:05:42] <wbs> BBB: gitx, show all branches, is quite useful too [19:05:54] <Yuvi> it's not a unix tool unless it offers the inevitable equivalent of rm -rf / [19:06:03] <BBB> wbs: I have tried [19:06:07] <BBB> I was a little confused with it [19:06:11] <BBB> git gui seems more useful [19:06:20] <mru> gitk is useful too [19:06:27] <mru> and git gui blame [19:07:02] <BBB> yuvi: just committed something else, I'm at inter prediction now [19:07:10] <wbs> i like the way gitx visualizes branches, and do all the rest via commandline [19:07:48] <BBB> yuvi: I'm sure I will lose my changes a-la rm -fr / at some point [19:07:55] <Yuvi> BBB: nice [19:08:06] <Yuvi> I have intra frames looking like http://i.imgur.com/vF94J.png atm [19:08:19] <BBB> not bad [19:08:31] <BBB> when I tried 2 days ago they looked like red edges on a white background [19:08:55] <BBB> inter doesn't draw anything yet, not sure how long that'll take me [19:09:23] <Yuvi> helps when you don't read chroma coeffs from random places on the stack [19:09:41] <wbs> BBB: there are quite a few safety nets in git actually, but they're not all too obvious :-) [19:09:56] <BBB> wbs: I'm not sure if it's useful if it's hidden [19:10:33] <BBB> imagine being in a traincrash, and there's plasters in the front of the train (the part that was just decimated by it's crash with the other train) [19:11:46] <BBB> Yuvi: also, it doesn't look like that for me [19:11:56] <Yuvi> just pushed some more fixes [19:11:56] <wbs> yeah, but in this case, there's usually someone to ask [19:12:09] <BBB> true [19:12:14] <wbs> knowing how the basic data structures in git works do help a bit [19:12:51] <BBB> yuvi: aha, much better indeed [19:23:55] <hyc> anyone else have ideas on how to condense h264 parsing code for rtp / sdp ? [19:25:10] <hyc> I might try adding a callback to ff_h264_decode_extradata() [19:26:21] <hyc> then I can use that in sdp.c. but overall I don't see a lot of opportunities to re-use existing code. [19:26:38] <BBB> let me look at the patch [19:27:16] <hyc> BBB two choices, this http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20100518/b5cd4… [19:29:06] <BBB> or... [19:29:08] <hyc> and these https://lists.mplayerhq.hu/pipermail/ffmpeg-devel/2010-May/089579.html [19:29:11] <BBB> :) [19:29:11] <hyc> plus the following msg [19:30:01] <hyc> for rtp.c we just need to parse either form of NAL, I think that's no big deal. [19:30:20] <hyc> for sdp.c the format of extradata is quite different in the AVC case [19:30:53] <hyc> maybe adding a callback to ff_h264_decode_extradata() is the right approach. I dunno. [19:31:47] <BBB> so what is the complaint regarding patch#1? [19:31:56] <hyc> too much code duplication [19:34:37] <hyc> and I guess, assuming we refactored it correctly, possibly the solution might be useful elsewhere. [19:35:06] <hyc> for anything else that outputs h264 but expects it in only one form or the other [19:35:37] <BBB> so why can't you force it to be in only one form or the other? [19:35:50] <BBB> if it expects form A, and it gets form B, isn't that the very bug? [19:36:15] <BBB> I'm purely guessing here, but NAL vs. annexB (?) are about as similar as MPEG-4 is to Theora [19:36:33] <BBB> I'm quite sure that if I send MPEG4-style RTP packets using Theora payload-packetization, stuff won't work [19:37:48] <Dark_Shikari> er... [19:37:51] <Dark_Shikari> No, it's the same thing [19:37:58] <Dark_Shikari> annexb = startcode [19:38:01] <Dark_Shikari> mp4-style == sizes [19:38:03] <Dark_Shikari> that's it [19:38:06] <Dark_Shikari> everything else is the same [19:38:29] <BBB> I can see that from the patch [19:38:41] <BBB> but still if the code expects nal, it should get nal, not annexb [19:38:50] <hyc> afk for a few [19:39:06] <BBB> this shouldn't be too hard to force or autodetect in the encoder [19:39:22] <BBB> if it is, we screwed up somewhere [19:39:45] <wbs> BBB: encoder is one thing, stream copy is another [19:40:17] <wbs> and in this case, encoding with libx264 works with our packetizer, but stream copy doesn't, necessarily [19:40:23] <BBB> figure out a solution :) I'm sure it's not that hard, didn't someone bring up bsfilter? [19:41:09] <peloverde_> Whatever happened to autoBSF injection? wasn't there a patch floating around around for it [19:41:27] * mru finds a 33% speed regression in gcc 4.5 compared to 4.3 and 4.4 [19:42:03] <peloverde_> Is that really a surprise? [19:42:16] <mru> it's not usually _that_ bad [19:42:19] <BBB> 33% is quite a lot [19:42:25] <mru> and 4.5 is generally better than 4.4 [19:42:30] <mru> 4.4 was a disaster [19:42:46] <Dark_Shikari> what did it do this time? [19:42:49] <Dark_Shikari> failed vectorization? [19:43:13] <mru> just crap code [19:43:30] <Dark_Shikari> but I mean usually something specific is responsible [19:43:51] <Dark_Shikari> like "can't use the stack properly" [19:43:56] <Dark_Shikari> or "fails at register allocation" [19:44:13] <mru> this looks more like "fails in non-obvious ways" [19:44:17] <Dark_Shikari> ah. [19:44:41] <mru> it's bad, but it's not obvious why it's that bad [19:45:07] <mru> and this was running on cortex-a9 [19:45:16] <mru> which is out of order [19:48:05] <mru> the ooo actually manages to compensate for most of the gcc 4.4 suckiness [19:48:26] <peloverde_> ooo? [19:48:33] <mru> out of order [19:48:50] <peloverde_> ah [19:49:18] <BBB> is ooo like call parallelization? [19:49:36] <mru> like executing instructions not in program order [19:49:51] <BBB> I've seen wince-binaries do that also [19:50:01] <mru> it's a cpu thing, not a binary thing [19:50:04] <mru> suppose you have four instructions a,b,c,d [19:50:05] <BBB> I always wondered if maybe the cpu would run multiple calls in parallel? [19:50:16] <mru> where b depends on the result of a but c does not depend on a or b [19:50:48] <mru> then an in-order cpu would have to wait for A before issuing B and can do nothing else in the meantime [19:51:05] <mru> an out of order cpu can issue C and A in parallel, then B and D in parallel [19:51:28] <BBB> interesting [19:52:39] <mru> and with register renaming it can do this even if they use some of the same registers [19:53:09] <mru> e.g. if A and B use the same destination register [20:07:34] <hyc> BBB: I don't want to use the mp4toannexb bsf because it's a waste. malloc/copy/insert header, then feed to rtpenc which just wants to strip the header [20:09:04] <BBB> uhm... [20:09:09] <BBB> so fix that? [20:09:42] <hyc> IMO there should just be generic parser that works for either format, that everything else uses [20:10:02] <BBB> I read someone (luca?) bring up that "this code might be useful to others that need either one format or the other speciically also", and now you're saying there's a huge performance penalty? [20:10:08] <BBB> that should be fixed, not worked around [20:10:21] <hyc> I don't see how you can fix the bsf. [20:10:30] <hyc> the startcode is always 3 bytes [20:10:42] <hyc> the NAL length size can be 1, 2, or 4 bytes [20:10:59] <hyc> either way, there are combinations where you can't replace one for the other without a malloc/copy [20:11:48] <hyc> instead of a filter that transforms one format to another, you should just have a parser that accepts both formats and tells you the actual position and size of each NAL unit [20:11:55] <hyc> that's what I wrote in my second patch [20:12:37] <hyc> which Luca said was too complicated.... I of course disagree on that ;) but if other people also see it as too complicated, then we need another approach [20:12:55] <j0sh_> BBB: wbs: what d you think about adding a linkedlist (of strings) to httpcontext for custom headers? [20:13:00] <BBB> 1 sec [20:13:54] <wbs> j0sh_: hmmm, I don't know about that, but generally I think the question is what the interface between rtsp and http should be.. that is, should the internals of the http protocol be used directly, or should everything be passed over the normal protocol handling interface (url_open etc) [20:14:17] <BBB> why "strings"? [20:14:19] <BBB> it's 1 string [20:14:29] <j0sh_> we have a couple [20:14:39] <BBB> they're separated by \r\n [20:14:41] <BBB> not \0 [20:14:42] <j0sh_> x-sessioncookie for both, content-type for POST [20:14:46] <j0sh_> true [20:15:08] <BBB> hyc: 1 sec :) [20:15:14] <j0sh_> good point, i suppose it'd make removing them easier if that ever comes up, but just a simple string soinds better [20:15:30] <j0sh_> one tangentially related question: , content-type for POST [20:15:31] <j0sh_> 13:14 < j0sh_> true [20:15:31] <j0sh_> 13:15 <@BBB> hyc: 1 sec :) [20:15:31] <j0sh_> , content-type for POST [20:15:31] <j0sh_> 13:14 < j0sh_> true [20:15:33] <j0sh_> 13:15 <@BBB> hyc: 1 sec :) [20:15:47] <j0sh_> woops [20:16:42] <j0sh_> one tangentially related question: why doesnt rtsp use a urlprotocol structure? [20:16:59] <wbs> j0sh_: because a protocol is a simple byte stream [20:17:16] <wbs> j0sh_: you open it and read one or more bytes. rtsp is a demuxer, since it cannot simply be seen as one single stream of bytes [20:20:39] <BBB> hyc: I honestly think that if there's two formats, then introducing a third "for comptibility sake" goes a tad bit far [20:20:43] <j0sh_> wbs: now that i think of it, my method wouldnt even work with the current url_open, etc, since everything is initialized and the connection is made from that one call [20:20:56] <BBB> hyc: I understand it's frustrating, and it might not be best for performance [20:21:06] <BBB> hyc: but it can't be that terrible either [20:21:12] <DonDiego> Yuvi: will you apply the theora bitexactness thing? [20:21:28] <j0sh_> wbs: makes sense, i was thinking of rtsp as a protocol all along, not a demuxer [20:21:29] <hyc> BBB: I don't see where I'm adding a 3rd format [20:21:31] <hyc> ? [20:22:09] <BBB> "a parser that acceps both formats and outputs [...]" <- something not A and not B, so a new format [20:22:19] <BBB> I might take that a bit far [20:22:24] <BBB> sorry for that :) [20:22:31] <wbs> j0sh_: yeah.. rtsp is a bit more complicated than what fits within the lavf "protocol" definition, but within a muxer or demuxer, you can do almost what you want to within that :-) [20:22:45] <BBB> j0sh_: it's in between, but rtsp doesn't transport a muxed format, but individual elementary streams [20:22:46] <hyc> it doesn't "output" new data, it just tells you the start and stop points of the data you have [20:22:53] <BBB> hence it's easier to implement it as a demuxer [20:23:12] <hyc> which is functionally all these things are doing when they call find_startcode anyway [20:25:11] <BBB> hyc: if that works (i.e. if people are ok with it), it's fine with me, but I'm a little pessimistic... [20:25:54] <hyc> I think the generic parser works pretty well for my patch to rtpenc_h264.c [20:26:23] <hyc> as I mentioned, the extradata parser for sdp.c is still clunky [20:26:41] <BBB> hyc: that's true [20:26:47] <BBB> hyc: I like that part [20:26:58] <BBB> hyc: but it's a lot of new code in avc.c [20:27:12] <BBB> but like I said, if people are ok with it, it's fine with me [20:27:31] <hyc> well so far, only Luca has spoken up, and he's opposed :P [20:27:55] <BBB> who maintains avc.c? [20:27:59] <hyc> I guess it's new code in avc.c, but nothing that it does is particularly new [20:28:04] <BBB> ask that person how he'd do it or 'd like you to do it [20:28:35] <BBB> what's the practical loss of the extra memcpy during bsfilter memcpy? [20:28:38] <hyc> dunno. file header has Baptiste [20:28:40] <BBB> i.e. how much slower is it? [20:30:41] <wbs> that's a bit of a dilemma. generally, michael has been quite strongly against extra memcpys, but using bsfs instead of replicating parsing code in all muxers would be a cleaner solution generally [20:31:07] <BBB> right [20:31:17] <hyc> I haven't profiled it [20:31:32] <hyc> but I'm concerned since I'm using this for realtime transcode of rtmp to rtsp [20:31:43] <hyc> and the transcode already takes 100% of CPU [20:32:33] <BBB> I wonder how much of that is useless loops like that one in ffserver.c [20:32:35] <hyc> and if we have a nice generic parser that can be called as needed, that still avoids the code duplication [20:32:53] <BBB> right, but if the 100% is an issue, then profile it and look at stuff on top [20:33:12] <hyc> yeah, good point [20:33:28] <BBB> my feeling is you're looking at the wrong place, memcpy()s can be expensive when overused, but I'm unsure if they'd bring it back from 100% to something significantly below [20:33:48] <hyc> malloc is the bigger problem [20:33:54] <BBB> (not that it isn't a valid point, but it's not what causes the 100%) [20:34:09] <hyc> memcpy is a waste, but not as much of a pig as malloc [20:34:36] <hyc> and also, I want this to work well on my G1. any unnecessary cyles means lost battery life [20:34:57] <BBB> I'd suggest to profile it so you can see what actually takes most of that [20:35:14] <BBB> malloc might well be on top, but maybe it's something completely different, like a fscked-up ffserver.c loop or so :) [20:35:37] <wbs> j0sh_: generally, the question is how to pass custom options to different url protocols. currently, there's no other way than adding custom "query string parameters", look e.g. at the rtp and udp protocols how they do it [20:35:54] <wbs> j0sh_: but the problem there is that for http, it could clash with an actual parameter that was intended as part of the url [20:36:08] <hyc> right. ok, it ebears further investigation then [20:36:34] <wbs> j0sh_: e.g. http://server/path?customheader=x-sessioncookie... [20:37:08] <j0sh_> wbs: didnt realize query strings could conflict with http headers [20:37:20] <wbs> j0sh_: not with http headers as such [20:37:48] <wbs> j0sh_: but if the http protocol is faced with such an url, how do you know that that's actually an lavf-internal custom header that should be stripped off, instead of sent as part of the actual request? [20:38:03] <j0sh_> wbs: i see what you mean [20:38:33] <j0sh_> wbs: appending some custom query to the http url for internal use [20:39:00] <wbs> j0sh_: exactly [20:39:28] <wbs> j0sh_: the udp and rtp protocols use it for some purposes at the moment, but in those cases there's no normal use of query string parameters so there's no conflict [20:39:40] <j0sh_> maybe if we prefixed it with something that's unlikely to show up, like LIBAV_ or something [20:39:53] <wbs> perhaps [20:40:38] <BBB> j0sh_: that's hacky [20:40:53] <BBB> j0sh_: for internal use, we have some private rtp_*() functions called in rtsp.c [20:41:04] <BBB> I wouldn't completely mind having similar http_*() functions [20:41:11] <BBB> it'll require some refactoring [20:41:12] <j0sh_> i'll take a look at those [20:41:26] <BBB> e.g. url_open("http://"); [20:41:40] <BBB> then http_set_headers(url, "Content-Type: blabla\r\n"); [20:41:43] <BBB> then get data [20:41:49] <BBB> (and add some code so it does a delayed open [20:41:50] <BBB> ) [20:42:01] <BBB> but it'd of course be better if you added proper option handling [20:42:23] <BBB> e.g. url_open(const char *url, int flags, something options); [20:42:25] <j0sh_> yeah, url_open immediately connects right now [20:42:37] <j0sh_> so theres no way to add a header beforehand [20:42:41] <BBB> right [20:42:44] <BBB> rtp:// doesn't do that [20:42:47] <BBB> so look at that [20:42:52] <BBB> http:// can be changed, if needed [20:43:10] <j0sh_> alright [20:43:27] <wbs> BBB: rtp is udp, which is connectionless, so it doesn't "connect" on url_open [20:43:34] <j0sh_> wouldnt new parms for url_open be a big change [20:44:04] <BBB> j0sh_: yes, but it's long overdue [20:44:04] <wbs> yeah, but e.g. a general flag like URL_DELAYOPEN perhaps would be accepted [20:44:11] <BBB> we've discussed it repeatedly [20:44:28] <BBB> imagine that "force http" or "force udp/multicast" could be options for rtsp protocol [20:44:34] <BBB> right now we don't really have options like that [20:44:40] <j0sh_> only 19 occurrences of url_open accordng to cscope so thats manageable [20:44:53] <BBB> you'd introduce a new function url_open2() [20:44:57] <BBB> never change api :) [20:45:08] <j0sh_> heh alrght [20:45:29] <wbs> also, url_open is in the public api, can only be removed at a major bump [20:46:01] <j0sh_> gotcha [20:46:36] <BBB> look at AVOptions [20:46:49] <BBB> the idea was always to use AVOptions to specify private options for protocols [20:47:33] <wbs> isn't it an issue that AVOptions requires the struct to be an AVClass, and URLContext isn't (until the next major bump?) [20:47:54] <BBB> don't ask me exactly how it'd work, but probably like url = url_alloc(); av_set_option(url, "extra_headers", "content-type=...\r\n"); url_open(url, "http://..."); [20:47:55] <BBB> or inverted [20:48:14] <BBB> if we need to bump abi, then we need to bump abi [20:48:19] <BBB> this stuff is long overdue [20:48:24] <wbs> true [20:48:30] <BBB> but it's true, might be too early [20:49:10] <BBB> j0sh_: easiest might be the delayed-connect and then use a private http_set_request_headers() function [20:49:19] <BBB> j0sh_: that should be relatively easy, and would be OK with me [20:49:26] <BBB> j0sh_: just document the function properly [20:49:48] <j0sh_> BBB: private == ff_? [20:49:49] <j0sh_> will do [20:49:58] <BBB> private is "not part of external api" [20:50:08] <BBB> ff_http_* probably, yes [20:50:09] <j0sh_> yeah [20:52:36] <BBB> gotta go now :) [21:17:21] <hyc> and the other side of this - if the big problem is only with the sdp.c patch, it's kind of a who-cares thing. sdp processing is not performance-critical, it only happens once at the beginning of any session [21:17:51] <hyc> while the rtpenc_h264 patch affects every frame of data... [21:21:49] <hyc> 1-3 months feels like the right time scale for releases... [21:22:55] <mru> yes, 1-3 months per year or two [21:23:00] <j0sh_> lol [21:26:17] <DonDiego> 1 year is better though [21:28:04] <Dark_Shikari> I like the 1 hour timescale [21:28:06] <Dark_Shikari> do a new release every hour [21:28:49] <mru> you'll have to have a pipelined release team to manage that [21:29:27] <Dark_Shikari> no, you just svn commit often [21:29:48] <mru> depends on what you require to call something a release [21:30:20] <mru> just wait until you work for a large company [21:30:25] <mru> doing a release takes half a year [21:30:43] <DonDiego> however [21:30:51] <DonDiego> it just takes a few minutes to bitch [21:30:55] <mru> meaning it's obsolete before even _one_ user gets his hands on it [21:30:56] <DonDiego> so everybody bitches.. [21:34:29] <mru> "7.6 Almost Alphabetically-ordered table of DSP ASE instructions" [21:37:00] <KotH> night boys and girls [21:37:10] <mru> girls? where? [21:46:45] <DonDiego> siretart: you around? [21:47:01] <siretart> DonDiego: about to fall asleep [21:47:13] <mru> better than falling apart [21:47:32] <DonDiego> were janne's patches for experimental encoders already applied? [21:50:55] <siretart> no, I guess he's waiting for someone to apply, IIRC they were already acked [21:51:44] <DonDiego> maybe janne should start applying his own patches? [21:51:45] <janneg> yes, I'm waiting for someone to apply the last two [21:52:16] <siretart> you got your OK from michael, what are you waiting for? ;-) [21:53:11] <janneg> I wouldn't mind commit rights and try to work as patch monkey [21:55:21] <janneg> waiting for someone to apply ok-ed patches is frustrating and I fear we miss to apply some if the submitter is not persistent enough [22:01:43] <DonDiego> janneg: you will have to publically accept the project policy [22:05:17] <DonDiego> janneg: suggestion to make you a committer sent [22:05:46] <DonDiego> janneg: i will disappear tomorrow, prod KotH or mru to give you an account if i am not around [22:05:55] <DonDiego> all assuming that you agree to the dev policy [22:06:01] <DonDiego> and michael gives his ok [22:10:38] <janneg> DonDiego: sure, I'm reading it now [22:16:09] <janneg> DonDiego: there are at least two '@xref{...}' in http://ffmpeg.org/developer.html. are that typos or missing functionality in texi2html? [22:16:42] <DonDiego> i don't understand [22:17:36] <DonDiego> Yuvi: note that the xiph people are already complaining about the spec not being followed.. [22:19:48] <janneg> DonDiego: I would expect instead of a literal '(@xref{Coding Rules})' a <a href="...#SEC_CODING_RULES">Coding Rules</a> [22:26:32] <CIA-93> ffmpeg: diego * r23390 /branches/ (0.6 0.6/configure): [22:26:32] <CIA-93> ffmpeg: Require --enable-nonfree flag for libvpx. [22:26:32] <CIA-93> ffmpeg: The license of libvpx is incompatible with the (L)GPL. As long as this is [22:26:32] <CIA-93> ffmpeg: the case, the only way to use it is by marking the result as nonfree. [22:26:32] <CIA-93> ffmpeg: backport r23371 by diego [22:28:56] <DonDiego> janneg: indeed, something is amiss there.. [22:36:53] <DonDiego> gnite [22:37:19] <spaam> good night DonDiego [22:37:54] <janneg> DonDiego: it's ok with my texi2html version [22:37:59] <janneg> good night [22:39:01] <DonDiego> i was suspecting something like this.. [22:39:04] <DonDiego> what is your version? [22:39:19] <DonDiego> oh, i remember [22:39:20] <janneg> I suspect the one used on natsuki is too old/buggy. the texi2html homepage has moved to nongnu.org [22:39:41] <DonDiego> yes, it's an old version that i keep around on purpose [22:39:45] <janneg> 1.78 [22:40:05] <DonDiego> unfortunately only that old version produces the neat layout that we use.. [22:40:43] <DonDiego> patches welcome [22:41:03] <DonDiego> i'm at the end of my wisdom there.. [22:41:18] <DonDiego> i use 1.56k [22:41:28] <DonDiego> it's an old version.. [22:41:57] <janneg> yes, my version has navigation elements below each section and soesn't look pretty [22:42:45] <DonDiego> exactly.. [22:43:02] <DonDiego> if you find a version that produces nice layout without those bugs - i'm all ears.. [22:52:18] <janneg> DonDiego: --init-file=/usr/share/texi2html/noheaders.init looks good with 1.78 [22:52:41] <janneg> the TOC at the top of the page is still missing [23:09:23] <DonDiego> ok, that surely points in the right direction [23:09:24] <DonDiego> thx [23:09:37] <DonDiego> ok, i'm off to bed now, gnite [23:58:40] <CIA-93> ffmpeg: maxim * r23391 /trunk/libavcodec/ivi_common.c: Make dequantization equation use less registers on some CPUs.

1 0

IRC log for 2010-05-29
by irc＠mansr.com 29 May '10

29 May '10

[00:03:52] <BrknCodes> Anyone notice that vp6 support is broken on Generic Big Endian machines, since around Christmas 2009? [00:04:01] <BrknCodes> (decode) [00:04:34] <DonDiego> generic as in? [00:04:37] <DonDiego> sample? [00:04:47] <BrknCodes> as in (powerPC, no altivec) [00:05:09] <BrknCodes> as in (MIPS BE, NXP 8635) [00:05:18] <DonDiego> hmm [00:05:23] <kierank> let google fix the bugs ;) [00:05:31] <DonDiego> i have a g4, i could test [00:05:33] <BrknCodes> same issue in both CPU's [00:05:42] <BrknCodes> G4 has an altivec... [00:06:05] <BrknCodes> STB4100 however does not [00:06:40] <BrknCodes> neither does IBM STB 250 [00:07:18] <DonDiego> sample? [00:07:28] <BrknCodes> define sample please [00:07:46] <DonDiego> sample == file that triggers the problem [00:07:49] <BrknCodes> yes [00:07:53] <BrknCodes> where to upload? [00:07:59] <DonDiego> incoming [00:08:00] <BrknCodes> want on tinyupload.com? [00:08:01] <DonDiego> or wait [00:08:29] <DonDiego> http://samples.ffmpeg.org/V-codecs/VP6/ [00:08:31] <DonDiego> first [00:08:44] <DonDiego> see if one of the ones we already have triggers it as well [00:09:21] <BrknCodes> I will test predator2_vp6HuffyYuv [00:09:46] <BrknCodes> will take less than 3 mins [00:09:53] <DonDiego> os x or linux? [00:10:26] <mru> vp6 is fine here: http://fate.multimedia.cx/index.php?build_record=232160 [00:10:28] <BrknCodes> baremetal [00:10:37] <mru> that BE with no special asm [00:11:29] <mru> pa-risc is BE too [00:11:48] <mru> and sparc of course [00:13:06] <BrknCodes> problem that occurs, is that it destroys all the intra frames, causing "bleeding" and color effects [00:13:49] <BrknCodes> it runs, just fine, however, it is unwatchable, except for a few frames after each keyframe [00:14:21] <BrknCodes> dont know if this would be detected by the FATE system? [00:15:00] <mru> fate verifies a checksum of the decoded frames [00:16:47] <BrknCodes> so, is there a "recomended" config for my SOC that will curb this effect? or should I go back to #ffmpeg? [00:17:05] <mru> I'm not aware of a bug [00:17:30] <BrknCodes> if I assumed you were aware, mru, I would not be here trying to report it :) [00:17:42] <Compn> BrknCodes : run the make test or whatever that fate runs to verify vp6 [00:17:49] <BrknCodes> miss talking to you on #beagle [00:17:52] <mru> I played several vp6 files on x86 a couple of days ago, and they all seemed fine [00:18:05] <BrknCodes> x86 is not generic, nor is it BE [00:18:29] <mru> what I mean is that vp6 decoding seems ok there at least [00:18:47] <mru> and fate hasn't complained [00:19:13] <mru> it's possible of course that the samples tested there don't trigger the bug [00:19:21] <lu_zero> you can run make test on your bare metal? [00:19:32] <BrknCodes> no, I cannot [00:19:48] <mru> hold on, I'll do a no-asm build on ppc and check [00:20:11] <BrknCodes> is there a configure option for no-asm? [00:20:18] <mru> --disable-asm [00:20:34] <BrknCodes> although, I dont see any asm in vp6.c, or vp56.c [00:20:44] <mru> you wouldn't [00:21:05] <mru> they use the vp3 idct [00:21:10] <mru> which does have asm versions [00:24:39] <DonDiego> seems to work fine here with altivec.. [00:27:05] <BrknCodes> DonDiego Look above, I said "Without Altivec" [00:27:26] <BrknCodes> :D [00:29:24] * Dark_Shikari is headdesking [00:29:31] <Dark_Shikari> reading the A119 h265 proposal software here [00:29:39] <Dark_Shikari> it has a separate copy-pasted function for every single block size comparison [00:29:44] <Dark_Shikari> i.e. sad 16x16, 16x8, 8x16... [00:29:44] <BrknCodes> I have been bashing my head for 8 days over this issue [00:29:49] <Dark_Shikari> every single one has a 10 line function header comment [00:29:54] <Dark_Shikari> i.e. function, purpose, input, return, parameters [00:30:02] <Dark_Shikari> yes, every single one has a separate "purpose" line [00:30:08] <Dark_Shikari> and it goes on and on and on and *GAH* [00:30:08] <mru> corporate policies gone mad [00:30:10] <BrknCodes> umm [00:30:58] <Dark_Shikari> here's a good one [00:31:07] <Dark_Shikari> http://pastebin.org/289029 [00:31:10] <Dark_Shikari> explain to me what "FAST_MODE" does. [00:31:34] <Dark_Shikari> and what kind of drugs the author of this function is on. [00:31:52] <BrknCodes> Item: Bicycle Fuction: Mode of Transportation Purpose: Get ya there with no fuel Input: Pedals Return: Forward Motion Input: Steering bar (Handlebar Struct) [00:32:24] <kierank> Dark_Shikari: LOL [00:32:57] <Dark_Shikari> FAST_MODE [00:33:02] <kierank> who needs SIMD when you can have FAST_MODE [00:33:03] <BrknCodes> fast mode is 64+64 iterations, non is 64*64 iterations [00:33:03] <mru> copy the line out before calculating the sad? [00:33:05] <mru> wtf? [00:33:48] <Dark_Shikari> some of them use memcpy! [00:33:54] <BrknCodes> so, 128, or 4096, pick and choose [00:34:02] <kierank> "Clean and fast software written from scratch using C" [00:34:04] <mru> BrknCodes: what are you talking about? [00:34:13] <Dark_Shikari> kierank: is that an actual quote? [00:34:14] <mru> both calculate the same thing [00:34:21] <mru> FAST_MODE with an extra "memcpy" [00:34:43] <kierank> yes from the powerpoint [00:34:55] <Dark_Shikari> LOL [00:35:05] <DonDiego> BrknCodes: can you reproduce with one of our samples? [00:35:15] <mru> fate passes w/o asm on my ppc [00:35:16] <BrknCodes> umm, fast_mode appears to take longet to me, iteratively [00:35:34] <Dark_Shikari> THATS THE POINT [00:37:14] <kierank> disappointingly they've left track changes on the proposal documents but there doesn't seem to be a history [00:37:56] <BrknCodes> test samples work [00:38:38] <BrknCodes> my test.flv, however does not, and I have several samples which dont [00:38:45] <BrknCodes> some AVI, some FLV [00:38:52] <mru> upload one [00:38:58] <BrknCodes> link for upload? [00:39:32] <bcoudurier> why doesn everybody misinterpret bt601/709 and full/normal range yuv [00:39:43] <mru> upload.ffmpeg.org [00:39:48] <BrknCodes> found upload.ffmpeg.org [00:39:54] <mru> bcoudurier: because they know nothing about the subject [00:40:45] <bcoudurier> yeah, and somebody will blog crap and it will get worse [00:41:45] <BrknCodes> uploading test.flv [00:41:57] <BrknCodes> 9 years, 37 days remaining [00:42:46] <Dark_Shikari> oh wow. the comments are mispelled too [00:42:52] <Dark_Shikari> "Check whetehr SVT mode should be skipped" [00:43:23] <BrknCodes> LOL [00:44:40] <BrknCodes> 4 years remaining [00:45:51] <hyc> wbs: you don't happen to have a copy of iSO/IEC 14496-10:2005 online too do you? [00:46:16] <mru> hyc: why such an old version? [00:46:20] <Dark_Shikari> here's another great representative 5 lines from the A119 software [00:46:21] <Dark_Shikari> { [00:46:22] <Dark_Shikari> { [00:46:23] <Dark_Shikari> { [00:46:27] <Dark_Shikari> (two extra line breaks omitted) [00:46:34] <hyc> mru: I guess the particular version doesn't matter [00:46:51] <hyc> I was just trying to understand the format of sps/pps encoded in SDP sprop-parameter-sets [00:48:09] <mru> http://www.itu.int/rec/T-REC-H.264-200903-S/en [00:48:15] <mru> grab your free copy there [00:48:29] <hyc> ah found it. 03/09 ? [00:49:45] <hyc> mru: thanks [00:50:03] <BrknCodes> file uploaded, in incoming folder, "test.flv" [00:50:05] <hyc> so it looks like sprop-parameter-sets is SPS,PPS [00:50:25] <BrknCodes> works fine on x86, fails on every generic BE machine I have here [00:50:43] <hyc> if a stream has multiple spss then they should all be concatenated into that first part? [00:50:45] <BrknCodes> which is 6 different machines, including 3 Mips BE [00:51:37] <kierank> Dark_Shikari: mixed tabs and spaces all over the place too [00:52:22] <kierank> eugh and random unformatted tables [00:54:21] <DonDiego> BrknCodes: test.flv is not exactly a great name.. [00:56:11] <BrknCodes> ok [00:56:47] <DonDiego> please either use a name that describes the problem or the sample [00:58:29] <lu_zero> hyc: you might also send them inline [00:58:42] <hyc> is there a sample H.264 file with multiple SPSs and/or PPSs? Most of the ones I've seen have only 1 of each [01:00:39] <BrknCodes> uploading "vp6_intra-frame_fail_BE_Generic.flv" [01:00:51] <mru> you don't need to upload another [01:01:03] <BrknCodes> he told me to rename, cannot rename [01:01:05] <mru> and I can't reproduce the problem [01:01:08] <hyc> lu_zero: just trying to make sure when I encode an AVC extradata in rtpenc_h264.c that it still makes sense [01:01:12] <BrknCodes> Canelled [01:01:24] <mru> still no need to upload several copies of the same file [01:01:30] <BrknCodes> gotcha [01:01:42] <BrknCodes> next time, I name correctly before to make upload [01:02:11] <mru> however, I still can't reproduce the error [01:02:30] <BrknCodes> shame [01:02:47] <mru> which means pebkac for you [01:02:54] <mru> most likely [01:02:55] <BrknCodes> STB4100 is based on PowerPC 750CL [01:03:03] <BrknCodes> all other codecs work fine [01:03:11] <mru> ppc is ppc [01:03:13] <lu_zero> mru: do not factor out the compiler [01:03:21] <mru> I used gcc 4.3 [01:03:31] * lu_zero still reminds some funny typos in the ancient ones... [01:03:32] <BrknCodes> I am using gcc 4.4.3 [01:04:04] <BrknCodes> same issue on 4.4.2 [01:04:18] <lu_zero> cflags? [01:04:36] <mru> defaults I hope [01:04:41] <mru> otherwise he's wasting our time [01:05:31] <hyc> hmm. av_base64_encode() ought to return pointer to end, not pointer to beginning of output [01:05:45] <hyc> you passed in the pointer to out, you don't need it back again [01:06:19] <hyc> returning the pointer to end of output would let callers calculate len without wasting a call to strlen() [01:07:19] <BrknCodes> -MD -MP -Wstrict-prototypes -Wmissing-prototypes -Wundef -Wdisabled-optimization -Wno-pointer-sign -Wdeclaration-after-statement -std=gnu99 -Wall -Wno-switch -Wpointer-arith -Wredundant-decls -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -mpaired -ffast-math -I. -Wdeclaration-after-statement -Wall -Wno-switch -Wpointer-arith -Wredundant-decls -g -O3 -pipe -mrvl -mcpu=750 -mtune=750 -meabi -mhard-float [01:07:49] <mru> that doesn't look like our flags [01:07:59] <mru> works with 4.4.3 here [01:08:14] <mru> so WHY DID YOU MESS WITH THE FLAGS? [01:08:32] <BrknCodes> will not build for my baremetal without them [01:08:40] <mru> of course it will [01:08:47] <mru> get rid of -ffast-math to begin with [01:08:54] <BrknCodes> no help [01:08:59] <mru> and put back -fno-tree-vectorize [01:09:07] <BBB> we need this on the quotes page [01:09:30] <mru> I see nothing funny [01:12:08] <mru> and what's -mrvl? [01:12:41] <BrknCodes> Broadway, testing on Wii, cuz is closest to the board, without having to TFTP [01:12:55] <mru> uh? [01:13:24] <BrknCodes> -mrvl, enables wii linking [01:13:28] <BrknCodes> nm [01:13:31] <BrknCodes> not important [01:13:37] <mru> you don't know that [01:13:51] <BrknCodes> dont know what "not important" [01:13:53] <BrknCodes> ?? [01:14:00] <j0sh_> lu_zero: how should the client specify they want tunnelled http? do we need a new option for that? [01:14:01] <mru> obviously you don't [01:14:07] <mru> if you did, you'd have fixed it by now [01:14:22] <BrknCodes> ok... [01:14:35] <AbuseMePls> is that better? [01:15:05] <mru> good riddance [01:15:44] <BBB> j0sh_: same as ?tcp or ?udp [01:15:47] * lu_zero abusemepls please also drop -mpaired [01:15:48] <BBB> ?http would be good [01:15:57] <lu_zero> sad but true =_= [01:15:58] <mru> lu_zero: he ran away [01:16:14] <lu_zero> mru: and I mistyped [01:16:20] * lu_zero feels sleepy [01:16:21] <mru> I have no desire to help people who insist on stupid cflags [01:16:24] <kierank> i wonder what he's up to doing vp6 on the wii [01:16:26] <DonDiego> gnite [01:16:41] <mru> I had enough when a customer insisted we use -mbig-endian -mlittle-endian [01:16:48] <mru> or something like that [01:16:59] <lu_zero> mixedendian missing? [01:17:32] <lu_zero> on 64bit would it cause have the first 32bit big and the second little? [01:17:38] <mru> I asked which one was correct, they said we were to use both [01:17:41] <mru> we did, it broke [01:17:51] <hyc> lol [01:17:55] <lu_zero> that's evil =P [01:17:58] <hyc> The Customer Is Always Wrong [01:18:01] <mru> but which order would the high/low words have? [01:18:23] <Dark_Shikari> so mru [01:18:31] <lu_zero> probably they had a cpu that worked better as le and one as be of the same arch ^^; [01:18:37] <Dark_Shikari> we need to decode 1024x768 video on an ipad in about 23ms or less in motion [01:18:41] <Dark_Shikari> i.e. not with a static screen [01:18:50] <Dark_Shikari> Sorenson FLV1 takes about ~34ms with ffmpeg in motion [01:19:03] <Dark_Shikari> so my next challenge is to hack it until it takes less than 23ms [01:19:07] * Kovensky wonders how many WTFs are on TDWTF's source code [01:19:11] <mru> find something that's close and optimisable, then throw me some cash ;-) [01:19:12] <Dark_Shikari> Besides swapping out the transform, any ARM-specific optimizations you can think of? [01:19:25] <Dark_Shikari> i.e. modifying the video format to make it faster. [01:19:47] <lu_zero> that cpu doesn't have any accelerator you could use beside relying on neon? [01:19:57] <mru> lu_zero: not accessible [01:20:07] <lu_zero> neon or the accelerators? [01:20:10] <Dark_Shikari> latter [01:20:11] <mru> accels [01:20:16] <Dark_Shikari> we may get it in time [01:20:18] <Dark_Shikari> But not fast enough. [01:20:23] <Dark_Shikari> er, not soon enough [01:20:53] <mru> do you have a sample file? [01:20:59] <mru> I can do a quick profile [01:21:13] <Dark_Shikari> one moment [01:21:40] <lu_zero> the gpu could be abused ? [01:22:30] <Dark_Shikari> that would be a ton of owrk [01:23:45] <lu_zero> the color conversion/scaling is already managed through the native scaler? [01:24:00] <Dark_Shikari> we do it in opengl [01:24:01] <Dark_Shikari> yes [01:24:04] <Dark_Shikari> mru: http://x264.nl/developers/Dark_Shikari/output.flv [01:24:08] * mru thinks people should learn to see in yuv [01:24:20] <Dark_Shikari> That's a representative "hard" sample [01:24:30] <ohsix> braintap yub [01:24:33] <Dark_Shikari> i.e. "this is the hardest footage we will have to handle in realtime" [01:24:37] <Dark_Shikari> It's not the right resolution but whatever [01:24:49] <lu_zero> so you already are using some of the gpu [01:25:56] <Dark_Shikari> yeah, but that's easy [01:32:19] <kierank> could an ARM926 decode 700kbps h.264? [01:32:39] <kierank> i'm wondering how iplayer wii manages to decode 700kbps h.264 [01:32:52] <mru> no way [01:33:15] <mru> probably has some hardware support [01:33:17] <Dark_Shikari> yes, hardware [01:33:21] <Dark_Shikari> wii doesn't even have altivec [01:33:42] <Dark_Shikari> got a profile yet? [01:33:50] <kierank> because the bbc blog post says it was done on the cpu and 700kbps was their upper limit and they tweaked their encoding profile [01:34:03] <mru> Dark_Shikari: yeah [01:34:09] <mru> idct is quite a bit [01:34:18] <Dark_Shikari> link? [01:34:19] <mru> and dequant [01:34:32] <Dark_Shikari> interesting that _dequant_ is a lot [01:35:10] <mru> yeah, it's usually much less [01:37:11] <Dark_Shikari> ... link? [01:37:22] <mru> to what? [01:37:53] <Dark_Shikari> the profile [01:38:41] <mru> http://pastebin.com/WftRrss8 [01:39:09] <Dark_Shikari> armv5te?!?! [01:39:13] <mru> what weird settings did you encode with? [01:39:22] <Dark_Shikari> -B 6000000 [01:39:26] <Dark_Shikari> er, -b [01:39:26] <mru> that function is usualy insignificant [01:39:35] <Dark_Shikari> why would it be insignificant? [01:39:38] <Dark_Shikari> it's run before every single idct [01:39:45] <mru> <1% is insignificant [01:39:51] <Dark_Shikari> that sounds like your bitrate is really low [01:40:02] <Dark_Shikari> 13%+ spent on dequant is huge [01:40:06] <mru> yes [01:40:07] <Dark_Shikari> you think you could make that faster in neon? [01:40:10] <mru> never seen that before [01:40:15] <mru> I'll try a neon version [01:40:21] <mru> should be easy [01:40:22] <Dark_Shikari> should be easy, yeah [01:40:24] <Dark_Shikari> quant is trivial [01:40:43] <Dark_Shikari> amazing how much idct uses up [01:40:51] <Dark_Shikari> how much faster would h264 idct be? [01:41:06] <mru> quite a bit I imagine [01:41:23] <mru> the mpeg2/4 idct has to use 32-bit maths [01:41:35] <mru> and multiplication [01:41:49] <Dark_Shikari> like, 2x? 3x faster? [01:42:12] <mru> I honestly don't know [01:42:19] <Dark_Shikari> k [01:44:39] <kierank> interesting...the wii has it's own video format as well [01:44:51] <mru> wiideo [01:45:49] <Dark_Shikari> so lets see here [01:46:10] <Dark_Shikari> 11.87% + 7.93% + 5.8% + 3.69% + 2.81% + 2.15% [01:46:11] <Dark_Shikari> holy crap [01:46:19] <Dark_Shikari> 35% of time is the idct. [01:46:32] <Dark_Shikari> what's put_dct? [01:46:35] <mru> it's usually <20% [01:46:45] <mru> I don't know what put_dct is [01:46:46] <Dark_Shikari> yeah, it's because every single block has a residual [01:46:49] <Dark_Shikari> EVERY single block [01:47:08] <Dark_Shikari> due to high motion [01:47:20] <mru> I should go back over that dct, maybe there's something I can improve [01:49:07] <Dark_Shikari> Yeah, 35% of time seems unreasonably high [01:49:16] <Dark_Shikari> though I guess multiplies suck on neon [01:49:23] <Dark_Shikari> what's the latency/throughput like on typical 32-bit multiplies? [01:49:26] <mru> they should all be 16x16 [01:49:30] <mru> with 32-bit result [01:49:50] <Dark_Shikari> so what's latency/throughput on those [01:50:33] <mru> 5/1 [01:50:42] <Dark_Shikari> that sounds like a bitch to schedule [01:50:49] <mru> it is [01:51:19] <mru> as I said, I might revisit the idct [01:51:40] <Dark_Shikari> what are the different parts for? [01:51:42] <Dark_Shikari> e.g. "pld" [01:52:04] <mru> I don't remember [01:52:14] <Dark_Shikari> heh, so a while ago then. [01:52:20] <mru> 2 years [02:42:48] <kierank> oooh, found the wii h.264 decoder binary [02:46:07] <kierank> interesting string: "MATSUSH.ITA_H264.DECODER" [02:49:07] <Dark_Shikari> interesting [02:50:11] <kierank> dunno how to dissasemble it though [02:52:00] <ShadowJK> panasonic? [02:52:44] <kierank> matsushita became panasonic [03:14:05] <kierank> it seems to have debug symbols too [03:16:26] <Dark_Shikari> o.0 [03:17:57] <kierank> there's a lot of mentions of words relating to h.264 decoding like: coeff, transform, vui, baseline [03:18:42] <Broken> btw, mru, those didn't help [03:19:11] <Broken> -fno-tree-vectorize and removing -ffast-math [03:19:18] <kierank> Broken: do you know what an rso file is? [03:19:19] <mru> use default flags [03:19:23] <kierank> (off-topic) [03:19:24] <Broken> I cannot [03:19:27] <mru> why? [03:19:28] <Broken> will not compile [03:19:30] <mru> why? [03:19:40] <Broken> you ask me why [03:19:49] <mru> it's your job to find out [03:19:53] <Compn> paste errors [03:19:57] <Compn> or we cant guess [03:20:01] <Broken> by default flags, what do you mean? the ones generated by the configure script? [03:20:04] <mru> yes [03:20:26] <Broken> mp_fifo.c fails to compile, showing like 80 pages of errors [03:21:54] <Broken> btw, yes, its a mplayer compile, but the error is relegated to libavcodec [03:22:08] <Broken> which as I understand is ffmpeg [03:22:15] <mru> gaaaaaaaaaaaaaaaaaaaaaaaaaaaaahh [03:22:35] <Broken> gaaawhat? [03:22:48] <Compn> lol. [03:23:06] <Compn> mplayer compilation is different than ffmpeg [03:23:14] <Broken> yippee [03:23:17] <Compn> no matter how much mplayer uses ffmpeg... [03:23:22] <Broken> k [03:23:39] <Compn> sometimes mplayer is broken , because of changes to ffmpeg and mplayer hasnt been updated yet [03:23:49] <Broken> so, do I need to go beg someone in #mplayer ? [03:24:08] <Compn> you need to paste your errors to pastebin.com so #mplayer people can help you, yes [03:24:14] <Broken> errm [03:24:32] <Broken> there are no errors, just incorrect playback of vp6 [03:24:57] <Compn> i forgot to mention that i hit those vp6 errors too [03:25:23] <mru> Compn: then maybe _you_ can explain what you did and why [03:25:44] <Compn> i'm pretty sure i filed a report [03:25:45] * Compn looks [03:26:06] <Broken> and I'm not the only one with the issue, wiimc, has the issue, as well as mplayer-CE for Wii, and the recent NXP release of the NXP 8635 (based on ffmpeg march release) [03:26:20] <Compn> http://roundup.ffmpeg.org/issue182 [03:26:43] <Compn> http://roundup.ffmpeg.org/issue708 [03:26:48] <mru> Broken: all of those are full of hack [03:26:51] <mru> we can't support them [03:27:04] <Compn> http://roundup.ffmpeg.org/issue965 [03:27:38] <Compn> there, three vp6 bleeding problems [03:27:48] <Broken> mru, this doesn't explain why building ffmpeg, and using the compiled static lib gives the exact same issue [03:28:09] <mru> using broken flags breaks build [03:29:00] <Broken> awesome [03:29:21] <Broken> so, icanhas working flags, and know the taboo ones? [03:29:34] <mru> configure sets good flags [03:29:37] <mru> don't screw with them [03:29:38] <Broken> ... [03:29:48] <mru> if that doesn't work, we can start talking [03:30:07] <Broken> okie dokie [03:30:13] <Broken> see you in 18 minutes [03:30:15] <Compn> mru : bcoudurier at least confirmed this bleeding vp6 bug > http://roundup.ffmpeg.org/issue965 [03:30:26] <mru> yes, I see it too [03:30:29] <Compn> :P [03:30:34] <mru> probably a different issue [03:30:43] <Broken> or the same issue [03:30:45] <Broken> ... [03:30:50] <mru> Broken: your file plays perfectly [03:30:53] <mru> ergo, not same [03:31:24] <Compn> where is Broken's file ? [03:31:28] * Compn wants to checks :) [03:31:41] <Compn> incoming? [03:31:42] <mru> incoming/test.flv [03:31:44] <Compn> oo [03:31:45] <mru> yeah, great name [03:31:50] <Broken> if by perfectly, you mean the screen tears all to hell, and blocks get misdecoded, then sure, it plays perfectly, and PC gets it wrong by making intelligible video, without nasty artifacting [03:32:02] <mru> I mean I can watch a family guy clip [03:32:12] <Broken> so can I [03:32:15] <mru> if it was meant to be some other show, well... then we have a problem [03:32:29] <Compn> Broken : just relax, some bugs arent found on all systems [03:32:35] <Compn> and this one is one of those :) [03:32:51] <Compn> just because mru cant reproduce, doesnt make it any less of a bug [03:32:55] <Broken> its the entire show after the first commercial, and on mplayer PC, it looks beutiful [03:33:18] <mru> I built ffmpeg on ppc w/o altivec [03:33:23] <mru> perfect decode [03:33:31] <Broken> on PowerPC 750CL, not perfect decode [03:33:36] <Compn> mru : --disable-optimizations? -O0 ? [03:33:37] <mru> ppc is ppc [03:33:45] <mru> Compn: --disable-asm [03:33:53] <Broken> I cannot configure [03:34:07] <Compn> Broken : ffplay gives the same artifacts ? [03:34:15] * Compn cant remember if he tested ffplay or not [03:34:30] <Broken> cannot test, ffplay is not part of mplayer [03:35:02] <Compn> you know this is the ffmpeg channel right ? you should test with ffmpeg/ffplay if you want to report bugs here [03:35:31] <Broken> I compiled libavcodec from ffmpeg sources, and used directly, accomplished same error [03:37:01] <Broken> mru, if you want to pastebin the resulting Makefile, and config.mak, so I can compare, that might be helpful [03:38:47] <Broken> if you wonder why I cannot run configure, open NXP's SDK, and try typing ./configure [03:39:01] <Broken> fun time converting the configure script... fun fun fun [03:39:16] <mru> what has an nxp sdk got to do with ffmpeg? [03:39:25] <Broken> errm [03:39:39] <Broken> thats what I'm trying to get results with? [03:39:47] <mru> so? [03:39:54] <Broken> and it worked perfectly before november 2009 [03:40:00] <mru> you must have a compiler for the target system [03:40:04] <Broken> yep [03:40:07] <mru> use that with the normal ffmpeg configure script [03:40:16] <Broken> mru [03:40:30] <Broken> there is no shell in the sdk from our nice frinds at nxp [03:40:39] <mru> wtf are you babbling about? [03:40:48] <mru> does your system not come with a shell? [03:41:02] <Broken> typing ./configure into it results in 4 beeps, and the edit window opening [03:41:13] <mru> typing into WHAT? [03:41:14] <Broken> yes, cmd prompt [03:41:22] <mru> do you have a linux system with xterm and bash? [03:41:31] <Broken> yes [03:41:53] <mru> and it can't run the ffmpeg configure script because you _also_ have an unidentified sdk somewhere on the system? [03:42:06] <Broken> no [03:42:11] <mru> what then? [03:42:17] <Broken> the linux system is another computer altogether [03:42:27] <mru> gaaaaaaaaaaaaaaaaaaaaaaaaaaaaaah [03:42:58] <Broken> the nxp SDK is a crappy windows based tool [03:43:04] <mru> so don't use it [03:43:12] <Broken> fun [03:43:35] <Broken> apps built with the gcc cross compile dont load [03:43:56] <mru> maybe you should get a working compiler _before_ trying to build ffmpeg [03:44:06] <Broken> i have a working compiler [03:44:07] <Broken> and [03:44:11] <mru> evidently not [03:44:16] <Broken> it worked fine before November 2009 [03:44:27] <mru> < Broken> apps built with the gcc cross compile dont load [03:44:37] <mru> that's not working [03:44:40] <Broken> umm [03:45:01] <Broken> THE NXP SDK worked fine, with ffmpeg sources from BEFORE November 2009 [03:45:32] <mru> not my fault [03:45:45] <Broken> I never said it WAS your fault [03:47:06] <Broken> My indication, in all of these matters was, a) there is a known issue with vp6, confirmed by another, b). it did not exist locally before November 2009, c) you indicate its a CFLAG problem, d). I have asked to see your CFLAGS, and e). we seems to speak different versions of english, [03:47:47] <mru> I have yet to hear two consistent statements from you [03:47:55] <mru> therefor, I give up [03:48:07] <Broken> awesome, show me 2 conflicting statements pls [03:48:13] <mru> scroll up [03:48:24] <Broken> I have [03:48:28] <mru> why don't you track down the commit that broke it instead? [03:48:41] <Broken> I have been present in all of the conversation, between you, and myself [03:49:25] <Broken> according to you its not broken, so that (according to you) would be a complete waste of time [03:49:56] <mru> it's not broken here [03:50:03] <mru> and I can't fix what ain't broken [03:50:18] <Broken> true, its not broken in alot of places, that does not disprove the issue [03:50:29] <mru> _if_ there is a bug, it's more restricted than "all big-endian" [03:51:17] <Broken> I never said "all big endian" I said "General Big Endian" meaning CPU set to General, and Endianness set to BIG_ENDIAN [03:51:33] <mru> what's the difference? [03:51:44] <mru> and where do you set the cpu to "general" [03:51:45] <mru> ? [03:51:46] <Broken> yet, I have asked to see your cflags, and we are arguing about what I did not say [03:51:53] <mru> that's not an option in our configure script [03:52:00] <Broken> nope, its not [03:52:15] <mru> CFLAGS= -mcpu=7450 -mpowerpc-gfxopt -std=c99 -fomit-frame-pointer -maltivec -mabi=altivec -g -Wdeclaration-after-statement -Wall -Wno-switch -Wdisabled-optimization -Wpointer-arith -Wredundant-decls -Wno-pointer-sign -Wcast-qual -Wwrite-strings -Wtype-limits -Wundef -Wmissing-prototypes -O3 -fno-math-errno -fno-signed-zeros -fno-tree-vectorize -Werror=implicit -Werror=missing-prototypes [03:52:34] <mru> we only support builds made with our build system [03:52:40] <Broken> hi [03:52:46] <mru> hi? [03:52:47] <Broken> Can you test without altivec? [03:52:59] <mru> that is wihtout altivec [03:53:10] <Broken> -maltivec -mabi=altivec [03:53:17] <Broken> is not without altivec [03:53:50] <mru> the actual altivec code is still disabled [03:54:14] <Broken> then it wouldn't hurt to test without altivec now would it? [03:54:22] <mru> I DID [03:54:42] <mru> now you claim to have one version of the source that works and one that doesn't [03:54:53] <mru> it's your job to find out exactly which revision "broke" it [03:55:02] <mru> until you do, I'm not saying another word [03:55:09] <mru> I might, however, kick you [03:56:02] <Broken> according to our nice friends at gcc, -mabi=altivec means "generate AltiVec code wherever possible". [03:57:02] <Broken> no need to kick me, this river is very deep, denial solves nothing [03:57:12] <saintdev> lol [05:05:48] <j0sh_> is there a reason some internal functions are prefixed ff_ and others are not? [05:08:30] <jai> non-static functions not part of the public api -> ff_ [05:14:04] <j0sh_> alright [07:29:24] <CIA-93> ffmpeg: kostya * r23370 /trunk/libavcodec/vc1dec.c: [07:29:24] <CIA-93> ffmpeg: 321l: do not use shifted s->linesize instead of correct s->uvlinesize. [07:29:24] <CIA-93> ffmpeg: This should fix chroma issues in WMV3/VC-1 decoder with avfilter enabled. [09:41:14] <CIA-93> ffmpeg: diego * r23371 /trunk/configure: [09:41:14] <CIA-93> ffmpeg: Require --enable-nonfree flag for libvpx. [09:41:14] <CIA-93> ffmpeg: The license of libvpx is incompatible with the (L)GPL. As long as this is [09:41:14] <CIA-93> ffmpeg: the case, the only way to use it is by marking the result as nonfree. [09:43:26] <lu_zero> 05:52 <@mru> the actual altivec code is still disabled [09:43:38] <lu_zero> with -O3 the autovectorizer kicks in [09:44:42] <lu_zero> but I read -fno-tree-vectorize that makes the point moot [11:44:15] <superdump> mru: ping? [12:03:31] <mru> superdump: pong [12:04:11] <superdump> i'm having trouble with shared library symbol resolution in debian unstable 64-bit when using stuff installed to /usr/local but only with ffmpeg [12:04:30] <superdump> i'm wondering if the build system is doing something that debian is finding unusual [12:04:33] <mru> sounds like a debian problem [12:04:51] <superdump> ldconfig -v shows /usr/local/lib is listed first [12:05:00] <superdump> and libx264.so.96 is found in there [12:05:47] <superdump> but when i build ffmpeg against libx264, it seems the one from /usr/lib gets picked up [12:06:03] <mru> why do you have two of them? [12:06:03] <superdump> and i can't remove that because i want some of the other dependencies [12:06:13] <siretart> wtf? x264 is at soname 96 already?! [12:06:17] <mru> --extra-ldflags=-L/usr/local/lib [12:06:57] <superdump> hmm, someone just said ldconfig and gcc/ld resolution order have nothing to do with each other - why? [12:07:04] <superdump> and i'll try that [12:07:05] <mru> that's how it is [12:07:10] <superdump> ok [12:07:39] <mru> you can also set LIBRARY_PATH to a list of directories to search before the standard ones [12:08:12] <superdump> LIBRARY_PATH or LD_LIBRARY_PATH? [12:08:26] <mru> LD_LIBRARY_PATH is for the dynamic linker at runtime [12:08:31] <superdump> that worked, thank you [12:09:54] <mru> btw, lol @ dilbert [13:12:10] <CIA-93> ffmpeg: siretart * r23372 /branches/ (0.6 0.6/libavcodec/audioconvert.h): [13:12:10] <CIA-93> ffmpeg: Fix documentation of av_audio_convert. [13:12:10] <CIA-93> ffmpeg: Patch by Cyril Russo, stage D nexvision A laposte net [13:12:10] <CIA-93> ffmpeg: backport r23285 by cehoyos [13:12:48] <CIA-93> ffmpeg: siretart * r23373 /branches/ (0.6 0.6/libavformat/utils.c): [13:12:49] <CIA-93> ffmpeg: Display a more descriptive log message when probe buffer limit is [13:12:49] <CIA-93> ffmpeg: reached. [13:12:49] <CIA-93> ffmpeg: backport r23288 by jai_menon [14:04:01] <CIA-93> ffmpeg: siretart * r23374 /branches/ (8 files in 4 dirs): [14:04:01] <CIA-93> ffmpeg: VP8 decoding via libvpx [14:04:01] <CIA-93> ffmpeg: Patch by James Zern for Google, Inc., jzern google com [14:04:01] <CIA-93> ffmpeg: backportd r23191,23303,23307-23308 by conrad, cehoyos and mstorsjo [14:05:53] <CIA-93> ffmpeg: siretart * r23375 /branches/ (0.6/doc/general.texi 0.6): [14:05:53] <CIA-93> ffmpeg: Fix VP8 listing in general.texi [14:05:53] <CIA-93> ffmpeg: backport r23306 by mstorsjo [14:11:52] <CIA-93> ffmpeg: siretart * r23376 /branches/ (0.6/libavformat/matroska.c 0.6): [14:11:52] <CIA-93> ffmpeg: matroska: Add V_VP8 [14:11:52] <CIA-93> ffmpeg: Patch by Google [14:11:52] <CIA-93> ffmpeg: backport r23192 by conrad [14:11:54] <siretart> \o/ - with this patch, 0.6 can finally and properly playback the elephants dream! [14:12:12] <J_Darnley> Don't forget the non-free [14:12:28] <siretart> I'll discuss that with diego [14:12:57] <siretart> any other backport candidates? - last nominations? [14:13:33] <ramiro> are we still waiting for libvpx encoding? [14:13:47] <siretart> good question. [14:13:59] <ramiro> that would be nice [14:14:07] <siretart> I guess playback is way more important, given that the encoders are probably in flux for quite some time [14:14:17] <siretart> or do you mean encoding support for libvpx? [14:14:19] <peloverde> there should be no release without vpx "non-free" or (L)GPL compatible libvpx imho [14:14:27] <mru> how evil is it to hardcode struct offsets in asm? [14:14:47] <ramiro> mru: michael seems to not mind (look at swscale_internal.h) [14:14:50] <peloverde> mru, if you have to do it, put a note in the struct [14:15:15] <mru> it's the h263 dequant functions [14:15:27] <mru> they use a bunch of fields in MpegEncContext [14:16:07] <mru> ramiro: swscale would not pass review today [14:16:14] <ramiro> heh, that's true... [14:16:29] <ramiro> specially with the "do not commit unrelated things on the same commit" [14:16:38] <ramiro> rule [14:19:28] <peloverde> I would object to any new toplevel repository included via svn:externals :) [14:20:56] <CIA-93> ffmpeg: siretart * r23377 /branches/ (0.6/libavcodec/api-example.c 0.6): [14:20:57] <CIA-93> ffmpeg: api-example: Try to avoid decoding incomplete frames [14:20:57] <CIA-93> ffmpeg: Use a larger input audio buffer, refill it when it has less than 4 KB data [14:20:57] <CIA-93> ffmpeg: left. [14:20:57] <CIA-93> ffmpeg: backport r23323 by mstorsjo [14:25:07] <j-b> no backport of non-free? [14:26:20] <CIA-93> ffmpeg: siretart * r23378 /branches/ (0.6 0.6/libavcodec/h264_ps.c): [14:26:20] <CIA-93> ffmpeg: Check for VUI overeading and reset num_reoder_frames. [14:26:20] <CIA-93> ffmpeg: This helps the video from issue1831 [14:26:20] <CIA-93> ffmpeg: backport r23328 by michael [14:33:58] <CIA-93> ffmpeg: siretart * r23379 /branches/ (5 files in 4 dirs): [14:33:58] <CIA-93> ffmpeg: Add CODEC_CAP_EXPERIMENTAL and prefer encoders without it. [14:33:58] <CIA-93> ffmpeg: Patch by Janne Grunau, janne-ffmpeg jannau net [14:33:58] <CIA-93> ffmpeg: backport r23334,23337-23338 by cehoyos and stefano [14:34:42] <CIA-93> ffmpeg: siretart * r23380 /branches/ (0.6 0.6/libavcodec/aacenc.c): [14:34:42] <CIA-93> ffmpeg: Mark AAC encoder as experimental. [14:34:42] <CIA-93> ffmpeg: backport r23350 by alexc [14:35:25] <CIA-93> ffmpeg: siretart * r23381 /branches/ (0.6 0.6/libavcodec/vorbis_enc.c): [14:35:26] <CIA-93> ffmpeg: Mark vorbis encoder as experimental. [14:35:26] <CIA-93> ffmpeg: backport r23339 by cehoyos [14:41:23] <CIA-93> ffmpeg: siretart * r23382 /branches/ (0.6 0.6/ffserver.c): [14:41:24] <CIA-93> ffmpeg: backport latest ffserver fixes like memory leaks and invalid reads [14:41:24] <CIA-93> ffmpeg: Patches by Howard Chu, hyc at highlandsun dot com [14:41:24] <CIA-93> ffmpeg: backport r23290-23295 by mstorsjo [14:42:17] <CIA-93> ffmpeg: siretart * r23383 /branches/ (0.6 0.6/ffserver.c): [14:42:17] <CIA-93> ffmpeg: ffserver: Send a Content-Base header in the reply to RTSP DESCRIBE requests [14:42:17] <CIA-93> ffmpeg: This is needed for QuickTime Player to be able to connect properly. [14:42:17] <CIA-93> ffmpeg: backport r23325 by mstorsjo [14:46:03] <CIA-93> ffmpeg: siretart * r23384 /branches/ (0.6/libavformat/riff.c 0.6): [14:46:03] <CIA-93> ffmpeg: Samsung uses SIPP as FourCC for MPEG-4 ASP. [14:46:04] <CIA-93> ffmpeg: backport r23309 by cehoyos [14:49:48] <jai> ^ you'll need another patch for that [14:58:01] <siretart> jai: which one? [14:59:11] <siretart> rev 23336? [15:03:37] <jai> siretart: yeah [15:07:59] <CIA-93> ffmpeg: siretart * r23385 /branches/ (0.6/libavcodec/h263dec.c 0.6): [15:07:59] <CIA-93> ffmpeg: Treat SIPP like xvid, fixed issue1966 [15:07:59] <CIA-93> ffmpeg: backport r23336 by michael [15:30:33] <CIA-93> ffmpeg: mru * r23386 /trunk/libavcodec/arm/ (Makefile mpegvideo_arm.c mpegvideo_neon.S): ARM: NEON optimised dct_unquantize_h263_{intra,inter} [16:25:17] <peloverde> http://tech.blog.aknin.name/2010/05/29/mailing-list-debates-considered-harm… [16:26:15] <mru> and he can't spell [16:26:42] <mru> gaah [16:26:47] <mru> another mistake [16:27:07] <mru> wow, a sentence without errors [16:35:07] <kshishkov> mru: then that post was intended for Diego and not you [16:39:22] <nfl> is there an api call for arithmetic shift? [16:39:51] <kshishkov> >> [16:39:53] <mru> nfl: in practise shift of signed values is arith [16:43:33] <hyc> wbs: what do you think about adding -vpre support to ffserver config? [16:44:39] <wbs> hyc: sure, if you get it implemented cleanly [16:45:16] <hyc> picky, picky... ;) [16:46:21] <hyc> still trying to see if I can simplify the sdp patch any further [16:46:48] <hyc> doesn't seem like it [17:15:09] <lu_zero> uhmm [17:16:23] * lu_zero consider ffserver config annoing at best [17:16:38] <hyc> agreed [17:19:01] <_troll_> change it to xml! [17:19:55] * hyc changes his mind about agreeing to devel policy, relinquishes svn access... [17:19:57] <kshishkov> and rewrite in Java! [17:20:26] <jai> or c++ with boost [17:20:41] <kshishkov> ok, ou win [17:20:44] <kshishkov> *you [17:21:09] <jai> :) [17:21:20] <hyc> kshishkov: I guess a java wrapper is enough http://javacodegeeks.blogspot.com/2010/05/rtmp-to-rtsp-re-stream-using-wowz… [17:22:01] <_troll_> it has to be wrappers all the way down [17:22:54] <_troll_> when nds started writing wrappers for their own wrappers, I was one step closer to leaving [17:24:47] <Dark_Shikari> _troll_: oh nice, dct unquant n eon [17:24:50] <Dark_Shikari> what % time does it use now? [17:25:02] <_troll_> 5% [17:25:13] <Dark_Shikari> heh, nice, so almost 3x faster [17:25:16] <kshishkov> what made you leave then? docmenting wrappers on wrappers on own wrappers? [17:25:20] <Dark_Shikari> It does bug me the way that h263 works [17:25:26] <Dark_Shikari> it does unquant as a separate function instead of during decoding [17:25:31] <_troll_> kshishkov: it helped that the wrappers were _wrong_ [17:25:40] <Dark_Shikari> the latter would probably be faster in many cases [17:25:47] <_troll_> hard to simd though [17:25:49] <Dark_Shikari> i.e. when there aren't many dct coeffs per block [17:25:50] <Dark_Shikari> yeah [17:25:55] <Dark_Shikari> but h264 does that for example [17:26:39] <Dark_Shikari> anyways, thanks a lot -- 10% free speed without horribly munging anything. [17:27:02] * _troll_ sends Dark_Shikari an invoice [17:31:30] <lu_zero> 19:17 <@_troll_> change it to xml! [17:31:44] <lu_zero> if anything maybe json =P [17:31:58] <lu_zero> the problem is what you put there not how anyway [17:32:02] <_troll_> drk_shikari? [17:32:04] <peloverde> ebml! [17:32:22] <hyc> Dark_Shikari: it looks to me like x264_encoder_headers() only outputs one sps and one pps. is that pretty typical? [17:32:53] <hyc> trying to figure out if I need to handle more than one of each when pushing codec->extradata into sdp sprop-parameter-sets [17:33:20] <kierank> multiple sps/pps is rare [17:33:49] <lu_zero> I find strange having ffmpeg called outside with params to produce a feed file and then you have another way to feed ffmpeg params in ffserver [17:34:40] <hyc> kierank: kinda suspected that. [17:34:43] <kshishkov> put them to XML extradata :P [17:35:09] * elenril would compress it with crc32 [17:35:24] <hyc> lu_zero: hm? you can't set ffmpeg params when outputting to a feed [17:35:46] <kshishkov> s/compress/hash/ [17:36:15] <lu_zero> uh? [17:36:26] <elenril> kshishkov: i stand behind what i said =p [17:36:30] <lu_zero> at least input params for sure [17:36:48] <lu_zero> hyc: btw what are you trying to archive? [17:37:03] <hyc> kierank: rtpdec_h264 seems to be set up to parse an arbitrarily long list of sps/pps [17:37:21] <hyc> lu_zero: hm? what archive? [17:37:31] <lu_zero> 19:31 <+hyc> trying to figure out if I need to handle more than one of each when pushing codec->extradata into sdp sprop-parameter-sets [17:37:57] <lu_zero> I was quite sure that the code for that is already present [17:38:07] <hyc> lu_zero: currently ffserver will not serve FLV files over rtp correctly [17:38:24] <hyc> because the flv extradata is in AVC format, not bytestream format [17:38:44] <hyc> and libavformat/sdp.c currently only encodes bytestream extradata [17:38:59] <hyc> I just posted a patch for it to use AVC format [17:39:07] <hyc> but my patch only handles a single sps and pps [17:39:16] <hyc> not sure if it needed to be able to handle multiple [17:39:16] <lu_zero> uhmm [17:39:17] <lu_zero> eng/src/media/parser/h264.c [17:39:19] <lu_zero> f [17:39:21] <lu_zero> check there [17:39:36] <hyc> ok [17:39:38] <hyc> thx [17:40:26] <lu_zero> http://cgit.lscube.org/cgit.cgi/feng/tree/src/media/parser/h264.c#n91 [17:40:35] <lu_zero> is that missing? [17:40:51] <hyc> I have the source tree here [17:41:12] <lu_zero> ok =) [17:43:28] <hyc> lu_zero: ok, it looks like you just output them all, with a comma between each b64 string [17:44:12] <lu_zero> yes [17:44:16] <lu_zero> that's the idea [17:44:55] <hyc> ok, then my last emailed patch is wrong. thanks for clarifying [17:46:08] <hyc> seems like you ought to check in case there were no sps in encode_avc1_header [17:46:12] <lu_zero> I should doublecheck the rfc if you found something different [17:46:24] <lu_zero> uhm? [17:46:33] <hyc> or would that have been an invalid setup, rejected much earlier? [17:47:23] <hyc> the RFC said something about these being sps/pps pairs, which confused me. led me to believe there was a strict sps,pps,sps,pps order or something. [17:48:25] <lu_zero> cnt = *(p+5) & 0x1f; // Number of sps [17:48:57] <hyc> right, is it ever legal for that cnt to be zero? [17:49:08] <lu_zero> I'm afraid right now it doesn't check if it is zero [17:49:12] <lu_zero> and isn't expected [17:49:52] <hyc> it would certainly make no sense to encounter that, but ya never know [17:50:54] <lu_zero> that reminds me that ffmpeg doesn't fill the extradata for elementary streams [17:51:27] <hyc> and just to confirm, in avc1 header, only sps and pps are present, no other nal types [17:52:11] <hyc> sdp.c currently checks to make sure type is 7 or 8 when encoding a bytestream extradata [17:53:09] <lu_zero> if anything got there it would be serialized the same way [17:53:20] <hyc> ok [18:13:25] <hyc> I looked at mp4, mkv, and flv, it seems they all store the extradata in AVC format [18:13:44] <hyc> so ffserver always fails to stream H.264 from these files [18:14:15] <hyc> is there a file format that doesn't use AVC? [18:36:08] <astrange> .h264 [18:36:10] <astrange> maybe .ts [18:38:52] <hyc> thx, will try .h264 [18:44:34] <hyc> hmm. ffmpeg -i xxx.flv -vcodec copy -an test.h264 [18:44:44] <hyc> ffprobe test.h264 -> detects as mp3 [18:44:59] <lu_zero> ffmpeg -i ? [18:45:41] <hyc> yes, what's wrong with that? [18:46:00] <lu_zero> I mean [18:46:07] <lu_zero> ffmpeg -i test.h264 [18:46:16] <hyc> lots and lots of garbage [18:46:17] <lu_zero> says the right thing? [18:46:42] <hyc> no, it says the same as ffprobe. mp3 [18:47:03] <hyc> [NULL @ 0x28fc470]Format detected only with low score of 24, misdetection possible! [18:47:04] <hyc> [mp3 @ 0x28fd710]Header missing [18:48:41] <lu_zero> pretty bad [18:48:57] <lu_zero> file says the same? [18:49:19] <hyc> "file" says "test.264: data" [18:49:40] <hyc> s/264/h264/ [18:53:08] <kierank> hyc: you need to convert from mp4 to annex b [18:53:33] <kierank> ffmpeg should really do that by itself when you use .h264 output though [18:54:29] <hyc> kierank: ah, that's better, thanks [18:57:41] <lu_zero> works? [18:57:49] <hyc> yep [18:58:16] <hyc> hmmm. not playing well from ffserver though [18:59:37] <hyc> and playing the file directly, frame rate is wrong [19:00:00] <lu_zero> the extradata is correctly parsed? [19:00:37] <hyc> I think so, overall the image looks fine [19:06:38] <hyc> ffserver doesn't serve it properly [19:06:50] <hyc> with or without my rtpenc_h264 patch [19:07:04] <hyc> so at least I didn't break anything :P [19:07:56] <lu_zero> good =) [19:09:49] <hyc> ffplay on the .h264 file, frame rate appears to be too fast [19:10:05] <hyc> ffplay thru ffserver, I get one frame and then nothing [19:10:22] <kierank> the .h264 file might be vfr [19:12:16] <hyc> variable frame rate? [19:12:57] <kierank> yes [19:13:58] <kierank> I'm not sure how ffmpeg does it but it could have put the flv timebase in the h.264 vui. [19:14:47] <kierank> or there might not even be a vui since some h.264 files don't have any [19:15:02] <hyc> seems like it recorded the timebase [19:15:06] <hyc> here's the .flv [19:15:16] <hyc> Stream #0.0: Video: h264, yuv420p, 640x360 [PAR 1:1 DAR 16:9], 29.97 tbr, 1k tbn, 59.94 tbc [19:15:23] <hyc> here's the .h264 [19:15:43] <hyc> Stream #0.0: Video: h264, yuv420p, 640x360 [PAR 1:1 DAR 16:9], 29.97 fps, 29.97 tbr, 1200k tbn, 59.94 tbc [19:18:55] <hyc> if you want to take a look, http://highlandsun.com/hyc/test.flv [19:21:58] <kierank> it's flagged as vfr though [19:22:09] <kierank> s/though/ [19:23:03] <kierank> it should play at the right speed though [19:23:38] <hyc> what do you get when you copy the video stream to a .h264 file? [19:24:30] <kierank> num_units in tick: 1001 time_scale: 60000 [19:25:04] <kierank> which is correct [19:35:08] <hyc> but does it look like the correct rate when you play it? [19:39:30] <kierank> no [19:42:16] <hyc> looks to me like 24 or 25fps would have been correct [19:42:56] <hyc> mebbe the original encoder lied [20:10:04] <Kovensky> <kierank> it's flagged as vfr <-- isn't flv always vfr [20:15:10] <kierank> yes [22:01:57] <lu_zero> wbs: around? [22:33:46] <lu_zero> mru: poing [22:41:50] <DonDiego> gnite [22:45:59] <Kovensky> <@peloverde> It's an interesting game but it's no starcraft <-- peloverde++ [22:46:28] <Kovensky> (yes i only saw that today lol) [22:51:07] <superdump> about sc2 or...? [22:55:17] <Kovensky> about soccer [22:55:50] <Kovensky> silly argentinians [22:59:49] <superdump> aha :) [22:59:53] * superdump sleeps [23:02:24] <mru> lu_zero: pong [23:03:16] <Compn> everyone knows brazil is the best... ;p [23:04:27] <mru> some say spain has a good chance... [23:09:19] <lu_zero> I'm hopefully completing the sctp protocol [23:09:38] <lu_zero> (it will end up w/out deps on libsctp) [23:10:12] <lu_zero> wanted to know if my way to check for headers and struct is correct [23:10:41] <mru> send patch [23:11:27] <lu_zero> http://pastie.org/983764 [23:32:43] <Kovensky> Compn: tell me about it; I'll be forced to hear people talking about football the whole day every day for a whole month -_- [23:33:05] <Kovensky> not like I'm not forced to that usually though; it'll just be more intense D: [23:33:39] <Kovensky> lu_zero: StarCraft Transmission Protocol protocol? [23:49:44] <lu_zero> Kovensky: uhmmm [23:49:50] <lu_zero> would be fine for gaming indeed [23:50:03] <lu_zero> sctp isn't about starcraft anyway [23:55:23] <mru> lu_zero: that looks reasonable but fix the whitespace [23:58:18] <lu_zero> which line?

1 0

IRC log for 2010-05-28
by irc＠mansr.com 28 May '10

28 May '10

[00:05:52] <Compn> a wicked wicked place no doubt [00:09:51] <reynaldo> hi Compn [00:13:45] <Compn> wb reynaldo [01:33:37] <Compn> heh [01:50:12] <peloverde> http://threatpost.com/en_us/blogs/cert-releases-basic-fuzzing-framework-052… [01:51:28] <bcoudurier> humm, how do you mention that you are using full range yuv in h.264 ? [01:52:33] <Dark_Shikari> --fullrange in x624 [01:52:56] <mru> I suppose it's signaled in vui or a special sei [01:53:17] <Dark_Shikari> VUI [01:55:50] <bcoudurier> vui ? [01:55:59] <bcoudurier> I'm reading the specs [01:56:26] <Dark_Shikari> video [01:56:29] <Dark_Shikari> video_signal_type [01:56:32] <Dark_Shikari> video_full_range_flag [01:56:48] <mru> annex e [01:57:17] <mru> what happened to annex f? [01:57:19] <bcoudurier> all right [01:57:24] <bcoudurier> why wasn't that fixed in svn ? [01:57:28] <bcoudurier> it's pretty trivial [01:57:36] <bcoudurier> if video_full_range pix_fmt = PIX_FMT_YUVJ420P [01:57:47] <Dark_Shikari> I thought jpeg had some other thing going on? [01:57:49] <bcoudurier> no [01:57:54] <bcoudurier> jpeg uses 0-255 [01:57:57] <bcoudurier> yuv [01:58:19] * Dark_Shikari wonders why we don't have another range flag [01:59:03] <bcoudurier> libswscale already supports it, so it should work correctly [02:00:33] <bcoudurier> and we do have one [02:00:36] <bcoudurier> it seems [02:00:49] <bcoudurier> AVCOL_RANGE_JPEG [02:01:52] <mru> and h264 sets it [02:05:26] <bcoudurier> but since the range is ignored [02:05:52] <mru> having two ways of specifying the same thing is bad [02:10:45] <bcoudurier> I agree, although we have some legacy stuff that is painful to remove [02:12:24] <bcoudurier> BUG: unable to handle kernel NULL pointer dereference at 0000000000000009 [02:12:24] <bcoudurier> IP: [<ffffffff81071482>] free_pid+0x3d/0xbb [02:12:24] <bcoudurier> PGD 12189b067 PUD 17ba91067 PMD 0 [02:12:59] <bcoudurier> has anybody any idea about how important this might be ? [02:15:30] <ohsix> rebooting would be in short order [02:19:09] <bcoudurier> agree :) [04:11:34] <hyc> hm, the mpeg4video_parser also needs to look at avctx->extradata [04:11:53] <hyc> and it just sets a flag and then checks it on every parse [04:12:16] <hyc> I guess it's too much trouble to add a new API, just going to leave it with checking a flag [04:39:09] <peloverde> gah! the psymodel is setting the threshold way too low on sfb 21 for some reason causing hilarity at low bitrates [04:52:19] <kshishkov> peloverde: blame implementor [04:53:08] <peloverde> Before that I spent 8 hours chasing down spectral holes due to a typo I made today :( [04:56:43] <peloverde> I'm also not sure how much I really care about 32k/channel [04:57:33] <kshishkov> that's 64kbps in total, sounds quite widespread [04:58:56] <peloverde> Down in that space you are really starting to step into SBR territory [05:02:55] <peloverde> I guess 64 is reasonable with decent stereo coding [05:03:17] <peloverde> I've been focusing on mono only [06:05:54] <Dark_Shikari> Yuvi: idct_dc for vp3 is wrong [06:06:05] <Dark_Shikari> fyi. [06:06:20] <Dark_Shikari> the correct version is faster, too. [07:02:25] <CIA-93> ffmpeg: conrad * r23358 /trunk/libavcodec/x86/vp3dsp_mmx.c: [07:02:25] <CIA-93> ffmpeg: vp3: The DC-only IDCT is surprisingly not supposed to be bitexact to the [07:02:25] <CIA-93> ffmpeg: full IDCT. Fix this. [07:03:10] <Dark_Shikari> Yuvi: you have to fix the c too [07:03:16] <Yuvi> oh right [07:16:55] <superdump> morning [07:17:28] <wbs> morning [07:17:59] <jai> morning [07:18:19] <wbs> jai: isn't it more like noon over there? :-) [07:18:38] <jai> wbs: yeah, just blending in ;) [07:19:00] <wbs> jai: or to put it in a kshishkov-ish way, you're pretending to be swedish? ;P [07:19:18] <Tjoppen> kaffe. [07:19:21] <jai> lol [07:20:01] <thresh> moroning, btw [07:20:01] <jai> wbs: there are only 2 kinds of people, swedes and wanna be swedes :) [07:23:03] <CIA-93> ffmpeg: conrad * r23359 /trunk/libavcodec/ (arm/vp3dsp_neon.S vp3dsp.c): vp3: 10l Fix DC-only IDCT for C and ARM too [07:23:56] <wbs> jai: at least in some people's minds :-) [07:30:34] * _av500_ does not want to be suede [07:31:12] <_av500_> gm btw [07:52:55] <Tjoppen> I still don't get it - how can VP8 be considered unencumbered? all I see is handwaving like "google will use its patent stick" [07:53:21] <_av500_> how iwll gg use its patent stick? [07:53:22] <Dark_Shikari> that sounds sexual. [07:53:26] <Tjoppen> :o [07:53:26] <Dark_Shikari> "patent stick" [07:53:34] <_av500_> you cann sue troll back usually [07:53:41] <Dark_Shikari> frauenhofer will take google's patent stick right up its patent hole [07:53:45] <_av500_> because they dont make product of their own [07:54:00] <Yuvi> it's probably just different enough that any patents it infringes are of the stupidly overbroad variety [07:54:01] <_av500_> you cannot sue trolls back usually [07:54:12] <Tjoppen> basically mutually assured destruction? [07:54:16] <Dark_Shikari> Yuvi: I think they're betting on prior art on some things [07:54:24] <Dark_Shikari> e.g. hoping that nokia mvc prior arts the intra pred patents [07:54:30] <Dark_Shikari> Which technically it _does_ [07:54:33] <Dark_Shikari> it's just that the courts are retardo [07:54:36] <Yuvi> nokia doesn't have patents on it? [07:54:43] <_av500_> Dark_Shikari: this will still not help many small players [07:54:43] <Dark_Shikari> "everything that isn't a patent doesn't count as prior art" [07:54:52] <Tjoppen> durr [07:54:57] <_av500_> trolls go after small prey 1st [07:54:59] <Dark_Shikari> Yuvi: any patents on spatial intra pred came 2002 or later iirc [07:55:03] <Dark_Shikari> and mvc was 2000 [07:55:43] <Yuvi> still, if it's nokia patenting it, 2002 would mean it's "valid" regardless of mvc [07:55:44] <Tjoppen> so it's basically as I suspected then [07:56:07] <Dark_Shikari> and of course we all know that nokia never exercises its patents >_> [07:58:09] <Yuvi> or it's possible that they might argue that the intra pred modes are pretty obvious (except for planar which they don't use) [07:58:18] <Yuvi> and thus any patents on them should be invalid [07:58:57] <Dark_Shikari> that would be REALLY hard to argue [07:59:06] <Dark_Shikari> there are many codec patents on far similar things [07:59:20] <Dark_Shikari> which most lawyers seem to think will hold up [07:59:47] <Yuvi> yeah, but if google manages to successfully argue that, that would be a pretty good win against software patents [08:00:02] <wbs> I want a pony, too. :-) [08:00:08] <Tjoppen> err.. AV_NOPTS_VALUE is unsigned? [08:00:11] <Yuvi> heh [08:00:29] <Yuvi> Tjoppen: equivalent to INT64_MIN iirc [08:00:37] <merbzt> ponys for everyone [08:00:40] <Tjoppen> yes, but it's unsigned :o [08:00:46] <Tjoppen> causing compilation warnings [08:01:07] <Tjoppen> since timestamps are stored in int64_t's [08:01:25] <Yuvi> which compiler? it's a literal, signed <-> unsigned shouldn't be warnings :/ [08:01:42] <Tjoppen> g++ -Wall [08:01:46] <Yuvi> or wrong terminology, but same [08:01:58] <Tjoppen> yes, I'm just doing ==, which should work [08:03:03] <Tjoppen> time for fika [11:18:59] <merbzt> mru: do you know hdmi stuff ? [11:20:26] <mru> what about it? [11:23:42] <merbzt> bit stream audio transfer [11:24:34] <mru> what do you want to know? [11:25:07] <twnqx> if it is existing in the driver it is shown in alsa as an spdif device [11:25:10] <twnqx> does that help? [11:25:29] <merbzt> how to transfer it, ie mux it [11:26:35] <merbzt> for example how to send things that cant be sent over a spdif cable [11:26:41] <merbzt> dts-ma [11:26:43] <mru> the hdmi spec is freely available [11:26:44] <merbzt> mlp [11:26:49] <mru> hdmi.org [11:29:31] <twnqx> merbzt: it can be sent [11:29:55] <twnqx> e.g. my mainboard allows way higher bitrates on its spdif port than the usual 1536kbit/s [11:30:12] <merbzt> neat [11:30:29] <twnqx> i only noticed when i booted windows, and the driver allowed be to test higher rates [11:30:39] <twnqx> dunno if it works with linux, though [11:30:47] <twnqx> i have no amp to test for the other end ;) [11:30:58] <merbzt> IC :) [11:31:19] <twnqx> should check if my hdmi-enabled marantz would accept that on spdif as well [11:33:25] <jai> you have a marantz receiver? [11:34:44] <mru> gaaah, this mips manual is annoying [11:37:45] <twnqx> jai: yes [12:04:46] <Vitor1001> jai: Since you seems to understand quite a bit about .rm, have you seem issue1708? [12:13:57] <scaphilo> hi everyone, im on my last steps in building my openloop mpeg2 to mpeg4part2 transcoder :-) the only thing that still doesnt work has something to do with the interlaced_dct macroblocks. Is there a differnece i dont know between mpeg2 and mpeg4? [12:15:26] <scaphilo> it only happens when these macroblocks were refered by other mb's [12:18:46] <jai> Vitor1001: yeah, those are old audio only streams. we dont support that currently [12:19:31] <scaphilo> mpeg2 specialist here? what happens when a mb refers to such a mb's top field for example? does it refer to the interlaced field (which contains 4 lines of the top and 4 of the bottom) or does it refer to the top 8 lines? [12:20:07] <jai> Vitor1001: shouldn't be too complex though, mplayer already has code which demuxes those [12:20:49] <Vitor1001> jai: That's why I pinged you, I was hooping it would be pretty trivial for someone who knows the format ;) [12:29:53] <jai> Vitor1001: sure, i'll take a look again [12:30:06] <Vitor1001> jai: Great, thanks! [12:32:57] <kshishkov> away away [13:02:28] <siretart> hyc: are you aware of any Linux distribution that ships rtmpdump and librtmp? [13:25:32] <lu_zero> we got a bug open to support rtmpdump [13:27:55] <siretart> lu_zero: would gentoo distribute the rtmpdump tarball on their distfiles mirrors? [13:30:32] <thresh> we still need a .so :( [13:33:43] <lu_zero> siretart: what's the issue with it? [13:33:51] <lu_zero> thresh: ? [13:34:05] <j-b> just dlopen it, like libdvdcss [13:37:12] <thresh> well i thought librtmp is a static library only [13:37:50] <j-b> oh? [13:39:56] <lu_zero> the bare makefile has just that [13:52:43] <j-b> anyone knows where nico and Erik are on IRC? [13:54:45] <merbzt> nico sabbi ? [13:55:23] <kshishkov> sounds so [13:55:35] <kshishkov> I think you should know a lot of Eriks though [13:57:30] <j-b> merbzt: [13:57:32] <j-b> merbzt: yes [13:57:45] <j-b> Erik Hovland [13:57:49] <merbzt> nicodvb is his nick if he is online [13:57:59] <j-b> the 2 people maintaining libdvdread for us :) [13:58:11] <j-b> +nicely [13:58:16] <kshishkov> you should've said that at once [13:59:00] <j-b> sorry, :) They don't seem to be around #mplayer or #mplayerdev [13:59:53] <kshishkov> I'm not sure it's easy to meet them here anyway [14:02:43] <janneg> j-b: I don't think Erik Hovland uses irc [14:04:57] <j-b> kshishkov: many thanks [14:05:00] <j-b> janneg: thanks [14:17:53] <siretart> j-b: do you have a patch for libavformat to dlopen() librtmp.so? ;-) [14:18:45] <j-b> siretart: nope [14:21:25] <BBB> why dlopen? [14:21:44] <twnqx> legal issues with linking against the lib [14:22:59] <siretart> what legal issues? [14:23:34] <twnqx> is rtmpdump considered a legal software? libdvdcss isn't in every country [14:23:49] <siretart> hyc: ^^ [14:23:52] <KotH> twnqx: neither is ssh legal in every country [14:23:54] <lu_zero> rtmpdump is legal as curl ... [14:24:03] <twnqx> i see [14:24:32] <lu_zero> and from what I'm seeing is quite useful since librtmp can also be used as building block for a server [14:24:52] <siretart> similar freetard'ish discussion going on here: http://thread.gmane.org/gmane.linux.debian.devel.general/152320 [14:25:03] <BBB> ooo tard discussion [14:25:05] * BBB clicks [14:25:11] <siretart> lol [14:25:20] <lu_zero> hyc: you'd accept to have the build system extended using ffmpeg one? [14:27:50] <KotH> siretart: tell marillat that his "license problem" is none [14:28:13] <KotH> siretart: they just wanted to scare people with a dmca, nothing more [14:28:17] <Tjoppen> av_metadata_set2() seems to leak memory. about 50 B per av_write_header() call [14:28:47] <KotH> siretart: and taht dmca notice is actually the reason why rtmpdump is hosted on natsuki [14:29:17] <hyc> lu_zero: the rtmpdump build system? I guess. why does it need extending? [14:29:37] <siretart> KotH: I've already prepared a draft but did not send it yet. [14:31:11] <KotH> siretart: you may add to it that none of us has ever heard from adobe since rtmpdump is hosted on natsuki [14:31:24] <BBB> Yuvi: regarding VP8Macroblock, is that supposed to be a visible macroblock (similar to libvpx' MACROBLOCKD) or is it also for prediction (analog to libvpx MODE_INFO)? I noticed you malloc intra4x4 (for prediction) and was wondering if you minded if I change that into a struct so we can store other prediction parameters in there as well (so it becomes a little like MODE_INFO in libvpx) [14:31:26] <siretart> natsuki is the hostname? [14:31:39] <KotH> (apperently they are smart enough to know that the dmca doesnt apply to .ch) [14:31:44] <KotH> yes, natsuki is our main server [14:31:53] <peloverde> libvpx in the MSU comparison I think a lot of people will be less than pleased https://groups.google.com/a/webmproject.org/group/codec-devel/browse_thread… [14:32:39] <mru> until they learn a thing or two about video, MSU might as well be comparing random-number generators [14:35:52] <BBB> holy shit x264 comes out well :) [14:37:40] <KotH> and theora loses to xvid... in all comparisons... [14:37:56] <KotH> mru: what do you critizise in their test? [14:38:35] <mru> they at least used to do them in total ignorance what settings were good [14:38:40] <mru> and with ancient versions [14:38:59] <mru> in fairness, the last couple of iterations have been a bit better [14:41:14] <j-b> libvpx in MSU is quite a good idea to have FACTS not FUD [14:41:57] * _av500_ loves FUDge [14:42:36] * KotH loves sprüngli chocolate [14:42:55] <_av500_> that too [14:43:58] <KotH> hmm.. next week is going to be a bit colder [14:44:10] <KotH> .o0(get up early tomorrow and buy tons of chocolate) [14:44:24] <peloverde> I thought they ask devs for recommended versions and settings [14:44:56] <mru> now they do [14:45:34] <twnqx> Stream #0.0(jpn): Video: h264, yuv420p, 720x480, PAR 186:157 DAR 279:157, 24.39 fps, 23.98 tbr, 1k tbn, 47.95 tbc <- i really don't understand how ffmpeg comes to these seemingly random fps values [14:45:41] <twnqx> (yes, it's in mkv) [14:47:13] <hyc> rights-restricted libraries? [14:47:37] <KotH> hyc: freetardism [14:48:11] <KotH> hyc: rtmdump has been tainted by a dmca notice.. it is now considered unfree..violating the gpl... etc pp [14:48:31] <lu_zero> hyc: to add shared library support [14:48:39] <lu_zero> mostly [14:48:47] <lu_zero> mru: https://review.webmproject.org/#change,40 [14:49:53] <hyc> lu_zero: I'll think about it. I guess it can always build a shared lib by default, in addition to static [14:50:36] <Tjoppen> err.. libavutil/mathematics.c:80: av_rescale_rnd: Assertion `b >=0' failed. [14:51:03] <lu_zero> and you are also lacking an install target [14:51:06] <lu_zero> ^^ [14:51:13] <hyc> for now I just add -fPIC to the C flags. it still builds static, but can be linked into other shared libs then [14:51:58] <hyc> librtmp has an install target. never really saw the need for one for rtmpdump [14:52:39] <hyc> but that's easily added... [14:52:54] <lu_zero> sure [14:53:01] <lu_zero> same as libdir param ^^ [14:55:01] <kshishkov> KotH: here I usually can get only Lindt chocolate, no SprÃŒngli [14:56:00] <mru> what, no sprÃŒngli??!?!?? [14:58:03] <kshishkov> probably they have Lindt part from L&S for foreighners and SprÃŒngli for Switzerland [14:58:28] <KotH> nope [14:58:48] <KotH> lindt is just the cheap, mass produced chocolate [14:59:06] <kshishkov> still, it's not bad [14:59:42] <scaphilo> how whould they spell sprÃŒngli in english :-) [14:59:51] <scaphilo> thats why they only get lidt [15:00:07] <scaphilo> "only" [15:06:14] <Tjoppen> never mind that av_rescale_rnd() thing btw.. it was just me being a bit careless with finding a common timebase between NTSC and AV_TIME_BASE - 2.997 GHz :o [15:06:38] <Tjoppen> clamping at INT_MAX worked well enough [15:06:55] <reynaldo> mornings [15:08:18] <j-b> Alex, you are my hero [15:09:01] <mru> nice one [15:10:12] <peloverde> :) [15:16:00] <_av500_> ? [15:18:20] <mru> vlc-devel [15:18:45] <_av500_> ah [15:25:53] <j-b> 'seeking [in ogg] is a little more complex'. Euphemism... [15:27:03] <Tjoppen> I love how lavf seeks in mxf - basically fseek(timestamp*bitrate/8) :) [15:27:29] <mru> oh no it's not</monty> [15:27:45] <mru> constant bitrate? [15:29:28] <Tjoppen> uses average bitrate derived somehow. it then scans for the next SMPTE UL [16:12:32] <BBB> is ffmpeg-user generally so flamy? [16:13:04] * mru fetches petrol [16:13:05] <ramiro> BBB: phil rhodes is [16:13:11] <BBB> I notice :) [16:13:30] <BBB> he's full of bs also [16:13:36] <ramiro> yep, he's a troll alright... [16:13:39] <BBB> ban him [16:14:19] <ramiro> he gets bored after a while and stops replying... [16:14:37] <BBB> that doesn't explain why he wasn't banned [16:15:03] <ramiro> well if we are going to ban trolls on our mailinglist we will lose some of the best devs [16:15:21] <BBB> we can exempt devs from the ban-rule [16:15:40] <BBB> or, more specifically, a non-trivial patch exempts you from a ban-on-troll [16:15:59] <BBB> that actually makes people want to contribute, so they can freely troll [16:16:10] <ramiro> "troll-driven development"? [16:16:20] <mru> ramiro beat me to it... [16:16:47] <BBB> I see a new t-shirt text [16:17:02] <ramiro> someone suggested that a few days ago, I just repeated the idea =) [16:17:12] <BBB> darnit I missed that [16:17:21] <BBB> you should do it, it sounds unique [16:17:30] <mru> we will [16:17:35] <mru> or I will [16:17:43] <mru> I usually make t-shirts [16:19:40] <mru> there's also "hope driven development": http://www.makinggoodsoftware.com/2009/05/12/hdd/ [16:20:18] <hyc> hope driven? I hope I found that last bug? [16:20:30] <mru> "I hope this will work" [16:21:24] <jai> there's asshole driven development too, though the line between that and "tdd" would be pretty thin [16:21:46] <mru> jai: that's what you get in most companies [16:21:50] <BBB> troll-driven sounds better [16:21:55] <mru> a-hole = phb and/or customer [16:21:56] <BBB> I'm sure the linux kernel counts as that also [16:22:52] <jai> heh [16:27:19] <kierank> are there any alternatives to hex-rays [16:27:49] <mru> octa-rays are 33% better [16:27:58] <jai> kierank: boomerang but it sucks [16:28:08] <kierank> jai: didn't work at all for me. just crashed [16:28:11] <jai> so no good alternatives [16:28:31] <jai> kierank: yep, it crashes on anything slight more complex than hello world [16:28:47] <kierank> and it wasn't able to see the .text section either [16:30:11] <KotH> .o0(FFdisasm) [16:33:15] <BBB> kierank: ? [16:33:19] <BBB> hexrays was quite good for me [16:35:34] <lu_zero> uhm? [16:36:05] <kierank> i'm not saying hex-rays is bad [16:36:12] <kierank> i'm saying it's expensive ;) [16:39:20] <kierank> but it does look very god [16:39:21] <kierank> good* [16:40:50] <BBB> oh [16:40:54] <BBB> but hexrays-old is free [16:41:03] <BBB> go to their website, click a few links, you'll see a free download link [16:41:08] <BBB> that's what most of us use I think [16:42:39] <kierank> are you talking about IDA or the actual hex-rays decompiler? [16:42:51] <jai> hexrays isnt free [16:43:01] <BBB> ah [16:43:03] <BBB> I meant ida [16:43:04] <BBB> sorry [16:43:14] <BBB> (I thought you meant that company's product) [16:53:48] <BBB> (addendum: IDA rocks; I tried hexrays and it is ridiculously poor) [16:54:44] <peloverde> The HexRays video looks impressive [16:55:05] * mru has never been impressed with a video of software [16:55:59] <peloverde> then you clearly should watch this: http://www.youtube.com/watch?v=9pwUdRKllo0 ;-) [17:16:16] <KotH> .o0(someone should teach the germans the meaning of "actual" and "current") [17:40:25] <_av500_> eh? [18:01:43] <Tjoppen> hah. smplayer sucks pretty bad [18:02:19] <Tjoppen> tried playing a remote dv file via my crappy 10 Mbps connection (dv is >= 25 Mbps). it crashed [18:08:23] <josh_> my first patch ever was for smplayer... i dont think it got applied, lol [18:11:49] <Tjoppen> it's pretty good. I should try vlc again though [18:12:07] <Tjoppen> too bad smplayer has all these strange little bugs everywhere [18:12:55] <KotH> if anyone needs a weekend project to work on, have a look at: http://spectrum.ieee.org/consumer-electronics/gadgets/backyard-star-wars [18:12:58] <KotH> :) [18:23:05] <CIA-93> ffmpeg: rbultje * r23360 /trunk/libavformat/ (rmdec.c rm.c rm.h): [18:23:05] <CIA-93> ffmpeg: Move rm_codec_tags to rm.c so muxer/demuxer can share it. [18:23:05] <CIA-93> ffmpeg: Patch by Francesco Lavra <francescolavra interfree it>. [18:23:05] <CIA-93> ffmpeg: rbultje * r23361 /trunk/libavformat/rmenc.c: [18:23:05] <CIA-93> ffmpeg: Use ff_rm_codec_tags[] in RM muxer. This, incidentally, also allows muxing [18:23:05] <CIA-93> ffmpeg: other audio codecs rather than only AC-3, so add some code that makes [18:23:06] <CIA-93> ffmpeg: word byte-swapping only happen for AC-3, not for all audio codecs. [18:23:06] <CIA-93> ffmpeg: Patch by Francesco Lavra <francescolavra interfree it>. [18:23:07] <CIA-93> ffmpeg: rbultje * r23362 /trunk/libavformat/rmenc.c: [18:23:07] <CIA-93> ffmpeg: Reindent after r23361. [18:23:08] <CIA-93> ffmpeg: Patch by Francesco Lavra <francescolavra interfree it>. [18:26:41] <Yuvi> BBB: yeah, VP8Macroblock is somewhat similar to MACROBLOCKD, though I'm trying to avoid having all the stuff that's in MACROBLOCKD in it [18:26:42] <Yuvi> intra4x4 is per-block and should remain by itself so fill_rectangle works [18:27:16] <BBB> macroblockd is a little big, yes [18:27:37] <Yuvi> actually [18:27:38] <BBB> so I think I need a structure that contains macroblock prediction params, but with edges [18:27:44] <Yuvi> it's more MB_MODE_INFO [18:27:46] <BBB> so I can't relaly use VP8Macroblock [18:27:59] <kshishkov> BBB: whatever you think about Apple, thold keyboards were better </offtrolling> [18:28:09] <Yuvi> per-mb? just add edges to VP8Macroblock [18:28:49] <BBB> I'm confused, I thought edges were macroblocks [18:28:55] <BBB> or are edges blocks within a macroblock? [18:29:12] <Yuvi> what do you mean by edges? an additional non-existant mb on each side? [18:30:40] <BBB> top/left, yes [18:31:38] <Yuvi> yeah, just do similar to intra4x4 and offset the macroblocks array by 1+mb_stride from the base pointer (mb_width+1)*(mb_height+1) and add mb_stride [18:32:14] <BBB> ok [18:44:17] <BBB> Yuvi: I'll ask more stupid questions at random intervals, not everything makes sense to me yet, hope that's ok [18:51:29] <CIA-93> ffmpeg: hyc * r23363 /trunk/libavcodec/ (h264.h h264_parser.c): [18:51:29] <CIA-93> ffmpeg: Parse avctx->extradata if available. [18:51:29] <CIA-93> ffmpeg: Fixes many "non-existing PPS referenced" error messages [18:51:55] <Yuvi> BBB: of course [19:46:40] <hyc> hm, I jumped the gone and committed this patch before Michael replied. https://lists.mplayerhq.hu/pipermail/ffmpeg-devel/2010-May/089557.html [19:47:17] <hyc> what now, email a fixed patch again? [19:47:40] <wbs> I guess that would be appreciated [19:47:53] <wbs> but nice to have those warnings gone, h264 over rtp looks oh so nice now :-) [19:47:59] <elenril> hyc: seppuku is the way to go [19:48:13] <wbs> yeah, that's always an option, too ;P [19:48:36] <hyc> going to change "first_picture" to "did_first" [19:48:47] <hyc> unless someone has a better name [19:48:57] <wbs> got_first perhaps? [19:49:08] <hyc> ok [19:49:16] <wbs> didn't the mpeg4 parser do something similar, how does that do it? [19:49:26] <hyc> it does exactly what I posted. [19:49:32] <wbs> ah. :-) [19:49:32] <hyc> first_picture [19:49:47] <hyc> and the wasteful init to first_picture=1 [19:49:55] <wbs> so, the lesson is, use existing code as example, unless when you shouldn't. :-) [19:50:01] <hyc> sigh.... [20:08:11] <lu_zero> wbs: ? [20:08:15] * lu_zero just wakes up [20:09:05] <lu_zero> hyc: \o/ thank you =) [20:09:17] <wbs> lu_zero: hyc commited a fix to the h264 parser, which spit out one warning per decoded frame earlier :-) [20:09:26] <wbs> .. as you found out yourself. ;P [20:10:33] <hyc> but the patch wasn't quite *perfect* ... doh [20:11:05] <lu_zero> add a ! and 1 and you are set or not? [20:12:35] <hyc> yep [20:14:28] <hyc> and now it's done. [20:14:33] <lu_zero> =) [20:15:05] <CIA-93> ffmpeg: hyc * r23364 /trunk/libavcodec/ (h264.h h264_parser.c): Cleanup prev commit, flag variable should start with 0 [20:20:13] <lu_zero> seems working nicely [20:22:34] <hyc> cool. [20:22:59] <hyc> now the only thing left in my tree is factoring out this extradata parsing for rtpenc_h264 [20:23:28] <wbs> don't we have the ffserver timestamp issue, still? [20:23:35] <hyc> hm, oh yeah [20:23:42] <wbs> I'll ping that thread [20:23:42] <hyc> I have the last patch you posted [20:26:21] <lu_zero> hyc: btw [20:26:42] <lu_zero> ffserver in rtp mode is just useful for on demand or I'm missing something? [20:26:53] <hyc> on demand or live [20:27:00] <lu_zero> how's set live? [20:27:11] <hyc> use ffmpeg to push something into feed.ffm [20:27:21] * lu_zero wants to hammer and compare it with dss and feng [20:27:38] <hyc> I posted some sample configs to the list already, lemme dig one up [20:29:07] <lu_zero> thank you [20:29:40] <lu_zero> btw wbs and hyc you both played with ffmpeg network protocols [20:29:46] <lu_zero> I need your opinion [20:29:52] <hyc> https://lists.mplayerhq.hu/pipermail/ffmpeg-devel/2010-May/088706.html [20:30:23] <lu_zero> I'm willing to add sctp to the supported protocols [20:31:01] <lu_zero> my main problem is that it has an interface for send and receive that you might consider similar to sendmsg [20:31:30] <lu_zero> and you want/need to get the additional control data [20:31:59] <lu_zero> where you'd store it? [20:32:48] <hyc> easy kludge - prefix the data [20:32:57] <hyc> I did this for LDAP over UDP [20:33:40] <hyc> the low-level recv just puts the control info in a fixed-size header in front of the data [20:34:05] <hyc> the higher level LDAP parser knows it's UDP and strips out the control info then falls thru to the regular LDAP message parsing [20:34:43] <lu_zero> that was the first way I thought [20:34:52] <josh_> e free encyclopedia [20:34:53] <josh_> Mikhail Romadin designed the space statio[B[B[B[B[B [13:34] [josh_(+i)] [2:freenode/#ffmpeg-devel(+cnt)] [Act: 1] -- more -- [20:34:57] <josh_> [#ffmpeg-devel] [20:35:00] <josh_> [13:34] [josh_(+i)] [2:freenode/#ffmpeg-devel(+cnt)] [Act: 1] -- more -- [20:35:03] <josh_> [#ffmpeg-devel] [20:35:04] <wbs> josh_: oops? ;P [20:35:09] <wbs> josh_: and hi :-) [20:35:12] <lu_zero> it is a bit annoying but... [20:35:15] <lu_zero> hi josh_ [20:35:27] <lu_zero> welcome =) [20:35:54] <lu_zero> well I'll need to specialcase it anyway [20:36:05] <CIA-93> ffmpeg: siretart * r23365 /branches/ (4 files in 4 dirs): [20:36:05] <CIA-93> ffmpeg: matroskaenc: Write codec time base as default duration for video tracks. [20:36:05] <CIA-93> ffmpeg: This isn't exactly semantically equivalent, but the field has already been [20:36:05] <CIA-93> ffmpeg: long abused to mean this, and writing it helps in determining a decent cfr [20:36:05] <CIA-93> ffmpeg: time base when transcoding from a mkv where the video codec stores none (VP8). [20:36:06] <CIA-93> ffmpeg: backport r23284 by conrad [20:37:57] <lu_zero> the other option was putting the data in the context [20:38:09] <lu_zero> so you read and then fetch it from there [20:38:38] <hyc> that sounds ok [20:42:06] <lu_zero> I need this since you can send over the same socket messages with a different stream id [20:42:52] <CIA-93> ffmpeg: alexc * r23366 /trunk/libavcodec/aaccoder.c: aacenc: Remove unnecessary variables and scopes in the TLS. [20:46:28] <CIA-93> ffmpeg: alexc * r23367 /trunk/libavcodec/aaccoder.c: Cosmetics: whitespace [20:53:14] <Compn> >we're new to working in the open source [20:53:14] <Compn> environment [20:53:24] <Compn> >gsoc running for 4+ years [20:53:25] <Compn> :P [20:55:29] <Yuvi> former on2 [20:56:13] <Compn> yeah, just funny :P [20:58:14] <Compn> diego requests open sourcing all on2 codecs? ahaha [20:58:22] <Compn> wishful thinking no doubt [20:58:50] <wbs> well, why are they naming their lib vpx if it isn't supposed to contain them all? ;-) [20:59:22] <peloverde> It's actually roman numerals, vp10 [20:59:31] <peloverde> 50% better than H.265 ;) [20:59:32] <wbs> ah, of course. ;P [21:02:06] <Vitor1001> some people get things so wrong [21:02:22] <Vitor1001> http://news.slashdot.org/story/10/05/28/2014200/Google-WebM-Calls-Open-Sour… [21:02:55] <Vitor1001> people really think that GPL incompatible => non-free?? [21:02:57] <Vitor1001> :p [21:03:05] <mru> freetards do, yes [21:03:21] <twnqx> when will they learn that the GPL is essentially non-free? :X [21:03:27] <peloverde> I believe it's two separate posts on the same topic amalgamated [21:04:20] <Dark_Shikari> gpl gives maximum freedom for developers at the expense of freedom for users [21:04:28] <Dark_Shikari> or er, the reverse [21:04:29] <Dark_Shikari> that's bsd [21:04:32] <peloverde> anyway should libvpx be under --enable-nonfree? [21:04:39] <Dark_Shikari> gpl gives maximum freedom for users at the expense of freedom for developers. [21:04:42] <Dark_Shikari> etc. [21:04:49] <Dark_Shikari> peloverde: that would be great. [21:05:08] <mru> or just ignore it [21:05:11] <mru> they're fixing the licence [21:05:13] <Vitor1001> peloverde: I think it would be under --enable-nonfree if google takes more than a week to solve it [21:05:19] <Dark_Shikari> ok, yes, that's better [21:05:23] <Dark_Shikari> if they can't fix it in due time [21:05:24] <Dark_Shikari> nonfree it [21:05:33] <Dark_Shikari> give 'em a few weeks. [21:05:52] <peloverde> Maybe if this were an organic release I'd want tot cut them some slack [21:06:04] <mru> organic? [21:06:06] <mru> wtf? [21:06:24] <Dark_Shikari> mru: no artificial flavorings. [21:06:35] <peloverde> but they did this cart before the horse special effects and puppies and rainbows big release from nowhere, and they have failed over and over again to get the little things right [21:08:17] <peloverde> If menno said he was "trying" to relicense libfaac would you move that out of enable-nonfree? [21:10:31] <Dark_Shikari> but google owns the code [21:10:33] <Dark_Shikari> they can relicense it [21:10:38] <Dark_Shikari> menno doesn't own the problematic code [21:10:39] <peloverde> and yet they haven't [21:11:29] <peloverde> I guess I missed the memo where we became part of the Google PR department? [21:14:05] <hyc> wbs: my mistake. currently the only timing patch I have in ffserver.c is to bypass the av_seek_frame [21:14:30] <hyc> and it's working... [21:14:56] <wbs> hyc: yeah, but I'm not sure that would work if we'd call the seek [21:15:09] <wbs> I see it this way: either we fully can assume start_time always is initialized [21:15:27] <wbs> OR, the if statement checking start_time absolutely needs an else clause doing something sensible [21:15:39] <hyc> good point [21:15:51] <wbs> in the former case, the if statement as such is unnecessary since we never should hit the else branch [21:16:15] <wbs> in the latter, we need to make sure the values are in the correct range regardless of start_time [21:30:46] <CIA-93> ffmpeg: alexc * r23368 /trunk/libavcodec/aaccoder.c: aacenc: Remove an unnecessary division from the TLS. [21:33:08] <DonDiego> say [21:33:18] <DonDiego> linuxtag clashes with the world cup... [21:33:30] <mru> fine with me [21:33:43] <mru> worse that it clashes with that damned air show [21:33:55] <mru> or whatever is eating hotels for breakfast [21:34:06] <lu_zero> .... [21:42:35] <janneg> DonDiego: I'm sure there will be inofficial public viewing [21:42:58] <kierank> put the football on the ffmpeg screens [21:43:23] <janneg> and if not we can organize it [21:44:19] <mru> if it's anything like here, there won't be many pubs _not_ showing the games [21:44:25] <DonDiego> there is simply no thing in this world that will make me miss the argentina game [21:44:28] <DonDiego> s [21:44:43] <DonDiego> well, childbirth, accidents and similar maybe.. [21:45:08] * mru locks DonDiego in a room without tv or internet [21:47:50] <lu_zero> DonDiego: ADDICTED! [21:48:17] <janneg> I was more thinking of the fairground as the match argentinia nigeria is 16:00 local time saturday [21:49:11] <DonDiego> yes [21:49:28] <DonDiego> i'm not addicted, i'm passionate [21:49:33] <mru> same thing [21:58:46] <BBB> he's in denial [21:59:32] <peloverde> It's an interesting game but it's no starcraft [21:59:44] <DonDiego> i'm in no state of denial at all [22:00:00] <kierank> what's the special thing between germany and argentina? [22:00:02] <DonDiego> there is no higher priority except life and death [22:00:15] <DonDiego> kierank: the history :) [22:00:17] <kierank> ofc over here it's england vs germany and england vs argentina [22:00:19] <DonDiego> also, i'm from argentina.. [22:00:24] <kierank> oh [22:00:47] <kierank> the argentina rivalry is maradonna and falklands based [22:01:44] <DonDiego> argentina - england, yes [22:02:05] <DonDiego> argentina - germany rivalry comes from 86/90 [22:02:21] <mru> Yuvi: mmx has no non-rounding avg? [22:02:27] <Yuvi> mru: nope [22:02:30] <mru> what a joke [22:03:03] <Yuvi> in fact, just mmx has no rounding avg either [22:31:56] <DonDiego> Yuvi: seen gmaxwell's mail? [22:32:12] <DonDiego> Yuvi: when was the last time you ran theora benchmarks? [22:32:21] <Yuvi> some time ago [22:32:24] <Yuvi> where? [22:32:41] <DonDiego> foms mailing list [22:32:50] <DonDiego> i think i CCed you on my reply, didn't i? [22:33:06] <Yuvi> the charts with ffmpeg a bit behind libtheora? [22:33:25] <mru> Yuvi: did the changes you did this week make much difference? [22:33:27] <Yuvi> iirc gmaxwell's machine/toolchain likes libtheora better [22:33:36] <DonDiego> yes, that one [22:33:55] <mru> Yuvi: how did he manage to find such a combination? [22:34:20] <Yuvi> mru: only the put_no_rnd should have any effect on speed [22:34:30] <DonDiego> well, it's his machine, he must have bought it considering that criterion [22:34:31] <DonDiego> ;) [22:34:38] <Yuvi> the dc one cut out a few instructions [22:35:04] <mru> Yuvi: what about skipping the loop filter when strength = 0? [22:35:19] <mru> sounds like it would be doing less work [22:35:31] <Yuvi> DonDiego: yeah, basically a while back we were benching on the same file in the same way, and my machine beat libtheora by 10% wheras on his libtheora won by 5% [22:35:37] <Yuvi> (approximately) [22:35:46] <Yuvi> mru: oh right, that [22:35:51] <DonDiego> weird.. [22:35:54] <mru> do you know what compiler he uses? [22:36:11] <mru> maybe he has a very noisy machine and picks the results carefully [22:36:28] <bcoudurier> Yuvi, FAST flag can be used [22:36:34] <bcoudurier> for non-bitexact optims [22:36:35] <Yuvi> that should give ~7-10% boost when the loop filter is done [22:36:42] <Yuvi> not done [22:37:18] <Yuvi> bcoudurier: same problem, are codecs allowed to set that? the bitexact selection is in dsputil [22:37:32] <bcoudurier> no [22:37:34] <bcoudurier> but user can [22:37:43] <bcoudurier> by default -> bitexact [22:37:46] <bcoudurier> fast -> fast [22:37:57] <Yuvi> mru: I doubt he's intentionally skewing the results [22:37:59] <bcoudurier> not necessarly bitexact [22:38:01] <mru> default bitexact would be very bad [22:38:15] <Tjoppen> BBB: poke btw [22:38:19] <mru> that would disable fast mpeg2 idct etc by default [22:38:21] <Yuvi> and he should be good enough to do benches fairly [22:38:27] <BBB> Tjoppen: sorry, haven't looked yet [22:38:33] <bcoudurier> default has always been to be bitexact [22:38:35] <bcoudurier> to the reference suite [22:38:36] <mru> Yuvi: I don't trust those people [22:38:36] <Tjoppen> k [22:38:39] <BBB> I'm trying to understand vp8... [22:38:43] <BBB> it's on my list [22:38:46] <Tjoppen> aren't we all :) [22:38:58] <mru> bcoudurier: only for codecs that have an exact definition [22:39:06] <bcoudurier> yes, the ones that matters [22:39:25] <mru> are you saying mpeg2, mpeg4, and all audio codecs are irrelevant? [22:39:47] <bcoudurier> these conform to the reference implementation AFAIK [22:39:56] <bcoudurier> ie libavcodec outputs the same [22:40:01] <mru> they are within the required limits, yes [22:40:14] <bcoudurier> theora should do the same [22:40:17] <mru> they are not exact even across different machines [22:40:35] <mru> much less against some reference code [22:41:42] <bcoudurier> it seems only mpeg2 switch unquant intra [22:41:48] <bcoudurier> depending on bitexact [22:42:01] <mru> the default idct is different [22:42:18] <mru> look at dsputil_init_mmx() or wherever it's set [22:42:20] <bcoudurier> since md5 match on every arch [22:42:26] <bcoudurier> I guess it's bitexact [22:42:37] <mru> the regtests use -flags +bitexact [22:42:47] <bcoudurier> yes so it only mpeg2 unquan intra changes [22:42:51] <bcoudurier> everything else stays the same [22:43:05] <bcoudurier> so the default is bitexact except for this case [22:43:37] <mru> well, grep for CODEC_FLAG_BITEXACT and see is affected by it [22:43:43] <mru> *what [22:43:56] <bcoudurier> unquant intra for mpeg2 function [22:44:19] <mru> and a bunch of other things [22:44:22] <mru> I don't remember them all [22:44:44] <mru> I get 33 matches [22:44:47] <bcoudurier> wmaenc, tiffenc, aacenc, acelp, lsp mjpegenc, mpeg4enc [22:45:10] <bcoudurier> and it's for the libavcodec ident [22:46:15] <mru> there's about a dozen matches in libavcodec/x86 [22:46:37] <mru> but that's beside the point [22:46:44] <mru> being slow by default is stupid [22:46:53] <mru> default should be as fast as possible within spec [22:47:11] <mru> even if that means varying across machines [22:48:33] <Dark_Shikari> Unless the spec involves being the same. [22:48:47] <mru> that's why I said "within spec" [22:51:51] <bcoudurier> yes I agree [22:53:27] <mru> hmm.. why so many branch mispredics in h264 loop filter? [22:53:36] <Dark_Shikari> because the C code is branchy? [22:53:59] <mru> the miss rate is disproportionately high there [22:54:19] <mru> and yes, I'm measuring the C code [22:55:14] <mru> it's also where most of the branches are happening [22:55:24] <Dark_Shikari> why use the c code, use asm [22:55:31] <Dark_Shikari> and of course the c code has tons of mispreds [22:55:59] <mru> I have reasons for doing this [22:56:09] <Dark_Shikari> explain them :) [22:56:14] <mru> someone is paying [22:56:40] <mru> this is just one of many tests [22:57:43] <mru> comparing some CPUs in different ways [22:58:02] <mru> using asm on some and not others wouldn't be fair [23:00:27] <BBB> if the asm is never used in practice, what's the use? [23:00:48] <Dark_Shikari> the c you mean [23:01:00] <BBB> well yeah, sorry :) [23:01:25] <mru> there isn't asm for all cpus [23:01:40] <BBB> yes, but the same cpu will consistently use the same asm [23:01:57] <mru> if the point is to compare branch prediction of different cpus? [23:02:17] <mru> this is just a sample load [23:02:19] <BBB> isn't that code-dependent? [23:02:26] <mru> of course it is [23:02:33] <mru> that's why this is only one of many tests [23:02:37] <BBB> in other words, you're using an artificial testcase that will never in reality be run on that cpu [23:02:49] <BBB> I won't bore you with my naiveness ;) [23:03:06] <mru> there is no asm written for the cpu I'm looking at now [23:03:14] <Dark_Shikari> but if it was to be used, asm would be written [23:03:24] <Dark_Shikari> and more importantly [23:03:31] <Dark_Shikari> the asm would have very different performance characteristics frmo the C [23:03:32] <BBB> maybe the company wants to create a cpu that-needs-no-special-asm [23:03:35] <Dark_Shikari> e.g. improving branch pred wouldn't help [23:03:38] <Dark_Shikari> BBB: then they fund orc [23:03:41] <mru> what the code does is unimportant [23:04:04] <BBB> I guess I sort-of- see the point [23:04:24] <mru> it's just a test of how the cpu behaves under this type of load [23:04:42] <mru> this tests happens to have many hard to predict branches [23:04:56] <mru> there's lots of code like that [23:16:20] <CIA-93> ffmpeg: bcoudurier * r23369 /trunk/libavcodec/h264.c: In h264 decoder, use jpeg yuv pixel format when full range is set in vui

1 0

IRC log for 2010-05-27
by irc＠mansr.com 27 May '10

27 May '10

[00:09:38] <ohsix> spillcam is looking at the topkill now [00:10:17] <ohsix> apparently they switched it to an ROV camera since i last looked [00:29:50] <hyc> Dark_Shikari: so, got enough useful data? [00:29:57] <hyc> keep in mind this is only 600MHz [00:32:42] <CIA-93> ffmpeg: michael * r23343 /trunk/ffplay.c: [00:32:42] <CIA-93> ffmpeg: Fix pts reordering code. [00:32:42] <CIA-93> ffmpeg: This fixes a regression introduced when libavfilter support was added to ffplay. [00:33:20] <Dark_Shikari> hyc: I got less than a 2x boost [00:33:21] <Dark_Shikari> dunno why [00:33:26] <Dark_Shikari> maybe the source file. [00:34:16] <Dark_Shikari> wtf your system doesn't have coreutils? [00:34:41] <hyc> the base install is pretty bare [00:34:45] <Dark_Shikari> lol no coreutils [00:35:02] <Dark_Shikari> "make install" doesn't even work =p [00:35:09] <Dark_Shikari> anyways you now have x264 [00:36:22] <hyc> thanks, but this is my test card, I usually wipe it out each time I start playing with it [00:36:28] <Dark_Shikari> :/ [00:36:29] <Dark_Shikari> why [00:37:22] <hyc> the OS hasn't been decvalred stable, each release changes a bunch of stuff [00:37:28] <hyc> easier to start over from scratch [00:37:39] <hyc> (declared) [00:38:13] <hyc> I have 4-5 SD cards I shuffle around with different OS images on them [00:38:27] <hyc> they all self-unpack using an AUFS filesystem [00:38:40] <hyc> you wipe out /home and it rebuilds itself [00:40:09] <hyc> it multiboots now too, there's an Android image and a Ubuntu image available [01:29:58] <CIA-93> ffmpeg: cehoyos * r23344 /trunk/libavcodec/options.c: [01:29:58] <CIA-93> ffmpeg: Some fields were incorrectly reset (to NULL) when calling avcodec_copy_context(). [01:29:58] <CIA-93> ffmpeg: Patch by Jean-Daniel Dupas, devlists shadowlab org [04:26:28] <jai> Warning: post-commit hook failed (exit code 1) with output: [04:26:29] <jai> error: Unable to append to .git/logs/refs/remotes/git-svn: Permission denied [04:26:32] <jai> mru: ^ [04:26:44] <CIA-93> ffmpeg: jai_menon * r23345 /trunk/libavcodec/utils.c: Cosmetics : Fix typo. [04:28:55] <jai> also, is roundup down? [04:38:24] <Compn> roundup is down [04:40:03] <CIA-93> ffmpeg: conrad * r23346 /trunk/libavcodec/vp3.c: vp3: Skip the loop filter when strength is 0 or when requested [04:40:03] <CIA-93> ffmpeg: conrad * r23347 /trunk/libavcodec/dsputil.c: Add more const to _l4 pixel functions [04:40:04] <CIA-93> ffmpeg: conrad * r23348 /trunk/libavcodec/ (dsputil.c dsputil.h): Add const to ff_emulated_edge_mc [04:40:04] <CIA-93> ffmpeg: conrad * r23349 /trunk/libavcodec/ (allcodecs.c vp8_parser.c Makefile): VP8 parser [05:54:47] <reynaldo> hi kostya [05:55:24] * thresh helloes back [05:58:05] <siretart> morning. [05:58:52] <kshishkov> hej hej [05:59:54] <reynaldo> time to get some sleep here. bye bye boys [06:24:52] <_av500_> gm fellow comrades [06:30:48] <kshishkov> guten morgen, kamerad _av500_ [07:18:24] <KotH> bon giorno [07:34:20] <Tjoppen> morrn [07:37:03] <kshishkov> god morgon [09:04:01] <lu_zero> hi _av500_ [09:31:12] <pJok> god morgon, kshishkov :) [09:33:14] <kshishkov> goda morgnar, pJok [09:44:48] <Tjoppen> looks like I have an interesting task ahead of me: writing an LXF demuxer [09:48:01] <KotH> LXF? league of extraoridnary furries? [09:48:23] <Tjoppen> proprietery format be Harris/Leitch [09:48:25] <kshishkov> loony exchange format is more likely [09:48:26] <Tjoppen> *by [09:48:49] <Tjoppen> which we'll preferrably want to support by adding to libavformat [09:49:29] <KotH> who's "we"? [09:50:54] <kshishkov> Kodbruk AB från Umeå? [09:51:13] <Tjoppen> indeed. well, our customer [09:56:46] <spaam> kshishkov: allt bra idag? :) [09:56:59] <kshishkov> spaam: kanske [09:57:26] <kshishkov> det ska komma klart imorgon [09:58:24] <spaam> ok :) [10:22:58] <KotH> .o0(why is it, that whenever i read "idag" i think of "ideg"?) [10:23:23] <kshishkov> KotH: because you are not FFmpeg dev and you don't know Swedish [10:23:35] <pJok> hehe [10:23:37] * mru suspects the latter has more to do with it [10:24:26] <KotH> kshishkov: i know the meaning [10:24:30] <KotH> kshishkov: still, i think of ideg [10:25:14] <mru> knowing the meaning is not knowing the language [10:25:53] <KotH> well, nobody thaught me swedish yet [10:26:08] <mru> nor english spelling, it would seem... [10:26:19] <mru> (it's "taught") [10:26:30] <mru> and "thought" of course [10:27:31] <kshishkov> KotH: same story here [10:29:35] <KotH> mru: the last words of my english teacher in high school were: "i'm glad that we dont have an english exam this year. you'd fail horribly" [10:29:55] <mru> last words? before you killed him? [10:30:17] <kshishkov> mru, he won't admit that on public [10:36:09] * KotH wouldnt even admit it in private [10:36:47] <KotH> np: kaji meiko - shura no hana [10:40:28] <mru> !translate [10:41:56] <mru> http://www.theregister.co.uk/2010/05/27/html5_hype/ [10:45:01] <lu_zero> yawn? [10:45:08] <iive> KotH: you think of ideg, because you are still mplayer developer. [10:48:41] <dezodorant> hi, what`s wrong with roundup? [10:50:13] <twnqx> "invoice for server was eaten by spam assassin" [10:55:02] <dezodorant> OM NOM NOM NOM [11:24:47] <KotH> mru: do you know lady snowblood? [11:24:56] <KotH> mru: or have you seen kill bill? [11:25:24] <mru> no, yes [11:25:48] <KotH> do you remember the japanese song that was always playing? [11:26:11] <mru> too long since I watched it [11:29:48] <jai> KotH: which one? [11:29:59] <jai> KotH: the "theme"? [11:30:16] <merbzt> battle without honor [11:30:25] <jai> yeah, tomayasu hotei [11:31:02] <KotH> jai: see dcc :) [11:31:24] <jai> ah [11:37:23] <dezodorant> how to switch off swscale build ? [12:22:32] <dezodorant> still not fixed build without filters [12:22:40] <dezodorant> ffmpeg.c:1657: undefined reference to `av_vsrc_buffer_add_frame' [12:27:14] <kshishkov> send a patch [12:44:03] <Tjoppen> does writing demuxers for subtitles (.srt for instance) seem like a good idea? [12:44:32] <kshishkov> nope, it's raw data [12:44:37] <kshishkov> you need just parser [12:50:05] <merbzt> would be nice if it would be possible to render subtitles and convert them to bitmaps [12:50:29] <merbzt> for later muxing or hard rendering [12:50:40] <Compn> text2bitmap ? [12:50:45] <Compn> srt2vobsub that is [12:50:49] <Compn> probably exists already [12:51:07] <merbzt> but not on thefly in ffmpeg [12:51:12] <Compn> no, not in ffmpeg :) [12:51:37] <Tjoppen> not quite sure what parsers do actually. but aren't they automatically inserted when opening demuxers? [12:51:42] <jai> sub overlay would be nice [12:51:54] <Tjoppen> since there's no demuxer for say .srt, ffmpeg can't make sense of it [12:53:04] <Compn> oh you want a subtitle renderer for ffmpeg ? [12:53:16] <Compn> isnt there an -scodec copy now ? [12:53:19] <Tjoppen> no, I just want a subtitle stream out of a file [12:53:58] <Compn> yeah ffmpeg has -scodec now :) [12:53:58] <Tjoppen> in this case, imagine having subtitles in a separate file and wanting to mux them as well [12:54:22] <Compn> well you want this then ? `-newsubtitle' [12:54:22] <Compn> Add a new subtitle stream to the current output stream. [12:55:15] <Tjoppen> yes, but from where does ffmpeg take the subtitles now? I know that there's various demuxers that produce them, but there are no "demuxers" that simply take some of the standard text/binary formats [12:56:33] <Tjoppen> I imagine it'd quite easy to write say a .srt demuxer that outputs just one stream - AVMEDIA_TYPE_SUBTITLE, with correctly timestamped packets or something similar [13:15:34] <Tjoppen> I hear no protests to such an approach. maybe I should write a proof-of-concept demux though [13:15:41] <Tjoppen> +er [13:27:59] <janneg> argh, could we please merge ffmpeg and libswscale git repos. git bisect is unuseable [13:28:36] <janneg> especially when libswscale doesn't build [13:28:57] <siretart> janneg: yes, please! [13:29:12] <kshishkov> well, I think we'll get fully LGPLed swscale soon, probably it can be merged into one repo [13:29:30] <mru> that has nothing to do with it [13:29:55] <mru> the merge can't happen until ffmpeg switches fully to git [13:30:08] <mru> _and_ mplayer stops importing bits of ffmpeg as svn externals [13:30:18] <siretart> then let's finally do that! [13:30:22] <thresh> mplayer could easily stop doing that, when ffmpeg goes git [13:30:31] <mru> nothing is easy in mplayer [13:30:39] <thresh> rm -rf /var/lib/svn/ffmpeg [13:31:20] <mru> doing a proper merge of the repos requires a fair amount of manual work [13:31:37] <mru> to tidy up the result of ugly rcs file renames in cvs days [13:31:55] <mru> it would probably take me a day to do it [13:32:04] <mru> and I'm only going to do it _once_ [13:32:10] <janneg> I'm volunteering [13:32:17] <mru> that's not the issue [13:32:20] <mru> I'll do the work [13:32:27] <mru> but I'm not going to do it in vain [13:32:52] <mru> and a merged git-svn repo isn't possible [13:33:05] <mru> and as I said, it requires cooperation from mplayer [13:33:12] <mru> or we could just piss them off [13:33:33] <elenril> mru: by breaking mplayer you'd help uau ;) [13:34:03] <mru> at this point I don't really care [13:34:08] <mru> mplayer is doomed regardless [13:34:35] <elenril> yeah, ffplay will kill it [13:34:40] <mru> well, no [13:35:16] <elenril> unless you're trolling i fail to see how mplayer is doomed [13:35:26] <elenril> looks just fine to me [13:35:40] <mru> mplayer served a purpose for a while [13:36:09] <mru> now it's been displaced by vlc as the "default" video player [13:36:25] <elenril> lolvlc [13:36:33] <mru> millions use it [13:36:40] <janneg> mru: we could provide a svn mirror of the git repo like the git mirror of the svn repo know for mplayer [13:36:49] <mru> janneg: much harder [13:37:15] <mru> and I have no desire to do that [13:37:36] <elenril> meh, don't bother with mplayer [13:37:45] <mru> that what I said [13:37:50] <elenril> it can just backport the fixes from uau's fork [13:37:55] <elenril> or write their own [13:37:55] <mru> we could just piss them off and let them fix their shit [13:37:59] <mru> which they won't [13:38:49] <pJok> isn't mplayer only good for testing binary codecs? [13:39:00] <mru> no idea [13:39:03] <mru> I don't do that [13:39:40] <BBB> wbs: josh's patch is probably ok, completely (see my reply and the link therein) [13:40:47] <pJok> mru, i'd say you shouldn't keep things running just because others use it if its blocking progress in your end... [13:41:03] <mru> that's only one of many problems [13:41:22] <mru> and even if I don't really care about mplayer, I'd rather not be flogged by diego for breaking it [13:41:47] <mru> there's also the issue of diego and michael being pretty much set against git [13:42:55] <elenril> vote about it? [13:44:16] * pJok hands mru a plunger and a spanner [13:45:00] <kshishkov> pJok: MPlayer has a nice default GUI in my opinion [13:45:05] <thresh> cvlc also [13:45:35] <pJok> kshishkov, isn't that just a matter of taste? [13:45:41] * pJok doesn't really like the gui of vlc [13:45:48] <pJok> but im used to it, so can't really complain [13:46:12] <janneg> I think it's safe to ignore diego. if he cares deeply about fixing commit messages we could require git format-patch patches for review [13:46:13] <BBB> mplayer has a gui? [13:46:27] <thresh> pJok: cvlc has a nice default gui [13:46:55] <kshishkov> BBB: the lack of gui is the best gui IMO [13:47:36] <thresh> that's why kshishkov uses telnet to IRC [13:47:46] <elenril> janneg: or we could have a development and a "stable" branch [13:48:05] <kshishkov> thresh: ssh + irssi in screen actually but that's all TUI [13:48:18] <thresh> kshishkov: ты не труъ. [13:48:39] <kshishkov> thresh: я и не претендую [13:51:25] <KotH> mru: if i'd be you, i'd rather fear the warth of some japanophile turkish guy living in switzerland... he'd not be very happy if you'd break mplayer [13:51:35] <KotH> ;) [13:53:16] <kshishkov> KotH: "wrath" is more fearful than "warth" [13:54:59] <j-b> ohoh, ogg vs webm on webm-discuss... !summon troll [13:54:59] <Tjoppen> I read it like "warmth" [13:55:22] <KotH> j-b: rotfl [13:55:24] <kshishkov> j-b: do we have webm trolls? [13:55:36] <janneg> elenril: how does that help with bad commit msg? stable is development with fixed commit msg? [13:55:37] <KotH> Tjoppen: the warmth of a few thousand suns exploding ;) [13:56:48] <Tjoppen> hehe [13:57:30] <BBB> ooooo [13:57:33] <BBB> j-b: link? [13:57:48] <janneg> https://groups.google.com/a/webmproject.org/group/webm-discuss/browse_threa… [13:57:50] <j-b> https://groups.google.com/a/webmproject.org/group/webm-discuss/browse_threa… [13:57:53] <j-b> rah [13:58:09] <j-b> sorry for the fail [13:59:10] <peloverde> Happy Thursday! [14:00:20] <BBB> peloverde: awesome response :) [14:00:27] <BBB> but that's no discussion or trollwar [14:00:34] <BBB> it'll become one, though [14:00:38] <BBB> but it isn't qualified as one, yet [14:01:28] <kierank> i was also expecting a flamefest, not some burning embers [14:05:49] <peloverde> "Suggestions regarding fragmentation and extensions" is a much better troll thread but it is strangely absent from the archives [14:07:41] <Kovensky> < Kovensky> jfs: also, it could be worse, they could have used ogg as webm's base < Mandarinka> would be .webo? < Mandarinka> .weboshi < PharaohAnubis> Mandarinka those names would rly suit it [14:07:46] <Kovensky> lulz [14:08:17] * Kovensky didn't even know about that webm-discuss thread ._. [14:08:18] <kierank> https://groups.google.com/a/webmproject.org/group/webm-discuss/browse_threa… [14:08:21] * kshishkov reads last extension as .webohshit [14:08:35] <Kovensky> kshishkov: you're doing it right [14:08:48] <dezodorant> orly? [14:09:03] <kierank> lol monty I'm biased and [14:09:03] <kierank> I do think Ogg would have been a better technical choice for WebM [14:09:09] <j-b> because it would be called webo ? [14:09:13] <j-b> LOL [14:09:29] <mru> I happen to know why they chose matroska [14:10:35] <Kovensky> it's lulz how people say WAV is PCM audio [14:10:37] <mru> quoting a google doc: "Ogg has many issues with the format." [14:10:44] <Kovensky> +uncompressed [14:11:19] <kshishkov> mru: I think I quote your blog with the same phrase [14:11:30] <Kovensky> > Are you in favor of dropping support for Ogg on VLC as well? :) [14:11:30] <Kovensky> You know what? I wish we could. [14:11:33] <Kovensky> j-b++ [14:12:25] <Kovensky> "I do support Ogg as a WebM container." <-- ... [14:12:33] <Kovensky> oh well, will read the rest later [14:12:36] <Kovensky> gotta run :V [14:22:23] <BBB> j-b: if you ever wondered why ffmpeg developers like you [14:22:27] <BBB> j-b: now you know ;) [14:42:45] <Kovensky> https://groups.google.com/a/webmproject.org/group/webm-discuss/msg/8d3c0e90… <-- ... wow [14:42:55] <Kovensky> why do I still get impressed by the tardness of freetards [14:43:16] <kierank> i lol'd at that one too [14:43:42] <Kovensky> the only thing remotely sane he said is FLAC, but that's still unrealistic considering today's broadband quality and coverage [14:44:37] <mru> putting the t in tard... [14:47:20] <CIA-93> ffmpeg: alexc * r23350 /trunk/libavcodec/aacenc.c: Mark AAC encoder as experimental. [14:47:38] <BBB> some parts of the VP8 spec make you wonder what highschool student wrote it [14:47:43] <BBB> "Otherwise (when the above bool is true), we are using inter-prediction (which of course only happens for interframes), to which we now restrict our attention." [14:48:03] <mru> lol [14:48:08] <BBB> that sentence alone is a death sentence in scientific publishing... imaging a book containing that sentence [14:48:16] <BBB> *iamgine [14:48:19] <BBB> god damn it :) [14:48:22] <BBB> *imagine [14:48:26] <kshishkov> BBB: on the contrary, high school students demonstrated their ability to analyze VP8 [14:48:36] <mru> kshishkov: college [14:48:46] <BBB> 3rd yr college, even [14:49:05] <kshishkov> mru: what rank of school is that? [14:49:20] <mru> after high-school [14:49:41] <kshishkov> how'd you call KTH then? [14:49:50] <superdump> don't they leave high school at 18 in the US? [14:49:51] <mru> university [14:50:02] <BBB> superdump: yes [14:51:10] <CIA-93> ffmpeg: alexc * r23351 /trunk/libavcodec/aac.c: [14:51:10] <CIA-93> ffmpeg: aacdec: Clarify a channel mapping comment. [14:51:10] <CIA-93> ffmpeg: Patch by Cyril Russo >stage nexvision laposte net< [14:51:23] * kshishkov is always confused about foreign education system. His was simple as a brick and as effective as a brick [14:52:00] <peloverde> The ogg trolls have finally woken up... [14:52:10] <peloverde> "I hope the reason is not because it has better DRM support..." [14:52:14] <mru> ready the flamethrowers [14:52:49] <kshishkov> maybe they really didn't want to turn VP8 into Theora 2 [14:53:19] <peloverde> It can't be, libtheora is GPL compatible ;) [14:54:41] <BBB> awesome, freetard flamewar [14:54:46] <BBB> this is like a bitchfight, but better [14:57:05] <siretart> how is mental masturbation better than a bitchfight? [14:57:46] <_av500_> peloverde: url? [14:57:59] <janneg> https://groups.google.com/a/webmproject.org/group/webm-discuss/browse_threa… [14:58:47] <kshishkov> siretart: by cutting out intermediate step [14:59:55] <BBB> Yuvi: is golden2 altref? [15:00:24] <Yuvi> BBB: sure, feel free to rename it (just copied it from vp56) [15:00:47] <BBB> it's fine, for now [15:01:17] <BBB> so now how do I commit? if it's easier/safer I can email to you also [15:01:26] <BBB> s/commit/push/ [15:01:31] * kshishkov predicts "silver frame" in VP9 used as not-for-display reference P-frame and "dirt frame" i.e. no-displayed B-frame (just to eat bits) in VP12 [15:01:38] <Yuvi> git push should work now [15:02:29] <BBB> You can't push to git://github.com/yuvi/ffmpeg.git [15:02:29] <BBB> Use git@github.com:yuvi/ffmpeg.git [15:03:07] <Yuvi> oh, guess you cloned the read-only url, try replacing that in .git/config [15:03:44] <BBB> url = git://github.com/yuvi/ffmpeg.git? [15:03:49] <Yuvi> yeah [15:03:56] <BBB> I replace that with... rbultje(a)github.com/yuvi/ffmpeg.git? [15:04:11] <BBB> or git://rbultje@..? [15:04:21] <Yuvi> git@github.com:yuvi/ffmpeg.git I guess [15:04:57] <Yuvi> whatever's on http://github.com/yuvi/ffmpeg/ for the ssh url for you [15:05:35] <peloverde> Google suggests using altref for a fixed background to do MPEG-4 style composition [15:06:24] <BBB> git gui is nice [15:06:56] <BBB> ! [rejected] vp8 -> vp8 (non-fast forward) [15:07:24] <Yuvi> try git pull origin/vp8 --rebase first then [15:08:25] <Yuvi> or git pull --rebase origin vp8 even [15:08:47] <BBB> origin/vp8 [15:09:13] <BBB> refusing to pull with rebase: your working tree is not up-to-date [15:09:43] <BBB> does that mean I have local commits pending? (I do) [15:09:47] <Yuvi> yeah [15:09:55] <BBB> I don't want to commit it yet [15:09:58] <Yuvi> git stash git stash apply [15:10:03] <Yuvi> around the git pull [15:11:04] <BBB> right [15:11:29] <BBB> did it work? [15:11:35] <BBB> I tried to push something [15:11:41] <Yuvi> http://github.com/yuvi/ffmpeg/commit/f36a144aee6642cbc47d5621e24a24825d2a29… yep [15:12:45] <BBB> \o/ [15:12:56] <BBB> ok, now I should actually write some code [15:14:04] <peloverde> once you git used to git your vc headaches to code writing ratio will approach zero [15:14:38] <peloverde> And I hear git 2 will just look at the spec and write the code itself ;) [15:15:07] <BBB> then the code will be very buggy for vp8 [15:15:47] <peloverde> I didn't even bother to send my list of PS spec/software issues to MPEG :( [15:16:05] <BBB> I would imagine you have enough on your mind already [15:23:33] <lu_zero> BBB: =) [15:24:51] <BBB> ooo, GitX is nice alos [15:26:23] <lu_zero> uhmm [15:26:42] <lu_zero> who is going to chip in that thread and just say "because ogg sucks" ? [15:27:42] <_av500_> i would ride the drm wave a bit 1st [15:27:59] <kshishkov> that would be throwing a pack of yeast into cesspool on hot day [15:34:22] <lu_zero> today I felt bored =P [15:35:14] <lu_zero> BBB: the spec vp8 is really nice as a code walkthrough and I'm afraid that's what was when it started [15:36:07] <_av500_> lu_zero: \o/ [15:37:27] <BBB> lu_zero: that's exactly what it is, yeah [15:37:57] <peloverde> What's the license on the spec? [15:38:44] <BBB> it's a spec [15:38:54] <Yuvi> still has a license: http://www.webmproject.org/license/bitstream/ [15:39:02] <BBB> that's the patent license [15:39:11] <BBB> the code fragments are whatever you want [15:39:14] <BBB> which is funny [15:39:21] <BBB> because the same code in the reference decoder is BSD [15:39:29] <lu_zero> btw that mailinglist is a trollnest [15:39:30] <BBB> the patent licenses are also different [15:40:35] <lu_zero> I wonder how the google devs could be as gentle while they have such idiots complaining about ie6 support in the website or claiming that they are forking everything when they provided patch... [15:41:32] * peloverde still can't believe that he defended the vp8 launch [15:41:42] <Yuvi> would be nice if they fixed the css, web pages that do http://i.imgur.com/IiN2Q.png are annoying [15:42:23] <BBB> peloverde: so now... really [15:42:28] <BBB> peloverde: are you paid by google? :-p [15:42:36] <BBB> you are VERY present on everything-google [15:42:48] <BBB> I remember you being on all chrom{e,ium} MLs also [15:43:11] <BBB> either that or you are a googl3>r [15:43:37] <mru> a gootard... [15:43:39] <peloverde> It's more that i dislike mozilla [15:44:01] <lu_zero> theehhe [15:44:24] <merbzt> I like that they send me a new tshirt every year [15:44:40] <merbzt> 2 last year [15:44:43] <lu_zero> mru: how's going? [15:46:15] <BBB> I don't dislike mozilla [15:46:35] <BBB> but mozilla is a typical free software project gone wrong, where vocal minorities rule the public opinion (or perceived opinion) of the project [15:46:50] <lu_zero> so what's the solution? [15:46:59] <_av500_> shotgun? [15:46:59] <BBB> go corporate, shut them up or fire them [15:47:08] <BBB> shotgun also works, but leaves trails [15:47:15] * lu_zero considers webkit nicer right now [15:48:05] <lu_zero> right now I wonder if wildfox will really develop [15:48:23] <lu_zero> and if they will really integrate lav* into it [15:48:27] <peloverde> I used to be very pro Mozilla, it was the first free software project I did anything with [15:48:35] <BBB> weren't they discussing which "media framework" to use? [15:48:37] * lu_zero as well [15:48:53] <BBB> if you can't even get that question sorted out before launch, well, then you're a typical free software project going nowhere ;) [15:49:02] <peloverde> But I always felt like I was relegated to a second class in regard to access not being a netscape employee [15:49:16] <lu_zero> BBB: they have two options: gst to use native codecs or ffmpeg and ignore the rest [15:49:31] <BBB> what's a native codec? [15:49:45] <lu_zero> BBB: system ones [15:49:50] <BBB> what's a system one? [15:50:05] <BBB> is gst-plugins-base a system one? [15:50:18] <BBB> or do you mean "directshow for win32 or quicktime for mac"? [15:50:41] <lu_zero> the dshow and quicktime [15:51:01] <BBB> don't forget gst is trying to position itself as "native for linux/unix/..." [15:51:13] <BBB> which is kind of silly since it doesn't provide any codecs by itself [15:51:21] <peloverde> The mozilla trademark policy is what really pushed me over the edge [15:51:44] <peloverde> that and their claim of multi-process architecture being unfeasible until chrome did it [15:51:44] <lu_zero> eh [15:52:30] <lu_zero> they always said that multi-process would take a long time since they'd need to cleanup too much [15:52:39] <lu_zero> so wasn't lying [15:53:07] * lu_zero would be happier if they refactored a bit more [15:55:26] <peloverde> I don't want excuses I want a browser that works, and it's interesting how many former high profile Mozilla people jumped ship to WebKit based browsers [15:58:37] * mru shoots gst [15:59:42] <lu_zero> gst improved a lot over time but has an hype aura similar to the xiph one... [16:03:18] <hyc> the mozilla code has been unmaintainable for probably 80% of its existence [16:03:32] <hyc> jumping ship to webkit is a no-brainer [16:03:53] <mru> 80% of its existance, starting from the beginning [16:03:57] <mru> not when it was opened [16:04:28] * mru remembers the dec compiler on tru64 having a special "netscape mode" [16:04:34] <hyc> probably. when you see stuff in their bugzilla from 1999, marked as critical/next release, still unfixed, you know theyv'e got problems [16:04:48] <mru> basically using 32-bit pointers and forcing it to low address space [16:05:01] <peloverde> but the NGLayout (Gecko(TM)) rewrite was unmaintainable [16:05:11] <mru> hyc: better than gcc [16:05:18] <mru> gcc down-mark bugs they don't like [16:05:40] <mru> 'cause you can't have critical bugs open for too long [16:06:40] <peloverde> what about lowering bug priority so they can do a release with zero P1s? [16:06:54] <mru> that's what I'm talking about [16:08:43] <peloverde> Mozilla also created this ridiculous XPCOM interface only to rip it out a few years later https://wiki.mozilla.org/Gecko:DeCOMtamination [16:08:52] <hyc> even better is reading the history and seeing a bug get assigned to one engineer, sitting for a couple years, and having to be assigned to another 'cause the first guy left the project without ever working on the issue [16:08:52] <peloverde> kind of reminds me of bonobo [16:09:25] <hyc> and of course, most of that was happening while it was still a commercial effort [16:09:32] <BBB> bonobo :D [16:09:34] <mru> that was a mad time in general [16:09:42] <mru> corba... eeew [16:09:47] <BBB> typical case of overoveroverengineering [16:09:54] <BBB> nobody, even its inventors, wanted to work with it [16:10:19] <BBB> evolution is the only app using it, and it's so complex and incomprehensible that it took a good 5 years to de-bono'ify it after bonobo was deprecated [16:10:32] <BBB> of course nobody wants to hack on evolution either ;) [16:17:04] <BBB> again lol @ vp8 reference: "Much of the process is more easily described in C than in English." [16:17:16] <BBB> (and then it c/p's a whole .c file as "documentation") [16:18:27] <hyc> well, a lot of specs illustrate using pseudo-code. mebbe they decided that's too imprecise. [16:18:44] <hyc> still, it's bad form to make an "illustration" a normative part of a spec. [16:19:10] <Yuvi> for dequant, they paste the two tables and say that they're modified somehow, go look at quant_common.c [16:19:38] <Yuvi> that's just lazy [16:50:50] <Kovensky> <@Yuvi> git stash git stash apply <-- don't use apply, use pop (unless you want to still keep the changes stashed even after the apply) [17:11:36] <lu_zero> mru: did you find a sane hotel? [17:12:28] <CIA-93> ffmpeg: michael * r23352 /trunk/libavformat/utils.c: [17:12:28] <CIA-93> ffmpeg: Make sure that when the parser is feeded with frame==packet that the [17:12:28] <CIA-93> ffmpeg: packets are passed through and wont be marked as static which would [17:12:28] <CIA-93> ffmpeg: require them to be copied by av_dup_packet(). [17:12:57] <mru> I managed to book a room in "Ivbergs Charlottenburg" through hrs.de [17:13:07] <mru> the hotel's own website said it was full [17:22:14] <lu_zero> now even hrs.de says that's full [17:22:46] <mru> is there something else going on besides linuxtag? [17:22:54] <mru> it's not usually this hard to find hotels [17:26:03] <lu_zero> no clue [17:31:15] <janneg> yes, ILA. berlin air show [17:31:53] <lu_zero> uh? [17:33:01] <osaft> ther is also the DMY Design Festival at this time [17:33:06] <osaft> there* [17:35:51] <janneg> http://www.ila-berlin.com [17:36:10] <janneg> internationale Luftfahrt Austellung [17:36:32] <peloverde> Reddit: The blind leading the stupid? http://i.imgur.com/LEcme.png [17:36:46] <mru> janneg: linuxtag overlapped with that a couple of years ago [17:36:57] <mru> the hotel situation now is awful [17:37:59] <mru> peloverde: lol [17:38:00] <janneg> I think the first one berlin did [17:38:11] <janneg> +in [17:52:09] <Kovensky> you guys should all just drop linuxtag and go to the air show [17:52:12] <Kovensky> planes > linux [17:52:27] <kierank> true [17:53:41] <BBB> oil > planes [17:56:23] <jai> girls > oil? [17:56:42] <mru> girls+oil [17:56:44] * mru runs [17:57:25] <lu_zero> obviosuly > * [17:58:47] <jai> lol [18:45:16] <peloverde> sigh, the AAC channel model rears its ugly head again [18:46:57] <peloverde> and roundup is down so I can't even see the original bug report [18:49:08] <ohsix> isn't getting that back up a priority? heh [18:49:38] <ohsix> does roundup cc bugmail to somewhere you can search? [18:50:49] * Kovensky wonders how to do cheap struct RTTI in C [18:55:04] <peloverde> It boggles my mind how menno thought an instance tag didn't need to be unique [18:56:01] <ohsix> menno? [18:57:00] <Kovensky> ohsix: faad / faac's author, nero employee [18:58:21] * kshishkov may meet Menno some day [19:00:00] <kshishkov> and mru has seen Ivan Dimkovic, another AAC encoder creator who worked at Nero [19:02:19] <peloverde> Ivan Dimkovic wrote some worthwhile papers [19:02:49] <kshishkov> yes, that's what I remember about him [19:03:38] <peloverde> several of my ffaacenc improvements were taken from "IMPROVED ISO AAC CODER" and his IEEE(?) paper [20:41:01] <CIA-93> ffmpeg: siretart * r23353 /branches/ (4 files in 2 dirs): [20:41:01] <CIA-93> ffmpeg: change author metadata to artist in mov de/muxer [20:41:01] <CIA-93> ffmpeg: backport r23266 by bcoudurier [20:47:55] <CIA-93> ffmpeg: siretart * r23354 /branches/ (0.6/libavformat/movenc.c 0.6): [20:47:55] <CIA-93> ffmpeg: write 3gp perf tag for artist metadata [20:47:55] <CIA-93> ffmpeg: backport r23268 by bcoudurier [20:48:38] <CIA-93> ffmpeg: siretart * r23355 /branches/ (0.6/libavformat/aea.c 0.6): [20:48:39] <CIA-93> ffmpeg: Fix detection of some stereo atrac files by not comparing the [20:48:39] <CIA-93> ffmpeg: block size mode and info byte. [20:48:39] <CIA-93> ffmpeg: backport r23272 by banan [20:48:39] <CIA-93> ffmpeg: siretart * r23356 /branches/ (0.6/libavformat/aea.c 0.6): [20:48:39] <CIA-93> ffmpeg: Reduce the score for the aea demuxer probing function. [20:48:40] <CIA-93> ffmpeg: backport r23273 by banan [21:10:53] <peloverde> Anyone ever used SceneScope? [21:22:29] <DonDiego> *sigh* [21:22:41] <DonDiego> mru: how is your dsputil splitup coming along? [21:22:44] <bcoudurier> is it usual to have H.264 using full range yuv ? [21:23:00] <_av500_> peloverde: no, but give me a copy if you have one :) [21:23:12] <Dark_Shikari> bcoudurier: it happens [21:23:12] <DonDiego> on highly parallel builds dsputil.c and motion_est.c take longer to build than ALL THE REST of libavcodec.. [21:23:20] <mru> DonDiego: haven't done anything on that lately [21:23:21] <_av500_> DonDiego: yup [21:23:41] <mru> but I'll get back on it [21:23:48] <DonDiego> great [21:23:55] <CIA-93> ffmpeg: conrad * r23357 /trunk/ (6 files in 3 dirs): On2 IVF demuxer [21:24:05] <mru> right now I need to concentrate on paid work [21:24:09] <_av500_> i used to hack up dsputil severly in the past to get a small build [21:24:09] <bcoudurier> ah [21:24:16] <bcoudurier> and how is it handled ? [21:25:13] <DonDiego> _av500_: submit :) [21:26:01] <_av500_> DonDiego: what part of "hackep up" did you not understand? ;) [21:26:06] <_av500_> hacked [21:26:28] <DonDiego> :) [21:30:05] <peloverde> sigh, scenescope like most of it's peers it spits out a few fields from the headers and bufffer/bitrate info only [21:40:49] <peloverde> At some point I should just finish these AAC analysis tools I'm making and sell them :) [21:41:05] <Dark_Shikari> what do you need checked? [21:41:08] <Dark_Shikari> I have an analzyer that says it does aac [21:41:35] <peloverde> I need something that visualizes windowing and scalefactors [21:41:51] <Dark_Shikari> It might. This is a ridiculously good program [21:41:58] <Dark_Shikari> it does the equivalent for h264 [21:42:05] <Dark_Shikari> well, ridiculously good except for all the bugs and slowness [21:42:16] <Dark_Shikari> but what can you expect from a rebranded analyzer that pirates coreaac [21:42:16] <peloverde> Pretty much everything I've found so far prints out the headers and does buffering analysis [21:42:33] <Dark_Shikari> lemme see here. [21:43:00] <peloverde> So I've slowly been gluing the reference decoder to pylab [21:44:09] <Dark_Shikari> wow, it does indeed do nothing at all. [21:44:11] <Dark_Shikari> that's useless [21:44:23] <Dark_Shikari> It's really weird, why do all the video tools have so many features, but their audio parts have none? [21:44:53] <peloverde> i've been wondering the same thing [21:53:16] <bcoudurier> Dark_Shikari, interesting, what tool is it ? [21:53:37] <Dark_Shikari> cma1820 [22:13:40] <bcoudurier> looks nice [22:18:45] <spaam> so in .pl they play this game at school http://www.thenews.pl/national/artykul132388_game-in-secondary-school-gets-… [22:19:05] <mru> spaam: keep that stuff in #the-alliance [22:20:04] <spaam> ok :) [22:22:02] <lu_zero> ... [22:24:19] <mru> others: don't go there, it is a silly place [23:54:40] <DonDiego> gnite

1 0

IRC log for 2010-05-26
by irc＠mansr.com 26 May '10

26 May '10

[00:01:23] <janneg> mru: your math is flawed. 1 * 1.25 * 0.75 = 0.9375 [00:01:49] <mru> no, gcc math is flawed [00:02:41] <mru> I got it [00:02:53] <mru> you can't do the calculation like that [00:03:02] <mru> suckage is sort of inverted quality [00:03:19] <mru> so sucking 25% more means being 25% less good [00:03:32] <mru> thus 4.4 is 25% less good than 4.3 [00:03:38] <mru> and 4.5 is 25% more good than 4.4 [00:03:50] <mru> and it all works out [00:04:52] <janneg> sure [02:42:30] <Compn> is james zern in here? [04:21:25] <CIA-93> ffmpeg: alexc * r23332 /trunk/ (4 files in 2 dirs): Add an AVSTREAM_PARSE_FULL_ONCE parsing mode to parse headers and combine packets once and only once. [04:23:43] <CIA-93> ffmpeg: alexc * r23333 /trunk/libavformat/asfdec.c: Parse and repack the first frame of H.264 in ASF because SPS+PPS lives in its own packet. [05:24:27] <Dark_Shikari> Yuvi: fyi, gmaxwell (iirc) showed me a graph the other day of decoding speed [05:24:41] <Dark_Shikari> at qiis in theora that were so high that the loopfilter was off, libtheora got a big speed boost [05:24:44] <Dark_Shikari> so there was a hump in the graph [05:24:49] <Dark_Shikari> There was no hump for ffmpeg. [05:24:52] <Dark_Shikari> I suspect something's up here, [05:35:46] <astrange> it looks like vp3.c never skips the loop filter [05:36:45] <astrange> it could use skip_loop_filter too but without nonref frames it'd be ugly [05:38:05] <Dark_Shikari> but at low qii it does nothing [05:38:17] <Dark_Shikari> h264 doesn't use skip_loop_filter for that [05:39:13] <astrange> i mean it could support the skip_loop_filter option [05:39:21] <Dark_Shikari> ah. [05:39:24] <Dark_Shikari> that could be done too. [05:39:28] <Dark_Shikari> well, we have it for h264 in "all" mode too [05:39:30] <Dark_Shikari> and people use that. [06:51:38] <KotH> salut [06:52:12] <kshishkov> shalom [06:52:14] <wbs> gomorgon [06:52:46] <kshishkov> wbs: "gomorron" then [07:04:42] <Dark_Shikari> mru: re your previous question about deblock strength in h264 [07:04:44] <Dark_Shikari> http://x264dev.multimedia.cx/?p=443 [07:04:47] <Dark_Shikari> Now it has a C version :) [07:05:00] <Dark_Shikari> So you could write a straightforward one for x264, test it, and then easily port it to ffmpeg. [07:05:15] <Dark_Shikari> for neon. [08:10:40] <_av500_> gm [08:23:01] <Dark_Shikari> http://img.photobucket.com/albums/v16/PicsOfMax/asseenby.jpg [08:28:20] <lu_zero> good morning [08:58:44] <_av500_> Dark_Shikari: http://topnews.in/google-s-vp8-codec-ready-showcasing-2262330 [08:59:02] <_av500_> all that ffmpeg h264 decoder bashing... :) [09:07:13] <KotH> the downside of all that hyping: if someone voices some concerns that sound half way verifiable, then everyone will hype those concerns too [09:07:44] <Dark_Shikari> also, I just sent an email to michael containing a nice idea to give a big decoder speed boost. [09:07:53] <Dark_Shikari> confirmed to help in x264. [09:09:09] <KotH> damn.. [09:09:39] <KotH> working on oss projects should be made a mandatory item on any ciriculum that teaches programming [09:10:40] <kshishkov> there are many OSS projects of high quality like PHP [09:10:58] <KotH> believe, the code i've here in front of me is much worse than php [09:12:06] * kshishkov believes without any strains [09:12:25] <KotH> i have an 80 page document that explains the architecture and everything... it's worse than reading the h.264 standard, contains at least one design error every ten pages and doesnt tell teh interesting stuff [09:12:42] <kshishkov> sounds like proper standard [09:13:06] <Dark_Shikari> sounds like vp8 [09:13:07] * Dark_Shikari runs [09:13:39] <KotH> nah.. no code c&p's :) [09:14:20] <kshishkov> Dark_Shikari: it sounds more like VP8 whitepaper disguised as standard to me [09:16:42] <janneg> KotH: the problem is that computer science/informatik doesn't teach programming [09:17:04] <KotH> janneg: nah.. that's no problem [09:17:09] <KotH> janneg: i dont care about CS anyways [09:17:27] <siretart> janneg: depends on the university [09:17:40] <KotH> janneg: but everyone who gets a course in programming (like math, phys, bio, ee,...) should get their beating in an oss project too [09:18:19] <kshishkov> KotH: or in programming at all [09:18:55] <KotH> kshishkov: programming itself is not the problem most times [09:19:10] <janneg> and I'm not even sure sure that programming skills can be teached (beyond a certain amount) [09:19:11] <KotH> kshishkov: it's that people are not aware of the traps and pitfals they are writing [09:19:23] <KotH> kshishkov: like using int32 for file handles [09:19:30] * kshishkov remembers that his group at uni got ~50% of females and ~0% of people capable of programming [09:19:35] <KotH> kshishkov: it works, yes... until you switch to a 64bit system [09:20:08] <KotH> kshishkov: sad thing: the company internal coding guidelines demand, that each used integer type has to be fully qualified with its size [09:20:57] <KotH> kshishkov: which makes sense when writing code for embedded systems, but when writting user space apps on a unix system, it's just asking for trouble [09:21:01] <kshishkov> int32_on_32_bit_platform_but_64_on_64_bit_platform i, j, k; [09:21:02] <janneg> KotH: open returns an int [09:21:21] <KotH> janneg: yes, i know [09:21:51] <KotH> janneg: but $guy doesnt care because $codingguideline tells him to use in32 [09:22:21] <kshishkov> yes, guidelines are for people without common sense [09:23:32] <janneg> int is 32bit in most deployed 64bit implementations [09:23:56] <KotH> best thing we had in our coding guidelines were: each function has to have a forward declaration at the top of the file [09:24:27] <janneg> argh [09:25:12] <janneg> KotH: you should summon diego to clean up your coding guidelines [09:25:30] <KotH> i cleaned up most of the issues already [09:25:53] <KotH> revolting against those guidelines was one of the first things i did when i started here :) [09:26:54] <KotH> interstingly, goto was forbidden in the guidlines [09:26:58] * KotH wonders why [09:27:34] <kshishkov> because they heard that at school [09:29:02] <astrange> they don't want you writing error handlers or direct-threading interpreters [09:29:32] <Dark_Shikari> No, they want error handlers to use massive nested if ;) [09:29:32] <pJok> god förmiddag, kshishkov :) [09:30:20] <kshishkov> god morgon och god dag och god kvÃ€ll, pJok [09:31:47] <Dark_Shikari> http://img.photobucket.com/albums/v16/PicsOfMax/asseenby.jpg [09:33:43] <spaam> didnt you paste that some hours ago? [09:34:04] <spaam> one hour.. [09:34:17] <Dark_Shikari> oh wait. I did. [09:34:28] <Dark_Shikari> I fail at keeping track of which channels I post images in. [09:34:29] <Dark_Shikari> but whatever. [09:45:18] <janneg> Dark_Shikari: have you seen http://lwn.net/SubscriberLink/389029/4d93fde770743516/ "Swift and predictable reactions to WebM"? [09:45:30] <janneg> "... compared the codecs side-by-side, encoding the same source media at the same audio and video data rates, which Garrett-Glaser did not do, ..." [09:46:52] <Dark_Shikari> janneg: saw it long ago [09:46:53] <Dark_Shikari> they're idiots [09:46:56] <Dark_Shikari> what do you expect [09:47:05] <Dark_Shikari> they can't even read the text [10:19:33] <Compn> 'same audio rates' :D [10:19:45] <mru> what has audio got to do with it? [10:23:14] <mru> lol, the article mentions that old sun codec [10:23:26] <mru> the one that requires 32-bit maths for everything [10:23:45] <mru> because nobody uses 16-bit computers anymore, right? [10:39:38] <CIA-93> ffmpeg: cehoyos * r23334 /trunk/libavcodec/ (avcodec.h utils.c): [10:39:38] <CIA-93> ffmpeg: Add CODEC_CAP_EXPERIMENTAL and prefer encoders without it. [10:39:38] <CIA-93> ffmpeg: Patch by Janne Grunau, janne-ffmpeg jannau net [10:39:50] <mru> \o/ [11:01:09] <janneg> DonDiego: first step for avoiding experimental codecs committed [11:01:26] <DonDiego> not quite [11:01:41] <DonDiego> this will still use the vorbis encoder if libvorbis is not available [11:01:57] <DonDiego> little is gained in this way [11:02:55] <janneg> aka first step. the vorbis encoder isn't even marked as experimental yet [11:03:38] <DonDiego> did i misread your patch? [11:03:55] <DonDiego> explain: what happens if ffmpeg was not compiled against libvorbis? [11:05:35] <janneg> I'm thinking of adding strict vs. experimental checks in avcodec_de|encode_* [11:05:43] <janneg> DonDiego: currently nothing [11:08:22] <DonDiego> the internal vorbis encoder is not used? [11:11:13] <janneg> DonDiego: that's the goal (unless -strict experimental is used) [11:11:33] <DonDiego> what is missing for that goal? [11:11:59] <wbs> hmmmm, speaking of that... in the libvorbis wrapper, I noticed a memcpy that I'm not certain that it can't be overlapping... http://pastebin.org/283057 [11:12:12] <janneg> peloverde: is it ok to mark ffaacenc as experimental? [11:13:12] <kshishkov> of course [11:13:22] <janneg> DonDiego: adding CODEC_CAP_EXPERIMENTAL [11:13:26] <kshishkov> Alex will unmark it when cosiders it's ready [11:13:30] <kshishkov> *considers [11:16:38] <nietsu> I have experienced some crashes when decoding certain h264 streams. mb_height seems to change after alloc_tables and cause overflows. [11:17:02] <DonDiego> svn HEAD? [11:17:09] <DonDiego> then we need samples to reproduce [11:17:58] <nietsu> I have created a small patch which at least seems to fix it: http://dl.ksenos.fi/tmp/h264_crash_fix.diff [11:18:39] <nietsu> The same crash occurred on svn and 0.5.2 [11:19:17] <DonDiego> then please submit the patch on ffmpeg-devel or on the issue tracker [11:19:32] <merbzt> nietsu: != -> >= maybe [11:20:09] <nietsu> merbzt: Hmm, might make sense [11:20:28] <merbzt> I'm not sure as I don't know the rest of the code [11:21:09] <merbzt> nietsu: anyway, provide sample and attach patch so someone can confirm the issue [11:22:29] <nietsu> Getting a sample might be a bit tricky, but I'll see what I can do [11:23:13] <wbs> merbzt: also, > instead of >= I guess, otherwise you'd reallocate stuff all the time? [11:25:53] <merbzt> true [11:28:43] <pross-au> https://review.source.android.com/#patch,sidebyside,14699,1,libc/memset.c [11:29:13] <merbzt> why did they remove that optimization ? [11:37:02] <_av500_> pross-au: yeah! [11:37:55] <pross-au> that made me laugh [11:38:15] <_av500_> the old code compiled much better [11:38:25] <janneg> at least arm has an asm memset [11:41:30] <bilboed-pi> pross-au, that'll teach them for NIH'ing like mad [11:41:39] <Tjoppen> hehe [11:42:00] <_av500_> lol: google has founded theora for dsps, where is it then? [11:42:10] <Evgeny> hi. in my subdir.mak file i have error "commands commence before first target. Stop.". How to solve it? [11:42:25] <_av500_> that half finished things that is noteven realtime forsub sd content? [11:42:38] * _av500_ buys more spaces [11:45:04] <_av500_> grah, that lwn article is just crap [11:45:28] <janneg> " " sells them for $1 a dozen [11:45:47] * _av500_ buyssomefromjanneg [11:49:03] <kshishkov> _av500_: funding != immediate result [11:55:00] <superdump> _av500_: did you mean theora or vp8? [11:57:06] <DonDiego> _av500_: i already commented on that article, you should, too.. [12:00:23] <pross-au> theora de-motivates me [12:00:58] <_av500_> it mentions the gg effort to port theora [12:01:25] <_av500_> now, gg being able to spend 125mio on on2, they could have spent 50k on a theora dsp port [12:03:35] <_av500_> DonDiego: i am on 2g for this week, all things web take ages [12:04:10] <pross-au> _av500_: http://webcache.googleusercontent.com/search?q=cache:http://lwn.net/Subscri… [12:04:51] <_av500_> pross-au: yes, i read it [12:05:08] <_av500_> now need to motivate myself to create lwn login [12:05:23] <_av500_> maybe if gg sponsors me [12:08:23] <_av500_> ok, i cannot comment, i am not a subscriber... [12:10:23] <KotH> hmm? [12:10:50] <KotH> you should be able to comment w/o being a subscriber [12:13:50] * KotH wonders how many subscribers lwn has these days [12:14:27] <_av500_> it wont let me [12:17:28] <KotH> then subscribe :) [12:17:34] <KotH> lwn is cheap, and it's worth it [12:18:11] <mru> really? [12:18:23] <mru> I can read xiph rants for free elsewhere [12:19:03] <KotH> yeah, the xpih rants are nasty, but otherwise it gives a quite good overview of what is going on in the linux scene [12:19:27] <mru> oh, I don't do "scene" [12:19:44] <mru> and I don't care about gnome and kde etc [12:20:19] <mru> and linux-kernel has anything kernel-related [12:27:40] <nfl> merbzt: ping [12:29:33] <merbzt> pong [12:30:18] <nfl> you have mail [12:33:18] <DonDiego> siretart: what is the status of ffmpeg in debian now? [12:33:28] <DonDiego> that reminds me of a certain wiki page :) [12:34:11] <siretart> DonDiego: squeeze currently has 0.5.1, need to prepare an 0.5.2 upload [12:34:38] <siretart> DonDiego: experimental currently ships an 0.6 prerelease package (and has already cleared NEW) [12:34:46] <DonDiego> ok [12:34:54] <DonDiego> with full source but some encoders disabled? [12:35:10] <siretart> yes, as usual [12:35:32] <DonDiego> ok [12:35:55] <siretart> DonDiego: I've also uploaded that prerelease package to ubuntu maverick, but it currently doesn't build for transient issues (libdirectfb-dev is currently uninstallable) [12:38:01] <mru> how does libdirectfb affect ffmpeg? [12:39:16] <siretart> it declares a build dependency on directfb [12:39:22] <mru> wtf? [12:39:28] <mru> we don't use directfb [12:39:34] <siretart> indirectly. [12:39:37] <mru> how? [12:39:38] <mru> sdl? [12:39:44] <siretart> we depend on sdl, which itself depends on directfb [12:40:12] <mru> I've never understood the purpose of directfb [12:40:20] <mru> there seems to be nothing direct about it [12:41:37] <siretart> the issue is transient after all. maverick has just opened and a lot of packages are being thrown in the archive. most of that will clear up itself the next few days/weeks [12:42:14] <hyc> just out of curiosity - are you using --enable-librtmp ? [12:43:56] <siretart> no, not yet. Is there already an librtmp-dev package yet? [12:44:30] <siretart> no, there isn't. so I'd need to package librtmp first [12:44:40] <hyc> I don't know. rtmpdump itself was only recently accepted in debian [13:26:21] <CIA-93> ffmpeg: maxim * r23335 /trunk/libavcodec/ (indeo5data.h indeo5.c ivi_common.h ivi_common.c): [13:26:22] <CIA-93> ffmpeg: moves indeo5 scan patterns into ivi_common.c [13:26:22] <CIA-93> ffmpeg: so those can be shared by indeo4. [13:29:03] <jai> that might tick off the commit log police [13:29:48] <lu_zero> ? [13:30:01] <DonDiego> third person singular [13:33:16] <mru> unusual grammar, but at least it's clear about what the change is [14:14:36] <BBB> roundup is so slooooooooow [14:17:16] <kierank> doesn't work at all for me [14:18:09] <BBB> same here :( [14:18:13] <BBB> lu_zero: ping? [14:26:43] <lu_zero> BBB: pong [14:27:35] <lu_zero> the server that had it on had its contract expired since the payment notice was eaten by spamassassin... [14:27:50] <KotH> ouch [14:27:57] <lu_zero> I'll reinstate it soonish [14:27:59] <kshishkov> well, teach it that bills != spam [14:28:38] <BBB> haha :) [14:28:47] <lu_zero> kshishkov: apparently the sender had his clock/calendar set wrongly [14:28:56] <lu_zero> and spamassasin disliked it a lot [14:29:22] <KotH> lu_zero: if you want, we could move roundup somewhere else [14:29:41] * KotH has a bunch of servers idly sitting around waiting for some work to do [14:30:01] <lu_zero> I was thinking about moving it to the topix [14:30:18] * kshishkov concludes that all those servers were unfit for rendering Big Buck Bunny [14:30:24] * lu_zero has servers in 2 other different locations [14:30:34] <lu_zero> topix renders bbb AND sintel [14:30:37] <KotH> http://www.topix.ch/ ? [14:30:59] <lu_zero> http://www.top-ix.it/ [14:31:13] <KotH> kshishkov: unfortunately, yes [14:31:32] <lu_zero> s/renders/mirrors [14:31:38] <KotH> kshishkov: these servers are usually in the 1-2GB ram ball park [14:32:36] <KotH> http://www.top-ix.it/traffic-summary [14:32:45] * KotH concludes, italians dont get up before noon [14:33:18] <kshishkov> why should they? [14:33:31] <twnqx> you still need to finish BBB for linuxtag? [14:33:44] <lu_zero> what are you doing with bbb? [14:34:06] <BBB> he's crunching me [14:34:30] <lu_zero> mru: btw there are updates regarding linuxtag? [14:35:04] <janneg> twnqx: almost complete, there are a couple of frames which need more than 8G [14:35:18] <twnqx> get me a list... [14:35:19] <janneg> http://www.jannau.net/bbb_videowall/ [14:36:13] <lu_zero> just one remaining? [14:37:09] <janneg> I think 200-250 frames remaining [14:37:19] <lu_zero> job I mean [14:37:29] <janneg> yes [14:37:48] <janneg> but I can split it [14:37:56] <janneg> it needs more than 6G [14:38:55] <lu_zero> I have an 8g box somewhere [14:39:15] <lu_zero> but you should ping me this night about this ^^; [14:39:45] <janneg> twnqx: I'll prepare a list [14:41:08] <kierank> hyc: have you seen this: http://lists.infradead.org/pipermail/get_iplayer/2010-May/000016.html [14:41:21] <kierank> get_iplayer is also looking for an rtmp expert [14:44:06] <BBB> lu_zero: can you point us to an alternate address for roundup? [14:44:08] <BBB> I'm stuck :) [14:44:54] <lu_zero> BBB: let me have the server reinstated and everything will be fine... [14:45:03] <BBB> ok [14:45:04] <BBB> I think [14:50:22] <lu_zero> KotH: roundup is python btw [14:50:46] <lu_zero> are you sure you want to start learning about virtualenv AND roundup now? [15:00:15] <Tjoppen> how nice.. just worked out that drop frame time codes have a time base about 1 ppm lower (faster) than "normal" ntsc. this of course means collisions once every million frames (~10h) even if one is very careful [15:34:36] <Compn> anyone still working on sun/sparc stuff? someone is selling them and i dunno if these are useful to fate or whatever [15:34:37] <Compn> LX - $5 [15:34:37] <Compn> Sparc5 and 10 - $10 [15:34:37] <Compn> Sparc1000 - $15 [15:34:37] <Compn> Ultra2 - $20 [15:35:11] <kshishkov> buy one and ship to mru [15:35:22] <hyc> $20, woohoo [15:35:53] <mru> sparc is rather uninteresting [15:36:08] <lu_zero> why? [15:36:14] <mru> for ffmpeg [15:36:20] <kshishkov> mlib? [15:36:24] <mru> it's an interesting cpu in many other ways [15:36:27] <mru> but it's dead [15:36:31] <Compn> well thats why i said for whatever , doesnt have to be ffmpeg :P [15:36:35] <kshishkov> and opensourced :P [15:36:49] <lu_zero> sparc is gpl somehow [15:36:51] <Compn> i know you guys have special/rare hardware [15:37:22] <kshishkov> not me [15:38:13] <Compn> thought you had a geode? or loonghen [15:38:22] <KotH> lu_zero: i want to learn it somewhen, i'm not sure i want to learn it now :) [15:38:29] * Compn cant remember names of these cpus anymore [15:38:37] <kshishkov> Compn: shortchicken-based netbook [15:38:43] <Compn> lol [15:38:56] <lu_zero> KotH: eh eh [15:40:02] <KotH> Compn: if you can get your hands on a ultra2, that'd be cool [15:40:11] <KotH> Compn: the others are.. unintersting [15:40:35] <KotH> Compn: ok, maybe the sparc1000 as it's a bigger machine, but the others are just small pizza boxes [15:40:54] <KotH> lu_zero: there is an gpl'ed vhdl code of an sparc cpu implentation, called leon [15:42:33] <lu_zero> http://en.wikipedia.org/wiki/LEON [15:43:52] <lu_zero> http://en.wikipedia.org/wiki/UltraSPARC_T3 <- that seems interesting [15:44:36] <Compn> sparcserver 1000 - The fastest cpu modules were 85MHz: [15:44:37] <Compn> heh [15:45:03] <hyc> T3? will it ever see the light of day? [15:45:07] <KotH> Compn: i used to own a sparcstation 5 back in 2000 [15:45:18] <kshishkov> hyc: that's why it's interesting [15:45:31] <KotH> Compn: by that time it was already a few years old and the company i got them from were throwing them away after they were sitting in the cellar for years [15:45:33] <hyc> I still have a sparcstation sitting in the office. unplugged now tho ;) [15:45:38] <jai> btw, maybe we can delete http://samples.mplayerhq.hu/sub/DivX%2bSubtitles.divx ? [15:45:46] <KotH> Compn: i think my brother has still one of those [15:46:11] <Compn> heh, i dont think i want one... [15:46:11] <jai> the subs don't work with the divx player too, so its just misleading to carry it around [15:46:33] <Compn> jai : which version divx player? i'm assuming it worked at one time and divx player just outdated it [15:46:43] <ramiro> all this computing power... only so that we may watch pictures of cats with captions... [15:46:51] <KotH> Compn: the ss5 had iirc a 5MHz sparc-II cpu, which felt like a 100 MHz pentium in work speed [15:46:59] <KotH> 50MHz, not 5 ^^' [15:47:01] <Compn> like how realplayer doesnt play every realmedia file, or official ogg demuxer cant handle all files... [15:47:17] <KotH> ramiro: can i haz cheezburger? [15:47:17] <jai> Compn: v8 [15:47:20] <kshishkov> luckily, it's not the case with FFmpeg [15:47:34] <Compn> jai : you might want to try a version of divx player that is closer to the date on that file [15:47:48] <Compn> luckily :) [15:48:28] <Compn> ffmpeg is quickly becoming the only software which can play these old crappy files no one cares about anymore [15:48:39] <jai> except this one ;) [15:48:51] <jai> i havent found _any_ player which handles this [15:48:56] <Compn> i thought reimar got those subs working in mplayer ... [15:48:57] * jai goes to look on filehippo [15:49:10] <jai> xsub works in mplayer/vlc/ffplay [15:49:13] <jai> not this file though [15:49:17] <Compn> ah [15:50:00] <Compn> http://bugzilla.mplayerhq.hu/show_bug.cgi?id=634 [15:50:04] <Compn> theres the bug for that file [15:50:24] <Compn> could be invalid, could be antique version of xsub file ? hehe [15:54:40] <jai> Compn: well yeah the xsub decoder works pretty well [15:55:00] <jai> my problem with that specific sample is that it doesnt seem to have any xsub packets :( [15:55:29] <Compn> ah heh [15:55:43] <Compn> i thought i ran strings on it and found subs but its been 4 years so i dotn remember now [15:56:09] <Compn> but yeah, i can delete it if no one wants it around [15:56:51] <hyc> hmm. seems like neither rtsp nor rtmp has provision for a subtitle track in the stream. [15:56:56] <hyc> anyone know for sure? [15:57:12] <_av500_> burned in subs :) [15:57:15] <kshishkov> Compn: why delete a sample? [15:57:49] <BBB> Yuvi: vp8data.h doesn't compile, TM_VP8_PRED is missing [15:58:10] <_av500_> kshishkov: make a backup 1st of course... [15:58:20] <jai> Compn: strings wont yield anything, the subs are rle coded rects [15:59:41] <jai> kshishkov: well, we can atleast rename it and move it to the divx dir [16:02:30] <wbs> hyc: don't think there's anything stopping it from being implemented in rtsp/rtp, but I don't know any specs on it offhand [16:02:40] <wbs> hyc: there's shitloads of different rfcs on how to pack different formats in rtp [16:03:12] <wbs> hyc: rtsp itself doesn't mind what's being wrapped, rtsp just sets up the connection... anything you can fit into rtp/sdp then should be fine [16:05:33] <Compn> hyc : i remember a few articles about ripping rtmp hosted subs from cruncyroll [16:06:19] <hyc> right, I just think no one has written a spec for it [16:06:32] <Compn> hyc : for rtsp subs here is a sample >> http://bugzilla.mplayerhq.hu/show_bug.cgi?id=296 [16:06:36] <Compn> oh specs, no idea :P [16:06:42] <hyc> Compn: re: crunchyroll - the point was that subs weren't part of the rtmp stream, so they were hosted separately [16:07:07] <Compn> everybody just puts their stuff in X-perimental and ignores specs anyhow [16:07:13] <hyc> likewise with hulu, they provide closed captions in a separate SMIL file [16:11:17] <lu_zero> let me see [16:11:24] <hyc> I should write a subtitle spec for RTMP. see how Adobe responds. "Damn, some freetard is extending our proprietary spec!!" [16:13:04] <lu_zero> ugh... [16:13:35] <BBB> Compn: that rtsp link works fine in ffmpeg [16:13:46] <BBB> Compn: or was the bug in the mov file? [16:13:49] <BBB> (then I don't know) [16:13:57] <lu_zero> 17:55 <+hyc> hmm. seems like neither rtsp nor rtmp has provision for a subtitle track in the stream. [16:14:10] <lu_zero> rtp has at least two ways to provide subtitles [16:14:15] <lu_zero> one is using rtp-text [16:14:23] <lu_zero> the other is using/abusing rtcp-xr [16:14:31] <mru> the proper freetard way is to create a new spec, loosely based on (but deny this) the proprietary one, mostly by removing any nice features it might have, then adding the missing feature in a way that makes almost impossible to use [16:14:53] <lu_zero> mru: you are describing... [16:14:56] <lu_zero> hmm [16:15:03] <lu_zero> ogg feels completely original [16:15:59] <mru> yes, ogg is 100% original crap [16:16:02] <lu_zero> hyc: josh wants to have subtitles working in rtsp so something will be done about it [16:16:15] <hyc> lu_zero: cool, thx for info [16:16:32] <Compn> BBB : which rtsp link? the first playlist one that pulls in video and subs ? [16:16:41] <BBB> in that mplayer bug report [16:16:46] <BBB> rtsp://vstream.acm.org/10.1145/siggraph2004/courses4/crs022-1.mp4 [16:17:32] <Compn> BBB : does it work if you call it from the http mov playlist? http://www.siggraph.org/soma/SIG04/Media/disc4/crs022-1.mov [16:17:40] <Compn> i guess i could check :) [16:17:55] <ohsix> mru: any proof on what its loosely based on? [16:18:33] <BBB> no [16:18:38] <BBB> it has 23 chapters of metadata though [16:18:42] <BBB> each seems a subtitle :) [16:18:50] <Compn> hehe [16:20:02] <mru> ohsix: I wasn't talking about anything specific [16:20:28] <ohsix> ok; the "they deny this" part seemed to point at something specific, as in they've done it already :] [16:23:15] <janneg> mru: have you ordered sponsored linuxtag social event tickets? "deadline" is Sunday, May 30th [16:23:55] <mru> wtf? where did you read that? [16:24:08] <janneg> http://wiki.linuxtag.org/w/fp:Social_Event [16:24:27] <mru> linuxtag organisation gets worse every year [16:24:52] <janneg> but that was afaik always the case, just nobody cared [16:25:34] <mru> they used to send out emails about such things [16:25:38] <mru> not make you hunt obscure wikis [16:26:06] <janneg> the location is nicer this year if we have good weather [16:26:21] <mru> and as usual I have no fucking clue how many people will be turning up [16:26:36] <ohsix> roll 2d6 [16:26:52] <ohsix> if one die is under 4 multiply it with the other [16:27:26] <janneg> 1*1 [16:27:46] <ohsix> o noes [16:30:19] <janneg> mru: you, av500, kshishkov, DonDiego, Stefan, mchinen, me [16:30:37] <janneg> maybe lu_zero [16:30:49] <mru> cehoyos [16:31:45] <janneg> he said friday, saturday. so he might not be in berlin thursday evening [16:31:53] <mru> right [16:32:45] <janneg> Thilo Borgmann? [16:33:18] <mru> I don't remember him saying anything about coming [16:33:51] <janneg> yes, but he seems to have access to the free passes [16:34:05] <mru> then he must be registered with another project [17:01:09] <lu_zero> I'm next to surely in =) [17:02:19] <lu_zero> and hopefully I'll be able to help setting up =P [17:02:42] <lu_zero> and that reminds me [17:03:05] <mru> great [17:03:16] <lu_zero> which hotel you'll stay? [17:03:29] <mru> need to book that [17:03:33] <mru> probably the ibis [17:04:01] <lu_zero> I see [17:09:04] <lu_zero> the ibis seems full [17:09:37] <mru> crap [17:10:16] <lu_zero> Ibis Berlin Messe is it? [17:10:29] <mru> yes, good location [17:10:31] <mru> for linuxtag [17:11:18] <lu_zero> too good apparently =P [17:11:47] <mru> not full, but insanely expensive [17:12:15] <mru> as usual the first price they show is only half of what it ends up at [17:15:33] <lu_zero> mru: for me it was claimed full [17:15:43] <mru> where did you look? [17:16:07] <lu_zero> between 8 and 13 [17:16:13] <mru> yes, but what website? [17:16:27] <lu_zero> ibishotel.com [17:19:05] <mru> stupid hotels [17:19:11] <mru> arrival on 7th has rooms [17:19:13] <mru> but not 8th [17:19:21] <mru> how the fuck does that make sense? [17:19:35] <mru> but I'm not paying 112 euros per night for that hotel [17:22:02] <kierank> give them a ring [17:22:32] <lu_zero> 112 it's a bit for it [17:22:32] <kierank> a lot of the time the price is totally different [17:22:32] <kshishkov> mru: train in Denmark first, looks like their hotels are with the highest prices [17:22:39] <spaam> kierank: one ring to rule them all? [17:23:04] <kshishkov> spaam: one phone ring definitely rules in ex-USSR [17:23:15] <kshishkov> in direct sense [17:23:44] * kierank picks up the phone and asks for spaam to be whacked [17:24:00] <spaam> kierank: <3 [17:24:12] <kierank> say hi to the horse in your bed [17:24:30] <CIA-93> ffmpeg: michael * r23336 /trunk/libavcodec/h263dec.c: Treat SIPP like xvid, fixed issue1966 [17:24:37] <jai> whoa godfather reference [17:24:44] <spaam> kshishkov: ok :D [17:24:56] <spaam> jai: teh best :) [17:25:30] <spaam> three weeks ago me and some friends watched god father one to three ;D [17:25:35] <spaam> it was nice :) [17:25:49] <jai> :) [17:26:58] <mru> same rate on the phone [17:27:06] <kshishkov> spaam: and in Ukraine we had a term "phone law" [17:27:35] * kshishkov had once to spent a night in three-star hotel in Copenhagen for 700 DKK [17:27:38] <spaam> kshishkov: what about that law? :D [17:27:42] <lu_zero> uff maporama sucks [17:28:15] <kshishkov> spaam: if somebody from top calls you by phone, his words have higher priority than any other rules or law [17:28:55] <spaam> kshishkov: ok :) [17:36:21] <Dark_Shikari> so yeah mru, after seeing my post and the 15-line C functions that now _actually_ exists, what do you think of deblock strength on neon? ;) [17:36:28] <Dark_Shikari> s/functions/function [17:36:58] <spaam> kshishkov: does that law exists today? :) [17:37:55] <lu_zero> mru: what about http://www.hotel-funkturm-messe.de/preise.html ? [17:38:03] <mru> looking at it now [17:39:02] <Dark_Shikari> deblock_strength_c is the relevant bit. [17:39:06] <lu_zero> the english prices look quite different [17:41:59] <mru> different in all languages [17:46:27] <Tjoppen> interesting - drop frame time codes work out to exactly be 29.97 fps, not 30000/1001 [17:47:02] <Tjoppen> 107892 frames to the hour, not 108000. good to know [17:52:55] <Compn> Tjoppen : you should write down your findings somewhere for others [17:53:34] <Compn> gah roundup is down [17:54:47] <Tjoppen> I'm thinking of writing down my quicktime findings on the wiki. particularly regarding the 'avis' tag in the 'dref' tag [17:54:55] <Tjoppen> have to nag mike a bit I guess [17:56:42] <kierank> the wiki needs a section called "things that should be long dead". I would add ntsc framerates, interlacing and drop frame to it [17:56:55] <kierank> ac-3 and mpeg-2 as well [17:56:59] <_av500_> avi? [17:57:03] <kierank> yes [17:57:03] <_av500_> :( [17:57:06] <mru> ac3 and mpeg2 are fine [17:57:13] <_av500_> err :) [17:57:17] <mru> avi _is_ dead [17:57:22] <_av500_> no [17:57:23] <peloverde> avi is not dead [17:57:33] <peloverde> check demonoid if you disagree [17:57:40] <mru> the only avi files on my computer are the ones in the samples archive [17:57:52] <_av500_> fine for you [17:58:12] <_av500_> the hdds and ssds of our users are full of avi [17:58:15] <peloverde> The bulk of US TV on demonoid is Xvid in AVI [17:58:38] <ohsix> i have terabytes :] [17:59:22] <kierank> there are a lot of places that mandate xvid in avi [17:59:40] <Tjoppen> I'd call the article "Headaches" or something like that [17:59:53] <kierank> mainly because people want their old divx dvd players to keep working [18:00:40] <kierank> just like ac-3 survives because people want their old amps to still work [18:01:28] <mru> and because the dvd spec isn't changing [18:01:33] <mru> and they're still selling dvds [18:01:49] <mru> besides, what's the problem with ac3? [18:01:58] <_av500_> it works [18:02:19] <mru> I don't see anything particularly annoying about it [18:02:29] <_av500_> me neither [18:02:34] <mru> nor mpeg2 [18:02:35] <kierank> it's being used in new applications when there's something better [18:02:37] <_av500_> except the dolby cert... [18:02:53] <mru> kierank: what would you use instead? [18:02:55] <kierank> aac [18:03:07] <mru> aac is much more annoying [18:03:31] <mru> the good thing about aac is that there are so many of it to choose from [18:03:35] <_av500_> well, it is way waychaeper [18:03:43] <kierank> aac lc [18:03:54] <_av500_> ac3 is awfully expensive [18:04:22] <mru> licensing aside, ac3 works well for the intended application [18:04:29] <_av500_> i agree [18:04:44] <mru> decent quality and reasonably cheap to decode [18:04:58] <_av500_> and even self syncing [18:09:01] <Tjoppen> hm. at 10;00;00;00, which is where smpte recommends you start counting, the difference between those two time bases is one frame [18:10:56] <peloverde> It seems like AAC-LC should be transparent at ac-3 optical disc bitrates [18:14:06] <Tjoppen> I bet SMPTE 12M has something to say about this. it even deals with leap seconds, recommending you re-count that second rather than count up to 60 [18:14:17] <Tjoppen> instead of 59. hooray [18:35:42] <CIA-93> ffmpeg: cehoyos * r23337 /trunk/ (libavcodec/avcodec.h Changelog): Bump minor version and add Changelog entry after r23334. [18:46:03] <CIA-93> ffmpeg: stefano * r23338 /trunk/ (libavcodec/avcodec.h doc/APIchanges): [18:46:04] <CIA-93> ffmpeg: Bump minor version bump and add an APIchanges entry after addition of [18:46:04] <CIA-93> ffmpeg: CODEC_CAP_EXPERIMENTAL. [18:46:20] <ramiro> has the minor version just been bumped twice for the same thing? [18:47:24] <peloverde> Such things have been known to happen from time to time [18:47:34] <mru> it does no harm [18:55:47] <CIA-93> ffmpeg: cehoyos * r23339 /trunk/libavcodec/vorbis_enc.c: Mark vorbis encoder as experimental. [19:01:50] <CIA-93> ffmpeg: cehoyos * r23340 /trunk/libavcodec/ (h264.c h264.h): [19:01:50] <CIA-93> ffmpeg: Factorize ff_h264_decode_extradata(). [19:01:50] <CIA-93> ffmpeg: Patch by Howard Chu, hyc highlandsun com [19:04:21] <Kovensky> < kierank> the wiki needs a section called "things that should be long dead". I would add ntsc framerates, interlacing and drop frame to it <-- telecine, srt, deen, tsukihime anime [19:04:30] <Kovensky> rmvb [19:04:31] <Kovensky> ._. [19:12:47] <mru> lu_zero: that hotel with the strange rates... they have yet another rate when you use the form on the webpage [19:12:51] <mru> 90 euro per night [19:12:53] <mru> idiots [19:15:49] <_av500_> hrs.de [19:16:17] <spaam> mru: germans.... [19:16:41] <mru> germans have the most complex rules and rituals around hotels I've ever seen [19:17:33] <kierank> especially involving sun loungers and towels [19:20:19] <twnqx> :> [19:20:44] <twnqx> you should witness buffets. [19:21:20] <mru> the best hotel breakfasts I've had were in america [19:21:29] <mru> they know how to make breakfast there... [19:21:58] <_av500_> +1 [19:22:06] <twnqx> hm [19:22:08] <peloverde> Really, generally I'm not a fan of American hotel breakfast [19:22:10] <mru> the german breakfast buffets usually look impressive at a distance [19:22:21] <mru> when you get closer, you see there's really nothing to it at all [19:22:38] <twnqx> never been to america [19:22:44] <dgt84_> I'm always surprised how much people outside the US love US breakfast [19:22:49] <mru> peloverde: try more expensive hotels [19:22:54] <mru> hilton is usually nice [19:23:28] <twnqx> also i don't really benefit from huge breakfasts... since i just eat two slices of bread [19:23:36] <twnqx> sometimes egg, sometimes fruit... [19:24:36] <dgt84_> marriott and ritz are also nice but really at that point you can get a cheapo room and go out to Denny's / IHOP / etc (depending on where in the US) in the morning for a decent meal [19:24:43] <twnqx> anyway, i agree that most german breakfast selections can't compete with some things i've seen in the middle east (where the majority of hotels i've been in is located) [19:25:04] <dgt84_> twnqx, what sort of breakfast stuff do you get there? [19:25:18] <mru> don't expect any bacon :-( [19:25:28] <twnqx> mru: depends, in dubai you have bacon everywhere [19:25:34] <twnqx> hyatt in cairo as well [19:25:58] <twnqx> also, i've learnt how nice veal bacon is [19:26:06] <twnqx> which you get all over saudi arabia :P [19:26:16] * dgt84_ mostly eats turkey bacon [19:26:28] <mru> real bacon is made from pigs [19:26:34] <twnqx> dgt84_: basically american breakfast, just replace pork with veal/turkey etc, pluz arab mezzah [19:26:51] <twnqx> plus "continental" breakfast [19:27:04] <mru> but sure, there's lots of good food from the middle east [19:27:05] <twnqx> usually with omelett/eggs made to order [19:27:06] <dgt84_> twnqx, ah okay, cool [19:36:33] <ramiro> what's the link to ffmpeg.org's awstats? [19:36:34] <FFFF-RAGE> Does anyone else experience corrupted sound when encoding 5.1 audio with: ffmpeg -i temp.ac3 -acodec libvorbis -aq 5 -y temp.ogg [19:37:04] <lu_zero> 21:25 <@mru> real bacon is made from pigs [19:37:08] <lu_zero> uhmm [19:37:48] <kierank> military breakfast > all [19:37:50] <lu_zero> that reminds me that I want to try ostrich [19:40:43] <FFFF-RAGE> ostrich is good [19:41:31] <thresh> i never could eat at the morning [19:42:01] <_av500_> redefine morning [19:42:08] <thresh> when I wake up [19:42:31] <mru> so redefine it [19:42:41] <mru> define morning as when you get hungry [19:49:31] <wbs> FFFF-RAGE: it seems like the libvorbis wrapping only supports 1 or 2 channels, patch welcome I guess [19:49:51] <FFFF-RAGE> ah [19:50:08] <FFFF-RAGE> I don't think I'll be submitting one [19:50:10] <wbs> FFFF-RAGE: check lines 149-156 in lavc/libvorbis.c [19:50:37] <wbs> I don't think it's complicated to fix that [19:50:44] <FFFF-RAGE> that may be so [19:50:58] <FFFF-RAGE> but nobody applies my patches [19:52:10] <twnqx> thanks for ffwmv3, plays the stream from BP's oil valve, even though it's a bit boring [19:52:30] <ramiro> FFFF-RAGE: ffmpeg-cvslog says otherwise [19:52:35] <_av500_> it plays the oil directly? [19:52:42] <twnqx> sadly not [19:52:42] <FFFF-RAGE> colours on windows? [19:52:53] <FFFF-RAGE> vorbis comments in ogg vorbis files? [19:53:30] <ramiro> FFFF-RAGE: wasn't colours on windows rejected until a cleaner solution is found? [19:53:44] <mru> if you're talking about that patch that either doesn't work, doesn't do anything, or breaks stuff, there's a good reason it's rejected [19:53:51] <FFFF-RAGE> What's wrong with someone else re-writing it later? [19:54:05] <FFFF-RAGE> And it works just fine in cmd [19:54:24] <FFFF-RAGE> and wil probably only ever work in cmd [20:00:56] <bamiaux> does anyone know which codec (m2v?) stress ffmpeg bitstream readers enough so that their speed is critical ? [20:01:19] <Dark_Shikari> huffyuv? [20:01:54] <peloverde> AAC at high bitrates [20:02:30] <bamiaux> huffyuv looks more bandwith constrained [20:02:37] <bamiaux> i'll check both anyway [20:03:46] <peloverde> AAC does have bitstream primitives inlined these days, so that changes some results [20:03:55] <BBB> yuvi: ping (once you're awake) [20:04:54] <bamiaux> aren't they supposed to be always inlined though ? [20:06:50] <peloverde> By primitives I mean directly using OPEN_READER/UPDATE_CACHE/GET_VLC/SHOW_UBITS/etc rather than get_vlc2, get_bits [20:06:56] <pengvado> huffyuv spends about 70% of its time in the bitstream reader [20:07:01] <pengvado> 90% if you turn off median [20:07:38] <FFFF-RAGE> That was simple but now I have mis-matched channels [20:08:16] <kierank> [20:52] <+twnqx> thanks for ffwmv3, plays the stream from BP's oil valve, even though it's a bit boring --> that live stream is a PR diversion imo [20:08:32] <twnqx> sure is, nothing happens [20:08:48] <ohsix> that live stream was hard fought for, they coveted any video at all for nearly a month [20:09:09] <ohsix> becuase even if it is a distraction people can make their own estimates and see that they were lowballing them [20:09:42] <twnqx> there's nothing to see [20:09:48] <twnqx> zero, nada, rien [20:10:13] <ohsix> heh, when they do the topkill there will be something to see, but the point was to get the public to see the flow rate [20:10:33] <twnqx> have you looked at it? you see no flow... [20:10:44] <bamiaux> Ok, but I assume huffyuv spend most of its time inside get_vlc*, and not regular get_bits [20:10:45] <kierank> erm there's a lot of flow [20:10:53] <twnqx> in the picture? [20:11:00] <kierank> yes [20:11:06] <twnqx> mh [20:11:06] <peloverde> It's ridiculous that these days we expect big business to act in a substantively fraudulent manner (I say substantively because they control the legislative process, so nothing they do is illegally fraudulent) [20:11:12] <mru> it probably looks small because you don't have a sense of scale [20:11:13] <ohsix> then we might be talking about different things :] http://globalwarming.house.gov/spillcam [20:11:28] <FFFF-RAGE> Is there a standard way to remap channels in ffmpeg? [20:11:29] <kierank> they've moved it around [20:11:43] <twnqx> mms://a246.l9789246245.c97892.g.lm.akamaistream.net/D/246/97892/v0001/refle… is what i'm looking at [20:11:45] <kierank> yes [20:11:59] <kierank> the camera isn't facing the leak [20:12:30] <ohsix> bummer, it was the last few days [20:23:24] <CIA-93> ffmpeg: maxim * r23341 /trunk/libavcodec/ (indeo5.c ivi_common.h ivi_common.c): Add the forgotten ff_ prefix to the shareable scan patterns. [20:23:48] <peloverde> Is roundup down? [20:23:54] <BBB> yes [20:24:27] <peloverde> So much for fixing bugs :) [20:24:52] <ohsix> snow day \m/ [20:32:10] <hyc> kierank: heh I didn't evn know they had a mailing list. but I'm in regular contact with the get_iplayer author... [20:35:30] <hyc> BBB: hmm, this would all be pretty easy if I just add an AVCodecContext pointer inside the AVCodecParserContext. wdyt? [20:35:32] <Dark_Shikari> mru: ping [20:36:14] <hyc> of course it would render the AVCodecContext on the parse argument list redundant [20:36:28] <Dark_Shikari> or just general question to here [20:36:32] <Dark_Shikari> I need a video format that: [20:36:39] <hyc> does anybody use a single ParserContext with multiple CodecContexts at once? [20:36:40] <Dark_Shikari> a) compresses fast enough to do realtime 720p [20:36:47] <Dark_Shikari> b) decodes 2-2.5x faster than h264 without cabac or deblocking [20:36:49] <Dark_Shikari> c) on ARM [20:36:50] <BBB> hyc: uh... so why can't you do all initialization (delayed) in _parse(), as Michael suggested? [20:36:59] <Dark_Shikari> d) compresses _enough_ to work over wireless g [20:37:31] <peloverde> 802.11 a/b/g/n? [20:37:33] <hyc> BBB: I can, that's what my last posted patch does. I just think it's stupid to add an "did we do this yet" flag to the H264Context and check it on every call to Parse. [20:37:57] <BBB> hyc: fair enough [20:38:02] <Dark_Shikari> Yuvi: ping maybe [20:38:11] <hyc> when it's obviously an init-type step, and we have an explicit init entry point... [20:38:19] <kierank> hyc: that's the get_iplayer fork mailing list [20:38:20] <Dark_Shikari> peloverde: g I think [20:38:37] <Dark_Shikari> so in other words it can't be totally uncompressed/crap [20:38:39] <Dark_Shikari> but it can be close [20:38:42] <BBB> hyc: I think somehow changing api all the time might not be ideal also, though [20:39:58] <hyc> BBB: true... oh well. it just nags at me, I think this API is wrong but I can see the value in not disturbing it. [20:40:42] <hyc> Dark_Shikari: DV is 25Mbit/sec. in a noise-free environment, it will work over 802.11g [20:40:43] <BBB> hyc: I'm not maintainer, so my opinion adds little value to the discussion ;) in this case, if michael prefers X, then you probably don't want to waste your time on proposing Y unless there's a really good reason to waste your time on it [20:40:44] <BBB> :) [20:41:01] <hyc> well his last reply was that he was open to it [20:41:02] <janneg> Dark_Shikari: .g means 20mbps netto [20:41:34] <BBB> hm... [20:41:34] <Dark_Shikari> hyc: I don't think it's fast enough [20:41:41] <Dark_Shikari> too high bitrate [20:41:51] <BBB> hyc: I think you should add it to init then, or as I said before, add an init2() that has it [20:42:00] <BBB> then at least the api change is obvious [20:42:10] <janneg> Dark_Shikari: which ARM? [20:42:11] <BBB> adding it to parsectx is hackish because it might not be immediately clear to users [20:42:29] <Dark_Shikari> janneg: Cortex A8 [20:42:36] <Dark_Shikari> must decode 1024x768 in realtime [20:42:41] <Dark_Shikari> actually, 2x realtime [20:42:47] <Dark_Shikari> we have to spend ~10-15ms per frame displaying it [20:42:57] <Dark_Shikari> so we only have about 10-15ms left after overhead and network time to actually decode [20:44:20] <hyc> Dark_Shikari: bummer, it's close. I've streamed DV over my home wireless-G, but any change in the weather and it glitches [20:44:35] <Dark_Shikari> we have full control, the wireless can be right next to it if we want [20:44:39] <FFFF-RAGE> Can I make libvorbis.c depend on vorbis_data.c? [20:44:53] <Dark_Shikari> in short, we need to cheat to put video on an ipad. [20:45:15] <BBB> get a faster h264 encoder [20:45:19] <BBB> decoder [20:45:19] <Dark_Shikari> encoder isn't the problem [20:45:23] <BBB> (sorry) [20:45:24] <Dark_Shikari> decoder? coreavc is too slow [20:45:27] <Dark_Shikari> by a factor of 1.5-2x [20:45:32] <BBB> didn't ipad have a hw decoder? [20:45:32] <Dark_Shikari> With deblocking off [20:45:33] <Dark_Shikari> cabac off [20:45:34] <Dark_Shikari> and subpel off [20:45:43] <Dark_Shikari> ipad has a hw decoder that we can't use. [20:45:48] <BBB> why not? [20:45:49] <Dark_Shikari> and if we get access, it will be too late. [20:45:52] <Dark_Shikari> Ask Steve. [20:45:56] <BBB> there's an api for it [20:46:01] <Dark_Shikari> Where? [20:46:04] <BBB> or was that a generic mac api? [20:46:09] <Dark_Shikari> Our iphone dev says no. [20:46:11] <hyc> what clock rate is that A8? [20:46:12] <wbs> FFFF-RAGE: sure, just add it at the correct spot in the makefile [20:46:12] <BBB> apple released an api to their hw decoding features a while ago [20:46:29] <Dark_Shikari> where? [20:46:29] <BBB> also, the quicktime api on the iphone should give you access to it [20:46:34] <Dark_Shikari> hyc: 1ghz [20:46:35] <janneg> Dark_Shikari: have you tried mpeg2? [20:46:37] <hyc> BBB: that API works for their Nvidia cards [20:46:38] <BBB> how else does decoding h264 work in any application? [20:46:41] <ramiro> Dark_Shikari: Steve seems to be listening to you, maybe you should ask him =) [20:46:42] <Dark_Shikari> BBB: it doesn't [20:46:45] <Yuvi> BBB: pong [20:46:49] <BBB> you've gotta be kidding me [20:46:52] <Dark_Shikari> I'm not [20:46:53] <kierank> have you checked there's not a way through OpenGL? [20:47:00] <Dark_Shikari> kierank: opengl can do yuv conversion for us [20:47:02] <Dark_Shikari> Not decoding [20:47:03] <wbs> BBB: the hw decoding API was desktop only [20:47:06] <BBB> Yuvi: ah, hi, is decode_mb() for macroblock intra or inter decoding? I'd like to implement that now [20:47:11] <BBB> wbs: oh. damnit [20:47:12] <Dark_Shikari> apple has _repeatedly_ said no [20:47:18] <Dark_Shikari> to requests from various people to use the hardware decoder [20:47:20] <Dark_Shikari> with no explanation [20:47:25] <Yuvi> BBB: oh, both, let me push what I have [20:47:26] <BBB> Dark_Shikari: email steve [20:47:26] <wbs> BBB: and all video APIs on iphone are way, way too highlevel for what they're trying to do [20:47:27] <BBB> he owes you [20:47:28] <BBB> :) [20:47:35] <BBB> damnit [20:47:40] <BBB> I bet you implemented what I just did [20:47:42] <Yuvi> also, TM_VP8_PRED is in h264pred.h [20:47:47] <BBB> it isn't [20:47:49] <Dark_Shikari> Yuvi: you got an arm? [20:47:51] <hyc> Dark_Shikari: hm, I thought mru had already tweaked the neon h264 code pretty well [20:47:51] <BBB> check github [20:47:56] <Dark_Shikari> hyc: yes, it's still too slow [20:48:01] <Dark_Shikari> I'm saying it will NEVER be fast enough [20:48:02] <BBB> I grepped for it [20:48:04] <Dark_Shikari> not in a million years [20:48:05] <Yuvi> Dark_Shikari: yeah [20:48:14] <Yuvi> BBB: hm, maybe I forgot to push that too [20:48:20] <Dark_Shikari> Yuvi: What decoder do you think would be 2.5x faster than ffh264 with no deblock and no cabac [20:48:23] <Dark_Shikari> on arm [20:48:24] <Dark_Shikari> And could you bench it? [20:48:31] <Dark_Shikari> (mjpeg, dv, mpeg2, etc are fine) [20:48:36] <Dark_Shikari> even svq1... [20:48:43] <Yuvi> the best I can think of is a h263 derivative [20:48:51] <hyc> too bad. I also keep thinking OMAP when I see Cortex, and want to suggest DSP but obviously that's not here, oh well [20:48:55] <Dark_Shikari> Yuvi: flv1? [20:49:06] <Yuvi> iirc A8@5-600 MHz can do mpeg-4 at 720p24 [20:49:15] <Dark_Shikari> I need two things benched [20:49:29] <Dark_Shikari> 1) mpeg4/flv1 (pick one) at say qscale 4, 1024x768 [20:49:45] <Dark_Shikari> 2) x264 with --preset ultrafast at say qp 25, 1024x768 [20:49:46] <hyc> I have 600MHz A8 w/1024x600 screen [20:49:54] <Dark_Shikari> I need to know how much faster 1) is compared to 2) [20:50:08] <Dark_Shikari> if the answer is "at least twice", this may be possible. [20:50:25] <janneg> Yuvi: barely, without sound and buffering lot of frames. [20:50:27] <Dark_Shikari> (I can do it myself, of course, if I had ssh) [20:50:45] <hyc> those are encoder benches, I thought you were worried about the decoder [20:50:47] <Dark_Shikari> decoder. [20:50:55] <Dark_Shikari> Yes, I mean decoding the output of those encodes [20:50:59] <hyc> ok [20:51:49] <hyc> I may be ble to get to it in a little bit if no one else jumps up [20:51:52] <Dark_Shikari> k [20:52:09] <kierank> have you tried erm theora [20:52:22] <kierank> arm* [20:52:34] <hyc> 1024x768? can you cheat the rez and upscale on playback? [20:53:10] <hyc> that's what I do for hulu on my touchbook, play the 512x288 stream and scale to 1024x576 [20:53:38] <Dark_Shikari> kierank: theora is slower than mpeg4 I'd assume [20:53:46] <Dark_Shikari> hyc: Yeah we can do that, it sucks [20:54:08] <hyc> I doubt most users will know the difference [20:54:16] <Dark_Shikari> It's kinda obvious when playing a game. [20:54:25] <hyc> mmm [20:54:32] <lu_zero> Dark_Shikari: you'd like having ssh on an efikamx and/or a beagleboard? [20:54:38] <hyc> a game with live video background huh [20:54:40] <Dark_Shikari> lu_zero: that would be cool [20:54:48] <Dark_Shikari> hyc: no, the game is the video background ;) [20:54:52] <lu_zero> ping me insistently in the next days [20:55:01] <Yuvi> BBB: pushed [20:55:13] <BBB> Yuvi: was my patch quarter-way useful? [20:55:14] <lu_zero> so I prepare an image for the beagleboard and boot both of them [20:55:25] <BBB> oh, see there, my patch is in there :) [20:55:40] <wbs> BBB: getting used to git? :-) [20:55:49] <BBB> no [20:55:55] <BBB> I send yuvi patches by mail and he applies [20:55:58] <BBB> I'm confused by git [20:56:02] <wbs> ah ;P [20:56:07] <lu_zero> BBB: bad =E [20:56:30] <BBB> I know [20:56:34] <BBB> I'm cloning his repo now [20:56:37] <BBB> let's see if this works [20:57:09] <Yuvi> BBB: oh, I misread the patch, it should be rac_get_nn not _sint2 [20:57:34] <BBB> wait what? [20:57:46] <Yuvi> I made a wrong change [20:57:55] <BBB> get_uint() was wrong? [20:58:08] <Yuvi> no, it was right [20:58:20] <Yuvi> I just thought it was another instance of sint2 that the spec didn't name [20:58:30] <Yuvi> but it's an instance of _nn like in vp5/6 [20:59:12] <BBB> error: Unable to find d1ec4470be04fba3ff10fbecd455a14ab322d14e under http://github.com/yuvi/ffmpeg.git [20:59:12] <BBB> Cannot obtain needed object d1ec4470be04fba3ff10fbecd455a14ab322d14e [20:59:12] <BBB> while processing commit 0681684c9eaad2aaad060fbd664c28041378fb5c. [20:59:12] <BBB> fatal: Fetch failed. [20:59:15] <BBB> what is that? [20:59:42] <ohsix> missing a pack? [20:59:52] <BBB> I don't know what that means [21:00:15] <wbs> BBB: you've probably got an old git version and using the http url.. even if that shouldn't fail, you'd be better off either using the git:// url or upgrading to a newer git [21:01:01] <wbs> their old http transport mechanism is slow and failure prone, the new smart http is about as fast as over git:// or ssh [21:01:42] <Yuvi> never seen that before, but yeah, use git:// if possible [21:02:10] <Yuvi> anyway, fixed my screwing up your patch [21:02:35] <ohsix> shallow clones and repacks can make stuff unreferenced, git gc will clean it up if its a real problem [21:02:49] <ohsix> theres a thing to display loose refs too [21:02:54] <Yuvi> git gc on whose end? [21:02:54] <BBB> Yuvi: is decode_mb() for the stuff directly after the mvprob prediction? [21:03:23] <Yuvi> yeah, it uses data from the same partition [21:04:06] <Yuvi> or the header does [21:05:19] <BBB> hm, the //reset s->mvc fell off the patch somehow [21:05:41] <BBB> yeah I should use git instead of quilt, quilt is painful at mistakes [21:06:04] <ohsix> hurf my git doesn't seem to know about repack or anything anymore; they might have ditched that whole thing [21:06:23] <FFFF-RAGE> A patch to look at: http://pastebin.org/284035 [21:06:47] <astrange> git 1.7 still has repack [21:07:18] <ohsix> git version 1.7.0.4 [21:07:27] <Yuvi> basically (since the spec doesn't explain this): each macroblock mode is stored in the frame header, right after all the probability updates [21:07:27] <Yuvi> the coeffs are in the partitions after, and use separate arith coder contexts [21:07:28] <Yuvi> macroblock row i is in partition i%(num partitions) [21:07:32] <ohsix> was it optional or deprecated? [21:08:22] <BBB> Yuvi: I have the source in front of me ;) [21:08:24] <ohsix> ah they hid all the applets from the path [21:08:30] <BBB> I don't read the spec, too often it's wrong [21:08:34] <FFFF-RAGE> wbs: can you look at: http://pastebin.org/284035 [21:08:41] <astrange> FFFF-RAGE: send it to ffmpeg-devel [21:09:15] <FFFF-RAGE> I will if people don't say that it needs a major change [21:09:18] <ohsix> and the man pages aren't in a reachable spot for those moved applets either, hrmph [21:09:33] <wbs> FFFF-RAGE: I'm not sure if someone wants to keep the separate mono codepath or not [21:10:04] <wbs> FFFF-RAGE: and for the channel mapping, at least for decoders, they're able to declare their channel mapping somewhere, but I have no clue about how to do this for encoders [21:10:18] <wbs> FFFF-RAGE: so I can't help you, but hopefully someone on the mailing list can [21:10:23] <Dark_Shikari> hyc: ping me when you have time to test it then. [21:10:39] <wbs> FFFF-RAGE: I think superdump has been meddling with channel mappings at least [21:10:47] <Yuvi> the spec is helpful for some stuff, even if it's not clear and dead wrong in places [21:10:47] <Yuvi> figuring out coeff decode is a lot easier to read chapter 13 first than piece out detokenize.c [21:11:14] <FFFF-RAGE> I'll send it off then [21:11:26] <BBB> Yuvi: true [21:11:38] <BBB> yuvi: although in 50% of the cases the spec code is literally the decoder code :) [21:11:44] <BBB> I mean literally [21:11:51] <Yuvi> heh, yeah [21:12:05] <Dark_Shikari> chapter 13 is detokenize.c [21:12:05] <Dark_Shikari> seriously [21:12:21] <BBB> :-p [21:12:44] <Yuvi> Dark_Shikari: in theory, no clue (yet) how accurate it is [21:14:41] <BBB> Yuvi: more generally, how can I be helpful at this? [21:14:52] <BBB> Yuvi: would you like me to focus on particular chapters, different functions? [21:15:07] <BBB> 2 people on 1 code is a little complex [21:15:49] <mru> Dark_Shikari: have you tried mpeg4 asp? [21:16:05] <Dark_Shikari> mru: that's what I want to test the speed of now [21:16:26] <DonDiego> Yuvi: did you check out my crash? [21:16:28] <peloverde> I would try SP [21:16:28] <Yuvi> BBB: yeah, maybe you could work on interframe-only stuff for the moment? either that or verify that the bitstream parsing I've done so far is right [21:16:52] <Yuvi> DonDiego: that only happens with theora? [21:17:01] <drv> FFFF-RAGE: it might be worth it to factor out the l*context->vi.channels part, unless gcc already does that [21:17:05] <mru> Dark_Shikari: don't use qpel or gmc [21:17:10] <Dark_Shikari> mru: I know [21:17:13] <mru> there's no neon for those [21:17:20] <Dark_Shikari> mru: oh, so normal MC has neon for mpeg-4? [21:17:23] <mru> yes [21:17:24] <Yuvi> BBB: I don't plan on looking at chapters 16+ until keyframes are bitexact [21:17:27] <Dark_Shikari> sweet, thx [21:17:33] <Dark_Shikari> anything in mpeg-4 sp/h263 that doesn't have neon? [21:17:45] <mru> "normal" is same as mpeg2 more or less [21:17:48] <BBB> Yuvi: I'll start a rough verify and then I'll do inteframe [21:17:49] <BBB> thanks [21:17:56] <Dark_Shikari> mru: yeah, with the +1/-1 rounding [21:18:01] <Dark_Shikari> which alternates [21:18:05] <DonDiego> Yuvi: what do you mean only with theora - it's a crash in the theora testsuite.. [21:18:07] <Dark_Shikari> or did mpeg2 do that too [21:18:13] <mru> there's neon for both rounding variants [21:18:16] <Dark_Shikari> k [21:18:24] <Yuvi> DonDiego: I mean, the crash is from av_picture_copy [21:18:40] <mru> whatever the mpeg4 big buck bunny clip uses is optimised [21:18:49] <Dark_Shikari> lol [21:18:55] <Yuvi> which I think is copying into a buffer sdl provided [21:19:26] <BBB> Yuvi: second half of patch now also in your inbox [21:19:34] <BBB> it fell off the first patch (not sure why) [21:19:51] <BBB> it resets s->prob.mvc for keyframes [21:21:23] <FFFF-RAGE> drv: thanks for the tip [21:22:55] <Yuvi> BBB: thanks pushed [21:23:07] <DonDiego> Yuvi: well, i have not found any other samples to reproduce so far.. [21:23:15] <DonDiego> Yuvi: does the duck sample work for you? [21:23:53] <mru> Dark_Shikari: btw mpeg2 is slower than mpeg4 to decode at acceptable quality [21:24:22] <Yuvi> DonDiego: yeah [21:24:30] <DonDiego> hmm [21:24:51] <DonDiego> Yuvi: can you reproduce the funky colors gmaxwell talked aobut? [21:25:17] <Yuvi> DonDiego: already fixed (r23304) [21:25:29] <Yuvi> which isn't backported to 0.6 yet I think? [21:26:57] <DonDiego> could be, dunno.. [21:27:03] <Dark_Shikari> mru: why is that, differetn vlc tables? [21:27:09] <BBB> how do I switch branch in git? [21:27:20] <Yuvi> git checkout <branch name> [21:27:38] <BBB> git checkout vp8? [21:27:41] <BBB> doesn't work :( [21:27:49] <Yuvi> if it's remote, add origin/<branch name> [21:27:50] <mru> Dark_Shikari: higher bitrate required for same quality [21:28:07] <Yuvi> git checkout -b vp8 origin/vp8 will set up a local branch to track the remote [21:28:29] <BBB> why would I want that? [21:28:54] <Yuvi> because otherwise you're going to loose your local commits into the ether [21:29:04] <BBB> oh [21:29:05] <BBB> ok [21:29:11] <BBB> and then git pull? [21:29:26] <Yuvi> yeah [21:29:27] <mru> you might want git pull --rebase [21:29:39] <mru> otherwise you end with lots of merge commits [21:29:43] <mru> which is annoying in a private tree [21:29:55] <BBB> I'm confused [21:30:01] * BBB runs configure and hopes nothing breaks [21:30:31] <BBB> it's like this ultra-sharp swiss-army knife and I just know I'm gonna cut myself [21:30:35] <BBB> somehow I still play with it [21:31:16] <astrange> well git has advanced recovery tools (revlog and git reset --hard) to go with the advanced breaking-everything tools [21:31:19] <ohsix> but it has a freakin' toothpick and a woodsaw!, scissors! [21:31:39] <mru> git usually lets you undo mistakes [21:31:46] <BBB> the "usually" scares me [21:31:57] <BBB> but ok, I'll try it [21:32:00] <mru> just don't git gc --prune=now [21:32:06] <ohsix> ^ [21:32:08] <BBB> worst case I keep sending patches by mail to yuvi [21:32:23] <BBB> Yuvi: how do I commit patches myself? [21:32:25] <ohsix> unreached objects eventually get tossed, but operations just unlink them, so you can link them back in [21:32:42] <Yuvi> BBB: git commit [21:32:43] <ohsix> at least in your working copy [21:32:49] <Yuvi> -a to be like svn [21:33:02] <mru> don't commit -a [21:33:04] <mru> it's evil [21:33:08] <mru> try git gui [21:33:11] <mru> it's quite nice [21:33:51] <astrange> i prefer git diff + commit -a, partial commits seem like they could create commits you haven't tested on their own [21:34:59] <BBB> ok [21:35:03] <BBB> so is it locally or remotely committed now? [21:35:11] <Yuvi> locally [21:35:11] <BBB> I did a commit in git gui [21:35:14] <BBB> git gui is nice, btw [21:35:22] <Yuvi> git push is for remote [21:35:25] <BBB> so can I commit remotely somehow? [21:35:31] <BBB> push, aha [21:36:01] <BBB> does the push button push the last commit, all commits or the current commit? [21:36:08] <Yuvi> all [21:36:19] <BBB> that sounds dangerous [21:36:20] * BBB tries [21:36:58] <BBB> source branch, vp8? [21:37:04] <BBB> destination repo: origin? [21:37:13] * BBB feels like he'll break something [21:37:52] <Yuvi> can't yet since github is timing out in giving you commit rights [21:38:00] <BBB> shouldn't it "push" to origin/vp8? [21:38:03] <BBB> instead of origin? [21:38:27] <Yuvi> no, branches are separate from repos in push [21:38:50] <Yuvi> geh, I have to go, bbl [21:38:54] <BBB> bye :) [21:41:41] <BBB> -((col * 16) << 3) -> would gcc automatically optimize that to col << 7? [21:42:08] <mru> BBB: try and see [21:42:23] <mru> I suspect it does [21:44:53] <Dark_Shikari> mru: what's a configure line for ffmpeg on a cortex a8? [21:44:56] <Dark_Shikari> i.e. with neon and all that jazz [21:45:50] <mru> fate should have a good one [21:46:00] <janneg> depending on your tools --arch=armv7 --cpu=cortex-a8 --extra-cflags="-mfpu=neon -mfloat-abi=softfp" [21:46:10] <mru> --arch=arm is fine [21:46:24] <mru> --cpu is the detailed one [21:50:28] <Dark_Shikari> softfp? [21:50:29] <Dark_Shikari> why [21:50:42] <mru> that's just the calling convention [21:51:02] <mru> it took gcc like 15 years to add proper fpreg parameter passing [21:51:37] <mru> and even now it takes some serious acrobatics to bootstrap a system with it [21:51:53] <mru> so most systems still pass fp args in integer regs [21:51:57] <ohsix> isn't codesourcery over that junk [21:51:59] <Dark_Shikari> ah k [21:52:02] <hyc> I think the Angstrom ffmpeg build is already configured pretty well [21:52:08] <mru> ohsix: recent gcc versions support it, yes [21:52:31] <hyc> Dark_Shikari: you can see its settings anyway, seems to cover all the bases for cortex a8 [21:52:33] <ohsix> i mean weren't they the first, relatively recent interest in doing so [21:52:39] <mru> Dark_Shikari: it doesn't matter for performance in ffmpeg [21:52:43] <peloverde> Doesn't that suck when functions returning float are called in a tight loop? [21:53:00] <mru> peloverde: yes, but we don't do that [21:53:18] <mru> calling _anything_ in a tight loop is usually a bad idea [21:53:25] <astrange> lto would allow internal functions to violate abi anyway [21:53:33] <astrange> though i doubt it'd be worth it [21:53:50] <mru> astrange: gcc simply didn't have the ability to generate such calls _at all_ [21:54:31] <peloverde> I could have sworn we ran into that in SBR land, though the SBR filterbank needs a rewrite [21:54:54] <BBB> you just wrote it [21:54:59] <mru> my profiling shows nothing like that [21:55:21] <mru> most of the time is spent in easily simdable loops [21:55:57] <mru> which I'm not going to spend time optimising if it's slated for rewriting anyway [21:57:19] <peloverde> meh, it's still faster than faad [21:57:48] <mru> if I can triple the speed again, I will [21:59:03] <BBB> peloverde: we love you for that [21:59:57] <peloverde> most of the speed advantage comes from LC and dsputil [22:00:19] <mru> and fft [22:00:27] <mru> which isn't technically part of dsputil [22:00:32] <peloverde> fair enough [22:01:26] <peloverde> Also I think faad uses doubles some places where it doesn't need to [22:02:53] <Dark_Shikari> 2fps encoding! woohooo [22:02:56] <Dark_Shikari> <3 cortex a8 [22:03:03] <peloverde> I guess not [22:08:14] <janneg> Dark_Shikari: -vcodec mpeg -qscale 3 is twice as fast as -vcodec libx264 -vpre ultrafast and has similiar filesize [22:08:24] <janneg> decoding [22:10:57] <Dark_Shikari> janneg: on an arm? [22:13:06] <bcoudurier> janneg, which mpeg ? mpeg2video ? [22:14:50] <janneg> mpeg4 [22:14:57] <janneg> Dark_Shikari: on omap3 [22:16:43] <janneg> just decoding, i.e. -f null /dev/null [22:17:27] <janneg> it's a little bit faster with -flags -qpel-gmc [22:17:43] <mru> aren't those off by default? [22:19:06] <Dark_Shikari> yes they are [22:27:08] <CIA-93> ffmpeg: stefano * r23342 /trunk/ (libavformat/nut.c libavcodec/raw.c): [22:27:08] <CIA-93> ffmpeg: Add support for the newly added Nut codec tags (added in Nut r669): [22:27:08] <CIA-93> ffmpeg: Y1[00][16], [16][00]1Y, Y3[11][16], [16][11]3Y, Y3[10][16], [22:27:08] <CIA-93> ffmpeg: [16][10]3Y, Y3[00][16], [16][00]3Y, Y4[11][ 8], Y2[00][ 8]. [22:38:36] <janneg> mpeg2 -qscale4 is a little bit faster but still more factor 2 than 2.5 [22:38:55] <Dark_Shikari> mpeg2 is faster than mpeg4? [22:42:40] <janneg> yes, 5-10% at qscale 4. [22:43:01] <janneg> testing with a 1280x720 video [22:47:32] <pengvado> why is mpeg2 faster than mpeg4? what work is it skipping? [22:54:45] <janneg> theora is not even 50% faster as h264 --ultrafast at the same bitrate and same speed at double bitrate [22:57:44] <astrange> mpeg12 bitstream might be faster than mpeg4 bitstream [22:58:03] <astrange> or maybe one isn't using simpleidct [22:59:13] <janneg> ffv1 is around 50mbps, i.e. too much for 802.11 g [23:02:41] <pengvado> janneg: decoding speed? that's called --tune=fastdecode, not --preset=ultrafast [23:08:34] <janneg> pengvado: Dark_Shikari asked for --preset ultrafast, testing --tune=fastdecode now [23:09:28] <Dark_Shikari> already benched it here [23:09:34] <Dark_Shikari> ffv1 is way too slow =p [23:09:44] <Dark_Shikari> what about svq1? [23:10:25] <Dark_Shikari> or other similar fast things? [23:10:31] <Dark_Shikari> is svq1 fast enough to encode in realtime anyways? [23:10:44] <janneg> mjpeg is slower than mpeg4 [23:12:11] <Dark_Shikari> interesting [23:12:15] <Dark_Shikari> not surprising though [23:12:20] <janneg> doesn't look like it is without multithreading [23:12:34] <Dark_Shikari> I could always go hack in optimizations to svq1 of course [23:12:40] <Dark_Shikari> how fast does it decode? [23:12:54] <janneg> --tune=fastdecode is slower than --preset=ultrafast [23:13:03] <janneg> Dark_Shikari: still encoding [23:14:07] <janneg> 3fps [23:15:33] <mru> astrange: mpeg2 and mpeg4 should use the same idct by default [23:16:14] <Dark_Shikari> mru: also note that we can modify video formats however we want [23:16:21] <mru> doubling the svq1 encoder speed is probably trivial [23:16:21] <Dark_Shikari> e.g. if we wanted, we could swap out the transform for h264's transform [23:16:28] <Dark_Shikari> we control encoder and decoder [23:16:34] <Dark_Shikari> (the mpeg-2 transform, that is) [23:16:48] <mru> mpeg2 or mpeg4 with h264 transform would be interesting [23:16:54] <Dark_Shikari> it would have to be simple enough to be a small project though; we don't really have time right now for something complicated [23:17:06] <mru> idct is a huge chunk of cpu time in mpeg2/4 [23:17:09] <Dark_Shikari> how much faster is h264 transform than mpeg-2 on arm? [23:17:30] <mru> I haven't measured the transform separately [23:17:44] <mru> but it's much simpler [23:18:00] <Dark_Shikari> and of course I mean the 8x8 one [23:18:03] <Dark_Shikari> to make it a direct swap-out [23:18:05] <mru> yes, of course [23:18:25] <Dark_Shikari> you'd need to mess with quant ofc [23:18:34] <astrange> how much sparse row handling does arm simpleidct have? [23:18:47] <mru> some [23:19:00] <astrange> also, mpeg4 with a flat dct will have really bad blocking, even if the qscale is precise [23:19:08] <Dark_Shikari> "flat dct"? [23:19:11] <mru> the decoders don't track last nonzero unfortunately [23:19:15] <astrange> flat cqm [23:19:19] <Dark_Shikari> oh. [23:20:18] <astrange> iirc last nonzero doesn't help if you use ac prediction [23:21:01] <mru> eh? [23:21:47] <mru> if last nonzero is low enough you can skip large chunks of the transform [23:21:55] <Dark_Shikari> ac pred is only for intra iirc [23:22:23] <astrange> mpeg4videodec.c:1082 [23:22:26] <astrange> ah [23:22:44] <astrange> yeah, that is in intra [23:22:49] <mru> but without a last nonzero indicator you have check all the coeffs [23:23:48] <mru> and that's not much faster than doing the transform in neon [23:24:11] <astrange> yeah [23:24:27] <astrange> it should be really cheap in sse4, i need to rewrite the xvid idct for that. but i can't understand my own macros anymore [23:34:01] <janneg> Dark_Shikari: svq1 is another 10% faster [23:37:53] <janneg> factor 2.1 compared to --preset=ultrafast (which somehow got or more likely I mixed up utime and real time the first time) [23:38:00] <janneg> +faster [23:39:24] <spaam> astrange: "but i can't understand my own macros anymore" <-- haha.. thats bad ;S [23:39:27] <mru> once in a while I've seen utime > real time on a single-core [23:39:35] <mru> no idea what's going wrong when that happens [23:39:55] <mru> spaam: no, it's very clever macros [23:40:13] * mru hopes he'll never have to debug his own macros [23:40:51] <spaam> mru: why is that clever? you write it so you can understand it . [23:41:19] <astrange> i understand them when they're expanded [23:41:45] * mru points at brian kernighan [23:42:08] <spaam> whos that? [23:42:24] <mru> go away, you are not worthy to be here [23:43:14] <spaam> haha [23:43:28] <spaam> ah thats him.. ;S [23:43:35] <spaam> one of the K&R guys.. [23:43:35] <mru> "Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it." [23:44:20] <spaam> nice

1 0

IRC log for 2010-05-25
by irc＠mansr.com 25 May '10

25 May '10

[00:00:19] <ohsix> or wait, i take that back; i updated from karmic -> lucid since i last went there, flash is the same though [00:00:32] <bcoudurier> janneg, we don't have experimental decoders anyway [00:00:46] <lu_zero> ohsix: flash might still crash, but I'm more and more convinced that's partly fault of the plugin interface [00:00:52] <hyc> ohsix: interesting. Hulu had new encryption mechs enabled, which aren't present in the 64 bit flash plugin [00:01:14] <hyc> this would mean they've lowered their security settings back to pre-Flash 10.0.22 [00:01:32] <ohsix> lu_zero: mebbe, but when i say never i meannever :O (old java plugin? not so much) [00:01:43] <Kovensky> <@DonDiego> http://www.osnews.com/story/23346/Nero_Files_Antitrust_Case_Against_MPEG-LA <-- I like his neutral, professional tone [00:02:01] <ohsix> hyc: oh, FMS stuff? i think i read about that; file signing or something and an extra challenge [00:02:06] * lu_zero is still trying to figure out how to make the vlc plugin not crash [00:02:16] <hyc> ohsix: or you just got lucky - Hulu used to be exclusvely on Akamai, now they're also using Level3 and Limelight CDNs [00:02:40] <hyc> which one you get at any particular time seems random, and they're all at different revisions of FMS [00:02:49] <ohsix> i'll see if i'm still lucky later [00:03:57] <ohsix> now that i think of it the applet signing thing might have been iplayer :O [00:04:32] <kierank> hyc: bbc is the same [00:04:35] <bcoudurier> hehe [00:04:41] <janneg> bcoudurier: yes. should I repost a patch without the avcodec_find_decoder changes or can you just commit without it [00:05:36] <hyc> Hulu turned on SWF verification a while back, but then they turned it off again [00:06:12] <hyc> they probably figured out it wasn't worth the additional load on their servers [00:06:57] <ohsix> it seems silly; i cant imagine managing supporting multiple viewers, which obviously includes multiple versions of the same viewers that might be around :[ [00:07:46] <hyc> it was probably keeping a grunt employed for a few months, to stay on top of all those versions they were kicking out [00:21:08] <hyc> wbs, bcoudurier: ok, fixing cur_dts for H264 in libavformat fixed get_packet_send_clock() for me [00:23:04] <DonDiego> gnite [00:23:56] <hyc> what a coincidentally relevant exit msg... [00:36:16] <bcoudurier> humm ohsix, you smoking good pot [00:36:24] <bcoudurier> 64bit doesn't play here [01:20:18] <CIA-93> ffmpeg: cehoyos * r23303 /trunk/ (7 files in 3 dirs): [01:20:18] <CIA-93> ffmpeg: VP8 decoding via libvpx. [01:20:18] <CIA-93> ffmpeg: Patch by James Zern for Google, Inc., jzern google com [01:37:10] <hyc> bcoudurier: you can always use this instead http://forum.xda-developers.com/showpost.php?p=6495551&postcount=8 [01:53:21] <bcoudurier> janneg, are you still there ? [02:35:24] <janneg> bcoudurier: yes, can't sleep [02:57:28] <hyc> kinda funny how everyone's making a big deal about Android 2.2 being able to stream from Hulu [02:57:46] <hyc> and then having Hulu block it again a few hours later [02:58:17] <astrange> whoops, spent way too much time looking at a bug in mt that turned out to be on mainline too [02:58:34] <astrange> too bad i still can't figure out the cause, it's in avfilter dr1 somewhere [03:20:43] <CIA-93> ffmpeg: conrad * r23304 /trunk/libavcodec/vp3.c: [03:20:43] <CIA-93> ffmpeg: theora: Don't read an excess bit for maximum length long bit runs if the run [03:20:43] <CIA-93> ffmpeg: exactly ends the remaining blocks. [03:21:07] <Dark_Shikari> does that need backporting? [03:21:42] <Yuvi> yep, siretart ^ [03:22:27] <Yuvi> I think diego is reporting SDL bugs to me again... [03:25:05] <Yuvi> now, to make the decoder bitexact to libtheora: the put_no_rnd_pixels mmx2 functions need to be fixed [03:26:38] <Dark_Shikari> it has errors that accumulate? that sucks [03:27:11] <Yuvi> I've yet to find anywhere it accumulates enough to be visible, even with 500 frame gop which noone uses for theora [03:27:16] <Yuvi> but it should be fixed [03:27:37] <Yuvi> hope michael doesn't require me to bench on the PII/PIII he wrote these for... [03:27:53] <Dark_Shikari> are you going to be able to get rid of the branch in mc? [03:28:02] <Dark_Shikari> also do we have w16 motion compensation yet (sse)? [03:28:12] <Yuvi> eventually and no [03:29:10] <Yuvi> do kinda wish I could rewrite dsputil_template* in yasm to get width sse for free... [03:29:21] <Dark_Shikari> use yasm ;) [03:30:00] <Yuvi> doubt michael will accept that given that everything uses those functions [03:37:18] <astrange> i have a pIII but i don't think we're actively benchmarking on those anymore [04:05:25] <astrange> https://twitter.com/rentzsch/status/14669859679 oops? [04:20:48] <astrange> siretart: could you backport r22730 to the branches it's not in? i thought it was there, but apparently not... [05:36:33] <Tjoppen> morning [05:46:51] <_av500_> morning [05:49:56] <pJok> goda morgonar, kshishkov :) [05:58:12] <benoit-> good morning [06:12:41] <jai> hmm [06:12:46] <jai> "libwebm - a library for creating and parsing WebM container files" [06:12:50] <jai> is there such a thing? [06:13:24] <elenril> renamed libmatroska? [06:14:46] <bcoudurier> google doesn't find anything [06:15:21] <jai> http://www.webmproject.org/code/repository-layout/ [06:15:27] <jai> ^ found that here [06:22:24] <astrange> http://i.imgur.com/vvNtU.png how can an intra-only MB decode differently with threads on... [06:22:35] <astrange> well, at least there's not many stages involved, i can just add asserts [06:24:32] <Dark_Shikari> astrange: loopfilter? [06:24:42] <astrange> turned it off [06:27:04] <astrange> guess: h->mb isn't cleared. forgot what does that [06:29:53] <astrange> need a better code browser too, so i can open arbitrary files more than once. maybe i should figure out emacs [06:30:22] <Yuvi> you can do that in textmate, as long as you don't need them in the same window [06:30:36] * elenril wonders how to open urls from irssi without using mouse [06:31:12] <superdump> morning [06:31:30] <Dark_Shikari> is uint8_t (*x[2])[2][4][4] an array of two pointers to uint8_t [2][4][4]s? [06:31:34] <Dark_Shikari> I hate cdecl [06:32:02] <Yuvi> why? just use random types instead of stdint.h [06:32:15] <Dark_Shikari> ? [06:32:26] <Dark_Shikari> how does that fix problems with scary arrays of pointers to arrays of arrays [06:32:26] <Yuvi> and yeah [06:32:47] <astrange> http://cdecl.org/ [06:32:54] <Yuvi> oh, I though you were talkgin about cdecl.org [06:33:11] <superdump> Dark_Shikari: what you said would make sense [06:36:02] <astrange> yeah, h->mb needs to be zeroed the first time a decode thread runs. can't believe that lasted until now [06:37:59] <astrange> so 1 day for 1 line fix and i found 2-3 bugs in mainline along the way. that's about average [06:43:40] <superdump> astrange: how is ffmpeg-mt going? [06:44:31] <KotH> y0! [06:45:06] <elenril> sup dawg [06:51:35] <astrange> todo got shorter. a day or two and i'm sure i can send a patch that will play theora [06:52:53] <superdump> cool [06:53:10] <superdump> are you receiving any funding to eventually push it towards a merge into trunk [06:53:12] <superdump> ? [07:00:13] * KotH sends astrange some swiss chocolate [07:00:17] <KotH> superdump: yes he does ;) [07:00:42] <superdump> i was the one who tipped him off about it (they were going to pay me) [07:01:55] <CIA-93> ffmpeg: kostya * r23305 /trunk/libavformat/rtmpproto.c: [07:01:56] <CIA-93> ffmpeg: 24l trocadero: RTMP reader forgot to shift high byte of timestamp to its [07:01:56] <CIA-93> ffmpeg: proper position [07:01:56] <CIA-93> ffmpeg: Patch by trueice (his gmail account is obvious) [07:02:50] <kshishkov> pJok: goda morgnar men det är min ADSL har reset klockan åtta [07:07:30] <_av500_> adsl reset your klock? [07:08:16] <superdump> :) [07:08:17] <kshishkov> it resets at around eight o'clock CET [07:08:36] <kshishkov> you should learn Swedish, this is FFmpeg development channel after all [07:08:49] <superdump> :) [07:10:17] <siretart> astrange: hrmpf. you mean for 0.5? 0.6 certainly has that patch. [07:10:44] <siretart> astrange: anyway, I'll put it on my list, the patch does not backport cleanly. I'm currently at work [07:11:57] <_av500_> kshishkov: reset it once at e.g. 3am, i guess it has a 24h timer... [07:13:19] <kshishkov> _av500_: why should I do resets at all? It's ISP that does it at that time no matter when I reset it manually [07:13:57] <astrange> siretart: k. x86-64 works without it, i think that's the most common platform already [07:15:16] <_av500_> kshishkov: to move the reset time to a more convenient hour (in case you care) [07:15:50] <kshishkov> _av500_: told you, I've tried it several times with no luck [07:16:02] <_av500_> ah ok [07:16:40] <_av500_> get e decent isp [07:16:43] <_av500_> a [07:17:07] <kshishkov> got one but it's not in Ukraine :P [07:17:44] <wbs> wouldn't that normally be a bonus? :-) [07:20:09] <kshishkov> wbs: of course, but until I get proper setup here, I'd use my EEE left at Ukraine for running irssi [07:22:37] * _av500_ has a local isp with fixed ip and no daily reset [07:22:46] <kshishkov> same here [07:22:51] <kshishkov> (I think) [07:27:12] <CIA-93> ffmpeg: mstorsjo * r23306 /trunk/doc/general.texi: Fix VP8 listing in general.texi [08:15:47] <lu_zero> good morning [08:16:09] <kshishkov> hej [08:59:06] <CIA-93> ffmpeg: cehoyos * r23307 /trunk/libavcodec/libvpxdec.c: Headers for libvpx are installed into vpx subdirectory. [09:00:47] <siretart> okay, now that libvpx support is in, does anyone know what is the status for webm support in avformat? [09:01:59] <superdump> there was another thread on the ml iirc [09:02:31] <siretart> I read that as 'pending' [09:02:49] <j-b> why move to vpx/ ? [09:03:18] <siretart> j-b: it was claimed that libvpx's Makefile would install the headers to /usr/include/vpx [09:03:50] <astrange> demux is in, i think encode and mux are pending? [09:04:21] <j-b> siretart: weird, I didn't saw that [09:04:21] <kshishkov> seems so [09:04:40] <jai> muxing is pending [09:05:03] <j-b> siretart: I don't really care as far as it doesn't change every 2 days :D [09:05:24] <jai> carl didnt update configure btw [09:06:10] <wbs> jai: I pinged him about that on cvslog [09:06:35] <jai> wbs: ah, ok [09:22:49] <CIA-93> ffmpeg: mstorsjo * r23308 /trunk/configure: Look for libvpx headers in the vpx subdirectory in configure, too [09:47:40] <lu_zero> wbs: ping2 [09:47:49] <wbs> lu_zero: pong1 [09:47:55] <wbs> lu_zero: tested it right now [09:49:04] <wbs> lu_zero: DSS was initially configured with 1000 max connections, then it crashed when reaching the max... when I set it a bit lower it worked quite well [09:49:12] <lu_zero> [8633885.510229] DarwinStreaming[3871]: segfault at 8ae1040 ip 0000000008106a99 sp 00000000f74c3ed0 error 6 in DarwinStreamingServer[8048000+fe000] [09:49:16] <lu_zero> eh... [09:49:36] <lu_zero> and also seems to leak [09:49:38] <wbs> feng also crashes if I set the max connections to 1000 there [09:50:14] <wbs> yes, it's not all that pretty.. I've fixed some valgrind warnings in dss in http://github.com/mstorsjo/dss at least [09:51:46] <wbs> lu_zero: this is the crash I got with feng: http://pastebin.org/278296 [09:52:17] <lu_zero> current master? [09:52:31] <wbs> quite recent at least, not exactly todays master [09:52:41] <wbs> and with libnetembryo 0.1.1 if that matters [09:54:25] <lu_zero> I'll try to reproduce it [09:54:27] <lu_zero> that's new [09:54:59] <wbs> a wild guess is that it's out of file descriptors, normally a process is limited to 1024 unless you lift the ulimit [09:56:23] <lu_zero> uhm [09:56:25] <lu_zero> right [09:56:36] <lu_zero> I did not address that yet [09:57:02] <lu_zero> what happens if you raise the limit? [09:58:07] <wbs> I'll try [09:59:17] <wbs> hmmm, it ran for a while, then it crashed in some other way [09:59:25] <wbs> outputting too much data to fit in my terminal scrollback ;P [10:00:20] <lu_zero> please fetch the latest one [10:00:41] <lu_zero> so far diego is killing his local network first before killing feng ^^; [10:00:57] <wbs> I'm just running this over loopback :-) [10:01:27] <lu_zero> you must have quite a cpu =) [10:02:02] <wbs> it's a quad xeon :-) [10:03:49] <lu_zero> I see [10:04:50] <wbs> still crashing http://pastebin.org/278334 [10:06:09] <lu_zero> interesting [10:06:19] <lu_zero> can you reproduce it in some way? [10:06:39] <lu_zero> if yes please fill a bug, I couldn't find a reliable way to cause it [10:07:45] <wbs> got the same crash at the same place in the next run, too [10:08:26] <lu_zero> great =) [10:10:49] <lu_zero> give me a report =) [10:11:09] <wbs> done [10:12:08] <lu_zero> thank you [10:14:33] <wbs> since updating it to the latest version, it doesn't crash if the max file descriptor limit is at 1024 as normal, but it hangs instead, not able to serve new clients [10:14:37] <wbs> I'll file a separate bug for that [10:18:46] <lu_zero> thank you [10:29:48] <lu_zero> do you have valgrind handy? [10:36:39] <CIA-93> ffmpeg: cehoyos * r23309 /trunk/libavformat/riff.c: Samsung uses SIPP as FourCC for MPEG-4 ASP. [10:51:16] <_av500_> lol: https://review.source.android.com/#patch,sidebyside,14699,1,libc/memset.c [10:51:33] <_av500_> never mind the byte access [10:52:23] <spaam> _av500_: do you ever set it do something else then 0? ;) [10:52:27] <kshishkov> the question is how they found out the bug [10:56:14] <janneg> libavcodec/4xm.c: memset(up, -1, sizeof(up)); [10:56:41] <_av500_> so thex want to add 4xm to android... [10:56:49] <spaam> haha [10:56:50] <_av500_> whatever that is,,, [10:57:21] <janneg> and aac and ac3 [10:57:45] <_av500_> aac they have [10:57:58] <_av500_> ac3 they will never have [10:58:14] <mru> nor dts [10:58:21] <mru> because the omap3 isn't certified for dts [10:58:21] <janneg> libavcodec/anm.c: memset(*dst, pixel, striplen); [10:58:28] <janneg> whatever that is [10:58:56] <janneg> cavs uses non-0 memsets too [10:59:58] <wbs> lu_zero: I'll give it a try [11:03:20] <mru> http://carlodaffara.conecta.it/?p=420 [11:09:58] <astrange> get_buffer uses memset 0x80 [11:15:49] <Kovensky> "It is also true that x264 beats the hell on current VP8 encoders (and basically every other encoder in the market); despite this, in a previous assessment Dark Shiraki performed a comparison of anime (cartoon) encoding and found that VP7 was better than Apple’s own H264 encode – not really that bad." [11:15:57] <Kovensky> I like how he says that beating Apple's encoder is something to brag about [11:16:28] <mru> the real question is whether he has any qualifications whatsoever to comment on patent issues [11:17:41] <Compn> no, he does not [11:17:54] <Compn> patent lawyers also do not if you think about it [11:17:57] <Kovensky> next time people will say beating Bink or Indeo is a good thing [11:17:59] <Compn> most anything is patented [11:18:09] <Kovensky> in b4 talking about patents is patented [11:18:20] * pJok patent trolls ffmpeg [11:19:15] <jai> "Dark Shiraki"? [11:20:03] <janneg> http://fosspatents.blogspot.com/2010/05/webm-vp8-safe-and-royalty-free.html [11:28:06] <KotH> -- [11:28:08] <KotH> Google's refusal to indemnify (let alone to hold harmless) calls into question that Google is really certain that there's no potential problem with patents [11:28:11] <KotH> -- [11:28:44] * KotH wonders how anyone can have such a twisted logic [11:29:38] <elenril> >certain >patents [11:30:10] <KotH> even if it wouldnt be about patents [11:30:38] <KotH> because they do not A, it means B, where as A and B have no connection what so ever [11:42:53] <lu_zero> ^^ [12:14:29] <Evgeny> hi. how to use random mechanism in ffmpeg? thanks [12:26:59] <jai> random mechanism? [12:27:06] <jai> do you mean the prng? [12:27:15] <jai> Evgeny: ^ [12:28:07] <janneg> KotH: posters are here [12:30:36] <lu_zero> mru: ping [12:31:13] <mru> pong [12:31:26] <lu_zero> regarding libvpx build system [12:32:24] <lu_zero> I'm tempted to start factor some components of ffmpeg's configure so they could be properly shared across project that might like to use it [12:32:55] <lu_zero> are you against, strongly against or you'd kill me if I try that? [12:32:58] <lu_zero> ^^ [12:33:06] <mru> I don't have time to review it now [12:33:57] <lu_zero> it would take some time for me as well, just wanted to know if you think could be useful or you'd hate it [12:34:46] <mru> there are some things I'd like to do first [12:34:54] <mru> but I simply don't have time for that right now [12:35:10] <lu_zero> I see =| [12:37:55] <Evgeny> <@jal> i mean that i need something like rand() function. [12:38:37] <Evgeny> now i use av_lfg_init - its send me the same values [12:38:42] <Evgeny> in every start [12:51:39] <iive> mru: would you be so kind to add mmst protocol as depending on network? [12:52:21] <mru> patches welcome [12:52:36] <iive> it's one line, and i can commit it myself. [12:53:11] <mru> not until you post a patch [12:53:57] <iive> you are mainteiner. maintin it yourself. [12:54:28] <mru> I am maintainer, I approve patches [12:55:21] <kshishkov> i.e. too lazy to do it by yourself and not too lazy to give control to somebody else [12:56:33] <Compn> heh [12:56:45] <Compn> it would be funny if only it werent so pathetic ;\ [13:03:38] <CIA-93> ffmpeg: mru * r23310 /trunk/configure: mmst_protocol depends on network [13:09:21] <iive> you should have waited for the patch... i suspect that t in mmst stands for tcp, and that makes it depend on tcp_protocol.... sorry [13:09:46] <mru> you're never happy, are you [13:13:00] <Evgeny> i mean av_lfg_get [13:13:13] <Evgeny> FFMPEG doesn't let me use rand function [13:13:24] <Evgeny> and forces to use this one [13:13:32] <Evgeny> but it returns same value every time [13:13:53] <kshishkov> iive: I think all those network protocols depend on TCP or UDP [13:14:15] <kshishkov> and mmsT may stand for "tunneling" i.e. with HTTP if you meant that [13:14:54] <lu_zero> Evgeny: there isn't something to seed it? [13:15:07] <Evgeny> @lu_zero: i can use time [13:15:17] <Evgeny> but even then multithreaded [13:15:28] <kshishkov> or av_get_random_seed() [13:15:30] <iive> the mail thread says " [patch]MMS protocol over TCP" [13:15:41] <Evgeny> has a chance of causing same result [13:16:10] <lu_zero> av_lfg_init(&random_state, av_get_random_seed()); [13:16:25] <kshishkov> same story with _any_ random number - if you don't specify different seed on init you won't get different random number sequences [13:16:27] <iive> no, i'm wrong. [13:16:41] <iive> it selects, tcp... not depending on it. [13:17:06] <kshishkov> why should it? [13:17:23] <kshishkov> it should use url_open() and it will fail if protocol is not enabled [13:18:19] <Evgeny> @lu_zero: any idea which header this defined? [13:18:35] <iive> i'm talking about configure and enabling stuff for compilation. [13:19:07] <Evgeny> it's actually called now ff_random_get_seed() [13:19:40] <Evgeny> thanks anyway! :) [13:19:43] <wbs> no, actually it's called av_get_random_seed() [13:19:55] <Evgeny> @wbs: I have last week svn [13:20:06] <Evgeny> and I don't see there anywhere av_get_random_seed() [13:20:08] <wbs> Evgeny: yes, and it was changed two days ago [13:20:31] <kshishkov> ff_ version is still there until next major version change though [13:20:46] <Evgeny> heh :) [13:21:02] <wbs> yes, but the prototype is removed from the headers, so you shouldn't be using it for now code, only for binary compatibility with old libraries [13:22:00] * lu_zero is pondering about playing with the network protocols today [13:22:21] <wbs> lu_zero: do you think the Content-Base patch for ffserver is ok? [13:22:31] * kshishkov tells lu_zero it's feasible and even works on YouTube [13:24:00] <lu_zero> kshishkov: what's feasible? [13:24:08] <lu_zero> wbs: seems correct [13:24:18] <wbs> lu_zero: great, thanks [13:24:24] <lu_zero> hi BBB___ [13:26:12] <kshishkov> lu_zero: playing with network protocols, of course. There are some players supporting RTP and such [13:26:29] <lu_zero> kshishkov: I was thinking about adding dccp and sctp [13:27:23] <BBB> better [13:27:59] <kshishkov> lu_zero: dccp is for playing anime straight from IRC bots, right? [13:28:37] <Evgeny> another question [13:28:48] <Evgeny> is there any utlity to get random string built-in in ffmpeg? [13:28:58] <kshishkov> nope, why? [13:29:07] <lu_zero> kshishkov: nope =) [13:29:21] <Evgeny> @kshishkov: wondered if i need to write of my own, or there is something ready [13:29:23] <merbzt> http://www.geeks3d.com/public/jegx/200808/keyboard-for-real-coder.jpg [13:29:23] <lu_zero> sctp and dccp are some relatively new protocols like tcp and udp [13:29:50] <wbs> lu_zero: which means in practice the whole internet will drop such packets? ;-) [13:30:02] <wbs> or do they run on top of udp? [13:30:11] <lu_zero> wbs: so far feng serves through sctp w/out any issue [13:30:14] <lu_zero> they are on top ip [13:30:22] <wbs> ok [13:30:40] <kshishkov> merbzt: laaaame, you know that programs should be input with flips, not keyboards [13:30:44] <wbs> at least some ipv6-in-ipv4-tunnels may be dropped in some situations, depending on how paranoid the routers are [13:31:26] <lu_zero> in that case rtp-rtsp-http-tcp-ip totem could do [13:31:27] <lu_zero> =P [13:31:43] <wbs> :-) [13:32:01] <lu_zero> and that reminds that another proto we need is tls [13:32:06] <lu_zero> reminds me [13:32:25] <kshishkov> what we are missing? [13:32:38] <lu_zero> kshishkov: for what? [13:32:43] <kshishkov> for TLS [13:32:47] <lu_zero> uhmm [13:32:58] <lu_zero> using the bits we already have? [13:33:08] <kshishkov> of course! I sthere any other way? [13:33:12] <kshishkov> *Is there [13:33:38] <lu_zero> kshishkov: if you are willing to do this way... [13:33:54] <kshishkov> no, but I may provide some missing bits [13:35:41] * lu_zero should have a look on the tls spec [13:35:56] <lu_zero> I'd rather use openssl and be lazy [13:36:41] <lu_zero> x509 is too boring [13:36:43] * kshishkov would rather have fftls and tie rtmpdump closer to lav [13:36:51] <kshishkov> tell that to KotH [13:36:53] <lu_zero> kshishkov: I see ^^; [13:37:25] <hyc> how many times does that wheel need to be reinvented? [13:37:35] <hyc> polarssl is pretty good too [13:37:54] <hyc> compact, no kitchen sink features [13:38:21] <kshishkov> hyc: you haven't seen that BC comic about inventing wheels, have you? [13:38:31] <lu_zero> http://www.ietf.org/rfc/rfc2246.txt [13:38:47] <pJok> kshishkov, ffOS? [13:38:51] <lu_zero> hyc: why polarssl and not gnutls or openssl? [13:38:57] <kshishkov> pJok: on ffCPU [13:39:19] <kshishkov> lu_zero: because other implementations use rectangular coordinates [13:39:30] <hyc> lu_zero: I like OpenSSL too, of course. I've written a few bits of it. But it's large, and sometimes a pain to port to embedded machines. [13:39:53] <hyc> I've also written a few bits of gnutls, but only under duress. gnutls is quite poor quality code. [13:39:54] <lu_zero> kshishkov: you got flameeyes to bite you somehow? [13:40:10] <hyc> polarssl is very small, written specifically for embedded systems [13:40:10] <lu_zero> hyc: so you'd like to have a smaller ssl implementation [13:40:13] <kshishkov> lu_zero: not at all, why? [13:40:20] <lu_zero> polarssl is gpl2 [13:40:31] <lu_zero> kshishkov: same kind of humor [13:40:36] <lu_zero> http://www.polarssl.org/source_code that is useful [13:40:58] <hyc> librtmp supports all 3 of those anyway [13:41:01] <kshishkov> lu_zero: I mostly specialize on dark humour [13:41:11] <hyc> but I'm now using polarssl exclusively for my Windows builds of rtmpdump [13:43:15] <lu_zero> kshishkov: the polarssl page has a nice breakup of the various components [13:43:28] <kshishkov> Windows. Small embedded systems. Hmm, makes sense [13:43:35] <lu_zero> brb [13:43:51] <hyc> kshishkov: it was expedient. rtmpdump is gpl, polarssl is gpl. [13:43:55] <BBB> wbs: ffserver patch seems ok to me, wait for baptiste to ok it [13:44:04] <hyc> it would be a licensing problem for me to ship rtmpdump+openssl [13:44:15] <hyc> gnutls is gpl too of course, but it sucks [13:44:39] <wbs> hyc: isn't gnutls lgpl? [13:44:44] <hyc> whatever [13:44:52] <hyc> either way, I would never use it voluntarily [13:45:09] <wbs> in commercial setups, the difference between lgpl and gpl is quite important ;P [13:45:25] <wbs> BBB: yeah, I'll wait and see if he has anything to say on it [13:45:41] <Compn> ugh openssl license ;\ [13:46:15] * Compn reminds himself to not make static builds in the future [13:48:56] <hyc> wbs: I recognize that commercial environments frown on GPL. most of the people doing the frowning are dumbasses. [13:49:42] <BBB> what country is that? [13:49:50] <BBB> nowadays many corporate environments do use gpl [13:49:53] <BBB> I see it all around me [13:50:02] <BBB> and I'm not even consulting [13:50:11] <BBB> (US) [13:50:14] <wbs> hyc: it isn't about frowning on it, but you can't ship binaries linking in such code [13:50:31] <wbs> unless you gpl the whole thing of course [13:50:37] <hyc> wbs: of course you can. you simply have to make it clear to customers that source code is available. [13:51:11] <wbs> hyc: yes, code to the whole application, not just the originally gpl part [13:51:11] <Tjoppen> unless you have to deal with proprietary libraries at the same time [13:51:19] <hyc> and IMO, GPL'ing the whole thing is the correcy thing to do. [13:51:42] <hyc> if you're getting benefit from my GPL code, then you owe some reciprocation [13:53:14] <hyc> more to the point, you owe society in general... [13:53:56] <hyc> proprietary libraries == theft, theft from the public domain, etc... [13:54:10] <wbs> yes, and in the cases where that's not an option, commercial entities tend to stay away from gpl [13:54:33] <hyc> everybody who ever created some proprietary IP was educated with the benefit of the public domain [13:54:50] <wbs> and I have no problem giving back the actual changes done to the original library, as with lgpl [13:55:20] <hyc> for them to turn around and ransom their creations back to society is just piracy [13:56:04] <kshishkov> hyc: some of proprietary libraries != theft, that's just act of mercy. Look at original VP3 code [13:56:12] <hyc> lol [13:57:03] <hyc> kshishkov: we learn even more from mistakes than from successes. even crap code should be open to scrutiny. moreso. [13:58:32] <lu_zero> eh eh [14:00:04] <Tjoppen> if you're in a position to impose such things on the companies providing proprietary libraries to you that would be. that isn't usually the case though [14:00:15] <Tjoppen> *be nice [14:00:56] <hyc> Tjoppen: well, the thing to do is to make the proprietary code irrelevant [14:01:10] <hyc> write a a better library and open source it [14:01:33] <Tjoppen> yeah, the customer isn't going to pay for that [14:01:44] <Tjoppen> sadly [14:01:56] <hyc> if that's the only factor that drives your business decisions, you have problems. [14:02:25] <hyc> No customer would have ever paid for the thousands of hours we spent refactoring OpenLDAP between 2000-2003. [14:02:48] <hyc> but the fact is the code base is now the fastest in the world, and we have customers migrating to us all the time now. [14:03:49] <hyc> 2 years ago Microsoft AD had 85% of the directory market, OpenLDAP had 10%. Today M$ has 70%, OpenLDAP has 22%. [14:04:29] <Tjoppen> OpenLDAP isn't GPL though, unless I'm mistaken [14:04:44] <hyc> you have to make a decision "we're going to fix this code because it's the right thing to do" regardless of whether any current customers ask for it. [14:05:31] <hyc> No, it's OpenLDAP License, BSD-derivative [14:05:31] <Tjoppen> eventually it'll probably come to developing libraries of one's own [14:05:46] <Tjoppen> either to get around the proprietary libs, or the gpl ones [14:06:38] <hyc> Still the point remains - create in the open, and make the closed stuff irrelevant [14:07:20] <Tjoppen> sure, but what are you going to do until the free library is good enough to replace the old one? [14:07:34] <hyc> suffer for a while I guess. [14:07:36] <Tjoppen> code I guess :o [14:07:38] <hyc> we had no choice... [14:07:41] <hyc> exactly [14:08:46] <hyc> there's no instant gratification, everything takes work [14:09:34] <hyc> rtmpdump is the same way. Adobe has locked-down platforms. until we put in sufficient time to decipher all of the locks, we're dead in the water. [14:10:09] <hyc> but eventually it all unfolds, and now rtmpdump provides all the functionality on any platform, while Adobe still has only their handful of supported systems [14:12:21] <hyc> and in comparison, the free solution now uses 100x less CPU than Adobe's... [14:13:40] <hyc> seems like the only benefit of proprietary code is to hide poor craftmanship [14:14:04] <kshishkov> that's what I've said [14:24:42] <CIA-93> ffmpeg: michael * r23311 /trunk/libavcodec/golomb.c: [14:24:42] <CIA-93> ffmpeg: Correct golomb vlc decoding tables. [14:24:42] <CIA-93> ffmpeg: Fixes issue 1930 [14:25:44] <kierank> yay [14:34:13] <BBB> lu_zero: thanks for the email [14:35:00] <lu_zero> BBB: I wrote about it long ago in the private ml but had no replies ^^; [14:35:10] <BBB> I probably forgot to read it [14:38:48] <hyc> I'm guessing that a patch to make av_parser_init() take an AVCodecContext instead of a codec_id won't fly [14:38:50] <hyc> ? [14:41:30] <BBB> you could add a av_parser_init2() [14:41:39] <BBB> if there's a good reason [14:42:08] <hyc> the actual parsers' init functions would also need to change, to make it worth the effort [14:42:22] <hyc> instead of just parser_init(AVCodecParserContext) [14:42:34] <hyc> would also want to pass the AVCodecContext there [14:43:20] <hyc> seems like there are quite a few parsers... [14:44:01] <hyc> and apparently aside from h264, none of them need this, otherwise this API would have been changed before now [14:44:09] <hyc> hmm... [14:45:17] <hyc> I dunno. it seems like the most obvious fix to me but maybe someone else will have a better idea [14:48:20] <BBB> is this b/c of the extradaat? [14:48:26] <hyc> right [14:48:36] <BBB> I mean, I'm not against it but I'm not a maintainer of that code either so I can't help you much ;) [14:49:05] <BBB> submit a patch [14:49:13] <BBB> I think it's ok, just don't change any existing symbols [14:49:20] <hyc> it would be a big patch, to update all the existing parsers [14:49:21] <BBB> add new symbols instead, so API/ABI doesn't change incompatibly [14:49:27] <BBB> why update all of them? [14:49:33] <BBB> parser_init() wouldn't change [14:49:38] <BBB> you'd add a parser_init2() [14:49:42] <hyc> oh [14:49:45] <BBB> and update h264parse accordingly [14:49:47] <hyc> hmmm [14:49:48] <BBB> otherwise it's an ABI change [14:49:57] <hyc> ok [14:50:02] <BBB> and add a fallback that aclls parse_init() if init2() is NULL [14:50:11] <hyc> right [14:50:20] <BBB> and av_parse_init() should call av_parse_init2(bla, NULL) or so [14:50:24] <BBB> you know what I mean :) [14:50:29] <hyc> right [14:50:48] <hyc> well, I need to look at it some more, see if this can be fixed without any new APIs [14:50:49] <BBB> don't forget to deprecate av_parse_init() [14:50:54] <BBB> ok [14:51:24] <hyc> deprecate it? I'll insult it and its mother. :P [14:51:47] <BBB> woohoo [15:01:04] <Tjoppen> BBB: did you see my simple web server thing on the ML? should suffice to test the patch [15:01:18] <BBB> yes [15:01:22] <BBB> I should look at it :) [15:01:26] <BBB> keep kicking me [15:01:29] <Tjoppen> :) [15:01:30] <BBB> I'll do it eventually, really [15:01:38] * BBB puts on todo list [15:02:37] <Tjoppen> ok. back to wrestling SMPTE 12M timecodes [15:03:21] <Tjoppen> I've managed to parse their 8-byte representation into useful sequential AVRational-ish time codes [15:03:41] <Tjoppen> accounting for drop frames and the like. it's magic [15:04:19] <_av500_> drop frames [15:04:22] <_av500_> nice [15:04:29] <kierank> eugh drop frames [15:04:53] <_av500_> wasnt there an epic discussion about that some while ago? [15:05:32] <Tjoppen> they're an abomination. in fact, NTSC is an abomination [15:05:46] <Tjoppen> </work> [15:06:19] <Tjoppen> <pizza_buffet_and_beer> [15:08:56] <BBB> want_pizza1 [15:14:38] <lu_zero> BBB: should I send it through dcc? [15:16:40] <BBB> sure [15:16:49] <BBB> homemade? [15:17:24] <lu_zero> anybody knows a sane and fast way to know how many fd are allocated from within program? [15:17:45] <lu_zero> (opening /proc/self/fd or similar isn't that good) [15:18:14] <lu_zero> BBB: I know how to make that but there are way better source for pizza [15:18:45] <lu_zero> (btw a multimedia conference in italy would be interesting to organize) [15:19:12] <wbs> lu_zero: don't know if it's easily accessible from within the program; if you look at the number of the latest opened socket, you might get a clue, but once you start closing old ones, it won't help you [15:19:27] <lu_zero> that is the annoying part ^^; [15:19:34] <jai> lu_zero: of course :) [15:20:15] <_av500_> lu_zero: with spaghetti code sessions? [15:20:19] * _av500_ hides [15:20:25] <wbs> doh [15:20:29] <lu_zero> tortellini code sessions [15:20:45] <lu_zero> we do OOP in ffmpeg =P [15:21:01] <jai> i can finally get that monica bellucci autograph i wanted... [15:21:21] <lu_zero> (the filling is obviously inline assembly) [15:40:25] <CIA-93> ffmpeg: rbultje * r23312 /trunk/libavformat/rmdec.c: [15:40:25] <CIA-93> ffmpeg: We're using generic tag-to-ID functions, so specific codec_id assignments [15:40:25] <CIA-93> ffmpeg: are no longer necessary. Patch by Zhou Zongyi <zhouzy AT os pku edu cn>. [17:03:03] <hyc> well if it's any consolation, totem SEGVs for me on the mkv in issue 1831 [17:03:42] <hyc> the OP said totem worked and vlc/mplayer crashed [17:05:16] <kshishkov> totem worked? on anything? he's lying! [17:05:39] <hyc> lol [17:07:21] * Compn wishes xine/vlc/mplayer would share more samples n bugreports [17:10:00] <bilboed-pi> hyc, totem using gstreamer git works fine though [17:10:16] <bilboed-pi> fine => no video [17:20:54] <hyc> going to feed it into the reference decoder and see what it says [17:34:18] * peloverde seems to have broken his git-svn setup and can't seem to reclone [17:42:00] <peloverde> Is there some sort of git-am for svn? [17:58:11] <kierank> is there going to be a 0.5.2 announcement on ffmpeg.org? [18:02:11] <siretart> kierank: there is already? [18:02:26] <siretart> kierank: first point in the NEWS section [18:02:59] <kierank> hmmm seems there's something caching it [18:03:03] <kierank> it's appeared now [18:21:53] <CIA-93> ffmpeg: siretart * r23313 /branches/ (5 files in 4 dirs): [18:21:53] <CIA-93> ffmpeg: matroskadec: Support webm doctype [18:21:53] <CIA-93> ffmpeg: Patch by James Zern <jzern at google> [18:21:53] <CIA-93> ffmpeg: backport r23245 by conrad [18:22:51] <CIA-93> ffmpeg: siretart * r23314 /branches/ (0.6 0.6/libavformat/matroskadec.c): [18:22:51] <CIA-93> ffmpeg: matroskadec: Allow unknown EBML doctype [18:22:51] <CIA-93> ffmpeg: backport r23246 by conrad [18:23:29] <CIA-93> ffmpeg: siretart * r23315 /branches/ (0.6/libavformat/matroskaenc.c 0.6): [18:23:29] <CIA-93> ffmpeg: matroskaenc: Don't write track timecode scale [18:23:29] <CIA-93> ffmpeg: It's not required for mkv and unsupported in webm [18:23:29] <CIA-93> ffmpeg: backport r23247 by conrad [18:25:05] <CIA-93> ffmpeg: alexc * r23316 /trunk/libavcodec/aaccoder.c: aacenc: Factor out find_min_book so it can be used by multiple coefficient coders. [18:29:06] <CIA-93> ffmpeg: alexc * r23317 /trunk/libavcodec/aaccoder.c: [18:29:06] <CIA-93> ffmpeg: aacenc: Only trellis over a column of 61 scalefactors (reduced from 256). [18:29:06] <CIA-93> ffmpeg: This still provides plenty of dynamic range, makes every move legal, and greatly reduces the search space. [18:32:47] <CIA-93> ffmpeg: alexc * r23318 /trunk/libavcodec/aaccoder.c: [18:32:47] <CIA-93> ffmpeg: aacenc: Trellis over scalefactors using an estimated codebook rather than every codebook. [18:32:47] <CIA-93> ffmpeg: The minimal codebook to encode the band without clipping is used (as is done in the TLS). [18:33:31] <saintdev> :O [18:33:50] <CIA-93> ffmpeg: alexc * r23319 /trunk/libavcodec/aaccoder.c: Remove useless costly inf checks from the trellis scalefactor search. [18:34:29] <CIA-93> ffmpeg: siretart * r23320 /branches/ (6 files in 4 dirs): [18:34:29] <CIA-93> ffmpeg: Update regression tests after removing track timecode scale from mkvenc [18:34:29] <CIA-93> ffmpeg: backport r23248 by conrad [18:35:11] <CIA-93> ffmpeg: siretart * r23321 /branches/ (0.6 0.6/libavcodec/avcodec.h): [18:35:11] <CIA-93> ffmpeg: Document CODEC_FLAG_EMU_EDGE and avcodec_align_dimensions interaction. [18:35:11] <CIA-93> ffmpeg: backport r23258 by reimar [18:35:53] <CIA-93> ffmpeg: alexc * r23322 /trunk/libavcodec/aaccoder.c: aacenc: Split find_max_val() from find_min_book() to eliminate duplicate searches. [18:38:00] <saintdev> \o/ less sucky aacenc [18:38:28] <peloverde> Actually that is all improvement to code that is turned off [18:38:50] <peloverde> but it does makes the trellis search operate at a usable speed [18:46:00] <janneg> bcoudurier: hi [18:46:19] <saintdev> reverse onjoin, haha [18:46:37] <bcoudurier> hi [18:47:43] <janneg> bcoudurier: you've pinged me yesterday [18:55:27] <bcoudurier> indeed, but I can't remember why now [18:56:45] <janneg> maybe experimental decoders/encoders? [19:01:00] <Tjoppen> hm. I wonder if I could convince my employer and our client to let me go to that convention coming up [19:09:47] <_av500_> tattoo convention? [19:12:24] <Tjoppen> no? [19:14:18] <CIA-93> ffmpeg: mstorsjo * r23323 /trunk/libavcodec/api-example.c: [19:14:18] <CIA-93> ffmpeg: api-example: Try to avoid decoding incomplete frames [19:14:18] <CIA-93> ffmpeg: Use a larger input audio buffer, refill it when it has less than 4 KB data [19:14:18] <CIA-93> ffmpeg: left. [19:17:06] <CIA-93> ffmpeg: mstorsjo * r23324 /trunk/libavcodec/api-example.c: Cosmetics: reindent after the previous commit [19:18:21] <wbs> bcoudurier: ok to add the Content-Base header in RTSP replies from ffserver? http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20100525/5fb50… [19:21:40] <bcoudurier> yes [19:23:50] <wbs> thanks [19:24:09] <CIA-93> ffmpeg: mstorsjo * r23325 /trunk/ffserver.c: [19:24:09] <CIA-93> ffmpeg: ffserver: Send a Content-Base header in the reply to RTSP DESCRIBE requests [19:24:09] <CIA-93> ffmpeg: This is needed for QuickTime Player to be able to connect properly. [19:24:42] <hyc> wbs: hmm, bypassing that initial av_seek_frame() in ffserver also seems to work, without the libavformat/utils.c patch [19:25:24] <hyc> if (stream_pos && c->fmt_in->iformat->read_seek) [19:25:24] <wbs> hyc: hmm, interesting [19:25:49] <hyc> of course, I don't know what that does if we actually provide a seek position [20:43:42] <twnqx> uau: what was necessary again to get -af lavcac3enc? :X [20:46:39] <spaam> uau is not here twnqx ;) [20:48:26] <twnqx> that doesn't solve my problem [20:48:40] <spaam> ) [20:56:56] <CIA-93> ffmpeg: siretart * r23326 /branches/ (0.6 0.6/ffplay.c): [20:56:56] <CIA-93> ffmpeg: FFplay : Avoid manipulating NULL data pointers so that future checks [20:56:56] <CIA-93> ffmpeg: remain valid. This fixes segfaults for those cases where data copy to [20:56:56] <CIA-93> ffmpeg: this invalid pointer is attempted. [20:56:56] <CIA-93> ffmpeg: backport r23264 by jai_menon [20:57:33] <CIA-93> ffmpeg: siretart * r23327 /branches/ (0.6 0.6/ffplay.c): [20:57:33] <CIA-93> ffmpeg: Cosmetics : re-indent after last commit. [20:57:33] <CIA-93> ffmpeg: backport r23265 by jai_menon [21:00:52] <merbanan> siretart: can you backport my aea demuxer patches ? [21:03:01] <siretart> merbanan: that's r23272 & r23273, right? [21:03:07] <merbanan> yes [21:03:19] <siretart> already scheduled [21:08:18] <merbanan> tnx [21:22:46] <spaam> dylanza: hard to chose? stay or not to stay? ;) [21:23:04] <_av500_> stay [21:23:12] <_av500_> no, dont [21:23:37] <BBB> so google chrome uses ffmpeg for html5 right? [21:23:44] <thresh> yes [21:23:47] <dylanza> ah, sorry - was cleaning quassel logs. it doesnt make it easy [21:23:58] <BBB> awesome, I'm actually using ffmpeg now :-p [21:24:25] <spaam> BBB: didnt you use ffmpeg before? :P [21:24:46] <BBB> well, I use it, but it's fun to know that the software you use everyday uses it also [21:24:47] <mru> everybody uses ffmpeg [21:25:15] <BBB> unfortunately, it doesn't do vp8 [21:25:21] <spaam> BBB: never heard of vlc? :P [21:25:41] <BBB> vlc is a media player, it requires media [21:25:46] <BBB> I hardly watch videos except for youtube [21:25:53] <BBB> I watch dvds on my dvd player from sony [21:26:02] <BBB> and itunes doesn't use ffmpeg :( [21:26:26] <wbs> BBB: with perian, I guess you can get itunes to use ffmpeg ;P [21:26:44] <mru> BBB: youtube uses ffmpeg [21:26:50] <BBB> that's true [21:28:08] <Yuvi> interesting, -Werror=missing-prototypes doesn't seem to be included in -Wall -Werror [21:28:38] <mru> probably because -Wall doesn't include it [21:29:24] <Yuvi> yeah, just strange because if it was, this broken system header probably would've been found sooner [21:29:36] <mru> which system? [21:29:43] <Yuvi> emmintrin.h on apple gcc 4.2 [21:30:07] <mru> why would you want to use that? [21:30:12] <Yuvi> I don't [21:30:31] <Yuvi> but including most any of apple's frameworks winds up including it [21:30:38] <DonDiego> Yuvi: wanna fix that theora crash? ;) [21:30:47] <Yuvi> DonDiego: do you have symbols? [21:30:56] <DonDiego> let me fire up my desktop and try with ffplay_g.. [21:31:03] <DonDiego> give me 5 mins [21:31:26] <mru> so don't use apple's frameworks [21:42:27] <BBB> Yuvi: I haven't much looked at vp8 so far, and you've been very active in it, could I be helpful at all there? [21:43:03] <mru> we need a native decoder [21:43:09] <Dark_Shikari> just take vp6 and rewrite a few things [21:45:09] <mru> vp5678.c? [21:45:35] <Dark_Shikari> lol [21:45:58] <hyc> vpn.c :P [21:46:08] <hyc> but then people will mistake it for networking... [21:47:11] <Dark_Shikari> vpx.c [21:47:12] <Dark_Shikari> ;) [21:48:51] <saintdev> gah, beat me to it [21:49:25] <_av500_> on2/google beast you all to it [21:49:31] <_av500_> lol beat [21:52:18] <CIA-93> ffmpeg: michael * r23328 /trunk/libavcodec/h264_ps.c: [21:52:19] <CIA-93> ffmpeg: Check for VUI overeading and reset num_reoder_frames. [21:52:19] <CIA-93> ffmpeg: This helps the video from issue1831 [21:53:02] <DonDiego> mru: what's the best way to disable the vorbis encoder, but allow it to be enabled explicitly in configure? [21:53:16] <DonDiego> i don' t see an obvious way [21:53:46] <BBB> CONFIG_EXPERIMENTAL? [21:53:47] <DonDiego> i can place a 'disable vorbis_encoder' in the right spot, but then there will be no possibility to override it [21:54:01] <mru> that's hackish [21:54:04] <Dark_Shikari> why not make it like snow [21:54:06] <Dark_Shikari> require -vstrict -2 [21:54:08] <DonDiego> BBB: that's on trunk.. [21:54:26] <mru> vorbis_encoder_deps=experimental would do it [21:54:36] <mru> and add experimental to CONFIG_LIST [21:54:46] <DonDiego> but that's only on trunk, right? [21:55:05] <mru> that's CODEC_CAP_EXPERIMENTAL [21:55:12] <mru> and that's probably enough [21:55:17] <mru> no need to disable in configure [21:55:44] <DonDiego> is that available on the 0.6 branch or is that janneg's recent code? [21:56:29] <mru> it hasn't been committed yet afaik [21:57:41] <DonDiego> hrmpf [21:59:29] <DonDiego> i need something quick and dirty that works on the branch :) [22:00:24] <DonDiego> i promised the xiph folks to disable the vorbis encoder (by default) and it does make sense to do so.. [22:02:27] <mru> ping janneg's patch first [22:02:35] <mru> if no response by tomorrow we'll think of something [22:03:24] <janneg> DonDiego: the right spot for "disable vorbis_encoder" would be immediately after "enable $ARCH_EXT_LIST" [22:03:38] <DonDiego> janneg: i found that place already :) [22:03:58] <DonDiego> although, admittedly, my knowledge of configure is getting a little rusty.. [22:04:22] <DonDiego> janneg: ping your patch please, say that i want it for 0.6.. [22:04:59] <DonDiego> Yuvi: you have mail, i redid the valgrind trace with ffplay_g (although this is the older system valgrind version) [22:05:00] <janneg> DonDiego: my patch doesn't help against ffmpeg -acodec vorbis [22:05:27] <DonDiego> hmm [22:05:43] <DonDiego> then we need something else i guess [22:08:59] <bcoudurier> I agree [22:09:09] <bcoudurier> I'd say do on trunk as well [22:09:17] <bcoudurier> disable vorbis encoder in configure by default [22:09:18] <mru> disabling it still won't make -acodec vorbis do the right thing [22:09:30] <bcoudurier> no, but people cannot do -acodec vorbis _at all_ [22:09:46] <bcoudurier> so they will search for methos [22:09:49] <bcoudurier> methods [22:10:06] <mru> janneg: could your patch be extended to refuse the experimental codecs unless some extra flag is provided? [22:10:10] <bcoudurier> and hopefully find -acodec libvorbis [22:10:21] <bcoudurier> and we also could print a warning [22:10:39] <bcoudurier> "you typed vorbis, you might want to use libvorbis instead" [22:10:54] <DonDiego> something should indeed happen on that front [22:11:17] <DonDiego> however, if we cannot make up our minds what... [22:11:28] <peloverde> who is maintainer? [22:11:32] <DonDiego> maybe svn rm vorbisenc.c :) [22:11:42] <mru> I suggested that years ago [22:11:52] <DonDiego> peloverde: nobody, that's why the code is so crappy.. [22:12:05] <peloverde> who committed it? [22:12:09] <bcoudurier> oded did [22:12:25] <bcoudurier> well we also have aac encoder ;) [22:12:45] <DonDiego> but the aac encoder is moving forward - slowly, but moving [22:12:56] <DonDiego> the vorbis encoder is moving nowhere slow [22:12:58] <bcoudurier> well we should stay modest on this one [22:13:17] <bcoudurier> and avoid doing 2 weights 2 measures [22:13:42] <DonDiego> ? [22:13:48] <DonDiego> was that french? [22:13:50] <DonDiego> :) [22:13:52] <bcoudurier> yes [22:13:53] <bcoudurier> :) [22:14:03] <DonDiego> translation please :) [22:14:04] <bcoudurier> doing the idomatic corresponding hehe [22:14:06] <bcoudurier> dunno [22:14:11] <bcoudurier> idiomatic [22:14:16] <bcoudurier> I sucks :( [22:14:17] <peloverde> AVCodec.name to "ffvorbis" will that work? [22:14:34] <bcoudurier> anyway, aac encoder will also be tagged as "experimental" [22:14:50] <bcoudurier> I'd say just disable by default the vorbis encoder [22:15:23] <bcoudurier> then if you want to easily workaround, just translate "vorbis" to "libvorbis" [22:15:41] <bcoudurier> in opt_codec_name or something [22:15:47] <janneg> bcoudurier: patch for encoders only sent [22:15:49] <bcoudurier> hackish but simple [22:16:18] <DonDiego> i think a plain [22:16:24] <DonDiego> disable vorbis_encoder [22:16:33] <DonDiego> in configure will be the best solution for the branch [22:16:53] <bcoudurier> janneg, did you send the smae patch ? :> [22:17:01] <bcoudurier> in trunk as well [22:17:03] <DonDiego> that encoder should *not* be used in production [22:17:19] <DonDiego> if you want to do development on it, trunk is the right place anyway [22:17:28] <bcoudurier> but like mru said, it won't make "-acodec vorbis" use libvorbis [22:17:29] <DonDiego> mru: any quick alternative solutions? [22:17:32] <janneg> mru: not easily, avcodec_find_encoder only has a codec id as parameter [22:17:43] <DonDiego> bcoudurier: -acodec vorbis will fail [22:17:48] <bcoudurier> yes [22:17:51] <DonDiego> and people will have to learn about libvorbis [22:17:53] <bcoudurier> that's what I said [22:17:57] <DonDiego> ah, ok :) [22:18:16] <bcoudurier> mru, are you ok with this ? [22:18:18] <DonDiego> you're as smart as me then [22:18:23] <DonDiego> only - quicker.. [22:18:24] <DonDiego> :) [22:18:24] <bcoudurier> lol [22:18:27] <mru> ok with what? [22:18:34] <bcoudurier> disable vorbis by default [22:18:45] <mru> depends on how it's done [22:18:45] <bcoudurier> on trunk and on the branch [22:18:49] <bcoudurier> in configure [22:18:53] <mru> depends on how it's done [22:19:12] <janneg> I have patch for ffmpeg to fail if a codec is experimental and strict > -2 [22:19:19] <mru> that should do it [22:19:41] <DonDiego> that sure is cleaner, but it's not yet available [22:19:46] <DonDiego> i want something *now* [22:19:49] <mru> what about the avcodec_find_{en,de}coder_by_name functions? [22:20:02] <mru> DonDiego: you can wait one more day [22:20:13] <DonDiego> i guess.. [22:20:20] <DonDiego> Yuvi: seen my mail? [22:20:54] <bcoudurier> IMHO there is nothing to change in decode_by_name [22:21:00] <mru> no, there's not [22:21:03] <mru> of course not [22:21:12] <mru> just make it fail w/o right -strict [22:21:14] <mru> or whatever [22:21:21] <bcoudurier> you'd have to pass -strict [22:21:30] <bcoudurier> this is awkward [22:21:40] <mru> janneg: will you send the patch? [22:23:30] <bcoudurier> btw how the auto pthreads topic ended ? [22:23:47] <mru> in a bikeshed [22:23:56] <mru> I'll now lock the door and toss the key [22:24:11] <bcoudurier> humm it seems that we all agreed to autodetect it, no ? [22:24:48] <bcoudurier> last mail in the thread is 04/19 from you, and you said ok [22:32:16] <DonDiego> please move that stuff forward finally [22:32:25] <DonDiego> another idea for vorbis: [22:32:41] <DonDiego> we could just disable the avcodec declaration in vorbisenc.c [22:32:50] <DonDiego> then the code will still get compile-tested [22:32:56] <DonDiego> but encoding will not work.. [22:36:09] <janneg> bcoudurier: yes, sorry forgot to commit [22:36:24] <janneg> mru: of course, was distracted [22:37:42] <DonDiego> so.. [22:37:52] <janneg> it compiles [22:38:02] <DonDiego> shall i open a thread on -devel about the vorbis encoder? [22:47:42] <BBB> DonDiego: yes [22:47:46] <janneg> DonDiego, mru: patch sent [22:54:29] <CIA-93> ffmpeg: cehoyos * r23329 /trunk/libavcodec/vorbis_enc.c: [22:54:29] <CIA-93> ffmpeg: Do not invert samples when encoding Vorbis. [22:54:29] <CIA-93> ffmpeg: Patch by Frank Barchard, fbarchard google [22:56:03] <CIA-93> ffmpeg: aurel * r23330 /trunk/libavformat/matroskadec.c: matroskadec: avoid potential crash after r23169 [23:11:43] <mru> DonDiego: see r19149 and r19290 [23:15:10] <DonDiego> oh, i faintly remember that.. [23:15:29] <DonDiego> that would be an ok solution as well [23:15:49] <DonDiego> but on the branch disabling in configure is better i think [23:16:06] <mru> http://article.gmane.org/gmane.comp.video.ffmpeg.devel/91490 [23:16:19] <mru> I find your reversal of opinion curious [23:16:20] <DonDiego> otherwise configure lists it in the list of enabled encoders [23:16:21] <mru> but welcome [23:16:35] <DonDiego> umm, no, it will not [23:17:10] <mru> full thread: http://thread.gmane.org/gmane.comp.video.ffmpeg.devel/90998 [23:17:30] <DonDiego> my comment there goes in a somewhat different direction [23:19:20] <DonDiego> oh, ivan is active in that thread.. [23:19:37] <DonDiego> no wonder it did not produce the intended results ;) [23:22:07] <mru> lol CODEC_CRAPABILITY [23:26:17] <CIA-93> ffmpeg: alexc * r23331 /trunk/libavcodec/aaccoder.c: Fix declaration after statement [23:27:44] <saintdev> aacenc is feeling so loved today [23:29:13] <peloverde> That's more loving ancient compilers than aacenc [23:29:39] <Dark_Shikari> s/ancient/microsoft [23:30:08] <janneg> and gcc 2.95 [23:30:50] <mru> that reminds me, I need to file a bug for armcc [23:31:52] <mru> it fails on some c99 stuff in gcc mode [23:31:56] <peloverde> Did we ever come up with a good solution about multi-level const arrays? they choke out all other warnings for me [23:32:09] <mru> ignore michael and fix the code? [23:44:29] <peloverde> some of the other warnings gcc 2.95 spits out makes me wonder if aacenc works on 2.95 at all [23:44:41] <mru> like? [23:46:10] <peloverde> It seems to find void* aritmetic where there is none [23:46:25] <mru> ? [23:47:00] <DonDiego> Yuvi: ping [23:47:12] <peloverde> aaccoder.c:346 [23:47:22] <peloverde> "memset(sce->zeroes + win*16 + start, !stackcb[i], count);" [23:47:41] <peloverde> uint8_t zeroes[128]; [23:48:22] <peloverde> (win and start are both int) [23:48:22] <mru> is memset a macro that expands to something interesting? [23:48:40] <peloverde> I don't know, gcc-2.95 does not support my architecture [23:49:00] <peloverde> and I don't have access to said fate machine [23:49:01] <mru> I managed to shoehord a 2.95 build on my ppc machine [23:49:10] <mru> *horn [23:49:58] <peloverde> Can fate give me preprocessed source or anything else useful? [23:50:19] <mru> note the /usr/include/bits/string2.h:454: warning: pointer of type `void *' used in arithmetic [23:50:58] <DonDiego> mru: gcc 2.95 totally sucks on ppc.. [23:51:17] <peloverde> Looks like libc is broken? [23:51:20] <mru> I didn't intend to actually use it [23:51:30] <mru> gcc 2.95 totally sucks everywhere [23:51:38] <Dark_Shikari> s/2.95// [23:51:49] <mru> 4.3 sucks a hell of a lot less [23:52:01] <mru> 4.4 sucks about 25% more than 4.3 [23:52:13] <mru> 4.5 about 25% less than 4.4 [23:52:37] <Dark_Shikari> lol [23:54:08] <saintdev> hmm, odd number gcc theory? [23:54:22] <mru> do the maths [23:54:27] <mru> 4.5 is still worse than 4.3 [23:54:50] <saintdev> oh wait that's 4.4 [23:55:06] <saintdev> yeah, for some reason i read 4.3 for both :p [23:55:06] <mru> 3.4 was ok though [23:55:09] <mru> at the time [23:55:13] <Dark_Shikari> 3.4 is still ok [23:55:19] <mru> 4.3 is better [23:55:21] <Dark_Shikari> it's still less buggy than 4.x a lot of the time [23:55:27] <mru> different bugs [23:55:29] <Dark_Shikari> True. [23:55:37] <mru> old code probably avoids them

1 0

IRC log for 2010-05-24
by irc＠mansr.com 24 May '10

24 May '10

[00:00:06] <mru> there's nothing mmx-specific about it [00:00:29] <bcoudurier> ok [00:17:30] <bcoudurier> mru it's entangled :/ [00:17:39] <bcoudurier> mm_support is also present for arm [00:17:56] <bcoudurier> and the MM_ are defined in avcodec.h [00:40:38] <DonDiego> siretart: you wanted me to read through the changelog or something? [00:40:46] <DonDiego> release notes.. [00:44:53] <CIA-93> ffmpeg: conrad * r23280 /trunk/libavutil/rational.c: [00:44:53] <CIA-93> ffmpeg: Convert NaN to 0/0 in av_d2q [00:44:53] <CIA-93> ffmpeg: This fixes aspect ratio calculation for encoding from files with 0/0 stored, [00:44:53] <CIA-93> ffmpeg: common with ogg/theora [01:03:03] <DonDiego> Yuvi: 0.6 material? [01:03:37] <Yuvi> I think so, it's a regression I accidentally introduced (maybe after the 0.6 branch?) [01:04:02] <DonDiego> please doublecheck, thx [01:04:29] <Yuvi> r22898, so just before [01:04:43] <DonDiego> then please merge it [01:05:17] <Yuvi> hm, I don't have a svn checkout [01:07:10] <Yuvi> svn merge -r 23279:23280 ? [01:07:40] <DonDiego> no [01:08:04] <DonDiego> svn merge -c 23280 ^/trunk [01:08:37] <DonDiego> nm, i can do it [01:08:42] <DonDiego> but my machine compiles slowly.. [01:17:20] <bcoudurier> what's still missing for vp8 integration ? [01:21:10] <astrange> libvpx decode [01:21:19] <DonDiego> libvpx encode [01:22:01] <bcoudurier> how does the decoder patch look ? [01:22:16] <DonDiego> getting better afaict [01:34:28] <CIA-93> ffmpeg: diego * r23281 /branches/0.6/ (6 files in 2 dirs): Ignore generated files in the libswscale directory. [02:10:29] <CIA-93> ffmpeg: diego * r23282 /branches/ (0.6/libavformat/oggdec.c 0.6): [02:10:29] <CIA-93> ffmpeg: Enable AVFMT_GENERIC_INDEX for Ogg demuxer. This avoids the many [02:10:29] <CIA-93> ffmpeg: seeks needed for binary search when seeking to a previously seen [02:10:29] <CIA-93> ffmpeg: location. [02:10:29] <CIA-93> ffmpeg: backport r23279 by reimar [02:19:09] <DonDiego> Yuvi: about your last commit message.. [02:19:37] <DonDiego> if you start with "this", then your phrasing is automatically bad [02:20:01] <Yuvi> how so? [02:20:11] <DonDiego> "this sentence tells you that commit messages should be direct." [02:20:15] <DonDiego> compare with [02:20:29] <DonDiego> "commit messages should be direct [02:20:31] <DonDiego> " [02:20:36] <DonDiego> see the difference? [02:20:49] <DonDiego> you are already telling it, no need to tell that you are telling it [02:21:18] <Yuvi> yes, but with that sentence without the "this" there's no subject for the sentence [02:21:58] <Yuvi> err, with the sentence in my commit [02:22:20] <Yuvi> with yours, the subject changes [02:22:30] <DonDiego> s/this fixes/fix/ [02:22:34] <DonDiego> and you're done [02:22:48] <DonDiego> shorter even [02:23:09] <DonDiego> technical prose is very much like code - perfect when you cannot take anything away [02:24:44] <DonDiego> also, you could end sentences in periods. [02:25:04] <DonDiego> umm [02:25:06] <DonDiego> geez [02:25:11] <DonDiego> sorry [02:25:38] <DonDiego> i pasted your log message into my editor without the first line [02:25:50] <DonDiego> Yuvi: forget everything i said [02:26:09] <DonDiego> it's 4:30am here and my eyes are falling shut.. [02:26:20] <Yuvi> heh, no worries [02:26:27] <Yuvi> I could be more consistent with using periods [02:27:14] <DonDiego> if in doubt, follow the rules of proper english [02:28:37] <CIA-93> ffmpeg: diego * r23283 /branches/ (0.6 0.6/libavutil/rational.c): [02:28:37] <CIA-93> ffmpeg: Convert NaN to 0/0 in av_d2q [02:28:37] <CIA-93> ffmpeg: This fixes aspect ratio calculation for encoding from files with 0/0 stored, [02:28:37] <CIA-93> ffmpeg: common with ogg/theora [02:28:37] <CIA-93> ffmpeg: backport r23280 by conrad [02:36:55] <Yuvi> mkvalidator spews errors for all of the mkvtoolnix files I've tried, hmmm [06:46:26] <wbs> morning [06:51:06] <bcoudurier> morning [07:21:44] <_av500_> morning [07:27:50] <KotH> salve [08:59:12] <CIA-93> ffmpeg: conrad * r23284 /trunk/ (3 files in 3 dirs): [08:59:12] <CIA-93> ffmpeg: matroskaenc: Write codec time base as default duration for video tracks. [08:59:12] <CIA-93> ffmpeg: This isn't exactly semantically equivalent, but the field has already been [08:59:12] <CIA-93> ffmpeg: long abused to mean this, and writing it helps in determining a decent cfr [08:59:12] <CIA-93> ffmpeg: time base when transcoding from a mkv where the video codec stores none (VP8). [10:12:11] <CIA-93> ffmpeg: cehoyos * r23285 /trunk/libavcodec/audioconvert.h: [10:12:11] <CIA-93> ffmpeg: Fix documentation of av_audio_convert. [10:12:11] <CIA-93> ffmpeg: Patch by Cyril Russo, stage D nexvision A laposte net [10:59:38] <dezodorant> why probing doesn`t skip id3? [11:00:22] <Evgeny> hi! when i added new protocol i add new field in Makefile. Field like this OBJS-$(CONFIG_RTSPHTTP_PROTOCOL). should i add something somewhere else? [11:00:25] <Evgeny> thanks! [11:00:31] <dezodorant> i mean not excluded from probing_size ? [11:01:42] <jai> dezodorant: ? [11:01:58] <jai> its skipped properly [11:02:05] <dezodorant> id3 tag with album art may be as big as probing size [11:02:27] <jai> so [11:02:28] <jai> ? [11:02:34] <dezodorant> one moment [11:03:00] <dezodorant> http://pastebin.org/273986 [11:03:20] <dezodorant> and with stripped tags [11:03:38] <dezodorant> http://pastebin.org/273992 [11:08:13] <dezodorant> probably id3 tag should be excluded from probing procedure ? or not ? [11:13:12] <dezodorant> jai: what do you think about it ? [11:16:11] <jai> dezodorant: please paste the entire output from ffmpeg -loglevel debug -i <file> [11:17:53] <dezodorant> 1st http://pastebin.org/274032 original [11:17:53] <dezodorant> 2nd http://pastebin.org/274033 stripped [11:37:24] <lu_zero> wbs: poing [11:37:33] <wbs> lu_zero: pong [11:43:57] <lu_zero> wbs: could you give me a tutorial on dss? [11:44:16] <wbs> sure [11:44:29] <lu_zero> I wanted to compare the behavior between feng and dss on certain kind of loads [11:46:40] <wbs> sure... what part do you want a tutorial of? setting it up? [11:46:49] <lu_zero> basically [11:47:12] <lu_zero> which is the file to edit in order to get it to listen to 0.0.0.0 [11:47:29] <wbs> I think it listens on all interfaces by default [11:51:50] <lu_zero> nope [11:51:59] <lu_zero> it listen to localhost and only that [11:54:39] <wbs> hmmm, netstat -l -p on one machine reports that it listens on *:rtsp [11:55:28] <wbs> lu_zero: check /etc/streaming/streamingserver.xml, look for bind_ip_addr [11:55:34] <wbs> it's set to simply "0" in my case [11:59:19] <DonDiego> Yuvi: you around? [11:59:52] <lu_zero> wbs: the dss is up on lscube.org [12:00:03] <lu_zero> it has the usual sample files there [12:00:30] <mru> lu_zero: are you coming to linuxtag? [12:00:41] <lu_zero> I'm hoping to [12:00:48] <mru> then why haven't you said so? [12:00:48] <DonDiego> Yuvi: http://samples.mplayerhq.hu/V-codecs/Theora/theora_testsuite/320x240.skelet… [12:01:04] <DonDiego> Yuvi: this sample spouts a lot of warnings about [12:01:08] <mru> you can't expect me to guess who might be coming [12:01:10] <DonDiego> [ogg @ 0x8b38400]Page at 252669 is missing granule [12:01:28] <lu_zero> because it's not 100% sure yet =| [12:01:45] <mru> you could still say that [12:01:56] <mru> this is not just you [12:02:00] <mru> it's everybody [12:02:07] <lu_zero> sorry =\ [12:02:38] <mru> so far only janneg has committed to help with booth setup [12:02:42] <mru> I find that disappointing [12:03:35] <lu_zero> If I manage to be there I should be available to help, the problem is that I'm not sure I'll be there yet ^^; [12:04:26] <DonDiego> http://samples.mplayerhq.hu/V-codecs/Theora/theora_testsuite/ducks_take_off… [12:04:29] <DonDiego> *** glibc detected *** ./ffplay: munmap_chunk(): invalid pointer: 0xb460a020 *** [12:04:32] <DonDiego> ouch [12:04:38] <mru> valgrind it [12:05:18] <DonDiego> can somebody reproduce? [12:05:32] <DonDiego> i've never used valgrind before, quick pointers? [12:07:26] <siretart> wow. ffmpeg ACCEPTED for debian. [12:07:33] <siretart> experimental, that is [12:07:54] <KotH> \o/ [12:08:04] <DonDiego> elaborate.. [12:08:18] <KotH> DonDiego: there is a tutorial in the documentation, iirc [12:09:03] <mru> DonDiego: seriously? [12:09:10] <mru> what rock do you live under? [12:09:21] <mru> hint: valgrind program args... [12:09:41] <jai> valgrind --leak-check=full <ffmpeg command line> is a start [12:10:58] <hyc> for a crash like this you don't need leak checking [12:11:52] <lu_zero> valgrind --db-attach=yes might also be useful [12:12:04] <DonDiego> vex x86->IR: unhandled instruction bytes: 0xF 0xE 0x90 0xE9 0B f=0/0 [12:12:04] <DonDiego> ==13182== valgrind: Unrecognised instruction at address 0x8498DBD. [12:12:07] <DonDiego> bah [12:12:18] <DonDiego> valgrind sigill? [12:12:19] <mru> old valgrind? [12:12:38] <DonDiego> valgrind-3.3.1-Debian [12:12:57] <lu_zero> my ffmpeg doesn't crash [12:13:17] <hyc> 3.3.1 is pretty ancient [12:13:18] <mru> DonDiego: never use debian versions of anything that matters [12:13:45] <DonDiego> i usually cannot be bothered to use non-distro versions of most stuff [12:13:48] <mru> debian, the best in museum-grade software [12:13:58] <mru> so use a real distro [12:14:14] <DonDiego> i *like* museum-grade software [12:14:28] <DonDiego> do you usually worry what ls and groff you are using? [12:14:39] <jai> hyc: yeah, i didnt see the backlog [12:14:54] <mru> DonDiego: you'd be surprised [12:15:08] <lu_zero> groff, yes [12:15:11] <lu_zero> ls no [12:15:13] <mru> I always feel crippled when forced to use debian machines [12:15:37] <hyc> they're not as bad as rhel, but I agree [12:16:59] <lu_zero> hyc: my most unsettling experience was with centos [12:17:13] <lu_zero> broken apr while developing a module for apache [12:17:13] <BastyCDGS> mru, what's the problem with debian? [12:17:18] <siretart> DonDiego: valgrind is effectively a virtual machine that translates x86 opcodes to a special bytecode that allows sophisticated analysis [12:17:27] <mru> BastyCDGS: as I said, museum-grade [12:17:35] <lu_zero> worked perfectly on our systems and not on the production ones... [12:17:51] <siretart> DonDiego: maybe older versions of valgrind have problems with special amd k6 opcodes? [12:17:54] <lu_zero> apr_stat was broken ... [12:18:00] <mru> siretart: yes, they did [12:18:09] <mru> 3dnow stuff was added rather late [12:18:25] <DonDiego> i'll see if i can be bothered to upgrade [12:18:50] <DonDiego> mmu_screen: nice to see your beos patches coming along so well! [12:19:26] <BastyCDGS> dondiego give ubuntu 10.04 a try, it's based on debian [12:19:49] <siretart> DonDiego: or try a copy of ffmpeg without k6 3dnow opcodes for your copy of valgrind [12:19:54] <DonDiego> if i cannot be bothered to install new versions of dev tools, do you think i can be bothered to switch distros? [12:20:01] <siretart> or use a chroot with newer dev tools [12:20:03] <lu_zero> that might be the faster route [12:20:19] <DonDiego> i'm forced to use 10.4 at work - horrible.. [12:20:22] <lu_zero> DonDiego: gentoo-prefix works on debian, not just macosx =P [12:20:35] <mru> DonDiego: if you cannot be bothered to install usable tools, why do you call yourself a developer? [12:20:44] <DonDiego> i don't [12:21:06] <DonDiego> nobody else calls me a dev after all [12:22:32] <BastyCDGS> dondiego, then try 8.04 that's what I'm working with, too right now and it works without problems for me with ffmpeg [12:22:47] <DonDiego> i must be speaking chinese [12:23:19] <lu_zero> BastyCDGS: he loves _his_ debian [12:23:22] <DonDiego> me no change distro in 5+ years past [12:23:28] <DonDiego> me no change distro in 50+ years future [12:23:50] <DonDiego> lu_zero: no, i love spending my time on something else [12:24:08] <lu_zero> DonDiego: you might just update debian [12:24:09] <BastyCDGS> well if you not want to change distro, try building valgrind etc. from git? [12:24:13] <lu_zero> 3.5.0 is there [12:24:16] <BastyCDGS> or add a backport repository [12:24:23] <DonDiego> i track stable releases [12:24:56] <DonDiego> i tried getting bazaar from backports, that did not work so well.. [12:26:09] <BastyCDGS> maybe you can get the source from your debian's valgrind version and add the 3dnow patch manually there and recompile? [12:27:14] <ramiro> maybe someone can give him ssh access somewhere where this is all taken care of? [12:27:33] <DonDiego> i'm sure you guys all mean well and it's appreciated and all [12:27:34] <BastyCDGS> I can give you one and mru probably as well [12:27:59] * BastyCDGS got one ssh from mru for testing on big endian [12:28:00] <DonDiego> but really the day has a short few 24h only and i should be spending them on something else.. [12:28:28] <lu_zero> anyway [12:28:37] <lu_zero> the sample doesn't trigger anything here [12:28:41] <lu_zero> it's just black [12:28:52] <DonDiego> it should show some ducks in a ond [12:28:54] <DonDiego> pong [12:28:55] <DonDiego> pond [12:28:58] <lu_zero> I should probably rebuild my ffmpeg and check with the tip [12:31:02] <DonDiego> bye [12:31:04] <Vitor1001> DonDiego: Valgrind works fine installed localed as non-root. [12:31:35] <mru> don't you guys get it? he _wants_ the petrified version [12:32:31] <BastyCDGS> dondiego, what's wrong with doing this via ssh? [12:32:35] <DonDiego> i like vintage software to go along with my vintage hardware [12:32:44] <mru> ffplay doesn't run so well over ssh [12:33:01] <CIA-93> ffmpeg: cehoyos * r23286 /trunk/libavformat/mpeg.c: [12:33:02] <CIA-93> ffmpeg: Skip pes payload during probing to avoid start code emulation. [12:33:02] <CIA-93> ffmpeg: Patch by Janne Grunau, janne-ffmpeg jannau net [12:33:08] <DonDiego> BastyCDGS: that a) i cannot be bothered b) it likely will not work c) i don't have time [12:34:16] <BastyCDGS> well if you don't have time it's probably the best to just turn off 3dnow with ffmpeg's configure so your valgrind won't crash anymore [12:34:31] <BastyCDGS> at least until you have some time to adress that issue [12:37:49] <ramiro> Vitor1001: hey, I have a question regarding the theory behind the fir filter in mlp, and you seem to know this stuff quite well. [12:37:50] <Vitor1001> mru: The way I get it, is that he doesn't like modifing his distro. I don't like it either, that's why 99% of the time I use "valgrind ffmpeg_g" and in 1% I do "~/ffmpeg/valgrind-svn/vg-in-place ffmpeg_g" [12:38:16] <mru> and I run gentoo [12:38:30] <Vitor1001> ramiro: You can try, but I never took the time to really read the theory of that [12:38:39] <Vitor1001> I don't think I can be of very big help [12:38:43] <BastyCDGS> gentoo is a distro I'ld like to test, too. [12:39:02] <mru> it doesn't work on amiga [12:39:31] <BastyCDGS> linux works on amiga if you have a 68k with MMU [12:39:36] <BastyCDGS> but I wasn't talking of amiga ;) [12:39:43] <lu_zero> mru: I wonder if somebody didn't do [12:39:50] <lu_zero> we have a 68k port... [12:39:51] <ramiro> Vitor1001: the fir does something like y[n] = y[n-1] * coeff[1] + y[n-2] * coeff[2] ... + y[n-m] * coeff[m] + x[n]. my teacher says that, theoretically, to be classified as a FIR, it should only use x[n-<something>], and not y[n-<something>] [12:40:16] <ramiro> by using y[n-<something>], it is an IIR [12:40:16] <mru> lu_zero: building a distro on a ~50MHz 68k doesn't sound like much fun [12:41:06] <lu_zero> mru: crossdev and cross-emerge are a boon ^^; [12:41:15] <Vitor1001> ramiro: I remember having stumbled upon that once [12:41:30] <BastyCDGS> mru, it really won't be fun ;) [12:41:39] <lu_zero> tested with the curreng ffmpeg btw [12:41:42] <BastyCDGS> I never used linux on amiga, though [12:41:48] <lu_zero> no double free nor crash [12:42:13] <Vitor1001> ramiro: just a min [12:43:46] <BastyCDGS> http://linuxonamiga.org/ [12:46:14] <Vitor1001> ramiro: All this make me think about the thread: "[PATCH] allow different input/output buffers for DC filter" [12:46:26] <Vitor1001> But I'm not 100% sure it is related [12:46:42] <janneg> DonDiego: not reproduceable with branches/0.6 r23283 on core2 [12:47:47] <merbzt1> I might be able to test on a geode [12:47:57] <BastyCDGS> http://aminet.net/package/gfx/conv/ffmpeg-svnr22669-m68k.lha [12:48:01] <merbzt1> should match what diego has [12:48:46] <ramiro> Vitor1001: thanks, I'll check [12:49:16] <Vitor1001> ramiro: If it is indeed related, don't forget asking Ronald how he didn't needed it after all. [12:49:28] <janneg> does the k6 have mmx? I can test on phenom with sse* disabled [12:50:02] <DonDiego> yes, it has mmx, 3dnow and 3dnowext (it's a k6-3+ [12:50:04] <DonDiego> ) [12:50:32] <pross-au> u have a III+, nice [12:55:58] <ramiro> Vitor1001: hm, I don't think so. I'll ask ronald later, but he's said in the past that he doesn't quite understand the theory... [12:56:21] <superdump> ramiro: i'm pretty sure what you said above is correct [12:57:01] <ramiro> superdump: so mlp uses incorrect names? [12:57:16] <superdump> http://rob.opendot.cl/index.php/2007/09/05/filtering-out-the-crap/ [12:57:20] <superdump> i wrote that from wikipedia [12:57:24] <superdump> basically [12:57:44] <lu_zero> wbs: is the dss on lscube.org reachable for you? [12:58:32] <wbs> lu_zero: yeah, it seems to work just fine, I played a sample from there a few minutes ago [12:58:46] <lu_zero> uhmm [12:59:09] <lu_zero> which one? [12:59:36] <wbs> sample_50kbit.3gp [13:00:05] <superdump> ramiro: if mlp uses >1 output coefficients then it's using an iir i think [13:00:11] * lu_zero wonders why the h264_100kbit didn't work [13:01:07] <superdump> ramiro: actually, i see what you typed now. what are the x[] and y[] arrays precisely? [13:01:47] <ramiro> superdump: it has one thing it calls the fir filters (which is the one I said above), and another one it calls the iir filter, which I'm not sure why but it does some weird & mask with the msb from the result of the sum. [13:01:49] <superdump> it looks like you're using y[] as your input samples and x[] as your output [13:02:13] <wbs> lu_zero: it seems to work just fine for me, but the .mov versions don't work with ffmpeg, only the .mp4 ones [13:02:13] <superdump> and only one x[] is used, the x[n-0] [13:02:20] <superdump> so it does indeed look like an fir [13:02:36] <janneg> DonDiego: are you sure about 3dnow ext? ggc manual mentions it only for athlon [13:02:42] <lu_zero> ok [13:02:49] <DonDiego> janneg: yes [13:02:51] <ramiro> superdump: x[n] are the residuals read from the bitstream, y[n] are the output samples, and the input to the coeffs to the next y[n+1] [13:03:00] <ramiro> for iir it's different [13:03:35] <DonDiego> janneg: gcc manual is wrong, new gccs also put mmx2 in my binaries with -march=native and then i get sigill [13:04:18] <ramiro> superdump: hm, so it's an fir if it's interpreted the other way around, as in x[n] = y[n] - y[n-1] * coeff[1] ... [13:04:54] <ramiro> I'm not sure if that makes sense. anyways I have to go to class now, I'll read more on this later [13:06:24] <superdump> mmm, i see what you mean [13:06:25] <janneg> ./configure --enable-gpl --cpu=k6-3 --disable-sse --disable-ssse3 works fine, but still generates 64bit code. can't build 32bit since the system doesn't have 32bit libs [13:06:39] <superdump> it uses one input value and multiple output values [13:06:48] <superdump> so it's like an opposite of the fir [13:08:27] <merbzt1> fir the output is just based on the input and fixed coeffs [13:08:52] <merbzt1> iir the output is based on the input, fixed coeffs and the previous output [13:09:57] <mru> which is pretty obvious [13:10:20] <mru> if output only depends on input, the output of an impulse will eventually die out [13:10:36] <mru> hence finite impulse response [13:10:56] <mru> if old output values also contribute, the impulse response can keep itself going indefinitely [13:11:13] <superdump> so it's an iir [13:12:43] <merbzt1> mru ftw [13:13:04] <mru> what's an ftw filter? [13:13:13] <merbzt1> even though he needs a hug from time to time ;) [13:13:19] <merbzt1> for the win [13:13:32] <merbzt1> not related to filtering [13:13:33] <mru> I know what ftw means [13:13:52] <merbzt1> good for you [13:14:15] <superdump> forward thinking wins [13:14:44] <mru> not finite transform window? [13:15:27] <merbzt1> well there are many types of filers [13:15:45] <merbzt1> some could be named ftw filter [13:15:52] <merbzt1> if not we could invent one [13:17:26] <merbzt1> 1 hit in google [13:17:47] <merbzt1> from 83 [13:17:57] <merbzt1> guess it's not that much used [13:18:18] <merbzt1> ie we can invent something and use it [13:18:27] <Tjoppen> odd. get_buffer() fails on EOF (EPIPE) on file protocol even though I check url_feof() before reading. ftell() reveals it is actually at EOF [13:19:43] <mru> we'll also need the inverse, the wtf filter [13:20:00] <merbzt1> \o/ [13:20:30] <mru> btw merbzt1, do you know yet if you'll make it to linuxtag? [13:20:40] <merbzt1> nope :/ not yet [13:20:48] <merbzt1> pending [13:22:13] <mru> let me know if I should send my team of persuaders somewhere [13:24:15] <Tjoppen> ah, it relies on figuring out get_buffer() returned <= 0 the previous call. fair enough I guess [13:36:23] <dezodorant> jai: u here? [13:52:47] <DonDiego> Yuvi: your assistance required [13:53:04] <DonDiego> gregory maxwell has thrown the gauntlet.. [13:53:09] <mru> link? [13:53:20] <DonDiego> http://people.xiph.org/~greg/cb/cb_60_ffmpeg.png [13:54:25] <mru> and what's that supposed to be? [13:54:29] <thresh> looks like 'life' game [13:56:37] <DonDiego> http://people.xiph.org/~greg/cb/controlled-60.ogv [13:56:47] <DonDiego> ffplay doing this sample [13:57:08] <DonDiego> i get a crash again.. [13:57:19] <DonDiego> maybe i shall have to update valgrind after all.. [13:57:23] <DonDiego> can anybody reproduce? [14:00:39] <DonDiego> http://samples.ffmpeg.org/V-codecs/Theora/controlled-60.ogv [14:00:48] <DonDiego> i put the sample in the usual spot [14:01:03] <mru> what's gregory claiming this time? [14:01:22] <DonDiego> that libtheora is faster than fftheora.. [14:01:34] <mru> how did he measure? [14:01:48] <mru> bet he included some expensive colourspace conversion for ff but not lib [14:02:06] <kshishkov> mru: measure? You posted that link to Dilbert strip - "pull numbers out of your..." [14:02:27] <DonDiego> http://myrandomnode.dyndns.org:8080/~gmaxwell/theora/implementations.png [14:02:29] <DonDiego> http://myrandomnode.dyndns.org:8080/~gmaxwell/theora/implementations2.png [14:03:40] <mru> hardare? configure flags? [14:03:46] <mru> that's not very specific [14:04:17] <DonDiego> http://people.xiph.org/~greg/cb/ [14:04:26] <DonDiego> shall i forward you the mail? [14:04:31] <janneg> strange spike for libtheora at 2600kbps [14:04:54] <mru> DonDiego: is he harassing you in private mail? [14:05:07] <DonDiego> no, foms list [14:05:19] <DonDiego> r [14:06:44] <DonDiego> they complain about the vorbis encoder as well [14:06:52] <DonDiego> rightly so [14:07:07] <DonDiego> i guess we could just disable it on the release branch [14:07:59] <wbs> DonDiego: there's a patch in discussion that would prefer external libraries over knowingly experimental encoders, if that one's accepted I guess it's more conforming just to pick that one [14:08:19] <janneg> or wait for my experimental codec caps being committed [14:08:28] <wbs> that's the one I meant [14:09:16] * janneg still has to finish the fix for ffmpeg -acodec vorbis [14:10:05] <Compn> DonDiego : btw i meant to check ogg vorbis and oggds/ogm files with -demuxer lavf , not just theora :) [14:10:48] <DonDiego> go for it :) [14:11:09] <DonDiego> i'm fine with any solution [14:11:23] <DonDiego> but the vorbis encoder has been a sticking point for too long [14:11:32] <BBB> does anyone oppose if we commit the vp8 libvpx-based decoder while we work on our internal one? [14:12:11] <Compn> BBB : no, its useful to have reference to test internal one [14:12:12] <mru> only if the patch is clean [14:12:21] <BBB> clean the patch [14:13:11] <BastyCDGS> hi BBB :) [14:13:30] <BastyCDGS> nice to see you, quite a long time since our last meeting ;) [14:13:40] <BBB> you had exams, I had a meeting, I guess ;) [14:13:44] * BBB was off for a few days also [14:13:56] <BastyCDGS> yes exactly [14:13:58] <merbzt1> where is my student .... [14:15:55] <BBB> ah, gsoc starts today? [14:15:57] <BBB> where is my student [14:16:12] <BBB> I guess he did quite well in his qualification already [14:16:17] <Compn> shouldnt you guys have schedules in place already? :P [14:16:26] <BBB> my schedule is simple: finish asap [14:16:28] <Compn> like be on irc from x-y each day [14:16:29] <Compn> :P [14:16:43] <kshishkov> where is my WVP2 decoder? [14:16:45] <mru> be on irc 0-24 [14:16:58] <BastyCDGS> yes GSoC starts today, that's why I did upload the UAE stuff yesterday to upload.ffmpeg.org for testing tucomposer and also posted a mail for MOD implentation ;) [14:16:59] <BBB> kshishkov: vp8 is more important imo [14:17:01] <Compn> kshishkov : did you work on indeo at all ? [14:17:09] <BBB> hey ai [14:17:11] <BBB> oops [14:17:11] <BastyCDGS> hi jai [14:17:12] <BBB> jai [14:17:15] <Compn> michael wants comments from indeo devels, but i dont remember who works on that file [14:17:32] <kshishkov> Compn: I've sent the reply to that [14:17:42] <Compn> oh good :) [14:17:42] <jai> ohai BBB, BastyCDGS [14:17:47] <Compn> indeo3 > alan smithee [14:17:48] <Compn> hmmmmm [14:18:06] <kshishkov> he's on Wikipedia [14:18:19] <kshishkov> quite a famous guy in Hollywood [14:18:50] <Compn> yes i saw his movie 'burn hollywood burn' [14:20:33] <BastyCDGS> BBB just read and replied to the IFF patch [14:20:38] <CIA-93> ffmpeg: jai_menon * r23287 /trunk/ffplay.c: FFplay : Implement custom reget_buffer for the input filter. [14:20:41] <BastyCDGS> should I really change this? [14:21:01] <BBB> I'll look later, I can't help much yet [14:21:21] <BastyCDGS> btw, I just found another solution: make it uint8_t as you said buf do a if ((int) value >= 0) [14:21:42] <BBB> we're trying to get rid of ugly casts [14:21:46] <BBB> not add them :) [14:23:18] <dezodorant> jai: so back to probing: is it right behavior or not ? [14:23:40] <DonDiego> http://samples.ffmpeg.org/V-codecs/Theora/controlled-60.ogv [14:23:49] <DonDiego> can somebody quickly run this through ffplay? [14:24:21] * Compn downloads latest ffplay [14:25:00] <BastyCDGS> BBB, I will change it only if you really want me to do this [14:25:16] <hyc> I got a single image [14:25:23] <hyc> DonDiego: what is the expected output? [14:26:39] <kierank> hehe ffmpeg can't handle an sps_id of 31 it seems [14:27:11] <BBB> BastyCDGS: I will check later today [14:27:30] <jai> dezodorant: do you have a sample i could look at? [14:27:39] <dezodorant> yes [14:27:46] <BastyCDGS> BBB, if you haven't noticed yet, I just fixed the enabled-avfilter crash with IFF decoder ;) [14:28:05] <jai> dezodorant: please upload to incoming [14:29:57] <dezodorant> mb http://myau.su/29cec1bf-59f5-11df-9ebd-000423b32792 fine too ? [14:30:54] <janneg> dezodorant: plays fine [14:30:59] <janneg> DonDiego: ^^^ [14:31:06] <DonDiego> hmm [14:31:08] <DonDiego> cpu? [14:31:16] <DonDiego> trunk or release? [14:31:29] <janneg> hyc: video of a controlled burning of a wodden house [14:31:35] <janneg> trunk [14:31:55] <hyc> janneg: yeah, after I downloaded it completely it played [14:31:59] <DonDiego> revision? [14:32:03] <hyc> it didn't stop by itself though, at the end of the video [14:32:12] <janneg> DonDiego: core2 and 0.6 plays it fine too [14:32:15] <hyc> before I just tried to play it off the URL [14:32:32] <hyc> I'm on -r23210 [14:32:32] <janneg> r23286 [14:32:45] <DonDiego> hyc: ffplay does not exit [14:32:47] <jai> dezodorant: ok, thx [14:33:01] <hyc> DonDiego: right, didn't exit [14:33:16] <dezodorant> probably i need a little bit more help [14:33:24] <dezodorant> https://roundup.ffmpeg.org/issue1954 [14:33:40] <dezodorant> i need direction where to serach [14:37:01] <elenril> dezodorant: use git bisect? [14:38:08] <dezodorant> it`s in avformat or avcodec ? [14:38:17] <dezodorant> probing in format [14:38:35] <jai> per container probe functions are in lavf [14:38:37] <elenril> probing is done in lavf [14:39:06] <elenril> it's a read_probe function in AVInputFormat struct [14:39:15] <janneg> DonDiego: that's by design, use -autoexit [14:39:21] <dezodorant> and how about packet parsing ? [14:42:05] <dezodorant> as far as i can see mp3 packet parsing in avcodec but i cannot find where we deciding to use packet or discard [14:51:46] <kierank> so...anybody interested in fixing get_ue_golomb_31 ? ;) [14:53:54] <lu_zero> wbs: could you please test run_a_lot_of_clients (in feng contrib) agains your dss setup and against a feng with the same content? [14:54:15] <lu_zero> some numbers might be 100 10 or 10 100 [14:54:55] <lu_zero> (remember to issue a killall ffmpeg after since I still forgot to cleanup properly =p) [15:05:05] <mru> kierank: what's the problem with it? [15:06:11] <kierank> it's broken. It causes files with an sps_id of 31 to not decode. [15:06:31] <kierank> when you replace it with the normal get_ue_golomb everything works normally [15:06:53] <kierank> this bug: http://roundup.ffmpeg.org/issue1930 [15:10:37] <DonDiego> bye [15:46:50] <jai> dezodorant: btw, for now you can use a bigger probesize to workaround the problem [15:47:36] <dezodorant> i`m stripping tags as a workaround) anyway i`m filling them from db [15:47:49] <jai> you dont need to do that [15:48:19] <jai> in your script/whatever just add a -probesize 10000000 [15:48:25] <jai> before -i [15:48:40] <dezodorant> it`s handmade app [15:49:18] <jai> i'd be interested in knowing why this is a regression though [15:52:20] <janneg> jai: several probing functions got stricter last year [15:55:03] <dezodorant> jai: i haven`t found any specs about mp3 packets, so maybe it`s not a regression. [15:58:25] <ramiro> superdump, merbzt1: so both filters in mlp (what it calls fir and iir) are actually iir? [15:59:01] <BBB> fir is inverse iir [15:59:02] <BBB> basically [15:59:10] <mru> iir has feedback, fir doesn't [16:00:42] <ramiro> take a look at the code in lavc/mlpdsp.c, both use result to update their buffers [16:00:45] <jai> janneg: yes, but that wouldn't lead to this [16:01:43] <jai> dezodorant: the problem here is just that the second id3 tag is too big [16:01:46] <ramiro> iir ends up being residual - accum&~mask, I have no idea why that is. (the lsb from mask being subtracted) [16:02:06] <dezodorant> jai: i`m talking about other issue [16:02:13] <dezodorant> https://roundup.ffmpeg.org/issue1954 [16:02:17] <dezodorant> this one [16:02:22] <BBB> ramiro: look at celp_zero_synthesis_filter and celp_synthesis_filter [16:02:28] <jai> dezodorant: you are skotopes? [16:02:31] <BBB> ramiro: most likely iir is synthesis ad fir is zero [16:02:32] <dezodorant> yes [16:02:42] <jai> dezodorant: oh, i remember you around here :) [16:03:00] <dezodorant> my nick is catched by someone else [16:03:11] <dezodorant> so i got new name ;( [16:03:14] <ramiro> msg nickserv ghost? [16:03:20] <jai> dezodorant: heh, you should've /register'd [16:04:45] <dezodorant> now i am [16:04:57] <ramiro> dezodorant: skotopes last seen 36 weeks ago. ask a freenode admin to unregister that guy and take his place [16:05:03] <ramiro> that's how I got my nick =) [16:05:15] <mru> ramiro: I thought it was your name [16:05:21] <ramiro> lol [16:05:23] <BastyCDGS> one question, what's wrong with this patch from ami_stuff? [16:05:24] <BastyCDGS> http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/2009-August/073638.html [16:05:38] <ramiro> mru: apparently I'm not the only ramiro on freenode [16:05:39] <mru> it's from ami_stuff [16:05:43] <mru> that's usually a bad sign [16:06:10] <BastyCDGS> why? what's wrong with him? [16:06:20] <mru> his patches are usually no good [16:06:32] <dezodorant> ramiro: i`m like all other sysadmins is a little bit lasy for this [16:06:55] <ramiro> dezodorant: it takes 5 minutes... [16:07:37] <BastyCDGS> I just noticed that he does a #define MULH MULH what's the sense of this? [16:08:04] <mru> the real problem is that his patches are untested and untestable [16:08:40] <BastyCDGS> I can test them but reading his asm code shows me that his MUL64 isn't optimal [16:08:48] <mru> I expected as much [16:09:06] <mru> how would you test though? [16:09:06] <BastyCDGS> I did one MUL64 for TuComposer which is less half of the size [16:09:15] <BastyCDGS> UAE ;) [16:09:28] <mru> no gcc version is able to build ffmpeg for m68k [16:09:47] <mru> I tried all that would even build themselves once [16:09:51] <mru> half failed to build [16:09:52] <BastyCDGS> the latest ffmpeg for m68k is built with gcc-4.5 [16:09:54] <mru> the rest failed on ffmpeg [16:09:58] <BastyCDGS> as published on aminet [16:10:24] <BastyCDGS> but he changed some stuff in the original FFmpeg code [16:10:32] <mru> besides, we don't care about emulators [16:11:15] <BastyCDGS> btw, I meant this one (it's not a direct download link): [16:11:16] <BastyCDGS> http://aminet.net/package/gfx/conv/ffmpeg-svnr22669-m68k.lha [16:11:27] <BastyCDGS> it leads to an info page describing the package [16:12:42] <BastyCDGS> I also can test it on my native amiga if you wish [16:13:00] <BastyCDGS> but true amiga support is something I want to do after GSoC has finished [16:13:16] <mru> oh lord, have mercy [16:13:53] <kierank> lol [16:15:44] <BastyCDGS> mru, I see you're the greatest amiga fan I ever seen *gg* [16:22:35] <BastyCDGS> mru, ami_stuff should at least use a function pointer which sets to correct MULU64 if it's a 68060 or not [16:22:56] <mru> no function pointers there [16:23:23] <BastyCDGS> I mean such stuff like you do with x86 optimizations, pointer which uses either 3dnow, mmx, sse2, sse3 etc. [16:23:39] <mru> the mul64 and related functions must be inlined [16:23:52] <BastyCDGS> oh ok then it's a bad idea [16:24:20] <BastyCDGS> then he should do sth. #if ARCH_MC68060 or sth. like that [16:24:50] <mru> why did they remove the 64-bit multiply in 68060? [16:25:24] <BastyCDGS> that was a decision I understand as much as you probably do => null [16:25:35] <BastyCDGS> maybe the circuit designer had drunk to much beer? [16:26:23] <BastyCDGS> it's not only 64-bit multiply but also 64/32->32 division [16:26:36] <mru> division is much less important [16:37:07] <BastyCDGS> yes of course just wanted to mention this for sake of completeness [16:43:06] <CIA-93> ffmpeg: jai_menon * r23288 /trunk/libavformat/utils.c: [16:43:06] <CIA-93> ffmpeg: Display a more descriptive log message when probe buffer limit is [16:43:06] <CIA-93> ffmpeg: reached. [16:56:05] <BBB> andoma, mru: if you care, please reply to BastyCDGS's mailinglist thread about mod support [16:56:14] <BBB> some comments would be appreciated ;) [16:56:16] <hyc> they removed instructions whenever profiling commercial apps showed they were unused [16:57:06] <hyc> and presumably they needed to simplify something else [17:00:10] <_av500_> ############################################################ [17:01:57] * _av500_ wrestles netbook from little son's hands [17:03:50] <Vitor1001> BastyCDGS: Just a question about TUComposer (yes, I'm too lazy to read the source): [17:03:51] <hyc> oh, I thought you were just providing comments... [17:04:47] <Vitor1001> does it converts all the possible formats to some internal format that it them tries to actually convert to raw audio or every "decoder" does it on its own? [17:05:53] <BastyCDGS> viktor, yes it converts them to an interal format and then always playbacks this internal format to raw audio [17:06:46] <Vitor1001> Hmmm, have you considered adding a new AVMediaType? [17:07:19] <Vitor1001> I mean, we don't have a libavcodec_video and a libavcodec_audio, so I wonder why sampling formats should have its own. [17:07:43] <Vitor1001> ITOH, maybe putting the code than converts the internal format to raw audio might fit in libavsomething... [17:09:27] <BastyCDGS> the internal format is also used for stuff like pattern display etc. [17:09:43] <BastyCDGS> but AVMediaType sounds interesting too. [17:11:52] <Vitor1001> Doing a pattern display in libavcompose look a good idea too. [17:12:28] <Vitor1001> What will be a PITA is that changing the fields of the internal format will break the API [17:12:34] <BastyCDGS> do you know OpenCubicPlayer? [17:12:57] <Vitor1001> How much typically the internal format changes when adding support for a new format? [17:13:15] <Vitor1001> I know practically nothing about sampling formats :( [17:13:24] <Vitor1001> I just read your msg ;) [17:14:05] <BastyCDGS> it won't be much anymore and it can be added with backward compatibility, I have a reserved field for this which is set to 0 [17:14:18] <BastyCDGS> so if we add new features the code simply checks if that's non 0 and uses it [17:14:20] <Vitor1001> brb [17:26:07] <jai> i used to use ocp on dos [17:26:51] <_av500_> BastyCDGS: do we really expect new tracker formats? [17:27:18] <BastyCDGS> jai, cp has a really nice output, right? [17:27:44] <BastyCDGS> av500, more likely than not [17:28:38] <jai> BastyCDGS: yep [17:29:01] <jai> hmm, i think ryg used to work on ocp [17:29:21] <jai> kb too [17:29:30] <BastyCDGS> did you like CP 1.7 more than the newer 2.x for DOS too? [17:31:41] <jai> yeah, but bugfixes went to the 2.6 branch iirc so i switched [17:31:58] <BastyCDGS> wuerfel mode ;) [17:32:48] <jai> i dont even remember clearly, i think that was in early 98 or something [17:32:57] <jai> BastyCDGS: heh [17:33:30] <BastyCDGS> the animated dice with cp1.7 [17:41:03] <wbs> hyc: btw, tip of the day for easier review, when starting new threads, don't start them as replies to a previous thread by just changing the subject; my mail client groups those messages within the old thread [17:41:22] <wbs> hyc: (it took me quite a while to dig up the patch that you said shouldn't be controversial) [17:46:40] <hyc> wbs: hm, ok. I figured replying would keep everything in a single thread. [17:46:52] <hyc> and all of these patches are closely related [17:47:38] <wbs> hyc: yeah, but when there are numeruous patches, some applied and some not, at different places in the threads, it quickly gets hard to keep track of [17:47:58] <wbs> I'm looking at the cleanup patch now at least [17:48:06] <hyc> ok [17:48:51] <wbs> lu_zero: I'll try it in a while, ping me later if I haven't gotten back to you on it [17:50:18] <CIA-93> ffmpeg: reimar * r23289 /trunk/libavformat/ (md5enc.c Makefile allformats.c): Add -f framemd5 muxer similar to framecrc. [18:15:40] <Vitor1001> BastyCDGS: where is the TuComposer sourcecode? [18:16:04] <BastyCDGS> either grab the UAE files on upload.ffmpeg.org [18:16:06] <BastyCDGS> AMIGA subdir [18:16:35] <BastyCDGS> or from my site: http://forum.cdgs-crew.com/viewforum.php?f=11 [18:16:44] <Vitor1001> Amiga.7z? [18:16:55] <BastyCDGS> the whole sub dir [18:17:06] <BastyCDGS> WB39.7z, ROMS.7z and AMIGA.7z are essential [18:17:17] <Vitor1001> Ok, but the C files? [18:17:29] <BastyCDGS> are in WB39.7z or on the site [18:18:01] <hyc> wbs: does this reply make sense to you? https://lists.mplayerhq.hu/pipermail/ffmpeg-devel/2010-May/088962.html [18:18:10] <BastyCDGS> if you want to use UAE also get ffmpeg-.uaerc (for linux) or the FFmpegWinUAE.uae (WinUAE) [18:18:27] <BastyCDGS> you just have then to adjust the path stuff in the config files and can go on [18:18:49] <wbs> hyc: don't know h264 well enough to comment on that [18:19:10] <hyc> I tried to look at the mkv demux but didn't see anything relevant [18:23:54] <hyc> likewise in the mov demux [18:35:58] <Vitor1001> BastyCDGS: Does TuComposer decodes the whole file to a TuComposerTrackData before playing? [18:36:30] <BastyCDGS> To a TuComposerModule structure which contains the track data [18:36:42] <BastyCDGS> like I wrote yesterday evening on FFmpeg (the 7 points) [18:36:46] <Vitor1001> It is never too big? [18:37:03] <BastyCDGS> I tested with 2 KB mods up to 30 MB IT modules w/o problems [18:37:18] <mru> there's always a bigger input file [18:37:32] <BastyCDGS> I allocate memory dynamically there ;) [18:37:48] <mru> if I have 2GB of ram an the input file is 10GB? [18:37:59] <BastyCDGS> Out of Memory... [18:38:06] <mru> fail [18:38:07] <BastyCDGS> tucomposer checks mem allocation result for NULL [18:38:13] <mru> wow, impressive [18:39:01] <BastyCDGS> I made some thoughts of partially loading modules into memory [18:39:02] <Vitor1001> Now someone will find a way to create a 10GB MOD just to prove a point ;) [18:39:08] <BastyCDGS> but there's no implementation of it yet [18:39:21] <mru> Vitor1001: not necessary [18:39:22] <BastyCDGS> TCM files can't be larger than 4 GB [18:39:26] <mru> it only runs on amiga anyway [18:39:27] <BastyCDGS> like any IFF/RIFF file [18:39:30] <mru> and they don't have that much ram [18:39:36] <mru> 1GB should be more than enough to kill it [18:39:43] <Vitor1001> mru: Doesn't ffmpeg does more or less the same with images? [18:39:57] <Vitor1001> I mean, what if we feed it a 20GB image? [18:40:09] <mru> Vitor1001: well, it's a assumed you have enough memory to hold one frame [18:40:16] <mru> and reference frames when needed [18:40:28] <BastyCDGS> btw, standard protracker modules can't be even that big, there are 31 samples maximum with 64KB size of each [18:40:37] <mru> ffmpeg was never designed to work on single, insanely large images [18:40:38] <BastyCDGS> so 31*64 KB + pattern data (which is limitted to 255*1KB) [18:40:56] <mru> what if I want to make a file with a playtime of 10 years? [18:41:05] <BastyCDGS> using loop commands [18:41:13] <mru> without loops [18:41:25] <mru> suppose I connect it to the midi feed from my friend's studio [18:41:30] <BastyCDGS> set speed to 255 and bpm to 32 [18:41:39] <mru> no, no... I want full quality [18:41:43] <BastyCDGS> with TuComposer you can do it [18:41:49] <BastyCDGS> just not with the original MOD format [18:41:53] <mru> not if it keeps everything in ram [18:41:56] <BastyCDGS> IT/XM should be fine too [18:41:57] <mru> there is always a limit [18:42:46] <BastyCDGS> yes of course [18:43:05] <mru> unless you design it not to load everything into ram [18:43:21] <mru> loading all samples upfront is probably reasonable [18:43:32] <mru> but not the actual note data [18:43:42] <mru> that needs to be read and interpreted as you go [18:44:04] <BastyCDGS> samples are far bigger than note data so it would make more sense to load the samples from disc [18:44:08] <BastyCDGS> and keep the notes im RAM [18:44:17] <Vitor1001> I was thinking that if you go with the AVMediaType design, you can work in parallel with implementing the formats (and making commands like "ffmpeg -i my_song.s3m my_song.xm" work) and implementing the library that will be able to play it. [18:44:18] <mru> not if the note data is _really_ long [18:45:35] <mru> may I express my deep doubt over the success of such a project? [18:45:36] <BastyCDGS> one note per channel is usually 4-8 bytes long (1 byte: octave/note, 1 byte cmd byte, 1 byte data byte and 1 byte vol cmd byte) [18:45:52] <mru> multiply that by a few billion then [18:46:14] <BastyCDGS> let's say you have 64 channels [18:46:32] <BastyCDGS> 4*64 = 256 bytes per row [18:46:45] <mru> suppose for sake of argument one note = one byte [18:46:51] <mru> if your file has one note played per second [18:47:30] * elenril wonders if there's something like pulseaudio that doesn't suck [18:47:43] <mru> elenril: suck is the very definition of pulseaudio [18:47:51] <mru> so being like it without sucking is not possible [18:48:05] <BBB> I don't quite understand what's wrong with exposing it as a mod-codec as a default audio codec [18:48:09] <mru> anyway, you'd still reach a few GB after a few decades [18:48:32] <mru> and realistically you'd need much more memory per note [18:48:41] <mru> and notes are far more frequent [18:48:55] <elenril> mru: s/like pulseaudio/something with more features than alsa/ [18:49:06] <Vitor1001> BBB: You mean making outputting SAMPLE_FMT_COMPOSER? [18:49:07] * mru wants less features, not more [18:49:11] <BBB> Vitor1001: exactly! [18:49:23] <BastyCDGS> SAMPLE_FMT_COMPOSER sounds really neat :) [18:49:25] <BBB> Vitor1001: somehow you're way too bright [18:49:31] <Vitor1001> lol [18:49:32] <mru> composer is a bad name [18:49:37] <elenril> mru: alsa fails horribly at dynamic config [18:49:41] <BBB> SAMPLE_FMT_MOD is what I would call it [18:49:45] <mru> elenril: so configure it statically [18:49:46] <BBB> but you probably already understand what I mean [18:49:49] <elenril> i.e. an external soundcard [18:49:52] <BBB> it allows copying from one to another mod [18:49:57] <BBB> and allows decoding to wave [18:49:58] <BastyCDGS> what about SAMPLE_FMT_MULTICHANNEL [18:50:03] <mru> eh what? [18:50:08] <ohsix> elenril: do you have something in mind? /j #pulseaudio [18:50:15] <BBB> BastyCDGS: what is that? [18:50:20] <Kovensky> hm, is (0 > NaN) true or NaN [18:50:26] <mru> false [18:50:35] <mru> any comparison to nan is false [18:50:35] <BastyCDGS> oh just because modules usually use lots of channels [18:50:42] <mru> so? [18:50:44] <BBB> BastyCDGS: it's still mod :) [18:50:46] <Kovensky> ok [18:50:48] <BBB> SAMPLE_FMT_MOD makes sense [18:50:54] <BBB> or SAMPLE_FMT_COMPOSER [18:50:58] <BBB> whatever, give it a cute name [18:51:04] <BastyCDGS> I'ld prefer SAMPLE_FMT_COMPOSER [18:51:05] <mru> KITTEN? [18:51:14] <BBB> mru: awesome [18:51:20] <BastyCDGS> we could add support MID support later too [18:51:23] <BBB> kitty is better [18:51:26] <BBB> SAMPLE_FMT_KITTY [18:51:27] <BastyCDGS> like opencubicplayer does [18:51:36] <BastyCDGS> it can also play .MID files using MOD engine [18:52:09] <BBB> so you need a demuxer/decoder (dmx can be "raw"-style) [18:52:21] <BBB> the decoder "converts" from mod format to an internal composer-representation [18:52:27] <BBB> and an audioconvert-style extensions converts that to wave [18:52:33] <BBB> and voila, we can play mod :) [18:52:46] <BBB> ffplay.c wouldn't even have to be modified [18:53:36] <BBB> and yes, midi support could be "designed in" as well [18:53:52] <_av500_> BBB: what is pts dts for a packet of notes? [18:54:04] * Kovensky abuses undef as an integer NaN [18:54:08] <BBB> for all I care we start assining it AV_NO_PTS [18:54:34] <BastyCDGS> and if a mod format gets an encoder it just takes the internal composer-representation to do this ;) [18:54:35] <BastyCDGS> grewa [18:54:40] <_av500_> but what u get out of a decorder is assumed timeable [18:54:46] <BastyCDGS> BBB, TuComposer has MIDI support designed in [18:54:47] <BBB> let's not bikeshed until a simple implementation exists :) [18:54:48] <Vitor1001> BBB: The problem imho of outputting audio is that [18:54:48] <Vitor1001> 1) all the audio AVContext fields with be somewhat meaningless (bit_rate, sample_rate, etc). channels might be the exception. [18:54:48] <Vitor1001> 2) the allocation will be probably made by the decoder [18:54:51] <BastyCDGS> samples can have MIDI channel etc. [18:55:10] <BBB> Vitor1001: I think that describes 95% of our audio codecs [18:55:36] <BBB> Vitor1001: for each, only a small subset of AVCodecCtx fields are used/filled in [18:56:00] <BastyCDGS> bits_per_sample could be used for number of channels in the internal mod [18:56:03] <Vitor1001> All the players need a sample_rate, even if the demuxer sets it [18:56:06] <BastyCDGS> channels is output of mixer [18:56:36] <Vitor1001> The fields are also there for video and will be there for AVMEDIA_COMPOSER. [18:56:50] <Vitor1001> What change is what client application might expect to do with it. [18:56:55] <BastyCDGS> one thing to note, .MID playback using a MOD engine requires sth. like GUS patches [18:57:35] <Vitor1001> But I agree, changing the audio convert framework to accept SAMPLE_FMT_COMPOSER will make everything work automagically... [18:58:12] <BBB> we might want to "extend" sample_rate a bit, so you can set it to whatever-you-please and the decoder may override it (always does, except for mod) [18:58:22] <BBB> or maybe request_samplerate, like we have request_channel_mask [18:58:23] <BastyCDGS> maybe we don't have to do this [18:58:34] <BastyCDGS> just add an extra field which is only used if SAMPLE_FMT_COMPOSER is set [18:59:00] <BastyCDGS> field could be point to AVComposer structure which is similar to TuComposer library base [18:59:22] <BastyCDGS> (according to the 7 points) [18:59:48] <BastyCDGS> AVComposer contains a player handler and a pointer to the module data [18:59:58] <BBB> BastyCDGS: do you think you can write A) an audioconvert.c extensions that converts SAMPlE_FMT_COMPOSER to float/s16/u8, B) a raw demuxer that forwards mod packets to an audio decoder, and C) a set of mod decoders in libavcodec/mod(*).c that decodes file data into SAMPLE_FMT_COMPOSER, which yopu may then define relatively freely? [19:00:41] <BBB> and then write it in such a way that it works in ffplay.c without modifications to ffplay.c [19:00:48] <BastyCDGS> A) is the mixing engine, right? [19:00:49] <BBB> (bonus points for that) [19:00:53] <BBB> yes [19:01:24] <BastyCDGS> using TuComposer's one, it's 99,9% platform independent [19:01:45] <BastyCDGS> that should be straight forward [19:01:54] <Vitor1001> BastyCDGS: Adding a pointer to AVCompose struct to AVCodecContext is hackish. It would be better then to make the decoders output in the "void *data" field this pointer. [19:01:55] <BastyCDGS> but it would be nice if the user can choose between different mixing engines [19:01:59] <BastyCDGS> like TuComposer can do too [19:02:20] <BastyCDGS> i.e. one "low-quality" one for real-time playback and one high-quality with all oversampling, interpolation, click-removal, etc. stuff for writing to HDD [19:02:28] <BastyCDGS> maybe also integer/FPU ones [19:03:01] <BastyCDGS> AVComposer should be part of the public API [19:03:03] <BBB> the user doesn't choose a "mixing engine" [19:03:07] <BBB> he chooses a "quality" then [19:03:09] <BastyCDGS> it should be possible to write a tracker with it [19:03:10] <BBB> or whatever the difference is [19:03:20] <BBB> the tracker would be an internal implementation detail [19:03:22] <BastyCDGS> I meant quality ;) [19:03:23] <Vitor1001> BastyCDGS: The point of "choosing different engines" should work the same way as choosing different scaler algos with swscaler [19:03:28] <Vitor1001> with flags [19:03:29] <BastyCDGS> yes [19:03:43] <BBB> I agree the user should never "see" the AVComposer [19:03:57] <BBB> just like the user never sees the MP3DecodeContext [19:04:00] <BBB> it sees an AVCodecContext [19:04:03] <BBB> nothing else [19:04:20] <BastyCDGS> so tracker writers have to use public API functions [19:04:28] <BastyCDGS> which write in the AVComposer stuff [19:04:46] <Vitor1001> The AVComposer should be visible for a caller app. [19:06:14] <CIA-93> ffmpeg: mstorsjo * r23290 /trunk/ffserver.c: [19:06:15] <CIA-93> ffmpeg: ffserver: Plug some memory leaks [19:06:15] <CIA-93> ffmpeg: Patch by Howard Chu, hyc at highlandsun dot com [19:07:07] <BastyCDGS> BBB [19:07:16] <BastyCDGS> B) are mod/s3m/xm/it loader [19:07:24] <BastyCDGS> which convert into internal composer representation [19:07:33] <BastyCDGS> or encoders convert from internal composer representation [19:07:39] <BastyCDGS> then forward to the decoder [19:08:16] <Vitor1001> I'd say this is C) [19:08:29] <Vitor1001> B) is just a do-nothing wrapper like the image2 demuxer. [19:08:41] <BastyCDGS> I thought C is the playback engine [19:08:53] <BastyCDGS> the playback engine interprets notes etc. [19:09:01] <BastyCDGS> and fills the mixer A) with it [19:09:44] <Vitor1001> I'd put that on A) too... [19:09:45] <BastyCDGS> hey saste [19:09:51] <BastyCDGS> just noticed you got here, fine :) [19:11:03] <saste> hi basty reading your mail now... [19:12:27] <BastyCDGS> viktor1001 you mean the wrapper is there we can change/switch mod engines later or sth. like that [19:12:36] <BastyCDGS> or what's the reason of the do-nothing wrapper? [19:12:44] <wbs> BastyCDGS: his name is vitor, btw. [19:12:55] <CIA-93> ffmpeg: mstorsjo * r23291 /trunk/ffserver.c: [19:12:55] <CIA-93> ffmpeg: ffserver: Fix another memory leak [19:12:55] <CIA-93> ffmpeg: Don't allocate st->codec, it will be overwritten by the memcpy a few [19:12:55] <CIA-93> ffmpeg: lines further down. [19:12:55] <CIA-93> ffmpeg: Fix by Howard Chu, hyc at highlandsun dot com [19:12:56] <BastyCDGS> oops sorry [19:12:59] <Vitor1001> BastyCDGS: The wrapper is just there because there is not much point in separating a demuxer/decoder for a mod file [19:13:06] <Vitor1001> in the same way of a jpeg file [19:13:38] <jai> also, use the tab key luke... [19:13:43] <Vitor1001> The file should be fed to the decoder directly. [19:14:13] <Vitor1001> And the decoder will transform the coded data in some internal representation. [19:15:01] <Vitor1001> As an internal representation I mean something format independent and part of the public api [19:15:14] <jai> has it been decided where the renderer will live? [19:15:29] <Vitor1001> And doing something with this internal representation do not belong to libavcodec. [19:16:45] <BastyCDGS> yes I meant it that way, too that internal representation is part of public API [19:17:27] <wbs> hyc: regarding the strchr vs memchr fix; are you sure it should check c->buffer_end? as far as I understand the code that calls rtsp_parse_request there, it only has data between c->buffer and c->buffer_ptr, not necessarily up to c->buffer_end? [19:17:38] <Vitor1001> Since libavcodec should only do the decoding, all that belongs in it is outputting this internal representation [19:18:34] <BastyCDGS> so the demuxer just probes if it's valid MOD/S3M/XM/IT/whatever will be add and forwards then in read_header to the decoder? [19:19:18] <BBB> read_header does nothing [19:19:26] <BBB> read_packet just reads the file [19:19:32] <BBB> and forwards directly to decoder [19:19:34] <BBB> (I think) [19:19:57] <BastyCDGS> read_header could check if the module header isn't corrupt [19:20:08] <BastyCDGS> so that read_packet can ensure that it's okay [19:20:12] <hyc> wbs: possible. the point is that before, strchr was searching past buffer_end [19:20:40] <BastyCDGS> but when I think about your approach, BBB [19:20:47] <BastyCDGS> it's the same way TuComposer does it, too [19:20:56] <wbs> hyc: yeah, I know. just wanted to see that once we fix it, we actually fix it correctly and not just something not-really-all-that-correct either [19:20:58] <BastyCDGS> there's only a IdentifyModule (which is av_probe) and LoadModule [19:21:03] <BastyCDGS> (which would be read_packet) [19:21:16] <Vitor1001> "(09:18:34 PM) BastyCDGS: so the demuxer just probes if it's valid MOD/S3M/XM/IT/whatever will be add and forwards then in read_header to the decoder?" [19:21:17] <Vitor1001> yes [19:22:04] <hyc> wbs: looks like you're right. should be buffer_ptr [19:22:07] <Vitor1001> But forward it to the _right_ decoder, by setting the right codec_id. [19:24:19] <BastyCDGS> I think I will start with porting the header files from TuComposer... [19:24:22] <CIA-93> ffmpeg: mstorsjo * r23292 /trunk/ffserver.c: [19:24:22] <CIA-93> ffmpeg: ffserver: Fix an out of bounds read [19:24:22] <CIA-93> ffmpeg: Fix by Howard Chu, hyc at highlandsun dot com [19:24:24] <BastyCDGS> module.h, song.h etc. [19:24:35] <BastyCDGS> to make it FFmpeg look&feel [19:24:43] <BastyCDGS> make comments doxygen friendly [19:24:48] <BastyCDGS> convert ULONG => uint32_t etc. [19:25:01] <BastyCDGS> and lowercase struct / element names etc. [19:25:13] <BastyCDGS> use 4 space indentation (tucomposer uses 2 space up to now) [19:25:34] <BastyCDGS> this also includes remove stuff which isn't needed anymore because it's already in ffmpeg [19:25:37] <Vitor1001> BastyCDGS: Yes, the first thing would be getting the AVComposer structure done and reviewed [19:25:59] <BastyCDGS> where I should put the header files anyway? [19:26:06] <BastyCDGS> lavf or lavc or lavu? [19:26:32] <Vitor1001> lavc, it is the only one who will need it. [19:26:57] <BastyCDGS> I will prefix them with tuc_ ok? [19:27:01] <BastyCDGS> tuc => the united composer [19:27:07] <BastyCDGS> one for all - all for one ;) [19:27:24] <BastyCDGS> thus => tucomposer/module.h => libavcodec/tuc_mod.h [19:27:28] <BastyCDGS> tuc_module.h [19:27:31] <Vitor1001> How many types will be needed? [19:27:32] <BastyCDGS> what do yout think? [19:27:35] <Vitor1001> I mean public ones? [19:27:46] <BastyCDGS> module.h, song.h, position.h, track.s, instr.h, sample.h, synth.h [19:27:49] <BastyCDGS> all of these are public [19:27:58] <Vitor1001> and they all need to be? [19:28:14] <BastyCDGS> these are the 7 points from the mail [19:29:06] <BastyCDGS> depends if we want to allow people to access there directly...we can make them private too. but then we have kind of getters/setters [19:29:07] <Vitor1001> Ok, but is it just 7 types? [19:29:21] <Vitor1001> No, no OO here ;) [19:29:40] <jai> avcomposer factory? ;) [19:30:17] <BastyCDGS> 7 dwarfes and a target ELF...lol [19:30:43] <BastyCDGS> these 7 types are the module itself [19:30:51] <BastyCDGS> tucomposer has a player.h for the playback engine [19:31:02] <BastyCDGS> which will also be used by FFplay for pattern display etc. [19:31:29] <BastyCDGS> and it has a external/mixer.h which is the mixing engine structure [19:31:36] <BastyCDGS> but maybe we can add that into player.h, too? [19:33:28] <Vitor1001> I was wondering if one should do an avcompose.h with all the 7 types. [19:33:38] <Vitor1001> And that's pretty much all that will be public. [19:33:51] <Vitor1001> But in anyway, I think this is the right place to start. [19:34:06] <hyc> wbs: thanks again [19:34:14] <Vitor1001> And I suggest you send it to the ML as soon as you have done it. [19:34:35] <Vitor1001> Since it will be public API, people will want to review it well before it is set on stone [19:35:00] <BastyCDGS> of course we can join them all in one, but it will be a very big file ;) [19:35:29] <BastyCDGS> 62 external.h [19:35:29] <BastyCDGS> 1104 instr.h [19:35:29] <BastyCDGS> 209 module.h [19:35:29] <BastyCDGS> 782 player.h [19:35:29] <BastyCDGS> 230 position.h [19:35:29] <BastyCDGS> 339 sample.h [19:35:29] <BastyCDGS> 391 song.h [19:35:30] <BastyCDGS> 924 synth.h [19:35:30] <BastyCDGS> 566 track.h [19:35:31] <BastyCDGS> 330 tucomposer.h [19:35:31] <BastyCDGS> 4937 total [19:35:47] <BastyCDGS> even if we can shorten them a lot it will still be around 2-3k lines I guess [19:36:27] <BastyCDGS> I think that amount of lines it a bit overkill for a single header file [19:37:07] <BastyCDGS> I wasn't counting the stuff in the external/ sub dir but that shouldn't be as much [19:37:07] <Vitor1001> Well, it is mostly enums [19:37:29] <BastyCDGS> maybe we do 3 files? [19:37:36] <BastyCDGS> one avcomposer.h (tucomposer.h) [19:37:44] <BastyCDGS> one module.h (contains module.h, song.h, etc.) [19:37:52] <BastyCDGS> and one player.h (contains player.h and external/mixer.h) [19:38:09] <Vitor1001> player.h should be public? [19:38:25] <BastyCDGS> in fact all when you don't want getter/setters for each single element in the struct ;) [19:38:56] <wbs> DonDiego: btw, regarding that ogv video that you had problems with... do you still get crashes if you add -noframedrop? [19:39:30] <BastyCDGS> module.h is public because tracker writers have to change the values of the modules if the user in the GUI changes module name etc. [19:39:33] <Vitor1001> Oh, I see. "player.h" makes me think of a player interface, not something the decoder would output [19:39:44] <BastyCDGS> player.h is the playback engine [19:40:04] <BastyCDGS> i.e. it takes the notes from the internal representation, calculates final frequency/volume/panning etc. for the mixer [19:40:13] <DonDiego> wbs: with ffplay? [19:40:25] <BastyCDGS> so after call to DoPlayerIRQ in TuComposer the mixer can directly output the mixing engine stuff to PCM [19:40:29] <Vitor1001> Is it needed to convert mod to xm? [19:40:35] <BastyCDGS> yes, too [19:40:53] <BastyCDGS> but also for mod to PCM [19:41:12] <Vitor1001> MOD to XM should be completely different than mod to pcm [19:41:13] <BastyCDGS> for converting from module to module the module.h stuff is needed, too. [19:41:44] <Vitor1001> everything needed to convert mod <-> xm should be in libavcodec/ [19:42:19] <BastyCDGS> depends on how well you want to make the converters, if you want do dumb and naive note 2 note conversation without deep analysis player.h isn't needed for mod<->xm [19:42:21] <Vitor1001> everything that is needed to convert mod -> pcm but not mod -> xm should _not_ be in libavcodec/ [19:42:34] <BastyCDGS> but for a in deep analysis (this incldues playtime calculation and seek offsets) [19:43:05] <BastyCDGS> you need player.h [19:43:37] <Vitor1001> ok, so as far as I understand player.h should not be in libavcodec/ [19:43:55] <BastyCDGS> oh lavc is ok I think [19:43:57] <BastyCDGS> why you think not? [19:44:12] <Vitor1001> it has nothing to do with decoding (in the strict sense of "turning the input to something universal") [19:44:51] <BastyCDGS> well input is internal composer representation [19:44:53] <BastyCDGS> output is PCM [19:45:01] <BastyCDGS> ok not direct [19:45:09] <BastyCDGS> output is SAMPLE_FMT_COMPOSER (mixing engine) [19:45:09] <wbs> DonDiego: yeah [19:45:18] <BastyCDGS> and that does the actual PCM conversation [19:45:18] <Vitor1001> No. Input is XM. After decoding internal composer representation. [19:45:24] <BastyCDGS> which can be mp3/ogg vorbis/etc. [19:45:57] <DonDiego> wbs: with -noframedrop i see some frames before the crash [19:46:05] <wbs> DonDiego: hmm, ok [19:46:31] <BastyCDGS> 1. load module (convert to internal composer representation) [19:46:45] <BastyCDGS> 2. for each tick call DoPlayerIRQ (playback engine which fills mixing engine fields) [19:47:21] <BastyCDGS> 3. mixing engine mixes multichannel samples to stereo/mono/5:1/etc. and that is outputted [19:47:27] <BastyCDGS> that's the steps for normal playback [19:47:41] <Vitor1001> And why 2) and 3) is needed for mod <-> xm? [19:48:35] <BastyCDGS> for mod <=> xm you won't need it, but for xm <=> it you will [19:48:35] <BastyCDGS> to get the virtual NNA channels to host channels [19:48:56] <BastyCDGS> but only if you want a smart converter [19:49:16] <BastyCDGS> consider another example, which explains it better: [19:49:40] <BastyCDGS> imagine you have a image format which doesn't support truecolor, but you want to convert a truecolor image to this target format [19:50:12] <BastyCDGS> a dumb decoder would simply write wrong pixel-data into the target format, a smart converter instead would convert the source image to 8bpp or sth. like that before [19:50:43] <BastyCDGS> for the xm<=>it example: [19:50:57] <BastyCDGS> instrument #1 NNA set to continue, pattern data: [19:51:05] <BastyCDGS> C-6 01 ... [19:51:10] <BastyCDGS> D#6 01 ... [19:51:19] <BastyCDGS> if you convert that naive to xm it's wrong [19:51:36] <BastyCDGS> because D#6 would cut C-6 (XM doesn't support NNA continue) [19:51:53] <BastyCDGS> (it plays 2 independant channels, xm would play one) [19:52:01] <BastyCDGS> so in xm that would have look like: [19:52:27] <BastyCDGS> ch. #1 ch #2 [19:52:27] <BastyCDGS> C-6 01 ... ... .. ... [19:52:27] <BastyCDGS> ... ... ... D#6 01 ... [19:52:39] <BastyCDGS> that would be a smart converter ;) [19:53:41] <BastyCDGS> DoPlayerIRQ calculates the NNA stuff and assigns target channels [19:54:05] <BastyCDGS> so the xm writer can just take the DoPlayerIRQ output and sees that these are actually 2 channels: output XM sounds the same as the original IT ;) [19:54:36] <Vitor10011> BastyCDGS: Sorry, my laptop decided it was out of battery when it was not :p [19:54:45] <BastyCDGS> damn I typed so much [19:55:06] <jai> BastyCDGS: pastebin [19:55:09] * jai goes [19:56:42] <Vitor10011> mru: Any live irc-logs? [20:00:10] <CIA-93> ffmpeg: mstorsjo * r23293 /trunk/ffserver.c: [20:00:10] <CIA-93> ffmpeg: ffserver: Fix extradata handling [20:00:10] <CIA-93> ffmpeg: Patch by Howard Chu, hyc at highlandsun dot com [20:01:53] <Vitor10011> BastyCDGS: About your example with palette -> truecolor jpeg, what ffmpeg would do will be [20:01:53] <Vitor10011> 1) lavc outputs paletted data [20:01:53] <Vitor10011> 2) swscaler (that is not part of lavc!) converts it to truecolor [20:01:53] <Vitor10011> 3) ffmpeg.c sends truecolor frame to lavc jpeg encoder [20:02:42] <BastyCDGS> we need some similar approach for converting mods between themselves [20:02:53] <BastyCDGS> at least if we want a converter that really deserves its name ;) [20:04:02] <Vitor10011> Hmm... What if you had a different intermediate format? [20:04:20] <BastyCDGS> what you mean exactly by this? [20:04:37] <Vitor10011> One where you could just pass that struct as read from mod directly to xm encoder without "playing" [20:05:11] <BastyCDGS> then you would have to write different converters for each possible combination of input/output I doubt [20:05:39] <Vitor10011> Hmm, in your example, what does NNA stands for? [20:05:39] <BastyCDGS> or do you mean mod => internal comp. represenation => xm encoder? [20:05:45] <BastyCDGS> New Note Action... [20:05:56] <Vitor10011> I mean "mod => internal comp. represenation => xm encoder", yes. [20:05:59] <BastyCDGS> it tells the tracker what happens with the previous note when it's played on the same channel [20:06:12] <Vitor10011> For some ultra-smart internal representation that would do the magic... [20:06:12] <BastyCDGS> NNA cut => kill previous note [20:06:24] <BastyCDGS> NNA fade => fade-out previous note, play new note on new channel [20:06:32] <BastyCDGS> NNA off => key-off noe, play new on new ch [20:06:38] <Vitor10011> So if the internal format did not support NNA it could still represent any input? [20:06:41] <BastyCDGS> NNA cont => don't do anything with old note, play new on new ch [20:06:44] <BastyCDGS> XM only knows NNA cut [20:06:53] <BastyCDGS> S3M/MOD too [20:07:22] <BastyCDGS> tucomposer has an additional NNA mode [20:07:36] <BastyCDGS> NNA synth => calls synth sound assembler which handles old note => new note on new channel [20:08:00] <BastyCDGS> NNA synth gives you assembly language level control of what happens with old note [20:08:43] <Vitor10011> But besides NNA synth [20:08:53] <CIA-93> ffmpeg: mstorsjo * r23294 /trunk/ffserver.c: [20:08:53] <CIA-93> ffmpeg: ffserver: Fix streaming with more than one stream [20:08:53] <CIA-93> ffmpeg: Fix by Howard Chu, hyc at highlandsun dot com [20:08:53] <Vitor10011> NNA cut can be represented without NNA, no? [20:09:25] <BastyCDGS> NNAs are just an example where you need smart conversation, it's just the most audible one [20:10:04] <mru> Vitor10011: no, sorry [20:10:10] <BastyCDGS> I want a approach like GCC does with optimization, an intermediate which is then converted to the best target arch asm code [20:10:13] <Vitor10011> mru: no problem [20:10:44] <Vitor10011> BastyCDGS: yes, that would be ideal [20:11:27] <hyc> wbs: nice, looks like only the timestamp patch is remaining [20:11:52] <BastyCDGS> this would have FFmpeg the best mod converter in the universe ;) :) [20:12:01] <BastyCDGS> all other mod converters I know of do it the dumb way [20:12:02] <Vitor10011> BastyCDGS: The next best would be (for "XM -> MOD") [20:12:02] <Vitor10011> 1) XM -> XM decoder -> internal representation (in lavc) [20:12:02] <Vitor10011> 2) internal representation -> internal representation simplified for MOD (in libavcompose) [20:12:02] <Vitor10011> 3) internal representation -> MOD (in lavc) [20:12:43] <mru> having the "best mod player in the world" is a bit like having the best steam engine in the world [20:13:03] <BastyCDGS> s/player/converter ;) [20:13:09] <BastyCDGS> ok best player, too. :D [20:13:13] <wbs> hyc: that one, the CHECK_CODEC(codec_id) fix, then one on rewriting the ffm header, and the h264/rtp stuff [20:13:17] <mru> analogy still stands [20:13:36] <hyc> wbs: ah yes [20:13:42] <wbs> hyc: it took me a while to crawl the mail thread, pick out the unapplied parts, check them in as local commits in git here to get some kind of overview of them [20:13:59] <wbs> and of course I ran into some new issues of my own while looking at this, too ;P [20:14:11] <hyc> I'll bet... [20:14:12] <BastyCDGS> yes internal representation is simplified just because MOD is simpler than XM and XM is simpler than IT [20:14:15] <Vitor10011> BastyCDGS: In step 2), you could maybe just pass a list of supported features of MOD to whatever function you are calling [20:14:16] <BastyCDGS> e.g. NNA would always be cut [20:14:47] <hyc> I sprinkled a bunch of new ifdef's in ffserver as well, to build my stripped down Android binary [20:14:50] <BastyCDGS> the MOD/S3M/XM could also just check if there's an instrument having NNA != cut and if so use smart mode, otherwise naive [20:14:59] <BastyCDGS> i.e. convert pattern by pattern/instrument by instrument [20:15:25] <hyc> but I don't think I'll be posting those, it's pretty unlikely to be of interest to anyone else [20:17:18] <Vitor10011> BastyCDGS: So do you understand why in my way of seeing things I think player.h should not be in lavc? [20:17:31] <BastyCDGS> as said, vitor, my approach for smart conversation would be do an internal playback (but instead recording the PCM to /dev/dsp or file etc.) it just uses the mixer structure to decide how to fill the notes in the target module format. [20:18:28] <Vitor10011> yes, but it would be in step 2), no? [20:18:29] <BastyCDGS> BTW, I did that once to rip a game tune from amiga (by catching write to hardware audio registers) and use that to create MOD structure :) [20:19:15] <BastyCDGS> the code for this btw, is also in the WB39.7z ;) [20:19:39] <BastyCDGS> Work:Sources/Asm/GianaPlay.s [20:20:22] <hyc> wbs: the CHECK_CODEC(codec) is obviously wrong, ccf->codec and ccs->codec are always NULL [20:20:29] * Vitor10011 is still downloading ;) [20:21:24] <Vitor10011> My point is that if you are doing the internal playback in step 2, its code should not be in lavc, but somewhere else. [20:21:59] <BastyCDGS> but where? [20:22:12] <Vitor10011> libavcompose? ;) [20:22:36] <BastyCDGS> that's what I prefer anyway ;) [20:22:52] <BastyCDGS> but mru will probably thumb up ;) [20:22:54] <BastyCDGS> right, mru? ;) [20:23:05] <BastyCDGS> and not only him [20:23:11] <mru> I think we should all be realistic [20:23:54] <ohsix> but when its pulseaudio all bets are off [20:24:08] <elenril> bcoudurier: can you review vorbiscomment writing for vorbis in ogg please? [20:24:17] <Vitor10011> mru: What do you mean precisely? [20:25:22] <mru> well, the tucomposer code is in no way whatsoever fit for inclusion in ffmpeg [20:25:29] <CIA-93> ffmpeg: mstorsjo * r23295 /trunk/ffserver.c: [20:25:29] <CIA-93> ffmpeg: ffserver: Fix one of the codec parameter checks [20:25:29] <CIA-93> ffmpeg: This is probably what was originally intended; the codec pointers are all NULL. [20:25:29] <CIA-93> ffmpeg: Fix by Howard Chu, hyc at highlandsun dot com [20:25:36] <mru> hell, half of it is m68k asm with no corresponding c code [20:25:42] <BastyCDGS> ??? [20:25:46] <BastyCDGS> half? [20:26:01] <BastyCDGS> everything except MOD/S3M/XM/IT loader is C [20:26:26] <BastyCDGS> and these are pretty small [20:26:43] <BastyCDGS> if you mean DoPlayerIRQ and the mixer...well these are also available as C [20:26:54] <BastyCDGS> so what's your problem? [20:28:05] <Vitor10011> mru: I find realistic doing [20:28:05] <Vitor10011> 1) Getting the internal composer representation reviewed [20:28:05] <Vitor10011> 2) Getting the MOD/S3M/XM/IT decoder commited [20:28:05] <Vitor10011> 3) Start discussing where put the code to actually play the internal representation [20:28:05] <Vitor10011> 4) Getting it done and reviewed [20:28:06] <Vitor10011> 5) Start discussing what to do to conversion [20:28:09] <BastyCDGS> btw, the loaders have to be rewritten anyway even if they would be available as C code [20:28:19] <BastyCDGS> since ffmpeg has it's own bitstream / bytestream stuff [20:28:51] <Vitor10011> 2) and 3) can be done in parallel [20:29:21] <mru> when I poked around the code I had trouble finding anything but function stubs in the c code [20:29:26] <mru> and what code I found was full of hack [20:29:51] <BastyCDGS> where you have been looking? [20:30:01] <BastyCDGS> can you give some examples, please? [20:30:50] <mru> in the zip file you linked a few weeks ago [20:30:58] <BastyCDGS> that is clear, be more precise, please [20:31:05] <mru> I don't remember the filenames [20:31:48] <BastyCDGS> do you mean that huge header file which contains the public API? [20:31:55] <BastyCDGS> that are wrappers for amiga OS library style calls [20:31:59] <BastyCDGS> they aren't needed in ffmpeg anyway [20:32:16] <BastyCDGS> this is because amiga os library expect parameters in registers not on stack [20:32:31] <mru> I was looking for mixing functions [20:32:33] <mru> and such [20:32:43] <mru> the files with names suggesting they might contain it had only stubs [20:32:50] <mru> I looked no further [20:32:58] <mru> the code is clearly not tidy [20:33:49] <ohsix> needs more adjectives [20:33:50] <BastyCDGS> mixer is Internal/InternalLQMix.c [20:34:02] <mru> I deleted it [20:34:26] <mru> and I'm not particularly interested anyway [20:34:38] <mru> you're just hogging the channel so I have nothing else to troll about [20:35:12] <elenril> you can always troll gstreamer [20:35:21] <DonDiego> i'm disappointed [20:35:26] <ohsix> or pulse [20:35:31] <BastyCDGS> dondiego, why? [20:35:36] <DonDiego> i just compiled valgrind from source [20:35:50] <DonDiego> and version 3.5.0 still complains about unknown instructions.. [20:36:00] <mru> I think they accept patches [20:36:03] <ohsix> 3dnow? :P [20:36:04] <drv> what's missing, SSE stuff? [20:36:04] <CIA-93> ffmpeg: stefano * r23296 /trunk/libavformat/riff.c: (log message trimmed) [20:36:04] <CIA-93> ffmpeg: Add missing codec id <-> codec tag entries: [20:36:04] <CIA-93> ffmpeg: CODEC_ID_RAWVIDEO <-> Y41B [20:36:04] <CIA-93> ffmpeg: CODEC_ID_RAWVIDEO <-> Y42B [20:36:04] <CIA-93> ffmpeg: CODEC_ID_RAWVIDEO <-> YUV9 [20:36:05] <CIA-93> ffmpeg: CODEC_ID_RAWVIDEO <-> YVU9 [20:36:05] <CIA-93> ffmpeg: These codec tags are listed in fourcc.org, and are already listed in [20:36:12] <mru> ohsix: yes, 3dnow [20:36:31] <drv> 3dtenyearsago [20:36:33] <BastyCDGS> dondiego, what assembler it uses to assemble? [20:36:35] <wbs> hyc: I'm not totally sure about the timestamp fix though [20:36:38] <ohsix> its a bygone era; you might have to do that sort of thing yourself heh [20:36:40] <BastyCDGS> maybe you have to update the assembler, too. [20:37:12] <mru> BastyCDGS: do you know what valgrind is? [20:37:23] <BastyCDGS> something like enforcer on amiga [20:37:30] <mru> I've no idea what that is [20:37:47] <mru> but here's a hint: find out what stuff is before having opinions on it [20:37:51] <mru> you look less of a fool then [20:38:08] <BastyCDGS> I know it's a debugger [20:38:19] <mru> and I know it's not [20:38:20] <drv> it's more of a cpu emulator with some debugging tools on top [20:38:28] <mru> it's a checker, not a debugger [20:38:58] <BastyCDGS> checking for stuff like memory overwriting ;) [20:39:00] <hyc> wbs: possibly i had unreliable input data [20:39:07] <BastyCDGS> and that's what enforcer is on amiga [20:39:17] <hyc> I've been testing exclusively with RTMP input streams [20:39:52] <Vitor10011> BastyCDGS: You said it was a lot of trouble getting MOD/S3M/XM/IT to work [20:39:57] <CIA-93> ffmpeg: stefano * r23297 /trunk/ (3 files in 3 dirs): [20:39:57] <CIA-93> ffmpeg: Add libavfilter 1-input - 1-output regression test, corresponding to the [20:39:57] <CIA-93> ffmpeg: target regtest-lavfi_pix_fmts. [20:39:57] <CIA-93> ffmpeg: The lavfi_pix_fmts test is disabled, this because there are [20:39:57] <CIA-93> ffmpeg: many tests which are failing, and there are still some output files [20:39:58] <CIA-93> ffmpeg: which cannot be played by NUT/ffplay. [20:40:03] <Vitor10011> BastyCDGS: Was the work in the loader or elsewhere? [20:40:11] <BastyCDGS> to get it work perfectly and handle all that undocumented stuff, basic support was easy [20:40:27] <BastyCDGS> partially loader / most stuff playback engine [20:40:34] <DonDiego> siretart: what stops us from making a 0.5.2 point release? [20:40:50] <DonDiego> a few patches have accumulated [20:41:12] <Vitor10011> Isn't the playback engine something whose behaviour is very well defined as a function of the internal representation? [20:41:24] <BBB> Vitor10011: I am ok with all of it, but I'd prefer if we assume from the beginning that the "SAMPLE_FMT_COMPOSER" stuff will be convertable with audioconvert.c [20:41:31] <bcoudu> wait [20:41:34] <BBB> Vitor10011: that way most applications won't need anything to play it [20:41:35] <BastyCDGS> it should be, but the documentation of S3M/XM is awful regarding this [20:41:38] <bcoudu> is theora using jpeg range ? [20:41:39] <BBB> Vitor10011: other than that I love your plan [20:42:05] <bcoudu> die ! [20:42:11] <BBB> and I agree with mru that tucomp code needs major review before it's fit for inclusion into ffmpeg, so let's do this small pieces at a time [20:42:25] <Vitor10011> BBB: Great. Anyway, we'll have a lot of time to discuss it while the internal representation is reviewed. [20:42:27] <BastyCDGS> BBB, I also said this...it has to be refactored a lot etc. ;) [20:42:29] <siretart> DonDiego: I'd say nothing [20:42:35] <BBB> excellent then [20:42:38] <DonDiego> go for it then? [20:42:47] <BBB> BastyCDGS: you have ten mentors, it seems, you should feel very lucky ;) [20:42:54] <bcoudurier> what's tucomp ? [20:42:54] <BastyCDGS> but it's simply not true that only half of the stuff is C and the rest asm [20:43:03] <BBB> most soc students in other projects (not ffmpeg) don't ever interact with their mentor [20:43:16] <BBB> bcoudurier: BastyCDGS's mod player [20:43:22] <bcoudurier> humm is yuvi around ? [20:43:59] <BastyCDGS> BBB, small correction: tracker [20:44:04] <BastyCDGS> although there's no GUI for it yet [20:44:06] <BBB> uh yes [20:44:09] <BBB> well look I'm an idiot [20:44:15] <BBB> for me anything that plays sound is a sound player [20:44:22] <BastyCDGS> no you aren't, because practically it's usable only as a player right now [20:44:27] <BastyCDGS> so we both are right ;) [20:45:27] <BastyCDGS> but I would like to know from mru what he meant with full of hacks [20:45:49] <wbs> BastyCDGS: trust me, you will notice when you try to get the code thrugh the review [20:46:26] <BastyCDGS> well if you give me some hints I can fix some issues straight away when I refactor it [20:46:38] <mru> ok then: all of it [20:47:31] <BastyCDGS> that's like when got asked where I life, and I reply with: somewhere on earth [20:47:40] <BastyCDGS> that's as helpful as your reply [20:48:01] <mru> I didn't see any code I wouldn't want replaced [20:48:45] <BastyCDGS> I mean actual code, not that refactor stuff (i.e. ULONG => uint32_t, etc.) that's clear [20:48:58] <BastyCDGS> I mean when all the refactoring is done, what's then there to be replaced [20:51:02] <BBB> you shouldn't use arch-specific size-specifiers unless there's a good reason [20:51:12] <BBB> for example, a palette holding RGB32 data should probably be a uint32_t [20:51:16] <BBB> but a size parameter should not [20:51:19] <BBB> it should be int [20:51:23] <BBB> it's a counter, nothing more [20:51:35] <BBB> when I looked, everything was ulong/uword/etc. [20:51:40] <BBB> that's not good [20:51:45] <BastyCDGS> that's part of refactoring [20:51:51] <BBB> but more generally, just put it's in ffmpeg, as vitor suggested [20:51:54] <BBB> and then let's review it [20:51:57] <BastyCDGS> please note it is (was) an amiga OS library [20:51:58] <BBB> it's more practical than all of this [20:51:59] <BBB> :) [20:52:06] <BastyCDGS> and there you have to use ULONG etc. [20:52:08] <BastyCDGS> always [20:52:09] <DonDiego> ok, valgrind cooperates with a --disable-amd3dnow build [20:52:12] <BastyCDGS> ok not intern as a counter that rights [20:52:22] <DonDiego> but it's taking very long and hogging the cpu [20:52:32] <DonDiego> is it supposed to exit on its own? [20:52:32] <mru> 21:52 < BastyCDGS> and there you have to use ULONG etc. <-- nonsense [20:52:40] <mru> every compiler lets you use int etc [20:52:59] <BastyCDGS> yes, but on amiga, some compilers threat int as 16-bit, some as 32-bit [20:53:02] <BastyCDGS> so shared library will break [20:53:27] <BastyCDGS> read the Amiga ROM reference manual regarding this [20:54:04] <BastyCDGS> practically all functions in tucomposer that weren't static were part of the shared library [20:54:31] <mru> INT_MAX: Minimum Acceptable Value: 2 147 483 647 [20:54:34] <mru> in posix [20:54:38] <mru> and that's what we target [20:54:52] <BastyCDGS> yes and as already said, I have to refactor it [20:55:14] <mru> then there's the wild casting [20:55:15] <BastyCDGS> maybe I misexpressed a bit, I of course didn't mean a dumb convert of each ULONG => uint32_t [20:55:16] <BastyCDGS> ;) [20:55:57] <BastyCDGS> all the casting has effects there [20:56:17] <BastyCDGS> I can tell this because during that time I added casting afterwards when it wasn't necessary [20:56:18] <mru> a cast with effects is wrong [20:56:24] <BastyCDGS> and each cast that remained there changed output [20:56:27] <mru> and a cast without effects is useless [20:56:29] <mru> and therefor wrong [20:56:35] <mru> ergo, casts are wrong [20:56:51] <ohsix> reductio ad absurdium [20:57:13] <mru> there are a few rare cases where casts are needed [20:57:14] <BastyCDGS> ok then I supply a patch now will removes every cast in ffmpeg :D :P [20:57:24] <mru> and these should usually be buried under a few layers of macros [20:58:28] <BBB> about that [20:58:37] <BBB> can we please get rid of the useless consts and unsigneds everywhere? [20:58:38] <hyc> DonDiego: valgrind exits when the slave program exits [20:58:41] <BBB> they confuse me a lot [20:59:00] <BastyCDGS> casts? [20:59:06] <DonDiego> hyc: what when it does not? [20:59:30] <hyc> then just Ctrl-C or kill -INT [21:00:40] <mru> DonDiego: what are you running? [21:00:42] <DonDiego> http://pastebin.org/275990 [21:00:52] <DonDiego> this is the valgrind output [21:01:09] <BastyCDGS> BBB, what's your problem with const? [21:01:16] <BastyCDGS> I mean what confuses you? [21:01:20] <BBB> most of them don't do anything [21:01:27] <BBB> we shouldn't use qualifiers that do nothing [21:01:31] <DonDiego> mru: i'm running ffplay [21:01:38] <mru> ffplay doesn't exit on its own [21:01:41] <mru> press q in the window [21:02:16] <BBB> a const in the API can be incredibly useful, because it's a promise we won't touch the data [21:02:17] <DonDiego> it crashed [21:02:25] <DonDiego> it does exit when it crashes [21:02:26] <BBB> e.g. decode(const uint8_t *data, int size); [21:02:41] <BBB> any other use of const is usually unnecessary [21:02:46] <BastyCDGS> BBB, I use it internally also for remembering me that I shouldn't fiddle around with the initially assigned value after it without side-effects [21:02:50] <BastyCDGS> that's useful, right? [21:02:55] <mru> valgrind sometimes changes the behaviour on invalid memory accesses [21:03:10] <mru> and sdl has a habit of sticking around if unusual things happen [21:03:11] <BastyCDGS> mru, ha I said it's like enforcer ;) [21:03:13] <BBB> BastyCDGS: if a programmer doesn't know what his data means (or that he shouldn't fiddle with it), then his code is likely hacky [21:03:20] <wbs> bcoudurier: can you give an ok on http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20100525/34f38… it's a quite minimal and trivial patch [21:03:22] <mru> BastyCDGS: I suggest you tone down a bit [21:03:40] <BBB> BastyCDGS: no const will ever fix hacky code [21:04:05] <DonDiego> anyway, will yuvi or anybody be able to do something with that valgrind output i posted? [21:04:06] <BastyCDGS> mru, what have I said wrong? [21:04:10] <BBB> BastyCDGS: I suggest you compile each time you use const with and without const, and see if the asm changed. if it didn't, it wasn't necessary [21:04:26] <ohsix> ^ wtf [21:04:29] <BastyCDGS> BBB, I don't use const mainly for assembly change but as a hint for myself [21:04:33] * BBB puts a boxing ball between BastyCDGS and mru [21:05:25] <hyc> wbs: does that patch make my pts patch go away? [21:05:28] <BastyCDGS> mru, I just said that valgrind is like enforcer...right? and enforcer does check for illegal memory accesses (which are part of debugging) and that's why I assign stuff like valgrind/enforcer to debuggers also [21:05:42] <mru> BastyCDGS: and you keep going on and on and on about it [21:05:57] <wbs> hyc: yes, with that one, your patch is unnecessary [21:06:06] <hyc> cool [21:06:10] <hyc> I'll give it a shot [21:06:50] <wbs> hyc: but that should be the last unapplied bit of your patches touching ffserver.c [21:07:06] <wbs> so I think it's nearing some kind of almost-usable state soon ;P [21:07:09] <BBB> BastyCDGS: get going, this is your gsoc chance, show us you can do this :) [21:07:20] <DonDiego> BastyCDGS: mans is trying to make you cut down on the idle chatter a bit - it would indeed be appreciated, no hard feelings and don't take offense [21:07:21] <BBB> BastyCDGS: want a summary of all this on the mailinglist? [21:07:29] <mru> I looked up enforcer and it's nothing like valgrind [21:07:32] <hyc> wbs: yes, looks like it. still have the rtp-level stuff to sort thru [21:07:47] <BBB> did josh start coding, wbs? [21:07:48] <BastyCDGS> BBB, a summary would be really appreciated, yes :) [21:07:53] <BBB> BastyCDGS: good, coming up [21:07:54] <hyc> wbs: does the suggestion about bitstream filters make sense to you? [21:08:08] <mru> all it does is provide page-level protection similar to what the OS should already do [21:08:14] <hyc> or should we jsut be thinking about a couple utility functions that can be used in each place [21:08:27] <wbs> hyc: I think it makes sense, but I'm not at all familiar with bitstream filters [21:08:41] <wbs> hyc: neither am I familiar with h264 formats at that level [21:08:53] <wbs> BBB: haven't heard from him, lu_zero is his mentor formally afaik [21:08:59] <hyc> wbs: me neither, no idea how we would get ffserver to configure them. [21:09:06] <BBB> wbs: yes but you're online more than lu_zero ;) [21:09:25] <wbs> BBB: :-) [21:10:03] <hyc> valgrind is a virtual machine, which happens to have loadable modules that can assist in different debugging tasks [21:10:11] <hyc> enforcer is more like electricfence [21:10:20] <hyc> single-purpose tools... [21:10:38] <BastyCDGS> but both enforce and valgrind check for illegal memory accesses [21:10:45] <wbs> hyc: but that's a generally very desired thing; it's needed if you want to do stream copy of h264 from one container assuming one format to another, which has only been solved with (more or less) hacks up to now, afaik [21:10:46] <DonDiego> GEEEZZZ [21:10:54] <mru> BastyCDGS: you obviously don't know what valgrind is [21:10:55] <BastyCDGS> that's what I meant with sth. like (not equal) [21:11:00] <DonDiego> stop trolling about tools already [21:11:05] <mru> you probably don't know what a virtual memory operating system is either [21:11:20] <DonDiego> i'm trying to debug a crash here.. [21:11:44] <peloverde> wbs, AAC has the same problems :( [21:11:52] <wbs> peloverde: yeah, that too [21:12:23] <BastyCDGS> mru, but what you meant then as you said that valgrind changes behaviour on illegal mem access...doesn't that imply it checks for these? [21:12:29] <peloverde> Wasn't there some sort of auto BSF negotiation patch floating around? [21:12:36] <wbs> hyc: it would be very beneficial to fork that discussion off to a separate thread, and see if you get a proper solution explained to you, so that you or someone else can implement it :-) [21:12:37] <mru> BastyCDGS: just fucking go and read about it [21:13:12] <bcoudurier> wbs, this is wrong [21:13:42] <wbs> bcoudurier: ok, so how is it supposed to work, then? [21:14:05] <wbs> bcoudurier: with the current state of things, cur_pts can have values in two totally different ranges [21:14:35] <bcoudurier> cur_pts is dts [21:15:06] <bcoudurier> btw start_time should be changed to first_dts [21:15:26] <bcoudurier> find out why [21:15:36] <bcoudurier> but assigning it always to 0 is definetely wrong [21:16:02] <hyc> bcoudurier: did you already read the context here? https://lists.mplayerhq.hu/pipermail/ffmpeg-devel/2010-May/089280.html [21:16:20] <wbs> the first packet seems to pass that code before start_time is initialized [21:17:15] <DonDiego> siretart: what do we need for the 0.5.2 release? [21:17:45] <DonDiego> changelog update, VERSION bump, tarballs, homepage entry, anything i forget? [21:18:17] <bcoudurier> yes [21:20:01] <bcoudurier> current code logic seems right to me [21:20:13] <bcoudurier> get_packet_send_clock [21:20:17] <wbs> but what should cur_pts be set to, if start_time isn't initialized? [21:20:25] <DonDiego> janneg: is your "prefer libs" patch committed? [21:21:25] <bcoudurier> this is a problem [21:21:32] <bcoudurier> find out why it is not initialized [21:21:34] <bcoudurier> and fix that [21:21:53] <wbs> or did you mean that I should use c->first_pts instead of ist->start_time there? [21:21:59] <bcoudurier> otherwise set start_time to the first value you get [21:22:07] <bcoudurier> next values should be fine [21:22:16] <bcoudurier> first_dst [21:22:19] <bcoudurier> dts [21:22:19] <hyc> bcoudurier: it's not that simple [21:22:29] <hyc> in the case I saw, the first packets had absolute timestamps [21:22:32] <siretart> DonDiego: we need a release checklist :-) [21:22:34] <hyc> subsequent had only relative [21:22:45] <bcoudurier> this is wrong [21:22:47] <bcoudurier> a bug [21:22:56] <bcoudurier> fix the bug [21:23:25] <DonDiego> siretart: yeah, i guess :) [21:23:56] <hyc> bcoudurier: so what is the expected content? all relative? [21:23:59] <hyc> or all absolute ? [21:24:18] <bcoudurier> pkt.dts is absolute [21:24:28] <siretart> DonDiego: otherwise, I think that's about it. [21:25:03] <DonDiego> ok, let's start, who does what? [21:25:06] <hyc> bcoudurier: ok, that should give me an idea what to look for, thanks [21:30:17] <janneg> DonDiego: I don't think so [21:31:34] <DonDiego> siretart: i've been getting a lot of prodding that the native vorbis encoder should be disabled somehow on the branch [21:33:03] <siretart> DonDiego: in 0.5 or 0.6 or both? [21:33:26] <DonDiego> 0.6 is what matters most [21:33:42] <DonDiego> in 0.5 i don't think we should fiddle with defaults anymore [21:33:47] <DonDiego> that's set [21:33:54] <DonDiego> no surprises [21:34:00] <siretart> hm. who did propose that? [21:34:06] <DonDiego> propose what? [21:34:16] <siretart> to disable the native vorbis encoder? [21:34:29] <DonDiego> i hear it from all sides [21:34:44] <DonDiego> baptiste, alex converse, janne and today all the xiph people [21:34:54] <siretart> okay, that convinces me :-) [21:35:33] <siretart> do we already have a patch for that? [21:35:45] <DonDiego> janneg is working on one [21:35:56] <DonDiego> otherwise i can just disable the vorbis encoder in configure [21:36:06] <DonDiego> so that it does not get compiled by default [21:36:18] <hyc> bcoudurier: then it sounds like this is wrong: c->cur_pts -= av_rescale_q(ist->start_time, ist->time_base, AV_TIME_BASE_Q); [21:36:39] <hyc> why isn't it using c->first_pts instead? [21:38:46] <janneg> DonDiego: if you want to release soon disabling it in configure is probably the easiest solution for the branch [21:38:49] <wbs> I was about to suggest that, too [21:40:16] <wbs> using c->first_pts that is [21:42:44] <CIA-93> ffmpeg: diego * r23298 /branches/0.5/Changelog: Update Changelog for 0.5.2 release. [21:43:24] <spaam> why release 0.5.2 when you guys are going to release 0.6 ? [21:45:58] <bcoudurier> ist->start_time is the first pts of the stream [21:46:05] <DonDiego> oh, a release troll.. [21:46:11] <wbs> bcoudurier: start_time only gets initialized after the second packet, for reasons deep within libavformat [21:46:21] <bcoudurier> that's a bug [21:46:35] <bcoudurier> DonDiego, where ? :> [21:46:39] <siretart> spaam: because there are still people that use 0.5 and we are willing to do the release [21:46:50] * DonDiego points his finger at spaam .. [21:46:56] <bcoudurier> arf [21:46:58] <DonDiego> :) [21:48:25] <spaam> DonDiego: i like you too. [21:48:29] <spaam> siretart: ok :) [21:49:07] * DonDiego pets spaam [21:49:12] <DonDiego> hey, no hard feelings :) [21:49:17] <spaam> its ok :) [21:49:43] <DonDiego> the regulars *do* troll me about maintaining the 0.5 branch.. [21:49:51] <spaam> DonDiego: you are not like KotH ;) he like to kick me ;S [21:49:53] <DonDiego> siretart: any suggestions for the release notes? [21:51:23] <wbs> bcoudurier: do you think this would be an acceptable patch? http://albin.abo.fi/~mstorsjo/0001-Make-sure-cur_dts-is-initialized-before-… [21:51:57] <wbs> I guess such things need to go through michael anyway, so I'll post it to the mailing list [21:52:18] <KotH> spaam: rotfl [21:52:49] <spaam> KotH: you cant deny that [21:53:04] <KotH> can someone give me op? i have to kick spaam [21:53:25] <KotH> DonDiego: thanks [21:53:35] <spaam> KotH: <3 [21:53:40] <siretart> DonDiego: this is a maintenance only release. distributors and system integrators are encouraged to update and share their vendor patches against this branch. something like that [21:54:06] <DonDiego> i mean for the RELEASE file [21:54:24] <BBB> feature add is MINOR or MICRO update? [21:54:40] <DonDiego> if you have ideas, go for it, i'm a bit tired and not creative right now.. [21:56:10] <CIA-93> ffmpeg: diego * r23299 /branches/0.5/VERSION: Bump version number for 0.5.2 release. [21:57:03] <siretart> BBB: depends. if it involves new public symbols or enum changes, minor. otherwise, micro [21:57:26] <BBB> it's a new protocol [21:57:30] <BBB> others update minor [21:57:33] <BBB> I'll updat minor [21:58:20] <siretart> yes, that sounds right. [21:58:41] <siretart> DonDiego: as for RELEASE file, I think that's fine. my text is more something for the website [21:58:58] <DonDiego> i used it for RELEASE :) [21:59:09] <DonDiego> i just committed it [21:59:18] <DonDiego> feel free to change it any way you see fit.. [21:59:38] <CIA-93> ffmpeg: diego * r23300 /branches/0.5/RELEASE: release notes for 0.5.2 [22:00:31] <CIA-93> ffmpeg: rbultje * r23301 /trunk/ (6 files in 3 dirs): MMS-over-TCP protocol support. Patch by Zhentan Feng <spyfeng gmail com>. [22:01:32] <kierank> nice mms over tcp [22:01:33] <siretart> DonDiego: yea, I think it's good [22:03:43] <DonDiego> ok, what did we forget then? [22:03:50] <siretart> heh [22:07:32] <BBB> kierank: mms-http (the most-used one) is coming [22:07:39] <KotH> night girls [22:07:40] <BBB> then we can kill libmms [22:08:07] <kierank> I remember spending ages when I had dialup trying to save those mms streams because the 33.6kbps ones looked like crap [22:08:31] <hyc> wbs, bcoudurier: no, something is still wrong. c->cur_pts is an absolute stamp, get_packet_send_clock() returns an absolute time [22:08:39] <hyc> get_server_clock() retur5ns a relative time [22:09:01] <hyc> so that comparison will always result in "it's not time to send a pkt yet" [22:09:40] <BBB> kierank: don't trash it yet... we don't do bitrate negotiation yet [22:09:45] <BBB> kierank: we will, but not yet now [22:12:00] <kierank> I'm talking about problems getting mms to work 10-15 years ago ;) [22:12:14] <bcoudurier> yes it is [22:15:31] <BBB> kierank: oh, I'm affraid I might not be able to help with that ;) [22:17:23] <bcoudurier> get_server_clock return the time passed since ... [22:17:40] <bcoudurier> c->cur_pts is the dts of the packet and that is absolute [22:18:01] <hyc> correct [22:18:20] <hyc> and get_packet_send_clock basically jsut returns c->cur_pts [22:18:35] <hyc> so you cannot compare the result of get_packet_send_clock() to get_server_clock()) [22:20:08] <bcoudurier> you can [22:20:17] <bcoudurier> it's absolute in the _file_ [22:20:42] <bcoudurier> like for mp4 it will be 0, 1, 2, 3, 4, 5 in frame counter at 25, 0, 0.04, 0.08 etc ... [22:20:50] <bcoudurier> for mpeg dts/pts never start at 0 [22:20:57] <bcoudurier> so you substract start_time [22:21:02] <bcoudurier> st->start_time [22:21:11] <bcoudurier> that's the way I understand it [22:21:12] <hyc> hmmmmm [22:21:19] <hyc> I just saw something [22:21:33] <hyc> there are two streams since there is audio+video [22:21:45] <hyc> onely one of them had ist->start_time initialized properly [22:22:27] <hyc> which kind of makes sense - if you only init it on the first packet in a stream [22:22:45] <hyc> the "first packet" can only belong to one stream. the other stream never gets init'd. [22:24:19] <hyc> so whose responsibility is it to initialize start_time ? [22:24:29] <mru> the big bang [22:24:46] <hyc> this is a live feed, so ffmdec? [22:26:07] <bcoudurier> avformat [22:27:45] <hyc> gaahh... //We skip H264 currently because ... [22:28:00] <hyc> so the video stream is not hitting any of this init code because it's H264 [22:44:25] <DonDiego> release done.. [22:44:27] <DonDiego> \o/ [22:46:38] <spaam> \o/ [22:46:44] <Dark_Shikari> 0.6? [22:48:10] <DonDiego> no, 0.5.2 [22:48:18] <DonDiego> a quick point releae [23:06:44] <DonDiego> bcoudurier: you around? [23:08:51] <bcoudurier> yes [23:11:18] <DonDiego> monty has a bug report for your ogg muxer [23:12:11] <DonDiego> i'll cc you on the reply [23:13:48] <bcoudurier> ah cool [23:14:54] <bcoudurier> nope [23:14:56] <bcoudurier> file is valid [23:16:58] <ohsix> as reported by oggz-validate? [23:17:09] <bcoudurier> yes [23:17:28] <bcoudurier> but ok [23:17:32] <bcoudurier> let's be friendly :) [23:17:48] <DonDiego> just answer the mail and keep the list in the cc [23:18:02] <ohsix> does he not post to the ml? [23:18:58] <lu_zero> where is the email? [23:19:25] <DonDiego> foms mailing list [23:19:27] <DonDiego> private [23:20:21] <mru> what's the "bug"? it beats his muxer? [23:21:06] <bcoudurier> the serial number crap [23:21:12] <mru> what of it? [23:21:21] <bcoudurier> I use stream index [23:21:25] <bcoudurier> 0, 1, 2, 3, [23:21:26] <mru> seems sane enough [23:21:31] <mru> he wants it "random" I guess [23:21:34] <DonDiego> "It is still not setting serial numbers on Ogg streams. This should be fixed." [23:21:36] <bcoudurier> yes [23:21:38] <bcoudurier> he wants random [23:21:50] <Dark_Shikari> why [23:21:57] <mru> while (random() != any_of_the_other_numbers) [23:22:00] <ohsix> you cant just append them if the numbers are serial :] [23:22:02] <bcoudurier> yes [23:22:03] <janneg> "0, 1, 2, 3," looks perfectly random to me [23:22:09] <mru> ohsix: you'd still have to check them [23:22:14] <mru> and potentially rewrite [23:22:19] <mru> so there's no difference [23:22:33] <ohsix> potentially to always renders the entire thing moot [23:22:38] <Dark_Shikari> janneg: http://webs.bcp.org/sites/amathurin/images/Dilbert(Random).jpg [23:22:43] <mru> I really, really hate it when people make the idiotic assumption that random implies globally unique [23:22:49] <Dark_Shikari> That's the problem with randomness [23:22:49] <mru> or even locally unique [23:22:52] <Dark_Shikari> You can never be sure ;) [23:23:03] <lu_zero> wbs: poing2 [23:23:04] <ohsix> its not unique, just unlikely; its like a hash but it doesn't chain when theres a collision [23:23:15] <mru> if anyone thinks of a plan to detard xiph, let me know [23:23:16] <janneg> Dark_Shikari: http://xkcd.com/221/ [23:23:18] <Dark_Shikari> ohsix: similarly, assuming that hashes don't collide is rather bad [23:23:24] <Dark_Shikari> CCP did that with EVE Online's filesystem [23:23:31] <Dark_Shikari> then one day, about 5 years after release [23:23:33] <Dark_Shikari> they added one file [23:23:35] <ohsix> you don't assume, the space is large [23:23:35] <Dark_Shikari> and the entire game broke [23:23:43] <Dark_Shikari> There had been a hash collision. [23:24:04] <Dark_Shikari> ohsix: there's a great paper about how assuming that hashes don't collide is stupid, even for a filesystem using 128-bit hashes [23:24:15] <mru> random numbers are hard to predict, but there is _no_ promise of uniqueness [23:24:21] <janneg> Dark_Shikari: 32 bit hash? [23:24:28] <ohsix> Dark_Shikari: it doesn't matter, you misconstrue the intent [23:24:29] <mru> you just don't know _which_ two random numbers will collide [23:24:29] <bcoudurier> yes I have to check them now [23:24:36] <bcoudurier> fuck I'm lazy [23:24:44] <DonDiego> tsk, tsk [23:24:50] <DonDiego> you lazy lout you! [23:25:01] <Dark_Shikari> janneg: CCP's, yes [23:25:02] <ohsix> and it doesn't matter if you assume or not if theres no collision; you merely assure it with the way its muxed by ffmpeg [23:25:15] <mru> assuming 128-bit hashes rarely collide is fine, provided you have a (potentially expensive) way of dealing with it [23:25:25] <ohsix> and its antithetical to the intent behind the numbers [23:25:26] <mru> but in this case there is no difference at all [23:25:33] <mru> ohsix: the intent is retarded [23:25:40] <mru> you still have to check them [23:25:42] <ohsix> thats a difference of opinion [23:25:53] <ohsix> you do, but you're changing the likelyhood [23:25:55] <mru> and if they collide, you must be ready to rewrite them [23:26:14] <mru> so the code is _exactly the same_ [23:26:50] <BastyCDGS> dark_shikari, I'm interested reading the paper regarding assumption of non-hash collisions is stupid [23:26:51] <ohsix> but in practice it is not; you change unlikely to likely and opt for the expensive operation, the files as they are have a stigma of expensive operations [23:27:15] <mru> the hardest part is parsing them to check for collisions [23:27:19] <Dark_Shikari> I _think_ it's [23:27:21] <Dark_Shikari> An analysis of compare-by-hash [23:27:21] <mru> and you're not escaping that [23:27:22] <Dark_Shikari> V. Henson [23:27:25] <Dark_Shikari> from USENIX [23:27:33] <mru> the operation as a whole is io-bound anyway [23:27:37] <Dark_Shikari> BastyCDGS: ^ [23:27:38] <DonDiego> http://www.osnews.com/story/23346/Nero_Files_Antitrust_Case_Against_MPEG-LA [23:27:49] <Dark_Shikari> DonDiego: welcome to a few days ago =p [23:28:02] <ohsix> regardless; you know the intent of the number from the person who created the format [23:28:10] <mru> Dark_Shikari: and the lawsuit is from january [23:28:15] <Dark_Shikari> mru: And yeah, that [23:28:16] <janneg> DonDiego: " [23:28:18] <BastyCDGS> thanks seems be the right [23:28:27] <mru> ohsix: I know the person who created the format is an idiot [23:28:35] <mru> so whatever his intent, it's irrelevant [23:28:43] <ohsix> don't get distracted, you know the intent of the number [23:28:47] <mru> besides, consecutive numbering is valid [23:28:53] <janneg> DonDiego: money quote "absolute power corupted MPEG LA absolutely" [23:28:57] <mru> libogg will happily do it btw [23:29:22] <mru> ohsix: unless the intent was to annoy the hell out of everybody, I really don't know [23:29:34] <mru> that seems to be just about all that idiot is capable of [23:29:48] <ohsix> the intent for them to rarely have collisions and putting files together is a cheap operation [23:30:06] <mru> it's a false sense of fuzzy and warm [23:30:16] <BastyCDGS> if someone else wants to read it: [23:30:16] <mru> but watch out, this kitten has claws [23:30:19] <BastyCDGS> http://valerieaurora.org/review/hash/index.html [23:30:21] <ohsix> it saves work [23:30:25] <mru> does not [23:30:39] <mru> you still have to write all the code to handle a collision [23:30:43] <ohsix> you're assuring that it doesn't by generating all worst case files [23:30:53] <janneg> iirc monty claimed that the intent is to somehow prevent serial clashes on single bit errors [23:31:00] <mru> besides, did anyone _ever_ have a need to concatenate two ogg files? [23:31:05] <ohsix> you don't avoid not writing code to handle collisions, you make it extremely unlikely that it need be done [23:31:26] <ohsix> does that change anything? [23:31:26] <mru> janneg: in that he has a very twisted idea of error resilience [23:31:47] <DonDiego> janneg: yeah, that quote is great [23:31:47] <mru> ohsix: the work is writing the code, not running it [23:31:53] <janneg> random() is a very poor method since it is not very good at it [23:32:11] <ohsix> heh [23:32:29] <janneg> DonDiego: but nothing that I would have expected in in serious law doc [23:32:43] <mru> anyway, if he's complaining about it, why did he allow it in the spec? [23:33:34] <ohsix> thats a red herring [23:33:41] <mru> nope [23:33:42] * lu_zero still wonders why discussing at lenght about it [23:33:42] <ohsix> you know the intent and the method [23:33:45] <mru> the spec is everything [23:33:52] <lu_zero> 1 2 3 4 5 is a perfectly valid random sequence [23:33:57] <ohsix> yep, the very definition of a red herring; with regard to the "bug" [23:34:19] <mru> given the spec, the code is flawless, and he had better shut up [23:34:50] <janneg> how should the serial handled in stream with 2^32 streams? [23:34:57] <mru> if resiliency were the goal, the spec should've required something like no two numbers differing by a single bit only [23:35:23] <janneg> s/stream/files/ [23:35:42] <mru> I doubt they think that big [23:36:03] <mru> and such a file is rather unlikely anyway [23:36:09] <lu_zero> if their idea was to provide a cheap way to "stream" through http using netcat [23:36:21] <mru> lu_zero: in that case they still busted it [23:36:37] <lu_zero> in many different ways =P [23:36:42] <mru> they can't possibly require that all ogg files ever created have unique IDs [23:37:01] <ohsix> "if", you know you can read about it http://people.xiph.org/~xiphmont/lj-pseudocut/o-response-1.html [23:37:03] <mru> unless they didn't envision a very widespread adoption [23:37:16] <mru> ohsix: is that supposed to be funny? [23:37:33] <janneg> yes, but if uniquess is their goal why not using 16bit serials and a 16 bit hash of it [23:37:51] <mru> retards? [23:38:25] <CIA-93> ffmpeg: bcoudurier * r23302 /trunk/libavformat/oggenc.c: In ogg muxer, use random serial number of each ogg streams [23:38:46] <ohsix> i think the point on the elementary stream numbers is prophetic [23:39:00] <lu_zero> hmm [23:39:09] <bcoudurier> I need yuvi for the upper limits blah blah [23:39:11] <mru> I think it's pathetic [23:39:13] <Dark_Shikari> mru: I think you're missing the point wrt abiding by stupid specs [23:39:20] <Dark_Shikari> If the spec says something retarded [23:39:23] <Dark_Shikari> the best thing is to obey it [23:39:25] <bcoudurier> I don't maintain vorbis/theora wrappers [23:39:27] <Dark_Shikari> because that means if something breaks as a result [23:39:30] <Dark_Shikari> You can blame someone else. [23:39:31] <mru> Dark_Shikari: we _are_ obeying the spec [23:39:38] <mru> it's the idiot who's claiming we're not [23:39:45] <Dark_Shikari> in this case, the spec is xiphmont's head [23:39:55] * mru shoots monty [23:39:57] <mru> not anymore [23:40:02] <lu_zero> it's leaking now [23:40:05] <lu_zero> even worse [23:40:09] <Dark_Shikari> haha [23:40:11] <janneg> Dark_Shikari: that doesn't scale [23:40:17] <Dark_Shikari> janneg: sure it does [23:40:34] * lu_zero meanwhile tries to decode Michael suggestion about the reordering in rtp [23:41:02] <bcoudurier> janneg, [23:41:08] <bcoudurier> your patch is ok for encoding [23:41:16] <Dark_Shikari> <pengvado> are there any devices that support 25 mbit high profile (L4.0), but don't support 25mbit main profile (L4.1) ? [23:41:19] <bcoudurier> it should be applied [23:41:19] <Dark_Shikari> <Dark_Shikari> no idea, but its easier to blanket-apply the rule to everything than to special-case [23:41:23] <Dark_Shikari> <Dark_Shikari> you can never go wrong by abiding by the spec, since if someone breaks the spec you can just blame them instead [23:41:26] <Dark_Shikari> <pengvado> fair enough. I'll allow the patch on the premise of passing the blame. [23:41:29] <Dark_Shikari> there's the relevant quote :) [23:41:30] <ohsix> you're just generating worst case degenerate files in all cases with respect to the elementary stream number [23:41:47] <mru> ohsix: I don't fucking care [23:42:00] <mru> there is no difference in any relevant use-case [23:42:03] <mru> and the code is simpler [23:42:28] <ohsix> your use cases don't involve using ogg at all so what is that supposed to mean? [23:42:47] <janneg> bcoudurier: I'm not so sure, I'm looking atm at ffmpeg.c and it seems to use avcodec_find_encoder_by_name to get a codec id and uses it later to open the codec [23:43:08] <bcoudurier> what ? [23:43:21] <bcoudurier> there is no codec name by default [23:43:31] <bcoudurier> anyway I need to reboot, brb [23:49:09] <janneg> bcoudurier: no, it doesn't. I've missed the "output_codecs[nb_ocodecs] = codec;" [23:49:25] <janneg> codec is the result of avcodec_find_encoder_by_name [23:49:53] <bcoudurier> so ? [23:49:56] <janneg> bcoudurier: why do you think it should not be added for decoders? [23:50:16] <bcoudurier> because av_find_stream_info will have side effects [23:50:53] <janneg> I don't think we have currently an experimental decoder and I don't expect any [23:51:51] <janneg> for new decoder development it has the same side effect as the alphabetical order of decoders in allcodecs.c [23:52:11] <peloverde> ffaacdec is less feature complete than libfaad2 but is also faster and less buggy [23:52:31] <mru> peloverde: what's the holdup with PS? [23:53:00] <peloverde> It's being reviewed now, see ffmpeg-devel and ongoing changes in git [23:53:12] <mru> is anything else missing? [23:53:24] <peloverde> Even then we are still missing ER and the features no one uses [23:53:31] <peloverde> (LTP, SSR) [23:53:38] <Dark_Shikari> wait I thought we had LTP? [23:53:45] <mru> so nothing that matters then [23:53:52] <peloverde> Apparently there us LTP in the soc branch [23:53:56] <mru> and nobody will be sad if we drop libfaad support? [23:54:21] <peloverde> I thought main didn't matter until I saw it in use in hulu [23:54:32] <peloverde> LTP is trivial [23:54:48] <peloverde> LD requires ER syntax and is apparently used in some applications [23:54:48] <janneg> anyone writing a new decoder is free to omit CODEC_CAP_EXPERIMENTAL while he is writing it and should be able to disable the non experimental codec through configure if needed [23:55:27] <lu_zero> hmm [23:55:48] <janneg> bcoudurier: I think inconsistent behaviour for avcodec_find_decoder|encoder is bad [23:55:54] <ohsix> hey speaking of hulu, its working on x86_64 (w/64bit flash) again [23:56:10] <peloverde> is make ever going to update 64-bit flash? [23:56:21] <peloverde> or has it been abandoned? [23:56:25] <peloverde> s/make/Mike/ [23:56:37] <bcoudurier> it's _different_ [23:57:07] <bcoudurier> there is no problem in being _different_ [23:57:13] <janneg> bcoudurier: I would prefer to to add a comment to #define CODEC_CAP_EXPERIMENTAL that marking decoders as exprimental can have unintended side effect for example in av_find_stream_info [23:58:16] <ohsix> peloverde: dunno but i'm pretty darn happy with the one thats available, its still updated unter the "alpha" or "beta" or whatever moniker they use for it, but it hadn't been for like 4months last time i checked [23:58:39] <ohsix> for calling it alpha its pretty solid; but i've never had flash crash anything :[ [23:58:43] <hyc> ohsix: you mean you updated your 64 bit flash plugin? or hulu changed something? [23:58:59] <ohsix> hyc: software unchanged, hulu must have done something

1 0

IRC log for 2010-05-23
by irc＠mansr.com 23 May '10

23 May '10

[13:21:15] * Terminating due to: TERM [13:21:28] * /join #ffmpeg-devel ... [13:21:30] *** TOPIC: Welcome to the FFmpeg development channel. That is, development of FFmpeg, not using FFmpeg, nor libav*. | Users should redirect their questions to #ffmpeg | FFmpeg 0.5.1 has been released! | this chat is now publicly logged. [13:21:30] *** TOPICINFO: superdump!~rob@unaffiliated/superdump, 1267604523 [13:21:40] <BastyCDGS> doesn't seem to ;) [13:22:34] <Vitor1001> lol [13:25:31] * Vitor1001 kicks CIA-93 [13:25:33] <CIA-93> ow [13:25:43] <BastyCDGS> didn't said it? he's still alive and loud :D [13:26:03] <BastyCDGS> oh why it's 93 now and not 7 anymore? [13:26:33] <Vitor1001> Should be random every time it logs in, probably to avoid nick clashing in freenode... [13:27:33] <BastyCDGS> I just remember that it was always 7 in the past at least from the time on where I was joining FFmpeg [13:35:38] <BastyCDGS> btw, I need an account for: ftp://upload.mplayerhq.hu/incoming I just can use: ftp://anonymous@upload.mplayerhq.hu/MPlayer/incoming [13:41:29] <CIA-93> libswscale: stefano * r31192 /trunk/libswscale/swscale.h: [13:41:29] <CIA-93> libswscale: Add empty newline to separate function declarations, for better [13:41:29] <CIA-93> libswscale: readability. [13:47:26] <_av500_> KotH: there will be good chinese food! [13:48:13] <BastyCDGS> av500, who I can ask for a FTP account? [13:48:21] <_av500_> BastyCDGS: anonymous works for me [13:48:30] <_av500_> whats the issue? [13:48:42] <BastyCDGS> the thing is that the folder I created disappears after some minutes and I can't access it anymore [13:48:53] <_av500_> mkdir folder [13:48:55] <_av500_> cd folder [13:48:55] <BastyCDGS> I think it's moved from MPlayer/incoming to /incoming [13:48:56] <_av500_> put [13:49:31] <BastyCDGS> it doesn't seem to work with anon in /incoming [13:49:38] <_av500_> it works for me [13:50:02] <BastyCDGS> as said some few minutes everything is normal but then the folder disappears with all files in it [13:50:06] <BastyCDGS> I know it's still lthere [13:50:12] <BastyCDGS> since I can't recreate the folder [13:50:27] <BastyCDGS> I'm using FTP kio slave from KDE as well as filezilla [13:50:53] <_av500_> BastyCDGS: yes, the folder is there [13:51:01] <_av500_> so you uploaded the files [13:51:08] <BastyCDGS> one is still uploading [13:51:08] <_av500_> so what is the issue? [13:51:16] <BastyCDGS> that I can't update the folder anymore etc. [13:51:33] <_av500_> what are all these files you upload? [13:51:49] <BastyCDGS> for testing & compiling TuComposer [13:52:15] <BastyCDGS> it contains the complete development environment for amiga since TuComposer today just builds on that [13:52:24] <BastyCDGS> for the upcoming MOD support in ffmpeg [13:52:27] <_av500_> and why to mplayer? [13:52:41] <_av500_> few ffmpeg devs work on amigas [13:52:51] <BastyCDGS> was recommended by me at very first day I was in #ffmpeg-devel [13:53:04] <BastyCDGS> although not MPlayer [13:53:15] <_av500_> but the src code is available on your website, no? [13:53:17] <BastyCDGS> but /incoming w/o MPlayer demands auth from me [13:53:35] <BastyCDGS> yes but not the amiga development environment as well as lots of test files [13:53:49] <_av500_> but who is supposed to use all that? [13:54:04] <BastyCDGS> stefano wanted to take a look onto it [13:54:50] <_av500_> ah ok [13:55:30] <BastyCDGS> he's my mentor ;) [13:55:59] <BastyCDGS> btw, could you give me the FTP url that works for you? [13:57:03] <_av500_> upload.ffmpeg.org [13:57:47] <BastyCDGS> still doesn't work :( [13:57:56] <BastyCDGS> tried ftp://upload.ffmpeg.org/incoming [13:58:47] <_av500_> http://www.ffmpeg.org/bugreports.html [13:59:00] <mru> incoming is write-only [14:00:18] <peloverde> The password is easily findable on the web if one is clever [14:03:20] <BastyCDGS> mru, yes but when the folders disappear I can't even blindly upload any files to my created folder [14:03:48] <mru> you can cd even if you can't see it [14:04:00] <BastyCDGS> I tried that it returns error [14:04:14] <BastyCDGS> maybe it's a KIO slave issue but also happens with filezilla [14:04:23] <peloverde> Try a commandlien client [14:04:50] <peloverde> eg lftp or ncftp [14:06:12] <BastyCDGS> basty@cdgs-basty:/var$ lftp upload.ffmpeg.org [14:06:12] <BastyCDGS> lftp upload.ffmpeg.org:~> [14:06:12] <BastyCDGS> lftp upload.ffmpeg.org:~> ls [14:06:12] <BastyCDGS> drwxrwsr-x 11 0 1004 4096 Mar 05 22:23 MPlayer [14:06:12] <BastyCDGS> drwx------ 2 0 0 16384 Dec 09 2005 lost+found [14:06:13] <BastyCDGS> lftp upload.ffmpeg.org:/> cd MPlayer/incoming/AMIGA [14:06:13] <BastyCDGS> cd: L'accès a échoué : 550 Failed to change directory. (/MPlayer/incoming/AMIGA) [14:06:14] <BastyCDGS> lftp upload.ffmpeg.org:/> cd incoming/AMIGA [14:06:14] <BastyCDGS> cd: L'accès a échoué : 550 Failed to change directory. (/incoming/AMIGA) [14:06:15] <BastyCDGS> lftp upload.ffmpeg.org:/> [14:07:02] <BastyCDGS> AMIGA is the directory I'm right uploading now and that disappeared after some minutes [14:08:56] <mru> try again, but hurry [14:09:35] <BastyCDGS> cd ok merci [14:10:34] <BastyCDGS> lftp upload.ffmpeg.org:/MPlayer/incoming/AMIGA> put ~/Desktop/ROMS.7z.txt [14:10:34] <BastyCDGS> put: L'accès a échoué : 553 Could not create file. (ROMS.7z.txt) [14:10:41] <BastyCDGS> damn upload and ls still doesn't work [14:12:16] <mru> now then [14:13:05] <BastyCDGS> transfer successful [14:13:08] <BastyCDGS> but still no ls [14:13:13] <BastyCDGS> what is the issue with that? [14:13:13] <mru> that's intentional [14:13:18] <mru> I said it's write-only [14:13:34] <BastyCDGS> but when I created it and uploaded the first files a ls did work [14:13:45] <mru> you got lucky [14:13:55] <BastyCDGS> well, after all I have now all files [14:14:02] <BastyCDGS> except the WB39.7z [14:14:07] <BastyCDGS> but this is still uploading [14:14:25] <BastyCDGS> @ 25% [14:14:53] <_av500_> you are uploading all amiga warez you have? ;) [14:15:16] <BastyCDGS> nope 90% of these are TuComposer Modules as well as the original mod/s3m/xm/it files [14:18:10] <BastyCDGS> there's a FFmpeg.txt on the workbench screen which you should read, it contains basic amiga UI stuff and compile HOWTO of TuComposer [14:27:42] <BastyCDGS> I will finish now the patches from last weekend [14:45:19] <KotH> _av500_: chinese food is overrated [14:46:12] <_av500_> KotH: iKnow [14:46:23] <mru> are you comparing the amiga to chinese food? [14:48:59] <BastyCDGS> mru, funny how do you come to the idea he could compare cf to amiga? [14:49:15] <mru> he said it was overrated... [14:49:29] <_av500_> some is even overheated [14:49:37] <mru> and full of MSG [14:49:37] <kierank> what is so brilliant about the amiga? [14:49:50] <KotH> it was ahead of it's time [14:49:57] <KotH> 30 years ago [14:50:10] <BastyCDGS> kierank can you image that a full-featured multitasking OS was able to run smooth in 1986 with a 7MHz CPU [14:50:12] <mru> the amiga is a fixed point in time [14:50:16] <mru> c. 1988 [14:50:24] <mru> before that, it was ahead of its time [14:50:27] <mru> after, well... [14:50:41] <BastyCDGS> yes with the approach of pentium the amiga lost [14:50:41] <kierank> 22 years later, what is so brilliant about it? [14:50:46] <KotH> nowadays i have a cell phone that has higher computation power, better graphics, higher resolution screen, more memory than my pc 10y ago [14:50:56] <mru> sun was making m68k-based Unix workstations well before that [14:51:03] <mru> far more powerful than any amiga [14:51:17] <_av500_> they used them to develop amiga afaik... [14:51:25] <KotH> BastyCDGS: have you ever heard of the pdp-11? [14:51:31] <BastyCDGS> pdp-11? no [14:51:35] <mru> rotfl [14:51:45] <KotH> BastyCDGS: it was running a full featured unix on a 8bit processor [14:51:56] <BastyCDGS> cewl [14:52:09] <spaam> mru: do you own an amiga? [14:52:14] <KotH> oops.. sorry, 16bit [14:52:33] <kierank> 16-bit sounds more realisitc [14:52:38] <kierank> realistic* [14:52:51] <_av500_> we were once an amiga company... [14:53:07] <BastyCDGS> av500, really...which one? [14:53:19] <_av500_> archos ,ade cdrom for amiga [14:53:20] <KotH> kierank: there were unix systems implemented on 8 bit machines [14:53:24] <_av500_> made [14:53:54] <mru> isn't that like fitting afterburners on a model T Ford? [14:54:02] <BastyCDGS> mru, what made these m68k SUN stations so special that they were far ahead from the amiga? [14:54:15] <KotH> mru: if the model t can fly after that, why not? [14:54:17] <mru> they ran SunOS [14:54:35] <mru> not a dinky toy OS only capable of simple games and "demo scene" material [14:54:38] <BastyCDGS> don't know SunOS so I can't compare that to AmigaOS [14:54:46] <mru> it's a full Unix [14:54:52] <BastyCDGS> lol the OS from the amiga was never used for games and demo scene stuff [14:54:57] <_av500_> mru: who cares, it made monex [14:55:29] <BastyCDGS> apart from user/group permissions amigaos could do almost everything that unix can do [14:55:39] <KotH> BastyCDGS: could it be that you are new to computers? [14:55:55] <BastyCDGS> if you consider since 1986 as new...yes [14:56:40] <KotH> BastyCDGS: new as in "has not seen anything but a single niche of computers" [14:56:40] <BastyCDGS> but this was a Plus 4...I got my A500 in 1988 [14:57:43] <BastyCDGS> amiga wasn't a niche during that time, it was the most widespread home computer besides the C64 [14:58:07] <KotH> s/niche/class/ if you want to be pedantic [14:58:15] <mru> KotH: http://www.snopes.com/autos/dream/jato.asp [14:58:24] <kierank> BastyCDGS: you haven't answered my question yet [15:50] <kierank> 22 years later, what is so brilliant about it? [14:58:56] <KotH> mru: knonw [14:58:59] <KotH> mru: known [14:58:59] <_av500_> that it was brilliant back then [14:59:07] <BastyCDGS> kierank, nothing really as I said already, since the arrival of pentium the amiga got behind [14:59:33] <mru> KotH: you asked if the model T would fly... [15:01:19] <BastyCDGS> kierank, I also don't have experience with today's PPC based amigas...so I can't really tell how brilliant they are, but from what I read, they're most like today PCs with no custom chips, so I wouldn't probably buy one... [15:01:49] <BastyCDGS> AmigaOS 4 is probably fine, but I doubt hardly that it can kill any recent Linux [15:02:19] <spaam> can you run AmigaOS 4 on x86 ? [15:02:43] <mru> of course not [15:03:01] <BastyCDGS> porting it could be pretty easy (HAL stuff) but as far as I know there's no x86 port [15:03:08] <BastyCDGS> but you can use AROS instead for x86 [15:03:31] <mru> or you can grow up and run linux [15:03:46] <BastyCDGS> yes that's what I do now ;) [15:04:17] <kierank> BastyCDGS: how many people are in CDGS? [15:04:23] <BastyCDGS> just me [15:04:24] <mru> later, some people suffer a mid-life crisis in which they fork another bsd [15:05:16] <BastyCDGS> kierank, hadn't really dealed with CDGS itself the last years...was just too busy with other stuff [15:05:21] * _av500_ must fork a bsd then [15:05:39] <Gottaname> this channel is way more lively than #ffmpeg [15:05:40] <_av500_> av-bsd [15:05:41] <Gottaname> :( [15:05:42] <BastyCDGS> hehe, everyone of us NOW forks a bsd :D [15:06:07] <_av500_> Gottaname: its sunday afternoon [15:06:39] <Gottaname> I'm mean, not to sound too demanding or something, I'm almost at wits end asking for help in the other channel... [15:06:40] <Gottaname> :( [15:07:31] <KotH> that's because we talk here about amiga and not about ffmpeg [15:07:44] <_av500_> whats ffmpeg anyway? [15:07:58] <KotH> something that uau has not forked yet [15:08:11] <spaam> haha [15:08:19] <Gottaname> is he around? [15:08:20] <spaam> do you think he will fork ffmpeg? ;) [15:08:23] <mru> has he forked bsd? [15:08:27] * Gottaname notes he comes for the bittornado channel [15:08:38] <KotH> "es wird empfohlen laufende programme vor der installation zu beenden" WTF? this is fucking unix! [15:08:57] <_av500_> u run german locale? [15:09:05] <BastyCDGS> It is recommended to terminate running programs before doing install [15:09:08] <KotH> _av500_: german software [15:09:13] <mru> we speak german [15:09:15] <BastyCDGS> just translated it for anybody not speaking german here [15:09:17] <iive> spaam: he would fork ffmpeg-mt [15:09:24] <_av500_> BastyCDGS: only a few [15:09:24] <KotH> spaam: ofc he will, as soon as he is dissatisfied with the development of ffmpeg [15:09:46] <_av500_> iive: ffmpeg-mt forsk itself, no? [15:10:11] <iive> well, having more forks in the fork doesn't fork^Whurt [15:10:14] <Gottaname> anyway, nobody to help newbies with using the ffmpeg libavcodec in the other channel? [15:10:19] <KotH> BastyCDGS: dont worry about translation. this channel speaks fluently german, swedish, japanese and arm assembler [15:10:21] * Gottaname is sadded [15:10:52] <KotH> Gottaname: only if you get atmel fix the bugs in their USB core [15:11:04] * BastyCDGS neither speaks / understands swedish and japanese [15:11:07] <KotH> or at least admit they have bugs [15:11:42] <_av500_> and he does usefull stuff more years and u will... [15:11:48] <_av500_> err [15:11:49] <KotH> "falls auf ihrem rechner ein virenscanner aktiviert ist (z.B. Norton Antivirus)...." ??? [15:11:50] <_av500_> undo [15:11:59] <BastyCDGS> av500, lol and this on linux [15:12:03] <BastyCDGS> wine Norton.exe :D [15:12:41] <_av500_> KotH: pray tell what sw is that? [15:13:41] <KotH> _av500_: very shitty ported software, as it seems [15:14:18] <_av500_> KotH: ramdoubler will not help you on linux [15:14:19] <BastyCDGS> I guess the wanted to know the name of that piece of sh^Hsoftware... [15:15:02] <Evgeny> hi all! [15:15:14] <KotH> salom [15:15:40] * _av500_ starts a fire... [15:16:11] <BastyCDGS> hi evgeny [15:16:19] * BastyCDGS sits to the fire [15:16:23] <Evgeny> shalom :) how can i generate cookie in ffmpeg code? is it special option? [15:16:35] <spaam> _av500_: going to eat BastyCDGS ? ;D [15:17:47] <BastyCDGS> damn you must be really hungry then ;) [15:18:38] <Gottaname> okay guys, anyone knowes who coded api-example.c> [15:18:45] <Gottaname> in libavcodec? [15:18:49] * BastyCDGS cuts a bit of fresh flesh from himself and then reprograms his DNA to recreate that missing part quickly [15:19:07] <spaam> Gottaname: did you read the log for that file? :) [15:19:53] <spaam> Gottaname: svn log libavcodec/api-example.c | less [15:20:07] <Evgeny> :'( anyone, please, help me [15:21:03] <KotH> Evgeny: you're aware that this is the ffmpeg development channel and not the "how do i use ffmpeg" channel? [15:21:49] <Evgeny> yes, i use ffmpeg channels [15:22:13] <Gottaname> spaam: read it [15:22:15] <Evgeny> but i trying to create RTSP over HTTP [15:22:25] <Gottaname> also, it appears I'm not the first one reporting it [15:22:32] <Evgeny> and i need cookie there [15:22:39] <votz> DonDiego: ping [15:22:52] <wbs> Evgeny: trying to "create", as in, implementing it? [15:22:55] <DonDiego> votz: pong [15:23:08] <DonDiego> votz: what did i miss? [15:23:08] <Evgeny> yes, implementing [15:23:12] <votz> DonDiego: hey qt [15:23:20] <votz> a few people in #ffmpeg have run into trouble with api-example.c [15:23:22] <wbs> Evgeny: well, just add a cookie header to the http requests you make then? [15:23:34] <DonDiego> why does that concern me? :) [15:24:09] <votz> DonDiego: your poor name was on api-example.c's history ;) [15:24:11] <votz> someone set you up the bomb [15:24:23] <DonDiego> it seems [15:24:24] <_av500_> DonDiego: you fixed all the spelling in that file [15:24:36] <votz> I just thought I'd bring it to your attention if you weren't already aware [15:24:56] <DonDiego> that's not my area, go look for someone else :) [15:25:06] <Gottaname> problems is semantic, not syntax [15:25:16] <Gottaname> the probkem* [15:25:44] <Gottaname> pardon my bad spelling, my left wrist maybe fractured [15:25:52] <Gottaname> going to the doctor's tommorrow for a x-ray... [15:26:02] <votz> DonDiego: who else should I bother? :) [15:26:17] <DonDiego> go for any other op around here :) [15:26:37] <Gottaname> direct us to the person so that we may continue burning torches and wielding pitchforks in that person's direction. [15:26:44] <Evgeny> <@wbs> ok. i'll try. [15:27:36] <votz> Gottaname: ah, I see youre in here anyhow [15:28:19] <Gottaname> well, I don't mind lurking around, but its like 11:30pm here in singapore [15:28:38] <wbs> noone of you have yet said what the problem is with output-example.c yet [15:28:46] <Gottaname> there's no problem with it [15:28:51] <Gottaname> that's the funny thing [15:29:05] <Gottaname> everything else works EXCEPT that particular function [15:29:35] <wbs> which function is that? [15:29:43] <votz> wbs: talk to Gottaname. I was just playing carrier pidgin on this one :) [15:30:38] <Gottaname> avcodec_decode_audio3 [15:30:53] <Gottaname> in the audio_decode_example [15:31:14] <Gottaname> http://ffmpeg.pastebin.com/vF7xxAqd <- error [15:31:17] <Gottaname> no args [15:34:37] <wbs> I'll have a look [15:34:52] <Gottaname> thanks [15:35:31] <CIA-93> ffmpeg: reimar * r23258 /trunk/libavcodec/avcodec.h: Document CODEC_FLAG_EMU_EDGE and avcodec_align_dimensions interaction. [15:37:27] <_av500_> api-example should be FATE tested... [15:39:50] <lu_zero> yawn [15:40:51] <lu_zero> where is hosted ffmtech website and how has a way to push stuff there? [15:45:13] <BastyCDGS> hey jai :) [15:45:16] <BastyCDGS> how are u? [15:47:04] <jai> hello BastyCDGS [15:48:17] <BastyCDGS> sorry I had been inactive last week but had to do the exams work [15:48:30] <BastyCDGS> had to develop a complete software with devel/user manual from last mon - fri [15:52:43] <DonDiego> has anybody else received mail from admin(a)mp3rocket.net, subject "FFMPEG Consultant Desired" and asking about audio to MP3 conversion? [15:54:22] <lu_zero> I didn't [15:56:04] <Compn> not i [15:56:37] <BastyCDGS> me neither [15:58:46] <_av500_> there is money in audi0o to mp3 conversion? [15:58:53] <_av500_> -0 [15:59:06] <wbs> it's quite advanced, not many people know how to do that nowadays [15:59:08] <DonDiego> i have my doubts.. [15:59:09] <wbs> ;P [15:59:13] <BastyCDGS> a lot of money...when you get sued from RIAA etc. ;) [16:00:16] <jai> where is the RIAA nowadays anyway, i'd have expected them to sue grooveshark [16:00:23] <_av500_> BastyCDGS: riaa is not picky, they sue for any encoding std, mabe not if your convert brtittny to .mod though.. [16:00:35] <jai> _av500_: ouch :) [16:00:42] <BastyCDGS> my poor ears :D [16:01:20] <BastyCDGS> we should get pain money for listening to britney & co. ;) [16:01:25] <BastyCDGS> not the other way around :P [16:01:32] <jai> is it just me having all these problems with ffplay after avfilter support [16:01:50] <BastyCDGS> what problems you have with ffplay? [16:02:16] <jai> quite a few [16:02:33] <jai> crashes, borked output etc [16:02:59] <BastyCDGS> well IFF crashes with enabled avfilter too ;) [16:03:08] <BastyCDGS> do you have any idea, what's wrong there? [16:03:51] <jai> BastyCDGS: that one is because you are trying to call get_buffer during init [16:04:06] <BastyCDGS> is that illegal? [16:04:13] <BastyCDGS> where I should put it instead? [16:05:09] <jai> BastyCDGS: ideally, do that in decode_frame [16:05:31] <jai> but i haven't looked at the code in detail, so i dont know what, if anything, prevents that [16:05:40] <BastyCDGS> funny...in decode frame it does reget_buffer again [16:05:40] <BastyCDGS> so I just probably can remove the getbuffer in init and replace reget_buffer in these with get_buffer? [16:05:50] <jai> yeah [16:05:59] <BastyCDGS> I'll try this out, if it works I will submit a patch [16:06:22] <jai> it might still crash :) [16:06:28] <jai> (if you use reget buffer) [16:06:49] <BastyCDGS> I said will replace reget_buffer with get_buffer so there won't be any reget_buffers then anymore ;) [16:06:55] <jai> oh [16:08:04] <BastyCDGS> after all it gets the buffer twice as it is implemented now [16:08:52] <BastyCDGS> hmm get segfault now [16:09:52] <DonDiego> btw, does anybody know of a FOSS project with an invite-only dev mailing list? [16:10:01] <Dark_Shikari> for reading or writing? [16:10:07] <DonDiego> both [16:10:11] <Dark_Shikari> glibc has one invite-only write mailing list [16:10:13] <Dark_Shikari> but anyone can read [16:13:54] <BastyCDGS> jai, it seems the problem is that init also calls ff_read_cmap_palette [16:14:03] <BastyCDGS> which expects frame to be initialized so I move that too [16:17:13] <BastyCDGS> yeah it was the cmap_read stuff and it still works having that only in decode_frame [16:17:19] <BastyCDGS> now I rebuild with --enable-avfilter ;) [16:34:31] <BastyCDGS> IFF works with avfilter enabled!!!!!!!!! YEAH!!! [16:35:14] <spaam> \o/ [16:35:18] <ramiro> isn't avfilter enabled by default now? [16:36:04] <BastyCDGS> yes but IFF crashed always with enabled avfilter ;) [16:36:13] <BastyCDGS> so I had do build with disable-avfilter up to now [16:36:19] <BastyCDGS> will prepare the patch and submit :) [16:36:34] <ramiro> shouldn't you get started on your actual gsoc project? [16:37:47] <spaam> how many gsoc students does ffmpeg have? [16:38:05] <BastyCDGS> ramiro, tomorrow [16:38:19] <BastyCDGS> that's the reason I'm uploading the amiga stuff for tucomposer [16:38:37] <ramiro> spaam: http://wiki.multimedia.cx/index.php?title=Summer_of_code [16:39:26] <spaam> ramiro: ty [16:39:30] <jai> BastyCDGS: good for you [16:39:43] <jai> now if only we could fix the rest... [16:39:55] <BastyCDGS> jai, what's good to me exactly? [16:40:08] <jai> BastyCDGS: ilbm works [16:42:12] <BastyCDGS> patch submitted to ml [16:45:45] <BastyCDGS> jai, I will then close the issue regarding this, ok? [16:45:57] <BastyCDGS> or at least mark as patch available [16:45:59] <wbs> BastyCDGS: not until the patch has been committed [16:46:22] <BastyCDGS> then I just attach the patch there, ok? [16:46:32] <wbs> yes, that's better [16:47:41] <jai> BastyCDGS: if you are feeling lazy, then just wait for it to be committed, and close it [16:47:43] <BastyCDGS> btw, as a side effect the bad aspect ratio stuff is also fixed with enabled avfilter ;) [16:47:51] <BastyCDGS> there's no black border anymore with the IFF images [16:47:55] <jai> i doubt anyone tracks issues at that granularity [16:50:08] <BastyCDGS> https://roundup.ffmpeg.org/issue1895 [16:58:04] <DonDiego> what's the status of the vp8/webm stuff? [16:58:09] <DonDiego> everything merged already? [16:58:49] <peloverde> WebM demux is merge [16:58:53] <peloverde> nothing else is [16:59:12] <DonDiego> k, thx [16:59:17] <peloverde> well except for the CODEC_ID stuff [16:59:40] <DonDiego> peloverde: when do you expect to finish PS? [17:00:00] <peloverde> It depends on how long review takes [17:00:02] <DonDiego> and what's the further roadmap for obsoleting libfaad? :) [17:00:39] <peloverde> faad supports LTP and some of the ER AOTs [17:02:38] <Compn> arg i forgot to ask sesse to upload his cfdecode2.ax [17:03:42] <peloverde> We are missing SSR, LTP, ER_LC, ER_LTP, and ER_LD [17:04:10] <peloverde> Of those probably only ER LC and ER LD matter [17:07:22] <DonDiego> do you plan to implement them (eventually)? [17:08:06] <peloverde> maybe LTP, because it is simple and non invasive [17:08:51] <peloverde> but I don't think I've ever encountered LTP in the wild [17:13:34] <wbs> Gottaname: for what it's worth, apiexample.c seems to have been broken since rev 9144, 27 may 2007 [17:14:41] <Gottaname> wbs: crap [17:14:52] <Gottaname> wbs: any way of getting it to work again? [17:15:06] <wbs> I'm not sure how the audio decoding really is intended to work there [17:15:58] <Gottaname> alot of ffmpeg tutorials point to using api-example.c as a guide for development... [17:16:04] <wbs> it writes encoded data to a file without any framing, and then reads arbitrarily sized chunks out of it and feeds it to the decoder. the last frame of the buffer will be cut off, and you get a decoding error [17:16:31] <Gottaname> no wonder [17:16:31] <wbs> well, it shows the basics, but for most audio codec, the file format needs to provide some kind of framing [17:16:37] <jai> better use ffmpeg.c as a reference ;) [17:17:02] <wbs> so if you just ignore the decoding error of the last half frame in each buffer read from disk, you get the picture of how it's supposed to work [17:17:05] <Gottaname> wbs: so the last frame is cut off, anyway of forcing it to read the last frame? [17:18:10] <Gottaname> wbs: input buffer is about 4600ish [17:18:23] <wbs> Gottaname: uhm.. well, you could increase the buffer size so that you read the whole file at once [17:18:23] <Gottaname> oh wait, that's the output [17:18:29] <Gottaname> the input is set at 4096 [17:18:46] <Gottaname> wbs: do away with the while loop? [17:19:04] <wbs> if you read partial data from a file, you'd need to provide proper framing, that is, read full frames from disk (or feed them through a parser, if one exists for that format) [17:20:02] <wbs> so one way to fix that would be to redesign it to write e.g. each frame to a separate file [17:20:16] <Gottaname> wbs: is it a major redesign? [17:20:40] <wbs> nah, it isn't that big a change I think [17:21:20] <Gottaname> I'm technically n00b at this... the api-example.c was supposed to give a refernece point... [17:21:21] <Gottaname> hmmm [17:21:30] <Gottaname> no chance of it being fixed anytime soon? [17:22:15] <wbs> can't give any promise [17:22:48] <wbs> but I can try to write a mail to ffmpeg-devel with a short analysis of it, with a question to michael (or someone else who's authoritive on that part) on how to fix it [17:22:50] <Gottaname> hmm, so the current generation of avcodec_decode_audio3 [17:23:25] <Gottaname> wbs: that would help [17:23:27] <wbs> but if you just want to learn how the API works, the code is a good starting point nevertheless [17:23:39] <Gottaname> yeah, but it doesn't do much good if it doesn't work [17:23:59] <wbs> yes, it does work, it just fails after a while [17:24:13] <wbs> I'll try to explain it slowly [17:24:38] <Gottaname> try to be abit patient since its 1:20am here, I might not be thinking so clearly... [17:24:47] <wbs> you've got a number of compressed frames written to the file. generally, you don't know the size of a compressed frame [17:24:59] <wbs> depending on format, you may need more or less a full decoder to know how long a frame is [17:25:17] <Gottaname> each frame is specific to its own format right? [17:25:18] <wbs> so therefore, you _normally_ write frames to disk using some container format, that clearly says how many bytes each frame is [17:25:21] <wbs> yes [17:25:33] <Gottaname> this is going to be painful... [17:25:40] <Gottaname> okay [17:25:46] <wbs> so then you can read out exactly one frame at a time [17:25:48] <Gottaname> assuming MP3 [17:26:03] <wbs> or for some formats, you may get multiple frames at a time [17:26:19] <wbs> then you pass this frame (or this packet containing many frames) to a decoder, which decodes one frame at a time from the buffer [17:26:37] <Gottaname> audio decode takes in a context, the input buffer, the output buffer [17:26:38] <wbs> this returns how many bytes it did output and how many bytes it consumed from the buffer [17:27:05] <Gottaname> I assume that would be the last part of the arguements taken in [17:27:16] <Gottaname> namely &pktavc or something [17:27:19] <Gottaname> at the end right? [17:27:29] <wbs> that's the input compressed data [17:28:24] <wbs> the problem with api-example.c is that it reads an arbitrary amount of data from the file, and pass it to the decoder. first it successfully decodes one frame at a time, about 18 times [17:28:43] <wbs> then you've only got partial data for the 19th frame, since you just read 4096 bytes from file [17:28:46] <Gottaname> yeah, but it isn't accurate isn't it? [17:29:12] <Gottaname> wbs: I assume similiar to SDL buffering? [17:29:53] <Gottaname> so this partial frame, I have to shrink the output buffer for it right? [17:31:09] <wbs> no, no.. no.. [17:31:40] <_av500_> no [17:31:54] <wbs> as a purely fictional example, lets say each of the compressed frames are about 220 bytes long [17:32:12] <wbs> frame 1 is at bytes 0-219, frame 2 at 220-439 in the file, etc [17:32:21] <wbs> you read bytes 0-4095 from file, and feed them to the decoder [17:32:39] <wbs> the decoder first decodes the first 220 bytes and outputs the corresponding uncompressed audio data [17:32:47] <wbs> and returns that it used 220 bytes of data from the source [17:32:58] <wbs> you then feed bytes 220-4095 to the decoder and tells it to decode more data [17:33:07] <wbs> which again returns 220 and the corresponding decoded audio data [17:33:16] <wbs> at the end, you've decoded 18 frames correctly [17:33:23] <wbs> and you've used 3960 bytes of the input [17:33:28] <wbs> but you read 4096 bytes from file [17:33:32] <Gottaname> but the 19th is the exception [17:33:37] <Gottaname> so how does one handle it? [17:33:45] <wbs> you normally use a container format [17:33:50] <_av500_> one reads more data [17:33:52] <votz> wbs: why doesnt the api-example.c use av_input_file(...) and av_read_frame(...), etc? [17:34:06] <wbs> votz: because it's an example of libavcodec, not libavformat [17:34:15] <votz> sensible enough :) [17:34:20] <Gottaname> that would be output_example right? [17:34:21] <ramiro> for libavformat there's output-example [17:34:39] <Gottaname> ah, but output example lacks an audio decode [17:34:46] <_av500_> and for all of it there is ffmpeg [17:34:47] <wbs> yes, but don't you see the big picture already? [17:34:59] <_av500_> and for all of it there is ffmpeg.c [17:35:45] <Gottaname> wbs: yeah [17:36:04] <wbs> normally, you would have a file format, and libavformat would handle that for you. or you could invent you own file format [17:36:15] <wbs> you could put a 2-byte header for each data packet, saying how many bytes it is [17:36:16] <votz> _av500_: ffmpeg.c can be kind of hard for some to parse for more specific use cases [17:36:29] <wbs> then you read 2 bytes, saying how many bytes the packet is, and then read exactly that many bytes [17:36:50] <Gottaname> that would work [17:36:59] <Gottaname> god, I should have stayed more alert during SDL class [17:37:07] <wbs> this has NOTHING to do with SDL [17:37:25] <Gottaname> yeah, but it deals with roughly the same concept [17:37:33] <wbs> uh, well, whatever [17:37:37] <Gottaname> I used SDL with FFMPEG before [17:38:00] <votz> what changed with avcodec_decode_aduio2 to avcodec_decode_audio3? [17:38:04] <votz> *audio2 [17:38:24] <_av500_> the pkt, no? [17:38:26] <wbs> votz: you provide an AVPacket instead of a plain buffer+size [17:38:48] <votz> ah [17:38:55] <votz> that simplifies things a bit [17:39:00] <Gottaname> wbs: this would be a task better suited for avformat anyway [17:39:32] <wbs> yes, it would [17:39:58] <wbs> mpeg codec perhaps may provide such framing in the codec itself, but the behaviour seems to have changed at some point (rev 9144) [17:42:55] <Gottaname> I'll tackle this tommorrow morning [17:42:56] <Gottaname> good night all [17:43:06] <BastyCDGS> good night [18:23:06] <KotH> http://digitaldaily.allthingsd.com/20100520/googles-royalty-free-webm-video… [18:29:27] <_av500_> old news [18:29:57] <spaam> _av500_: .ch dont get news so fast ;) [18:30:49] <_av500_> all the mountains make internet reception diffcult [18:31:05] <ramiro> the journalists were too busy eating chocolate [18:31:11] <kierank> and they are too busy eating fon due [18:34:11] <_av500_> KotH: but lol at the comment that mentions metabox AG [18:34:20] <_av500_> that wasindded a big fail iirc [18:35:08] <CIA-93> ffmpeg: stefano * r23259 /trunk/libavformat/ (nut.c nut.h nutenc.c nutdec.c): [18:35:08] <CIA-93> ffmpeg: Define ff_nut_video_tags and make Nut muxer and demuxer set it in [18:35:08] <CIA-93> ffmpeg: codec_tag. [18:35:08] <CIA-93> ffmpeg: stefano * r23260 /trunk/libavformat/nutdec.c: [18:35:08] <CIA-93> ffmpeg: Make the nut decoder read the ff_nut_video_tags to detect codec id of [18:35:09] <CIA-93> ffmpeg: the input file. [18:35:10] <CIA-93> ffmpeg: This is required as Nut codec tags are not contained in [18:35:10] <CIA-93> ffmpeg: ff_codec_bmp_tags. [18:40:11] <BastyCDGS> so amiga stuff is finished uploading [18:48:18] <DonDiego> siretart: i think baptiste's ogg muxer improvement is 0.6 material.. [18:49:51] <DonDiego> then there is the question what to do with the vp8 stuff [18:50:00] <DonDiego> obviously nobody could expect this.. [18:51:02] <siretart> looking [18:51:07] <CIA-93> ffmpeg: siretart * r23261 /branches/ (0.6 0.6/cmdutils.c 0.6/ffmpeg.c): (log message trimmed) [18:51:07] <CIA-93> ffmpeg: Open 2-pass logfile in binary mode for both reading and writing. [18:51:43] <CIA-93> ffmpeg: This fixes a regression on Windows introduced by r22769 in which the data read [18:51:43] <CIA-93> ffmpeg: from the file was not properly zero terminated. The file was read as text, [18:51:43] <CIA-93> ffmpeg: which caused the \r characters to be suppressed. Since the zero termination [18:51:43] <CIA-93> ffmpeg: happens at the end of the buffer, and there was one byte less read per line, [18:51:43] <CIA-93> ffmpeg: this caused the remaining space on the buffer to contain random data. [18:53:01] <siretart> DonDiego: vp8 is a good question, I think if we don't have it ready for 0.6, we should promise it for 0.6.1 [18:53:18] <DonDiego> yes, exactly my thought [18:53:28] <siretart> what's the status on webm/vp8 in trunk? - is trunk ready for it yet? [18:53:33] <DonDiego> we would need to do 0.6.1 in close proximity [18:53:43] <DonDiego> or wait a little more.. [18:53:57] * siretart feels 0.6 is already long overdue [18:56:33] <DonDiego> yeah :-/ [19:02:06] <KotH> how about doing it ... now? [19:04:34] <siretart> :-) [19:06:05] <siretart> DonDiego: with 'baptiste's ogg muxer improvement' you mean r23231, right? [19:07:20] <DonDiego> yes [19:12:39] <CIA-93> ffmpeg: stefano * r23262 /trunk/libavfilter/vf_scale.c: [19:12:39] <CIA-93> ffmpeg: Prefix value for flags with "0x", to make it clear that it is an [19:12:39] <CIA-93> ffmpeg: hexadecimal value. [19:13:17] <CIA-93> ffmpeg: siretart * r23263 /branches/ (4 files in 4 dirs): [19:13:17] <CIA-93> ffmpeg: In ogg muxer, pack multiple frames into one page, much lower overhead [19:13:17] <CIA-93> ffmpeg: backport r23231 by bcoudurier [19:14:09] <CIA-93> ffmpeg: jai_menon * r23264 /trunk/ffplay.c: [19:14:09] <CIA-93> ffmpeg: FFplay : Avoid manipulating NULL data pointers so that future checks [19:14:10] <CIA-93> ffmpeg: remain valid. This fixes segfaults for those cases where data copy to [19:14:10] <CIA-93> ffmpeg: this invalid pointer is attempted. [19:15:52] <CIA-93> ffmpeg: jai_menon * r23265 /trunk/ffplay.c: Cosmetics : re-indent after last commit. [19:16:41] <siretart> how much disk space does the fate repository take? [19:18:26] <drv> the samples? about 300 M currently [19:24:15] <siretart> ah, right. thanks [19:24:46] <drv> now i am trying to update them and remembering why i avoid writing my own rsync commands :) [19:24:58] <jai> :) [19:25:40] <KotH> rsync -Pvrt --delete-during <src> <dst> ? [19:25:48] <jai> for the release, wouldnt it make more sense to actually run the suite across all platforms? [19:28:04] <siretart> jai: indeed, but I understand mike's mail that this was not possible [19:30:36] <jai> siretart: ah, ok [19:30:42] <jai> must've missed that [19:31:05] <wbs> siretart: I guess he meant that there's no way to push the 0.6 to the current fate machines and use them to test it [19:34:27] <siretart> wbs: yes, and exactly that would be extremly helpful [19:43:36] <lu_zero> yawn [19:43:46] * lu_zero is feeling quite lazy [19:48:09] <lu_zero> wbs: I'm eventually trying your reorder patch [19:49:23] <lu_zero> I just need to recall how to use netem correctly [19:59:48] <siretart> DonDiego: I've just managed to build a shared ffmpeg 0.6 on ia64. I'll try to do a fate run on that machine as well. [20:01:07] <thresh> i've got a HPUX/ia64 if you want [20:02:55] <DonDiego> cool [20:03:02] * DonDiego pets siretart [20:04:01] <siretart> thresh: did ffmpeg 0.5 work on that machine? [20:04:26] <siretart> DonDiego: looks great so far, the machine has plenty of ram but isn't the fastest machine [20:06:10] <thresh> siretart: oh, never tried [20:06:28] <siretart> DonDiego: shall we test on some other arch as well, or do we consider this 'good enough'? [20:07:04] <siretart> thresh: a regression would be bad, but if it never worked, I wouldn't delay the release for that [20:08:35] <siretart> yay, fate test suceeded :-) [20:11:11] <DonDiego> do we have support for chained ogg files now? [20:11:35] <mru> depends on what you mean by support [20:11:48] <mru> they're not semantically clear [20:16:37] <DonDiego> i'm writing up a mail to the foms list [20:16:40] <wbs> lu_zero: good :-) [20:16:49] <DonDiego> mentioning xiph-related changes in 0.6 [20:17:19] <wbs> lu_zero: if you'd have time to add a comment on the discussion with michael on how to handle it in the best way regarding low delay and not queueing too much, it would be appreciated :-) [20:19:11] <lu_zero> I just did now [20:20:14] <wbs> great, thanks! [20:20:15] <thresh> god i wish git.ffmpeg.org provided branches also [20:20:17] <thresh> who do I poke? [20:20:53] <thresh> or who do I beer? [20:21:33] <siretart> DonDiego: do you think we can do a 0.6 release today or tomorrow? - what's left on your list? [20:22:27] <ramiro> siretart: thanks for the backport [20:22:57] <DonDiego> nothing much.. [20:23:00] <lu_zero> wbs: thanks for you contribution =) [20:23:54] <siretart> ramiro: thanks for nominating it :-) [20:25:42] <wbs> lu_zero: thanks for supporting it :-) [20:32:44] <siretart> DonDiego: what about my first question? [20:34:01] <DonDiego> hmm [20:34:20] <DonDiego> well, we might as well go for it [20:34:27] <DonDiego> siretart: ready to do it today? [20:36:23] <siretart> I'm currently doing a compile/fate run on a debian powerpc portmachine right now, but I don't expect failures [20:36:29] <siretart> so in principle, sure, why not [20:37:46] <DonDiego> ok [20:38:02] <siretart> it's a shame that vp8/webm is not in 0.6, but since that's not in trunk either, I think we can defer that to 0.6.1 [20:39:19] <DonDiego> we could do 0.5.2 along with it [20:39:31] <DonDiego> and yes, we could defer vp8 stuff to 0.6.1 [20:48:37] <bcoudurier> hi guys [20:53:30] <DonDiego> hi [20:53:41] <saintd3v> hi onjoin [20:53:50] <DonDiego> bcoudurier: say, did you make overhead comparisons with libogg? [20:54:20] <elenril> bcoudurier: can you fix author->artist thing in mov demuxer? [20:55:05] <DonDiego> ah, just saw your reply.. [20:55:21] <bcoudurier> elenril, I thought you were going to do it [20:55:49] <bcoudurier> but that's fine, it's a oneliner, I can do it right now [20:56:39] <elenril> cool, thanks [20:56:51] <DonDiego> siretart: reimar just proposed an ogg patch on -devel, hmmm [20:57:09] <DonDiego> the changelog contains nothing about ogg and theora-related changes [20:58:53] <siretart> DonDiego: hm. I don't see reimar's mail. what's the subject? [20:59:01] <enkidu> I promised to make a patch for grouped streams and droping zombie connections, but I realised, that it need some more work [20:59:10] <siretart> I see his '[PATCH] enable generic index for ogg demuxer' - do you mean that? [20:59:39] <enkidu> even it mostly works correct [21:00:19] <DonDiego> yes [21:02:11] <DonDiego> Yuvi: you around? [21:03:18] <siretart> ugh.. I somehow misread your line as if reimar had commented on an existing patch. - now, it's surely a new one [21:04:11] <CIA-93> ffmpeg: bcoudurier * r23266 /trunk/libavformat/ (movenc.c mov.c avformat.h): change author metadata to artist in mov de/muxer [21:05:00] <elenril> avformat? [21:05:12] <DonDiego> oops [21:05:27] <DonDiego> the changelog was not updated for the branch [21:05:36] <CIA-93> ffmpeg: bcoudurier * r23267 /trunk/libavformat/movenc.c: albm 3gp tag has optional track field not date [21:05:37] <DonDiego> i.e. the trunk changelog was not branched.. [21:07:01] <CIA-93> ffmpeg: bcoudurier * r23268 /trunk/libavformat/movenc.c: write 3gp perf tag for artist metadata [21:10:39] <bcoudurier> elenril, yes I bumped the micro version [21:10:46] <bcoudurier> so people complaining can check it [21:10:56] <CIA-93> ffmpeg: bcoudurier * r23269 /trunk/libavformat/avformat.h: oups, 100l, revert unrelated hunk from commit r23266 [21:12:28] <elenril> ah [21:12:29] <bcoudurier> this is what happens when you change things at the last minute :( [21:12:37] <elenril> :) [21:12:45] <elenril> DonDiego: i think that fix should go into 0.6 [21:12:55] <bcoudurier> DonDiego, do you know how you can output i420 with mplayer and not yv12 ? [21:13:08] <DonDiego> format filter i think [21:14:03] <bcoudurier> says md5sum does support i420 :( [21:16:20] <_av500_> wtf, nero ag sues mpegla [21:16:34] <siretart> uh? in that direction? [21:16:38] <mru> in january [21:18:27] <siretart> elenril: what svn revision? [21:19:03] <elenril> siretart: r23266/r23269 [21:20:36] <CIA-93> ffmpeg: diego * r23270 /trunk/Changelog: Reflect the 0.6 branch in the Changelog. [21:21:41] <bcoudurier> DonDiego, we are waiting for vp8 right ? [21:22:09] <DonDiego> we dunno, really [21:22:19] <DonDiego> vp8 might go in 0.6.1 as well [21:22:28] <DonDiego> it's not sure how long this will take [21:22:43] <DonDiego> and 0.6 has been delayed for too long already [21:25:31] <siretart> bcoudurier: if vp8/webm was already in trunk, that would be something else, but I don't see those patches applied in say, a week [21:26:16] <siretart> bcoudurier: waiting a few more weeks to get that tested and integrated and then backport it to a point release doesn't seem unreasonable [21:26:42] <siretart> OTOH, we could of course delay for another 2-3 weeks and have vp8 as excuse ;-) [21:26:56] <siretart> btw, fate/0.6/powerpc suceeded :-) [21:28:32] <BastyCDGS> so I just wrote to ML my ideas about MOD support [21:29:59] <bcoudurier> it seems stupid to release without vp8 [21:30:06] <bcoudurier> everybody will notice it [21:31:11] <CIA-93> ffmpeg: diego * r23271 /branches/0.6/RELEASE: small spelling fixes [21:31:20] <siretart> hm. the headline 'ffmpeg misses vp8' doesn't look great, indeed [21:53:50] <Yuvi> DonDiego: pong [21:55:21] <spaam> BastyCDGS: is it a big diff between .mod and .xm ? :) [21:55:43] <BastyCDGS> like IFF-8SVX => RIFF-WAVE [21:56:09] <BastyCDGS> xm supports 16-bit samples which mod doesn't and also instruments [21:56:14] <BastyCDGS> mod only knows samples [21:56:30] <BastyCDGS> otherwise they're pretty similar [21:56:39] <spaam> ok :) [21:56:40] <BastyCDGS> just the internal file format is totally different [21:57:12] <BastyCDGS> the biggest change was made with IT [21:57:27] <BastyCDGS> that's almost like DPaint => GIMP/Photoshop [21:57:34] <spaam> hehe ok :) [21:57:48] <CIA-93> ffmpeg: banan * r23272 /trunk/libavformat/aea.c: [21:57:48] <CIA-93> ffmpeg: Fix detection of some stereo atrac files by not comparing the [21:57:48] <CIA-93> ffmpeg: block size mode and info byte. Reduced the probe score just in case. [21:58:16] <DonDiego> Yuvi: could you update the changelog with your theora and ogg changes? [21:58:37] <Yuvi> sure [21:58:41] <DonDiego> my bad memory will likely miss half of them, for you it should be a matter of seconds.. [21:59:55] <Yuvi> did r22931 get into 0.6? it should if not [22:00:02] <BastyCDGS> DonDiego, changelog? hmm maybe it's time to write a changelog for IFF as well, since there has changed quite a bit now [22:00:35] <BastyCDGS> spaam, what do you think of my MOD post? [22:00:41] <BastyCDGS> was it clear and comprehensive? [22:00:59] <kierank> some of the things like MOD in AVI was scary [22:01:06] <kierank> just because it can be done doesn't mean it should [22:01:11] <BastyCDGS> someone here in #ffmpeg-devel had this idea ;) [22:01:21] <ramiro> scary nonetheless [22:01:29] <BastyCDGS> but why? [22:02:27] <CIA-93> ffmpeg: banan * r23273 /trunk/libavformat/aea.c: 10l, now the score is reduced [22:03:23] <BastyCDGS> ramiro, they of course can convert the MOD to PCM before putting it into AVI ;) [22:03:35] <BastyCDGS> or mp3 whatever you want [22:03:53] <BastyCDGS> at least when the video is release-ready [22:04:10] <kierank> it's still in avi [22:04:23] <Yuvi> siretart: could you port r22931 to 0.6 please? [22:04:39] <BastyCDGS> no I meant putting the PCM result instead of the MOD in the avi, the MOD itself is just used for composing [22:05:22] <BastyCDGS> although it could be a good idea to use the MOD itself unless the movie is finished (for easier editing the musical part) [22:05:40] <Yuvi> or nm [22:05:45] <Yuvi> the branch was created after that [22:05:50] <BastyCDGS> like you use lossless audio for editing a PCM sample and release the final as mp3/ogg vorbis [22:06:58] <kierank> it's still putting something in avi ;) [22:07:42] <siretart> Yuvi: it already is? [22:07:47] <DonDiego> BastyCDGS: was iff added without changelog entry? [22:08:16] <BastyCDGS> DonDiego, I meant the changes I made since I started with FFmpeg [22:08:19] <CIA-93> ffmpeg: diego * r23274 /branches/0.6/VERSION: Add VERSION file for 0.6 release. [22:08:26] <BastyCDGS> don't know if there's an initial changelog for iff [22:09:01] <BastyCDGS> did a grep for IFF: [22:09:02] <BastyCDGS> - IFF PBM/ILBM bitmap decoder [22:09:02] <BastyCDGS> - AIFF/AIFF-C audio format, encoding and decoding [22:09:02] <BastyCDGS> - TIFF picture encoder and decoder [22:09:02] <BastyCDGS> - Beam Software SIFF demuxer and decoder [22:09:02] <BastyCDGS> - IFF demuxer [22:09:05] <BastyCDGS> that's all [22:15:09] <Yuvi> DonDiego: don't know if all the various bugfixes should be mentioned, which leaves it at http://pastie.org/973834 (dunno about the ogg stuff even) [22:16:20] <DonDiego> BastyCDGS: ok, so the demuxer is mentioned.. [22:16:44] <BastyCDGS> yes but only mentioned no list of features, should I add something like this? [22:16:45] <siretart> Yuvi: that reads great to me [22:17:09] <DonDiego> i'll tweak and apply it, thanks [22:17:55] <Yuvi> actually a quick run puts the speedup at around 35% [22:21:08] <CIA-93> ffmpeg: conrad * r23275 /trunk/libavformat/matroskadec.c: matroskadec: Revert adding the doctype to metadata; it has no meaning elsewhere [22:23:12] <bcoudurier> is reimar on irc sometimes ? [22:23:34] <BastyCDGS> one question regarding to keyframes [22:23:47] <BastyCDGS> should the keyframe bit be set for single images? [22:23:53] <ramiro> bcoudurier: no [22:24:06] <BastyCDGS> I ask because I'm thinking why images get black with ffplay after resize or switch from/to fullscreen [22:24:17] <BastyCDGS> that it doesn't redraw because the keyframe flag is missing? [22:24:45] <bcoudurier> yes you must set it [22:25:12] <janneg> lol "But absolute power has corrupted MPEG LA absolutely" [22:25:30] <BastyCDGS> just took a look, iff_read_packet has a line: [22:25:30] <BastyCDGS> if(iff->sent_bytes == 0) [22:25:30] <BastyCDGS> pkt->flags |= AV_PKT_FLAG_KEY; [22:25:36] <BastyCDGS> so it sets it but only once [22:25:46] <mru> janneg: if I were in charge and received that I'd send it back with the words "get real" [22:25:56] * janneg didn't expected to read that in Nero's antitrust complaint against mpeg la [22:26:04] <mru> not saying they haven't done anything wrong [22:26:16] <mru> but such language does not belong in legal proceedings imo [22:27:54] <janneg> yes, very strange. I would have asked if that is intended language even if not in charge [22:28:28] <mru> it's full of stuff like that [22:31:20] <kierank> I think it's because of a bad translation [22:31:41] <janneg> like "to add insult to injury", maybe it's just a joke [22:32:18] <mru> kierank: it's signed by a US lawyer [22:32:38] <janneg> kierank: their LA attorneys should have fixed that [22:39:24] <BastyCDGS> Fuck, by mistake I linked FFplay with libpthread (which is required by libxvidcodec) and there was a conflict between pth and sdl threads, so false alert - everything works correctly! [22:39:39] <BastyCDGS> ami_stuff just wrote me this per mail while he was testing my latest patches [22:39:55] <BastyCDGS> thought would be a good idea to post that here, maybe we can fix this conflict [22:40:26] <BastyCDGS> false alert was: [22:40:26] <BastyCDGS> Please try to view some iff file with ffplay, resize the sdl window (so you will get black screen) and next press "f" key a few times to swicht between fullscreen/windowed mode. [22:40:26] <BastyCDGS> [22:40:26] <BastyCDGS> Here after some time the stats (time value) stop to be printed in the console and quit button or "q" key doesn't work, so I can't exit ffplay. [22:45:28] <BastyCDGS> suggested fix by me: [22:45:28] <BastyCDGS> We either should do not allow this at all or provide a fix: [22:45:28] <BastyCDGS> If pthreads is enabled then FFplay should also use pthreads instead of SDL threads. [22:45:28] <BastyCDGS> [22:45:28] <BastyCDGS> What do you think? [23:12:32] <bcoudurier> BastyCDGS, indeed, a patch changing this is welcome I guess [23:18:40] <CIA-93> ffmpeg: diego * r23276 /trunk/Changelog: Mention some more changes related to HTML 5 issues. [23:20:30] <CIA-93> ffmpeg: diego * r23277 /trunk/Changelog: small wording fix [23:29:15] <CIA-93> ffmpeg: diego * r23278 /branches/ (0.6 0.6/Changelog): Merge last round of Changelog updates for HTML 5 features. [23:34:42] <CIA-93> ffmpeg: reimar * r23279 /trunk/libavformat/oggdec.c: [23:34:42] <CIA-93> ffmpeg: Enable AVFMT_GENERIC_INDEX for Ogg demuxer. This avoids the many [23:34:42] <CIA-93> ffmpeg: seeks needed for binary search when seeking to a previously seen [23:34:42] <CIA-93> ffmpeg: location. [23:36:43] <mru> but monty says that's not necessary... [23:56:14] <bcoudurier> mru [23:56:32] <bcoudurier> can you please help me moving x86/cpuid.c to libavutil ? [23:56:48] <mru> what's the problem? [23:57:07] <bcoudurier> I'm not sure how do you want libavutil Makefile to be [23:57:22] <mru> same as libavcodec is now of course [23:57:26] <bcoudurier> OBJS-$(HAVE_MMX) += x86/cpuid.c ? [23:58:56] <bcoudurier> or separate Makefile in x86 ? [23:59:19] <mru> I guess a separate makefile is overkill for this one case [23:59:28] <mru> but shouldn't that be $(ARCH_X86) ? [23:59:49] <bcoudurier> dunno [23:59:59] <bcoudurier> cpuid.o is under HAVE_MMX in libavcodec

1 0

IRC log for 2010-05-20
by irc＠mansr.com 20 May '10

20 May '10

[00:53:21] * Terminating due to: TERM [00:53:32] * /join #ffmpeg-devel ... [00:53:34] *** TOPIC: Welcome to the FFmpeg development channel. That is, development of FFmpeg, not using FFmpeg, nor libav*. | Users should redirect their questions to #ffmpeg | FFmpeg 0.5.1 has been released! | this chat is now publicly logged. [00:53:34] *** TOPICINFO: superdump!~rob@unaffiliated/superdump, 1267604523 [02:55:04] <ramiro> libvpx's configure is strangely similar to ffmpeg's... [02:56:00] <astrange> learning from the best? [02:56:54] <ramiro> =) [02:57:37] <Yuvi> bcoudurier: I'm getting oggz-validate errors (timestamp out of order) with theora+flac, looking into it now [02:57:50] <Yuvi> also eos sometimes not being set [02:59:10] <peloverde> ramiro: ffmpeg's configure/makefile has a valid make install [03:00:00] <ramiro> and it's great for cross-compilation [03:00:24] <Yuvi> and it detects what arch you're on without additional arguments [03:02:22] <ramiro> many hunks are copy&pasted. did mru have anything to do with this? [03:02:23] <Compn> think of it this way [03:02:37] <Compn> they already distribute and maintain some ffmpeg in chrome [03:02:48] <Compn> would they chose autotools to use with vp8 ? [03:03:06] <Compn> actually, i wonder if they use ffmpeg makefile in on2? nothing to do with google ? [03:03:14] <Compn> on2 distributes mencoder hmm [03:03:34] <Compn> have to diff it against svn makefile to see how old it is :D [03:14:02] <bcoudurier> Yuvi, shit it's broken then [03:21:22] <peloverde> I feel like this webm situation gives me even less motivation to merge psdec into trunk [03:24:27] <bcoudurier> nah don't worry [03:24:34] <bcoudurier> Yuvi, something is wrong with the last_pts check [03:24:45] <bcoudurier> what if you remove it ? [03:26:17] <ramiro> peloverde: heh, now I get the make install is configuring thing... [03:26:41] <ramiro> imo make install shouldn't even try to build anything [03:27:46] <astrange> you don't like typing 'make install clean' to install a bsd port? [03:28:06] <peloverde> The big PS demotivator was losing funding for the OSS version, I mainly wrote it to sell to third parties (which I did successfully), webm is just icing on the cake [03:32:19] <Yuvi> bcoudurier: yep, that fixes the ordering [03:33:12] <Yuvi> looks like the eos too [03:33:57] <Yuvi> peloverde: was the funding from google / have you talked to them about potential money? [03:35:10] <peloverde> funding was osp.fi [03:37:43] <peloverde> google knows who I am and what I do, I even pushed SBR as hard as possible to try to meet their timelines (as well as an earlier projected 0.6), but they largely seem disinterested [03:40:08] <bcoudurier> Yuvi, got it [03:43:21] <peloverde> I also sent them some thoughts on the general multimedia topics in December about multimedia including funding OSS work and hiring some MPEG thought leaders and got a form type letter back [03:44:21] <Compn> peloverde : did you send a message to the head of google code ? [03:44:26] <Compn> maybe he can get someone to work on sbr [03:44:44] <peloverde> Compn: SBR is merged :) [03:44:59] <Compn> er not sbr, but whatever needs doing :P [03:45:03] <peloverde> PS [03:45:11] <peloverde> (parametric stereo) [03:45:13] <astrange> ps = he-aac v2 [03:45:18] <Compn> that then [03:45:21] <Compn> did you email the guy? [03:45:27] <astrange> it's used in broadcast but not on the web(?) so google might not care as much? [03:45:32] <peloverde> you mean diBona? [03:45:37] <Compn> yes dibona i think [03:46:29] <peloverde> I talked to chrome people [03:46:45] <Compn> forget those guys [03:46:48] <peloverde> but just thinking about dibona makes me miss "Geeks in Space" [03:47:25] <peloverde> that was a great podcast or "internet radio show" as it was known at the time [03:47:32] <Compn> send him a mail :P [03:47:38] <Compn> cant hurt anyhow [03:47:58] <Compn> or post a note on ffmpeg.org saying it would be nice if someone would try it [03:48:06] <peloverde> I suppose not :) [03:48:14] <Compn> or continue to bitch on irc, see if anything comes of that [03:48:37] <peloverde> I have actually gotten a few minor jobs on from ffmpeg.org [03:48:50] <peloverde> there are a few googlers idling in here :) [03:49:17] <Compn> are there ? [03:49:19] <Compn> hmmm [03:50:18] <peloverde> _skal_zZzZz_ scherkus [03:51:00] <bcoudurier> Yuvi, please try updated patch [03:51:09] <peloverde> off the top of me head, it wouldn't surprise me if there were a few more lurkers [03:51:28] <Compn> this channel grew a bit over the past few months [03:53:00] <bcoudurier> hiring some MPEG thought leaders ? [03:53:33] <bcoudurier> what do you mean peloverde ? [03:53:40] <Compn> bcoudurier : hyc is getting impatient about his ffserver patches , hehe [03:53:47] <bcoudurier> ah right [03:53:48] <peloverde> hiring some people from jvt-experts and mpeg-audio-call [03:53:56] <bcoudurier> marting seems to be handling them well, though [03:53:59] <bcoudurier> martin sorry [03:54:02] <bcoudurier> ah [03:54:05] <bcoudurier> why would they ? [03:54:10] <peloverde> like a gary sullivan or schylur quckenbush [03:54:16] <Compn> bcoudurier : well martin was waiting for an OK on the patches :) [03:54:19] <bcoudurier> gary is microsoft [03:54:33] <peloverde> gary is microsoft, he wasn't always microsoft [03:54:40] <bcoudurier> and everybody knows microsoft has better 401k and health package [03:55:14] <peloverde> ralph sperschneider or andreas scheneider from mepg audio are FhG and Dolby [03:55:24] <peloverde> (respectively) [03:55:26] <bcoudurier> google is for nerds < 30 years, sorry skal :) [03:55:53] <bcoudurier> these are good company for benefits [03:55:58] <bcoudurier> companies [03:56:05] <bcoudurier> I guess [03:56:35] <peloverde> Max Neuendorf from FhG would also be a potential good pick [03:57:23] <bcoudurier> I'm not sure google cares about standardization though [03:57:44] <bcoudurier> otherwise they wouldn't have chosen very "unstandard" codecs [03:58:06] <peloverde> I think to a degree they need to be aprised of what is going on there since their major competitors are (M$ and apple) [03:58:24] <bcoudurier> I agree, but that is not SMPTE nor ISO [03:58:28] <peloverde> and regardless I think these people I named have good ideas that can be applied elsewhere [03:58:46] <bcoudurier> of course [03:58:55] <bcoudurier> but OSS is not their play fields [03:59:30] <peloverde> only because mpeg and/or proprietary pays more [04:00:23] <bcoudurier> maybe [04:00:52] <peloverde> also what I know is when CT was independent and what I wanted aligned with what [04:00:56] <bcoudurier> Yuvi, are you there ? [04:01:09] <peloverde> CT wanted Andreas Schneider knew how to get things done at MPEG [04:01:09] <bcoudurier> CT ? [04:01:16] <peloverde> Coding Technologies [04:01:20] <bcoudurier> oh [04:01:31] <peloverde> now known as Dolby International [04:02:03] <bcoudurier> dolby care about standards because of equipment [04:02:52] <bcoudurier> anyway home time [04:02:57] <peloverde> I've interviewed at Dolby more times than I care to admit, their business model is to make very good production tools and license the formats downward [04:03:23] <peloverde> CT was even more dependent on licensing [04:03:42] <Yuvi> bcoudurier: yeah [04:03:53] <Yuvi> the new patch on the ML fixes the issues, looking at it more now [05:35:45] <Yuvi> youtube's webm muxer is based off of lavf :) [05:36:01] <astrange> isn't it still mencoder? [05:36:19] <Yuvi> probably [05:38:10] <Yuvi> but iirc they used gpac for mp4 for instance [05:49:47] <astrange> yeah, vfr is still broken [05:56:28] <astrange> http://astrange.ithinksw.net/ffmpeg/hiromoving_vfr.mp4 -> http://www.youtube.com/watch?v=TlxVrbkq5kw is all wrong ( <-- _skal_zZzZz_ ) [05:58:25] <pJok> goda morgonar kshishkov :) [05:59:08] <av500> Guten Morgen Herr kshishkov [05:59:24] <pJok> mornings av500 :) [05:59:49] <pJok> i wonder when the patent trolls will star to appear [05:59:52] <pJok> start* [06:01:29] <av500> not for a while [06:01:56] <av500> trolling early means killing your prey at a very yound age [06:02:01] <pJok> true [06:02:04] <av500> you want the sow to fatten [06:02:34] <Tjoppen> I already see a lot of people touting it as non-encumbered. this worries me [06:02:41] <av500> Tjoppen: dont be [06:02:54] <av500> ppl are just repeating press releases [06:03:52] <pJok> are people still touting vp8 as the best codec since sliced bread? [06:04:43] <av500> gg is touting it as "free" [06:35:40] <wbs> bcoudurier: regarding the ffserver patches, yes, please have a look at them, I only applied the really obvious ones... the rest of them requires quite a bit of familiarity of the intended architecture and stuff [06:35:50] <KotH> moin people [06:36:11] <wbs> didn't have time to dive in that deep on the matter just to approve/disapprove patches on something I don't maintain nor use :-) [06:36:25] <wbs> but the latest extradata handling patches are at least much less hacky than the initial ones :-) [06:40:04] <av500> KotH: moin, btw is gg street view in .ch as controversial as in .de? [06:45:03] <KotH> av500: juup [06:47:27] <Yuvi> "Yamka is designed around clear separation of responsibilities between an EBML Element and EBML Element Payload." that's a reason to develop a new library? [06:47:59] <av500> yamka? [06:48:09] <Yuvi> what sorenson developed to write webm [06:48:21] <Yuvi> http://sourceforge.net/projects/yamka/ [06:48:39] <av500> they needed to write a new lib to write mkv files? [06:49:38] <av500> urg, cpp [06:49:57] <astrange> well, libmatroska isn't great but i didn't see any problem with using it for encoding [06:51:12] <Yuvi> and libmkv is even simpler [06:51:24] <Yuvi> I think yamka's headers are larger than all of libmkv's source [06:51:37] <astrange> does it do audio? [06:51:52] <Yuvi> yeah [06:52:55] <KotH> av500: gg was already fined for not complying with local laws regarding street view [06:53:17] <KotH> av500: got us a nice comment from gg saying that swiss people are privacy nazis [06:54:18] <av500> I assumed swiss ppl would use their mandatory gun to shoot the street view cars [06:55:07] <KotH> said rifle is for official use only ;) [06:57:34] <av500> come on, you need some target practice [07:15:18] <Tjoppen> has anyone used libMXF? it seems to insist on generating TimecodeComponents that don't properly link with with their Tracks [07:17:42] <astrange> why does webm allow OutputSamplingFrequency if it can't contain sbr? [07:18:15] <Yuvi> they're working on grafting sbr onto vorbis? [07:18:45] <Yuvi> flix doesn't think audio packets deserve to have the keyframe flags set... [07:21:31] <Yuvi> (it also decimated my 30 fps to 12 for no apparent reason) [07:22:36] <Yuvi> is there an actual spec for webm other than "matroska with webm doctype"? [07:23:21] <av500> hmm, vp8 allows several outframes per decoded frame, what is the temporal relationship? [07:23:55] <Yuvi> are those the reference-only frames / not intended for display? [07:23:58] <astrange> http://www.webmproject.org/code/specs/container/ [07:24:04] <astrange> those are the altref frames [07:24:23] <av500> Yuvi: well, their simple_decoder example does that, but their lavc driver just uses 1.... [07:24:24] <astrange> er, altref means less output frames than input [07:24:36] <Dark_Shikari> astrange: why? [07:24:47] <astrange> because the altref is invisible [07:24:49] <Dark_Shikari> altref is just another reference frame iirc [07:24:55] <Dark_Shikari> at least that's what the spec said [07:25:05] <astrange> When enabled, the VP8 encoder will at its discretion inject a new frame â the alternate reference (AR) â into the output prior to the frame that depends on it. There will be at MOST 1 frame added between I/P-frames. The dependent frame (D) will always be a P-frame. The AR will be marked with the invisible flag by the codec SDK. This frame must be decoded before D, but will produce no output on its own. [07:25:12] <astrange> stuck in the container spec [07:25:36] <Dark_Shikari> that's the encoder delay [07:25:39] <Dark_Shikari> not an invisible frame [07:26:31] <astrange> the frame is also supposed to have its timestamp set 1 tick less than the next frame, so it certainly wouldn't show up for very long anyway [07:27:26] * Dark_Shikari never understood alt / golden [07:27:47] <astrange> i think alt is new, golden is just long-term referencing the keyframe [07:28:26] <Dark_Shikari> yeah I know [07:28:55] <Dark_Shikari> the worst part is due to alt+golden, the quality is all over the place [07:28:59] <Dark_Shikari> psnr bounces like a superball on crack [07:29:01] <Yuvi> "Seeking will be disabled if the webm file does not have a key frame Cues element." :< [07:29:56] <superdump> that description makes it sound like the encoder has the option of inserting a frame for reference purposes only and that will not be displayed [07:30:15] <superdump> Yuvi: are you interested in implementing an ogg mapping for vp8? :) [07:30:15] <astrange> give them a patent license for mbtree [07:30:21] <Dark_Shikari> astrange: lol [07:30:31] <Dark_Shikari> sounds like they sure as hell need it [07:30:35] <Yuvi> superdump: writing it? no, someone else is doing that [07:30:44] <Yuvi> once I've heard it's final I'll add it to the demuxer [07:30:53] <superdump> i said implementing :) [07:31:06] <Yuvi> well is it final? [07:31:07] <superdump> the mapping documentation should hopefully go up soon [07:31:19] <Yuvi> I saw a pre-1.0 [07:31:35] <Yuvi> and I don't really want a 4th _old mapping variation in the decoder [07:31:38] <Yuvi> demxuer [07:31:45] <superdump> :) [07:31:51] <superdump> understandable [07:32:23] <superdump> just checking you were aware of it, i figured you would be [07:34:21] <superdump> Yuvi: http://people.collabora.co.uk/~slomo/webm/ogg-vp8.pdf <--- that's apparently going to be the final mapping, so slomo says [07:34:26] <superdump> he told me to point you to that [07:34:38] <superdump> they're going to sort out getting it up on xiph.org soon [07:34:48] <superdump> he also said he's not going to change anything in that [07:35:58] <av500> there is not much in there to change [07:36:13] <superdump> indeed [07:36:14] <astrange> ugh, i have the feeling that altref means perian will break [07:36:40] <superdump> astrange: why? does perian have to have one frame in, one frame out or something? [07:36:49] <astrange> yes [07:36:53] <superdump> 'oop's [07:36:58] <av500> so, just reoutput the last frame [07:37:03] <astrange> or rather, quicktime has to have it, and perian's middleman handling isn't good enough [07:37:13] <superdump> that's what it sounds like to me [07:37:23] <Yuvi> xiph's theora decoder uses a flag for dropping that should mostly work [07:37:48] <Yuvi> ignoring frame-accurate seeking/stepping [07:38:26] <astrange> if it's a p-frame at the right place that should be ok (except for stepping sometimes displaying the same frame twice) [07:39:01] <astrange> but perian's video decoder just crashes if the ffmpeg codec does anything at all unexpected with buffer orders. need to rewrite it [07:39:45] <Yuvi> I have no clue how that works, I tried reworking ffmpeg's vp3's buffer model to what I thought should work and it still crashed [07:41:19] <Yuvi> maybe I should write PrevSize in mkv, I didn't know that field existed [08:05:16] <Yuvi> bcoudurier: another reason for the 1/1000 timebase in mkv: block timestamps are (cluster timestamp) + 16 bits signed [08:05:53] <bcoudurier> humm, so how can mkv claim to support nano sec accuracy ? [08:06:04] <Yuvi> one block per cluster [08:06:21] <Yuvi> which has like 6% overhead at reasonable bitrates [08:06:37] <Yuvi> it's one of those "in theory" things [08:06:44] <bcoudurier> pfff [08:06:53] <bcoudurier> the more I lean about mkv the more I hate it [08:07:12] <KotH> mkv, the new ogg? [08:07:29] <bcoudurier> btw did you check the updated ogg patch ? [08:07:46] * av500 never liked mkv [08:10:03] <hyc> av500: what format is better? [08:10:23] <hyc> bcoudurier: any chance you'll have time to review the remaining ffserver patches I posted? [08:10:41] <bcoudurier> yes, I'll try [08:10:47] <bcoudurier> this weekend at worst [08:10:48] <hyc> cool, thx [08:11:03] <bcoudurier> is it me or we suddently have a big bump in patch submission ? [08:11:13] <bcoudurier> which is great, don't get me wrong :) [08:11:22] <hyc> well, I had 85 new emails on the ffmpeg list in the past 8 hours [08:11:28] <hyc> looks like a bump :P [08:11:36] <Yuvi> bcoudurier: I think it looks okay, though it means I now really have to support seeking within a page [08:11:43] <Yuvi> in the demuxer [08:12:13] <bcoudurier> ah, indeed :) [08:12:15] <Yuvi> which in turn means porting oggz_auto which I've been trying to ignore ;P [08:12:52] <Yuvi> unrelated: maybe vrev should be dropped and you just change the bitstream version to 3.2.1 for old files? [08:15:05] <av500> hyc: the most sane container I encountered so far is asf [08:15:09] * av500 hides [08:16:52] * hyc throws brick at av500 anyway [08:29:26] <bcoudurier> Yuvi, can I do that ? [08:29:54] <Yuvi> hm, maybe not if you care about pre-3.2.0 [08:30:07] <Yuvi> but I'm pretty sure the muxer can't do anything with those since they only have 1 header [08:30:23] <Yuvi> the only difference 3.2.0 -> 3.2.1 is that pts change [08:32:34] * av500 watches VP8 decode on omap3.... :) [08:34:51] <av500> and it crashes in vpx_codec_destroy() doh [08:35:04] <hyc> destroy() was a good name for it then [08:37:51] <av500> yes, it destroys... [08:38:45] <kshishkov> so nothing to complain about? [08:39:14] <av500> as in? [08:39:54] <kshishkov> as if it crashed in vpx_codec_finish_and_not_segfault() [08:40:42] <elenril> is it me or interwebz are crashing? [08:40:55] * elenril can't get on a bunch of unrelated sites [08:41:35] <kshishkov> IIRC last time Internet crashed because of some Czech provider [08:41:56] <elenril> does e.g. tvtropes.org work for you? [08:42:40] <av500> it does [08:43:31] <elenril> hmm, works again [08:43:34] <elenril> with absurd pings [08:43:51] <elenril> ~180ms [08:43:59] <kshishkov> local ISP troubles, I think [08:44:54] <av500> InternetSlowdownProliferator [08:47:18] * elenril blames av500 [08:48:26] * av500 takes blame [08:49:40] * KotH blames av500 [08:49:41] <av500> hmm, it crashes for 360p content, but does not crash for 720p... [09:05:05] <av500> mru: no wonder the tegra ppl dont talk to you on the forum, you are calling them idiots [09:05:27] <twnqx> friend of mine makes fun of the tegra demoboard [09:05:35] <twnqx> "nonworking pos" and stuff like that [09:24:04] <kshishkov> g'day, matey [09:36:41] <KotH> twnqx: wood screws? [09:36:50] <KotH> kshishkov: you scared him! [10:03:51] <Kovensky> <+elenril> with absurd pings <+elenril> ~180ms <-- my avg ping is 1800ms :( [10:04:40] <elenril> o_0 [10:06:43] <elenril> clearly it's time for you to move to a civilized country [10:21:27] <mru> av500: where did I call then idiots? [10:21:48] <mru> I certainly _implied_ as much, but I don't remember saying it explicitly [10:27:33] <mru> I also made no references to today's dilbert strip [10:31:18] <j-b> can I call someone idiot and not imply it? [10:31:31] <mru> that's harder [10:40:04] <mru> you have to do it rather indirectly [10:44:40] <lu_zero> yaaawn [10:44:46] <lu_zero> what's about tegra? [10:46:46] * av500 is entering "idiot" in the tegra forum search [10:58:16] <twnqx> if that fails, try baka [12:05:02] <peloverde> happy thursday [12:05:19] <mru> morning peloverde [12:05:30] <kshishkov> what's so ahppy about thursdays? [12:06:38] <mru> next day is friday [12:06:42] <thresh> exacrlt [12:06:51] <thresh> oh god. i wish friday evening came faster. [12:06:59] <mru> and friday is beer day [12:07:21] <peloverde> new comic books came out yesterday, NBC comedies to DVR tonight, and thursday is beer day here [12:07:44] <mru> the wine club at the uni here is doing a belgian beer special tomorrow [12:08:38] <peloverde> do we have the case against autotools writtendown somewhere? [12:08:47] <mru> ffmpeg/configure [12:11:50] <thresh> "thursday is beer day here", so you get dead drunk today and don't work tomorrow? niiiiiiice. [12:11:50] <av500> wasnt drunk a prerequisite to work on AAC PS= [12:11:50] <peloverde> gnome quacks are trying to get libvpx to switch to autotools and I'd like to give them a concise argument why autotools is retarded [12:11:50] <mru> the best days are those when you can drink at work [12:11:50] <av500> ? [12:12:48] <mru> peloverde: rational arguments don't work on gnome quacks [12:12:48] <peloverde> friday I usually just work hungover [12:12:48] <peloverde> mru: I'm not trying to convince the gnome quacks just google [12:14:27] <mru> do you ever play FPS games? [12:15:55] <superdump> if someone proposes an autotools patch that is proven to work for all the cases needed and proves they will maintain it and arguments are presented against autotools but no solution implemented, which might google choose? [12:16:11] <mru> noticed how all them have a type of monster that's harmless on its own, but often attacks in large swarms? [12:16:22] <superdump> yup [12:16:27] <superdump> zerg rush kekekeke [12:16:44] <mru> they're usually spider-like [12:16:47] * av500 only plays 24FPS movies [12:17:07] <mru> shotgun tends to be the best defence [12:17:08] <thresh> you hate all those fancy 29.97 newer ones? [12:17:12] <Compn> av500: on a 24hz tv ? [12:17:15] <mru> or flame thrower if you have one [12:17:31] * TheFluff wonders where mru is going with this [12:17:36] * superdump too [12:17:41] <av500> violent [12:17:43] <mru> freetards are exactly like that [12:17:52] <kshishkov> mru: you're wrong. Try Gatling [12:17:57] <Compn> hahaha [12:18:02] <mru> gatling is too slow to start [12:18:08] <superdump> run out of ammo too quickly as well [12:18:09] <kshishkov> flamethrower? [12:18:20] <av500> thresh: I dont like the visual effect on the missing 0.03Hz :) [12:18:23] <mru> played resistance 2? [12:18:51] <kshishkov> definitely not [12:18:54] <mru> kshishkov: you have a ps3 in the office [12:18:59] * kshishkov had no luck with 3D games [12:19:06] <mru> I'd be surprised if that game isn't there [12:19:20] <Compn> i get motion sickness playing portal sometimes :P [12:19:26] <twnqx> did you play duke nukem forever? [12:19:31] <j-b> peloverde: no autotools, so what do you suggest? [12:19:55] <peloverde> a shell script works just fine for ffmpeg [12:19:57] <thresh> go cmake go go go [12:20:11] * kshishkov gives a bottle of methanol to thresh [12:20:48] <mru> kshishkov: pointless... he's cheering on cmake so he must be blind already [12:21:06] <kshishkov> that causes death too [12:21:40] <superdump> a shell script does work fine for ffmpeg and mru does a great job of maintaining it so it works well [12:21:40] <thresh> I'm not in a suicide mood today :-( [12:21:53] <mru> use it to build a flame thrower instead [12:22:04] * av500 votes for mru as lipvpx shell script maintainer [12:22:08] <superdump> but if no other shell script ninja steps up to do the work and google don't do it (or don't do it well) either then... [12:22:22] <j-b> anything would be better than their actual shit [12:22:23] * mru votes for obsoleting libvpx with a native decoder [12:22:43] <kshishkov> thresh: Ð²ÑÐµ ÑÐ°Ð²ÐœÐŸ, ÐŽÐ»Ñ Ð»ÑÐŽÐµÐ¹, Ð¿ÐŸÐŽÐŽÐµÑÐ¶ÐžÐ²Ð°ÑÑÐžÑ cmake ÐµÐŽÐžÐœÑÑÐ²ÐµÐœÐœÑÐ¹ ÐœÐ°Ð¿ÐžÑÐŸÐº - Ð²ÐŸÐŽÐºÐ° "ÐÐ°Ð»ÑÐœÑÑÐºÐ°" [12:22:58] <peloverde> I just don't want the thing to check for a FORTRAN compiler every time I run it [12:23:00] <kshishkov> mru: fine with me [12:23:02] <av500> wodka what? [12:23:04] <thresh> kshishkov: ÑÑÐŸ ÑÐ°ÐºÑ :)) [12:23:30] <kshishkov> av500: local Russian and Ukrainian brand of the cheapest vodka [12:23:46] <thresh> cheapest == made of methanol [12:23:49] <av500> yes, what does the name mean? [12:24:03] <kshishkov> 'counterfeited" [12:24:10] <av500> ah, that brand [12:24:34] <thresh> P + Alenushka [12:27:42] <peloverde> I really enjoy the public review they had of the bitstream format before setting it in stone... oh wait [12:28:32] <av500> peloverde: what, u missed it? :) [12:28:40] <kshishkov> lucky guy! [12:28:43] <mru> the problem is you can't do a public review _and_ release it to thunder and lightning [12:28:53] <mru> obviously, thunder and lightning is more important than quality [12:29:19] <kshishkov> Apple prefers glamour and sequins instead [12:30:35] <peloverde> There is also no reason the FFmpeg patches couldn't have been pre-reviewed except for lack of interest on their part [12:31:42] <mru> several of us even had NDAs in place [12:32:32] <mru> not that I agree there was any need for one [12:32:50] <av500> NonDamageAgreement was needed for Dark_Shikari [12:34:13] <mru> only because vp8 is too weak to stand on its own [12:34:20] <mru> without a mountain of hype to support it [12:34:26] <kshishkov> so it will stand on xiph's shoulders [12:34:41] <peloverde> maybe they shouldn't have called it 50% better than h.264 [12:34:50] <mru> xiph's shoulders are too slopey to stand on [12:35:12] <kshishkov> not if you full of hot air [12:35:59] <mru> but then xiph will function more as an anchor [12:36:23] <kierank> mru: or a low water mark [12:43:38] <Kovensky> <@peloverde> I just don't want the thing to check for a FORTRAN compiler every time I run it <-- bug fixed in libtool 2.2.7a (aka svn snapshots) =p [12:44:05] <kshishkov> what about Ada compiler check? [12:52:10] <janneg> Dark_Shikari's review is good for identifying and classifying freetards [12:52:52] <pross-au> what's a freetard? [12:52:59] <mru> free+retard [12:53:20] <pross-au> I understand what a retard is. What does 'Free' have to do with it? [12:53:43] <mru> not talked to debian folks much? [12:53:58] <pross-au> Oh 'Free' [12:54:07] <pross-au> U gotta capitalise the 'F' [12:54:24] <kierank> and put GNU/Freetard [12:54:35] <av500> gnutard? [12:54:42] <mru> gnu turd [12:54:51] <av500> is that a gcc coredump? [12:55:00] <pross-au> Haha [12:55:16] <av500> has "duck" a special meaning for on2? [12:55:17] <kshishkov> "Free" as "a free beer", "free" as "a free speech" and "free" as "'free' in Stallman speeches" [12:55:37] <kshishkov> av500: it was originally Duck Corporation [12:55:39] <mru> freedom to do as I say [12:55:52] <av500> kshishkov: ah, that explains: #define duck_memalign(X,Y,Z) vpx_memalign(X,Y) [12:56:09] <pross-au> So we're talking about the extreme-socialist-left of software politics? [12:56:33] <kshishkov> what's the difference with pirate parties? [12:56:44] <av500> what is the extreme-conservative-right of software politics? [12:56:52] <pross-au> Microsoft [12:57:01] <mru> kshishkov: pirate parties want something that actually benefits them [12:57:05] <mru> freetards don't [12:57:45] <kshishkov> yes, it's all principles and higher good [12:57:54] * av500 got a visit from his local pirate party candidate at home [12:58:14] <hyc> well, *someone* has to have some principles around here [12:58:15] <mru> did he bring some dvds? [12:58:32] <av500> "she" did not and my wife described here as a "geek type" [12:59:21] <kierank> do they have a serious campaign? [12:59:29] <av500> "there was a woman here today who looked like she works with computers" [12:59:38] <av500> kierank: here in .de, yes [12:59:50] <kshishkov> s/.de/.se/ [12:59:57] <mru> both [13:00:02] <mru> it's a total joke in the uk [13:00:02] <kshishkov> .se is better [13:00:09] <av500> the best! :) [13:00:14] <kshishkov> all politics is a total joke in UK [13:00:21] <peloverde> to better articulate my opposition against freetards, I think saying software patents can just be avoided expresses a certain naivety [13:00:32] <av500> mru: come on, you are ruled by a house of lords... [13:00:43] <mru> peloverde: you're being far too polite [13:01:08] <peloverde> I think some of them are legitimately naive [13:01:20] * pross-au puts fingers in ears and signs alalalallaala [13:01:21] <mru> is there such a thing? [13:01:32] <KotH> peloverde: allah? ;) [13:01:41] <pross-au> to admit software patents are a problem, is to admit defeat. [13:02:00] <mru> ALLAH AKBAR! [13:02:01] <kshishkov> avoided - no, ignored - hell yes! [13:02:14] <peloverde> the first step of fixing a problem is admitting you have one... or something like that [13:02:23] <mru> now let's draw mohammed! [13:02:44] <mru> is there an official smiley for a beard? [13:02:51] <hyc> :} [13:02:53] <pross-au> :} [13:02:53] <kshishkov> :)> [13:02:57] <mru> and turban? [13:03:00] <kshishkov> { [13:03:03] <pross-au> [:} [13:03:04] <hyc> hm, ya got me on that [13:03:10] <janneg> =:)> [13:03:43] <hyc> dunno about avoiding s/w patents. better to just abolish them [13:04:50] <hyc> keep patents purely in the physical realm [13:05:09] <kshishkov> and in very strict limits [13:05:11] <mru> kill those too [13:05:12] <janneg> there are far too many and they are too vagely described to even find most of the ones you possibly violate [13:05:21] <mru> patents have outlived their purpose [13:05:26] <hyc> and if you develop a hardware process that someone is able to reproduce in software, tough luck. software is not hardware, so patent doesn't cover. [13:05:27] <peloverde> agreed, now if the freetards dumped as much money is lobbying as in funding freetard codecs maybe we'd have a shot at it [13:06:01] <kshishkov> mru: the UK once had it right - they granted each patent with Parliament act [13:06:23] <hyc> that would certainly slow things down ;) [13:06:49] <mru> patents only worked when the invention was still useful much longer than the patent validity [13:07:06] <hyc> I dunno, there's so many people entrenched in keeping the patent system alive, who would have to look for legitimate work after that [13:07:06] <mru> and when the system wasn't subject to constant abuse [13:07:11] <av500> patents were meant to allow others to do what you do, in exchange for a license, if I am able to do pinch zoom without reading the patent - in dont need to pay - so easy... [13:07:20] <kshishkov> with current situation it's not the inventor who benefits from patent (much) which defies its original purpose [13:07:31] <hyc> hard to believe any one movement would have enough lobbying power to get rid of them completely [13:07:39] <kshishkov> hyc: because it's $$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$ or so [13:07:42] <mru> so let's start shooting lawyers [13:07:48] <twnqx> and lobbyists. [13:07:50] <av500> kshishkov: you forgot one $ [13:07:50] <hyc> that might work [13:07:52] <mru> same thing [13:08:07] <kshishkov> av500: I forgot many of them [13:08:10] <twnqx> lobbyists are more often retired politicians [13:08:23] <kshishkov> who keep their source of bribes [13:08:28] <mru> and many politicians are lawyers [13:08:32] <hyc> right, patents were meant to allow you to license something from someone else that you couldn't figure out on your own [13:08:40] <av500> hyc: right [13:08:50] <hyc> but now, if you independently invent the same thing, you're in breach [13:08:52] <hyc> that's BS [13:09:06] <mru> that was always the case [13:09:13] <hyc> ok,true [13:09:17] <hyc> but it's still BS [13:09:23] <mru> but the idea was that patents would only be granted for things very unlikely to be invented by several people [13:09:25] <hyc> but ... it was much less of a problem before [13:09:44] <hyc> because it was seldom possible to independently invent something that was actually patent worthy [13:09:44] <av500> there is that nice article about the steam engine patent [13:09:52] <mru> hence the requirement for the invention being non-obvious to someone skilled in the relevant art [13:09:52] <twnqx> <hyc> right, patents were meant to allow you to license something from someone else that you couldn't figure out on your own <- no, patents were to protect the small inventor from the large company who would just have him carry the burden of development, then reap the rewards [13:10:15] <mru> the idea of patents was good [13:10:41] <hyc> twnqx: ok. [13:10:43] <av500> somebody should have patented it... [13:10:53] <kshishkov> meta-patented [13:11:31] <hyc> one of my previous ideas was to prevent corporations from owning IP. if you work at a company and create something that gets patented, you keep it, not the corp. [13:11:49] <kshishkov> and did it work out? [13:11:53] <av500> hyc: you are free to negotiate that with the corp [13:12:01] <hyc> if they want to be able to use it without a license, they need to keep you happily employed [13:12:03] <mru> av500: free to try [13:12:08] <av500> sure [13:12:13] <kierank> well it would be part of your employment contract [13:12:39] <av500> corp might remind you that it pays you for your time btw... :) [13:12:48] <hyc> kierank: to an extent. the idea is that your employment contract can't make you sign anything over. [13:13:01] <av500> hyc: why not= [13:13:03] <av500> hyc: why not? [13:13:28] <hyc> av500: because I don't think corporations are natural persons, and should not have the right to own things. [13:13:47] * av500 goes out to re-own the local bank [13:14:21] <hyc> IP should belong to the individual creators, that's all [13:14:21] <av500> damn, the security gaurd said "hyc? never heard of him" [13:14:27] <hyc> :P [13:14:30] <pross-au> nothing wtong with a 'limited' monopoly on inventions and artwork [13:15:07] <hyc> right now, corporations have so much vested in preserving their huge patent portfolios [13:15:07] <mru> yes, limited [13:15:26] <hyc> and they wield them like large clubs, bludgeoning everyone else around [13:15:45] <pross-au> with the pace of technology, that limit should be 10 years or something. [13:15:58] <hyc> that would happen less often if the patents belonged to the individuals, not the corps [13:16:17] <mru> pross-au: http://a-hackers-craic.blogspot.com/2010/05/australian-bananas-suck.html [13:16:41] <pross-au> on the other hand, patents make the research/work public [13:17:01] <hyc> true, it's better for the world than everything staying trade secret [13:17:10] <mru> not really [13:17:20] <av500> I'd prefer the 1click to have stayed a trade "secret" [13:17:23] <mru> they can refuse to license it [13:17:36] <av500> ppl would have puzzled for years how it works [13:17:37] <mru> a plain old secret can be legally reverse engineered [13:18:43] <pross-au> yep [13:19:08] <av500> but it would have been hard to have e.g. mpeg standardisation with trade secrets [13:19:28] <mru> they could still make money selling implementations [13:19:34] <pross-au> exactly [13:19:40] <mru> but then they'd have to make actually good encoders [13:19:42] <pross-au> make money producing things people want [13:19:45] <mru> and that's :effort: [13:19:51] <hyc> sigh... [13:19:51] <pross-au> a free maket? [13:19:54] <pross-au> *market [13:19:55] <av500> and designing h264 is not? [13:20:19] <hyc> make money by producing things that are actually worth paying for [13:20:57] <hyc> when the EULA for a product disclaims fitness for any purpose, you're paying money for something that wasn't fit to be sold. [13:20:58] <mru> patents are work once, get paid forever [13:21:40] <hyc> mru: not quite forever. copyrights are forever. :P [13:21:47] <mru> and diamonds [13:22:05] <hyc> all of it is a broken system, and it was broken by the large corps who own all of the IP [13:22:20] <janneg> and if forever arrives copyrights are extended for Disney [13:22:23] <hyc> take away their ownership, and it removes their ability to profit from these stupid games. [13:22:29] <janneg> s/if/when/ [13:22:42] <pross-au> copyrights are not forever [13:22:52] <mru> some are [13:22:54] <hyc> 70+ years now, close enough [13:22:57] <TheFluff> in practice they are because the terms just keep getting longer and longer [13:23:01] <KotH> pross-au: do you know the mikey mouse law? [13:23:01] <hyc> yep [13:23:25] <TheFluff> nothing produced after ~1930 will ever get into the public domain at this rate [13:23:26] <pross-au> Yeah, that mickey mouse steamboat video is Public Domain here [13:23:36] <TheFluff> (in the US, that is) [13:23:57] <pross-au> Change your government [13:23:57] <KotH> pross-au: not for long [13:24:04] <mru> and nowadays many copyrights belong to companies [13:24:04] <KotH> pross-au: just wait until ACTA gets passed [13:24:05] <peloverde> in practice no new works will enter the public domain except for a handful of things that copyright law explicitly excludes [13:24:38] <mru> do the 70 years start counting when the company is bankrupt or what? [13:24:56] <hyc> and then there's government funded research, where the results are given to a private corporation to monetize [13:24:59] <peloverde> the allegedly "originalist" justices on the us supreme court have no problem with this [13:26:16] <hyc> yeah, most of the current govt needs to just be thrown out. and a lot of constitutional amendments, and most new laws written since the 1930s [13:26:48] <mru> it's not just govt that's a problem [13:27:01] <mru> is the way businesses are locked into these bizarre ways [13:27:18] <mru> everybody knows everything they say is bullshit [13:27:30] <mru> but they have to say it because everybody else is saying it [13:27:39] <mru> and if you don't say it you'll look bad [13:28:12] <mru> biggest cargo cult operation ever [13:28:41] <KotH> mru: afaik, the 70 years start counting from the moment on, when the _original_ author dies [13:28:46] <KotH> mru: but IANAL [13:29:27] <TheFluff> isn't it 90 years in the us now [13:30:15] <peloverde> it's [13:30:23] <peloverde> FFMAX(90, life+70) [13:30:39] <TheFluff> 95 years from publication or 120 years from creation whichever is shorter (anonymous works, pseudonymous works, or works made for hire, published since 1978)[298] [13:30:43] <TheFluff> 95 years from publication for works published 1964-1977; 28 (if copyright not renewed) or 95 years from publication for works published 1923-1963 (Copyrights prior to 1923 have expired.)[299] [13:30:47] <TheFluff> says wikipedia [13:30:50] <TheFluff> 70 years for works published after 1978 [13:31:13] <TheFluff> 70 years after death of creator, that is [13:31:29] <av500> the creator is dead? omg [13:32:07] <TheFluff> lorf [13:36:15] <av500> opensuse supports vp8? [13:37:54] <kshishkov> yep, opensuse is very evil [14:00:21] <dezodorant> hi all [14:00:41] <dezodorant> got nice bug/feature in probing [14:01:50] <dezodorant> libav detecting wrong bit rate, if first packet 0-length [14:03:56] <dezodorant> in "FFmpeg version SVN-r0.5.1-4:0.5.1-1ubuntu1" detection was fine [14:05:36] <BBB> might want to report that on roundup.ffmpeg.org [14:05:41] <BBB> as a regression [14:05:50] <BBB> lu_zero: I like it, if you can make the html that'd be great [14:05:56] <jai> against trunk revisions [14:15:33] <lu_zero> ping me this night [14:17:30] <lu_zero> hopefully I'll have the split images by that time [14:17:37] <lu_zero> otherwise I'll split them mysel [14:19:55] <lu_zero> f [14:20:23] <av500> dont split yourself [14:20:48] <kshishkov> yes, fork yourself! [14:21:38] <KotH> no! dont! a child process is very time consuming! [14:21:49] <BBB> what if you have twins? [14:22:34] <mru> what if fork() occasionally created two new processes? [14:22:38] <janneg> forked long time ago if identical [14:22:44] <kshishkov> BBB: thrice as worse - synergy! [14:23:08] <BBB> awesome [14:23:13] <BBB> kshishkov: how's your vp8 decoder going? [14:23:27] <mru> kshishkov is working on a vp8 decoder? [14:23:36] <KotH> native vp8 decoder? [14:23:41] <av500> I doubt it, it has specs, so no fun [14:23:49] <mru> we already have a naive one, only add t [14:23:50] <kshishkov> no, I just expressed agreement with mru on idea to have native one for FFmpeg [14:24:20] <kshishkov> I should be able to start working again soon [14:25:02] <av500> you dont work now? [14:25:04] <BBB> looking through the sources is fun [14:25:07] <dezodorant> https://roundup.ffmpeg.org/issue1954 , but i`m wondering - is it normal to place such packets at the begining [14:25:09] <BBB> much easier than RE'ing [14:27:55] <kshishkov> I tend to disagree [14:28:05] <kshishkov> in both cases you need to understand their logic [14:28:07] <mru> c++ is easier to RE [14:29:11] <kshishkov> RV4 decoder was C++ [14:31:38] <BBB> the logic is easier if you know where to start [14:31:51] <BBB> having a haeder file telling you which function is init/decode/etc. makes things easier [14:32:22] <kierank> that is true [14:33:01] <mru> if you have a dll there are usually named entry points [14:33:42] <kshishkov> yes, good luck with COM [14:35:45] <BBB> the named entry points are usually called "DllServer" [14:35:49] <BBB> that isn't terribly helpful [14:38:27] <kshishkov> what is not really helpful is that loads of functions are called via dynamic function pointer tables [14:39:02] <BBB> right [14:39:16] <BBB> DllServer in my case tends to load a function ptr table, call into it and that's all I know [14:39:17] <BBB> it sucks ass [14:39:23] <BBB> I prefer documented sources [14:39:27] <BBB> no matter how illogically documented [14:39:30] <BBB> they are documented [14:39:43] <kshishkov> well, VfW codecs are usually easy to RE [14:41:14] <BBB> the sources are funny [14:41:25] <BBB> "next 3 bytes are width and height, 12 bits each" [14:41:28] <BBB> then the code does: [14:41:45] <BBB> width = read_be16(data+3) & 0x3fff; [14:41:51] <BBB> height = read_be16(data+5) & 0x3fff); [14:42:01] <BBB> something is confusing there [14:42:12] <mru> comments are evil [14:42:17] <BBB> heh :) [14:42:29] <BBB> I think the code is wrong [14:42:35] <BBB> there is a comment and a check of width height [14:42:38] <BBB> and they're all commented out [14:42:44] <BBB> and there's a second function that re-reads them [14:42:47] <mru> the comment is commented out? [14:42:58] <BBB> sorry, a printf [14:43:16] <kshishkov> is it read the same way second time? [14:43:56] <kshishkov> also I have some experience understanding TrueMotion VP2 source [14:44:14] <BBB> the function is called "peek_si" [14:44:20] <BBB> suggesting there is a second "get_si" or so [14:44:25] <BBB> but doesn't appear to be that way [14:44:28] <BBB> maybe the comment is wrong [14:44:30] <BBB> dunno [14:44:35] * BBB goes find a webm movie [14:44:43] <kshishkov> www.youtube.com? [14:45:45] <av500> BBB: http://lachy.id.au/lib/media/elephantsdream/Elephants_Dream-360p-Stereo.webm [14:45:59] <BBB> fantastic, thank you [14:46:04] <av500> http://lachy.id.au/lib/media/elephantsdream/Elephants_Dream-720p-Stereo.webm [14:46:10] <BBB> 1 is enough :) [14:48:23] <j0sh_> is webm streamable? [14:48:33] <mru> it's mkv [14:48:59] <j0sh_> mkv restricted to vp8 and vorbis basically? [14:49:29] <twnqx> if i read it correctly only stripped by some rarely used features [14:49:39] <twnqx> though Dark_Shikari didn't go into details :P [15:03:51] <BBB> twnqx: mkv isn't that bad, so little to complain there [15:04:09] <BBB> j0sh_: hey there [15:18:22] <dezodorant> any audio gurus here ? [15:18:38] <kshishkov> what specific area of audio? [15:18:41] <BBB> ask :) [15:18:55] <hyc> the answer is 42 [15:18:59] <av500> the MOD guru is not in today... [15:19:26] <dezodorant> i got a lot of audio helpers and classes for processing [15:19:47] <Tjoppen> BBB: did you see my example test program based on libmicrohttpd? [15:19:56] <dezodorant> and planing to start project for common audio tasks [15:20:18] <dezodorant> only one part is missing - decoding [15:20:37] <dezodorant> now i`m using libav for this purposes [15:21:56] <dezodorant> but i do not need lot of stuff from libav and want to fork some audio related code from libav [15:22:20] <dezodorant> so question: is it ok ? [15:22:24] <twnqx> why fork? why not contribute back and improve? [15:22:34] <dezodorant> c++ [15:22:39] <twnqx> yuck [15:22:40] <mru> that's not ok [15:23:01] <dezodorant> ;-( [15:23:46] <mru> calling libavcodec from c++ works fine [15:23:49] <BBB> dezodorant: I don't see why you wouldn't just use ffmpeg without encoders [15:23:57] <mru> for values of fine compatible with c++ [15:24:00] <BBB> forking code is bad practice and will most likely just frustrate both you and us [15:28:21] <dezodorant> most part of my framework already compleated and written in c++, so hardly they will be usefull for ffmpeg [15:28:43] <dezodorant> probing and formats implemented in c++ too [15:28:59] <dezodorant> only codecs i want to take [15:29:46] <mru> so call libavcodec from your code [15:29:48] <mru> it's not hard [15:33:07] <dezodorant> as a variant [15:34:51] <av500> dezodorant: I do the same, I use ffmpeg only for the codecs [15:34:56] <av500> works fine [15:35:50] <j-b> is James Zern on IRC? [15:42:15] <peloverde> i guess not? [16:04:42] <hyc> rtsp over http? why not just use plain http then??? [16:05:37] <siretart> a usable C++ wrapper library that would encapsulate (most) important data structure of lavc and lavf would be awesome, I guess. [16:06:04] * mru fails to see why [16:06:26] <Compn> hyc : rtsp (and i think rtmp does this too) does http tunneling for people behind corporate firewalls etc [16:06:33] <elenril> a python wrapper would be nice [16:07:22] <dezodorant> python is slooooowly [16:07:34] <elenril> nah, not really [16:07:43] <dezodorant> yes it is yes it [16:07:51] <Compn> av500 : what do you play on the videowall ? i have some ideas like 'tokyo scanner' or some imax movies :P [16:07:57] <dezodorant> and no threading ) [16:07:59] <av500> BBB! [16:08:10] * BBB kicks av500 [16:08:12] <Compn> big buck bunny eh [16:08:28] <av500> yes, rendered in really huge [16:08:40] <kierank> I also have a suggestion but it's a little nsfw [16:08:47] <kierank> but it was filmed in 4k [16:08:57] <av500> kierank: I was asking for 4k all the time :) [16:09:00] <av500> gimme [16:09:03] <Compn> also there are a bunch of software freedom documentaries, altho those are mostly boring interviews and dont show off much [16:09:27] <peloverde> Why does gcc assume I don't know order of operations? [16:10:13] <mru> gcc assumes you're stupid [16:11:20] <hyc> most people *are* stupid so it's a safe assumption [16:11:24] <mru> last year TI got slapped for showing quake3 [16:11:30] <mru> nsfw might not be a good idea [16:11:37] <peloverde> Multiplication comes before addition, they taught us that in elementary school [16:12:24] <mru> and and is like mul and or is like add [16:12:26] <janneg> FPS shooter is more problematic than nudity [16:12:31] <av500> mru: huge BBB and the fosdem loop shold be ok [16:12:36] <av500> should [16:12:49] <mru> janneg: in europe yes [16:12:58] <mru> in the US it's probably the opposite [16:13:24] <Compn> tokyo scanner is just a bunch of zooms + pans around tokyo via glider or airplane, and most of those imax movies are rated G too :P [16:13:55] <Compn> er, its a helocopter i remember now [16:13:56] <Compn> heh [16:14:18] <mru> but is it available in 4k? [16:14:40] <BBB> \o/ [16:14:49] * BBB can print the size of a vp8 keyframe [16:15:07] <mru> INT_MAX? [16:15:40] <Compn> no, i was only able to find mpeg2 version and its full of blocks :\ [16:15:43] <ramiro> off topic, is dlfcn.h supposed to be #include'able by c++ without extern "c"? [16:15:56] <ramiro> I don't know what spec to refer to to find this [16:15:59] <jai> BBB: working on a native decoder? [16:16:05] <mru> the C++ spec doesn't mention that header afaik [16:16:26] <mru> ramiro: http://www.opengroup.org/onlinepubs/009695399/basedefs/dlfcn.h.html [16:16:35] <mru> the spec is defined in C [16:16:55] <mru> I suspect using those interfaces from other languages is undefined [16:17:17] <ramiro> mru: thanks, so I don't have to bother with c++ [16:17:51] <mru> as far as posix is concerned, c++ doesn't exist [16:18:06] <hyc> ah, if only the rest of the world were so sane [16:18:31] <ramiro> mru: this is the reason I asked http://code.google.com/p/dlfcn-win32/issues/detail?id=7&can=1 [16:18:44] <ramiro> it had appeared in the past and I had answered http://code.google.com/p/dlfcn-win32/issues/detail?id=1&can=1 [16:19:37] <TheFluff> dezodorant: if you only want audio decoding and nothing else http://code.google.com/p/ffmpegsource/ could be useful to you I guess [16:19:49] <mru> the glibc header has the c++ guards but that doesn't mean anything [16:19:54] <TheFluff> audio support is kinda unreliable though [16:21:28] <dezodorant> TheFluff: i already have wrapper ) [16:21:42] <TheFluff> what are you asking for then [16:21:45] <av500> dezodorant: add another one [16:21:55] <av500> you need at least 5 [16:22:25] <dezodorant> av500: http://s.lurkmore.ru/images/1/1b/Dont_drink_1.jpg [16:22:47] <TheFluff> use of ffms2 is also kinda debatable depending on what you want to do, in most scenarios that don't require sample-accurate seeking it's usually easier, faster and less buggy to just use ffmpeg itself directly [16:23:07] <av500> dezodorant: a russian that does not drink does not exist [16:23:28] <dezodorant> av500: lolwut [16:24:50] <dezodorant> i`ll go to feed my bear [16:25:12] <dezodorant> and play balalaika ) [16:27:13] <hyc> hmm. It seems if I specify -s XxY for the output from ffmpeg, and the X:Y aspect ration doesn't match the input, then ffmpeg will scale to the new size and lose the original aspect ratio [16:27:34] <hyc> is there a way to force it to preserve the original input aspect ratio? [16:28:22] <janneg> afaik only with manual padding or specifying a pixel aspect ratio [16:28:50] <hyc> that's what i thought. ok. was hoping I wouldn't have to calculate the padding myself. [16:29:02] <janneg> there was recently a related ml post [16:30:11] <hyc> how recent, this month? I'll check the archive [16:30:38] <janneg> 2-3 months ago [16:30:43] <hyc> ok [16:30:47] <janneg> i'm looking for it [16:32:31] <hyc> March, Video size to fit in screen ? [16:36:06] <janneg> not finding that one [16:36:34] <hyc> this is what I found https://lists.mplayerhq.hu/pipermail/ffmpeg-user/2010-March/024548.html [16:38:23] <janneg> no, I'm not reading -user. It was a patch micheal rejected for not using avfilter iirc [16:39:08] <hyc> ah ok [16:46:38] <janneg> there's "Mar 03 VolodyA! V Anarh [FFmpeg-devel] [PATCH] pixel aspect ratio" which was subsequencely implemented as avfilter but I don't think I meant that one [16:50:45] <hyc> hmm, says it's already committed [16:53:19] <janneg> hyc: libavfilter/vf_scale.c has "-1 = keep original aspect" [16:54:17] <janneg> so -s 640x-1 should preserve the aspect [16:54:25] <hyc> hm, cool. [16:54:45] <hyc> I'll try that, thanks! [16:57:11] <hyc> nope, got "Incorrect frame size" [17:06:05] <janneg> hyc: -vf scale=640x-1 doesn't work either [17:07:18] <hyc> bummer [17:07:37] <janneg> but -vf scale=640:-1 does [17:09:07] <hyc> yeah, cool [17:09:52] <hyc> hm. not sure I can configure that in ffserver.conf [17:24:23] <superdump> is anyone here familiar with 'tc' from iproute? [17:24:37] * mru has heard of it [17:25:04] <mru> <cv>I have 10 years experience</cv> [17:25:05] <superdump> i'm trying to rate limit all traffic on a network device [18:16:05] <mru> t-shirt idea: what is your favourite colour? [18:20:26] <janneg> bikeshed [18:20:56] <mru> too obscure? [18:24:27] <BBB> peloverde: holy mother 142kb? [18:24:35] <mru> mostly tables [18:26:28] <janneg> mru: probably. something vp8/webm related would be good [18:26:45] <mru> I'm sick and tired of that already [18:27:00] <mru> and we already did html5 [18:27:27] <janneg> "webm, faster, ffmpeg" [18:27:42] <BBB> too much google hype [18:27:50] <Dark_Shikari> s/google// [18:27:51] <mru> I'd rather not give that abomination more publicity than necessary [18:28:18] <hyc> too late ;) [18:28:29] <Dark_Shikari> notice how all the freetards hate google [18:28:33] <Dark_Shikari> until google releases vp8 [18:28:37] <Dark_Shikari> then for a short period, they love google [18:28:41] <Dark_Shikari> then they'll go back to hating google again [18:28:43] <mru> I did briefly reflect over that [18:29:01] <mru> how google become evil though? [18:29:05] <mru> they used to be cool [18:29:11] <BBB> privacy bla bla [18:29:20] <Dark_Shikari> the big guy is always evil [18:29:21] <BBB> as long as lefty aclu organizations start hating you [18:29:25] <BBB> you get bad press [18:29:25] <Dark_Shikari> when the little guy becomes the big guy [18:29:27] <BBB> and everyone hates you [18:29:30] <Dark_Shikari> they become evil [18:29:38] <BBB> everyone being freetards and other incompetent, lazy and useless lefties [18:29:39] <mru> rule #1: what happens on the internet, stays on the internet, _forever_ [18:29:48] <hyc> well, power corrupts [18:29:56] <BBB> hehe, see facebook? [18:30:00] <hyc> so naturally, when the little guy becomes the big guy, they also become evil [18:30:18] <mru> I don't have a problem with facebook [18:30:19] <Dark_Shikari> and absolute power corrupts absolutely [18:30:36] <mru> I wouldn't put anything on there that I'd mind if anyone saw [18:31:23] <hyc> yeah, anyone putting private stuff on an online forum is just asking for trouble [18:31:33] <hyc> doesn't matter if it's facebook or anything else [18:31:43] <hyc> if it's supposed to be private, keep it off the net [18:34:54] <hyc> hmmm... ffm transfers height/width as 16 bit numbers [18:35:06] <hyc> I guess you won't be realtime-streaming to any video walls [18:35:50] <mru> ours is only 3840 wide [18:35:53] <CIA-7> ffmpeg: michael * r23202 /trunk/libavformat/avidec.c: [18:35:53] <CIA-7> ffmpeg: Disable non interleaved avi code when there is no index available. [18:35:53] <CIA-7> ffmpeg: Fixes issue1956. [18:36:08] <hyc> I was actually looking to see if I can pass a -1 in there [18:36:16] <hyc> but most likely it would be treated as 65535 [18:36:20] <kshishkov> mru: can I get 3XL T-shirt? [18:36:39] <mru> kshishkov: if they have that size [18:36:54] <kshishkov> and dark gray? [18:37:08] <ramiro> kshishkov: did you manage to leave your country? or are you just going out for linuxtag? [18:37:16] <mru> standard ffmpeg t-shirt is black [18:37:40] <kshishkov> mru: only before first wash :P But I shan't mind [18:37:40] <hyc> yah, bummer, get_be16 returns unsigned int [18:37:49] <janneg> mru: "troll driven development" for the t-shirt? [18:38:00] <mru> not bad [18:38:03] <_av500_> +1 [18:38:34] <kshishkov> ramiro: no, I just happen to live in Germany right now [18:38:48] <hyc> heh heh... "boy OMAP3 is really slow at decoding ____" [18:38:48] <kshishkov> ramiro: and I don't consider Ukraine to be my country [18:39:01] <mru> hyc: ? [18:39:02] <_av500_> hyc: where? [18:39:07] <hyc> just trolling :P [18:39:55] <hyc> I think you've got a winner for a t-shirt [18:40:14] <ramiro> kshishkov: oh, I didn't know you had managed to move to germany... [18:40:43] <mru> kshishkov: website says they do 3xl [18:41:15] <kshishkov> ramiro: well, I had some troubles with Internet access away from work [18:42:44] * kshishkov still misses his hemland [18:57:13] <pasteeater> is -devel ML having issues or is it my fault? I haven't recieved anything today. [18:57:32] <peloverde__> I have not had any problems [18:57:34] <mru> seems fine here [18:57:39] <pasteeater> ah, ok. thanks. [18:58:40] <mru> pasteeater: what's your email? I can check logs for anything unusual [19:00:08] <pasteeater> mru: lou at fakeoutdoorsman.com [19:01:05] <mru> pasteeater: connection refused on your mx [19:01:30] <mru> works now though [19:02:02] <mru> hmm, IP address has changed [19:02:12] <pasteeater> damn it! stupid cloud-thing. i know what to do. thanks for looking. [19:12:04] <Compn> heh [19:25:05] <elenril> so PS is done? [19:25:34] <mru> posted to ML != done [19:25:47] <mru> you have a + so you should know that [19:25:57] <elenril> hm i don't [19:26:03] * elenril wonders where did it go [19:26:26] <elenril> nvm, /me just fails at reading [19:28:14] <elenril> anyways, the end of faad is near! [19:31:40] <BBB> let's kill libvpx [19:32:22] <mru> KILL KILL [19:32:48] <mru> anyone working on a proper decoder yet? [19:36:26] <BBB> I'm reading libvpx and have a skeleton vp8dec [19:36:30] <BBB> that's about it [19:36:37] <Dark_Shikari> lol [19:36:50] <BBB> I want to see how it works before doing anything stupid [19:36:57] <BBB> the bitstream doesn't seem particularly difficult [19:37:55] <mru> comparing against vp[56].c might be useful [19:38:03] <mru> there's bound to be something similar in there [19:38:24] <Dark_Shikari> yes [19:38:46] <Dark_Shikari> you'll have to write vp8 versions of the intra pred code [19:38:55] <mru> companies like to reuse their oldest, most pungent code for the longest time [19:39:12] <mru> probably because whoever wrote it is a director now [19:40:03] <Yuvi> the fun vp3 (i)dct that had a huge amount of leakage and only used (16x16 bit)>>16 multiplies was used until vp7 [19:40:17] <Dark_Shikari> vp8 still uses 16x16>>16 [19:40:22] <Yuvi> :/ [19:40:51] <Yuvi> signed x unsigned still too? [19:41:20] <Dark_Shikari> not sure [19:41:21] <Dark_Shikari> check the code [19:41:24] <Dark_Shikari> they had big constants [19:41:26] <Dark_Shikari> e.g. bigger than 32k [19:42:06] <mru> ugh [19:44:03] <mru> BBB: any word on that licence yet? [19:44:11] <BBB> trying to get a word from them [19:44:14] <BBB> nothing final yet [19:45:31] <Yuvi> yep, 16 bit unsigned x signed [19:46:00] <Yuvi> which requires two instructions on like every simd set ever [19:47:12] <Yuvi> and they have a constant rounding of 0, why is that still in the code :/ [19:50:16] <Yuvi> at least it wasn't copy pasted into the spec [19:51:53] <_av500_> mru: btw, I sent nvidia the vp8 question today... [19:52:10] <mru> let's see if they answer you [19:52:24] <_av500_> they will [19:52:57] <mru> my trolling on the forums hasn't been very successful [20:00:39] <Vitor1001> Dark_Shikari: Just wondering, how much of code of x264 could one reuse to a vp8 encoder? [20:00:52] <Dark_Shikari> motion search: 100% [20:01:02] <_av500_> golden frames: 0% [20:01:03] <Dark_Shikari> scenecut decision and ratecontrol: everything but the b-frames [20:01:15] <Dark_Shikari> mb-tree: everything [20:01:27] <Vitor1001> does x264 support disabling b-frames already? [20:01:29] <Dark_Shikari> yes [20:01:37] <Dark_Shikari> intra: everything, with small changes [20:01:40] <Dark_Shikari> entropy coder: rewrite [20:01:43] <Dark_Shikari> quant/macroblock encode: rewrite [20:01:45] <Dark_Shikari> dct: rewrite [20:01:49] <Dark_Shikari> mv pred: rewrite [20:01:54] <Dark_Shikari> you could reuse most of mode decision [20:02:41] <Vitor1001> And how better would a franksteinish x264/libvpx mixture be than libvpx alone? [20:02:55] <Dark_Shikari> well, suppose we did an x264 -> vpx conversion without using much of vpx [20:02:59] <Dark_Shikari> things we would NOT have: [20:03:02] <Dark_Shikari> golden/alt ref frame [20:03:08] <Dark_Shikari> sub8x8 modes (easier to omit them) [20:03:20] <Dark_Shikari> and a few other minor things I think [20:03:20] <BBB> what is a goldenframe? [20:03:29] <Dark_Shikari> It would still beat the living fuck out of libvpx [20:03:30] <BBB> it's a p-frame that is used as reference? [20:03:43] <Dark_Shikari> It's a second reference frame. [20:03:45] <Dark_Shikari> With a special name. [20:04:31] <_av500_> Dark_Shikari: but do you see any actual point in it? or just on2 cargo cult? [20:04:32] <BBB> do goldframes have the keyframe flag set? [20:04:43] <BBB> if no, then the parsing likely resembles more a p-frame style than a i-frame style [20:04:49] <Dark_Shikari> BBB: any frame can be a golden frame [20:05:00] <BBB> ok [20:05:06] <BBB> and how's that different from altref? [20:05:12] <Dark_Shikari> altref frame can be used to emulate b-frames sorta weirdly [20:05:17] <_av500_> altref is not shown [20:05:32] <Compn> Dark_Shikari : are you saying something like how h263 can be formed into mpeg4asp ? like vpx can be formed into h264base ? [20:05:38] <BBB> notshown is a flag [20:05:44] <Dark_Shikari> Compn: it's a bit more rewriting than that. [20:05:47] <BBB> altref is not the same as notshown, I think [20:06:15] <_av500_> BBB: what sense does it make to decode a frame and not show it if it is not a ref? [20:06:43] <BBB> altref is ref ? [20:06:51] <janneg> killing decoding time [20:07:04] <_av500_> janneg: because_we_can :) [20:11:09] <janneg> maybe an eloberate way of maintaining constant bitrate [20:20:57] <mru> or maybe it's just a bug that made it into the spec [20:22:41] <_av500_> unthinkable [20:23:23] <mru> Dark_Shikari: steve jobs or someone impersonating him reads your blog [20:23:26] <mru> http://www.theregister.co.uk/2010/05/20/jobs_on_vp8/ [20:24:01] <Dark_Shikari> what, fakesteve? [20:24:09] <Dark_Shikari> WAIT WHAT? [20:24:25] <JEEBsv> haha [20:24:29] <Dark_Shikari> WHAT WHAT WHAT? [20:24:33] <_av500_> realsteve [20:26:12] <drv> apparently steve reads your blog :P [20:28:02] * _av500_ blames Dark_Shikari for aapl not supporting the open web standards [20:28:38] <BBB> Dark_Shikari: see, now this is why you should shut up about ffmpeg's h264dec being slow and just make it faster, or claim it is faster [20:28:46] <mru> jobs has a nice way with brevity sometimes [20:28:49] <Dark_Shikari> should I thank him for referencing my blog post? [20:28:51] <BBB> now the whole world will read that our h264dec is the slowest in the world [20:29:12] <BBB> btw, lol@"third-year college student" [20:29:23] <mru> it's true [20:29:48] <BBB> that's not the point [20:30:28] <mru> I though we were in the business of writing code, not selling lies [20:34:05] <BBB> fair enough [20:34:12] <BBB> Dark_Shikari: go write some code you third-year college student! [20:34:32] <BBB> did anyone notice that their vpx_read_bit() is really big? [20:35:01] <mru> what is its purpose? [20:35:06] <mru> get_bits1()? [20:35:49] <BBB> I think so, but it's incredibly complex [20:35:57] <BBB> for a get_bits1(), I mean [20:44:04] * Kovensky thinks someone should add "<@BBB> Dark_Shikari: see, now this is why you should shut up about ffmpeg's h264dec being slow and just make it faster, or claim it is faster <@BBB> now the whole world will read that our h264dec is the slowest in the world" to the quotes page [20:44:41] * Kovensky also thinks the quotes page should be in the topic :> [20:44:49] <BBB> that would be my deathbed [20:45:38] <Dark_Shikari> all michael has to do is quote it in a quote of his own on the ML [20:45:45] <Dark_Shikari> and then get some other guy to add it to the niedermayer quotes page [20:46:01] <_av500_> nm: ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ [20:46:10] <_av500_> Ãªrr, mn: ^^^^^^^^^^^^^^^^ [20:46:48] <mru> Kovensky: add it to the quotes page yourself [20:46:59] * Kovensky doesn't know the URL :( [20:47:18] <mru> http://wiki.multimedia.cx/index.php?title=Quotes [20:47:30] <Kovensky> mru: add to the /topic :> [20:47:41] <Kovensky> meh, requires account [20:48:06] <mru> ask mike for one [20:48:17] <Kovensky> how2request mike for one [20:48:39] <mru> mailto:mike at multimedia cx [20:49:18] <mru> Dark_Shikari: http://my.opera.com/haavard/blog/2010/05/20/webm-analysis [20:50:48] <Dark_Shikari> seen it [20:50:50] <mru> and what is it with people who don't think companies will spend $100M on junk? [20:50:54] <Dark_Shikari> lol [20:51:00] <Dark_Shikari> yahoo did it for years [20:51:25] <mru> I know many companies whose entire existence depends on others buying their junk [20:51:48] <_av500_> what a load of bs [20:51:54] <_av500_> the article [20:51:59] <Dark_Shikari> "raw" [20:52:02] <Dark_Shikari> "been around for 6+ years" [20:52:08] <mru> av500: of course it's bs [20:52:21] <_av500_> this one: http://my.opera.com/haavard/blog/2010/05/20/webm-analysis [20:52:22] <Kovensky> "Despite claims to the contrary, The WebM format is not set in stone. The WebM FAQ points out that there is a separate development branch for possible future improvements. " <-- didn't you say google said that the *spec* is set in stone [20:52:41] <mru> it's an article by an opera troll relating what a xiph told a freetard mailing list [20:52:42] <_av500_> it is practically set in stone [20:52:53] <_av500_> as it is released with fanfare [20:52:59] <Dark_Shikari> the good thing is that nobody cares about opera. [20:53:01] <Kovensky> <@mru> it's an article by an opera troll <-- I also remember that last name being associated with Trolltech's founding [20:53:40] <Kovensky> Dark_Shikari: Opera is (was?) strong in the non-apple non-microsoft mobile field [20:53:45] <astrange> maybe you should change "similar to H.264 Baseline" to "similar to H.264 Baseline without multiple reference frames" [20:53:53] <Dark_Shikari> astrange: but it has multiple refs [20:54:01] <astrange> not as many [20:54:04] <Dark_Shikari> ok, true [20:54:08] <Dark_Shikari> but most people rarely use more than a few [20:54:13] <Dark_Shikari> and most devices limit to only a few [20:54:19] <_av500_> Kovensky: opera is strong on the iphone :) [20:55:13] <mru> with that thing that renders the pages on their servers and sends only a low-res image? [20:55:34] <mru> and still doesn't get it right [20:55:44] <Kovensky> _av500_: it is? [20:55:59] <Kovensky> though I never checked, people tend to stay with stock stuff if it doesn't suck too much =p [20:56:21] <Kovensky> though people still stay with ie6, so I guess the "if it doesn't suck too much" isn't really relevant [20:57:24] <_av500_> Kovensky: it is #1 download in itunes app store [20:57:53] <Dark_Shikari> does safari on iphone suck that much? [20:57:59] <_av500_> no [20:58:04] <_av500_> having 128mb sucks [20:58:09] <Dark_Shikari> ? [20:58:13] <_av500_> so safari has to drop loaded pages all the time [20:58:23] <_av500_> ipad is even worse [20:58:25] <Dark_Shikari> and opera ... adds more memory to your phone? [20:58:32] <mru> or uses less [20:58:36] <_av500_> no, but seems to keep a smaller page footprint [20:59:04] <_av500_> ppl try to load several pages to read on a flight, then check the gate with another app - pages lost... [20:59:25] <Kovensky> <_av500_> Kovensky: it is #1 download in itunes app store <-- o, they approved it? [20:59:32] <_av500_> Kovensky: indeed they did [20:59:42] <Kovensky> I haven't read anything on the subject ever since they started that site with the "countup" until approval [20:59:53] <_av500_> it got approved fairly quikcly [20:59:54] * Kovensky has over 20 thousand unread items on google reader [21:00:00] <ohsix> suprised they didn't technical it cuz it can run ecmascript [21:00:21] <_av500_> ohsix: i think they feared operas eu leverage [21:00:32] <Kovensky> IIRC opera renders pages on their server and only sends the result? [21:00:37] <astrange> opera mini doesn't run js [21:00:56] <_av500_> Kovensky: yep [21:01:40] * Kovensky never had any cellphone fancier than "takes pics with a shitty 320x240 camera" [21:01:43] <BBB> Dark_Shikari: yes safari sucks [21:01:47] <BBB> Dark_Shikari: it's dog slow [21:01:56] <Kovensky> and the last one I had didn't even have a camera lol [21:02:06] <twnqx> lucky you [21:02:12] <twnqx> those are hard to come by :X [21:02:16] <_av500_> ...Starting today, Google is using WebM to encode all YouTube videos larger than 720p... [21:02:18] <Kovensky> twnqx: lol [21:02:23] <twnqx> you laugh [21:02:27] <_av500_> >720p only? [21:02:28] <j-b> Opera Mini is fast [21:02:28] <mru> twnqx: the last phone I bought has no camera [21:02:45] <twnqx> you don't work with companies who forbid cells with camera [21:02:45] <mru> I went to a shop and asked for the cheapest phone they had [21:03:20] <Kovensky> twnqx: o_O [21:03:49] <Kovensky> what do you work with, chemical weapons? nuclear research? reverse engineering? [21:04:09] <mru> they make camera phones [21:04:12] <Kovensky> ("reverse engineering" as in taken to the level of that ben affleck movie) [21:04:20] <mru> paycheck? [21:04:21] <twnqx> currently the company i work for would like me to have the most modern mobile around (mobile network operator) [21:04:24] <Kovensky> yea [21:04:47] <mru> uma wasn't worth enduring ben in that film [21:05:00] <Kovensky> lol [21:05:11] <Kovensky> the movie wasn't very good but was enjoyable [21:05:37] <twnqx> but i've worked with government agencies and ministries and a car manufacturer, as well as comapnies delivering to that one [21:05:59] <twnqx> those are pretty sensitive. some agencies don't allow any cells in :S [21:06:14] <bcoudurier> hi folks [21:06:15] <twnqx> neither laptops or portable storage [21:06:23] <twnqx> annoying working environment [21:06:25] <mru> twnqx: some companies don't allow any cells, not even brain cells [21:08:05] <janneg> Dark_Shikari: including psnr numbers was an error. it would have spared use the "WebM (sic!) is clearly better than H264 baseline" [21:08:22] <Dark_Shikari> But it is [21:08:26] <Dark_Shikari> vp8 is better than h264 baseline [21:08:31] <Dark_Shikari> It's just that their encoder is shit [21:11:23] * Kovensky wonders if it can be made to approach main's efficiency [21:11:31] <Kovensky> but I guess no because of no bframes [21:11:42] <pJok> Kovensky, ffvp8enc will tell... ;) [21:11:45] <janneg> as long as their encoder is the only one it's not better for practical purposes [21:11:55] <Kovensky> ffmpeg has good video encoders? [21:12:00] <pJok> dunnno [21:12:08] <pJok> mpeg2 seems to be working [21:12:09] <Kovensky> afaik the only good one is -vcodec libx264 :> [21:12:10] <pJok> ;) [21:12:42] <mru> so we need libxvp8 [21:12:58] <mru> or maybe that's xp8 [21:12:59] <mru> not sure [21:14:26] <BBB> call it libx268 [21:15:45] <pJok> it has an 8 in it, it must be better than 4 [21:15:50] <Kovensky> but... think of 40 years in the future! [21:16:09] * Kovensky wonders what will ITU-T do when they run out of H.26d [21:16:26] * pJok wonders if those who thought of 720i and 1080i were thinking of the future or just their wallets right now... [21:16:44] <mru> 720i doesn't exist [21:16:55] <pJok> mru, oh [21:16:58] <pJok> good at least [21:17:13] <BBB> Kovensky: h270 is available [21:17:19] <BBB> or in hex, h26A [21:17:27] <BBB> endless possibilities [21:17:37] <Kovensky> well, h.26A could happen =p [21:17:37] <mru> anyone remember h26L? [21:17:43] <Kovensky> H.270 is allocated to sth else IIRC [21:17:51] * pJok mumbles something about 60fps 1080p should have been the lowest HD broadcast resolution [21:18:04] <_av500_> in 40 years, the survivors will not care for codecs, but for braaaains [21:18:06] <mru> pJok: then you'd still be waiting for it [21:18:18] <mru> _av500_: those are not the survivors [21:18:20] <Kovensky> pJok: they'd just have progressively-encoded interlacing with frame doubling [21:18:38] <Kovensky> LOL [21:18:40] <_av500_> mru: yes, the survivors from in 39.9 years [21:18:48] <pJok> Kovensky, might be, but it'd still be 60fps for when they would eventually stop doubling the frames ;) [21:19:37] <pJok> mru, considering i have a very low def tv at home, im still waiting for HD ;) [21:19:48] * Kovensky sees a brighter future with a working moon base [21:20:00] <pJok> its not like tv gets any better in HD anyways [21:20:03] <_av500_> i found base 16 ok so far [21:20:04] * Kovensky has an analog tv at home, digital broadcast first started last week [21:20:37] <pJok> i think there are only a few bbc programmes that deserve HD broadcast... and possibly a few movies as well [21:20:49] <pJok> but for the rest... give me content instead of HD [21:20:56] <_av500_> +1 [21:21:07] * pJok watches dvd's in œ resolution anyways [21:21:20] * _av500_ wathces stuff on 5" in the tram :) [21:21:20] <mru> http://xkcd.com/732/ [21:21:35] * Kovensky wishes he could watch anything on commute without doing it for the last time [21:22:26] <pJok> mru, thats exactly 100% true [21:23:13] <mru> that said, a 1080p picture _is_ far better than SD [21:23:17] <Kovensky> _av500_: re: survivors: <+hatefulcunt> the survivors will care for loli butts <+hatefulcunt> same as always <+hatefulcunt> Strike Witches season 36 wheeen [21:23:39] <Kovensky> mru: if only for the "smaller" macroblocking [21:23:54] <mru> no, I can't see the scanlines in the display from across the room [21:23:59] <mru> that really does help [21:24:15] <mru> even when watching SD stuff [21:24:45] <_av500_> dpi ftw! [21:25:22] <Kovensky> also re zombie apocalypse: http://xkcd.com/734/ [21:27:52] <CIA-7> ffmpeg: stefano * r23203 /trunk/libavcodec/eval.h: Fix doxy reference to unexisting function. [21:28:07] <bcoudurier> <Kovensky> ffmpeg has good video encoders? [21:28:14] <bcoudurier> is that a joke ? if it is, it is a very bad one [21:31:56] <mru> the video encoders are certainly better than the audio ones [21:32:00] <mru> at least some of them [21:35:17] <_av500_> so, ffmpeg has some encoders that are better than some others... [21:35:23] <Kovensky> lol @ "M-x butterfly" actually "working" on emacs [21:35:48] <mru> new version? [21:38:17] <Kovensky> http://xkcd.com/742/ hah [21:38:19] <Kovensky> mru: 23.2.1 here [21:43:16] <Yuvi> vp8 has a start code... 3 bytes after the beginning of the frame [21:43:33] <_av500_> late start [21:44:43] <janneg> anything important before the "startcode"? [21:45:11] <Yuvi> yes, the frame type, version, and size [21:46:35] <_av500_> so we need ungetbits(24); [21:50:02] <mru> skip_bits(-24) ? [21:50:20] <Yuvi> in the parser though? [21:50:25] <_av500_> mru: good that we made the parameter int :) [21:51:09] <mru> DonDiego: are you coming to linuxtag? [21:51:29] <_av500_> DonDiego: and do you bring yv along? [21:52:15] <DonDiego> i'd like to come to linuxtag [21:52:21] <DonDiego> dunno if yvonne will join [21:52:25] <DonDiego> will ask her tomorrow [21:52:33] <mru> tell her we'd like her to come along [21:52:38] <DonDiego> i will [21:53:00] <mru> I could tell her myself I suppose... [21:53:06] <mru> when whe comes online [21:53:17] <DonDiego> do you have her jabber? [21:53:23] <mru> yeah [21:53:24] <DonDiego> yeah, invite her.. [21:54:15] <mru> so are _you_ coming? [21:54:23] <_av500_> he must

1 0

IRC log for 2010-05-19
by irc＠mansr.com 19 May '10

19 May '10

[00:07:01] <Kovensky> astrange: isn't jfs waiting on your comments; or did you already sent them to he and he's lazy/busy/stuck [00:07:04] <Kovensky> send* [01:18:59] <astrange> i sent them [01:19:07] <astrange> he says he'll update it tomorrow or so [04:15:51] <peloverde_> Could the first two frames in a stream having the same dts be related to the first frame being a "no frame!"? [04:47:28] <hyc> grumble... OK, I sent an FLV file to ffserver, and saved the transcoded data from its feed.ffm [04:47:49] <hyc> then I ran ffmpeg on that, -vcodec copy / -acodec copy to a new FLV file [04:48:06] <hyc> the live feed played fine over rtsp with ffserver [04:48:30] <hyc> but still, trying to play the new FLV over rtsp fails with all kinds of garbage [04:49:31] <hyc> and I've fixed the sdp_write_media_attribute() to send the sps/pps for the FLV case, and wireshark shows that this is now identical to the live streaming case [05:03:11] <hyc> playing audio-only from a file works [05:04:02] <hyc> so it's only H264 video causing trouble [05:30:06] <peloverde> Why does it make sense to set stream start_time based solely on the first audio packet when the vcodec is h.264 and pts is missing? [05:48:50] <hyc> ok. rtpenc_h264.c only knows how to handle H264 NALs that start with the 3 byte startcode [05:49:00] <hyc> it doesn't know anything about AVC1 [05:49:25] <av500> teach it :) [05:49:45] <hyc> trying to... [05:50:17] <hyc> unfortunately it seems that AVC1 NALs start with the NALU length, but the size of that length is not constant [05:50:35] <hyc> gotta see how avcodec/h264.c determines the length [05:50:40] <av500> it is given in the extradata [05:50:51] <av500> nal_unit_length or so [05:51:02] <hyc> so it's constant for the entire stream? [05:51:08] <av500> I thinkl so [05:51:16] <hyc> I don't think rtpenc_h264 has access to the extradata [05:51:16] <av500> I read it once [05:51:23] <hyc> but will dig into that [05:51:33] <hyc> thx for the pointer [06:18:18] <hyc> av500; success! [06:26:59] <wbs> mru: don't think I've ever heard about a krongÃ€dda before, actually [06:27:20] <wbs> mru: but on the other hand, it's over 10 years since I was fishing the normal kind of gÃ€dda last time, too [06:30:08] <superdump> morning [06:40:46] <benoit-1> hej superdump [06:43:29] <peloverde> Is there an obvious reason why H.264 remuxed by ffmpeg would crash MPC and make Haali Splitter refuse to see the video track? [06:47:42] <CIA-7> ffmpeg: benoit * r23170 /trunk/libavcodec/ivi_common.h: [06:47:42] <CIA-7> ffmpeg: Fix signedness of q_delta field of the IVIMbInfo. [06:47:42] <CIA-7> ffmpeg: Patch by Maxim max_pole () gmx * de [06:47:58] <hyc> peloverde: remuxed to what container? [06:48:05] <peloverde> mp4 [06:48:20] <hyc> mebbe it's tripping over the same H264 vs AVC1 variant nonsens that I was just struggling with [06:49:07] <peloverde> That is possible I suppose [06:50:37] <peloverde> There was a "no frame!" at the beginning but the source (ASF) file plays fine in WMP and MPC [07:04:55] <kshishkov> benoit-1: thanks [07:32:09] <peloverde> hyc: looks like you were at least partially right [07:32:45] <hyc> wow, that's pretty good for me on this channel ;) [07:34:19] <wbs> hyc: btw, your sdp/rtp/h264 patch has some reindenting in rtpenc_h264.c [07:34:56] <wbs> other than that, I let the ones knowledgeable on h264 bitstream formats comment on what to do in this case [07:35:23] <peloverde> now I get to play the, how do I put the mov demuxer in atom tree mode game again (I really should write it down) [07:35:35] <hyc> wbs: yes, I couldn't decide whether to fix all the indenting or to leave it for a separate commit [07:35:52] <hyc> that stuff is easy, it seemed more important to have a readable patch for now [07:36:36] <wbs> yeah, but it still is easier to see that the original code is unmodified in the !is_avc if fork if you don't change its indentation, even if it is just 10 lines [07:36:43] <hyc> well, now I know why there's an endless stream of "non-existing PPS referenced" messages [07:37:07] <hyc> the parser is using its own H264Context, separate from the one that was created for the AVCodecContext. [07:37:25] <hyc> only the AVCodecContext has teh extradata that was parsed by the decoder_init [07:38:06] <wbs> which parser is this, one i ffserver? [07:38:12] <hyc> loosely-coupled systems with isolated APIs only work when they're actually coupled ..... [07:38:20] <hyc> this is libavcodec/h264_parser.c [07:41:07] <peloverde> The strange part is that there is an avcC atom here, it's just getting lost in the shuffle [07:41:26] <wbs> yes, but the missing extradata from the parser, where is that parser instantiated? or does the parser never read extradata at all? [07:41:34] <hyc> never [07:41:43] <wbs> oh, goodie [07:41:44] <hyc> av_parser_init() only takes a codec_id [07:41:56] <hyc> this API is really f#cked [07:42:04] <peloverde> Is stts supposed to have 1000s of entries? [07:42:10] <wbs> so whenever the h264 parser is used with h264 that has extradata, one will get those errors [07:42:15] <hyc> yep [07:42:38] <hyc> (was answering wbs. dunno answer to peloverde) [07:43:29] * peloverde dusts of -12, -14, and -15 [07:43:40] <peloverde> s/of/off/ [07:44:37] <wbs> peloverde: possibly, if not all samples have equal duration [07:45:04] <peloverde> I have a terrible feeling that this stream is being treated as VFR [07:45:26] <hyc> the parsers are always called with both an AVCodecParserContext and AVCodecContext argument. perhaps should just change h264_parser to only look at the avcodeccontext [07:46:42] <Yuvi> Last time I tried h264 to mp4 there were +-1 timestamp rounding errors from somewhere [07:47:14] <wbs> haha, wtf.. that youtube rtsp url that had non-monotone packet ordering, is suddenly sending all the packets properly ordered again ;P [07:49:58] <hyc> great.... bug on their end? [07:50:18] <peloverde> Yuvi: Is there a good way to deal with +/-1 timestamp issues? [07:50:28] <wbs> it's google, nobody will know if it's a bug or if it's intentional "tweaking" ;P [07:52:42] <Yuvi> peloverde: Dunno, fix the raw h264 demuxer? Iirc they were due to the multiple timebases it sets up [07:53:38] <peloverde> This file is coming in from the asf demuxer :/ [07:54:13] <Yuvi> Doesn't asf usually use 1/1000 timebases? [07:54:27] <Yuvi> Which would also explain it [07:59:15] <CIA-7> ffmpeg: siretart * r23171 /branches/ (57 files in 9 dirs): [07:59:15] <CIA-7> ffmpeg: mov: Read nero chapters [07:59:15] <CIA-7> ffmpeg: backport r23020 by conrad [08:02:07] <elenril> o_0 57 files? [08:02:55] <CIA-7> ffmpeg: siretart * r23172 /branches/ (0.6/libavformat/movenc.c 0.6): [08:02:55] <CIA-7> ffmpeg: movenc: Swap positions of mov_write_header and mov_write_packet [08:02:55] <CIA-7> ffmpeg: backport r23021 by conrad [08:02:55] <CIA-7> ffmpeg: siretart * r23173 /branches/ (0.6/libavformat/movenc.c 0.6): [08:02:55] <CIA-7> ffmpeg: movenc: Write QuickTime chapters [08:02:56] <CIA-7> ffmpeg: backport r23022 by conrad [08:02:59] <peloverde> roozhou seems to have some patches for this stuff? has he submitted them? [08:03:15] <kshishkov> you haven't seen FATE specs committed to SVN, have you? [08:04:05] <KotH> grüezi wohl [08:04:13] <CIA-7> ffmpeg: siretart * r23174 /branches/ (4 files in 2 dirs): [08:04:13] <CIA-7> ffmpeg: Make av_strerror() return -1 even in the case when av_strerror_r() is [08:04:13] <CIA-7> ffmpeg: not defined. [08:04:13] <CIA-7> ffmpeg: This allows applications to check if av_strerror() cannot provide a [08:04:13] <CIA-7> ffmpeg: meaningful representation for the provided error code, without having [08:04:14] <CIA-7> ffmpeg: to actually check the filled string. [08:04:15] <CIA-7> ffmpeg: backport r23031 by stefano [08:04:15] <CIA-7> ffmpeg: siretart * r23175 /branches/ (0.6 0.6/cmdutils.c): [08:04:16] <CIA-7> ffmpeg: Make print_error() use strerror() in case av_strerror() fails. [08:04:16] <CIA-7> ffmpeg: Should provide a meaningful error message for systems which do not [08:04:17] <CIA-7> ffmpeg: support strerror_r(). [08:04:17] <CIA-7> ffmpeg: Fix roundup issue #1894. [08:04:18] <CIA-7> ffmpeg: backport r23032 by stefano [08:04:52] <CIA-7> ffmpeg: siretart * r23176 /branches/ (0.6 0.6/cmdutils.c): [08:04:52] <CIA-7> ffmpeg: Simplify print_error(), directly use av_strerror()/strerror() for [08:04:52] <CIA-7> ffmpeg: printing the error code associated to FF_NETERROR(EPROTONOSUPPORT). [08:04:52] <CIA-7> ffmpeg: backport r23033 by stefano [08:05:28] <CIA-7> ffmpeg: siretart * r23177 /branches/ (0.6 0.6/cmdutils.c): [08:05:28] <CIA-7> ffmpeg: Reindent after the last commit. [08:05:28] <CIA-7> ffmpeg: backport r23034 by stefano [08:06:49] <siretart> ok. seems my backport script indeed works :-) [08:08:50] <wbs> siretart: would you be interested in backporting 23160 - 23165, too? you could perhaps want to wait a few days with that, though, since it hit svn yesterday [08:09:27] <wbs> on a distro-installed ffmpeg package, that's an end-user feature that makes ffmpeg replace MP4Box for the one feature I've been using it for [08:10:47] <siretart> wbs: thanks for the hint, scheduled for review&backporting [08:11:41] <siretart> technically, I'm "ticking" (flagging) backport candidates in my ffmpeg-cvs mailbox. my backport script presents me the log message and the diff, so I can review, compile and test in place [08:11:50] <wbs> ah, nice. :-) [08:12:08] <siretart> if you know more revisions to backport, just tell me on irc or on the mailing list [08:13:04] <CIA-7> ffmpeg: mstorsjo * r23178 /trunk/Changelog: Add a changelog entry for the RTP hinting in the mov muxer [08:14:02] <CIA-7> ffmpeg: mstorsjo * r23179 /trunk/libavformat/avformat.h: Late bump of the minor version, for the addition of AVFMT_FLAG_RTP_HINT [08:16:38] <siretart> btw, sorry for the delay of 0.6, I've already told diego that I got terribly distracted by real life issues. I'm trying to catch up this week and finally get it out by this week end (though, no promises!) [08:17:14] <CIA-7> ffmpeg: mstorsjo * r23180 /trunk/doc/APIchanges: Add an APIchanges note regarding the new rtp hinting flag [08:17:23] <siretart> the fact that mplayer doesn't compiled against a shared libswscale from ffmpeg 0.6 is annoying, though. [08:17:44] <wbs> woohoo, 100th commit with my own svn account \o/ [08:18:02] <siretart> congrats [08:18:03] <siretart> :) [08:18:19] <wbs> thanks :-) [08:18:30] <hyc> wbs: fixed the non-existing PPS bug... [08:18:35] <twnqx> siretart: the fact that mplayer can't play pgssub is FAR FAR FAR more annoying [08:19:04] <twnqx> and uau doesn't want to give me his existing patches so i can't wotk on that :( [08:19:51] <siretart> twnqx: I guess he publishes a git repo with the patches, no? [08:19:59] <twnqx> those aren't in a repo yet [08:20:05] <siretart> great :/ [08:20:18] <twnqx> i'll bug him again some time :) [08:20:28] <spaam> dont you like uau sometime? :P [08:20:34] <twnqx> oh, i do [08:20:44] <twnqx> alone for the fact that his mplayer builds against ffmpeg-mt [08:21:24] <twnqx> yet need to figure out why my last build refused to play bluray pcm audio... [08:21:36] <twnqx> i know it did before :P [08:21:42] <hyc> I'm pretty happy that his mplayer builds with librtmp ... [08:25:24] <Tjoppen> if bultje ok's my http patch, would that be something that goes into 0.6? [08:30:01] <kshishkov> wbs: it's what you actually commit that counts [08:30:31] <wbs> kshishkov: true, but most of my commits have actually been new features, that at least I'm interested myself ;P [08:31:56] <kshishkov> the best kind! [08:32:19] * kshishkov hopes he also has made 100 useful commits so far [08:32:51] <wbs> your commits, however many or few they are, are probably way more useful to a much larger audience, than mine. :-) [08:36:46] <peloverde_> most of my 294 commits replace a library that works just fine [08:37:00] <peloverde_> asf->264->mp4 works fine, hmmm [08:38:58] <peloverde_> oh, because it totally blew away my fps [08:59:23] <hyc> wbs: unfortunately my avcodec patch only works for ffplay, not mplayer [08:59:53] <hyc> if mplayer is using libnemesi or liveMedia then the wrong AVCodecContext handles are present [09:07:15] <av500> hyc: I was just asking myself whether a bitstream filter has access to extradata at all? [09:07:32] <av500> (while sitting in a dentists chair - me, not the bitstream filter) [09:08:11] <wbs> av500: the h264 mp4 to annex b bitstream filter sure does something with extradata [09:08:19] <av500> ok [09:08:26] <hyc> av500: you can IRC from a dentist's chair? talk about self control... [09:08:35] <wbs> but I don't know if it actually is allowed to change extradata, or just change packet data as it flows through [09:08:37] <av500> hyc: :) [09:08:39] <kshishkov> av500, are you trying to ask questions in extreme environment? [09:09:18] <av500> i figure dentist to ffmpeg-devel is two of the most extreme environs, no? [09:09:25] <hyc> lol [09:09:40] <hyc> anyway yes, looking at the mp4toannexb code, it can be done [09:09:57] <hyc> but that's parsing the extradata yet another time, and keeping yet another private copy of the result [09:10:52] <av500> (but dentist is luckily over...) [09:11:08] <hyc> and every packet sent thru does an alloc_and_copy. I think it's pretty gross... [09:11:26] <hyc> which I suppose also applies to dentist visits ;) [09:12:06] <av500> can you spell root canal.... [09:12:14] <hyc> auuuuugggghhhh [09:12:19] <hyc> I think it's something like that [09:13:56] <hyc> wbs: heisenbug - by observing it too closely, you sent it back into hiding... [09:14:06] <hyc> (rtp pkt ordering...) [09:14:12] <wbs> yeah, probably [09:14:19] <wbs> or someone from google is reading the mailing list :-) [09:14:28] <hyc> heh [09:47:22] <CIA-7> ffmpeg: mstorsjo * r23181 /trunk/libavformat/rtsp.c: [09:47:22] <CIA-7> ffmpeg: Fix a crash when opening WMS RTSP streams [09:47:22] <CIA-7> ffmpeg: Fixes issue 1948 [09:49:50] <Kovensky> <peloverde_> asf->264->mp4 works fine, hmmm <-- yea, weird, isn't it :) [09:50:07] * Kovensky probably missed something [09:51:14] <wbs> siretart: you probably want to pick 23181 to 0.6, too, since it fixes a crash [09:52:39] <siretart> wbs: excellent. that would have qualified even for a point release :-) [09:53:04] <wbs> :-) [09:53:15] <thresh> moo siretart. any plans on having decent ffmpeg on debian, say, sid? :) [09:53:18] <wbs> it's not relevant for 0.5 though, it's new code we added a few weeks ago [09:53:24] <thresh> decent == supporting h264 in vaapi ;-) [09:53:30] <siretart> thresh: after squeeze release, sure [09:55:21] <siretart> thresh: if you insisted on pushing ffmpeg 0.6 into squeeze, I would have to ask you to verify to not break existing applications in squeeze. fixing mplayer (which is based on the rc3 branch) would be a good start ;-) [09:55:51] <thresh> siretart: naaah, I'd rather had 0.6 packages for experimental ;) [09:56:02] <siretart> thresh: already uploaded [09:56:08] <thresh> oh [09:56:10] <thresh> :-) [09:56:20] <siretart> still not accepted, though [09:56:43] <thresh> so I have to poke someone to upload libva and vdpau-video [09:56:52] <thresh> then, I could use debian [09:57:29] <siretart> are these two already packaged and tested? If they were in the pkg-multimedia team git, I would take a look. [09:58:21] <thresh> siretart: http://bugs.debian.org/569635 IIRC [09:59:11] <siretart> oh right, I knew I had seen it before. ok, the ball is indeed in my camp [09:59:20] <siretart> you'd need both packages? [09:59:22] <thresh> and http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=569641 [09:59:36] <thresh> siretart: yes, the second one is needed to support nvidia cards [09:59:50] <thresh> IIRC there is a support for fglrx as well by means of a separate project [10:00:24] <siretart> thresh: I build them, if you would test them for me, I'd sign and upload them. deal?;-) [10:00:32] <thresh> siretart: sure! [10:00:37] <siretart> i386 or amd64? [10:00:41] <thresh> amd64 [10:01:14] <thresh> ah, here it is, xvba-video: http://www.splitted-desktop.com/~gbeauchesne/xvba-video/ [10:01:31] * Kovensky wonders why is that not merged so far [10:01:34] <Kovensky> that branch is over a year old [10:02:15] * Kovensky pokes __gb__ [10:02:35] <thresh> siretart: we could probably also talk in #d-m@oftc ;-) [10:02:52] <siretart> thresh: sure [10:07:55] <siretart> thresh: http://siretart.tauware.de/~siretart/upload-queue/ - libva is already there, vdpau-video is still building [10:08:19] <siretart> oh, vdpau-video fails to build because of missing libva-dev :/ [10:38:11] <spaam> siretart: are those packages going into some kind of repo? :) [10:39:31] <siretart> spaam: yes. in git repos on git.debian.org, pkg-multimedia namespace [10:40:12] <spaam> siretart: so it will hit unstable in the summer ? :) [10:40:46] <siretart> spaam: depends on a number of factors [10:41:40] <spaam> siretart: like? [10:42:43] <siretart> packages being tested, me finding time to review& upload, ftp-masters to accept, etc. [10:43:17] <spaam> ah ok. :) [10:44:02] <__gb__> hi KotH [10:45:00] <__gb__> humm, no, sorry Kovensky :) [10:46:27] <spaam> siretart: going to test it later when vdpau thing is done :) [10:47:27] <thresh> ;) [10:47:36] <janneg> fuck. the highest german court paved the way for software patents [10:51:56] <siretart> janneg: link? [10:52:06] <janneg> siretart: www.heise.de/newsticker/meldung/Bundesgerichtshof-ebnet-Weg-fuer-Softwarepa… [10:53:03] <janneg> they reversed a decision of the - already lax on software patents - patent office and patent court [10:54:23] <siretart> that's seems indeed very bad news :-( [10:55:32] <av500> dont despair, just add them to the list of people that go 1st against the wall when revolution comes.. [10:56:11] <thresh> ..right after the journalists. [11:00:17] <siretart> thresh: spaam: http://siretart.tauware.de/~siretart/upload-queue/ - now contains upload candidates for libva and vdpau-video. please give me feedback; if they work for you, I'll upload to unstable [11:00:27] <metiu_> hi, I've got ffmpeg streaming on rtp which stops for a while (30s) [11:00:36] <thresh> siretart: \o/ will do. [11:00:43] <metiu_> i strace()d it to a read(/dev/random, 6) [11:00:59] <metiu_> does it need such randomness? [11:01:07] <metiu_> (git HEAD btw) [11:04:11] <spaam> siretart: only i386.. i have amd64 :) [11:07:33] <thresh> yeah, vdpau-video is i386 only there :( [11:10:02] <siretart> d'oh - now pushed. reload [11:10:41] <spaam> nice [11:12:54] <__gb__> thresh, IIRC it works on my amd64 system, what is the problem? [11:13:26] <thresh> __gb__: I was referring to siretart's built packages [11:13:32] <thresh> __gb__: and it also works on amd64 for me ;) [11:14:29] <__gb__> ah ok :) btw, I noticed his packages are quite old (vdpau-video 0.6.3 vs. 0.6.9) [11:15:02] <thresh> yeah, shouldnt be too hard to update though. [11:15:17] <thresh> should libva also be updated? [11:20:33] * KotH pokes __gb__ [11:20:36] <KotH> ;) [11:22:22] <__gb__> thresh, probably, I have not checked what version he used [11:23:03] <thresh> 1.0.1 [11:37:09] <spaam> siretart: works great with latest vlc-git-head and latest ffmpeg. i get around 40% cpu usage drop :) [11:39:11] <CIA-7> ffmpeg: siretart * r23182 /branches/ (0.6/libavcodec/aaccoder.c 0.6): [11:39:12] <CIA-7> ffmpeg: Make the faac inspired quantizer search make sense for a slightly narrower definition of "make sense." [11:39:12] <CIA-7> ffmpeg: backport r23035 by alexc [11:39:12] <CIA-7> ffmpeg: siretart * r23183 /branches/ (0.6 0.6/libavcodec/aacenc.c): [11:39:12] <CIA-7> ffmpeg: Error out when too many bits per frame are requested. [11:39:12] <CIA-7> ffmpeg: backport r23036 by alexc [11:39:49] <CIA-7> ffmpeg: siretart * r23184 /branches/ (0.6/libavcodec/aaccoder.c 0.6): [11:39:49] <CIA-7> ffmpeg: 10l: store the result of clipping added in r23035 [11:39:49] <CIA-7> ffmpeg: backport r23037 by alexc [11:41:22] <siretart> spaam: what did you test exactly? vdpau-video or just libva? [11:44:48] <spaam> siretart: what i did was recompile ffmpeg, vlc . then deactivated "accelerated video output" in perferences in vlc.. open my avril 1080p video.. watched the video and top.. then activete acceleration and did the same thing :) [11:45:36] <CIA-7> ffmpeg: siretart * r23185 /branches/ (0.6/libavformat/asfdec.c 0.6): [11:45:36] <CIA-7> ffmpeg: Favor chunk size over hitting the correct position after reading the chunk size in asf. [11:45:36] <CIA-7> ffmpeg: Fixes issue1923 [11:45:36] <CIA-7> ffmpeg: backport r23040 by michael [11:47:26] <siretart> spaam: using 'my' packages, that is? [11:47:28] <CIA-7> ffmpeg: siretart * r23186 /branches/ (0.6/cmdutils.h 0.6): [11:47:28] <CIA-7> ffmpeg: Document cmdutils.c:print_error(). [11:47:28] <CIA-7> ffmpeg: backport r23051 by stefano [11:47:37] <spaam> siretart: yes :) [11:47:44] <siretart> okay, that works for me :-) [11:48:31] <lu_zero> siretart: I just noticed git notes [11:49:02] <siretart> lu_zero: sorry? [11:49:08] <lu_zero> with that the obnoxious "edit/redact commit messages" requirement is fulfillable =) [11:49:33] <janneg> english report of the german court ruling re sw patents http://fosspatents.blogspot.com/2010/05/german-high-court-declares-all-soft… [11:50:30] * lu_zero was idling reading git release notes [11:52:34] <siretart> spaam: okay, package uploaded [11:52:54] <lu_zero> btw good day ^^ [12:47:31] <hyc> ok, simple fix for ffserver's I/O loop, no more CPU hogging [13:30:26] <CIA-7> ffmpeg: siretart * r23187 /branches/ (0.6 0.6/libavcodec/avcodec.h): [13:30:26] <CIA-7> ffmpeg: Another try for fixing/improving decode_video documentation. [13:30:26] <CIA-7> ffmpeg: backport r23057 by reimar [13:31:20] <CIA-7> ffmpeg: siretart * r23188 /branches/ (0.6 0.6/configure): [13:31:20] <CIA-7> ffmpeg: Remove hardcoded-tables hack for IA-64: with latest binutils that now actually [13:31:20] <CIA-7> ffmpeg: causes linking errors instead of avoiding them. [13:31:20] <CIA-7> ffmpeg: backport r23058 by reimar [13:44:25] <CIA-7> ffmpeg: siretart * r23189 /branches/ (0.6 0.6/cmdutils.c): [13:44:25] <CIA-7> ffmpeg: Fix build with swscale disabled [13:44:25] <CIA-7> ffmpeg: backport r23062 by mru [13:50:49] <siretart> hm. since when does 'make test' *require* libswscale? [13:50:57] <mru> since a long, long time [13:51:36] <siretart> k [13:52:14] <mru> the "ffmpeg" executable requires it [13:52:31] <mru> you can disable it if you only need e.g. lavc [13:52:45] <CIA-7> ffmpeg: siretart * r23190 /branches/ (0.6/tools/qt-faststart.c 0.6): [13:52:45] <CIA-7> ffmpeg: qt-faststart: Avoid leaking memory if encountering a file with double ftyp atoms [13:52:45] <CIA-7> ffmpeg: backport r23065 by mstorsjo [14:02:43] <av500> ha, finally: http://cdrecord.berlios.de/private/R-3.0.html [14:03:15] <kshishkov> and close in time to new IJG version [14:04:02] <twnqx> :X i failed to write a dvdiso to a bd-rw recently [14:04:52] <mru> I've had my fun with schilling [14:07:20] <mru> I'm a bit disappointed the ijg guy doesn't read my blog... [14:08:41] <KotH> av500: omg... the intro contains more buzzwords than our sales uses in any offer he writes [14:11:26] <kshishkov> KotH: time to fire your sales rep? [14:11:43] <mru> KotH: shame you missed that epic flamewar at linuxtag a few years ago [14:12:24] <KotH> kshishkov: nah.. he's cool [14:12:31] <KotH> kshishkov: killed 3 people with his bare hands [14:12:33] <Compn> mru : are you going to put some news entry up on ffmpeg.org about coming to see you guys at linuxtag? [14:12:49] <KotH> mru: i'm quite sure i'll miss something again this year :) [14:13:58] <mru> Compn: I guess I should [14:15:20] <siretart> mru: the flamewar went on at the last two cebit exhibitions [14:15:25] <av500> mru: can you re-enact it? [14:15:40] <mru> av500: I could try if I find him again [14:15:46] <mru> he's easily baited [14:16:12] <mru> siretart: schilling trolls cebit too? [14:17:15] <siretart> mru: so I was told. with legal tricks, threats and everything. [14:19:13] <mru> my "discussion" with him was mostly about why IDE drives shouldn't be addressed with scsi triplets, why using buffer-underrun recovery is better than burning a coaster, and why Linux can't be expected to retain old bugs for the sake of one application relying on them [14:20:17] <twnqx> but ide drives are just scsi drives to the kernel... these days [14:20:22] <twnqx> he was just ahead of his time! [14:20:32] <mru> yes, but they don't have bus/target/lun addresses [14:20:48] <mru> they have /dev/sdX names [14:20:57] <twnqx> ah, that's what you're refering to [14:20:58] <twnqx> right [14:21:12] <twnqx> though you can i think use bus/target/lun [14:23:43] <av500> mru: but where do the luns end up in /dev/sdX [14:24:31] <mru> av500: different X [14:24:55] <twnqx> hm [14:24:59] <mru> of course most devices have only one lun [14:25:04] <twnqx> wasn't the case for the only device i ever had with luns :X [14:25:19] * av500 once had 18 luns to manage [14:25:25] <twnqx> ... 18? [14:25:47] <mru> I've never seen a CD drive with more than one [14:25:54] <twnqx> i... did [14:25:59] <twnqx> it was a scsi cd changer, though [14:26:05] <av500> 3x teac CD-C68E ... http://www.dansdata.com/changer.htm [14:26:05] <mru> explains it [14:26:09] <av500> and it was IDE [14:28:25] <thresh> siretart: being a noob in debian, is there a way to use your http://.../upload-queue as a source dir for apt? [14:29:26] <twnqx> wow, BD-Rs dropped to 1.80â¬ [14:35:44] <mru> 25G? [14:36:15] <twnqx> yeah [14:36:56] <twnqx> and that's verbatim, not noname [14:37:14] <mru> cheaper than flash at least [14:37:53] <twnqx> yeah [14:38:08] <twnqx> i wonder if they'll reach parity with HDDs [14:38:41] <mru> optical discs have one distinct advantage over HDDs [14:38:45] <mru> you can mail them easily [14:39:01] <mru> or store them in dense stacks [14:39:21] <mru> although not more dense than hdd [14:39:54] <twnqx> i wonder if they have longer shelf life than hdds [14:40:39] <mru> before or after burning? [14:41:39] <kshishkov> well, one of the cheapest brands here meant "a hope" when translated [14:41:52] <twnqx> after, and hdds filled :P [14:43:33] <mru> kshishkov: in the same spirit as naming a famous soviet newspaper "truth"? [14:44:51] <kshishkov> mru: no, original name was "Esperanza" and most people didn't get it here [14:45:59] <KotH> well..not everyone is as lingofil as ffmpeg developers [14:46:15] <siretart> thresh: no, but I'd suggest you issue a 'dget http://.../$package.changes', which downloads all files referenced from that changes file [14:52:52] <KotH> kshishkov: apropos weird names [14:53:12] <KotH> kshishkov: there is a japanese restaurant here, that calls itself "sukebe" [14:53:59] <KotH> kshishkov: the owner has been asked in an interview once, what the name means, his answer was literaly "don't know, something asian... but it sounds cool" [14:54:18] <mru> does it mean anything? [14:54:51] <KotH> perverted old man [14:54:57] <mru> lol [14:55:03] <mru> is the place any good? [14:55:12] <KotH> dont know [14:55:24] <KotH> i refuse to enter an japanese restaurant where the owner isnt japanese [14:55:31] <mru> good policy [14:55:34] <KotH> or at least the staff [14:55:37] <kshishkov> KotH: well, and the famous Chinese Restaurant called "Translation server error" [14:55:47] <av500> KotH: or at least the food? [14:55:58] <kshishkov> also good policy is to avoid restaurants with menus translated into Russian [14:56:07] <mru> the nationality of the owner doesn't really matter as long as the chefs are genuine [14:56:09] <KotH> av500: doesnt matter whether the food is japanese or not, if the staff isnt japanese it wont taste good [14:56:50] <kshishkov> av500: it's like audiophile thing - it won't sound good on speakers from wrong company [14:57:00] <KotH> lol [14:57:21] <KotH> kshishkov: if you make it to zh once, i'll shwo you around some japanese restaurants [14:57:25] <mru> last time I was at one of the better indian restaurants here the waitress was romanian [14:57:27] <av500> kshishkov: I think mru even insists of a specific md5sum implementation to "listen" to audio [14:57:27] <hyc> hey, don't make me pull out my spectrographic analysis of taste bud excitation [14:58:01] <kshishkov> sounds _very_ related to speech codecs :P [14:58:15] <KotH> kshishkov: or ask ivan to get you good and bad japanese food [14:58:55] <mru> KotH: you know ivan? [14:59:11] <KotH> mru: depends on which ivan you mean [14:59:37] <av500> aacivan? [15:01:05] <mru> I know of only one ivan easily associated with kshishkov and japanese [15:01:29] <KotH> and which one would that be? [15:01:35] <kshishkov> mru: there are two Ivans here, one is AAC creator indeed [15:01:47] <kshishkov> *AAC encoder [15:02:07] <mru> kshishkov: yes, but only one of them has a japanese wife afaik [15:02:57] <kshishkov> that's another Ivan then, the one you've spoken to [15:03:07] <mru> I've spoken to both [15:03:15] <KotH> mru: then it's the right ivan :) [15:03:17] <kshishkov> KotH also should know him [15:03:22] <KotH> "know" [15:03:43] <KotH> all i know about him is that he has a japanese wife, his bank account number and that he got me a dvd box [15:03:52] <KotH> oh.. and the company he works for [15:04:28] <av500> I hope it was not home videos... [15:05:10] <KotH> nope [15:05:53] <KotH> it was a tv series, nearly as old as i am [15:06:15] <kshishkov> 50% chance it to be "Hyper Police" [15:06:35] <KotH> lol [15:06:47] <KotH> i'm older than Dark_Shikari :-) [15:07:02] <thresh> not a valid point, almost everyone are :P [15:07:10] <KotH> hehe [15:07:19] <KotH> kshishkov: but how come you think it's hp? [15:07:21] <spaam> how old are Dark_Shikari ? :) 22? :) [15:07:36] <KotH> are? [15:07:41] <kshishkov> KotH: that's your favourite anime [15:07:41] <KotH> are they multiple entities? [15:07:46] <KotH> kshishkov: rotfl... [15:07:51] <spaam> KotH: .. is :P [15:08:01] <KotH> kshishkov: it's one of the funny ones.. and a good namespace :) [15:08:16] <KotH> kshishkov: but HP is an end 90s anime [15:08:44] <av500> KotH: i have the dvd box of this: http://en.wikipedia.org/wiki/Ulysses_31 might match your age better [15:09:08] <kshishkov> av500: go to #mplayerdev [15:09:27] <av500> but its french, not japanese :) [15:09:31] <KotH> av500: oh... [15:09:36] <KotH> av500: damn! [15:09:41] <KotH> av500: i'm looking for that one [15:09:56] <kshishkov> anyway, continue without me [15:10:06] <av500> how can we? [15:10:18] <twnqx> hyper police... [15:10:38] <av500> well, its french-japanese, but the DVDs I have are only french iirc [15:12:00] <KotH> pah! [15:12:07] * KotH throws a zagor hammer at av500 [15:12:17] <av500> ah, now we are talking [15:12:30] <av500> alan ford anybody? [15:17:28] <KotH> nope [15:17:40] <KotH> too old and not enough japanese for my taste [15:17:56] * av500 is old [15:18:06] * av500 not enough japanese [15:18:10] * KotH knows [15:18:22] <KotH> you arent exactly my taste either [15:18:38] <mru> you tasted? [15:18:54] <av500> I deny everything [15:19:15] <KotH> mru: dont ask inapropriate questions [15:20:42] <thresh> mru: I see a check_ldflags for -Wl,-Bsymbolic. In which case it actually goes in a link line? [15:21:20] <mru> if the linker accepts the flag, it gets used [15:23:29] <thresh> thx, weird [15:26:51] <mru> what's weird? [15:29:36] <thresh> nevermind, me stupid again [15:41:33] <peloverde_> first googleIO keynote in 20 minutes [15:42:03] <mru> wake me when it's over [15:42:36] <mru> keynote = pretentious prick telling everybody how great he is [15:49:35] <JEEBsv> Pretty much [16:02:34] <janneg> http://code.google.com/p/webm/downloads/detail?name=mplayer-vp8-encdec-supp… [16:03:17] <peloverde_> Anybody want to start reviewing the patches? ;) [16:04:39] <av500> so, it will be MKV [16:07:29] <janneg> just patches to add libvpx support [16:07:41] <av500> grah [16:08:19] <av500> but kudos for not using pkgconfig! [16:08:36] <Dark_Shikari> so guys, in one hour I'm going to need to borrow you all for a bit [16:08:45] <av500> :) [16:08:47] <Dark_Shikari> I have my in-depth vp8 analysis ready [16:08:52] <Dark_Shikari> I will need /., reddit, etc, etc submissions [16:08:55] <av500> lol. I was download #6 on that website [16:09:00] <Dark_Shikari> I am free to release it in exactly one hour [16:09:12] <av500> Dark_Shikari: I dont care about reddit, when will there be native ffmpeg support? [16:09:18] <twnqx> lol [16:09:24] <Dark_Shikari> av500: hopefully never, it's not very good [16:09:42] <janneg> and bloating avcodeccontext with >10 parameter [16:10:04] <av500> ->number_of_golden_frames_per_foo_bar? [16:10:06] <peloverde_> It's got to be better than VP3 [16:10:16] <Dark_Shikari> ok, so yes, it's better than vp3 [16:10:24] <av500> its +5 better [16:10:25] <Dark_Shikari> Really though it's not that different from vp6 [16:10:29] <janneg> av500: I was downloader nr 5 [16:10:30] <peloverde_> we have a vp3 decoder [16:10:31] <Dark_Shikari> it's vp6, with more sections of the h264 spec copy-pasted [16:10:36] <Dark_Shikari> LARGE sections [16:10:37] <KotH> Dark_Shikari: huh? [16:10:39] <KotH> that bad? [16:10:47] <Dark_Shikari> They copied h264 intra prediction verbatim [16:10:51] <peloverde_> that will be fun for the mpeg-la [16:10:53] <Dark_Shikari> "oh and it's totally patent free" [16:10:58] <Dark_Shikari> they copied h264 intra pred [16:11:10] <Dark_Shikari> the h264 hierarchical tranform (16 4x4 dct + 4x4 hadamard) [16:11:20] <Dark_Shikari> now they did make minor changes, but imo nothing enough to avoid patents [16:11:30] <Dark_Shikari> they copied both i16x16, i4x4, _and_ chroma intra pred [16:12:08] <KotH> wow.. the freetards will like to hear that [16:12:14] <Dark_Shikari> the arithmetic coder looks almost exactly like cabac without a transition or range_lps_ table, but that's probably enough of a difference. [16:12:26] <Dark_Shikari> they still forgot to have delta quant. [16:13:53] <av500> webm, wtf? [16:14:02] <av500> + if (str == NULL || (strcmp (str, "matroska") && strcmp (str, "webm")) || version > 2) [16:14:17] <Dark_Shikari> Yes, they're trying to fragment web multimedia even more [16:14:24] <av500> \o/ [16:14:30] <janneg> av500: www.webmproject.org/ [16:14:33] <mru> av500: rebranding aka poor man's nih [16:15:20] <av500> janneg: wtf, the blog is pwd protecrted? [16:15:34] <Yuvi> ugh, they're copying the whole brand RIFF something else and call it new? [16:16:07] <mru> Yuvi: it's innovation, 21st-century-style [16:17:06] <janneg> av500: maybe not yet officially open [16:17:14] <thresh> so .webm is some sort of a container? [16:17:17] <av500> Dark_Shikari: the license grant you rights for all "google" patents [16:17:20] <KotH> who's behind webm? [16:17:23] <av500> thresh: it is mkv [16:17:26] <mru> KotH: google [16:17:28] <thresh> lol [16:17:38] <spaam> why do they have html code in libavcodec/libvpxenc.c file? ;S [16:17:44] <KotH> rotfl.. i expected better from them [16:17:49] <av500> thresh: hence the above + line from mplayer mkv demuxer [16:18:10] <Dark_Shikari> av500: I know [16:18:37] <av500> "WebM and the codecs it supports (VP8 video and Vorbis audio) require no royalty payments of any kind..." [16:18:38] <peloverde_> somebody needs to teach them about ordered patches [16:18:39] <thresh> av500: niiiice. [16:18:59] <av500> then they link to the license that mentions gg patents only, nice trickery [16:19:46] <Yuvi> they really don't like #including headers that include code disabled by configure [16:20:19] <mru> I'm assuming the patches are total rubbish and won't bother looking [16:20:41] <j-b> ramiro: ping [16:21:06] <j-b> thresh: patches against vlc are soon to be commited [16:21:25] <janneg> webm announcement no live in the keynote [16:21:29] <janneg> +w [16:22:03] <av500> err, is the libvpx in the code drop? [16:22:16] * mru closes ears [16:22:20] <janneg> git://review.webmproject.org/g/libvpx.git [16:22:23] <Yuvi> "best in class codec for realtime streaming" heh [16:22:29] <thresh> j-b: vlc + vp8? niice. [16:22:37] <mru> yes, best in the class defined as exactly this [16:22:40] <av500> wemb = vp8 + vorbis [16:22:53] <j-b> thresh: why do you think vlc 1.1 was delayed... [16:23:02] <av500> j-b: and the actual lib? [16:23:07] <j-b> av500: it is a mess [16:23:14] <j-b> av500: impossible to crosscompile [16:23:19] <av500> of course it is a mess, but where is it? [16:23:33] <j-b> patches against ffmpeg are a bit weird [16:23:34] <janneg> av500: git pull git://review.webmproject.org/g/libvpx.git [16:23:48] <av500> gee, that is what just finished :) [16:24:03] <thresh> j-b: because you are lazy [16:24:06] <thresh> :) [16:24:13] <j-b> thresh: not news :) [16:24:23] <janneg> av500: or not "fatal: The remote end hung up unexpectedly" [16:24:30] <av500> janneg: right [16:25:01] <j-b> http://code.google.com/p/webm/downloads/list [16:25:35] <spaam> new rev on the patches ;D [16:25:45] <spaam> 13min ago [16:25:46] <janneg> code.google.com/p/webm/downloads/detail?name=libvpx-0.9.0.tar.bz2&can=2&q= [16:25:50] <thresh> they probably listen to us here :o [16:26:06] <peloverde_> they updated the mplayer tarball chrome://downloads/home/alex/Downloads/mplayer-vp8-encdec-support-r2.tar.bz2 [16:26:16] <j-b> I am just not sure about the "Copyright (c) 2010, Google, Inc. All right reserved" [16:26:52] <Yuvi> max_cluster_size = 500*1024*1024; <- that seems kinda excessive [16:27:21] <j-b> and the following license... but well [16:29:00] <spaam> in r2 they have presets support ;D [16:29:08] <spaam> ffmpeg-only/ffpresets-libvpx.diff [16:31:43] <Dark_Shikari> http://news.ycombinator.com/item?id=1361442 upvote me [16:31:59] <av500> done [16:32:09] <peloverde_> sorry I don't participate in social news for the stupid [16:32:17] <ramiro> j-b: ping [16:32:19] <ramiro> oops, pong [16:32:49] <av500> just on #beagle: [18:30] <killring> anyone know if/how well the bb can hardware assist vp8 decode? [16:33:14] <j-b> ramiro: if you had just the time to see how this libvpx can be Xcompiled, that would be cool [16:33:16] <Yuvi> kinda wish they didn't do cvs style one file patches, there's a reason noone it anymore... [16:33:43] <peloverde_> at least ordered patches would be a huge win [16:34:22] <peloverde_> thanks were just given to theora, ick [16:35:16] <av500> Dark_Shikari: .webm as well? [16:35:37] <av500> whats the mime type? [16:35:45] <ramiro> what is libvpx? [16:36:12] <av500> the vp8 coded [16:36:36] <ramiro> so google has open sourced it? [16:36:55] <ramiro> and the solution to all earthly problems has finally arrived? [16:36:57] <av500> they says so [16:37:10] <av500> yes, your bus will be less crowded tomorrow [16:37:40] <av500> lol, the ffmpeg WEBM_DEMUXER does not support "V_QUICKTIME" [16:37:42] <ramiro> where's the fsf letter taking full credit for this? [16:38:04] <mru> and the xiph one doing same [16:38:10] <peloverde_> Google pretty much just gave all the credit to xiph ?! [16:38:15] <av500> and al gore? [16:38:35] <mru> peloverde_: WTF? [16:38:40] <Yuvi> http://pastie.org/967897 <- should I just push this? [16:38:49] <peloverde_> they called the theora developers visionaries [16:38:58] <Yuvi> the rest needs a bit of work [16:39:05] <av500> Yuvi: I am just pushing that for my player :) [16:39:20] <peloverde_> and before mentioning that reference hardware is in the work they thanked vorbis/theora and only vorbis/theora [16:39:26] <j-b> ramiro: :) [16:39:34] <j-b> ramiro: but their configure is a mess [16:39:53] <av500> j-b: its a decoder, what kind of fancy configure will it need? [16:40:13] <j-b> av500: I don't know, the possiblity to CrossCompile? [16:40:23] <j-b> to win32 and win64, I mean [16:40:25] <Yuvi> add_cflags -DHAVE_STDINT_H [16:41:03] <mru> peloverde_: visionaries like this one? http://www.apenotmonkey.com/2010/05/10/god-within/ [16:42:30] <mru> Yuvi: I wouldn't bother crediting google with that [16:42:33] <BBB> spyfeng: hi :) [16:42:55] <mru> Yuvi: certainly not as they give credit to xiph [16:43:31] <BBB> oh cool, google posted vp8? [16:43:35] <BBB> do we decode it? :) [16:43:54] <spaam> Dark_Shikari: you like to use that SVT file to compare thing ;) [16:44:54] <av500> mru: TI vp8 announce in 30min from here: http://e2e.ti.com/blogs_/b/mobile_momentum/default.aspx [16:45:25] * mru refuses to look [16:45:37] <j-b> you are a geek, you cannot resists [16:45:39] <j-b> -s [16:45:54] <peloverde_> It's just irritating how on webmproject.org it's ffmpeg all over the place, but in their keynote they can't shut up about how great xiph is without a single ffmpeg mention [16:46:42] <av500> j-b: I will just copy it here line by line :) [16:47:08] <av500> peloverde_: so xiph wrote vp8 by taking vp3 and adding h264, right? [16:47:31] <j-b> peloverde_: PR vs real world [16:49:50] <Yuvi> mru: eh, don't feel like changing it [16:50:07] <Dark_Shikari> av500: vp6 [16:50:35] <j-b> aren't they a bit optimist about the patents? [16:50:56] <Dark_Shikari> ridiculously so [16:51:05] <CIA-7> ffmpeg: conrad * r23191 /trunk/libavcodec/avcodec.h: [16:51:05] <CIA-7> ffmpeg: Add VP8 CODEC_ID [16:51:05] <CIA-7> ffmpeg: Patch by Google [16:51:05] <CIA-7> ffmpeg: conrad * r23192 /trunk/libavformat/matroska.c: [16:51:05] <CIA-7> ffmpeg: matroska: Add V_VP8 [16:51:05] <CIA-7> ffmpeg: Patch by Google [16:51:06] <CIA-7> ffmpeg: conrad * r23193 /trunk/libavformat/riff.c: [16:51:06] <CIA-7> ffmpeg: Add VP80 fourcc [16:51:07] <CIA-7> ffmpeg: Patch by Google [16:54:04] <av500> so, everybody agrees that the new web is all about glossy magazines? [16:54:21] <av500> aapl thinks so, gg does too... /sigh [16:54:39] <mru> is the clusterfuck over yet? [16:54:51] <peloverde_> I think they are done with codec stuff [16:55:15] <janneg> no, sports illustrated talking now [16:55:30] <av500> swimsuit issue? [16:55:43] <av500> it wont be on the ipad, so goog has the edge :) [16:55:50] <peloverde_> does SI cover starcraft yet? [16:55:50] * janneg is not listening [16:55:51] <mru> sports illustrated is obviously a euphemism for playboy [16:56:26] <av500> janneg: but why did they get william shatner to present it? [16:56:35] <av500> or who is that old guy? [16:56:57] <peloverde_> blol at lebron [16:57:07] <peloverde_> the man can't deliver under pressure [16:58:12] <janneg> av500: not watching either [17:00:34] <av500> + // Start a new cluster when we get a key frame [17:01:12] <Yuvi> not strictly required but probably a good idea, esp for streaming [17:02:01] <Yuvi> I guess the audio packet delay stuff is related to that, but I think strict interleaving is better [17:04:28] <ramiro> j-b: I'll try later today [17:05:41] <j-b> ramiro: \o/ [17:07:21] <ramiro> I have a report to turn in in a couple of hours and I haven't started. we've had 1 month to do it... [17:07:33] <ramiro> procrasti-fucking-nation... [17:07:56] <av500> just get it from wikipedia [17:08:37] * mru used to quite enjoy catching students cheating [17:12:07] <peloverde_> I think it's time to close this keynote, get some caffeine, and get back to dealing with this asf+h.264 mess [17:13:14] <ramiro> av500: nah, I don't cheat... I frequently fail exams though, but I don't cheat. [17:14:28] <av500> ramiro: I did not expect it being on wikipedia, what is it about? [17:17:03] <Tjoppen> interesting analysis of VP8 [17:18:11] <ramiro> av500: lab report about (probably badly translated) regulation and yield of an autotransformer [17:18:28] <ramiro> the worst part is that I seem to have misplaced the data we collected [17:18:51] <ramiro> and we had to turn in a copy of the data so the teacher could make sure we didn't make up numbers. [17:18:58] <ramiro> now he has a copy and I don't =) [17:22:59] <KotH> ramiro: [FAIL] ? :) [17:24:07] <ramiro> KotH: =D [17:24:20] <av500> ok, my player plays .webm files [17:26:31] <Dashiva> That was quick [17:26:40] <av500> well, it falls back to audio only :) [17:26:48] <hyc> cheater [17:26:57] <mru> av500: my demux? [17:27:13] <av500> mru: I thought you did not want to hear about it? :) [17:28:11] <av500> mru: http://mru.pastebin.com/iqsK7TcP [17:31:09] <mru> thanks, but I doubt I'll be needing it anytime soon [17:32:15] <av500> hmm, libvpx has arm/neon support [17:32:27] <j-b> av500: my vlc does the same :) [17:32:32] <mru> av500: yes, I know [17:32:43] <mru> not very well-written though [17:32:56] <mru> but not totally atrocious either [17:33:05] <av500> mru: I assumed that since you are still in old europe :) [17:33:16] <av500> and not in the new world [17:33:33] <mru> what has that got to do with anything? [17:42:05] <Compn> One of the most unexpected supporters is Adobe, whose CTO Kebin Lynch said that his company is really excited about the new codec. Adobe will use VP8 for Flash and, Lynch said that it will help to dristribute VP8 to a billion people within a year. [17:42:07] <Compn> oh [17:42:16] <Compn> so its collusion to destroy h264's hold on the market [17:42:17] <Compn> i see [17:44:15] <Compn> or to force h264 to make web video free, either way [17:46:18] <Yuvi> ugh, the libvpx configure script hard-codes OS X versions [17:46:18] <Yuvi> and [17:46:25] <Yuvi> doesn't recognize 10.6 [17:46:27] <j-b> :) [17:46:35] <mchinen> anyone want to explain to me what keyframe flags (for AVIndexEntry) mean for audio? [17:46:48] <j-b> 18:39 < j-b> ramiro: but their configure is a mess [17:47:02] <mchinen> as in AVINDEX_KEYFRAME [17:47:21] <mchinen> *i mean for audio files like mp3 [17:47:34] <Yuvi> or is it that *and* I have to tell it that I'm on OS X [17:47:52] <av500> mchinen: they are all keyframes? [17:48:31] <mchinen> av500: okay, that's what I was hoping, thx [17:53:47] <Yuvi> 'make install' only results in configure rerunning wtf [17:54:17] <av500> hmm, I just compiled it for armv7/neon, wasnt that hard... [17:54:30] <Yuvi> did you install it too? [17:54:41] <Yuvi> cause it compiles with an explicit --target [17:54:41] <CIA-7> libswscale: lorenm * r31180 /trunk/libswscale/x86/yuv2rgb_template2.c: [17:54:41] <CIA-7> libswscale: 40% faster yuv420 to rgb24 mmx. [17:54:41] <CIA-7> libswscale: It is now faster than the old gpl version on conroe. [17:54:41] <CIA-7> libswscale: lorenm * r31181 /trunk/libswscale/x86/ (yuv2rgb_mmx.c yuv2rgb_template2.c): [17:54:41] <CIA-7> libswscale: 13% faster yuv420 to rgb15 mmx. [17:54:41] <CIA-7> libswscale: It is now faster than the old gpl version on conroe. [17:54:43] <av500> I have no code yet that would use it [17:54:44] <Yuvi> just doesn't install for me [17:54:54] <av500> define "install" [17:55:04] <Yuvi> move stuff to /usr/local/lib and include [17:55:17] <av500> ah, that is custom here anyway [17:55:33] <av500> I could add it to buildroot I guess... [18:02:34] <peloverde_> Where does the extradata get built when playing raw h264? i've looked in both the demuxer and the parser [18:03:01] <Yuvi> does it? I thought that was only done by the muxer [18:03:33] <peloverde_> ffplay and ffprobe both report extradata being present (but is_avc being false) [18:03:49] <peloverde_> the muxer expects some sort of extradata presence [18:04:44] <peloverde_> http://git.ffmpeg.org/?p=ffmpeg;a=blob;f=libavformat/movenc.c;h=440c98ad26b… [18:06:07] <Yuvi> guess, so, dunno then [18:10:37] <peloverde_> I guess it's printf time! [18:13:27] * Yuvi gives up and installs it manually [18:22:19] <ramiro> oh, alex is back... [18:23:10] <peloverde_> for anyone who his the logs on google, it comes from avf/utils.c through the parser [18:27:57] <spaam> peloverde_: printf debugging? D; [18:30:42] <ramiro> the greatest form of debugging [18:31:15] <peloverde_> ramiro, for a moment I wondered where I had gone, then I checked my e-mail :) [18:33:38] <j-b> Where is Diego when I need license reviewing? :D ^^ [18:37:58] <drv> the webm site has some horrible fixed-width layout that doesn't fit in my browser... [18:38:16] <drv> seems like a web site about web standards would know how to build a decent web site [18:41:25] <j-b> drv: it is ridiculously broken on resizing with small screens [18:41:32] <BBB> maybe alex works for google now :-p [18:48:47] <mru> http://zencoder.com/encoder-blog/2010/05/19/vp8-webm-and-html5-video/ [18:48:53] <mru> any idea who wrote that? [18:57:04] <peloverde_> does it make sense for h264_split() to return zero when the whole packet is sps/pps? [18:58:30] <hyc> so is it a stupid question to ask about vp8 in an FLV container? [18:58:45] <Dark_Shikari> lol [18:59:09] * janneg is still wondering what an open source codec is? libavcodec/* doesn't seem to qualify [18:59:24] <kierank> hyc: vp8 over rtmp ;) [18:59:32] <hyc> ;) [18:59:48] <hyc> well come on, vp6 and all its earlier relatives are there ;) [18:59:53] <kierank> also do you plan to reverse engineer that flash p2p thing? [19:00:07] <hyc> the rtmfp stuff? I hadn't planned to, no [19:00:31] <kierank> there's no good reason to do so; just adobe trolling [19:00:35] <hyc> it would probably be too nauseating [19:01:58] <hyc> I can only stomach working with so much crappy design in one lifetime... [19:03:12] <peloverde_> at least wikistupedia will be happy they can finally do vorbis in flash... [19:03:51] <kierank> anything is better than that java player [19:16:47] <bcoudurier> hi guys [19:17:50] <astrange> should've woken up earlier, i missed the excitement [19:19:14] <Dark_Shikari> I've had >10k hits in 2.5 hours [19:20:20] <elenril> \o/ [19:20:28] <elenril> let the drama begin [19:22:21] <janneg> av500: blog is now public [19:24:11] <astrange> did it come with a vp7 decoder? [19:25:02] <Yuvi> no, but apparently there are enough references that it'll probably be about as easy to RE from vp8 as vp5 was from vp6 [19:35:14] <BBB> maybe someone could ask google nicely [19:35:19] <BBB> we now have someone posting patches [19:36:04] <kierank> sshhh BBB, vp7 is their secret codec [19:36:46] <BBB> hm? [19:36:48] <mru> the code has comment blocks with /* vp7 version */ etc [19:37:14] <BBB> that's useful [19:37:22] <BBB> maybe we should try it with vp7 input [19:37:26] <mru> probably doesn't cover all the differences [19:37:34] <BBB> although admittedly our vc1 decoder crashed when feeding it wvp2 input [19:50:13] <astrange> Yuvi: shouldn't adding CODEC_ID_VP8 be a minor version increase [19:52:28] <bcoudurier> yup [20:13:48] <Yuvi> oops, fixed [20:14:46] <CIA-7> ffmpeg: conrad * r23194 /trunk/libavcodec/avcodec.h: Bump minor version for CODEC_ID_VP8 [20:19:33] <CIA-7> ffmpeg: alexc * r23195 /trunk/libavcodec/aac.c: Make aac_decode_frame() consume zero padding at the end of a packet. [20:19:34] <CIA-7> ffmpeg: alexc * r23196 /trunk/libavcodec/ (allcodecs.c Makefile chomp_bsf.c): Add a chomp BSF to consume zero padding at the end of a packet. [20:20:14] <BBB> if xiph is so into this "webm" thing, then how come it doesn't use ogg? [20:20:56] <iive> they are not. [20:21:42] <ohsix> BBB: that sort of thing doesn't seem like it would actually be some sort of contention [20:21:47] <iive> but this vp8 codec needs developers and people who would improve it, and x264 devs are not going to jump on the task. So google needs to "pay" xiph for their services. [20:22:15] <BBB> right, but wouldn't xiph people scream out loud that ogg is better than matroska? [20:22:29] <iive> i mean, to encourage them, give them some PR boost and stuff like that. [20:22:39] <ohsix> why would they? [20:23:01] <ohsix> seems you might be projecting a little with all the anti- that goes around ;] [20:23:13] <iive> well, it is not. And they know it. And google knows it. But sometimes you just need somebody to tell that the king is naked. [20:23:21] <BBB> ohsix: just an innocent bystander [20:23:34] <BBB> ohsix: anyway, vp8 could be cool, let's see if it makes the one-year hallmark [20:24:21] <iive> and the webm could be used in both directions. google could extend that format without asking the original mkv developers, while also not shaming xiph PR. [20:24:39] <ohsix> some things just have merit and they don't always need some rabid character at the wheel, just a rational one [20:24:40] <BBB> I guess [20:24:58] <BBB> yuvi: you have a final patch for matroskadec yet? ;) [20:25:05] <bcoudurier> Yuvi, I sent the ogg muxer patch [20:25:06] <BBB> I might look into the actual decoder lib and see how complex it is [20:25:14] <bcoudurier> could you please have a quick look ? that would be great [20:25:33] <iive> BBB: i guess you've read DS blog? [20:25:59] <_av500_> i guess xiph is secretly happy that somebody else took the drop ogg decision... [20:26:15] <_av500_> now they can go mkv and say it was gg that did it... [20:26:25] <ohsix> you could just ask him instead of speculating [20:26:46] <_av500_> btw, is theora offially dead as of today? [20:27:23] <iive> _av500_: more likely there will be theora2 and it would take some years. [20:28:03] <_av500_> based on vp8? [20:28:08] <bcoudurier> I don't like MKV :( [20:28:14] <iive> of course. [20:28:17] <janneg> don't think so, vp8 has first to prove not to be patent encumbered [20:28:20] <Dark_Shikari> but but its not mkv [20:28:21] <Dark_Shikari> it's webm [20:28:26] <Dark_Shikari> webm webm webm webm webm! [20:28:29] <bcoudurier> how do they pack audio ? [20:28:32] <iive> web mkv [20:28:35] <_av500_> tight [20:28:36] <bcoudurier> same cluster crap ? [20:29:00] <j-b> what is the use of bumping LIBAVCODEC_VERSION_MINOR but not resetting MICRO? [20:29:01] <bcoudurier> btw Yuvi what timebase does the lavf muxer use ? [20:29:01] * mru decides to troll nvidia with vp8 [20:29:05] <Dark_Shikari> mru: oh god [20:29:14] <bcoudurier> j-b that's a mistake [20:29:21] <bcoudurier> it happens frequently :> [20:29:24] <mru> I've been trolling the tegra forums for a while [20:29:27] <mru> no reaction [20:29:28] <j-b> bcoudurier: it is your fault then :D [20:29:33] <j-b> bcoudurier: bjr, d'ailleurs [20:30:11] <_av500_> mru: [20:30:14] <_av500_> #tegra? [20:30:24] <mru> that exists? [20:30:34] <_av500_> dunno, im asking you? [20:30:40] <janneg> no [20:30:45] <mru> doesn't seem so [20:30:50] <mru> I meant the web thing [20:30:55] <janneg> neither does #tegra2 [20:30:55] <_av500_> or the web forums? [20:31:52] <BBB> iive: ds? schleef? [20:31:56] <BBB> iive: does he have a blog? [20:32:00] <_av500_> yes [20:32:38] <_av500_> he had that half optimized theora for c64x iirc [20:32:39] <iive> BBB: ds= Dark_Shikari [20:32:46] <BBB> oh, yeah I read that [20:33:09] <janneg> mru: maybe they want to add vp8 only to their graphic chips [20:33:57] <_av500_> mru: they can do vp8 easily on the arm....err wait, no neon :) [20:34:11] <mru> yes, that's the troll [20:34:45] <BBB> is anyone looking at that codec lib already? [20:34:53] <_av500_> i looked a bit [20:35:00] <_av500_> it compiled [20:35:47] <janneg> their git repo is still not cloneable [20:35:55] <BBB> christ that code is a mess [20:36:05] <BBB> millions of header files already [20:36:07] <_av500_> janneg: worked for me [20:36:08] <BBB> who would do that :( [20:36:16] <mru> idiots would [20:36:19] <mru> idiots abound [20:36:36] <_av500_> janneg: i compile the git stuff [20:36:41] <_av500_> +d [20:36:41] <janneg> _av500_: git://review.webmproject.org/libvpx.git ? [20:36:43] <BBB> but I'm not an idiot, I think [20:36:45] <BBB> maybe I am [20:36:52] <BBB> everyone else is crazy except me, I'm an airplane [20:36:53] <mru> BBB: no, not you [20:36:57] <_av500_> janneg: dunno, was at work [20:37:12] <_av500_> but sounds like the one [20:37:53] <_av500_> janneg: works here too [20:38:01] <mru> I don't think anyone from nvidia follows those forums [20:38:13] <ohsix> forums are for parking people [20:38:15] <mru> they didn't even reply when I suggested using omap4 instead [20:38:32] <mru> there are some old replies from nvidia people [20:39:00] <thresh> it even compiled cleanly on osx [20:39:07] <astrange> oh, a resizing library [20:39:08] <mru> but yes, forums are the internet equivalent of being placed on hold with phone support [20:39:30] <ohsix> more like getting thrown in the drunk tank while you sober up ;] [20:39:38] <astrange> a very strange one [20:40:00] <_av500_> mru: more like writing to a message wall in a deserted shopping mall [20:40:31] <mru> only the spiders will read it [20:41:19] <_av500_> mru: gg heard you, they provide decode_to_md5 in their example code :) [20:42:10] <janneg> sloccount counts "php: 35742 (29.70%)" wtf? [20:42:18] <Yuvi> BBB: in a sec, I'm actually compiling it now [20:42:20] <Yuvi> bcoudurier: sure [20:42:29] <Yuvi> bcoudurier: 1/1000 [20:43:06] <bcoudurier> shit [20:43:11] <bcoudurier> can't we use a more decent one ? :> [20:43:34] <Yuvi> the problem is that the numerator is fixed at 1e9 [20:43:39] <Yuvi> err denominator [20:43:46] <Yuvi> you can write whatever for the numerator [20:45:03] <janneg> syntax highlighting for the documentation [20:45:15] <_av500_> what? [20:45:28] <bcoudurier> // ms precision is the de-facto standard timescale for mkv files [20:45:28] <bcoudurier> av_set_pts_info(st, 64, 1, 1000); [20:45:29] <bcoudurier> rofl [20:45:57] <Yuvi> x264 does some math to decide a better one I think? [20:46:14] <bcoudurier> best one for audio is 1/sample rate [20:46:28] <BBB> bcoudurier: I'm quite sure the mkv demuxer doesn't do that? [20:46:31] <BBB> their webm one does? [20:46:35] <BBB> that's crazy [20:46:39] <Yuvi> BBB: muxer [20:46:50] <BBB> doesn't the user set the timescale for muxer? [20:46:53] <Yuvi> bcoudurier: too bad you can't represent those exactly with x/1e9 [20:46:55] * BBB confused [20:46:57] <janneg> _av500_: examples/includes/geshi/ 29kloc php [20:47:03] <bcoudurier> Yuvi, yes, that's why mkv sucks [20:47:53] <Yuvi> BBB: the issue is that mkv uses a weird way of specifying its one timebase for the file and most common timebases aren't exactly representably [20:47:56] <Yuvi> representable [20:48:17] <Yuvi> so I just chose 1/1000 always since that's what everyone else uses [20:49:21] <CIA-7> ffmpeg: bcoudurier * r23197 /trunk/libavcodec/libx264.c: fix x264 encoding when delay is > number of input frames [20:49:30] <bcoudurier> but that is really bad for 23.98 [20:49:37] <bcoudurier> and bad for audio as well [20:49:54] <bcoudurier> 1000000 should be better at least [20:50:37] <mru> people with the attention span of a US commercial interval simply don't understand problems like clock drift [20:52:21] <Yuvi> bcoudurier: yeah, I want to think about the cluster+block implications in a bit, afk for a few [20:52:53] <bcoudurier> Yuvi, can you please look at the ogg muxer patch as well ? [20:53:01] <bcoudurier> that would be nice to fix this once and for all :> [21:06:43] <mru> and here's the statement where the fsf takes credit for everything [21:06:47] <mru> http://www.fsf.org/news/free-software-foundation-statement-on-webm-and-vp8 [21:07:38] <Dark_Shikari> mru: lolo [21:08:41] <_av500_> ...users can show support for this new technology by joining our PlayOgg mailing list... [21:08:49] <_av500_> playogg? err? [21:09:07] <bcoudurier> how does chrome support vp8 ? [21:13:11] <Yuvi> probably with the patches they're sending us [21:13:57] <saintd3v> so has anyone checked if mkv in a video tag actually works in current chrome releases, or not? [21:14:27] <janneg> bcoudurier: chrome with vp8 support will be released next week [21:14:39] <_av500_> saintd3v: it works in todays opera :) [21:14:45] <saintd3v> erm sorry 'WebM' :/ [21:15:20] <saintd3v> _av500_: know of any sites that have an example of a video tag with matroska? [21:17:39] <Yuvi> whoops, I sent the exact same patch and claimed it was fixed [21:17:55] <mru> was the "new" one approved? [21:18:14] <_av500_> saintd3v: labs.opera.com has some [21:18:35] <_av500_> i downloaded some .wemb from there [21:45:47] <mchinen> are there any known cases where the timebase might be less than the sample rate for audio files? [21:51:27] <bcoudurier> depends on the file format [21:51:32] <mchinen> i guess this happens when we have audio/video and fixed video framerate too.. [21:53:44] <mchinen> so how would you feel to also have a seek by sample seek function for accurate audio seeking? [21:55:00] <mchinen> or a different, probably better option is to return info about the start sample of the decoded audio [21:55:15] <mchinen> i don't think that's in there now, is it? [21:58:44] <bcoudurier> well you have to seek at a frame [22:00:05] <mchinen> yes, for this reason i think its better to have the client be able to see what the start sample is [22:00:21] <mchinen> *of the decoded frame [22:03:18] <bcoudurier> it's a matter of timestmaps conversion [22:05:47] <mchinen> but if the samplerate is greater than the timebase, you won't be able to specify exact samples since it is an int [22:07:17] <bcoudurier> I see, well I guess that driven by the users [22:07:22] <bcoudurier> do they want that ? [22:07:43] <mchinen> at least for audio editors this is useful [22:07:52] <mchinen> for playback i don't think anyone cares [22:09:03] <mchinen> i also saw a few mails on the user list asking about this [22:16:52] <Yuvi> Dark_Shikari: btw, lavf's mkv muxer supports streaming [22:16:58] <Dark_Shikari> it does? [22:17:05] <Yuvi> yes, I fixed that a while back [22:17:07] <Dark_Shikari> oh nice [22:30:16] <mru> hmm... is the vp8 source code licence gpl compatible? [22:31:13] <BBB> poor diego [22:31:36] <BBB> mru: given that collabora worked together with them, it surely is [22:31:39] <BBB> gstreamer is lgpl after all [22:31:44] <Dark_Shikari> it's bsd [22:31:49] <Dark_Shikari> oh wait [22:31:51] <Dark_Shikari> you mean the patent license [22:31:53] <mru> yeah [22:31:57] <Dark_Shikari> actually... probably not [22:32:04] <mru> the bit about losing the licence if you sue [22:32:20] <mru> that doesn't look very gpl-compatible [22:32:27] <Dark_Shikari> let's put it under --enable-nonfree then [22:33:09] <peloverde_> blol [22:33:12] <j-b> BBB: poor diego? why ? [22:33:30] <Kovensky> <@mru> hmm... is the vp8 source code licence gpl compatible? <-- BSD [22:33:46] <Kovensky> oh, that thing [22:33:51] <mru> I thought it was bsd + patent stuff [22:33:53] <kierank> didn't they say they could license it as lgpl [22:34:13] <drv> i thought they meant lgpl the lib wrapper part for ffmpeg [22:34:17] <drv> not the actual library [22:34:21] <Kovensky> how did they stuff VP8 in matroska anyway, use the V_VFW_FOURCC tag? D: [22:34:26] <kierank> oh i see [22:34:55] <mru> V_VP8 apparently [22:35:09] <Kovensky> ._. [22:35:26] <Kovensky> I thought they'd do something like V_ON2_GOOGLE_VP8 because why not [22:35:40] <Kovensky> free advertising! [22:35:52] * Kovensky wonders how big of a flop will webm be [22:36:12] * Kovensky still lols @ no b-frames, no aq and code-as-spec [22:36:31] <BBB> j-b: he's flaming google on the ml [22:36:50] <j-b> BBB: he is right [22:36:54] <Kovensky> o, fflames, where [22:37:08] <j-b> BBB: Google or not, the library is a mess [22:37:15] <BBB> I'm going through it [22:37:40] <peloverde_> diego has a point, they have a 0-day list of 30+ commercial partners, there's no reason why they couldn't have gotten these patches pre-approved weeks ago [22:37:47] <Yuvi> I like how there's an install target, but it doesn't do anything [22:38:11] <_skal_> Kovensky: there's AQ [22:38:14] <_skal_> oops [22:38:17] <_skal_> wrong win [22:38:19] <BBB> I only need vpx_codec/ right? [22:38:24] <j-b> no [22:38:26] <BBB> the rest seems crap and old stuff for vp8 [22:38:36] <BBB> what does the ffpatch use? [22:38:53] <Yuvi> http://pastie.org/968513 <- I think almost all of these are needed [22:39:03] <Yuvi> vp8e.h maybe not [22:39:08] <BBB> oh you need vp8x.h also [22:39:10] <BBB> blegh [22:39:13] <j-b> you need vpx_codec and vp8 [22:39:15] <BBB> that's a big sourcetree [22:39:20] <BBB> darnit [22:39:25] <BBB> what is vpx_codec/ and what is vp8? [22:39:26] <j-b> cp vp8/*.h and vpx_codec/*.h [22:39:35] <BBB> I want to look what the decoder does [22:39:39] <BBB> maybe rewrite it ;) [22:39:57] <Yuvi> rewriting it is a given ;) [22:41:54] <BBB> well this is better than re'ing a binary without comments [22:41:58] <BBB> at least you can see waht it does [22:45:53] <CIA-7> ffmpeg: michael * r23198 /trunk/libavutil/ (log.c log.h): av_default_item_name() so Simply AVClasses need 1 function less. [22:47:35] <BBB> I think the patent license is pretty standard [22:48:31] <mru> yes, but is it gpl-compatible? [22:48:44] <BBB> I'm asking our experts ;) [22:48:45] <mru> being incompatible with the gpl is also pretty standard [22:51:34] <CIA-7> ffmpeg: michael * r23199 /trunk/libavutil/ (log.h avutil.h): [22:51:34] <CIA-7> ffmpeg: Make it possible for a log context to keep track of its parent context. [22:51:34] <CIA-7> ffmpeg: This is usefull to keep track and display relations where things are a [22:51:34] <CIA-7> ffmpeg: bit more complex (like AVProtocols or demuxers used by demuxers and such) [22:52:30] <CIA-7> ffmpeg: michael * r23200 /trunk/libavutil/log.c: Print parent log context too, if available. [22:56:22] <CIA-7> ffmpeg: michael * r23201 /trunk/libavcodec/ (opt.c eval.c eval.h ratecontrol.c): [22:56:22] <CIA-7> ffmpeg: Change eval API to take parent log context and log level offset. [22:56:22] <CIA-7> ffmpeg: this is based on stefanos work, especially all bugs are his fault ;) [22:59:38] <BBB> uhm... so the whole of vpx_codec/* appears to be a very complex, big huge wrapper around something that has so many layers that I lost track already? [22:59:43] <BBB> what a waste [22:59:50] <BBB> I suppose vp8/ is the implementation then? [22:59:54] <j-b> BBB: probably for VP3, VP6 and VP7 [23:00:01] <j-b> and they aren't in the release spec [23:00:10] <j-b> so, only vp8/ should be interesting [23:00:20] <BBB> darnit, vpx_codec/ was smaller so I started there [23:00:24] <ohsix> BBB: are you using gnu global or lxr/mxr to look around or something? they can be really handy (global is really fast at generating indexes and html too) [23:00:26] <BBB> ok, vp8/ then [23:00:35] <Yuvi> yeah, sounds similar to the vp3 dump [23:00:40] <Yuvi> except more organized [23:00:42] <BBB> gnulxrmxr? [23:00:43] <BBB> wtf? [23:00:47] <BBB> no I use xcode [23:00:59] <BBB> it's kinda crappy but it can search [23:01:10] <ohsix> http://www.gnu.org/software/global/ [23:01:13] <BBB> I'll look at mxrlxr later :) [23:01:48] <ohsix> well, heh; lxr is the thing, mxr is mozillas modification of the original, but they're just source browsers; global is probably easier for a one-off [23:01:53] <astrange> i use textmate, it's probably a little better than xcode but neither have indexing [23:02:28] <ohsix> its _really nice_ to fly around stuff; even if its html in a browser and it has to be generated :] [23:02:50] <BBB> xcode will do for now, I'm just looking :) [23:03:38] <Dark_Shikari> http://daringfireball.net/linked/2010/05/19/vp8-funny [23:03:39] <Dark_Shikari> LOL [23:06:50] <mru> he'd be funnier if he weren't such a hypocrit and fanboy [23:07:18] <Dark_Shikari> who, christopher blizzard or daringfireball? [23:07:22] <mru> gruber [23:07:23] <Dark_Shikari> the former is funny _because_ he's a hypocrit :) [23:07:57] <BBB> blizzard? [23:08:10] <BBB> you ever believed a word of that bastard who says "ffmpeg is illegal"? [23:08:36] <BBB> he actually tried to convince the mozilla foundation that they shouldn't use ffmpeg because our sources are illegal and might lead to patent infringement in otherwise patent-free codecs [23:08:48] <BBB> as if the implementation would suddenly make theora violate patents [23:09:04] <mru> it could [23:09:09] <mru> ever heard of "essential patents" [23:09:14] <mru> vs non-essential ones [23:09:30] <BBB> two feature-par decoders will violate the same patent [23:09:36] <BBB> *patents [23:09:45] <mru> not necessarily [23:09:50] <BBB> ? [23:09:53] <mru> one might use some patented trick to run faster [23:10:00] <mru> or whatever [23:10:04] <janneg> or slower [23:10:21] <peloverde> or upsidedown! [23:10:23] <Yuvi> like (a-b)^a or whatever you do to put the sign back branchless [23:10:31] <mru> yeah, such things [23:10:46] <BBB> aaron says the patent-clause is potentially not gplv2-compatible, but might be gplv3-compatible and will get back to me tomorrow [23:10:57] <BBB> anyone wanna wack them on the ml? :) [23:11:01] <Dark_Shikari> who's aaron, sflc? [23:11:04] <BBB> sflc [23:11:28] <BBB> gplv3 contains a similar clause although it has a grace period, unlike google's patent recovation clause [23:11:54] <BBB> gplv2 does not allow revocation like that, but it's not 100% sure if that extends to patents or just software itself [23:11:58] <BBB> so he'll look into it ;) [23:12:06] <mru> unless it's a strict subset of the gpl, it's not compatible [23:12:27] <BBB> ok, so go whack the patch :) [23:12:55] <mru> there's also specific talk about patents in the gpl, remember [23:13:03] <mru> and this time that clause is relevant [23:13:07] <BBB> right [23:13:17] <mru> because google owns both the patent and the copyright [23:13:18] <BBB> because google owns them [23:13:23] <BBB> good point [23:13:36] <mru> so is that patent licence compatible with what the gpl requires? [23:13:43] <mru> I somehow doubt that [23:14:27] <BBB> so probably no, I guess [23:14:43] <BBB> I'm gonna go home btw, but feel free to send this as a response to the ml :) [23:17:35] <astrange> raising [23:20:57] <drv> i like how one of the posters on DS's blog post says webm will be like PNG "in that that either you support it or you don't" [23:21:06] <drv> i hope he doesn't mean like PNG - some features missing in IE for a long time ;) [23:21:48] <Kovensky> so how's the diego vs google fflame going [23:21:57] <bcoudurier> rofl [23:22:32] <mru> I see some fantastic trolling opportunities for linuxtag [23:23:11] <Kovensky> IE already played the H.264 card [23:23:16] <Kovensky> I doubt they'll jump the WebM bandwagon [23:23:32] <Kovensky> same for Safari [23:23:49] <mru> http://windowsteamblog.com/windows/b/bloggingwindows/archive/2010/05/19/ano… [23:24:06] <Dark_Shikari> they're supporting whatever system codecs you have installed support [23:24:13] <Dark_Shikari> in practice this means whatever microsoft wants [23:24:30] <astrange> safari supports system codecs too [23:24:50] <astrange> i'm willing to support libvpx in perian when all their patches get merged [23:25:05] <bcoudurier> mru, is uint8_t one byte or can be more than one ? [23:25:11] <astrange> one byte [23:25:32] <Kovensky> mru: hmm [23:25:35] <mru> on a system with 8-bit bytes [23:25:42] <Kovensky> so they're doing exactly what mozilla says is evil :D [23:25:42] <bcoudurier> wtf is yadif having sizeof(uint8_t) code [23:25:51] <mru> posix requries 8-bit bytes [23:25:55] <mru> C does not [23:25:59] <Kovensky> bcoudurier: too much copypasta? [23:26:14] <Kovensky> mru: well, C does require "sizeof(uint8_t)" to be 1 [23:26:20] <mru> no [23:26:22] <Kovensky> it is 8 bits wide after all [23:26:25] <astrange> malloc(x * sizeof(uint8_t)) makes sense [23:26:26] <mru> C requires sizeof(char) == 1 [23:26:27] <Kovensky> o_O [23:26:36] * Kovensky loses trust in stdint.h [23:26:46] <astrange> if it's next to another kind of malloc, or if you want to extend support to 16 bit pixels [23:26:50] <mru> there is no requirement that int8_t == char [23:26:56] <bcoudurier> well [23:27:05] <bcoudurier> you just supported sizeof(char) [23:27:47] <Kovensky> <@mru> there is no requirement that int8_t == char <-- but isn't there a requirement that int8_t be 8 bits wide? same for int16_t being 16 bits wide, int32_t, etc [23:27:49] <mru> non-8-bit char systems are rare and painful though [23:27:53] <bcoudurier> for malloc I'm always for p = malloc(sizeof(*p)) [23:28:02] <mru> +1 [23:28:15] <Dark_Shikari> +1

1 0