[FFmpeg-devel-irc] IRC log for 2010-05-30

[irc at mansr.com]

[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/b5cd4c64/attachment.txt
[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.