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

[irc at mansr.com]

[00:03:02] <j0sh> lu_zero: i still don't see where it knows if "something is leftover"
[00:03:49] <j0sh> raw_packet_buffer_remaining_size ?
[00:09:54] <efriedma> Dark_Shikari: could you commit http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/2010-July/094291.html ?
[00:12:07] <Dark_Shikari> I thought they got you commit access?
[00:12:33] <efriedma> if i did, someone forgot to tell me :)
[00:13:00] <Dark_Shikari> There's a 27-post long thread on the secret mailing list about how you should get one.
[00:13:04] <Dark_Shikari> With no disagreements.
[00:13:05] <lu_zero> rt->cur_transport_priv I guess
[00:13:45] <j0sh> in rtsp, yes
[00:14:24] <kierank> does git svn remember passwords by default?
[00:14:27] <CIA-92> ffmpeg: darkshikari * r24702 /trunk/libavcodec/x86/ (Makefile dsputil_mmx.c h264dsp_mmx.c):
[00:14:27] <CIA-92> ffmpeg: H.264: SSE2/SSSE3 weighted prediction asm
[00:14:27] <CIA-92> ffmpeg: Patch by Eli Friedman <eli.friedman at gmail dot com>
[00:14:58] <lu_zero> in rtp buf
[00:16:13] <j0sh> I *think* av_read_packet won't iterate to the next/newest buffer in the list until the old buffer is exhausted
[00:16:58] <j0sh> but i'm not 100% sure
[00:17:09] <efriedma> Dark_Shikari: you forgot to commit a file
[00:27:32] <Kovensky> kierank: yes
[00:27:44] <Kovensky> that's a subversion default IIRC
[00:47:22] <Dark_Shikari> efriedma: oops
[00:47:23] <Dark_Shikari> I'm stupid
[00:48:18] <Dark_Shikari> efriedma: no, it's your mistake.  your patch is malformed
[00:48:21] <Dark_Shikari> so it failed to write the file
[00:49:19] <efriedma> Dark_Shikari: really? it's just the output of svn diff
[00:49:34] <Dark_Shikari> It says malformed patch.
[00:49:37] <Dark_Shikari> Maybe the mailer broke it.
[00:49:49] <Dark_Shikari> fixed
[00:50:39] <CIA-92> ffmpeg: darkshikari * r24703 /trunk/libavcodec/x86/h264_weight_sse2.asm: Add file missing in r24702
[03:59:05] <Dark_Shikari> Yuvi: how does the speed of the arm theora idct compare to the "real" idct?
[03:59:46] <Yuvi> I haven't measured, let me check
[04:00:06] <Dark_Shikari> is it very close to the real idct in terms of rounding?
[04:00:14] <Dark_Shikari> and it doesn't have any extraneous quantization factors, right?
[04:00:17] <Dark_Shikari> like the h264 one does
[04:02:49] <Yuvi> it's quantized differently enough that you can't substitute it with simple idct
[04:03:06] <Yuvi> see vp3.c:1469
[04:03:31] <Yuvi> iirc it looks wrong even with that
[04:03:31] <Dark_Shikari> I mean that the only difference in quantization factors is a constant
[04:03:38] <Dark_Shikari> as opposed to h264
[04:03:41] <Dark_Shikari> which has a quant factor per-coeff
[04:04:41] <Yuvi> I think it's similar enough that you could munge it, not entirely sure
[04:07:27] <Dark_Shikari> I want to swap in an idct to h263, but h264's requires a lot of munging because of the per-coeff multiplication factors
[04:12:19] <Dark_Shikari> so any idea how much faster it is?
[04:14:59] <Dark_Shikari> numbers vs h264 8x8 idct migth be useful too
[04:18:55] <Yuvi> with neon, vp3 is ~20 cycles slower than simple_idct
[04:19:55] <Yuvi> note that simple_idct has logic to do less work if there's lots of zeros
[04:20:27] <Dark_Shikari> ah
[04:20:39] <Dark_Shikari> how does h264 compare?
[04:20:54] <Yuvi> which for vp3 has to be done outside calling the idct to be worthwhile
[04:25:36] <Dark_Shikari> I'm really surprised the gain is that much
[04:25:45] <Dark_Shikari> er, with vp3 and the idct issue you mentioned
[04:26:19] <Dark_Shikari> and that isn't even just dc-only blocks
[04:30:12] <Yuvi> ~440 vs 460, and counting no DC-only blocks
[04:30:23] <Yuvi> h264 is 440 vs. 380
[04:31:27] <Yuvi> actually subtract 54 cycles from those numbers, I didn't subtract out the nop time
[04:32:42] <Yuvi> and it seems I never applied 8x8idct to ffmpeg, another thing to rebase and fix
[04:32:52] <Dark_Shikari> ?
[04:32:57] <Dark_Shikari> 8x8idct what?
[04:33:01] <Yuvi> h264 8x8
[04:33:09] <Dark_Shikari> wait, there's no neon version??
[04:33:52] <Dark_Shikari> also, what kind of bitrate is this at?
[04:35:03] <Yuvi> 580 kbit for 640x272
[04:35:05] <wbs> j0sh: regarding returning splitted packets in rtsp...
[04:35:10] <Yuvi> theora
[04:36:03] <wbs> j0sh: you don't need to bother with looking at the code in utils.c - that's for readding the packets used by av_find_stream_info into the queue, so that the user application gets them
[04:36:45] <wbs> j0sh: and at the start of rtsp_fetch_packet, it checks if cur_transport_priv is set (which gets set if the previous rtp read returned 1), then we just try to return a new packet from the previously buffered data
[04:37:12] <wbs> j0sh: once that isn't set any longer, we go on to actually look for and wait for a new packet from the network
[04:37:18] <Dark_Shikari> Yuvi: so ~400 cycles for a single idct?
[04:38:05] <wbs> j0sh: and "how does the application know to request another packet" - it doesn't, but once it wants another packet, it calls av_read_frame(), which ends up here, and we either immediately return one from the buffered data if we got one waiting, or block while waiting for more data from the  network
[04:38:41] <Yuvi> according to start/stop timer, checkasm reports 160 cycles for 8x8 idct
[04:39:10] <Dark_Shikari> then where's the 440 from?
[04:39:16] <Yuvi> maybe some prefetch issues, the stride is the only difference I can think of
[04:39:41] <Yuvi> start/stop timer in ffmpeg around the 3 idct_add
[04:39:52] <Dark_Shikari> 3? so it'd be 440/3?
[04:40:03] <Yuvi> no, 3 different version I mean (h264, vp3, simple)
[04:40:08] <Dark_Shikari> oh.
[04:43:29] <CIA-92> ffmpeg: mstorsjo * r24704 /trunk/libavformat/rtpdec_xiph.c:
[04:43:29] <CIA-92> ffmpeg: rtpdec_xiph: Split packets in the depacketizer
[04:43:29] <CIA-92> ffmpeg: The vorbis decoder doesn't handle more than one audio frame packed into
[04:43:29] <CIA-92> ffmpeg: the same AVPacket, so they need to be split in the depacketizer.
[05:01:27] <j0sh> wbs: ah, that makes sense
[05:01:53] <j0sh> wbs: muchas gracias for the explanation
[05:11:33] <j0sh> wbs: wouldn't it be a bit more convenient to pass in uint8_t **buf and int *len to handle_packet, rather than NULL/0 in the case of buffered data
[05:12:23] <j0sh> that'd eliminate some internal bookkeeping within the depacketizer
[05:13:23] <wbs> umm... elaborate, please?
[05:14:12] <j0sh> when we have buffered data,we pass in NULL for the buffer and expect the depacketizer to handle that buffering
[05:14:52] <j0sh> but can't we just do something like *buf += pkt_len or something, and pass that buffer back in again
[05:15:01] <wbs> ah, I see
[05:15:09] <j0sh> (not actually suggesting we implement something like that since its a major internal api change)
[05:15:25] <wbs> true, that would be convenient in one way, and would avoid some data copying
[05:15:52] <j0sh> quite a bit cleaner too, methinks
[05:15:56] <wbs> but would require changes up to the rtsp layer (since that layer owns the initial packet data buffer)
[05:16:29] <j0sh> yeah
[07:28:56] <superdump> morning peoples
[07:29:08] <superdump> marcelo has just about finished the AMR-WB decoder
[07:29:10] <kshishkov> morrow, superdump
[07:29:14] <kshishkov> yay!
[07:29:22] <superdump> but he still has some audible deviations from the reference
[07:29:25] <superdump> http://github.com/marspeople/AMR-WB
[07:29:37] <kshishkov> it took him less time than for somebody else on AMR-NB too!
[07:30:01] <superdump> his code is there in libavcodec/amrwb*
[07:30:03] <superdump> yeah :)
[07:30:15] <superdump> it certainly helps having someone around who knows how bad the specs are ;)
[07:31:04] <superdump> i would appreciate it greatly if people could review the code
[07:31:05] * kshishkov wrote a blog rant on that
[07:31:13] <superdump> so i saw
[07:31:14] <cartman> superdump: LGPL?
[07:31:15] <superdump> :)
[07:31:24] <superdump> yes, we dictate that
[07:31:43] <cartman> yay!
[07:31:49] <cartman> one more decoder to enable :p
[07:31:50] <superdump> floating point :)
[07:32:11] <superdump> and i guess it will mean that the majority of people won't need to compile in opencore
[07:32:21] <wbs> I still need it for the nb encoder
[07:32:25] <mru> eh, majority don't need amr in the first place
[07:32:33] <wbs> but I guess I'm in minority ;P
[07:32:34] <superdump> hopefully, yes
[07:33:16] <cartman> good news
[07:33:19] <superdump> does anyone have any suggestions/tips for finding the audible issues other than unit testing each bit of his code against the reference?
[07:33:59] <kshishkov> use Vitor on the source :)
[07:34:12] <superdump> hehe
[07:34:23] <superdump> well, i could give him a nudge i suppose
[07:35:09] <superdump> i think i'll suggest that he send a patch to the SoC mailing list asking for review and help finding the deviations
[07:35:32] <kshishkov> and you can also try opening reference decoded file and new decoded to look at what spectrum/waveform differences it has
[07:36:25] <kshishkov> or encode/decode sine wave
[07:36:58] <wbs> the problem is that there's no good really freely available encoder
[07:37:09] <wbs> there's the nondistributable reference code though
[07:37:15] <kshishkov> it does not matter with sines
[07:37:26] <wbs> but we removed libavcodec integration of that a year ago, though
[07:37:37] <superdump> i think he's got the reference encoder plugged up using the old code
[07:37:47] <wbs> ok, that's good
[07:37:55] <wbs> I think I've got a branch with that somewhere, too, just for testing
[07:39:11] <superdump> kshishkov: can one use audacity for comparing spectra?
[07:39:23] <kshishkov> of course!
[07:39:27] <superdump> good :)
[07:39:30] <kshishkov> peloverde does, for example
[07:44:00] <mru> superdump: btw, any plans for the 14th?
[07:44:11] <superdump> not sure
[07:44:27] <superdump> we're going over to the west side to see jenny's parents from saturday
[07:44:32] <superdump> not sure how long we'll be there
[07:44:36] <mru> ok
[07:44:40] <superdump> are you heading over to stockholm?
[07:44:43] <mru> yeah
[07:44:58] <superdump> well, give me a poke and i'll let you know :)
[07:45:02] <mru> was thinking of rounding up ffsthml in usual fashion
[07:45:12] <superdump> ffshtml
[07:45:19] <mru> ffsthlm
[07:45:20] <superdump> :)
[07:52:08] <superdump> there we go, vitor nudged with marcelo in a CC :)
[08:31:45] <lu_zero> j0sh: so you'd prefer keeping the buffering logic in the rtsp_fetch?
[09:32:30] <mru> merbzt: ping
[09:33:30] <merbzt> yes ?
[09:33:48] <mru> are you free on the 14th?
[09:34:06] <merbzt> bizzy from 1600 ish
[09:34:12] <merbzt> free for lunch though
[09:35:37] <mru> andoma: ^^
[09:36:00] <andoma> hm
[09:36:15] <merbzt> long time no see andoma
[09:36:27] <andoma> that's a saturday right?
[09:36:31] <mru> yes
[09:36:32] <merbzt> yes
[09:36:57] <andoma> good, i've screwed up so many dates recently :)
[09:37:09] <mru> dates? aren't you married?
[09:37:11] <andoma> but i've no plans for that day :)
[09:37:23] <andoma> no i'm not :)
[09:37:51] <andoma> i'm just a "sambo" whatever that is in english
[09:37:56] <mru> yeah, well
[09:37:58] <mru> same thing
[09:38:13] <merbzt> andoma: pseudo-married
[09:38:16] <wbs> swmbo - she who must be obeyed
[09:38:32] <mru> married or not, she still takes all the money
[09:39:21] * _av500_ has a deja vu
[09:40:10] <merbzt> me too
[09:40:58] <mru> I've heard it's quite common when women are concerned
[09:41:07] <kshishkov> or governments
[09:42:01] <andoma> so... dinner the 14th then?
[09:42:08] <andoma> err
[09:42:09] <andoma> lunch
[09:42:23] <mru> guess it is
[09:42:35] <merbzt> 12-13 is ?
[09:42:37] <merbzt> ish
[09:42:44] <andoma> cafe nero?
[09:42:52] <andoma> or change place?
[09:43:08] <merbzt> maybe mru will appear this time
[09:44:36] * kshishkov remembers April 7th, 2009
[09:48:52] * superdump makes a note
[09:49:15] <superdump> if i'm back in sthlm i'll be there
[09:49:24] <superdump> but nudge me again anyway :)
[09:49:30] <mru> will do
[09:53:22] <merbzt> superdump: need ma keys ...
[09:53:29] <superdump> oh yes!
[09:53:32] <superdump> shit, sorry
[09:53:35] <superdump> i'd forgotten about them
[09:53:38] <superdump> they're safe :)
[09:54:29] <merbzt> goodie
[09:55:30] <mru> safe at the bottom of some river
[09:56:18] <kshishkov> that's not safe
[09:56:42] <mru> http://www.theregister.co.uk/2010/08/05/novelty_numberplate/
[09:56:42] <kshishkov> safe means "filled with tons of concrete in some deep cave"
[09:58:12] <cartman> stupid
[09:58:55] <mru> cartman: stupid to keep merbzt's keys safe?
[09:59:33] <cartman> that license plate thing
[09:59:47] <mru> of course it's stupid
[09:59:52] <mru> that's why it got mentioned
[10:31:44] <pross-au> A Ukrainian computer programmer has been arrested after allegedly mutilating his grandmother and eating her alive. http://news.ninemsn.com.au/world/7940238/ukrainian-man-eats-grandma-alive
[10:32:25] <kshishkov> let's wait for a few days for conclusion
[10:33:48] <pross-au> k
[10:35:13] <kshishkov> you know, in such news aftermath really matters - if nothing happens, it was probably a hoax
[10:46:27] <pross-au> i am just curious as to why it was so important to mention his occupation.
[10:48:32] <_av500_> to warn the populace
[10:49:41] <kshishkov> maybe they just wanted to give at least any details
[10:49:55] <kshishkov> you know, news from third-world countries are not that common
[10:51:20] <pross-au> _av500_, you are onto something.
[11:43:40] <KotH> pross-au: http://attila.kinali.ch/tagesanzeiger-zuerich-informatiker.jpg
[11:43:45] <KotH> pross-au: if you can read german
[11:45:05] <KotH> it was a letter to a news paper, after, within one or two months, two IT guys killed their familly and then themselves, in .ch a few years back
[11:55:32] <Compn> the it guys' families wouldnt stop asking how to email those pictures onto that big blue E thing
[11:56:07] <Compn> *thats* internet explorer, you have to use an email program to send pictures, ahhhhhhhhh
[11:57:10] <kshishkov> it's easier in .ua - you'll have to do all by yourself since nobody old enough does not understand this new technologies
[11:57:41] <KotH> kshishkov: it's called "digital divide"
[11:58:26] <kshishkov> KotH: and electrical divide as well since old folks are oftean afraid of electricity
[11:58:42] <KotH> kshishkov: or to paraphrase marc pernski "digital natives" and "digital foreigners"
[11:59:24] <mru> and the floating-point divide?
[11:59:26] <KotH> kshishkov: "electricity does not crawl up the wall"
[12:06:08] <KotH> mru: floating point? is that the thing people try to use when they try to calculate something exactly
[12:07:36] <mru> yes, and then they sink if so much as nudged by a nan
[12:13:17] <KotH> to sink or not to think...
[12:15:46] <pross-au> http://www.wimp.com/motionillusion/
[12:17:28] <kshishkov> masking!
[12:17:50] <pross-au> Neat
[12:39:45] <peloverde> Are enum vars allowed to take numerical values that don't have names in the enum?
[12:39:53] <mru> yes
[12:40:06] <mru> how would you enforce anything else?
[12:40:25] <KotH> TP7 had range checks :)
[12:40:46] <mru> runtime checks at each assignment would be ridiculous
[12:40:50] <twnqx> but you were able to turn them off for speed
[12:41:02] <mru> especially with a sparsely populated enum
[12:41:09] <twnqx> mru: like array bounds checks? :>
[12:41:14] <mru> and what would you do if the check failed?
[12:41:25] <kshishkov> throw an exception
[12:41:29] <peloverde> We had problems with negative values
[12:41:30] <mru> twnqx: array checking is a simple range check
[12:41:34] <Kovensky> <@mru> how would you enforce anything else? <-- static checks?
[12:41:44] <mru> Kovensky: impossible
[12:42:08] <kshishkov> I can overwrite enum memory indirectly
[12:42:09] <mru> void foo(enum bar arg) { ... }
[12:42:18] <mru> kshishkov: good point
[12:42:19] <peloverde> "for (enum myEnum i = myEnumMax; i >= myEnumMin; i--)"
[12:42:41] <peloverde> The compiler decided i >= myEnumMin was always true
[12:42:47] <mru> yes, I know
[12:42:53] <peloverde> Is the legal?
[12:42:54] <mru> which was a valid thing to do
[12:43:09] <peloverde> Taht seems to contradict your previous statement
[12:43:12] <mru> no
[12:43:18] <mru> the enum had unsigned type
[12:43:26] <mru> and min == 0
[12:43:36] <mru> i >= 0u is always true
[12:43:39] <mru> enum or no enum
[12:43:48] <peloverde> so enums are unsigned?
[12:44:05] <kshishkov> by default
[12:44:05] <mru> they may be
[12:44:08] <mru> no
[12:44:14] <mru> it's implementation-defined
[12:44:22] <mru> and each enum can have a different type
[12:44:39] <mru> "Each enumerated type shall be compatible with char, a signed integer type, or an unsigned integer type."
[12:45:05] <mru> "The choice of type is implementation-defined,108) but shall be capable of representing the values of all the members of the enumeration."
[12:45:17] <mru> 108) An implementation may delay the choice of which integer type until all enumeration constants have been seen.
[12:45:32] <peloverde> It seems like having enum arrays in the context is a recipe for possibly wasting space
[12:46:52] <mru> if the compiler makes the type wider than necessary, yes
[12:47:14] <peloverde> yes but over the set of wonky compilers we (try to) support
[12:47:29] <mru> I'm not disagreeing
[12:47:54] <mru> enums are a weird language feature
[12:49:12] <peloverde> http://pastebin.com/Ghn29U26
[12:50:03] <KotH> if you ever want to see strang features, have a look at usb... there are no non-strange features
[12:50:45] <mru> or anything from the enterprise world
[12:50:57] <peloverde> At somepoint someone went though and changed a bunch of vars to enum to silence a bunch of ICC warnings, I want to undo (parts) of that
[12:51:33] <mru> that is a silly warning
[12:51:33] <kshishkov> it's Carl Eugen you want to troll then
[12:52:18] <peloverde> it is a silly warning
[12:52:36] <peloverde> and on gcc-x86_64 we are worse off for it
[12:56:32] <peloverde> At least gcc parentheses warnings don't make generated code any worse
[12:58:47] <KotH> lol
[12:59:03] * kshishkov waits for a day when GCC will become actually Lisp compiler written in Lisp
[13:00:00] <mru> the machine descriptions are written in a lisp-like language
[13:00:56] <kshishkov> well, they haven't managed to add enough warnings to demand input C to be actual Lisp
[13:04:54] <chiiph> I have a patch to support metadata in flv for flvenc... what's the procedure to get it reviewed and potentially in?
[13:05:45] <kshishkov> submit it to ffmpeg-devel mailing list, it will be commented there and if okayed somebody will commit it
[13:05:58] <kshishkov> otherwise you'll have to change/improve it and resend
[13:06:13] <chiiph> kshishkov: oks, thanks
[13:26:46] <pJok> kshishkov, the hackerspace im at started having lisp nights...
[13:27:17] <kshishkov> pJok: I'm not against Lisp, I'm against misusing it
[13:27:41] <kshishkov> (same for other languages, though for C++ and Java it seems to be euqivalent to any use at all)
[13:30:29] <pJok> kshishkov, im not against languages either... they have their specific uses...
[13:30:51] <mru> some mainly as torture instruments
[13:31:00] <merbzt> kshishkov: well there are some nice features in c++ I would like to have in c
[13:31:15] <mru> name one
[13:31:18] <kshishkov> there was one guy living in Egland who said it's convenient for him to write Lisp compiler in Forth and C compiler in Lisp then
[13:31:35] <kshishkov> mru: C++ forbids VLA, for instance
[13:31:46] <mru> I doubt that
[13:32:01] <mru> but that's not a feature per se
[13:32:12] <peloverde> mru implicit const cast on multdimensional array
[13:32:12] <mru> not having something
[13:32:26] <mru> peloverde: does c++ do that?
[13:32:32] <peloverde> yes
[13:32:40] <mru> well, that's not really what makes it c++ though
[13:32:42] <lu_zero> peloverde: C++ cast madness isn't a _nice_ feature...
[13:32:51] <peloverde> lu_zero: That particular one is
[13:33:12] <peloverde> recompile aacsbr.o if you disagree
[13:33:16] <mru> lu_zero: he's talking about implicit conversion from "char **" to "const char **"
[13:33:25] <merbzt> mru: constructors, if used sanely
[13:33:32] <mru> merbzt: strongly disagree
[13:33:51] <mru> anything that generates code without looking like it does is evil
[13:34:36] <mru> and what's so hard about typing out a call to an init function?
[13:34:39] <peloverde> more particularly "aacsbr.c:1412: note: expected ‘const float (*)[38][64][2]’ but argument is of type ‘float (*)[38][64][2]’"
[13:34:52] <mru> peloverde: yes, that one is very annoying
[13:41:50] <merbzt> // comments then
[13:41:55] <mru> that's in C99
[13:42:29] <mru> not that consider them all that great
[13:42:44] <mru> mildly more convenient in some cases
[13:44:06] <lu_zero> mru: templating vs preprocessor in the idea, not the implementation
[13:44:19] <lu_zero> if I had to pick something
[13:44:27] <mru> it's hard to tell what the idea was
[13:44:30] <kshishkov> so not C++ either :)
[13:44:36] <mru> c++ templates are not useful as they are
[13:45:00] <lu_zero> kshishkov: apparently ^^;
[13:45:12] <mru> and it's not a substitute for the preprocessor in general
[13:45:30] <lu_zero> they are quite good in making C++ harder to follow and to convert
[13:45:46] <mru> and that's supposed to be a good thing?
[13:45:49] <lu_zero> beside that they apparently give some corner cases a boost
[13:46:06] <mru> so don't have corner-cases, problem solved
[13:46:12] <lu_zero> (the sort benchmark being one touted a lot as a proof C++ is faster)
[13:46:53] <mru> benchmarketing doesn't count
[13:47:05] <kshishkov> sort as a proof that it's easier to write in say Erlang or Haskell
[13:47:33] <mru> nothing beats shell-script for sorting
[13:47:37] <mru> just call 'sort'
[13:48:51] <mru> although comparing a self-hosting language with one reliant on a huge runtime (usually written in C) isn't fair
[13:52:07] <KotH> are haskel or erlang selfhosting?
[13:52:14] <mru> no
[13:52:36] <mru> and c++ only for very liberal definitions of self
[13:52:54] <kshishkov> wait for new GCC!
[13:54:07] <lu_zero> or llvm only systems ^^;
[13:54:26] <lu_zero> (hi freebsd)
[13:55:00] <mru> speaking of bsd, am I dreaming, or did bsd dude really file an almost sensible bug report?
[13:57:00] <lu_zero> which one?
[13:57:04] <mru> vorbis
[13:58:41] <brad0> damn. is roundup hosted on a 486?
[13:58:51] * mru blames lu_zero 
[13:59:18] <brad0> maybe the bug report will pop up like 5 mins from now.
[13:59:54] <Tjoppen> solving bugs before they are reported? :)
[14:00:41] <janneg> kshishkov: g++ supports VLA
[14:01:29] <kshishkov> janneg: thanks, another reason to not use it
[14:03:40] <lu_zero> brad0: roundup is hosted on an opteron and it's the only thing in that server.
[14:04:15] <janneg> kshishkov: at least with -std=gnu++98 which is the default
[14:04:18] * lu_zero takes the blame for having actually seconded the idea of having roundup...
[14:04:25] <brad0> lu_zero: its pretty damn slow.
[14:04:29] <lu_zero> I know
[14:04:53] <brad0> It hasn't always been this slow for me but there must be a lot of people using it at the moment *shrug*
[14:05:19] <kshishkov> janneg: gnu and std? a bit contradicting IMO
[14:05:21] <kierank> mru: you need to rewrite roundup ;)
[14:05:35] <lu_zero> kierank: don't give him more ideas =P
[14:05:48] <mru> not likely to happen
[14:05:58] <lu_zero> anyway it's being hammered
[14:06:12] <brad0> what nick does Diego use?
[14:06:29] <KotH> which diego? :)
[14:06:29] <mru> lu_zero: would an accelerator help?
[14:06:36] <mru> lu_zero: hide it behind something like varnish
[14:06:46] <wbs> accelerator, as in, dropping it off a cliff?
[14:06:51] <lu_zero> mru: I'll try once we move
[14:06:53] <brad0> Biurrun
[14:06:56] <mru> wbs: that's tempting too
[14:07:03] <lu_zero> I was thinking about it
[14:07:32] <lu_zero> and being it around 2-3GB isn't exactly something quick to move...
[14:07:42] <KotH> wbs: no, accelerator as in LHC ;)
[14:07:45] <kshishkov> brad0: he's noble DonDiego
[14:07:51] <wbs> KotH: :-)
[14:07:56] <lu_zero> KotH: we'll do next time =P
[14:08:12] <brad0> I'm just wondering about his last comment here..
[14:08:13] <brad0> http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/2010-August/094496.html
[14:08:15] <KotH> lu_zero: then we have to get to mru's sister first... she's access :)
[14:08:26] <lu_zero> sounds like a plan
[14:08:43] <mru> where's rathann
[14:08:45] <mru> ?
[14:08:52] <KotH> busy :)
[14:09:15] <KotH> lu_zero: apropos...
[14:09:26] <KotH> lu_zero: about the roundup move to natsuki
[14:09:37] <KotH> lu_zero: pester mru, he shall setup everything needed
[14:10:30] <mru> guess I'll need to look into varnish then
[14:10:42] <mru> it should be able to help
[14:11:05] <mru> depends on why it's slow of course
[14:12:53] <Kovensky> I thought they were evil spawn from the devil?
[14:12:58] <Kovensky> (VLAs)
[14:13:02] <Kovensky> derp @ being scrolled up
[14:13:12] <mru> Kovensky: yes, they are
[14:13:28] <lu_zero> KotH: I have everything more or less set on lscube.org as well
[14:13:35] <lu_zero> part missing testing it
[14:13:43] * lu_zero today is dizzy
[14:13:45] <lu_zero> =_=
[14:14:31] * kshishkov remembers a series of ZX games with egg for protagonist
[14:38:11] <KotH> lu_zero: too much grappa yesterday evening?
[14:52:04] <brad0> mru?
[14:52:25] <mru> !
[14:54:14] <brad0> Since ALSA also sets _extralibs which as you said is unnecessary. Should I submit a diff to clean that up?
[14:54:49] <brad0> same for JACK.
[14:55:33] <mru> I don't remember why those are there
[14:55:38] <mru> I'll take a look tonight
[14:55:42] <brad0> k.
[14:55:56] <brad0> I see at least for my backend it just results in 3 -lsndio's in config.mak.
[14:55:57] <KotH> mru: when new people are added to fate, could you please tell them to use rsync instead of http. thanks
[14:56:10] <brad0> for EXTRALIBS.
[14:56:40] <mru> KotH: who's using http?
[14:56:52] <mru> probably mike
[14:56:56] <mru> nobody else is new
[14:57:11] <mru> KotH: send an email to fate at mplayerhq.hu
[14:58:56] <KotH> hmm.. mike should already have all fate samples...and know how to use rsync
[14:59:31] <mru> brad0: btw, since you seem to be on bsd, could you please help us with the vorbis issue?
[14:59:35] <KotH> beside, the isp is located in atlanta, which isnt where mike lives
[14:59:43] <mru> KotH: his isp might be
[14:59:51] <mru> he was on comcast last I heard
[15:00:16] <mru> whois on my IP returns an address in Kent
[15:00:21] <mru> I don't live in Kent
[15:00:21] <lu_zero> 16:38 < KotH> lu_zero: too much grappa yesterday evening?
[15:00:30] <brad0> mru: sure. I know who filed that report.
[15:00:32] <lu_zero> I usually don't drink
[15:00:53] <brad0> edd's our MPlayer port maintainer.
[15:00:55] <lu_zero> it's generic exaustion
[15:01:00] <mru> lu_zero: then "too much" might not be that much
[15:01:10] <mru> brad0: I'd like to get it fixed
[15:01:23] <mru> but it's hard to see what's going on without a machine to run it on
[15:01:26] <brad0> I maintain FFmeg, VLC, Xine and a lot of the other media libs.
[15:01:43] <lu_zero> mru: thehe =)
[15:01:44] <brad0> I can provide you access to a fresh machine with either amd64/i386.
[15:01:47] <mru> so if you or someone else could run it with debug printouts enabled, that would be cool
[15:01:54] <brad0> I have something here I've never used I could setup in a bit.
[15:02:00] <lu_zero> probably would be more correct saying I'm not drinking that often
[15:02:04] <KotH> mru: no, it isnt comcast
[15:02:04] <brad0> oh. that's all?
[15:02:13] * KotH wonders why china is interested in /avi/invalid_unaligned.avi
[15:02:13] <brad0> I could do that.
[15:02:34] <mru> it would be a start
[15:02:53] <brad0> just gimme a few mins.
[15:03:00] <mru> there are some debug macros commented out at the top of vorbis_dec.c
[15:03:08] <mru> you can probably figure out what to do
[15:03:18] <brad0> k.
[15:03:32] * KotH wonders whether there should be a os/2 box in fate
[15:03:36] <mru> post the output to roundup
[15:03:44] <mru> if it's not too unbearably slow
[15:03:46] <kshishkov> I wonder if Vorbis uses some math func that other codecs don't
[15:03:51] <mru> KotH: ask the koreans
[15:04:08] <mru> kshishkov: the bitstream reading is failing
[15:04:19] <kshishkov> ouch!
[15:04:22] <mru> that shouldn't depend on any libm stuff
[15:04:22] <KotH> mru: i'd ask netlabs, if these guys werent so absorbed in self pitty
[15:04:41] <mru> what else would you expect from someone running os/2
[15:04:47] <mru> it's not like anyone else will pity them
[15:07:28] <kshishkov> mru: a feeling of absolute superiority, ask Theo
[15:07:44] <mru> kshishkov: that's bsd users, but let's not bash them right now
[15:08:12] <mru> bsd is a real os after all
[15:08:19] <mru> just a bit old
[15:08:26] <kshishkov> so is os/2
[15:08:43] <mru> yes, but it's missing the part about being real
[15:08:43] <brad0> mru: oh please. not like linux users don't act like that.
[15:08:59] <mru> brad0: I guess everybody does to some extent
[15:09:06] <kshishkov> indeed
[15:09:19] <mru> now we do want to support bsd
[15:09:20] <brad0> windows users act like they're hot shit. so do OS X users.
[15:09:43] <mru> where's that matrix of pictures "as seen by ..."
[15:09:48] <brad0> anyway. back to the bug.
[15:10:18] <lu_zero> right
[15:42:40] <lu_zero> parkjoy.ivf <- seek fails
[15:42:45] <lu_zero> expected?
[15:43:01] <mru> probably
[16:11:48] <lu_zero> interesting
[16:11:59] * lu_zero is trying vp8 in rtp
[16:12:46] <lu_zero> j0sh: I probably messed up with the feng parser but till a point works =)
[16:25:10] <j0sh> lu_zero: awake now :)
[16:25:14] <j0sh> cool
[16:26:02] <j0sh> and regarding your earlier comment about keeping buffering in rtsp
[16:26:38] <j0sh> yeah, i think that'd make the logic inside the depacketizer cleaner, like martin's patch splitting xiph frames
[16:26:57] <j0sh> but it's a big change
[16:29:00] <wbs> yeah, I'm for it, in principle, but I wouldn't give it particularly high priority, there are far more important things to fix
[16:29:50] <j0sh> aye
[16:30:01] <wbs> (and it's a bit messy ;P)
[16:33:47] <lu_zero> and I'm afraid it started like that for a reason
[16:34:31] <lu_zero> but I'm quite sure that there isn't a packetizer needing to go over the buffer or doing stuff that we cannot factor on the upper level
[16:34:34] <lu_zero> fun
[16:34:41] <lu_zero> feng workish
[16:34:57] <lu_zero> I wonder what's wrong
[16:36:10] <j0sh> lu_zero: are you testing with my depacketizer?
[16:41:59] <lu_zero> yes
[16:42:18] <lu_zero> it decodes a number of frames and then garbles it
[16:42:44] <wbs> then it probably dropped a frame
[16:42:47] <wbs> try running over tcp
[16:42:54] <lu_zero> That's making me thinking I'm doing it wrong "Received no start marker; dropping frame"
[16:42:59] <lu_zero> even on localhost?
[16:43:11] <wbs> i've seen udp packetloss even over loopback, yes
[16:43:20] <mru> heh, odd network glitch here.. everything but web works
[16:43:27] <lu_zero> meh...
[16:43:32] <wbs> if the application receiving the packets isn't blocked in recv() but is doing a sleep or something else
[16:43:34] <lu_zero> you are right...
[16:43:57] <wbs> if ffplay don't want any more packets at the moment, it just sleeps and doesn't block waiting for more packets, so it may well miss some udp packets
[16:49:29] <lu_zero> and that put us back to the last night discussion
[16:50:00] <lu_zero> that will lead us to look at the proto implementation and how to fix that
[16:51:52] * j0sh sees udp packetloss ove loopback *all the time*
[16:52:09] <mru> look, just now it dropped an 'r'
[16:52:30] <j0sh> yes! :)
[16:53:04] <j0sh> well, not so much loss as out-of-order packets
[16:53:20] <lu_zero> I'm pondering if would be worthy and accepted having another proto system for buffering and fix that stuff
[16:54:25] <lu_zero> (network thread to poll for data, internal queue to buffer it, rtp_proto serving out of it)
[16:55:14] <CIA-92> ffmpeg: mru * r24705 /trunk/configure: configure: remove redundant extralibs settings
[16:55:52] <janneg> wbs: yes, you're patches would break the loas demuxer
[16:57:47] <janneg> LATM should have its own demuxer which reuses most of the laos demuxer
[17:27:20] <j0sh> wbs: i can double the sdp line to 32kb, but i have yet to see a combined theora/vorbis sdp take more than ~14kb
[17:27:37] <wbs> janneg: okay... do you think there's any point in making it use a chained demuxer, or is it just simplest to write it straight away all in the depacketizer?
[17:27:44] <j0sh> i dont even know where the 16kb max number comes from
[17:27:56] <wbs> j0sh: I think 16kb is enough, we'll increase it if someone reports it isn't enough :-)
[17:28:05] <j0sh> alright
[17:29:14] <wbs> lu_zero: well, it's mostly up to the user appliation if it always tries to read more packets (which imo is the sensible thing to do for realtime streams) or block locally when you've queued "enough" (when reading non-realtime streams)
[17:30:08] <lu_zero> uhm
[17:34:12] <j0sh> wbs: this is making my head hurt, but
[17:34:15] <j0sh> int remaining = s->buf + 6 + max_pkt_size - (s->buf_ptr + 2 + size);
[17:34:32] <j0sh> won't that count the packet length twice (for the +2)
[17:34:47] <j0sh> in the case where the frame is the first of the packet
[17:35:05] <j0sh> since we already factor that in with the +6
[17:35:34] <j0sh> s/packet length/frame length
[17:37:06] <lu_zero> where is this line?
[17:37:48] <j0sh> lu_zero: my xiph patch, line ~162
[17:38:03] <j0sh> (martin's latest review)
[17:39:57] <janneg> wbs: I don't know. if the standalone code is considerable easier go for it. otherwise we should try to avoid code duplication. I can look at making it easier for oob config
[17:41:28] <janneg> and I'll probably need make changes for chain demuxing from mpeg-ts
[17:41:53] <lu_zero> I have +        int remaining = max_pkt_size - ((int)(s->buf_ptr - s->buf) + size);
[17:42:25] <twnqx>     Stream #0.0: Video: IV41 / 0x31345649, 316x180, 8 fps, 8 tbr, 8 tbn, 8 tbc <- ugh, *eight* fps?
[17:42:39] <twnqx> i somehow hope that there's a mistake...
[17:44:40] <kshishkov> nope
[17:45:02] <kshishkov> in those times 12-15 fps were the limit
[17:45:10] <j0sh> lu_zero: yeah, that's from an older patch, look at the one from last night (or this morning, rather)
[17:46:04] <j0sh> lu_zero: martin in his latest review suggested a more precise way
[17:47:13] <lu_zero> that what I have from today 10AM my time
[17:49:27] <j0sh> lu_zero: http://pastebin.org/449130
[17:52:50] <lu_zero> uh?
[17:52:53] <lu_zero> why that?
[17:53:01] <j0sh> that is what i had in my patch
[17:53:30] <lu_zero> I mean the extension header should not change
[17:53:49] <cartman> lo guys
[17:54:03] <cartman> is there a way to stream encrypted video somehow?
[17:54:08] <j0sh> the header is actually 4 + 2n
[17:54:42] <j0sh> where n is the number of frames in the rtp packet (need to prefix the frame length before the start of each data segment)
[17:56:24] <j0sh> but the data_size includes those extra headers from previous frames
[17:56:41] <j0sh> maybe im just thinking too hard
[17:56:50] <lu_zero> 2.2.  Payload Header
[17:56:55] <lu_zero> we are talking this?
[17:57:42] <j0sh> yes
[17:58:08] <lu_zero> ok
[17:58:12] <j0sh> 2.2 + the payload length part of 2.3
[17:58:44] <lu_zero> so you have 4 + 2n space used for nondata stuff
[17:58:51] <j0sh> right
[18:01:27] <lu_zero> wouldn't be better keep writing and once it is full move to another?
[18:02:54] <j0sh> yeah, if we have a non-fragmented packet that doesn't fit in the buffered data, we need to send the buffered data off
[18:12:57] <wbs> j0sh: no, I'm not counting the packet length twice
[18:13:11] <wbs> j0sh: first, do you agree that the end of the buffer we may write to is s->buf + 6 + max_pkt_size?
[18:13:19] <j0sh> correct
[18:13:46] <wbs> and from buf_ptr, we will write 2 bytes for the packet length, plus the actual data, right?
[18:14:01] <j0sh> well, 3 extra bytes actually (just realzied this)
[18:14:08] <wbs> no?
[18:14:13] <j0sh> we need to include the xdt/frag/num_frames byte
[18:14:36] <j0sh> plus 2 bytes for the packet length
[18:15:11] <wbs> the xdt/frag/num_bytes byte is before buf_ptr (normally at least)
[18:16:37] <wbs> for the first packet, you actually don't know where you left the buf_ptr the last time, you aren't doing it consistently
[18:16:43] <j0sh> if it's not the first frame in the rtp packet, yeah
[18:17:53] <j0sh> yeah hence the if (s->num_frames > 1) check
[18:19:24] <wbs> so, in that case, I think the most correct thing is to add an s->num_frames > 0 && to the if statement
[18:19:48] <wbs> and use the remaining calculation I sent in the review, since that's correct for num_frames > 0
[18:21:08] <j0sh> alright
[18:21:26] <wbs> the problem that I encountered was, at least, that the first check noticed that the packet should fit unfragmented, but this check figured it wouldn't fit and flushed the "old buffered data" which wasn't anything at all
[18:21:37] <wbs> which sent a spurious 3 byte packet that the receiver barfed on
[18:22:03] <wbs> btw, regarding the ogg/vorbis timestamp issues - to test stream copying, I transcoded the movies into mkv, that supply proper timestamps for all packets :-)
[18:22:06] <j0sh> i noticed a few of those during my initial testing awhile ago, but i changed some other things and it hadn't come up again
[18:22:32] <wbs> I've got a movie that triggered it at the same spot every time :-)
[18:22:50] <j0sh> fan the flames of the ogg container debate :)
[18:23:48] <j0sh> hi BBB
[18:23:53] <BBB> hi
[18:35:35] <wbs> janneg: yeah.. as for code duplication, the length parsing loop is not much code at all, the config parsing is slightly more but not much that either. I'll await progress on the latm demuxer in general for a while to see if you get it to work properly
[19:03:40] <brad0> ugh. trunk is broken. :(
[19:04:44] <wbs> brad0: it is?
[19:18:30] <brad0> Ya. an issue with the assembler code for VP5.
[19:20:08] <mru> be more specific
[19:24:49] <thresh> you know what could be worse than smoke everywhere? dealing with clueless coworkers.
[19:25:19] <mru> if there were smoke everyhwere, they'd at least be choking and unable to do any harm
[19:25:32] <thresh> office is ACed...
[19:26:05] <thresh> and now, in the evening when I'm home, smoke from fires starts to come to a town
[19:26:19] <thresh> yesterday it reminded us of Silent Hill.
[19:28:16] <thresh> you couldnt actually see a sun yesterday, sooo weird
[19:30:33] <kshishkov> да гори эта Москва синим пламенем!
[19:31:20] <thresh> kshishkov: that's the main problem
[19:31:27] <brad0> mru: when trying to compile vp5.c..  {standard input}:60: Error: `(%esi,%edx)' is not a valid 64 bit base/index expression
[19:31:28] <thresh> it doesnt :(
[19:31:38] <thresh> I wish it did, thou.
[19:31:51] <mru> compiler?
[19:31:56] <kshishkov> everybody in Russia secretly does
[19:32:02] <brad0> gcc 4.2.1
[19:33:45] <Dark_Shikari> "leal (%2, %3), %3 \n\t"
[19:33:47] <Dark_Shikari> it fails on that
[19:33:54] <Dark_Shikari> but I'm pretty bloody sure that's valid on 64-bit
[19:34:08] <mru> Dark_Shikari: he's on some bsd
[19:34:24] <Dark_Shikari> oh.
[19:34:24] <mru> bsd is still only 62-bit
[19:34:37] <Dark_Shikari> mru: depends which bsd
[19:34:40] <kshishkov> and, more important, on LLVM
[19:34:43] <Dark_Shikari> they have a 48, 57, 61, and 63 version
[19:35:12] <mru> fate reports no build errors on bsd
[19:35:21] <mru> brad0: which bsd are you using?
[19:35:36] <Dark_Shikari> mru: question about a Cortex
[19:35:40] <Dark_Shikari> Apple's A4 claims to have 64KB of cache
[19:35:41] <mru> hmm, that would be good name for a fork: WhichBSD
[19:35:42] <Dark_Shikari> for L1
[19:35:50] <Dark_Shikari> is this 32k instruction, 32k data, like Intel?
[19:35:51] <brad0> OpenBSD. but the issue isn't OS specific. AFAIK its an issue with binutils.
[19:35:53] <Dark_Shikari> Or is this shared cache?
[19:35:55] <Dark_Shikari> Or is this 64k/64k?
[19:35:58] <mru> separate
[19:36:02] <Dark_Shikari> ok, so it's 32k/32k?
[19:36:16] <mru> depends on the chip in theory
[19:36:22] <mru> afaik they all use 32k
[19:36:26] <Dark_Shikari> I'm further optimizing the FLV decoder, need to know how much of it I have left to make a big bloated VLC table
[19:36:39] <Dark_Shikari> Guess my chip has the same amount as the ARM, so benches on my i7 should be comparable.
[19:36:54] <brad0> anyway. this breakge is relatively recent.
[19:37:05] <brad0> that is the current snap we're using is from mid May.
[19:37:26] <mru> fate reports nothing not building on openbsd
[19:37:59] <Dark_Shikari> hmm.  wow, the FLV decoder has no prefetch, I should add some
[19:38:03] <brad0> do you even have an amd64 system in your build farm?
[19:38:10] <Dark_Shikari> btw, mru, what do you know about mem -> L2 and L2 -> L1 prefetch on ARM?
[19:38:17] <Dark_Shikari> particualarly L2->L1, does that even exist?
[19:38:34] <mru> there is only one prefect instruction
[19:38:39] <Dark_Shikari> I mean automatic
[19:38:41] <Dark_Shikari> not instruction-based
[19:38:47] <mru> no idea
[19:39:02] <Dark_Shikari> I thought this kind of stuff would be well-documented for the Cortex?
[19:39:03] <mru> A9 has something
[19:39:06] <Dark_Shikari> It's not like they're Intel or something
[19:39:11] <mru> don't know about A8
[19:39:15] <mru> I can try to find out
[19:39:28] <Dark_Shikari> L2->L1 prefetch seems to be the single least documented feature of modern CPUs
[19:39:35] <Dark_Shikari> yet it's rather important
[19:39:43] <mru> different A8 revisions behave differently there
[19:40:28] <Dark_Shikari> do you know anything about any particular revision?
[19:40:32] <Dark_Shikari> just to get an idea of how it works?
[19:41:01] <mru> on A8 r1pX L1 and L2 are mutually exclusive
[19:41:08] <mru> nothing can be in both at the same time
[19:41:25] <mru> r3 is rather different
[19:41:34] <mru> supposedly much better
[19:41:37] <Dark_Shikari> they switched from exclusive to inclusive caching?
[19:42:00] <mru> they changed the external memory interface too
[19:43:04] <mru> allegedly performs better with certain access patterns
[19:43:12] <mru> hopefully ones that people actually use
[19:43:19] <mru> and not just some stupid benchmark
[19:47:01] <CIA-92> ffmpeg: mru * r24706 /trunk/libavcodec/arm/ (h264idct_neon.S h264dsp_init_arm.c):
[19:47:01] <CIA-92> ffmpeg: ARM: NEON H264 8x8 IDCT
[19:47:01] <CIA-92> ffmpeg: Parts by David Conrad.
[19:47:24] <Dark_Shikari> finally
[19:47:38] <mru> I'd totally forgotten about it
[19:48:12] <mru> 8x8 doesn't seem to be used much though
[19:49:37] <Dark_Shikari> mru: well, you know, only 50% of the time in high profile streams
[19:49:39] <Dark_Shikari> =p
[19:49:46] <Dark_Shikari> (at least)
[19:50:02] <mru> I never saw it use much time
[19:50:51] <Dark_Shikari> it's h264, everything else is so slow that the idct is not going to use 40% of time
[20:02:29] <Dark_Shikari> oh wow, I'm stupid.
[20:07:48] <CIA-92> ffmpeg: darkshikari * r24707 /trunk/libavcodec/vp8.c:
[20:07:48] <CIA-92> ffmpeg: VP8: fix bug in prefetch
[20:07:48] <CIA-92> ffmpeg: Motion vectors in VP8 are qpel, not fullpel.
[20:57:37] <peloverde> new aacx screenshot: http://imgur.com/K0zaK
[21:01:39] <spaam> aacx?
[21:02:04] <peloverde> AAC eXaminer
[21:02:16] <spaam> ok :)
[21:02:20] <peloverde> AAC bitstream analyzer
[21:05:21] <Dark_Shikari> peloverde: sell it ;)
[21:05:48] <saintd3v> peloverde: cool :)
[21:06:16] <saintd3v> Dark_Shikari: lol, he could probably get $5k a pop, because it's
[21:06:23] <saintd3v> 'professional'
[21:06:56] <spaam> just add professional to  aacx .. they you can make even more $$$ from it ;)
[22:57:46] <Dark_Shikari> heh, I hacked up the FLV decoder a bit more
[22:57:50] <Dark_Shikari> another 10% faster residual decoding...
[22:57:57] <Dark_Shikari> using a table of size 32*4*(2^13) bytes
[22:58:05] <Dark_Shikari> [qscale][13-bit VLC]
[22:58:15] <Dark_Shikari> In other words, performance will suck on anything that doesn't use one quant per frame =p
[23:00:32] <lu_zero> which is often or next to impossible?
[23:06:15] <iive> Dark_Shikari: why not se [13-bit vlc][qscale] ?
[23:06:19] <iive> se/use
[23:06:37] <iive> j/k
[23:07:22] <Dark_Shikari> lol
[23:07:32] <Dark_Shikari> lu_zero: doesn't happen on ffmpeg-createde streams!
[23:07:46] <lu_zero> that's enough =P