[FFmpeg-devel-irc] IRC log for 2011-01-25

[irc at mansr.com]

[00:00:20] <mru> that's roughly the price I paid
[00:00:46] <Flameeyes> hm, I actually found it at _one_ place at €200 (inc. VAT) here in Italy, how that's interesting, somebody with honest prices, in Italy?
[00:01:05] <Flameeyes> almost all of my hardware purchases come from Germany
[00:05:53] <jannau> mru: have queued any of Flameeyes' patches?
[00:06:04] <mru> some, about to push
[00:06:19] <mru> there
[00:06:24] <jannau> ok, I haven't
[00:06:27] <CIA-43> ffmpeg: Diego Elio Pettenò <flameeyes at gmail.com> master * r53493f9a81 ffmpeg/libavcodec/ (atrac.c atrac.h):
[00:06:27] <CIA-43> ffmpeg: Mark qmf_window table static to atrac.c unit.
[00:06:27] <CIA-43> ffmpeg: The table is not used anywhere else on libavcodec.
[00:06:27] <CIA-43> ffmpeg: Signed-off-by: Mans Rullgard <mans at mansr.com>
[00:06:36] <CIA-43> ffmpeg: Diego Elio Pettenò <flameeyes at gmail.com> master * r3568853f63 ffmpeg/ (cmdutils.c cmdutils.h):
[00:06:36] <CIA-43> ffmpeg: Make this_year static to cmdutils.c
[00:06:36] <CIA-43> ffmpeg: Signed-off-by: Mans Rullgard <mans at mansr.com>
[00:06:38] <CIA-43> ffmpeg: Diego Elio Pettenò <flameeyes at gmail.com> master * r82e1f217f2 ffmpeg/libavcodec/ (atrac.c atrac.h atrac1.c atrac3.c):
[00:06:38] <CIA-43> ffmpeg: Rename sf_table in atrac.c unit to ff_atrac_sf_table.
[00:06:38] <CIA-43> ffmpeg: This ensures a locally-unique name as well as marks the symbol as
[00:06:38] <CIA-43> ffmpeg: FFmpeg-private at least by declaration.
[00:06:38] <CIA-43> ffmpeg: Signed-off-by: Mans Rullgard <mans at mansr.com>
[00:06:39] <CIA-43> ffmpeg: Diego Elio Pettenò <flameeyes at gmail.com> master * rbb875b75ba ffmpeg/libavcodec/utils.c:
[00:06:39] <CIA-43> ffmpeg: Make the ff_lockmgr_cb function pointer static to utils.c
[00:06:40] <CIA-43> ffmpeg: Signed-off-by: Mans Rullgard <mans at mansr.com>
[00:06:41] <CIA-43> ffmpeg: Diego Elio Pettenò <flameeyes at gmail.com> master * r1d4da6a460 ffmpeg/libavcodec/ (mpegvideo_common.h mpegvideo_enc.c):
[00:06:43] <CIA-43> ffmpeg: Make denoise_dct_c and dct_quantize_trellis_c static.
[00:06:43] <CIA-43> ffmpeg: Signed-off-by: Mans Rullgard <mans at mansr.com>
[00:06:43] <CIA-43> ffmpeg: Diego Elio Pettenò <flameeyes at gmail.com> master * rf0a8676958 ffmpeg/libavformat/ (dv.h dvenc.c):
[00:06:43] <CIA-43> ffmpeg: Make dvenc.c functions static to the unit.
[00:06:43] <CIA-43> ffmpeg: Also drop some CONFIG_DV_MUXER #ifdefs probably vestigial from before the
[00:11:36] <lu_zero> BBB: so if I understood correctly in asf
[00:12:05] <lu_zero> you never have more than one or fragments of asf packets
[00:12:13] <lu_zero> per rtp packets
[00:18:14] * Flameeyes is also taking a moment to cleanup his historical patches
[00:26:30] <mru> Flameeyes: I can push the good parts of the DEBUG patch if you want
[00:26:34] <mru> avidec needs more work
[00:27:12] <Flameeyes> uhm define "more work", but okay for me to at least merge part of it
[00:27:19] <mru> see mail
[00:27:33] <Flameeyes> hasn't arrived here, so I'll see when it does :)
[00:27:44] <Flameeyes> the dprintf changes I had laying around since ... july?
[00:27:46] <CIA-43> ffmpeg: Diego Elio 'Flameeyes' Pettenò <flameeyes at gmail.com> master * r73a0b19ba3 ffmpeg/ (libavcodec/gifdec.c libavformat/mxf.h):
[00:27:46] <CIA-43> ffmpeg: Don't check for DEBUG before using dprintf.
[00:27:46] <CIA-43> ffmpeg: The dprintf macro is no-op when DEBUG is unset, so there is no need to
[00:27:46] <CIA-43> ffmpeg: put it conditional to DEBUG.
[00:27:46] <CIA-43> ffmpeg: Signed-off-by: Mans Rullgard <mans at mansr.com>
[00:29:11] <Flameeyes> see the original as re-imported here: http://gitorious.org/~flameeyes/ffmpeg/flameeyes-ffmpeg-historical/commit/cb0d9c259d8fac7908ce960dbbe12a7a6d760671  — it was second in a row to remove dprintf() for the POSIX.1-2008 collision
[00:36:16] <mru> BBB, wbs: libavformat/rtsp.c:1039:9: warning: 'rtx' may be used uninitialized in this function
[00:36:19] <mru> that's a new warning
[00:47:43] <CIA-43> ffmpeg: Diego Elio Pettenò <flameeyes at gmail.com> master * r5b5083b5fe ffmpeg/libavcodec/pcm.c:
[00:47:44] <CIA-43> ffmpeg: Don't declare a pcm_dvd encoder.
[00:47:44] <CIA-43> ffmpeg: The PCM_DVD encoder would be left unused, as allcodecs.c properly declared
[00:47:44] <CIA-43> ffmpeg: it as being decoder-only, but it would still be built into the object file.
[00:47:44] <CIA-43> ffmpeg: Since there is no block of code to properly encode this PCM format, it's
[00:47:44] <CIA-43> ffmpeg: not a full codec.
[00:47:45] <CIA-43> ffmpeg: Signed-off-by: Mans Rullgard <mans at mansr.com>
[00:52:03] <Flameeyes> mru: you know anything of syncpoint search stuff?
[00:53:10] <mru> nope
[00:53:42] <lu_zero> mru: that line is a comment here
[00:54:41] <lu_zero> make_setup_request anyway...
[01:17:42] <Flameeyes> mru: uhm, are floating-point versions of functions always preferred?
[01:17:58] <mru> elaborate
[01:18:47] <Flameeyes> acelp has interpolate and interpolatef (floating point) functions
[01:18:50] <Flameeyes> but only the latter is used
[01:19:10] <mru> ask the voice codec guys what they were planning
[01:19:19] <Flameeyes> another acelp source file has decode_gain_code, which is never used, and sipr16k.c has a float version of that
[01:19:57] <Flameeyes> sipr16k also has an lp_decodef, while lp_decode (integer) is still used
[01:20:32] <Flameeyes> is there any voice guy here who can enlighten me before I spent too much time on acelp? :)
[01:21:19] <DonDiego> Flameeyes: try pinging reynaldo or superdump
[01:21:33] <Flameeyes> DonDiego: will do!
[01:22:37] <Flameeyes> reynaldo: can you help me figuring out the duplication of integer and floating point functions between acelp and sipr16k? tia!
[01:22:44] <DonDiego> ok, i'm off to bed, gnite
[01:23:43] <CIA-43> ffmpeg: Mans Rullgard <mans at mansr.com> master * raa61e39eac ffmpeg/libavcodec/mpegvideo_enc.c:
[01:23:43] <CIA-43> ffmpeg: Make denoise_dct_c() and dct_quantize_trellis_c() static in definitions
[01:23:43] <CIA-43> ffmpeg: 1d4da6a460d5b78026e3b854fdd6f469957a054c added static to the
[01:23:43] <CIA-43> ffmpeg: prototypes for these fuctions. Adding it to the definitions
[01:23:43] <CIA-43> ffmpeg: as well.
[01:23:44] <CIA-43> ffmpeg: Signed-off-by: Mans Rullgard <mans at mansr.com>
[01:38:35] <CIA-43> ffmpeg: Diego Elio Pettenò <flameeyes at gmail.com> master * r69ad22c7a7 ffmpeg/libavformat/rtpdec.c:
[01:38:36] <CIA-43> ffmpeg: Make ff_realmedia_mp3_dynamic_handler static.
[01:38:36] <CIA-43> ffmpeg: Signed-off-by: Mans Rullgard <mans at mansr.com>
[01:42:16] <Dark_Shikari> mru: oh wow, there was an overflow in 8x8
[01:42:33] <mru> lu_zero: that warning about rtx uninitialised is compiler mistake
[01:42:48] <mru> classic case of init in first loop iteration, use in subsequent
[01:43:03] <mru> compiler too stupid to notice
[01:43:07] <mru> Dark_Shikari: apparently so, yes
[01:44:04] <Dark_Shikari> wait, did you apply it?
[01:44:08] <Dark_Shikari> if not, why is fate green?
[01:44:13] <mru> I fixed it
[01:44:15] <Dark_Shikari> k
[01:44:26] <mru> with help from BBB
[01:44:27] <Dark_Shikari> We need more really fun test cases like that.
[01:45:24] <BBB> agreed
[01:45:58] <CIA-43> ffmpeg: Diego Elio Pettenò <flameeyes at gmail.com> master * r119cc033fc ffmpeg/libavformat/ (rtpdec.c rtpdec.h):
[01:45:58] <CIA-43> ffmpeg: Make RTPFirstDynamicPayloadHandler static to rtpdec.c
[01:45:58] <CIA-43> ffmpeg: Signed-off-by: Mans Rullgard <mans at mansr.com>
[01:46:18] <mru> Dark_Shikari: now I don't claim to understand how that asm works
[01:47:55] <Dark_Shikari> it works much the same as the neon, really
[01:48:03] <Dark_Shikari> though the init part (i.e. above the main loop) is imo a total mess
[01:48:07] <mru> it doesn't look anything the same
[01:48:13] <mru> main loop?
[01:48:13] <Dark_Shikari> The core loop's logic is the same
[01:48:19] <Dark_Shikari> i.e. the part that calculates the output pixels
[01:48:27] <Dark_Shikari> the part that calculates i00/a/b/c is messy
[01:48:50] <BBB> its fast :)
[01:49:26] <mru> it's the part with the scalar registers I don't get
[01:51:37] <Dark_Shikari> Yes, that's the init part
[01:51:43] <Dark_Shikari> i.e. calculations of parameters for the simd part
[01:52:42] <mru> I see a lot of simd there too
[01:54:11] <Dark_Shikari> Some of the init can be done in simd
[01:54:28] <Dark_Shikari> e.g. the top pixels are multiplied by 8, 7, 6, 5, 4...
[01:54:34] <Dark_Shikari> you load them in simd, do a multiply
[01:54:36] <Dark_Shikari> then you horizontal sum
[01:54:47] <Dark_Shikari> the left pixels can't, because you have to load them one at a time
[01:55:30] <mru> you can load them one at a time and then simd them
[01:56:02] <BBB> pextrb is sse4
[01:56:07] <BBB> I may in the future write that also
[01:56:15] <BBB> may be slightly faster...
[01:56:16] <Dark_Shikari> you mean pinsrb
[01:56:19] <mru> what does that do?
[01:56:20] <Dark_Shikari> mru: not any faster
[01:56:22] <Dark_Shikari> imo
[01:56:24] <mru> element load?
[01:56:25] <BBB> right
[01:56:39] <Dark_Shikari> mru: so there are two ways to do it:
[01:56:41] <BBB> load a byte from memory anywhere into the mm reigster
[01:56:48] <Dark_Shikari> 1) 16x load, 16x mul, 16x add (48 ops)
[01:56:58] <Dark_Shikari> 2) 16x load, 16x shuffle into place, 1 mul, a few horizontal adds
[01:57:09] <Dark_Shikari> 2) is probably not significantly faster than 1)
[01:57:17] <mru> neon is 16x load, 1 mul
[01:57:25] <Dark_Shikari> and the horizontal adds of course.
[01:57:28] <BBB> mru: the scalar is simple, if you do 4X[n1]+3x[n2]+...+-4x[n9], then I can lose a mul by doing (n0-n8)x4
[01:59:23] <Dark_Shikari> hey, it's michael!
[01:59:39] <michaelni> hi jason
[01:59:52] <michaelni> iam just here becazse i promissed arpi ;)
[01:59:58] <michaelni> to logon today
[02:00:11] <michaelni> well i should have 6 hours ago i guess
[02:00:14] <Dark_Shikari> this is unheard of, we should throw a party
[02:00:50] <michaelni> actually iam tired and have to go to bed soon :(
[02:01:00] <michaelni> and ill meet ramiro tomorrow, he is in vienna
[02:01:07] <Dark_Shikari> leave your irc on, then you won't miss anything.
[02:01:15] * Dark_Shikari pokes BBB and mru etc
[02:01:16] <michaelni> willdo
[02:01:41] <BBB> feeding baby :-p but reading, hi michael
[02:01:49] <michaelni> BBB, btw, iam sorry for mentining your name with that email
[02:02:40] <michaelni> hi BBB, out of order msg & greeting ;)
[02:02:45] <BBB> it's ok, the email is fine otherwise so i guess it makes no difference
[02:03:29] <Flameeyes> hi michaelni
[02:03:32] <BBB> assuming it is the one i think it is
[02:03:39] <michaelni> hi Flameeyes
[02:04:01] <michaelni> BBB i dunno, it looked ambigouse
[02:04:08] <michaelni> but iam not a native
[02:04:31] <Flameeyes> I think I'm done with the patchball for tonight ^^;; the interface should be slightly easier to deal with this way
[02:04:33] <michaelni> a few paragraphs of new world propaganda and the offer for payment intermixed
[02:04:40] <Dark_Shikari> By the way, michaelni, not sure if you know, but "iam" is two words =p
[02:04:56] <michaelni> icnatspell
[02:05:07] <Dark_Shikari> is spacing spelling?
[02:05:17] <michaelni> who knows
[02:07:34] <Flameeyes> uhm the _decoder and _encoder objects should never be accessed directly, right?
[02:07:41] <mru> no
[02:07:49] <mru> they should have ff_
[02:08:17] <michaelni> hi mru
[02:08:30] <Flameeyes> mru: so let's say we change the macros to use ff_ prefix... adding a local: ff_*_encoder; ff_*_decoder; in the version script would be okay in that case?
[02:08:45] <mru> Flameeyes: I suppose so
[02:08:52] <mru> I don't know exactly how version scripts work
[02:08:56] <mru> what takes precedence?
[02:09:03] <mru> hi michaelni
[02:09:12] <Flameeyes> mru: should be first-match-rules
[02:09:17] <Flameeyes> but I'll doublecheck that now
[02:18:44] <Kovensky> a michaelni :O
[02:19:36] <Flameeyes> grrr there are three symbols that clashes with my idea of restricted mask =_=
[02:20:10] <mru> which ones?
[02:20:19] <Flameeyes> actually af few more
[02:20:32] <Flameeyes> T ff_init_range_decoder
[02:20:32] <Flameeyes> T ff_vp56_init_range_decoder
[02:20:32] <Flameeyes> T ff_init_cabac_decoder
[02:20:32] <Flameeyes> T ff_init_range_encoder
[02:20:36] <Flameeyes> these four here
[02:21:13] <mru> those should all be private too
[02:21:39] <michaelni> Kovensky, hi, ive a lookup failure in my brian with your nick who are you ? :)
[02:21:57] <Kovensky> just an observer :)
[02:22:12] <michaelni> mosad?
[02:22:25] <michaelni> or kgb?
[02:22:38] <Flameeyes> mru: then I should be able to go with this as an experimental approach
[02:22:41] <Kovensky> nah, neither
[02:22:48] <Kovensky> they don't allow anime in their workplaces do they
[02:23:50] * Kovensky made some mplayer builds for windows but stalled for almost a year on them and should resume building sometime soon
[02:24:10] <lu_zero> hi
[02:25:34] <Flameeyes> flame at yamato yamato % nm -D --defined-only /usr/lib/libavcodec.so | wc -l → 1519
[02:25:34] <Flameeyes> flame at yamato yamato % nm -D --defined-only libavcodec/libavcodec.so | wc -l → 1214
[02:25:34] <Flameeyes> not bad I'd say
[02:26:46] <lu_zero> nice indeed
[02:34:46] <lu_zero> good night michael, say hi to ramiro from me as well
[02:34:49] * lu_zero heads to bed
[02:35:06] <Dark_Shikari> michaelni: you can lurk #x264dev now too~
[02:35:57] * michaelni goes to kitchen eating a bit and then bed no more lurking
[02:36:20] <michaelni> good night everyone
[02:36:26] <BBB> goodnight
[02:36:45] <Flameeyes> bye BBB
[02:36:45] <BBB> baby is gone now
[02:36:50] <BBB> no that was to michael
[02:36:51] <Dark_Shikari> night michael
[02:36:54] <BBB> I'm not sleepy yet
[02:36:57] <Flameeyes> mru: ff_find_hwaccel is also internal, right?
[02:36:59] <Dark_Shikari> it's like 3 AM there
[02:37:21] <BBB> Dark_Shikari: mru is right that loading using pinsrb and then using pmullw might work for sse4
[02:37:27] <BBB> Dark_Shikari: I'll try that sometime next week or so
[02:37:32] <Dark_Shikari> BBB: pinsrb, ugh
[02:37:33] <BBB> even if it's only 5% faster, that's not bad
[02:37:40] <Dark_Shikari> iirc, pinsrb is as slow as movd+punpck
[02:37:44] <Flameeyes> Dark_Shikari: yeah and it's 3.30 here :P
[02:37:45] <mru> BBB: I used that approach for neon
[02:37:48] <BBB> haha, you said the same thing when I used it in vp8dsp
[02:38:03] <BBB> Dark_Shikari: it was _slightly_ faster for a few uses, in others it made no difference
[02:38:04] <mru> Flameeyes: where is it used?
[02:38:08] <BBB> if it's faster, why not use it? :)
[02:38:25] <Flameeyes> mru: mpeg12 h264 h263dec vc1dec
[02:38:30] <Flameeyes> declared in internal.h
[02:38:39] <mru> sounds pretty internal to me
[02:39:11] <Flameeyes> good, then we can go down to fewer than 1200 symbols in libavcoded with relatively small changes
[02:44:23] <CIA-43> ffmpeg: Mans Rullgard <mans at mansr.com> master * r6081f8c4e2 ffmpeg/libavformat/avidec.c:
[02:44:23] <CIA-43> ffmpeg: avidec: make print_tag() a macro and remove related ifdefs
[02:44:23] <CIA-43> ffmpeg: The dprintf macro is a no-op if DEBUG is not defined, so there
[02:44:23] <CIA-43> ffmpeg: is no need to guard it here.
[02:44:23] <CIA-43> ffmpeg: Signed-off-by: Mans Rullgard <mans at mansr.com>
[02:45:11] <Flameeyes> fwiw http://paste.pocoo.org/show/326396/ these are the symbols not prefixed with av exported by libavcodec
[02:45:53] <Flameeyes> I *think* we could start by hiding symbols that are internal to a given codec, so hide for instance ff_eac3_*
[02:46:15] <mru> which non-av* symbols are used outside lavc?
[02:46:22] <mru> that wasn't so many iirc
[02:46:26] <mru> so let's fix those instead
[02:47:10] <Flameeyes> well, it's a matter of renaming url_* and *_format, first of all
[02:47:17] <mru> those are in lavf
[02:47:18] <Flameeyes> and *_license
[02:47:25] <Flameeyes> ah you mean for codec itself, hmm
[02:48:07] <Flameeyes> the only user of ff_* functions from libavcodec is... libavformat
[02:49:50] <mru> you posted a list a while ago
[02:49:53] <mru> it looked rather short
[02:50:08] <mru> this one: http://paste.pocoo.org/show/326089/
[02:50:24] <Flameeyes> yep
[02:50:57] <Flameeyes> http://paste.pocoo.org/show/326402/ → this limits itself to libavformat's uses of libavcodec's ff_* functions
[02:51:35] <mru> does it use anything that's neither av* nor ff_*?
[02:51:47] <Flameeyes> i.e. elfgrep -DV -e '_.*@LIBAVCODEC' libavformat/libavformat.so
[02:51:49] <Flameeyes> sec
[02:53:14] <Flameeyes> nope
[02:53:27] <Flameeyes> at least libavformat that is
[02:56:07] <mru> hmm, that ff_toupper4 is funny
[02:57:07] <mru> it's obviously only intended for ascii
[02:58:01] <Flameeyes> also, http://paste.pocoo.org/show/326407/ these are all the non-prefixed interlib deps
[02:59:21] <mru> it can be simplified to (x & ~((x & 0x40404040) >> 1))
[03:00:43] <mru> all letters have bit 0x40 set, and uppercase have bit 0x20 clear
[03:01:43] <mru> the part that someone should have objected over is #include "libavcodec/internal.h" in libavformat/utils.c
[03:02:02] <mru> err, I can't read
[03:02:17] <mru> too many files with same name
[03:02:38] <mru> actually, I can read
[03:02:41] <mru> it is there
[03:16:54] <Flameeyes> heh the .dynstr table for libavcodec is about 32K.. I killed 6K just by hiding those symbols before
[05:14:08] <saintdev> nice article on groklaw about the GPL
[05:22:24] <Dark_Shikari> BBB: YOU ARE INSANE
[05:22:27] <Dark_Shikari> YOUR CODE IS NUTS
[05:22:41] <BBB> I know :-p
[05:22:44] <BBB> I'm sorry
[05:22:53] <saintdev> lol
[05:22:54] <BBB> I wasn't intending to apply as-is
[05:24:12] <BBB> shall I have loren review it?
[05:25:06] <BBB> we should put that on the quotes page
[05:25:13] <BBB> that was awesome
[05:26:08] <Dark_Shikari> you haven't been paying enough attention to my quotes =p
[05:26:43] <BBB> this one was definitely quoteworthy
[05:27:32] <Dark_Shikari> So yeah, I heard you like computed jumps now~
[05:29:42] <BBB> hehehe :)
[05:29:58] <BBB> dude, it's amazingly fast now
[05:30:10] <BBB> I was hoping to get close to 200 cycles, it's around 180 now
[05:30:14] <BBB> that's insanely fast
[05:30:53] <Dark_Shikari> It'd be faster if it only had to extend the edges
[05:30:57] <Dark_Shikari> and didn't have to copy the other parts
[05:31:05] <Dark_Shikari> i.e. if it wrote back to the main frame
[05:31:12] <Dark_Shikari> (wouldn't work with emulated edge mc though)
[05:31:58] <BBB> yeah, that doesn't work
[05:32:19] <Dark_Shikari> It does work, it would be faster for the non-emulated-edge case.
[05:32:22] <BBB> that'd be nice to try though
[05:32:37] <BBB> I know it would work, I mean right now that's not how it works
[05:33:20] <BBB> I may look into that in the future
[05:33:29] <BBB> but want to do vp8 multithreading and ffmpeg-mt integration also
[05:33:39] <BBB> xvp8 something something will soon start as well
[05:33:47] <BBB> dude, I'm gonna be a vp8 junkie
[05:34:25] <Dark_Shikari> lol
[05:34:47] <Dark_Shikari> *sings* "I'm gonna bet my liiiiife on a shiiiiiiity coooodecccc...."
[05:34:56] * saintdev sees BBB on the street corner searching for his next vp8 fix
[05:34:57] <BBB> hehehe :)
[05:35:22] <BBB> Dark_Shikari: at least it pays for my kids college education, then it's ok
[05:37:20] <pross-au> what! is somebody whoring themself for vp8?
[05:42:23] <BBB> oops, I'm caught
[05:42:25] <BBB> anyway
[05:42:27] <BBB> gotta sleep now
[05:42:34] <BBB> Dark_Shikari: please review my patch online
[05:42:49] <BBB> Dark_Shikari: other points: alignment to non-power-of-two-values (e.g. 48), is that ok?
[05:42:58] <BBB> I think 48 would work
[05:43:07] <BBB> it's a multiple of 16, should work
[05:43:11] <saintdev> BBB: just stay away from the minneapolis airport men's bathroom...
[05:43:35] <BBB> I shall remember that
[05:44:16] <Dark_Shikari> BBB: no, each one is not guaranteed to be in a single cacheline then
[05:44:41] <Dark_Shikari> ... then again ... the linker usually can't align to any more than 16.
[05:44:56] <Dark_Shikari> so it probably doesn't matter.
[05:45:17] <Dark_Shikari> and instruction prefetch likely happens ahead regardless
[05:51:49] * elenril wakes up and sees 100 new mails
[05:52:10] <elenril> and wtf, michael here?
[05:52:30] <Dark_Shikari> Yeah, the world turned upside down
[06:04:23] <thresh> moroning
[06:07:34] <astrange> if there's any more commit emails i'll have to set up list->folder filters
[06:08:09] <Dark_Shikari> you don't already have filters ?
[06:09:20] <astrange> my approach of starting at the top and hitting space 500 times really fast works very well
[06:23:17] <_av500_> yawn
[06:25:08] <siretart> buna diminaca
[07:53:11] <KotH> salut
[07:53:51] <spaam> god morgon
[07:54:55] <elenril> morning, glorious BofH
[07:55:10] <spaam> awww
[07:55:19] <spaam> KotH: he likes you
[07:56:06] <KotH> moin elenril
[07:56:24] <KotH> spaam: at least, he is not as perverted as you are
[07:56:46] <spaam> im not
[08:23:44] <bcoudu> elenril, btw it's very inefficient to always write utf16le with id3 v2.3
[08:24:01] <bcoudu> you'd better fallback on ascii when you can
[08:32:48] <elenril> i guess
[08:39:34] <cartman> moin
[08:40:51] <kshishkov> grüß dich
[08:41:10] <pJok> god morgon
[08:41:16] <andoma> hej
[08:44:39] <superdump> morning
[08:46:59] <kshishkov> ska vi göra någonting med WMAL?
[08:47:18] <kshishkov> eller WVP2?
[08:47:59] <kshishkov> eller RALF?
[08:50:22] <pross-au> roundup.ffmpeg.org down
[08:53:43] <kshishkov> it's called rounddown for a reason, mate
[08:54:19] <kshishkov> but no worries, I can check Bink-b decoder status directly from you
[08:57:01] <pross-au> status: active
[08:57:10] <kshishkov> yay!
[08:57:45] <kshishkov> have you seen http://codecs.multimedia.cx/?p=306#comments ?
[08:57:56] <pross-au> nup
[08:58:01] <pross-au> one sec mate
[08:58:36] <pross-au> Ta
[09:00:17] <pross-au> Strewth!!
[09:10:55] <bcoudu> elenril, also IMHO muxer should write 2.3 by default which is supported by more devices/oses
[09:15:10] <KotH> boys, if i'd be looking for a person/movement detection system using a camera based system, what words should i use to google for algorithms?
[09:15:32] <kshishkov> goldfish
[09:15:47] <kshishkov> and motion estimation
[09:16:00] <spaam> pross-au: will we see that decoder end of this week? :)
[09:16:25] <av500> KotH: encode and check size of P frames
[09:16:30] <peloverde> http://scholar.google.com/scholar?q=goldfish+motion+estimation
[09:18:38] <av500> KotH: http://www.codeproject.com/KB/audio-video/Motion_Detection.aspx
[09:20:51] <cartman> nice
[09:22:20] <KotH> peloverde, av500: domo arigatou!
[09:23:04] <kshishkov> KotH: I hope you don't ask how to encode video next time - it's FFmpeg channel after all
[09:25:28] <av500> ...._SVF.mxf: could not open codecs
[09:25:36] <av500> who is doing mxf?
[09:25:43] <kshishkov> Tjoppen
[09:25:46] <cartman> av500: bcoudu
[09:26:43] <av500> nice how you agree :)
[09:26:55] <av500> cartman: whats the code doing¿
[09:27:35] <KotH> kshishkov: no, i wont ;)
[09:27:47] <bcoudu> well it's more about who is friend with who ...
[09:28:49] <Tjoppen> av500: what codec? the demuxer only seems to support a limited set atm
[09:29:00] <cartman> av500: resting
[09:29:03] <av500> Tjoppen: I have no idea
[09:29:15] <cartman> av500: re-encode as avi
[09:29:46] <Tjoppen> try to get the codec UL
[09:29:57] <elenril> bcoudu: i disagree, i think we should push for the 2.4 standard
[09:30:13] <elenril> and only write the obsolete one when it's really required
[09:30:28] <av500> Tjoppen: the avi says: [scale @ 0x8c16d80] w:1998 h:1080 fmt:bgr24 -> w:1998 h:1080 fmt:yuv420p flags:0x4
[09:30:41] <bcoudu> why do you want to create files that cannot be read on windows ?
[09:30:45] <elenril> YES!
[09:30:47] <elenril> :)
[09:30:53] <bcoudu> this is stupid
[09:30:57] <elenril> well "windows"
[09:31:02] <elenril> most audio players can read them
[09:31:22] <bcoudu> windows does not read them, and the user reported the issue for a reason
[09:31:35] <av500> Tjoppen: ffprobe says this on the mxf: Stream #0.0: Video: [0][0][0][0] / 0x0000, 1998x1080, 24 fps, 24 tbr, 24 tbn, 24 tbc
[09:31:36] <Tjoppen> av500: weren't you just using mxf?
[09:31:44] <elenril> from what i heard, windows media player can read 2.4
[09:31:49] <av500> Tjoppen: I vcodec copied to avi
[09:31:49] <Tjoppen> you're trying to remux rawvideo from avi to mxf?
[09:31:50] <elenril> only windows explorer can't
[09:31:56] <Tjoppen> ah
[09:31:59] <av500> Tjoppen: I have a mxf
[09:32:02] <av500> that does not play
[09:32:07] <av500> i can play the audio mxf
[09:32:10] <av500> but not the video one
[09:32:21] <Tjoppen> do you have any idea what codec it's supposed to be?
[09:32:33] <bcoudu> wikipidia disagrees
[09:32:44] <bcoudu> not that wikipedia is a reliable source
[09:33:33] <bcoudu> av500, -vcodec copy -f rawvideo, that should extract the essence
[09:33:52] <lu_zero> uhm
[09:34:25] <elenril> bcoudu: therefore i don't think we should push an obsolete standard just because _one_ _file browser_ (not player) can't read them
[09:34:55] <bcoudu> you didn't understand me
[09:35:01] <bcoudu> windows media player does not support it
[09:35:05] <saintdev> i didn't know that av500 had the same syntax as ffmpeg
[09:35:13] <elenril> it doesn't?
[09:35:23] <elenril> i did in my tests
[09:35:27] <bcoudu> wikipedia says win7 doesn't
[09:35:33] <bcoudu> nor win media player
[09:35:35] <elenril> (which admittedly i didn't do myself, but....)
[09:35:48] <elenril> i wouldn't trust wikipedia on that matter
[09:36:12] <av500> elenril: url to your test file?
[09:36:18] <bcoudu> I wouldn't either but there is a reference in the article
[09:36:48] <elenril> ftp://ftp.khirnov.net/in.mp3 id3v2.4
[09:36:53] <elenril> ftp://ftp.khirnov.net/out.mp3 id3v2.3
[09:37:20] * av500 waits for worlds slowest win7 tablet to boot
[09:37:25] <elenril> ok, i'll do some more testing and think about it when i have more free time
[09:38:36] <kshishkov> av500: you've made that one too?
[09:38:52] <av500> kshishkov: not really
[09:39:00] <av500> I did nothing for it :)
[09:39:04] <GillesM> hi
[09:41:10] <GillesM> I have a strange problem on h264 with h->cabac.bytestream > h->cabac.bytestream_end + 2  ... when I read a dvb stream but it If I do a cat /dev/dvb/adapter0/dvr0 > file ... i don't have any problem readin file .. idea ?
[09:41:27] <kshishkov> av500: yes, I doubt you'd willingly work on that
[09:41:36] <bcoudu> even id3.org mention that v2.3 is the most popular format
[09:41:43] <bcoudu> ...
[09:42:31] <elenril> so?
[09:42:35] <elenril> avi is popular too
[09:42:39] <bcoudu> id3 is the reference, dude
[09:43:02] <elenril> that doesn't mean we should make it the default
[09:43:22] <bcoudu> default should be the most popular one
[09:43:44] <cartman> elenril: being compatible > being hip
[09:43:54] <bcoudu> this applies to codec settings as well
[09:44:02] <elenril> if that were true, new formats would never spread
[09:44:12] <merbzt> we should write the most common one as default if it can contain all the "info" the is supplied
[09:44:15] <cartman> elenril: they still encode pr0n with XVID
[09:44:15] <cartman> :P
[09:44:45] <bcoudu> not only porn but tv shows and movies
[09:44:54] <elenril> which is completely braindead
[09:44:59] <kshishkov> bcoudu: not in CHina
[09:45:04] <cartman> which is compatible :)
[09:45:24] <elenril> anyways, i'm not entirely convinced one broken player is a reason enough to switch, but i'll consider it
[09:45:43] <elenril> anyone else has an opinion on this?
[09:46:12] <av500> elenril: the 2.4 one is broken for the chinese tag
[09:46:22] <elenril> :/
[09:46:28] <elenril> file a bugreport to m$ =p
[09:46:32] <bcoudu> kshishkov, what about china ? scene releases are worldwide
[09:47:13] <bcoudu> Tjoppen, the clip wrapping patch is messy, don't you have an op1b patch that is cleaner ?
[09:47:16] <av500> elenril: I am for using the format that most players can understand
[09:47:50] <bcoudu> I agree with av500
[09:48:21] * elenril doesn't like the idea of having to write -id3v2_version 4 every time he converts something
[09:48:22] <GillesM> no idea about my h264 problem ?
[09:48:55] <bcoudu> you don't have to, everything supports v2.3 ;)
[09:48:57] <elenril> oh well, the majority is against me
[09:49:12] <j0sh> does the destination for swscale have to be aligned?
[09:49:17] <elenril> bcoudu: it's deprecated, obsolete and evil ;)
[09:49:30] <av500> nonsense
[09:49:36] <bcoudu> I agree v2.4 is superior because of utf8
[09:49:38] <elenril> (also we don't properly handle TDAT/TYER tags yet)
[09:49:43] <kshishkov> j0sh: yes
[09:50:07] <j0sh> hmmm alright
[09:50:27] <bcoudu> but you can mitigate by using ascii instead of utf16le
[09:50:29] <elenril> 2.4 is superiour because of other things too -- like a tag for full date
[09:50:41] <bcoudu> well only mov supports full date
[09:50:51] <elenril> ?
[09:50:51] <bcoudu> asf/mp3 only supports year
[09:51:04] <bcoudu> v2.3 I mean
[09:51:06] <roxfan> i _think_ wmp/win7 might not like utf-8 (i.e. it wants utf-16), rather than just v2.4
[09:51:16] <bcoudu> and itunes only show year anyway ;)
[09:51:25] <elenril> no, 2.3 supports full date too
[09:51:30] <elenril> but it splits in 3 tags
[09:51:35] <elenril> *splits it
[09:51:45] <elenril> TYER/TDAT/TIME
[09:51:52] <bcoudu> itunes write only year in TDRC here
[09:52:02] <elenril> your itunes is broken then ;)
[09:52:20] <roxfan> i.e. if you write v2.4 with utf-16 it should be able to read it
[09:52:31] <bcoudu> it's just a shortcut, because nobody care about the day and the month
[09:53:10] <elenril> that should be for the user to decide, not the format
[09:53:20] <bcoudu> lol
[09:53:21] <av500> but then I cant make a playlist with all music release april 1st....
[09:53:26] <av500> +d
[09:53:35] <bcoudu> users don't care they want stuff to work
[09:54:00] <elenril> users sometime care about the weirdest things
[09:54:16] <av500> elenril: we put these on hold...
[09:54:28] <bcoudu> certainly not day and month, otherwise itunes would display it
[09:55:00] <elenril> itunes automatically does what each user wants? ;)
[09:55:19] <elenril> most of the users certainly don't care
[09:55:40] <elenril> but that doesn't mean everybody
[09:56:04] <bcoudu> the point is to make the default the most popular but allow others to be able to do what they want
[09:56:41] <elenril> oh well, ok, but the date tags must be fixed first
[09:57:26] <av500> elenril: http://www.flickr.com/photos/av500/5387240974/
[09:57:43] * elenril kicks microsoft
[09:57:59] <av500> microsoft shrugs
[09:58:09] <superdump> hello michaelni
[09:58:17] <elenril> i knew i shouldn't have touched the utf-16 support =p
[09:59:09] <Dark_Shikari> michael should be awake by now
[09:59:17] <kshishkov> av500: ahem, do you know his tastes or just guessing?
[09:59:42] <saintdev> he's probably not paying attention, like loren
[09:59:42] <kshishkov> Dark_Shikari: I doubt you know his timetable
[09:59:48] <superdump> if anyone knows ogg, it seems some of reimar's ogg patches have sat for a few days without any motion on them
[09:59:48] <Dark_Shikari> he went to sleep like 7 hours ago
[10:00:09] <superdump> was there a party last night?
[10:00:34] <cartman> whoa michaelni is here ;)
[10:00:36] <bcoudu> I'm out, good night or good day
[10:01:47] <lu_zero> roundup back online
[10:02:07] <lu_zero> yesterday mess with networking upsetted nfs as well...
[10:02:43] <kshishkov>  /me is not surprised
[10:16:12] <Kovensky> 06:54.29 bcoudu: certainly not day and month, otherwise itunes would display it <-- ofc users want it
[10:16:15] <Kovensky> I for one want it =p
[10:16:26] <Kovensky> I have to use the "sort album" tag to disambiguate albums released in the same year <_<
[10:16:43] <av500> sort by what?
[10:16:54] <Kovensky> sort by album artist + year
[10:17:05] <av500> and how else would you sort?
[10:17:10] <Kovensky> well, album artist + date
[10:17:30] <Kovensky> I dunno
[10:17:41] <Kovensky> the problem is that itunes does it as album artist + date + album title
[10:18:11] <Kovensky> for example, asian kung-fu generation has 3 albums released in 2008; it falls back to sorting by album title and gets the order wrong
[10:18:31] <av500> omg
[10:19:01] <Dark_Shikari> Things get more fun when you have doujin albums.
[10:19:04] <Dark_Shikari> where album artist == circle
[10:19:08] <Dark_Shikari> and artist == composer
[10:19:11] <Kovensky> Dark_Shikari: no, itunes supports that properly
[10:19:15] <Dark_Shikari> and worse...
[10:19:18] <Dark_Shikari> when artist == vocalist
[10:19:19] <Dark_Shikari> not composer
[10:19:23] <Kovensky> unlike every other player other than foobar2000 I've used ever
[10:19:30] <Dark_Shikari> foobar <3
[10:19:39] <av500> http://www.thedoghousediaries.com/?p=2502
[10:19:55] <Kovensky> Dark_Shikari: it gets fun with alstroemeria records tho
[10:20:03] <Kovensky> Dark_Shikari: which often released 2, 3 albums per comiket
[10:20:20] <Dark_Shikari> <insert comment about how quantity != quality here>
[10:20:39] <av500> Dark_Shikari: I did already :)
[10:21:20] <superdump> and in general, if someone has time, since the change, we need to check that patches aren't falling into the void
[10:22:13] <Kovensky> 06:56.06 bcoudu: the point is to make the default the most popular but allow others to be able to do what they want <-- it's lacking the latter part then, since the year field only allows 4 digits (what about the year 10000?!?!) and there are no fields where you can put a more detailed date
[10:22:28] <Kovensky> I also had some files with ISO 8601 dates that itunes completely failed to read and had to get the year retagged
[10:24:45] <Kovensky> itunes does prefer to sort by "release date" instead of "date", but it doesn't allow you to add / modify release date and it fetches that information from the itunes store according to internet folklore; it's also apparently not stored in tags, only in the database
[10:24:56] <Dark_Shikari> and it doesn't look at vgdb
[10:24:59] <Dark_Shikari> er, vgmdb
[10:29:56] <elenril> Kovensky: there are no fields where you can put a more detailed date << read the specs plz
[10:30:15] <elenril> i already said id3v2.3 has the extra fields
[10:30:38] <elenril> the question is whether anyone supports them
[10:31:26] <elenril> and while we're at it, lolitunes, get a real player =p
[10:31:43] <kshishkov> elenril: buffering?
[10:32:03] <Kovensky> 07:31.47 elenril: Kovensky: there are no fields where you can put a more detailed date << read the specs plz <-- I said in the user interface
[10:33:06] <elenril> Kovensky: one more reason to get a real player
[10:33:11] <elenril> kshishkov: note the space
[10:33:28] <av500> http://www.real.com/realplayer/android
[10:33:29] <Kovensky> http://puu.sh/N0L
[10:33:42] <Kovensky> there are a few more options under Options but they're flags only
[10:34:26] <benoit-> The future of multimedia... iTunes + wikipedia... Yay!
[10:34:28] <elenril> looks stolen from amarok
[10:38:30] <elenril> Kovensky: what does it say about ftp://ftp.khirnov.net/test.mp3
[10:38:33] <Kovensky> anyway elenril, find me a real player then; one that works under osx, properly supports the album artist and artist separation and supports full dates
[10:38:36] <kshishkov> elenril: are you implying that absolute value of iTunes is bigger than its real part?
[10:42:45] <elenril> Kovensky: mpd obviously
[10:43:25] <Kovensky> elenril: now get me a client that doesn't look terrible, doesn't need x11.app to run and doesn't require me to code it myself
[10:44:02] <j-b> Kovensky: Amarok ?
[10:44:17] <elenril> mine should run anywhere where qt4 runs
[10:44:20] <Kovensky> j-b: fails the first requirement =p
[10:44:27] <thresh> amarok++
[10:44:33] <j-b> Kovensky: arf, :D
[10:44:39] <Kovensky> it also doesn't have album artist / artist separation
[10:48:43] <Kovensky> 07:38.31 elenril: Kovensky: what does it say about ftp://ftp.khirnov.net/test.mp3 <-- it reads the year (2006)
[10:53:41] <av500> hexdump reads 15:30
[11:27:26] <elenril> Kovensky: what does itunes do with TDRC tags in id3v2.4?
[11:27:35] <Kovensky> TDRC?
[11:27:41] <elenril> release date
[11:28:25] <elenril> it's a replacement for TYER i 2.4
[11:29:05] <Kovensky> well, itunes does have a column named "release date" that has an ISO-8601 date (but that's probably because I edited my short date format to ISO-8601), but it doesn't seem you can edit that
[11:29:43] <av500> needs sjobs approval to edit that
[11:32:23] <elenril> does qt4 run on apple btw?
[11:32:29] <Kovensky> yes
[11:32:37] <Kovensky> I heard the cocoa port is terrible though, but idk about 4.7
[11:35:11] * elenril wonders if pyside got usable yet
[11:35:21] <lu_zero> elenril: which one?
[11:35:49] <elenril> EAMBIGUOUSQUESTION
[11:43:49] * kshishkov reads http://techcrunch.com/2011/01/25/google-to-acquire-fflick-for-10-million/ and wonders why we don't have trademarked FF- prefix yet
[11:46:01] <spaam> Kovensky: do you use fflick everyday?
[11:46:06] <BBB> shit, my ffmpeg-log is gone
[11:46:07] <spaam> kshishkov..
[11:46:17] <BBB> Dark_Shikari: any comments on patch? my backlog is gone
[11:46:44] <kshishkov> spaam: nope, I've seen that name for the first time and it was a bit familiar
[11:46:53] <kshishkov> spaam: only two first letters though
[11:47:40] <spaam> maybe google going to buy FFmpeg also
[11:48:23] <Dark_Shikari> BBB: ?  which comments, besides ITS CRAZY
[11:48:39] <BBB> I was hoping you'd have suggestions on how to make it less CRAZY
[11:49:01] <BBB> also, did I mention it's fast? :-p
[11:49:13] * elenril would never sell his precious metadata to http://tvtropes.org/pmwiki/pmwiki.php/Main/PeaceAndLoveIncorporated
[11:49:40] <kshishkov> BBB: no, it was just a bit faster than you'd expected
[11:50:06] <kshishkov> elenril: do you think they won't pay you much for it?
[11:50:51] <cartman> elenril: let me know if you use pyside, I wonder if its usable too :P
[12:05:03] <lu_zero> Dark_Shikari, BBB: what's crazy and fast?
[12:06:19] <av500> lu_zero: h264 asm code
[12:06:39] <elenril> to are we faster than coreavc yet?
[12:06:57] <kshishkov> elenril: don't forget to stab yourself
[12:07:22] <cartman> elenril: never gonna happen
[12:07:27] <elenril> kshishkov: i'll do someting worse
[12:08:35] <elenril> i'll spend the rest of the day calculating scattering cross sections
[12:09:01] <kshishkov> yay!
[12:09:11] <elenril> how evil
[12:09:22] <spaam> elenril: compile ffmpeg with -O1338 and --omg-optimized.. then ffmpeg will be FAST
[12:09:22] <elenril> this is going to leave a deep scar on me
[12:09:35] <elenril> you ean -O9001
[12:09:38] <elenril> *mean
[12:12:28] <cartman> New Amazon SPAMâ„¢ service http://aws.amazon.com/ses/
[12:13:17] <Dark_Shikari> lu_zero: BBB's emulated edge
[12:17:46] <lu_zero> nice =)
[12:17:59] <kshishkov> cartman: well, at least it should be easy to block
[12:32:25] <CIA-43> ffmpeg: Mans Rullgard <mans at mansr.com> master * re153e9a53a ffmpeg/libavcodec/latm_parser.c:
[12:32:25] <CIA-43> ffmpeg: latm: remove superflous #includes
[12:32:25] <CIA-43> ffmpeg: Signed-off-by: Mans Rullgard <mans at mansr.com>
[12:32:42] <av500> mru: ping
[12:32:56] <mru> pong
[12:47:53] <CIA-43> ffmpeg: Daniel Verkamp <daniel at drv.nu> master * r3adbe49f2b ffmpeg/Makefile:
[12:47:53] <CIA-43> ffmpeg: Fix ALLPROGS_G so that *_g binaries get cleaned properly
[12:47:53] <CIA-43> ffmpeg: Signed-off-by: Mans Rullgard <mans at mansr.com>
[13:07:46] <DonDiego> 101 commits :)
[13:08:02] <mru> since?
[13:08:17] <DonDiego> new tree
[13:09:11] <kierank> mru: how come you haven't put yourself back in http://ffmpeg.org/consulting.html
[13:09:36] <mru> kierank: I'm not going to
[13:09:45] <mru> kierank: too much "spam" requests
[13:09:50] <mru> indians writing iphone apps etc
[13:10:00] <kierank> lol
[13:10:04] <mru> the clients I want find me anyway
[13:10:32] <kierank> what happened to nds using ffmpeg?
[13:11:10] <mru> I've been answering weird questions for them
[13:11:16] <mru> time to send them a bill soon I think
[13:11:31] <kierank> the sky boxes have OSS in them now
[13:11:36] <kierank> seems to be a weird shift
[13:11:53] <mru> I know too much about those new sky boxes
[13:12:24] <mru> that software is one of the reasons I left
[13:12:33] <lu_zero> too ugly?
[13:12:33] <mru> it's just too horrible to work on
[13:12:42] <mru> overengineered
[13:12:48] <mru> enterprise-in-a-box
[13:12:57] <spaam> mru: why didnt you fix it?
[13:13:02] <kierank> i've been sent a motorola box
[13:13:29] <kierank> it is also enterprise in a box
[13:13:57] <spaam> enterprise-in-a-box?
[13:14:06] <kierank> prolly as much as the NDA says I can say too
[13:14:23] * mru never cared much about NDAs
[13:14:27] <kshishkov> spaam: because they prevented him removing at least four of five homebrew wrapper layers there
[13:15:00] <mru> kshishkov: that was actually a different system
[13:15:14] <spaam> kierank: ... ;P
[13:15:14] <kshishkov> mru: but from the same company?
[13:15:18] <mru> yes
[13:15:22] <mru> the old system
[13:15:36] <mru> kierank is talking about the new linux-based one
[13:15:38] <kshishkov> so why can't you expect similar programming gems in newer one?
[13:15:50] <mru> oh, it'll get there
[13:16:02] <mru> it just hasn't had time to grow all the wrappers yet
[13:17:26] * cartman hears collegaues talking about "openjpeg" dependency in "freetype"
[13:17:29] <cartman> life is good
[13:19:53] <lu_zero> mru make clean works for you?
[13:20:59] <mru> lu_zero: it deletes stuff, if that's what you mean
[13:22:13] <lu_zero> it doesn't delete ffmpeg_g and the rest for some reason
[13:22:20] <mru> that's fixed
[13:26:11] <lu_zero> nice =)
[13:26:14] <lu_zero> uh
[13:26:16] <lu_zero> interesting
[13:26:21] <lu_zero> a platform with hardfp
[13:26:30] <mru> ?
[13:27:13] <merbzt> would be nice if we could create a ffmpeg version that can be compiled with hardfp
[13:27:25] <mru> ffmpeg works fine with hardfp
[13:27:26] <merbzt> if it has any benefits though
[13:27:40] <mru> if you're talking about ARM
[13:27:45] <merbzt> yes
[13:28:04] <mru> I build it for hardfp all the time
[13:28:07] <cartman> Tegra2?
[13:28:17] <mru> and omap3/4
[13:28:24] <mru> I don't use the tegra much
[13:28:40] <cartman> yeah tegra doesn't have neon lights =p
[13:29:00] <mru> and is generally painful to deal with
[13:29:14] <lu_zero> uhm
[13:29:26] <mru> no documentation etc
[13:29:36] <merbzt> so we don't use things that could be affected by hardfp ?
[13:29:42] <lu_zero> the toolchain I'm playing with seems to be bogus in some regards
[13:29:46] <mru> merbzt: we do, but it's all taken care of
[13:30:21] <merbzt> have you banchmarked hardfp vs soft ?
[13:30:30] <mru> not much difference in ffmpeg
[13:30:40] <mru> we don't tend to pass floats between functions much
[13:30:49] <merbzt> yeah thought so
[13:31:17] <mru> but it's still a saner calling convention
[13:32:05] <merbzt> yeah
[13:33:19] <mru> jannau: ping
[13:36:31] <kshishkov> BTW, are we ready for GSoC 2011?
[13:36:50] <av500> kshishkov: I am ready to apply
[13:37:33] <kshishkov> av500: for what project?
[13:37:52] <cartman> bink-b
[13:37:53] <cartman> :p
[13:38:32] <av500> kshishkov: hmm
[13:38:43] <av500> kshishkov: ffmpeg-wrapper maybe?
[13:38:50] <av500> or codec plugins
[13:38:56] <cartman> av500: OMX codec support in FFmpeg
[13:39:15] <mru> then do an omx wrapper around ffmpeg
[13:39:15] <kshishkov> yes, and make mru a mentor for that!
[13:39:53] <mru> I'll probably mentor for beagleboard if they're accepted again
[13:40:27] <elenril> i think we urgently need a shitty mp3 encoder
[13:40:41] <kshishkov> that's easy
[13:40:49] <kshishkov> wanna me write it?
[13:40:52] <elenril> maybe i could try writing one
[13:41:01] <elenril> kshishkov: you shoul fix aacenc
[13:41:05] <mru> elenril: why do we need that?
[13:41:05] * kshishkov has a shitty encoder in his portfolio already
[13:41:09] <mru> lame is good enough
[13:41:12] <elenril> mru: because we don't have one
[13:41:14] <mru> and mp3 is dead
[13:41:22] <kierank> elenril: could have a decent mp2 encoder ;)
[13:41:22] <kshishkov> mru: to provide source for his IDv3 tags of course!
[13:41:35] <kshishkov> kierank: to accompany x262?
[13:41:40] <av500> kshishkov: for a wrapper project, I will mentor myself
[13:41:46] <kierank> kshishkov: yeah
[13:41:50] <elenril> av500: what wrapper?
[13:42:08] <av500> elenril: wrap ffmpeg in itself
[13:42:47] <kshishkov> elenril: OMX input for FFmpeg using FFmpeg interface to OMX so lavc can indirectly call lavc indefinitely
[13:42:51] <av500> maybe we can wrap v2.4 tags as a binary blob in v2.3 ones too?
[13:42:59] <elenril> sure
[13:43:36] <kshishkov> elenril: does you metadata muxer support muxing v2.3 and v2.4 streams into single metadata?
[13:43:45] <kierank> what about mp3pro decoder
[13:43:52] <av500> that is even more dead
[13:43:56] <kierank> exactly
[13:43:59] * elenril stabs kshishkov 
[13:44:08] <av500> what are we, dead codecs society?
[13:44:16] <elenril> av500: you didn't notice?
[13:44:24] <kshishkov> kierank: it uses hacked SBR, sometimes very hacked
[13:44:35] <av500> hmm, the strange smell, yes...
[13:44:52] <kshishkov> av500: yes, we care for dead codecs, game codecs, obsolete and long-forgotten codecs and Bink-b
[13:45:14] <CIA-43> ffmpeg: Georgi Chorbadzhiyski <gf at unixsol.org> master * r6e78c8ee94 ffmpeg/libavformat/mpegtsenc.c: (log message trimmed)
[13:45:14] <CIA-43> ffmpeg: mpegtsenc: remove unused variables
[13:45:14] <CIA-43> ffmpeg: Remove two variables that were not used and caused the following
[13:45:14] <CIA-43> ffmpeg: warnings:
[13:45:14] <CIA-43> ffmpeg: CC libavformat/mpegtsenc.o
[13:45:14] <elenril> btw what happened to audio filters soc?
[13:45:15] <CIA-43> ffmpeg: libavformat/mpegtsenc.c: In function 'mpegts_write_section':
[13:45:16] <CIA-43> ffmpeg: libavformat/mpegtsenc.c:72:18: warning: unused variable 'ts'
[13:45:22] <CIA-43> ffmpeg: Daniel Verkamp <daniel at drv.nu> master * r54fe299b88 ffmpeg/configure:
[13:45:22] <CIA-43> ffmpeg: configure: move network tests before results are needed
[13:45:22] <CIA-43> ffmpeg: This moves network_extralibs setup before use so that the link tests
[13:45:22] <CIA-43> ffmpeg: for network functions work correctly.
[13:45:22] <CIA-43> ffmpeg: Signed-off-by: Mans Rullgard <mans at mansr.com>
[13:45:24] <CIA-43> ffmpeg: Mans Rullgard <mans at mansr.com> master * r3d157bf31f ffmpeg/Makefile:
[13:45:24] <CIA-43> ffmpeg: Makefile: fix cleaning of tools in tests directory
[13:45:24] <CIA-43> ffmpeg: The variable TESTPROGS is reset by the library makefiles,
[13:45:25] <CIA-43> ffmpeg: use another name.
[13:45:25] <CIA-43> ffmpeg: Signed-off-by: Mans Rullgard <mans at mansr.com>
[13:45:26] * av500 secretly plants bink-c info on teh intertubes...
[13:45:36] <elenril> saste: ^?
[13:46:06] * av500 goes to learn git
[13:46:12] <av500> git co
[13:46:21] <mru> mmit
[13:46:36] <elenril> fatal: Not a git repository (or any parent up to mount parent )
[13:46:36] <jannau> mru: pong
[13:46:40] <av500> is there a single git command that converts my svn checkout to git?
[13:46:42] <kshishkov> av500: there are no known bink-a, bink-c, bink-d and bink-e instances IIRC. And bink-b existence is not acknowledged by its creators either
[13:46:56] <mru> jannau: why does patchwork not always pick up commits?
[13:47:56] <kshishkov> mru: commit titles mismatch with patches?
[13:48:14] <mru> it that all it takes?
[13:48:17] <wbs> av500: do you want to convert your ntfs partition to ext3 in-place, too? ;P
[13:48:25] <av500> wbs: yes
[13:48:34] <jannau> hash mismatches, should be only patch content
[13:49:07] <av500> wbs: now that ff is git, I can finally commit my ff git into company svn :)
[13:49:07] <mru> jannau: so if patches are committed out of order it won't work?
[13:49:09] <kshishkov> av500: git init
[13:49:33] * av500 does not fall for that trap
[13:49:53] <av500> kshishkov: and then git add .svn?
[13:49:58] <kshishkov> git trap --target=av500
[13:50:07] <kshishkov> av500: of course
[13:50:07] <mru> av500: git init; git remote add origin git://git.ffmpeg.org/ffmpeg.git; git fetch; echo .svn >>.git/info/exclude
[13:50:52] <mru> + git branch -fb master origin/master
[13:51:01] <jannau> I've read that it has something to deal with mismatching offsets but it's not 100% relieable
[13:51:23] <av500> my svn checkout is borken anyway since swscale went awol
[13:52:45] <kshishkov> so just ditch it
[13:53:00] <av500> it has many valuable printfs :)
[13:53:18] <kshishkov> another reason to ditch it
[13:53:24] * cartman hands av500 a svn diff
[13:53:34] <av500> :)
[13:54:02] <mru> with some adjustments to the commands above you can turn the tree into a working git clone
[13:54:24] <mru> just change the branch command to point at the commit corresponding to the svn rev your checkout is at
[13:54:47] <mru> then you can git commit the changes and pull --rebase
[13:56:10] <mru> kshishkov: the fax decoder fails on blackfin
[13:56:12] <mru> fix it!
[13:56:25] <andoma> :)
[13:57:00] <mru> and lavf-dv crashes with a segv
[13:57:11] <mru> that's the test that uses a 100MB fifo
[13:57:14] <kshishkov> mru: okay, just donate me a blackfin
[13:57:25] <mru> and there's not that much memory available
[13:57:30] <av500> andoma: fedex picked it up
[13:57:47] <andoma> cool
[13:58:01] <mru> av500: you're sending *it* somewhere?
[13:58:09] <av500> yes
[13:58:14] <cartman> mru: make dsort=date default on fate pls
[13:58:31] <mru> cartman: I like it how it is
[13:58:36] <mru> change your bookmarks
[13:58:51] <cartman> mru: I don't use bookmarks, I type with my bear hands
[13:59:14] <mru> cartman: http://www.fugly.com/media/IMAGES/Random/with-my-bear-hands.jpg
[13:59:15] <DonDiego> mru: so, are you interested in the sun for fate or not?
[13:59:28] <mru> DonDiego: I have neither space nor time for it
[13:59:29] <cartman> mru: exactly that one
[14:00:02] <mru> DonDiego: and we have some sparc tests on there already
[14:00:05] <Flameeyes> DonDiego: do you really think I changed all those lines by hand?
[14:00:28] <av500> Flameeyes: bear hands?
[14:02:08] <DonDiego> Flameeyes: of course not - i did not mean to imply you should do the extra change by hand ;-p
[14:02:32] <Flameeyes> I really would avoid using gnu indent :P
[14:03:08] <DonDiego> Flameeyes: try uncrustify, works like a charm after you set it up properly and when it does not, the author reacts quickly...
[14:03:22] <mru> DonDiego: let's just get this prefixing done first
[14:03:23] <kshishkov> mru: bfin stderr for test gives "Cannot allocate 48018632 bytes output buffer". Can't you solder more memory there without my help?
[14:03:26] <mru> we can worry about style later
[14:03:26] <Flameeyes> DonDiego: will do!
[14:03:58] <mru> kshishkov: ah, that explains it
[14:04:11] <mru> I've allocated 32M for .bss+heap
[14:04:15] <DonDiego> the patch is fine as-is, i think i OKed it unconditionally on the ml, but by all means somebody commit it...
[14:04:34] <mru> I'd like the version script change separated
[14:04:37] <mru> as I said
[14:04:44] <mru> it's impossible to find in the noise
[14:04:45] <DonDiego> git add -p?
[14:04:57] <mru> just omit that file
[14:06:12] <cartman> 1,10MB of 484,OO KB
[14:06:18] <cartman> IE does it again :p
[14:07:26] <cartman> this fucking firewall is fucked up
[14:07:28] <cartman> URL: hakim.se/experiments/html5/sketch/
[14:07:29] <cartman> Category: Personal Relationships
[14:07:45] <kierank> turkish firewall
[14:08:12] <cartman> kierank: new work firewall :(
[14:08:15] <kshishkov> kierank: programmed by Turks for Turks
[14:08:20] <av500> every doner shop here has one of these
[14:08:25] <av500> döner
[14:08:33] <cartman> av500: go to döner.de
[14:09:59] * kierank feels hungry after thinking about doner kebab
[14:10:11] <cartman> kierank: döner in EU has the worst meat ever.
[14:10:15] <cartman> don't eat that crap
[14:10:18] <kierank> of course
[14:10:31] <kierank> it's no secret
[14:10:36] <mru> cartman: worse meat than in .tr?
[14:10:37] <kierank> but when you're drunk it's like manna
[14:10:38] <av500> cartman: its made of turkish kids, that is known...
[14:10:44] <cartman> mru: its lamb meat here.
[14:11:07] <mru> I wasn't primarily thinking about the species
[14:11:17] <cartman> mru: better meat here, sorry :p
[14:11:17] <av500> cartman: because I never see kids around the döner shops...
[14:11:17] <mru> not the primary species at least
[14:12:16] <cartman> av500: Don't you have a ministry of health?
[14:12:47] <mru> cartman: no, they have a ministry of disease
[14:12:49] <av500> these people vanish around döner places too
[14:13:03] <mru> av500: and the rats, don't forget the rats
[14:13:13] <av500> mru: rat döner is hard to find
[14:14:42] <cartman> av500: your favourite
[14:15:18] <kshishkov> av500: in .ru/.ua you can buy middle asian version with the best meat from stray cats or dogs
[14:15:54] <DonDiego> ruggles: Subject: [FFmpeg-devel] [PATCH 07/11] Remove unused ff_ac3_parse_header_full function
[14:16:03] <thresh> yeah, the meat that was myawing just 30 minutes ago
[14:16:13] <DonDiego> Dark_Shikari: this reminds me that i wanted to ping you about a libx264 patch
[14:16:31] <kshishkov> thresh: купи 5 беляшей и собери собачку
[14:17:19] <elenril> take your vulgar topics out of this noble company =p
[14:19:00] <kshishkov> av500: that's why I prefer eating in a country where they have proper deer, reindeer and elk meat
[14:19:53] <av500> kshishkov: thats how they label cats and dogs?
[14:20:06] <cartman> elk -> rat?
[14:20:30] <mru> size discrepancy...
[14:20:34] <kshishkov> av500: nope, there are plenty of real animals there
[14:20:35] <andoma> is there a sign-extension helper somewhere in ffmpeg?
[14:20:41] <andoma> get_bits(gb, 6) -> signed int
[14:20:43] <av500> womp rats ftw
[14:20:45] <mru> andoma: sign_extend() in mathops.h
[14:20:48] <andoma> oh!
[14:20:52] <mru> and get_sbits()
[14:20:55] <andoma> ah
[14:22:09] <kshishkov> cartman: in other places elks are known as mooses, not rats
[14:22:25] <mru> andoma: now I want a linux spotify client in return
[14:22:47] <kshishkov> mru: despotify.se
[14:22:52] <andoma> thanks
[14:23:04] <cartman> mru: there is one with Qt4 GUI :P
[14:23:13] <av500> mru: there is one, it runs on the linux kernel :)
[14:23:44] <andoma> your account needs to be premium or unlimited  though
[14:23:56] <cartman> yeah a vpn is cheaper \o/
[14:24:20] <mru> cartman: how does a vpn help connect to spotify?
[14:24:36] <cartman> mru: Prerequisite 0 was using OSX :P
[14:25:08] <kshishkov> mru: if you connect to andoma's work server via VPN...
[14:26:37] <BBB> Dark_Shikari: I'm waiiiiiitiiiiiiing :-p
[14:27:14] <kshishkov> BBB: go to mad house, show your patch at entrance, be admitted
[14:27:26] <BBB> yes, that is true
[14:27:26] <av500> DonDiego: lu_zero : you are booked at the St Nicolas too?
[14:27:33] <BBB> but how do I make it better? come on guys
[14:27:36] <BBB> it's not eternally doomed
[14:28:02] <elenril> BBB: go review my patches while D_S is procrastinating ;)
[14:28:13] <BBB> when I get in the office I will
[14:28:51] <kshishkov> office?
[14:29:03] <av500> the federal review office
[14:29:20] <kshishkov> they have only internal review office
[14:29:25] <kshishkov> aka IRS
[14:29:47] <DonDiego> av500: not sure, lu_zero is taking care of the rooms, i'm just trawling along, but the whole crew in the same hotel would be great - how much do you pay per night?
[14:29:55] <mru> hmrc ftw
[14:30:11] <BBB> elenril: btw didn't we review and apply all your patches already?
[14:30:13] <av500> hmso ftw
[14:30:42] <elenril> no
[14:30:51] <elenril> still two to review and 4 to apply
[14:31:16] <kshishkov> write some interesting patches then
[14:31:30] <kshishkov> (i.e. not related to metadata)
[14:31:32] <elenril> some crazy ones like BBB does?
[14:31:40] <kshishkov> why not?
[14:31:46] <av500> find a middle ground
[14:31:46] <BBB> why does everyone think it's crazy?
[14:31:53] <av500> hearsay
[14:31:54] <BBB> the patch is Fast[TM]
[14:31:55] <elenril> BBB: people say it is
[14:32:06] <kshishkov> BBB: because D_S said so and we trust his judgement
[14:32:07] <BBB> elenril: people say lots of things
[14:32:20] <BBB> the patch mechanism was his idea
[14:32:29] <BBB> so if it's nuts, it's because he told me to do so :-p
[14:33:01] * elenril scatters some µons on BBB 
[14:33:19] <kshishkov> elenril: he won't notice them anyway
[14:33:27] <kierank> [14:29] mru: hmrc ftw --> erm
[14:33:32] <kshishkov> elenril: try pi-mesons
[14:33:47] <mru> kierank: sarcasm detector offline?
[14:34:09] <mru> damn, I still need to make up some numbers for them...
[14:34:10] <av500> DonDiego: it was to answer siretart asking on the ML
[14:34:16] <av500> 54!
[14:34:46] <kierank> mru: yes offline
[14:39:10] * siretart turns up
[14:40:30] <av500> siretart: a bunch of us is in the st nicolas, i dont remember if that includes lu_zero  and DonDiego
[14:40:41] <siretart> k
[14:41:17] <siretart> A collegue here told me the hotel where the opensuse folks are staying
[14:41:26] <siretart> but I'm still not totally decided if I will go
[14:41:34] <cartman> siretart: those are good folks
[14:41:36] <cartman> *ahem*
[14:42:15] <av500> siretart: irc logs indicate they are there as well
[14:43:41] <siretart> av500: according to my information, they are in radison blu
[14:43:55] <av500> siretart: oh
[14:45:21] <kshishkov> cartman: the guys who gave us ALSA are good?
[14:45:59] <cartman> kshishkov: yes
[14:48:14] <elenril> kshishkov: better than the guys who gave us pulseaudio
[14:51:04] <kshishkov> elenril: well, SuSE guys created some other abominations as well
[14:53:58] <j-b> elenril: you can't wait for systemd, I guess, then :D
[14:54:24] <elenril> heh
[14:54:49] <elenril> upstart is rather nice though
[14:54:58] * mru prays to $all_deities that gentoo will remain a sane haven
[14:55:35] * cartman expects Gentoo to switch to systemd too
[14:55:54] <kshishkov> mru: it's been touched by Hand of BSD, so it's tainted :(
[14:56:17] <Kovensky> 11:54.58 mru prays to $all_deities that gentoo will remain a sane haven <-- wrong sigil, should've been @all_deities
[14:56:29] * Kovensky runs
[14:56:39] <mru> Kovensky: good catch
[14:56:47] <Kovensky> heh
[14:57:03] <kshishkov> an associative array of deities?
[14:57:33] <Kovensky> no, that'd be % and you can't put % directly on strings
[14:58:19] <cartman> brb
[14:58:27] * av500 thought $deity was a singleton?
[14:59:28] <Kovensky> av500: but there is a $deity singleton for each monotheistic religion, so it's easier to use @all_deities which contain refs to each religion's deities as a flattened list
[14:59:57] <mru> av500: java.faith.Deity.getInstance()?
[15:00:36] <av500> deties.xml
[15:07:13] <j-b> wbs: why do you care about win2000 ?
[15:07:40] <mru> win2k is irrelevant
[15:07:52] <wbs> j-b: well, it was discussed sometimes last year, people had varying opinions
[15:07:52] <mru> but does it work on windows me, that is the question?
[15:07:59] <wbs> lol
[15:08:08] <j-b> wbs: well, last year, win2000 was still supported
[15:08:12] <j-b> wbs: it isn't anymore
[15:08:31] <kshishkov> mru: win3.11 + win32s is the base
[15:08:38] <wbs> j-b: the effort for supporting it wasn't too bad, so we went that route instead of explicitly dropping support for something ;P
[15:08:55] <j-b> "Support for Windows 2000 ended on July 13, 2010!"
[15:10:54] <wbs> oh crap, didn't get that memo
[15:11:12] <CIA-43> ffmpeg: Diego Elio Pettenò <flameeyes at gmail.com> master * r362bfe2997 ffmpeg/libavcodec/ (ac3.c ac3.h):
[15:11:12] <CIA-43> ffmpeg: Remove unused ac3_parametric_bit_allocation function.
[15:11:12] <CIA-43> ffmpeg: Signed-off-by: Mans Rullgard <mans at mansr.com>
[15:11:15] <CIA-43> ffmpeg: Diego Elio Pettenò <flameeyes at gmail.com> master * r6ed3b504f9 ffmpeg/libavcodec/ (ac3.c ac3tab.c):
[15:11:15] <CIA-43> ffmpeg: Move ff_ac3_critical_band_size_tab in ac3.c for non-hardcoded tables.
[15:11:15] <CIA-43> ffmpeg: This symbol is only ever used to calculate the non-hardcoded tables, so
[15:11:15] <CIA-43> ffmpeg: only enable it in that case, and static to the source unit that uses it.
[15:11:16] <CIA-43> ffmpeg: Signed-off-by: Mans Rullgard <mans at mansr.com>
[15:16:27] * elenril loves 2.1-line integrals
[15:17:14] <mru> elenril: my rule of thumb in school was that if an expression got longer than one line, I'd made a mistake
[15:17:21] <mru> worked pretty well
[15:17:27] <elenril> no, qft is really that bad
[15:19:22] <mru> said rule obviously only works in school, not in the real world
[15:22:31] <kshishkov> probably it's reverse in solid bodies modelling - if it's shorter than two lines you've forgotten something
[15:22:56] * cartman notes that Cardigans is one of the good things coming out of *.se
[15:23:12] <mru> aren't they a bit 80s?
[15:24:57] * av500 wears t-shirts only
[15:25:04] <thresh> even in winters?
[15:25:11] <microchip_> lu_zero: ping
[15:25:56] <microchip_> alright, seems he's afk... anyone knows if ffserver can stream mp4/h264 ?
[15:26:01] <av500> thresh: in winter I wear jack wolfskin or north face, if only I could decide
[15:26:17] <thresh> they make t-shirts?
[15:26:31] <av500> i guess they do :)
[15:26:50] * cartman takes note :P
[15:28:57] <mru> av500: not south butt?
[15:29:08] <cartman> or Gore TeX
[15:29:40] <av500> AlGoreTex
[15:29:42] <kshishkov> mru: Abba is nice too. Jag älskar inlägd sill.
[15:29:54] <cartman> Cardigans is 90s
[15:30:15] <mru> still old
[15:30:57] <mru> not that old is necessarily bad
[15:31:14] <mru> they made some great rock in the 60s
[15:31:15] <av500> 1890?
[15:31:47] <cartman> better than current crap , *sniff*
[15:33:14] <thresh> you don't like Justin Bieber?!
[15:33:14] <kshishkov> mru: any opinion on Hagström guitars?
[15:33:34] * mru does not play the guitar
[15:33:45] <kshishkov> mru: http://sv.wikipedia.org/wiki/Hagstr%C3%B6m
[15:33:45] <cartman> http://www.youtube.com/watch?v=s2UWxiLSA48 kicks Justin's butt
[15:36:51] <cartman> KotH: http://www.rthaber.com/-haber-5668---.html
[15:39:53] <KotH> rotfl
[15:40:05] <av500> what is 4 and 5?
[15:40:42] <DonDiego> i'm going home, cu guys
[15:41:46] <cartman> av500: a guy called Temel asks the prime minister about corruption in 3 questions
[15:42:06] <cartman> av500: his friend Dursun asks (after a break), why the break was 30 minutes earlier and where tf is Temel now
[15:42:26] <av500> cartman: thx
[15:44:05] <mru> lol @ google translate
[15:44:20] <mru> 1-in power despite being worn out how we increased event.php?
[15:44:28] <cartman> lol
[15:44:52] <jannau> mru: 6ed3b504f9 breaks many compilers
[15:45:05] <cartman> translates Temel as "Basic"
[15:45:06] <cartman> heheh
[15:45:22] <mru> ruggles: !!!!!!!!!!!!!
[15:45:30] <mru> and Flameeyes
[15:46:51] <mru> do you people not test your patches?
[15:47:03] <kshishkov> cartman: it's very old joke, probably was popular in DDR too (and USSR of course)
[15:47:27] <av500> mru: fate does that
[15:48:52] <kshishkov> av500: it hasn't evolved yet to the stage when it can send letter back to ML with complaints "you commit broke my builds"
[15:48:59] <mru> fix sent
[15:49:00] <cartman> kshishkov: it was a good one :>
[15:49:12] <thresh> kshishkov: actually buildbot can do that
[15:49:22] <thresh> that isnt that cool yet though
[15:49:23] <cartman> time to slack off
[15:49:25] <cartman> see ya
[15:50:06] <mru> would someone please ack the patch?
[15:51:11] <CIA-43> ffmpeg: Mans Rullgard <mans at mansr.com> master * r21c900129c ffmpeg/libavcodec/ac3tab.h:
[15:51:11] <CIA-43> ffmpeg: ac3: remove ff_ac3_critical_band_size_tab[] external declaration
[15:51:11] <CIA-43> ffmpeg: This fixes compilation broken by 6ed3b504f984dc6cefde8d57a57726f9d30e5033
[15:51:11] <CIA-43> ffmpeg: Signed-off-by: Mans Rullgard <mans at mansr.com>
[15:54:44] <Tjoppen> the inbox overfloweth
[15:55:40] <av500> Tjoppen: wrt mxf, it supports a fixed list of codecs or something like fourcc based?
[15:56:45] <kierank> av500: fourcc in your dreams
[15:56:47] <kierank> guid more like
[15:56:53] <mru> fixed list of guid
[15:56:57] <kshishkov> Tjoppen: does that mean FFmpeg is in active development state again?
[15:56:59] <kierank> and even with all that guid space there are still colissions
[15:57:33] <BBB> indeed
[15:57:36] <BBB> indeed
[15:58:22] <kshishkov> kierank: why not? Especially since some GUIDs are not that random
[15:59:04] <BBB> hrm
[15:59:09] <BBB> my chat client is misbehaving
[15:59:11] <BBB> anyway
[15:59:25] <BBB> mru, jannau you are queueing patches OK'ed by us right?
[15:59:30] <BBB> or should I use patchwork also now?
[15:59:32] <kshishkov> BBB: check for babies around
[15:59:41] <BBB> mine is at home, so not here
[16:00:00] <av500> you left the baby at home alone
[16:00:09] <CIA-43> ffmpeg: Mans Rullgard <mans at mansr.com> master * r1e48cdaac3 ffmpeg/libavformat/tty.c:
[16:00:09] <CIA-43> ffmpeg: tty: remove superflous #include <strings.h>
[16:00:09] <CIA-43> ffmpeg: Signed-off-by: Mans Rullgard <mans at mansr.com>
[16:00:21] <CIA-43> ffmpeg: Mans Rullgard <mans at mansr.com> master * re781c4e6ff ffmpeg/libavutil/intfloat_readwrite.c:
[16:00:21] <CIA-43> ffmpeg: intfloat_readwrite: include "mathematics.h" for fallback macros
[16:00:21] <CIA-43> ffmpeg: This allows this file to build on systems lacking NAN or INFINITY
[16:00:21] <CIA-43> ffmpeg: in math.h.
[16:00:22] <CIA-43> ffmpeg: Signed-off-by: Mans Rullgard <mans at mansr.com>
[16:00:35] <mru> jannau: it would be nice if patchwork could somehow detect approved patches
[16:01:23] <merbzt> and if they are not approved, somehow fix them so they can be
[16:01:43] <kshishkov> av500: are you suggesting he should get few more babies?
[16:01:48] <mru> merbzt: is the warning counter to your liking btw?
[16:01:54] <mru> you were always asking for that
[16:02:31] <jannau> BBB: I'm away from a computer with git, I'll catch up tonight, everything mru hasn't picked up
[16:02:43] <jannau> mru: it's on my todo list
[16:03:03] <mru> no rush
[16:03:17] <merbzt> mru: simple and awesome
[16:03:23] <mru> we've managed without it all this time, so I'm sure we can cope a little longer
[16:03:47] <BBB> does patchwork apply patches?
[16:03:51] <BBB> or do you do that yourself still?
[16:04:04] <mru> it does not
[16:04:49] <BBB> ok
[16:04:52] <BBB> n/m then
[16:04:53] <mru> nor would I want that
[16:04:58] <BBB> hackable :-p
[16:06:09] <BBB> is anyone merging patches from ffmpeg-cvslog/videolan-tree?
[16:06:15] <BBB> e.g. the mov demuxer patch by baptiste?
[16:07:04] <mru> they should be posted to the ml for review
[16:07:42] <BBB> so nobody is working on that?
[16:07:45] <BBB> I'll tree to do that...
[16:07:50] <BBB> did you queue "Set reserved bits to 1 when writing PCR in mpegts packets"?
[16:08:16] <lyakh> how does it happen, that some codecs (audio or video) have a "hot-spot" where they spend, say, more than 25% of the time calculating, whereas others have load approximately evenly spread over several functions?
[16:08:22] <kshishkov> BBB: should I post your RM multistream patch for review?
[16:08:25] <mru> sent
[16:08:44] <BBB> kshishkov: sure, but it's hideous, people will think that all my code is suddenly poor
[16:09:00] <mru> lyakh: the former have not been optimised properly
[16:09:01] <kshishkov> lyakh: yep
[16:09:09] <BBB> mru: I was thinking of "In mov muxer, mux adpcm_ms and adpcm_ima_wav the way quicktime supports it"
[16:09:25] <kshishkov> BBB: so they'll know the truth
[16:09:28] <BBB> lyakh: if there's functions that we spend a lot of time in and the codec is popular, we'll optimize that function. if we don't care, we don't optimize it :-p
[16:09:32] <lyakh> aha, so, it's not some fundamental property of two codec-types...
[16:09:32] <mru> BBB: yes, I sent that and the one after
[16:09:39] <BBB> lyakh: indeed
[16:09:43] <BBB> mru: ah I see, ok thanks
[16:09:49] <lyakh> hm, ok, thanks...
[16:10:09] <BBB> mru: will you queue the mpegts one? it seems you ok'ed it but you didn't queue / commit it yet
[16:10:13] <BBB> lyakh: which codec is this?
[16:10:23] <BBB> lyakh: if you ask nicely and someone has time, we might optimize it
[16:10:39] <kshishkov> even on SH4 :)
[16:10:41] * mru optimises codecs for $$$
[16:10:45] <mru> or make that $$$$
[16:10:53] <lyakh> mp3 has 53% in one fn, als 30%, vorbis 25%...
[16:10:54] <BBB> peloverde: can you review some audio-patches? :-p
[16:11:19] <BBB> I thought mp3 was pretty well-optimized? could just be that gcc inlines everything so it looks like it's one function
[16:11:22] <BBB> not sure though
[16:11:24] <av500> even after optimization a codec might spend more time in some functions...
[16:11:28] <lyakh> I optimized mp3 (as you know;)) and als now too, but with sh4-asm...
[16:11:29] <mru> BBB: mp3 isn't that well optimised actually
[16:11:31] <BBB> audio is not important anyway, most decoding time is spent in video
[16:11:35] * BBB runs
[16:11:46] <mru> BBB: that's a flawed argument
[16:11:51] <BBB> I know :-p
[16:11:54] <BBB> that's why I ran :)
[16:12:02] <mru> apparently you ran in a circle
[16:12:10] * kshishkov gives Monkey's Audio to BBB
[16:12:40] <mru> lyakh: once I get that sh4 stuff off av500 I can help optimise stuff
[16:13:03] <lyakh> mru: thanks, for sh4 or for all?
[16:13:24] <mru> I'll probably do some arm opts there too
[16:13:30] <kshishkov> on sh4?
[16:13:35] <mru> no, on arm
[16:13:36] <av500> kshishkov: yes!
[16:13:46] <mru> but some restructuring is common
[16:14:04] <BBB> D_S didn't review my emu_edge patch beyond his "OMG ITS EVIL" :(
[16:14:09] <mru> I expect to double the speed of the windowing function
[16:14:42] <mru> BBB: I don't see your patch in patchwork
[16:14:43] <lyakh> so, my idea is - to prepare what I've profiled, and what I've managed to optimize so far, post it to the list even if in some crude form - just for info, and maybe discuss that at FOSDEM?
[16:15:18] <BBB> mru: I probably didn't send it git-formatted
[16:15:26] <BBB> mru: how do I edit a patch in git after committing it?
[16:15:37] <BBB> or, how do I make a branch out of my current origin/master+local commits?
[16:15:39] <mru> do the edits and commit --amend
[16:15:46] <mru> or use the gui
[16:16:03] <BBB> and the branching?
[16:16:11] <mru> lyakh: speaking of fosdem, there was some talk on the ml about people driving there
[16:16:12] <BBB> I don't mind having to recommit it after creating the branch
[16:16:29] <mru> lyakh: in case you want share a car with some others
[16:16:51] <lyakh> mru: yes, seen that. that might be useful, it is still not clear, whether I'll be able to use mine;)
[16:16:53] <av500> but on friday :)
[16:17:00] <mru> BBB: have you tried gitk?
[16:17:01] <av500> so you have to drink beer
[16:17:06] <BBB> I use git gui
[16:17:07] <lyakh> I'll see:)
[16:17:09] <BBB> and GitX also
[16:17:11] <mru> gitk is great
[16:17:25] <jannau> BBB: if you want to have all commits in a branch in a single commit: git merge --squash
[16:17:51] <av500> fatal: bad default revision 'HEAD'
[16:17:54] <av500> ???
[16:18:11] <jannau> context?
[16:18:26] <av500> git log
[16:18:30] <av500> after git init
[16:18:35] <av500> and add remote and fetch
[16:18:58] <av500> git init; git remote add origin git://git.ffmpeg.org/ffmpeg.git; git fetch
[16:19:32] <lyakh> decode_spectrum_and_dequant() - bloody hell...
[16:19:42] <mru> aac?
[16:20:26] <lyakh> yes...
[16:20:30] <BBB> jannau: how do I switch branch
[16:20:30] <BBB> ?
[16:20:52] <mru> lyakh: you should've seen it before I optimised it
[16:20:53] <jannau> git checkout $branch
[16:21:03] <lyakh> up to 10 levels of indentation...
[16:21:58] <Tjoppen> av500: it supports whichever codecs have been registered with SMPTE for use in MXF
[16:22:42] <Tjoppen> each one gets a 128-bit UL, which is pretty much the MXF way of saying FOURCC
[16:22:55] <av500> Tjoppen: ic thx
[16:22:58] <mru> SIXTEENCC
[16:23:09] <av500> but there is no av_log that shows it, no?
[16:23:19] <Tjoppen> even more fun is that some codecs have specific variants registered
[16:23:45] <av500> Tjoppen: I guess I will just upload the sample :)
[16:23:59] <Tjoppen> like, PAL intra-only mpeg2 + more arbitrary settings might be registered as a "sub-codec"
[16:24:15] <BBB> jannau: ah thanks
[16:24:25] <BBB> jannau: so now when I git pull, does it update all branches or just my current one?
[16:24:55] <Tjoppen> so if you only match say the first 112 bits that may be enough to say "oh, it's mpeg2"
[16:24:58] <jannau> av500: still in your svn checkout?
[16:25:22] <av500> jannau: no, fresh git
[16:25:33] <av500> why does git diff show strange ESC codes
[16:25:41] <av500> or why does my term not like them?
[16:25:56] <jannau> ansi color codes?
[16:26:05] <av500> prolly
[16:26:19] <mru> av500: export LESS=-R
[16:26:26] <mru> or add -R to whatever is already in $LESS
[16:26:42] <av500> thx
[16:26:47] <jannau> BBB: git pull only updates the current branch
[16:27:13] <Tjoppen> bah, my ubuntu-virtualbox keeps hanging
[16:27:20] <mru> av500: you probably already had it set, or git would've supplied its own less flags
[16:27:27] <av500> mru: yes
[16:27:31] <av500> -M -I
[16:27:58] * av500 blames suse
[16:34:01] <av500> mru: gitk is awesome, I love how I can got back to the 1st commit in 2000 :)
[16:34:23] <BBB> jannau: how do I make it do all branches?
[16:34:35] <BBB> ports doesn't have gitk :(
[16:34:44] <mru> ditch the mac
[16:34:45] <j-b> use tig
[16:34:49] <j-b> way better
[16:34:59] <j-b> and gitks runs on my mac
[16:35:31] <mru> j-b: I actually like the guis
[16:35:32] <BBB> also how do I tell it what to update against?
[16:35:39] <BBB> git pull --rebase doesn't work b/c I'm in a branch
[16:35:46] <BBB> but git pull --rebase origin/master doesn't work either
[16:35:52] <BBB> what do I do?
[16:35:59] <mru> for the same reason I don't like browsing the web with lynx
[16:36:13] <BBB> j-b: gitks? is that the portname?
[16:36:40] <j-b> git package IIRC
[16:36:50] <BBB> hm
[16:37:01] <BBB> oh indeed I have it already
[16:37:03] <BBB> cute
[16:37:12] <wbs> BBB: git checkout master, git pull, git checkout $branch, git rebase master, is what I usually do
[16:38:01] <BBB> oh cute
[16:38:04] <BBB> that works
[16:38:06] <BBB> git is nice
[16:38:16] <wbs> and if all commits were on master already, I can go back to master and do git branch -d $branch
[16:38:33] <j-b> 17:37 <@BBB> cute
[16:38:36] <BBB> I saw that in git gui
[16:38:38] <j-b> BBB: no, one says Qt
[16:38:39] <BBB> gitk also
[16:38:51] <wbs> which will work if the branch doesn't have anything not on the current branch, but fail if there's still unmerged stuff
[16:39:05] <wbs> (branch -D force-deletes branches)
[16:39:11] <peloverde> BBB: after work
[16:39:26] <jannau> BBB: that's because your branch tracks your master branch. 'git branch --set-upstream origin/master' in your branch should fix it
[16:40:06] <BBB> gnome is trying to raise donors since 2 weeks now, they only have 29 so far... that's a rather sad figure
[16:40:28] <mru> wbs: I've made a special command for that sequence: git assimilate
[16:40:32] <BBB> somehow I feel that the linux desktops (as opposed to applications) as developer attractions are slowly dying...
[16:41:08] <wbs> mru: ah, that would probably be handy
[16:41:56] <mru> wait, that's not quite what my assimilate does
[16:42:05] <wbs> BBB: I guess once you're at this point, getting to feel that you know what happens (more or less), at least visualized by GitX or similar, you're never ever going back to branchless coding again :-)
[16:42:06] <mru> you can probably guess what it does
[16:43:00] <mru> BBB: and that I think is a good thing (re gnome etc)
[16:43:11] <mru> apps are what matter
[16:43:16] <mru> the rest is just fluff and NIH
[16:44:38] <BBB> mru: probably... I'm just surprised it took so long... kde same thing btw, massive way over-weight organization/lib, and a lot of it isn't very useful
[16:44:53] <BBB> big succesful projects always exist outside the kde/gnome spheres
[16:45:05] <BBB> succesful in "adoption beyond a few hundred geeks"
[16:45:24] <BBB> e.g. firefox, thingyoffice, one or two of those mono apps, vlc
[16:45:54] <peloverde> ewww firefox
[16:46:04] <mru> sure, but that's not the point
[16:46:21] <mru> it's wildly popular and not tied to any "desktop environment"
[16:46:42] <mru> btw, wtf happened to gnome's own browsers?
[16:47:36] <av500> gnome with the wind?
[16:47:46] <BBB> I forgot what it's called
[16:47:50] <siretart> mru: epiphany is still being ported to webkit
[16:47:51] <BBB> but it was such an integration disaster
[16:48:05] <mru> oh, is that what it's called now
[16:48:11] <BBB> you'd think that at the very least, since gnome has this massive NIH "media framework", it'd play video - guess what IT DOES NOT
[16:48:16] <elenril> konqueror was rather nice
[16:48:19] <mru> is used to be galeon, then nautilus, or was it the other way around?
[16:48:25] <BBB> all of the above
[16:48:26] <mru> elenril: konqueror is/was kde
[16:48:27] <siretart> before it was galeon, but then ephiphany was forked from it
[16:48:28] <elenril> and amarok is pretty popular
[16:48:34] <elenril> mru: i know
[16:48:49] <mru> I think amarok is popular _despite_ being kde
[16:48:50] <peloverde> galeon wasn't officially part of gnome and was partial inspiration for firefox
[16:48:51] <siretart> nautilus is the file manager, not related with any web browsing at all
[16:48:59] <peloverde> kcachegrind is pretty nice
[16:50:03] <peloverde> I wish gnome were less tightly coupled to evolution
[16:55:25] <BBB> oh, evolution
[16:55:30] <BBB> waiting, waiting, waiting, waiting
[16:55:33] <BBB> *crash*
[16:55:36] <BBB> \o/
[16:56:11] <peloverde> sadly gnome seems to be the least-bad oss desktop
[16:56:27] <mru> how about _no_ "desktop"?
[16:56:42] <mru> has served me well for many years
[16:57:35] <wbs> merbzt, cartman, av500 and other interested in android: http://android.git.kernel.org/?p=platform/development.git;a=commit;h=dfb9123d750437d050fcbbd7d64e18bf44011234 finally merged - from the next release (or whenever that's part of a release), you should be able to build ffmpeg without hacking the ndk headers ;P
[16:57:40] <peloverde> I like some of the functionality it provides
[16:57:59] <av500> wbs: nice
[16:58:07] <kierank> the most useful feature in gnome/gtk is the "favourite directories" thing on the left of file selection dialogs
[16:58:18] <av500> yes
[16:58:21] <mru> kierank: you get that with plain gtk
[16:58:28] <av500> thats about what I use...
[16:58:39] <wbs> I'm not sure wtf has happened with my wireshark for osx btw, the gtk file open dialogs sort files according to filename _length_, which is kinda annoying ;P
[16:58:57] <mru> lol
[16:59:20] * mru wants the gtk1 open dialog back
[16:59:48] <peloverde> the calendar widget on the panel is nice, I need some sort of widget to keep track of my windows, the menu is kind of useful
[17:00:58] <peloverde> plus gtk# apps pull in 500 years of deprecated gnome dependencies (at least on debian/ubuntu)
[17:01:29] * mru knows where his windows are
[17:02:47] <BBB> I want the mac open file dialog in gtk
[17:02:50] <BBB> much better
[17:03:20] <mru> I want a command line with tab completion
[17:05:17] <peloverde> What I really want is the windows 7 task bar
[17:05:41] <mru> task bars are nothing but theft of screen space
[17:05:56] <mru> I _know_ what apps I'm running dammit
[17:06:20] <Flameeyes> mru: pretty sure I did test it, where did it break?
[17:06:32] <mru> Flameeyes: it didn't build
[17:06:34] <mru> see fate
[17:06:47] <mru> just click the arrow on any red box
[17:06:55] <Flameeyes> will check fate, I guess it might be setup-dependent, as here it definitely didn't fail
[17:07:02] <mru> they all broke
[17:07:32] <mru> did you perhaps test only with hardcoded tables?
[17:09:29] <Flameeyes> uhm, that's a good question, I could have forgotten migrating the other config :/
[17:10:18] <Snaggle> Compile (linking) failure question goes here or on #ffmpeg?
[17:10:20] <Flameeyes> d'oh! indeed I only had yamato, not yamato-nohardcoded in the makefile :/
[17:10:43] <mru> Flameeyes: oh well, it was easily fixed
[17:11:20] <Flameeyes> mru: thanks! I'll also make sure to restore the local build for that
[17:15:38] <BBB> Snaggle: try #ffmpeg first please
[17:16:51] <Snaggle> BBB: k
[17:35:28] <CIA-43> ffmpeg: Jai Menon <jai at retroficial.org> master * rc0ae5152d1 ffmpeg/libavformat/ffmetaenc.c:
[17:35:28] <CIA-43> ffmpeg: ffmetaenc: Use correct format specifiers.
[17:35:28] <CIA-43> ffmpeg: Use printf format macros from inttypes.h.
[17:35:28] <CIA-43> ffmpeg: Additionally, this fixes a warning when building with clang.
[18:08:35] <BBB> hah, I finally have a mt branch
[18:08:40] <BBB> let's start fixing issues
[18:19:19] <Compn> btw does anyone remember who or why the wrappers for other codec libs were removed ?
[18:19:38] <mru> examples?
[18:19:58] <Compn> its been a while and my memory is dead
[18:20:03] <Compn> maybe faad/faac ?
[18:20:07] <mru> faad and vorbisdec were removed since we have better decoders ourselves
[18:20:15] <mru> faac is still there
[18:21:14] <Compn> guess there was never a libmpeg2
[18:22:35] <Compn> thought there were more
[18:22:44] <BBB> libamrnb/wb
[18:22:50] <BBB> we have decoders ourselves now
[18:22:56] <BBB> we use opencore for amrnb encoding
[18:23:17] <mru> we only wrap things where we aren't as good (yet)
[18:23:17] <BBB> mru: when will you commit your work on vp8 neon/arm?
[18:23:35] <mru> when it's finished, polished, and reviewd
[18:23:37] <mru> +e
[18:23:42] <BBB> hm
[18:34:40] <Tjoppen> bcoudurier: I just got an mxf sample where DataDefinition seems to have bogus values. having codec_type rely on which type of Descriptor is used fixes it. does this seem like a reasonable approach?
[18:38:41] <cbsrobot> hi - anybody knows why http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/2011-January/thread.html is not updated anymore ... ?
[18:42:51] <spaam> are you sure?
[18:43:33] <spaam> i see a lot of emails from today in it
[18:43:55] <jannau> yes, I have checked other lists too, last refreshed today 00:3x
[18:44:47] <cbsrobot> http://news.gmane.org/gmane.comp.video.ffmpeg.devel seems ok
[18:44:58] <spaam> mru KotH ?
[18:45:08] <Dark_Shikari> BBB: what
[18:45:27] <cbsrobot> on mplayerhq I see "Last message date: Tue Jan 25 02:29:44 CET 2011"
[18:45:39] <BBB> Dark_Shikari: nothing, can you review my small change to vp8.c and then start reviewing my hellish emu_edge disaster and tell me how to fix it? :-p
[18:45:44] <BBB> Dark_Shikari: I'm working on -mt now
[18:46:40] <BBB> Dark_Shikari: I openly admit the asm is ugly, I could commit that separately and then start working on the asm as-we-go
[18:46:46] <BBB> Dark_Shikari: makes review easier perhaps
[18:48:53] <Dark_Shikari> BBB: done
[18:51:13] <CIA-43> ffmpeg: Ronald S. Bultje <rsbultje at gmail.com> master * r44002d8323 ffmpeg/libavcodec/vp8.c:
[18:51:13] <CIA-43> ffmpeg: Don't do edge emulation unless the edge pixels will be used in MC.
[18:51:13] <CIA-43> ffmpeg: Do not emulate larger edges than we will actually use for this round of
[18:51:13] <CIA-43> ffmpeg: MC. Decoding goes from avg+SE 29.972+/-0.023sec to 29.856+/-0.023, i.e.
[18:51:13] <CIA-43> ffmpeg: 0.12sec or ~0.4% faster.
[18:51:40] <BBB> "this is fucking ugly" rofl
[18:54:49] <Dark_Shikari> btw if you want you can apply the same patch to h264
[18:54:59] <Dark_Shikari> it should be trivial
[18:55:54] * Dark_Shikari notices michaelni is still here (amazing!)
[18:56:59] <spaam> Nice :D
[18:57:28] <kierank> Dark_Shikari: and not behind a proxy or tor or anything ;)
[18:58:35] <kierank> michaelni: are you going to join #x264dev
[18:58:55] <BBB> Dark_Shikari: I can look at it, that's for luma only right?
[18:59:07] <BBB> (that staged mc filter thing for h264 mc is scary)
[19:00:32] <Dark_Shikari> Luma only, chroma is always bilinear and thus trivial
[19:01:00] <Dark_Shikari> the staged MC filter is trivial, just calculate the hpel pixels you need, then take the MAX() of the pixels required for each
[19:13:11] <BBB> Dark_Shikari: ok, I'll have a look at that, may not be today but on my list
[19:13:22] <BBB> (the vp8 one was on my list since like forever, I just never did it, no idea why)
[19:57:25] <pontscho> what a hell
[19:57:45] <kierank> hell is other people
[19:57:55] <pontscho> :)
[19:58:24] <pontscho> o/
[19:58:59] <Sean_McG> hi folks... any idea what's up with roundup today?
[19:59:24] <elenril> evil italian smugglers are stealing our routes
[19:59:28] <elenril> OrSoIHeard
[19:59:33] <Sean_McG> oh, weak
[20:15:41] <spaam> kshishkov: mmmm cold trocadero
[20:17:46] <bcoudurier> Tjoppen, is that file old ?
[20:20:28] <andoma> spaam: mmm!
[20:32:07] <BBB> astrange: there's some major (funny) bugs in your mt code, I'll see what I can do, which ones are you working on? from the patch you posted a week ago, any changes in your local git? should I work on your tree instead of using your patch?
[20:32:27] <BBB> astrange: oh, and bug isn't "haha your code sucks" but rather "it produces funny images that aren't quite right"
[20:32:29] <Tjoppen> bcoudurier: the mxf file? nope, made today with avid
[20:33:38] <CIA-43> ffmpeg: Mans Rullgard <mans at mansr.com> master * rd0f0f6287c ffmpeg/configure:
[20:33:38] <CIA-43> ffmpeg: armcc: filter out non-gcc options from ASFLAGS
[20:33:38] <CIA-43> ffmpeg: This allows passing armcc-specific flags with --extra-cflags without
[20:33:38] <CIA-43> ffmpeg: choking the assembler.
[20:33:38] <CIA-43> ffmpeg: Signed-off-by: Mans Rullgard <mans at mansr.com>
[20:33:47] <Tjoppen> it uses something that isn't even an smpte ul for its datadefinitions. I would have thought they were UIDs or something, but they're identical in both video and audio files
[20:33:49] <CIA-43> ffmpeg: Mans Rullgard <mans at mansr.com> master * r9d201b2606 ffmpeg/configure:
[20:33:49] <CIA-43> ffmpeg: configure: add filter_out() function
[20:33:49] <CIA-43> ffmpeg: This adds a function to filter out words matching a pattern
[20:33:49] <CIA-43> ffmpeg: from a list.
[20:33:49] <CIA-43> ffmpeg: Signed-off-by: Mans Rullgard <mans at mansr.com>
[20:34:33] <astrange> BBB: take the changes from my mainline_patches branch and apply them to git
[20:34:44] <astrange> or you can use master of my repository, which should be the same
[20:34:53] <astrange> but is still based on the last SVN rev
[20:35:21] <astrange> the branch is the same as the patches i sent, it's just hard to find all those lost in the email
[20:39:30] <Tjoppen> since the video descriptors all inherit GenericPictureEssenceDescriptor and similarly for audio I think it makes sense to set codec_type based on that
[20:44:26] <spaam> http://mashable.com/2011/01/25/adaptive-bit-rate-video-streaming/
[20:46:55] <astrange> BBB: is this vp8 or an existing codec?
[20:47:06] <spaam> its about HLS HTTP Live Streaming
[20:47:51] <Sean_McG> Hot Lesbian Sex?
[20:47:55] * Sean_McG ducks and runs
[20:48:05] <CIA-43> ffmpeg: Anton Khirnov <anton at khirnov.net> master * r93b78d1210 ffmpeg/libavformat/ (asfdec.c avio.h aviobuf.c):
[20:48:06] <CIA-43> ffmpeg: lavf: make a variant of ff_get_str16_nolen public
[20:48:06] <CIA-43> ffmpeg: It will be useful in mp3 demuxer and hopeful some other places.
[20:48:06] <CIA-43> ffmpeg: Signed-off-by: Janne Grunau <janne-ffmpeg at jannau.net>
[20:48:07] <CIA-43> ffmpeg: Anton Khirnov <anton at khirnov.net> master * r2934cd9dbf ffmpeg/libavformat/asfdec.c:
[20:48:07] <CIA-43> ffmpeg: asfdec: remove some commented-out cruft
[20:48:07] <CIA-43> ffmpeg: Signed-off-by: Janne Grunau <janne-ffmpeg at jannau.net>
[20:48:08] <CIA-43> ffmpeg: Anton Khirnov <anton at khirnov.net> master * rc34461b35b ffmpeg/libavformat/mov.c:
[20:48:08] <CIA-43> ffmpeg: mov: simplify mov_read_chapters() by using avio_get_str16be
[20:48:08] <CIA-43> ffmpeg: It probably also fixes a memleak or two.
[20:48:09] <CIA-43> ffmpeg: Signed-off-by: Janne Grunau <janne-ffmpeg at jannau.net>
[20:48:10] <CIA-43> ffmpeg: Diego Elio Pettenò <flameeyes at gmail.com> master * r101e1f6ff9 ffmpeg/libavformat/ (audiointerleave.h utils.c):
[20:48:10] <CIA-43> ffmpeg: Make ff_interleave_compare_dts static to utils.c.
[20:48:10] <CIA-43> ffmpeg: Signed-off-by: Janne Grunau <janne-ffmpeg at jannau.net>
[20:48:15] <CIA-43> ffmpeg: Diego Elio Pettenò <flameeyes at gmail.com> master * r8529731961 ffmpeg/libavcodec/ (h264.c h264.h):
[20:48:15] <CIA-43> ffmpeg: Make ff_h264_decode_rbsp_trailing static to h264.c
[20:48:15] <CIA-43> ffmpeg: Signed-off-by: Janne Grunau <janne-ffmpeg at jannau.net>
[20:48:18] <mru> here comes the flood
[20:48:27] <CIA-43> ffmpeg: Diego Elio Pettenò <flameeyes at gmail.com> master * ra3dffc0627 ffmpeg/libavformat/ (mxf.c mxf.h):
[20:48:27] <CIA-43> ffmpeg: Make ff_mxf_pixel_layouts static to mxf.c.
[20:48:27] <CIA-43> ffmpeg: Also make it an anonymous structure as never it is accessed by name.
[20:48:27] <CIA-43> ffmpeg: Signed-off-by: Janne Grunau <janne-ffmpeg at jannau.net>
[20:48:30] <CIA-43> ffmpeg: Diego Elio Pettenò <flameeyes at gmail.com> master * rd625a32d6b ffmpeg/libavcodec/rdft.c:
[20:48:30] <CIA-43> ffmpeg: Make ff_sin_tabs constant to rdft.c
[20:48:30] <CIA-43> ffmpeg: Signed-off-by: Janne Grunau <janne-ffmpeg at jannau.net>
[20:48:34] <CIA-43> ffmpeg: Diego Elio Pettenò <flameeyes at gmail.com> master * rf2e246f576 ffmpeg/libavcodec/ (png.c png.h):
[20:48:34] <CIA-43> ffmpeg: Make ff_png_pass_xmin and ff_png_pass_xshift static to png.c.
[20:48:34] <CIA-43> ffmpeg: Signed-off-by: Janne Grunau <janne-ffmpeg at jannau.net>
[20:48:34] <Sean_McG> whoa commitstorm
[20:48:38] <CIA-43> ffmpeg: Diego Elio Pettenò <flameeyes at gmail.com> master * rebb06d96ed ffmpeg/libavcodec/ (dwt.c dwt.h):
[20:48:38] <CIA-43> ffmpeg: Make ff_spatial_idwt_{init, slice} static to dwt.c
[20:48:38] <CIA-43> ffmpeg: Both functions seem to be commanded by the ff_spatial_idwt function
[20:48:38] <CIA-43> ffmpeg: instead.
[20:48:38] <CIA-43> ffmpeg: Signed-off-by: Janne Grunau <janne-ffmpeg at jannau.net>
[20:48:39] <CIA-43> ffmpeg: Diego Elio Pettenò <flameeyes at gmail.com> master * r676f1f533e ffmpeg/libavcodec/ (ac3_parser.c ac3_parser.h):
[20:48:39] <CIA-43> ffmpeg: Remove unused ff_ac3_parse_header_full function.
[20:48:39] <CIA-43> ffmpeg: Signed-off-by: Janne Grunau <janne-ffmpeg at jannau.net>
[20:50:45] <Sean_McG> hmmm what's the difference between CODEC_ID_H264 and CODEC_ID_MPEG4, especially given that so many of the ASP variants have CODEC_IDs of their own?
[20:51:05] * Sean_McG is working on roundup #2386
[20:51:06] <mru> CODEC_ID_MPEG4 is MPEG4 part 2
[20:51:13] <mru> CODEC_ID_H264 is MPEG4 part 10
[20:51:18] <mru> totally different codecs
[20:51:27] <jannau> and http://patches.ffmpeg.org/project/FFmpeg-devel/list/ is still long
[20:51:34] <mru> divx, xvid etc are also CODEC_ID_MPEG4
[20:51:39] <Sean_McG> ah...hrm.
[20:51:44] <mru> only the MS variants have their own IDs
[20:51:51] <mru> since they are not compatible with the standard
[20:55:30] <bcoudurier> Tjoppen, omg avid files...
[20:56:58] <Flameeyes> jannau: thanks for taking care of those
[20:57:40] <Tjoppen> indeed. I managed to get both audio and video files to play though
[20:57:58] <lu_zero> siretart: ping
[20:57:58] <Tjoppen> using a bit of that clip wrapping stuff on the ML
[20:58:14] <bcoudurier> well yes
[20:58:52] <astrange> HEVC 1.0 posted. wonder if 1.0 means anything
[21:04:27] <spaam> astrange: link?
[21:04:55] <astrange> http://www.h265.net/2011/01/hevc-test-model-hm-reference-software-1-0-released.html which doesn't seem to load
[21:05:08] <astrange> https://hevc.hhi.fraunhofer.de/svn/svn_HEVCSoftware/tags/HM-1.0/
[21:06:03] <_av500_> hevc is h265?
[21:06:12] <kierank> yes
[21:06:29] <_av500_> as in they decided on that?
[21:06:36] <kierank> yes
[21:06:53] <Dark_Shikari> It takes only 35 seconds per frame to encode SD on a core i7!
[21:06:54] <_av500_> i was not asked
[21:06:56] <Dark_Shikari> On fast mode.
[21:06:58] <Dark_Shikari> Amazing!
[21:07:10] <Sean_McG> o_O;
[21:07:21] <spaam> kierank: will we get avseq before hevc?
[21:07:52] <kierank> spaam: avseq needs its own itu working group
[21:08:17] <_av500_> Dark_Shikari: at that speed generating random bitstream and checking the decoded result might be faster...
[21:08:56] <spaam> kierank =/
[21:12:23] <CIA-43> ffmpeg: Diego Elio Pettenò <flameeyes at gmail.com> master * rcf1d794a49 ffmpeg/libavcodec/ (ass.c ass.h):
[21:12:23] <CIA-43> ffmpeg: Make ff_ass_subtitle_header static to ass.c
[21:12:23] <CIA-43> ffmpeg: Signed-off-by: Janne Grunau <janne-ffmpeg at jannau.net>
[21:12:26] <CIA-43> ffmpeg: Diego Elio Pettenò <flameeyes at gmail.com> master * r13eb6b9097 ffmpeg/libavcodec/ (h264.c h264_parser.c h264_parser.h):
[21:12:26] <CIA-43> ffmpeg: Make ff_h264_find_frame_end static to h264.c; delete h264_parser.h
[21:12:26] <CIA-43> ffmpeg: The header is empty after making the function static, so delete it and
[21:12:26] <CIA-43> ffmpeg: drop its usage.
[21:12:27] <CIA-43> ffmpeg: Signed-off-by: Janne Grunau <janne-ffmpeg at jannau.net>
[21:12:28] <bcoudurier> avseq ?
[21:12:30] <CIA-43> ffmpeg: Diego Elio Pettenò <flameeyes at gmail.com> master * r1a88674862 ffmpeg/libavcodec/ (ra144.c ra144.h):
[21:12:30] <CIA-43> ffmpeg: Make ff_add_wav static to ra144.c
[21:12:30] <CIA-43> ffmpeg: Signed-off-by: Janne Grunau <janne-ffmpeg at jannau.net>
[21:12:40] <CIA-43> ffmpeg: Diego Elio Pettenò <flameeyes at gmail.com> master * r57c4d01ec9 ffmpeg/libavformat/ (rtsp.c rtsp.h):
[21:12:40] <CIA-43> ffmpeg: Make ff_rtsp_send_cmd_with_content_async static to rtsp.c.
[21:12:40] <CIA-43> ffmpeg: Signed-off-by: Janne Grunau <janne-ffmpeg at jannau.net>
[21:13:05] <spaam> bcoudurier: AVSequencer
[21:13:27] <_av500_> famous gsoc project
[21:14:05] <kierank> so famous i'm suprised google didn't sponsor its completion
[21:14:23] <_av500_> kierank: im in talks with sergey about that
[21:14:43] <kierank> good to know
[21:14:49] <kierank> have ballmer as a backup just in case
[21:15:15] <spaam> yeah.
[21:15:30] <_av500_> i have a chair if needed
[21:15:54] <Sean_McG> so codec_tag of H.264 content is only 'mp4v' if it's been authored by QuickTime?
[21:15:56] <spaam> then we all can join cdgs with basty
[21:16:10] <kierank> _av500_: lol'd
[21:18:06] <siretart> lu_zero: sorry, still in a phone conference
[21:18:20] <lu_zero> np
[21:20:48] <relaxed> lu_zero: On roundup I'm seeing, "content file for /var/db/roundup/ffmpeg/db/files/msg13546 not found" on https://roundup.ffmpeg.org/issue2570. Is this a temporary issue?
[21:21:23] <Sean_McG> me too
[21:21:48] <in3xes> Can someone tell about AVStream?
[21:22:14] <in3xes> like, what is that for, how it should be used...
[21:23:58] <in3xes> Or, its such a easy thing that I should be able to figure out myself ?
[21:24:48] <lu_zero> relaxed: let me have a look at it
[21:26:11] * in3xes dives again into doxygen pages.
[21:30:12] <Flameeyes> buaahhahahhaha the one switch I found last night that seemed to have had a decent price in italy... was the wrong one
[21:30:29] <BBB> astrange: h264 test suite
[21:30:43] <Flameeyes> it was the non-managed one that it's at £120 (at €200 in italy)
[21:30:43] <BBB> astrange: I'm running make fate-h264 and fixing problems 1-by-1
[21:30:56] <BBB> (or, well, planning to; I haven't fixed anything yet)
[21:31:05] <kierank> BBB <3
[21:31:14] <kierank> oh <3 was pre-emptive
[21:32:57] <astrange> BBB: i agree that there are unexpected bugs in that
[21:34:06] <astrange> i stopped early because i couldn't figure out how to get the actual ffmpeg command for a fate test
[21:34:36] <mru> V=1
[21:34:49] <j-b> 'morning
[21:35:01] <mru> evening'
[21:35:28] <astrange> http://gitorious.org/~astrange/ffmpeg/ffmpeg-mt/blobs/cd71fb4386961bc860c3abc4cf464b580366d57d/mt-work/test-failures.txt
[21:45:25] <BBB> astrange: V=1 yeah
[21:45:28] <BBB> I'm working on it too
[21:48:05] <astrange> in the repo do 'git diff master mainline/master libavcodec/h264*' and you'll get a large diff that reverts all changes to it
[21:48:22] <astrange> binary search (apply the whole thing, revert and apply the first half, etc.) should find regressions
[21:49:31] <siretart> lu_zero: okay, what's up?
[21:50:50] <Sean_McG> astrange: git bisect should help with that
[21:52:13] <astrange> bisect only travels across history and there are both mainline and mt breakages across history, so i think it's a bit confusing
[21:52:24] <astrange> but bisecting now vs. 2007 on one sample might work
[21:55:47] <siretart> lu_zero: please e-mail
[22:01:25] <lu_zero> siretart: I sent one few hours ago
[22:02:21] <siretart> oh, about fosdem?
[22:02:28] <lu_zero> yup
[22:02:35] <lu_zero> we are going short on rooms ^^;
[22:02:53] <siretart> aah, right. so did you already book the room?
[22:03:01] <lu_zero> nope
[22:03:12] <siretart> ok, now I understand the email
[22:03:13] <mru> where are you staying?
[22:03:17] <lu_zero> I wrote in the email that was about and wanted to heard from you.
[22:03:30] <lu_zero> mru: your hotel IF we don't lose the last triple ^^;
[22:05:35] <siretart> lu_zero: I still have to figure out how to get to fosdem. either I drive with stefan again, or I take the train
[22:05:53] <_av500_> siretart: there is a fftrain via aachen
[22:06:25] <siretart> _av500_: does it start in southern germany?
[22:06:42] <_av500_> siretart: no idea
[22:06:53] <_av500_> but one can switch trains :)
[22:07:42] <thresh> speaking of which, you guys all chose that st nicolas hotel?
[22:07:51] <siretart> lu_zero: so you basically need to know if I'm attending and I'm up to share a room, and this today, right?
[22:08:08] <lu_zero> mostly
[22:08:35] <siretart> hm. I'd really prefer to defer that for tomorrow, I have a student that considers joining, but is also undecided, and I have to check with stefan if he has room in his car
[22:08:49] <lu_zero> or I can pick the triple and stuff a random third once is available
[22:09:01] <_av500_> siretart: 6h from erlangen
[22:09:12] <_av500_> and you switch into the fftrain too :)
[22:09:21] <siretart> av500: what is fftrain?
[22:09:34] <_av500_> the ice14 that leaves aachen at 16:20
[22:09:39] <_av500_> with jannau and me
[22:09:45] <jannau> ice passing achen friday at 16:20
[22:10:21] <_av500_> siretart: from erlangen its 2x train change, so DB lottery... :(
[22:10:41] <_av500_> hopefully the weather is not extremely mild
[22:11:10] <siretart> there seems to be a connection 11:19 Er / 12:00 Nue -> 17:27 Bruessel
[22:11:30] <siretart> with some luck, that could be the fftrain
[22:11:45] <_av500_> thats the one
[22:11:51] <_av500_> midi as 17:35
[22:11:53] <Dark_Shikari> ok guys, I need adjective suggestions
[22:12:01] <_av500_> awesome
[22:12:07] <siretart> hm. sounds like another reason to take the train
[22:12:08] <Dark_Shikari> our rule is, every time we send out an x264 dev newsletter, we add two words (usually adjectives) to the following paragraph:
[22:12:12] <Dark_Shikari> Work is planned to integrate x264 with the Sandy Bridge's encoding
[22:12:14] <Dark_Shikari> ASIC for improved encoding performance.  Current status is: waiting on
[22:12:17] <Dark_Shikari> Intel (these guys move at the speed of a paraplegic three-toed sloth swimming
[22:12:20] <Dark_Shikari> down a frozen river of bricks while chained to an osmium anchor).
[22:12:21] <mru> gcc is hilarious
[22:12:23] <Dark_Shikari> Need suggestions on ones to add.  I've covered all the obvious bases so far.
[22:12:37] <Sean_McG> mru: hm?
[22:12:45] <mru> in a trivial function, it pushes a register to stack, puts a value in it, does nothing, and pops it back
[22:12:54] <Sean_McG> oh, heheh
[22:12:57] <_av500_> mru: it was cleaning it
[22:12:58] <jannau> Dark_Shikari: add "at 0 degree kelvin"
[22:13:02] <lu_zero> Dark_Shikari: the wind
[22:13:13] <siretart> lu_zero: so you're booking the triple room and have no roommate yet? is that correct?
[22:13:18] <lu_zero> add the wind direction
[22:13:22] <Sean_McG> D_S: so commitstorm today?
[22:13:25] <Dark_Shikari> Sean_McG: yes
[22:13:28] <Sean_McG> k
[22:13:30] <Dark_Shikari> "a river of bricks frozen in solid hydrogen"?
[22:13:50] <mru> s/hydrogen/helium/
[22:13:56] <lu_zero> siretart: I was about to book the double (there are still some left)
[22:13:58] <Dark_Shikari> ... helium doesn't freeze
[22:14:03] <mru> that's the point
[22:14:04] <_av500_> chromium?
[22:14:08] <lu_zero> and there is a single triple
[22:14:41] <Dark_Shikari> Current status is: waiting on
[22:14:41] <Dark_Shikari> Intel (these guys move at the speed of a paraplegic three-toed sloth swimming
[22:14:44] <spaam> Dark_Shikari: at 0 K it will..
[22:14:44] <Dark_Shikari> down a river of bricks covered in frozen helium while chained to an osmium anchor).
[22:14:44] <siretart> lu_zero: I'm pretty sure that I'm coming, and I'd be happy to stay with you
[22:14:47] <Dark_Shikari> spaam: nope
[22:14:49] * mru goes to write that function in asm instead
[22:14:52] <lu_zero> ok then it's set
[22:14:54] <siretart> ah, damn it, I wil somehow make it to brussels
[22:15:00] <saintdev> river of frozen helium ?
[22:15:06] <lu_zero> monday or not monday?
[22:15:19] <spaam> Dark_Shikari: are you sure?
[22:15:21] <siretart> boah, next difficult question.
[22:15:27] <saintdev> nah, that doesn't work
[22:15:28] <Dark_Shikari> yes
[22:15:44] <Dark_Shikari> Current status is: waiting on
[22:15:44] <Dark_Shikari> Intel (these guys move at the speed of a paraplegic three-toed sloth swimming
[22:15:47] <Dark_Shikari> better!
[22:15:50] <Dark_Shikari> down a river of frozen helium while chained to an osmium anchor stuck inside a black hole).
[22:15:51] <siretart> I'd rather prefer not monday
[22:16:01] <saintdev> lol
[22:17:39] <Sean_McG> hahahahah
[22:17:44] <Dark_Shikari> spaam:
[22:17:45] <Dark_Shikari> Unlike any other element, helium will remain liquid down to absolute zero at normal pressures. This is a direct effect of quantum mechanics: specifically, the zero point energy of the system is too high to allow freezing. Solid helium requires a temperature of 1–1.5 K (about −272 °C or −457 °F) and about 25 bar (2.5 MPa) of pressure.
[22:18:34] <siretart> lu_zero: sorry, I need to leave now, please let's continue this tomorrow.
[22:18:36] <siretart> cu!
[22:18:40] <lu_zero> ok
[22:24:24] <ruggles> argh! codecs' use of float_to_int16_interleave is such a mess!
[22:25:10] <mru> let's ditch the bias hack first
[22:25:16] <mru> should simplify matters significantly
[22:25:21] <mru> then we only have scale to think of
[22:25:34] <andoma> yes
[22:25:54] <ruggles> will that slow down the C version?
[22:25:59] <andoma> yes
[22:26:05] <ruggles> enough to matter?
[22:26:08] <mru> measurably?
[22:26:14] <Sean_McG> any word on the roundup error yet?
[22:26:18] <mru> on hardware with an fpu
[22:26:25] <lu_zero> trying is the only way to check
[22:26:27] <mru> softfloat is irrelevant
[22:26:28] <lu_zero> Sean_McG: which error?
[22:26:31] <_av500_> Sean_McG: routing afaik
[22:27:47] <Sean_McG> "content file for /var/db/roundup/ffmpeg/db/files/msg12681 not found" <-- this is routing related?
[22:28:19] <ruggles> my plan was to put mul/add bias in FmtConvertContext so they could be used directly instead of comparing function pointers. removing add bias would certainly make it somewhat simpler.
[22:29:02] <mru> bias/scale should obviously be provided explicitly
[22:29:09] <mru> but we might drop bias
[22:29:45] <andoma> i'm just thinking.. if speed is critical, why are you using a C-only version anyway?
[22:29:59] <ruggles> you don't have anything else?
[22:30:27] <_av500_> ruggles: like on a pen and paper computer?
[22:30:45] <andoma> yeah but then perhaps you should switch hardware
[22:32:02] <lu_zero> Sean_McG: I'm afraid that somebody got "luckily and commited something while that poor server was advised to route his packets through halfway the italian inner network and back
[22:33:21] <andoma> i just think it's just plain wrong for FFmpeg to jump thru loops to optimize for the C only case
[22:33:39] <lu_zero> (in short, roundup is nas backed on an IX, yesterday something got the wrong bgp informations and rerouted to hell most of the packets
[22:33:43] <lu_zero> )
[22:34:04] <lu_zero> andoma: I'd like to have the C as fast as possible w/out losing sanity
[22:34:09] <mru> any fpu has a fast float to int conversion instruction
[22:34:15] <Sean_McG> ahhh, so yeah if it's a network filesystem then that makes sense
[22:34:22] <mru> probably faster than that hack
[22:34:31] <BBB> astrange: I'll likely just run two instances in the debugger, one good and one bad, and compare variables
[22:34:57] <lu_zero> Sean_McG: so the file either got lost between the server and the nas or also between the sender and the server...
[22:35:06] <Sean_McG> fair point
[22:35:10] <_av500_> lu_zero: maybe the file is still "out there"
[22:35:14] * Sean_McG *assumed* it was a local fs
[22:36:03] <mru> _av500_: next to the truth
[22:36:25] <lu_zero> I put roundup on nas to make it grow as needed
[22:36:31] <ruggles> i vaguely remember mru saying something about some systems taking a huge percentage of time in format conversion.
[22:37:29] <mru> ruggles: that's why we write asm
[22:38:09] <ruggles> so what systems was that? or was that before the arm optimized float_to_int16_*?
[22:38:44] <Dark_Shikari> Here's the general rule:
[22:38:54] <Dark_Shikari> if you have no hardware FPU
[22:39:03] <Dark_Shikari> your decoder that generates the float code will be intolerably slow
[22:39:26] <Dark_Shikari> er, float data
[22:39:43] <Dark_Shikari> So... it's pointless to optimize float_to_int16_t for sytsems without an fpu.
[22:42:58] <Flameeyes> I assume *_(de)?muxer in libavformat/libavdevice should follow the same rule as libavcodec's stuff, right?
[22:44:13] <mru> yes
[22:44:37] <mru> but how does the matching work?
[22:44:45] <mru> is it first match or last match?
[22:44:50] <mru> or something else entirely?
[22:45:30] <Flameeyes> I think it's greedy stuff
[22:45:52] <Flameeyes> I know the common form is to provide a specific list in global: and then set local: *;
[22:48:05] <mru> ld info page sucks
[22:48:56] <Flameeyes> mru: ld info man page about the subject tend to lie as well
[22:49:12] <Flameeyes> _protocol as well?
[22:49:23] <mru> damn manual only says what not to do
[22:49:29] <mru> yes
[22:50:01] <BBB> astrange: for one of the testsuite files, two frames disappear, but the other frames are identical... does your code do anything w.r.t. framedropping or framedupping or so?
[22:50:36] <mru> BBB: always use -strict 1 -vsync 0
[22:50:51] <BBB> I do
[22:50:56] <BBB> even so it drops the first two frames
[22:53:09] <Flameeyes> mru: why I have a bad feeling about "s->informat == &ff_mpegts_demuxer"?
[22:53:34] <mru> same reason I get a bad feeling about that
[22:53:44] <astrange> no. hold on a sec and i'll tell you some things to printf()
[22:54:05] <Flameeyes> mru: equality tests between iformat and oformat seem to be all over the place :(
[22:54:30] <mru> lavf is a mess
[22:56:05] <lu_zero> interesting fact -std=c99 seems to trigger __STRICT_ANSI__ in certain compilers...
[22:56:15] <Flameeyes> lu_zero: surprised?
[22:56:28] <mru> that's correct
[22:56:31] <Sean_McG> aye
[22:56:43] <mru> it's various headers that are buggy
[22:56:56] <andoma> yup, it screws up with newlib pretty badly :(
[22:57:13] <mru> that's because someone confused syntax with symbols
[22:57:38] <mru> -std=foo is for choosing which language syntax to use
[22:57:51] <mru> library feature selection is done with -D_FOO_SOURCE
[22:58:00] <BBB> astrange: ?
[22:58:12] <BBB> astrange: I'm waiting :-p
[22:58:18] <astrange> had to move rooms
[22:58:19] <Flameeyes> mru: doesn't c99 also specify certain library interfaces?
[22:58:20] <Sean_McG> FOO being one of either POSIX, XOPEN, or what have you
[22:58:31] <lu_zero> Flameeyes: somebody assumes __STRICT_ANSI__ means --ansi
[22:58:34] <mru> Flameeyes: yes, so?
[22:58:54] <Flameeyes> mru: well, those should be enabled by -std=c99 anyway :) and those tend to be symbols as well
[22:58:58] <lu_zero> so you lose about all c99 in a batch
[22:59:05] <lu_zero> and yes
[22:59:34] <astrange> in avcodec_decode_video2 or its caller in the client, print AVFrame.coded_picture_number
[22:59:42] <lu_zero> newlib is the culprit
[23:00:33] <mru> Flameeyes: system headers should expose standard C by default, more of requested with -D_POSIX_C_SOURCE etc
[23:00:44] <mru> the standard headers, that is
[23:00:58] <astrange> and in h264 print H264Context.outputed_poc and (in mt only) H264Context.next_output_pic->coded_picture_number
[23:00:59] <mru> if a non-standard header is included, all bets are already off
[23:01:13] <Flameeyes> okay hiding symbols on libavformat at least seem to have a better effect on percentage
[23:01:17] <astrange>  / -> poc
[23:01:20] <astrange> that should help
[23:01:52] <astrange> the major change here is i moved a lot of code into a function decode_postinit(). i guess there could be a merge glitch there
[23:02:00] <Flameeyes> since it reduces symbols from 699 to 451
[23:02:27] <BBB> astrange: working on it
[23:07:16] <BBB> astrange: looks bad
[23:07:23] <BBB> astrange: it outputs images in the wrong order, I think
[23:07:47] <BBB> basically first few calls to decode_frame() in h264 are all outputed_poc=0
[23:08:07] <BBB> then after a while it skips up, avcodec_decode_video() returns data and then it's like this:
[23:08:13] <BBB> 0,4,5,3,7,8
[23:08:33] <BBB> (that's the order of numbers after subsequent calls to avcodec_decode_video()
[23:08:34] <BBB> )
[23:09:35] <BBB> astrange: 1 and 2 are missing and never occur in return calls from avcodec_decode_video()
[23:09:38] <BBB> astrange: whatever that means
[23:10:05] <astrange> poc is decode order, not display order. i think
[23:10:15] <astrange> the two decoders just have to match
[23:11:34] <BBB> I see, let me see
[23:11:55] <Dark_Shikari> no
[23:12:10] <mru> poc is monotonically increasing in display order
[23:12:16] <mru> but it's allowed to skip
[23:12:20] <Dark_Shikari> wrong
[23:12:30] <mru> what then?
[23:12:30] <Dark_Shikari> poc is required to increase 1 with each field
[23:12:39] <mru> did they finally fix the spec?
[23:12:39] <Dark_Shikari> 1, only 1, exactly 1
[23:12:43] <Dark_Shikari> so, 2 per frame
[23:12:59] <mru> that used to be the topic of endless debate
[23:13:06] <BBB> astrange: recompiling, give me a minute, don'trun anywhere
[23:13:30] <Dark_Shikari> frame num can have gaps
[23:13:31] <Dark_Shikari> poc can't
[23:13:34] <Dark_Shikari> AFAIK
[23:13:51] <mru> around 2004 everybody was doing it differently
[23:14:31] <Dark_Shikari> :/
[23:14:52] <mru> back when I was hacking on x264
[23:15:22] <Dark_Shikari> You should come do that again.
[23:15:25] <Dark_Shikari> We have tons of cool stuff to do.
[23:16:04] <BBB> astrange: no, bad
[23:16:14] <BBB> astrange: original, output is 1,2,0,4,5,3
[23:16:20] <BBB> astrange: mt output is 0,4,5,3
[23:16:22] <BBB> etc.
[23:16:28] <BBB> do you want the input of outputed_poc also?
[23:16:35] <Dark_Shikari> Why should mt output be different?
[23:16:39] <Dark_Shikari> x264 doesn't output frames in a different order.
[23:16:42] <Dark_Shikari> because of its mt
[23:16:42] <astrange> bugs
[23:16:46] <astrange> this is with mt turned off
[23:17:12] <mru> Dark_Shikari: nah, I don't like your coding style
[23:17:23] <mru> if ( foo ) eeeed
[23:17:24] <mru> eek
[23:17:33] <mru> sorry, i_foo
[23:17:33] <BBB> mt: 19x0,2,4,6; original: -2147483648x16,-4, -2, 0, 2, 4, 6
[23:17:45] <BBB> astrange: i.e. it appears to not handle negative poc values very well?
[23:17:49] <BBB> it truncates them to zero
[23:17:59] <BBB> and I guess then discard the frame
[23:18:11] <mru> is that INT_MIN?
[23:18:14] <BBB> yes
[23:18:56] <BBB> astrange: is this useful or do you  need more debug info?
[23:19:00] <Dark_Shikari> mru: we got rid of hungarian
[23:19:05] <Dark_Shikari> or, at least, new code doesn't have it.
[23:19:09] <astrange> that's getting close to it
[23:19:09] <BBB> if( foo ) is indeed weird
[23:19:13] <Dark_Shikari> if( foo ), not if ( foo )
[23:19:21] <Dark_Shikari> anyways, spacing style is not really a reason not to work on code
[23:19:22] <astrange> i need to move again and get the laptop power adapter to look
[23:19:27] <Dark_Shikari> ffmpeg, vlc, and x264 are all fine
[23:19:28] <astrange> is -debug mmco the same in both?
[23:19:30] <BBB> astrange: omg get a home :-p
[23:19:31] <Dark_Shikari> derf's code: NOT FINE.
[23:19:36] <Dark_Shikari> (i.e. celt)
[23:19:52] <BBB> astrange: I'm going home, email me if you need more or leave me a message in this irc bouncer thing
[23:19:56] <BBB> astrange: I'll read it later
[23:20:00] <astrange> i can look
[23:20:04] <astrange> just tell me the sample name, i forgot it
[23:20:23] <Dark_Shikari> mru: you're giving shitty excuses btw =p
[23:20:29] <BBB> ffmpeg -v 0 -vsync 0 -strict 1 -i /Users/ronaldbultje/Movies/fate-suite/h264-conformance/CAMA1_TOSHIBA_B.264 -f framemd5 -
[23:20:44] <mru> Dark_Shikari: I know
[23:20:44] <BBB> aka make fate-h264-conformance-cama1_toshiba_b
[23:20:48] <mru> but seriously, I have no time
[23:20:55] <Dark_Shikari> you have to time to bitch on irc all day =p
[23:21:01] <Sean_McG> lol
[23:21:06] <mru> I'm doing work at the same time
[23:21:17] <mru> right now I'm being paid to work on ffmpeg
[23:21:28] <Dark_Shikari> true, you're getting paid by the hour~
[23:22:14] <mru> I'm actually a rather generous fixed-price contract right now
[23:23:24] <lu_zero> Dark_Shikari: how's celt now?
[23:24:01] <Dark_Shikari> what about it
[23:24:07] <Dark_Shikari> they seem to be panicking about getting it done in time for opus mainly
[23:24:23] <Dark_Shikari> which is important because it hardcodes so much stuff in the bitstream format
[23:26:38] <jannau> mru: http://lists.ozlabs.org/pipermail/patchwork/2011-January/000369.html
[23:27:24] <lu_zero> ugh
[23:27:31] <lu_zero> so celt2 might be sane
[23:27:34] <lu_zero> not celt
[23:27:41] <mru> jannau: would work for me
[23:32:07] <Sean_McG> ahhh mail-archive.com has the emails for this issue, cool
[23:36:10] <mru> BBB: does the vp8 idct overflow 16 bits?
[23:37:57] <Dark_Shikari> no
[23:38:18] <mru> other than those multiplications that use only the high half
[23:40:47] <mru> BBB: btw, some vp8 emu-edge tests are failing on sparc64/bsd
[23:44:02] <Sean_McG> someone forget about big-endianness?
[23:44:35] <mru> works on ppc
[23:44:53] <mru> except some gcc versions
[23:45:33] <mru> and sparc64/linux works
[23:46:07] <Flameeyes> sparc64/bsd -> fbsd?
[23:46:12] <mru> open
[23:46:22] <Flameeyes> k
[23:46:41] <Flameeyes> was going to say that fbsd used to throw sigbus more often wrt unaligned load because gcc assumed the OS dealt with that
[23:47:36] <mru> we take care not to do any unaligned loads needing fixup