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

[irc at mansr.com]

[03:22:24] <CIA-38> ffmpeg: David Fries <David at Fries.net> master * r00952be424 ffmpeg/libavformat/udp.c:
[03:22:24] <CIA-38> ffmpeg: udp: Enable address reuse by default for multicast
[03:22:24] <CIA-38> ffmpeg: Keep the original corner case behaviour, where reuse is enabled
[03:22:24] <CIA-38> ffmpeg: for the case where no argument is given to the reuse url option.
[03:22:24] <CIA-38> ffmpeg: Signed-off-by: Martin Storsjö <martin at martin.st>
[03:22:24] <CIA-38> ffmpeg: Signed-off-by: Ronald S. Bultje <rsbultje at gmail.com>
[05:04:42] <Dark_Shikari>   5eb85d:       f3 ab                   rep stos dwordes:[edi],eax
[05:04:51] <Dark_Shikari> FFFFFFFFFFFFFFF gcc why are you using rep stos to store 16 BYTES.
[05:19:47] <saintdev> Dark_Shikari just got trolled by gcc
[05:28:21] * Sean_McG sighs
[05:28:32] <Sean_McG> I wish I could defend gcc, but I can't
[05:36:59] <saintdev> gcc says "Dark_Shikari: trollface.jpg"
[06:17:37] <elenril> morning
[06:18:08] <thresh> moroning
[06:19:35] <Sean_McG> Thu Feb 10 01:19:35 EST 2011
[06:19:42] <Sean_McG> wee smalls
[06:20:00] <thresh> EST == Estonian time?
[06:20:21] <elenril> Sean_McG: your time is broken
[06:22:27] <_av500_> thresh: didnt you switch to PCT? putin central time?
[06:25:01] <thresh> _av500_: it's medvedev northern time, MNT
[06:25:45] <elenril> wait, doesn't MNT mean....
[06:38:54] <thresh> ....what?
[06:39:50] <elenril> the evil overlord timezone
[06:40:12] <thresh> oh lol
[06:42:03] <spaam> god morgon :D
[06:57:36] <elenril> o_0 long subject is long
[06:58:54] <Dark_Shikari> elenril: Accidentally put it on one line
[06:59:08] <Dark_Shikari> git doesn't like it unless you put an extra line break between subject and commit message
[06:59:49] <elenril> i thought it also rejects overlong subjects
[06:59:52] <elenril> apparrently not
[07:51:28] <lu_zero> good morning
[08:08:45] <cartman> moin
[08:26:06] <elenril> what's the purpose of index_built in AVFormatContext?
[08:26:26] <elenril> git grep says it's not touched by any code in ffmpeg
[08:27:37] <elenril> ....and the code setting it was removed 2 years ago
[08:27:48] <elenril> so i guess i'll go ahead and deprecate it
[08:27:50] * bilboed-tp hands elenril the broom
[08:30:49] <av500> elenril: about the seek in asf
[08:31:03] <av500> you now added the url_is_streamed() check
[08:31:29] <DonDiego> elenril: nice to see you on a roll :)
[08:31:54] <av500> elenril: ok, forget it :)
[08:31:55] <elenril> DonDiego: exams!
[08:32:17] <av500> elenril: but you now still delay asf startup time on a slow http link
[08:41:13] * elenril kicks his isp
[08:41:18] <elenril> what did i miss?
[08:41:30] <spaam> elenril: nothing!
[08:41:34] <lu_zero> hi superdump
[08:41:46] <superdump> morning
[08:43:09] <elenril> av500: so what did you want to know?
[08:43:55] <av500> see ml
[08:44:26] <elenril> :/
[08:44:50] <av500> [09:32:17] <av500> elenril: but you now still delay asf startup time on a slow http link
[08:46:37] <elenril> well with current code you get the same delay on first seek
[08:46:44] <elenril> which is worse imo
[08:46:57] <wbs> except if you never seek
[08:47:20] <wbs> OTOH, if you want fast startup, you can set the IGNIDX flag
[08:47:59] <elenril> i admit that i don't do streaming much
[08:48:06] <elenril> so i'll leave it up to your judgment
[08:49:20] <av500> elenril: over here, I read avi and asf index in a separate thread :)
[08:49:40] <av500> wbs: but with IGNIDX you have no index at all, no?
[08:49:57] <wbs> no idea, but with that flag, the code elenril added isn't invoked at least
[08:50:04] <av500> true
[08:58:39] <elenril> and what's the purpose of AVFormatContext.packet_size?
[08:59:07] <elenril> it seems it's only used by a few de/muxers
[08:59:51] <elenril> is it useful to the users?
[09:07:06] <elenril> ....actually only mpegenc uses the user-supplied value
[09:07:28] <elenril> maybe it should be turned into a muxer-specific AVOption
[09:07:57] <bilboed-tp> for mpeg-ts maybe ?
[09:08:08] <astrange> it should be useful for anything used in the same situations as mpeg-ts
[09:08:10] <av500> ps, no?
[09:08:19] <astrange> but i guess people just use ts for everything?
[09:08:39] <av500> yes, apple uses it to stream mov :)
[09:10:39] <av500> mpegenc is the ps muxer, not the ts one
[09:11:31] <av500> ffmpeg.c does not set that value either
[09:13:34] <lu_zero> hi Flameeyes
[09:14:16] <Flameeyes> hi lu_zero
[09:14:22] * Flameeyes hopes quassel won't suicide again
[09:14:22] <DonDiego> bilboed-tp: hey, what version of ffmpeg does gstreamer use?
[09:14:31] <av500> Flameeyes: http://www.twoflavours.com/blogimages/dymowaxseal/DSC_0021.jpg
[09:14:31] <Flameeyes> care to tell me why you haven't answered skype?
[09:14:51] <bilboed-tp> DonDiego, in git we bumped to the last svn revision (still using the svn repo)
[09:14:58] <bilboed-tp> DonDiego, let me check what the last release uses
[09:15:01] <lu_zero> I guess skype ate you message...
[09:15:15] <Flameeyes> av500: heh old-style dymo :) I remember seeing those a long time ago — they also were bloody expensive :D
[09:15:17] <lu_zero> since I don't even see you up...
[09:15:36] <Flameeyes> terrific
[09:15:48] <Flameeyes> lu_zero: [OT] have you looked at the feng man pages?
[09:15:58] <bilboed-tp> DonDiego, 23623 for the last release
[09:15:59] <bilboed-tp> DonDiego, from the 0.6 branch
[09:16:09] <DonDiego> ok, thx
[09:21:47] <kshishkov> DonDiego: http://stallman.org/articles/xemacs.origin
[09:22:46] <DonDiego> kshishkov: any particular reason to point that out to me now? i know about the emacs split in general...
[09:24:25] <kshishkov> DonDiego: it's just funny and reminds me of other split
[09:25:06] * Flameeyes tries to guess whether lu_zero is still awake or fell asleep
[09:27:31] <superdump> narcolepsy
[09:27:52] <Flameeyes> superdump: nah it's more that Luca lives on his own timezone most of the time
[09:28:02] <Flameeyes> well I do much the same as well..
[09:40:30] <kshishkov> mate!
[09:42:03] <pross-au> gday
[09:43:05] <kshishkov> BTW, I should remind you that there are no people with game codec experience so your patch won't be reviewed
[09:44:15] <pross-au> Aye
[09:49:14] <elenril> also when the review is finished, there will be cake
[10:00:11] <Flameeyes> mru: list of software using libav* in Gentoo: http://paste.pocoo.org/show/335605/
[10:01:11] <Flameeyes> the only one looking fishy is wxsvg but it uses _all_ the libs anyway
[10:01:11] <av500> wow, ffplay
[10:01:28] <cartman> av500: a recent ruling in Munich court says Turks can stay in Germany for 3 months without a visa
[10:01:37] <cartman> you'll be happy to hear that :P
[10:01:37] <av500> cartman: and?
[10:01:54] <cartman> more döner with horse meat!
[10:04:04] <astrange> Flameeyes: doesn't detect mplayer
[10:05:57] <jannau> astrange: mplayer uses probably a private copy
[10:08:09] <cartman> absolutely it does
[10:08:10] <jannau> Flameeyes: can you create seperate lists for libavutil and libavcodec? and libavcore for the lulz?
[10:08:11] <astrange> yes, but if the list is used to check private API use then mplayer still counts as a client
[10:08:44] <kshishkov> as an abuser
[10:09:06] <Flameeyes> astrange: not used for that, more for identify who links to libavcore :P
[10:09:25] <Flameeyes> jannau: I can give you the raw data that include the needed entries
[10:09:54] <peloverde> the list is missing audacity (dlopens ffmpeg)
[10:09:58] <jannau> astrange: I think mru asked for something that uses libavutil bit not any other lib
[10:10:01] <Flameeyes> jannau: http://paste.pocoo.org/show/335612/
[10:10:14] <Flameeyes> peloverde: this is a list of NEEDED entries, no dynamic link involved obviously
[10:10:39] <peloverde> ok
[10:11:01] <Flameeyes> and tbh, bundled copies and dynamic links are not exactly high on my priority list of things to keep from breaking
[10:11:16] <Flameeyes> sorry let me qualify
[10:11:46] <Flameeyes> _unavoidable_ bundled copies and dynamic links
[10:13:16] <jannau> mediatomb uses libavformat without libavcodec
[10:13:20] <siretart> peloverde: IIRC there is someone in Debian's pkg-multimedia team working on a patch to make audacity link dynamically against libavcodec
[10:13:34] <siretart> jannau: impossible, as libavformat links against libavcodec
[10:13:36] <Flameeyes> siretart: you mean statically I guess
[10:13:46] <siretart> Flameeyes: I mean without dlopen
[10:13:54] <Flameeyes> siretart: then you mean static link to dynamic library :)
[10:14:03] <pross-au> libavgrabbag?
[10:14:08] <siretart> now you confuse me
[10:14:50] * elenril thinks Flameeyes likes confusing people with his advanced elf-fu
[10:15:23] <jannau> siretart: iKnow. from Flameeyes raw data: libmysqlclient_r.so.16,libz.so.1,libpthread.so.0,libtag.so.1,libmozjs.so,libmagic.so.1,libexif.so.12,libavformat.so.52,libavutil.so.50,libexpat.so.1,libmp4v2.so.1,libcurl.so.4,libstdc++.so.6,libgcc_s.so.1,libc.so.6  /usr/bin/mediatomb
[10:15:45] <Flameeyes> siretart: -Bstatic -lfoo → static link to static library (libfoo.a); -Bdynamic -lfoo → static link to dynamic library (libfoo.so); dlopen("libfoo.so") → dynamic link to dynamic library
[10:16:17] <siretart> Flameeyes: yeah, I see.
[10:16:45] <{V}> how is linking to libavcodec at buildtime an improvement over using dlopen
[10:16:50] <jannau> ok, there's no standalone user of libavutil in Flameeyes set
[10:17:26] <Flameeyes> {V}: it's resolved at startup rather than further down the road, PLT is updated at once, and whether it forks before or after dlopen() it doesn't have to CoW it
[10:18:03] <Flameeyes> and in both Debian's and Gentoo's cases is easier to make sure that it is linked to the latest version of ffmpeg
[10:18:16] <pross-au> {V}: the program can choose to function, even if the library is missing
[10:19:00] <{V}> pross-au, err.. that's when using dlopen. Not when linking at buildtime.
[10:19:12] <Flameeyes> pross-au: that's quite relative, it works fine for universal binary cases, but in Gentoo it's just an extra cost for no good reason
[10:20:04] <pross-au> ah okay
[10:41:42] <kierank> spaam: committed any libavseq changes yet
[10:43:07] <kierank> I'm suddenly reminded of bastycdgs insistence of calling every email to the ml a "commit"
[10:44:14] <wbs> kierank: argh, that was annoying :-)
[10:47:47] <av500> kierank: patch commited to mailing list
[10:49:21] <kierank> damn should have asked bcoudurier about -708 while he was awake
[10:51:09] <spaam> kierank: no =/
[10:51:10] <kierank> av500: that phrase is very confusing
[10:51:36] <av500> kierank: tell basty
[10:52:31] <spaam> wbs: klart du vill ha avseq ;D
[10:52:49] <spaam> wbs: you will be the number one commiter ;)
[10:53:20] <wbs> spaam: ugh ;P
[10:54:37] <spaam> wbs: and you are welcome to join our crew CDGS with  basty, me and kierank ;)
[10:54:56] <kierank> spaam: only as an associate member
[10:55:02] <spaam> ofc
[10:55:21] <kierank> needs further amiga training before becoming a provisional member
[10:55:34] <kierank> then a course in "optimisations" to become a full member
[10:56:51] <kierank> the full title is "optimising useless codecs"
[10:57:28] <spaam> wbs: you like that title? ;)
[10:57:49] <wbs> spaam: I'm delighted
[10:57:53] <kshishkov> i.e. rewriting C code into slightly optimised 68k ASM
[10:58:33] <kierank> why write in C when you can write in ASM
[10:59:26] <kshishkov> because C code exists
[11:00:21] <kierank> kshishkov: pssh you're never going to become a full CDGS member with that attitude
[11:00:31] <kshishkov> not that I case
[11:00:34] <kshishkov> *care
[11:01:48] <cartman> CDGS?
[11:02:44] <j-b> 'moroning
[11:02:45] <kierank> Coders Design Glorious Software or something like that
[11:03:38] <kshishkov> j-b: still in Berlin?
[11:04:00] <kshishkov> j-b: which is twinned with Bruxelle if you don't know
[11:04:58] <kierank> kshishkov: I have met a second ukranian who has left because of dislike of his homeland
[11:06:14] <j-b> kshishkov: I am back
[11:06:38] <kshishkov> kierank: where? (and who was the first one?)
[11:06:43] <kshishkov> j-b: congrats!
[11:07:00] <kierank> kshishkov: well first then since i haven't technically met you
[11:07:10] <kshishkov> j-b: though I suspect Paris is similar to them both
[11:07:14] <kierank> kshishkov: a friend of a friend
[11:08:50] <kierank> j-b: will computermodules send me an sdi card if I ask for one?
[11:09:37] <kshishkov> kierank: if your credit card asks then maybe
[11:10:05] <j-b> kierank: I doubt it. but ask
[11:10:18] <j-b> kierank: less cold
[11:10:24] <kierank> my current sdi card only works on linux :/
[11:10:26] <kierank> i mean windows
[11:10:53] <j-b> kshishkov: less cold
[11:10:57] <j-b> kshishkov: decklink?
[11:11:14] <kierank> j-b: osprey
[11:15:49] <lu_zero> j-b: decklink works ok on linux
[11:16:02] <lu_zero> btw remind me to stab the player patch for vlc as well
[11:16:17] <j-b> stab?
[11:16:18] * lu_zero currently made some quite bare player
[11:16:35] <lu_zero> j-b: shape it up if it hadn't been already fixed
[11:16:54] <kierank> lu_zero: that's the one with the c++ driver?
[11:17:02] <j-b> kierank: yes
[11:17:13] <j-b> lu_zero: no idea if it has been improved, indeed
[11:27:54] <CIA-38> ffmpeg: Anton Khirnov <anton at khirnov.net> master * rd42b09723e ffmpeg/libavformat/asfdec.c:
[11:27:54] <CIA-38> ffmpeg: asfdec: move DAR list to ASFContext
[11:27:54] <CIA-38> ffmpeg: This will be useful for splitting asf_read_header()
[11:27:54] <CIA-38> ffmpeg: Signed-off-by: Ronald S. Bultje <rsbultje at gmail.com>
[11:28:06] <CIA-38> ffmpeg: Anton Khirnov <anton at khirnov.net> master * r7c7253802b ffmpeg/libavformat/asfdec.c:
[11:28:06] <CIA-38> ffmpeg: asfdec: use an ASFContext array for storing stream bitrates
[11:28:06] <CIA-38> ffmpeg: This will be useful for splitting asf_read_header()
[11:28:06] <CIA-38> ffmpeg: Signed-off-by: Ronald S. Bultje <rsbultje at gmail.com>
[11:30:59] <kierank> erm a bit delayed
[11:32:29] <Dark_Shikari> BBB: patch review please
[11:32:45] <BBB> Dark_Shikari: the bottom part is unrelated
[11:32:54] <BBB> (I was already looking at it)
[11:34:47] <BBB> Dark_Shikari: it's a little difficult to see what you did because you moved the function, what's the difference?
[11:34:48] <Dark_Shikari> That was an accident, it'll be removed from the real patch.
[11:34:51] <Dark_Shikari> It was some hacky code in it
[11:34:57] <Dark_Shikari> because read_time wasn't being inlined
[11:34:59] <Dark_Shikari> just testing
[11:35:28] <BBB> it inlines the get_prob() things in the decode_mv() (what used to be find_near_mv()) function so that some steps are only done when they are necessary
[11:35:29] <BBB> ?
[11:35:34] <Dark_Shikari> on a related note, we need to inline av_clip_c
[11:35:37] <Dark_Shikari> er, always_inline
[11:35:40] <Dark_Shikari> yes
[11:35:50] <Dark_Shikari> basically previously we did:
[11:35:50] <av500> peloverde_: and we have that API/ABI breaking reputation to live up to, no?
[11:35:51] <Dark_Shikari> 1) all mv pred
[11:35:53] <Dark_Shikari> 2) all decoding
[11:35:55] <Dark_Shikari> now we do
[11:36:03] <Dark_Shikari> 1) the bare minimum mv pred required to decode the CNT_ZERO bit
[11:36:06] <Dark_Shikari> 2) CNT_ZERO bit
[11:36:12] <Dark_Shikari> 3) the bare minimum required to decode CNT_NEAREST
[11:36:15] <Dark_Shikari> 4) CNT_NEAREST
[11:36:16] <Dark_Shikari> etc
[11:36:25] <Dark_Shikari> So we postpone everything as late as possible.
[11:36:28] <BBB> Dark_Shikari: yeah, you mentioned that yesterday, please send a patch :-p I Can't believe it's not inlined, typical gcc...
[11:36:43] <Dark_Shikari> It's not inlined because the file has so many inline functions
[11:36:48] <Dark_Shikari> that it triggers the maximum inlining threshold
[11:36:52] <Dark_Shikari> ... this might be fixed on recent gcc.
[11:36:55] <Dark_Shikari> I'm using 4.3.4
[11:37:11] <Dark_Shikari> Anyways, I fixed that random shit that got in the patch
[11:38:15] <Dark_Shikari> there might be some optimization that can be done of MV_EDGE_CHECK.
[11:38:17] <BBB> I'm just teasing about that part :-p
[11:38:36] <Dark_Shikari> I still don't like having to manually zero all the stuff at the start.
[11:38:49] <Dark_Shikari> Oh yeah, and gcc used "rep stos" to zero near_mv originally.
[11:38:53] <Dark_Shikari> aka "ARE YOU CRAZY"
[11:39:02] <Dark_Shikari> (It's a function with a huge startup time)
[11:39:02] <BBB> I noticed the AV_ZERO32(), nice catch
[11:39:08] <Dark_Shikari> Note: it doesn't zero [3]
[11:39:20] <Dark_Shikari> If you look carefully you'll notice it doesn't need to be zeroed.
[11:39:27] <kierank> Dark_Shikari: what should gcc be using instead of rep stos?
[11:39:31] <BBB> true
[11:39:38] <BBB> kierank: stosd?
[11:39:41] <BBB> stosq?
[11:40:01] <Dark_Shikari> .... mov
[11:40:05] <BBB> Dark_Shikari: use AV_ZERO64()+AVZERO32() instead of 3x AV_ZERO32()
[11:40:05] <Dark_Shikari> it's zeroing 16 bytes.
[11:40:10] <Dark_Shikari> BBB: it's not aligned enough
[11:40:13] <BBB> oh
[11:40:18] <BBB> fuck it
[11:40:20] <BBB> :)
[11:40:25] <Dark_Shikari> additionally, I don't know if that will cause load/store forwarding penalties
[11:40:31] <Dark_Shikari> because they're accessed as 32-bit values.
[11:40:37] <Dark_Shikari> storing as 64-bit RIGHT BEFORE they are used might be bad.
[11:40:45] <Dark_Shikari> Oh also, another thing improved by my changes
[11:40:52] <Dark_Shikari> previously, near_mv[] and the mv array in find_near_mvs were different
[11:40:55] <Dark_Shikari> so, at the end, we had to do
[11:41:03] <Dark_Shikari> near_mv[0] = near[CNT_NEAREST]
[11:41:06] <Dark_Shikari> near_mv[1] = near[CNT_NEAR]
[11:41:08] <Dark_Shikari> two pointless copies.
[11:41:19] <BBB> yes, I wrote that, that part was ugly
[11:41:19] <Dark_Shikari> I originally fixed this by passing in a pointer to near_mv and making that [4] instead
[11:41:27] <Dark_Shikari> But then I just said fuck it and merged the functions.
[11:41:30] <BBB> I think this is the first function I wrote, so I was like "oh well who cares"
[11:41:52] <BBB> (I've noticed it comes up in profiling, kind of embarassng)
[11:41:58] <Dark_Shikari> I can't really time it very well here
[11:42:01] <Dark_Shikari> I think I saved at least 30-40 clocks
[11:42:05] <Dark_Shikari> I suggest you time it if you're curious
[11:42:18] <BBB> I'll time it, it'd help if you did that too ;)
[11:42:36] <Dark_Shikari> I did, but my computer isn't stable enough
[11:42:39] <Dark_Shikari> the timings are all over.
[11:42:43] <BBB> it looks interesting, I might suggest that you don't move the function so it's easier to see what changed in the patch
[11:42:46] <Dark_Shikari> I can tell it's DEFINITELY faster but I don't know much.
[11:42:48] <Dark_Shikari> I have to move it.
[11:42:55] <Dark_Shikari> Otherwise I'd need a forward declaration of decode_split_mvs
[11:42:57] <BBB> because of clamp_mv()?
[11:43:01] <BBB> oh that one
[11:43:03] <BBB> hm, ok
[11:43:07] <BBB> nm then, I'll tiem it
[11:43:19] <BBB> get a shell on a computer with a stable timer :-p
[11:47:51] <siretart> for friends of cross compiling that hate libtool: http://thread.gmane.org/gmane.linux.linaro.devel/2239
[11:49:46] <Flameeyes> siretart: you don't read my blog, do you? ;)
[11:49:55] <mru> or my rants
[11:50:31] <Flameeyes> which reminds me I need to get again to look at venus
[11:50:38] <Flameeyes> last time I checked it was crap, I wanted to create planet.multimedia.cx
[11:50:44] <andoma> when it come to build systems and makefiles mru is my god
[11:50:51] <Flameeyes> [already asked Mike if the domain sounded good]
[11:52:58] <spaam> andoma: mru our hero
[11:53:02] <andoma> !
[11:53:09] <spaam> all hail mru !
[11:53:14] <pross-au> venus?
[11:53:16] <kshishkov> spaam: and of proper nationality too!
[11:53:30] <spaam> kshishkov: the best part :)
[11:55:09] <kshishkov> spaam: now only to make that guy to put more spots on FFmpeg code
[11:56:41] <Flameeyes> pross-au: blog aggregator software
[11:58:00] <spaam> Flameeyes: is it written in ruby?
[11:58:07] <kshishkov> Flameeyes: the problem is that there's almost nothing to aggregate
[11:58:18] <Flameeyes> spaam: worse, python
[11:58:48] <cartman> Flameeyes: stop bashing python :P
[11:58:50] <Flameeyes> kshishkov: there's your blog, mike's, mru's and mine.. and the gst guys tend to blog a lot
[11:59:21] <kshishkov> Flameeyes: look at sidebar on spectralhole.blogspot.com
[11:59:36] <kshishkov> and I'd feel uneasy being aggregated with gst
[11:59:36] <Flameeyes> cartman: sigh, I can't deal with that language, it's the bloody lack of an "end" keyword for me
[12:00:01] <cartman> bah :)
[12:00:08] <mru> significant whitespace, yuck
[12:00:18] <cartman> lgtm
[12:00:19] <cartman> ;P
[12:00:26] <pross-au> blog post quantity is inversely proportional to productivity right?
[12:00:39] <Flameeyes> pross-au: depends how you define productivity
[12:00:49] * Flameeyes is vastly a doc person so writing _is_ productivity
[12:01:16] <Flameeyes> kshishkov: okay so that's at least a starting point, ain't it? :)
[12:02:17] <Dark_Shikari> BBB: poke for benchies
[12:02:22] <BBB> in a bit
[12:02:25] <Dark_Shikari> k
[12:04:20] <CIA-38> ffmpeg: Anton Khirnov <anton at khirnov.net> master * rd7a5106eb2 ffmpeg/libavformat/asfdec.c:
[12:04:20] <CIA-38> ffmpeg: asfdec: skip the stream bitrate list
[12:04:20] <CIA-38> ffmpeg: Its contents aren't used for anything.
[12:04:20] <CIA-38> ffmpeg: Signed-off-by: Ronald S. Bultje <rsbultje at gmail.com>
[12:05:26] <KotH> grüezi
[12:05:31] <spaam> hey KotH
[12:05:55] <BBB> Dark_Shikari: baby needs food, me needs food, then me needs to go to work and set something up early, then I do benchies for you
[12:06:00] <BBB> then ??? then $$profit$$
[12:06:09] <BBB> :-p
[12:06:20] <Dark_Shikari> no problem =p
[12:08:04] <wbs> it's good as long as you have $$profit$$ somewhere on your roadmap, even if there are a few unknown steps leading up to that ;P
[12:11:24] <BBB> yeah, highly volatile $$profit$$, maybe EUREURprofitEUREUR is better
[12:11:47] * BBB can't find the EUR on his keyboard
[12:11:54] <av500> here: €
[12:11:54] <kshishkov> €€€
[12:12:07] <kshishkov> BBB: I use compose-=-e
[12:12:47] <BBB> my kb is american english, it probably doesn't have that
[12:13:00] <kshishkov> mine is too
[12:13:02] <BBB> compose-= gives me ≠
[12:13:28] <kshishkov> compose=e
[12:13:29] * mru uses £
[12:13:49] <kshishkov> and are you on MacOSX by any chance?
[12:14:54] <kshishkov> if so try option-shift-2
[12:15:43] <Flameeyes> kshishkov: it's C=
[12:16:32] <Tjoppen> €€profit€€
[12:17:14] <kshishkov> Flameeyes: looks like there are many ways to get it óò
[12:17:37] <Tjoppen> ¤_¤
[12:18:15] <Flameeyes> kshishkov: well it is a C with a = sign impressed over it :P
[12:18:38] <av500> the c64 logo?
[12:19:07] <Tjoppen> the quake 2 logo turned sideways?
[12:19:52] <kshishkov> Flameeyes: and slanted! don't froget proper slant degree and alignment!
[12:20:02] <kshishkov> *forget
[12:21:16] <Flameeyes> kshishkov: don't remind me of the stupid artistics concerns and the winner of the "commemorative" €1 coin
[12:22:05] <kshishkov> Flameeyes: I like 5SEK coin
[12:22:26] <Flameeyes> kshishkov: have you ever seen the commemorative coin?
[12:23:22] <Flameeyes> kshishkov: sorry that was €2... http://en.wikipedia.org/wiki/File:%E2%82%AC2_commemorative_coin_UEM_2009_General.jpg
[12:23:47] <Flameeyes> and no, it's not like many thought, that it was a kid's drawing.. that's an "artist"
[12:24:28] <av500> nice, Emulated Money Unit
[12:24:31] <Tjoppen> derp
[12:25:23] <kshishkov> Flameeyes: that's really greedy hand he has...
[12:25:30] <mru> Flameeyes: yeah, one of the most renowned artists of the neolithic era
[13:11:07] <CIA-38> ffmpeg: Kostya Shishkov <kostya.shishkov at gmail.com> release/0.5 * r44511b17cb ffmpeg/libavcodec/rv34.c:
[13:11:07] <CIA-38> ffmpeg: Update dimensions in AVCodecContext when RV3/4 frame dimensions change
[13:11:07] <CIA-38> ffmpeg: Originally committed as revision 20572 to svn://svn.ffmpeg.org/ffmpeg/trunk
[13:11:07] <CIA-38> ffmpeg: (cherry picked from commit ec10d2d53999f6edf7d7b5ac88df263eccfb1fb0)
[13:11:07] <CIA-38> ffmpeg: Fixes heap corruption crashes
[13:11:07] <CIA-38> ffmpeg: Addresses: CVE-2011-0722
[13:11:08] <CIA-38> ffmpeg: Signed-off-by: Reinhard Tartler <siretart at tauware.de>
[13:11:20] <CIA-38> ffmpeg: Janne Grunau <janne-ffmpeg at jannau.net> release/0.5 * r9109a58867 ffmpeg/ (38 files in 38 dirs):
[13:11:20] <CIA-38> ffmpeg: convert svn:ignore properties to .gitignore files
[13:11:20] <CIA-38> ffmpeg: Signed-off-by: Janne Grunau <janne-ffmpeg at jannau.net>
[13:11:20] <CIA-38> ffmpeg: (cherry picked from commit 348b8218f7a59374355c966dbe3b851a7275f952)
[13:11:20] <CIA-38> ffmpeg: Signed-off-by: Reinhard Tartler <siretart at tauware.de>
[13:11:21] <CIA-38> ffmpeg: Reinhard Tartler <siretart at tauware.de> release/0.5 * re332c41670 ffmpeg/.gitignore: also ignore *.so for vhook plugins
[13:11:23] <CIA-38> ffmpeg: Janne Grunau <janne-ffmpeg at jannau.net> release/0.5 * r11f6eebdd3 ffmpeg/ (38 files in 38 dirs):
[13:11:24] <CIA-38> ffmpeg: consolidate .gitignore patters into a single file
[13:11:24] <CIA-38> ffmpeg: Signed-off-by: Janne Grunau <janne-ffmpeg at jannau.net>
[13:11:24] <CIA-38> ffmpeg: (cherry picked from commit 2c3589bfda036c7827ded0bf38b16dfe7630bae1)
[13:11:24] <CIA-38> ffmpeg: Signed-off-by: Reinhard Tartler <siretart at tauware.de>
[13:11:28] <CIA-38> ffmpeg: Michael Niedermayer <michaelni at gmx.at> release/0.5 * r48b086b0ef ffmpeg/libavcodec/utils.c:
[13:11:28] <CIA-38> ffmpeg: Update safety check as the maximum pixel size is no longer 4.
[13:11:28] <CIA-38> ffmpeg: New max size is 16bit * 4 samples (RGBA).
[13:11:28] <CIA-38> ffmpeg: Originally committed as revision 18655 to svn://svn.ffmpeg.org/ffmpeg/trunk
[13:11:29] <CIA-38> ffmpeg: (cherry picked from commit 445f0a8b666a34e6402f6ae96c6804c8bc024baa)
[13:11:29] <CIA-38> ffmpeg: Addresses: CVE-2010-3908
[13:11:30] <CIA-38> ffmpeg: Signed-off-by: Reinhard Tartler <siretart at tauware.de>
[13:12:13] <elenril> huh?
[13:12:40] <kshishkov> somebody is rolling new 0.5 release?
[13:13:07] <thresh> sometart
[13:13:46] <Orphis> For those interested, the first useful report of the win64 build has been done
[13:14:14] <kshishkov> нфн!
[13:14:43] <kshishkov> not on fate.ffmpeg.org yet
[13:15:10] <Orphis> And I'm thinking of moving to a linux build and transfer the build onto the windows box and run the test directly there
[13:15:28] <Orphis> http://fate.ffmpeg.org/x86_64-mingw-w64-gcc-4.5/20110210122230
[13:16:08] <kshishkov> OS: mingw32 <- that's a bit confusing
[13:16:36] <siretart> kshishkov: yes, I am
[13:16:36] <Orphis> Is kostylev here ? I might be interested in getting his rpc.wrapper to remotely run the test on the windows box
[13:16:58] <Orphis> Yes, but that's how the platform is called in the configure :p
[13:32:23] <Flameeyes> mru: can I ask your opinion on a possible feature of my ruby-elf tools? :)
[13:35:04] <mru> Flameeyes: ask away
[13:35:49] <Flameeyes> mru: have you seen the output of rbelf-size I posted for libavcodec? do you think it might be worth adding a --differential switch so that the first argument is used as baseline, and the other are expressed as +x or -y in the columns?
[13:36:21] <mru> I suppose that could be handy
[13:36:49] <cartman> Orphis: awesome!
[13:37:16] * Flameeyes starts to think how to easily implement that
[13:37:28] <Flameeyes> thankfully implementing a different thing altogether made it much easier to deal with that :)
[13:38:48] <cartman> why does chinese guys set reported display dpi to 25 is beyond me
[13:39:28] <Flameeyes> cartman: 'cause chinese fonts are impossible to read at small point sizes?
[13:39:48] <cartman> Flameeyes: at 25dpi I get the smallest fonts ever
[13:39:55] <cartman> should 160 or more
[13:39:57] <cartman> to be sane
[13:40:01] <mru> Orphis: looks like you're missing zlib
[13:40:17] <Flameeyes> cartman: hrm... dpi always escape me =_=
[13:40:21] * mru stabs fonts scaling with dpi
[13:40:24] <cartman> Flameeyes: ;>
[13:40:46] <mru> I know how many _pixels_ I want, dammit
[13:40:48] <Flameeyes> dpi → \Flameeyes
[13:40:59] <av500> "....Writing configure scripts by hand is error prone and no fun at all..."
[13:41:01] <cartman> hahah
[13:41:22] <mru> av500: depends on how you write them
[13:41:24] <cartman> av500: mru in the parallel universe said that
[13:41:37] <av500> mru: from one of the ELCE talks
[13:41:44] <mru> cartman: orthogonal universe more likely
[13:41:53] <Flameeyes> av500: mru: depends also on _who_ writes them
[13:41:54] <cartman> mru: ah true ;P
[13:42:21] <Flameeyes> i.e. if the author is a kde dev, a manual configure would be probably very much messed up, seeing the kde3 build system >_<
[13:42:26] <cartman> mru: had a chance to read your "discussion" with pbrook
[13:42:35] <cartman> about codesourcery toolchain
[13:42:37] <kshishkov> Flameeyes: autotools!
[13:42:45] <Flameeyes> kshishkov: no, kde3 wasn't autotools
[13:42:47] <Flameeyes> was autohell
[13:43:04] <cartman> Flameeyes: make -f admin/Makefile.cvs
[13:43:05] <cartman> or something
[13:43:07] <cartman> heheh
[13:43:45] <Flameeyes> cartman: and only with the right _micro_ version of the proper tools patched by SuSE...
[13:43:55] <cartman> ;>
[13:44:08] <Flameeyes> damn C++ libraries, why do they have to export so many bloody symbols? :(
[13:44:32] <andoma> because c++ sucks
[13:44:35] <av500> because c++ is overloaded with symbols
[13:44:45] <Flameeyes> it was a rethoric question guys :)
[13:44:51] <cartman> because you let them do that
[13:44:55] <andoma> it still sucks :)
[13:45:10] <lu_zero> we should chat more with kde people
[13:45:24] <lu_zero> regarding on having all kde using ffconf
[13:47:13] <mru> let's abduct lydia next time then
[13:47:17] <mru> won't be hard...
[13:48:13] <Flameeyes> I somehow doubt she's going to be able to put some sense into the buildsystem guys
[13:48:23] <lu_zero> lydia will kill us sooner or later
[13:48:43] <Flameeyes> o_O what the heck happened at fosdem?
[13:49:20] * mru did nothing
[13:49:31] <mru> well, I did sort of suggest we might troll her talk
[13:49:35] <mru> then we didn't
[13:50:10] <av500> whatshe talk about?
[13:50:18] <av500> kdvp8?
[13:50:25] <mru> don't know
[13:50:33] <mru> as I said, we didn't troll it
[13:52:27] <jannau> "Let me teach you how to fish!"
[13:52:45] <av500> hand grenade?
[13:53:10] <kshishkov> Holy Hand Grenade of Antioch
[13:53:31] <mru> jannau: she's so... girly
[13:53:57] <siretart> HHGoA?
[13:56:23] <mru> kshishkov: that's for rabbits, not fish
[13:57:27] <kshishkov> mru: it's for all kinds of enemies
[13:57:41] <kshishkov> just read Book of Arms
[13:57:43] <DonDiego> so lydia has got herself an fffanbase? :)
[13:58:09] <mru> DonDiego: that happened years ago
[13:58:22] <mru> I guess since that time we shared booth at linuxtag
[13:59:16] <DonDiego> when did we share booth with kde?
[13:59:24] <DonDiego> the year i did not attend?
[13:59:43] <mru> 2007 iirc
[13:59:55] <mru> not with kde, with amarok
[13:59:56] <kshishkov> DonDiego: yes, otherwise you'd have spotted a girl next to you
[14:00:20] * mru should've taken a photo of her next to kshishkov...
[14:00:27] <mru> that looked kinda funny
[14:00:47] <cartman> mru: post it!
[14:00:54] <Flameeyes> cartman: he didn't take it :P
[14:00:58] <kshishkov> mru: you have reference av500 instead
[14:01:06] <DonDiego> haha, yes, kostya has 3-4 times the volume :)
[14:01:07] <cartman> Flameeyes: damn
[14:02:18] <kshishkov> DonDiego: and I have not found out who has the biggest ego - Argentinians, Swiss or people from Moscow
[14:02:38] <DonDiego> haha, where did that come from now? :)
[14:02:47] <cartman> possibly Swiss
[14:02:49] <thresh> yeah, why arent we the only ones?
[14:03:07] <Flameeyes> kshishkov: where did you put Italy?
[14:03:18] <mru> kshishkov: none of those, it's schilling
[14:03:28] <DonDiego> bcoudurier: Maksym Veremeyenko is desperately trying to ping you for patch review...
[14:03:29] <cartman> hahah
[14:03:59] <kshishkov> mru: how much is that in IJGs?
[14:04:08] <Flameeyes> mru: followed by drepper?
[14:04:32] <mru> Flameeyes: drepper at least works on something that everybody uses
[14:04:33] <kshishkov> mru: also it's the name for pre-Euro Austrian currency, isn't it?
[14:04:38] <Flameeyes> mru: good point
[14:06:15] <Flameeyes> gha! haskell libraries are even worse than C++
[14:06:36] <mru> s/gha/ghc/ ?
[14:07:00] <Flameeyes> more or less yes
[14:07:21] <Flameeyes> btw "how surprising" that a bunch of stuff beaks with glibc-2.13
[14:07:38] <Flameeyes> didn't memcpy() tell you not to use it on overlapping areas since ... ever?
[14:07:55] <mru> that one never gets old...
[14:08:11] <cartman> Flameeyes: Flash developers didn't get the memo
[14:08:16] <mru> btw, gcc emits invalid memcpy() calls all by itself
[14:08:20] <Flameeyes> cartman: qt-webkit as well
[14:08:31] <cartman> Flameeyes: lulz at that one
[14:08:37] <mru> struct foo *a, *b; ...; a = b; ...; *a = *b;
[14:09:00] <Flameeyes> mru: uhm terrific
[14:09:13] <mru> gcc sometimes turns that into memcpy(a, b)
[14:18:25] <CIA-38> ffmpeg: Mans Rullgard <mans at mansr.com> master * r628b16f45f ffmpeg/libavformat/mov.c:
[14:18:25] <CIA-38> ffmpeg: mov: remove stray semicolon
[14:18:25] <CIA-38> ffmpeg: Signed-off-by: Mans Rullgard <mans at mansr.com>
[14:18:34] <CIA-38> ffmpeg: Mans Rullgard <mans at mansr.com> master * rdbb09ec23f ffmpeg/libavcodec/ivi_dsp.c:
[14:18:34] <CIA-38> ffmpeg: ivi_dsp: remove semicolons after function definitions
[14:18:34] <CIA-38> ffmpeg: Signed-off-by: Mans Rullgard <mans at mansr.com>
[14:18:38] <CIA-38> ffmpeg: Mans Rullgard <mans at mansr.com> master * rb4668274b9 ffmpeg/libavcodec/utils.c:
[14:18:38] <CIA-38> ffmpeg: Remove incorrect return statement from avcodec_thread_free()
[14:18:38] <CIA-38> ffmpeg: The function return type is void, so a return statement with an
[14:18:38] <CIA-38> ffmpeg: expression is forbidden (and pointless).
[14:18:38] <CIA-38> ffmpeg: Signed-off-by: Mans Rullgard <mans at mansr.com>
[14:33:21] * Dark_Shikari pokes BBB again
[15:09:57] <cartman> av500: rockplayer guys seems to have some AAC decoder changes mostly.
[15:10:10] <av500> and some dca stuff
[15:10:20] <av500> cartman: did you find out the exact svn rev?
[15:10:42] <cartman> av500: nah, just took the Jun 14 first commit as the base
[15:11:07] <av500> 16th
[15:11:25] <cartman> or that, sucks they didn't document it
[15:11:48] <av500> its before 22830 according the Changelog
[15:12:29] <cartman> might as well just ask tjem
[15:12:31] <cartman> them*
[15:13:41] <Compn> Dark_Shikari : still got contacts at facebook ? i wonder if they have any new bugs/fourcc/samples to share with ffmpeg ?
[15:15:22] <av500> cartman: aac?
[15:16:09] <cartman> av500: yes?
[15:28:50] <BBB> Dark_Shikari: yes, working on my work thing, after I'm done and that's moving, I'll work on this, I promise it'll be today
[15:29:57] <Dark_Shikari> No problem.
[15:29:59] <Dark_Shikari> Compn: nope
[15:30:01] <elenril> in dangerous testing environments the enrichment center promises to always provide useful advice
[15:38:53] <mru> BBB: could you take a look at my 2 remaining vp8 patches?
[15:40:01] <BBB> kshishkov already OK'ed them, no?
[15:40:03] <BBB> at least 3/3
[15:40:37] <mru> are you ok with the vp8.c parts?
[15:42:18] <BBB> rename vp8_dct_ to ff_vp8_dct_... and include arm/vp8.h? yes, that's ok
[15:42:54] <mru> and the rac patch?
[15:43:04] <BBB> I can't find that one, annoyingly
[15:43:11] <BBB> what's the thread name?
[15:43:15] <mru> same thread
[15:43:21] <mru> patchwork should have links to gmane
[15:45:31] <BBB> that's just vp56.h, but that's ok, yes. makes me wonder if we should do that for x86 also
[15:45:40] <Dark_Shikari> ?
[15:46:11] <BBB> Dark_Shikari: vp56_rac_get_prob_branchy() asm
[15:46:22] <BBB> instead of the non-branchy one, which you wrote asm for
[15:47:29] <Dark_Shikari> But isn't the whole point of _branchy that it needs to be inlined?
[15:47:34] <Dark_Shikari> so that gcc can put the if/else on the right sides
[15:48:19] <BBB> inline asm, of course
[15:48:25] <Dark_Shikari> But what are you going to inline asm?
[15:48:27] <Dark_Shikari> It doesn't need a cmov.
[15:48:41] <BBB> I don't know, maybe gcc generates quite good code here
[15:48:49] <mru> it didn't on arm
[15:49:04] <Dark_Shikari> well duh it's gcc
[15:49:12] <mru> partially because it doesn't know the limited ranges of various values
[15:49:16] <Flameeyes> BBB: stop smoking pot ;)
[15:49:21] <Dark_Shikari> using inline asm for things like that on arm bugs me though, because arm requires smarter scheduling than x86
[15:49:29] <Dark_Shikari> But if it helps, it helps.
[15:49:34] <Dark_Shikari> I guess having more registers makes inline asm less bad.
[15:50:20] <mru> scheduling matters more, yes, but gcc sucks at that too
[15:50:26] <mru> so it doesn't really get any worse
[15:50:30] <Dark_Shikari> heh
[15:50:43] <Dark_Shikari> how's armcc do on it all?
[15:51:05] <mru> on average maybe 5% faster than gcc
[15:51:10] <Dark_Shikari> I mean, on the asm.
[15:51:17] <Dark_Shikari> would you want to use the inline asm with armcc too?
[15:51:21] <mru> it doesn't support gcc inline asm
[15:51:53] <Dark_Shikari> ah.
[15:52:06] <Dark_Shikari> so gcc + inline asm in the right places is still worse than armcc?
[15:52:13] <Dark_Shikari> also, what do you do about stuff like AV_WN etc on armcc?
[15:53:58] <mru> armcc does the right thing there
[15:54:23] <Dark_Shikari> I mean, how do you tell the compiler that the writes are unaligned?
[15:54:33] <Dark_Shikari> Without writing byte-by-byte.
[15:54:40] <Dark_Shikari> Since ARM has separate unaligned instructions.
[15:54:40] <mru> attributes
[15:54:46] <mru> no it doesn't
[15:54:50] <Dark_Shikari> Oh, it doesn't?
[15:55:00] <mru> halfword and word load/store support unaligned
[15:55:08] <Dark_Shikari> on all ARM?
[15:55:08] <mru> load/store multiple do not
[15:55:12] <Dark_Shikari> Ah
[15:55:13] <mru> armv6 and later
[15:55:17] <mru> and armcc knows that
[15:55:19] <mru> gcc doesn't
[15:55:26] <Dark_Shikari> ah.
[15:55:36] <mru> gcc uses byte-by-byte on all arm versions
[15:55:42] <mru> that's why the asm is there
[15:57:42] <Dark_Shikari> ah.
[16:20:37] <av500> kshishkov: rockplayer has the RM timestamp correction :)
[16:20:43] <av500> I will post the patches
[16:23:20] <spaam> good boy
[16:27:38] <BBB> av500: thanks
[16:33:37] <av500> patch commited to mailing list :)
[16:36:40] <kierank> mru: what's the best way of keeping pcr precision?
[16:39:19] <spaam> av500: you forgot something.. git-formated-patch.. mru going to tell you about it
[16:39:59] <av500> spaam: I take as excuse that its against the svn rev they used
[16:40:42] <av500> my git foo is weak
[16:42:43] <mru> kierank: elaborate
[16:42:58] <mru> kierank: that is both a request and an answer :)
[16:43:34] <av500> https://groups.google.com/group/nextplayer/browse_thread/thread/9d89747f5db8d2a8?hl=zh
[16:43:56] <spaam> mru: you should teach your comrade av500 how to use git.
[16:44:12] <kierank> mru: in a software muxer, when you write each packet you increment PCR by (188*8)/bitrate. What's the best way of making sure you don't get errors in the PCR owing to lack of precision.
[16:44:50] <mru> kierank: count total packets
[16:44:53] <mru> I suppose
[16:45:06] <mru> and deal with overflows somehow
[16:45:13] <kierank> I used doubles to begin with (which is obviously wrong) and I changed to infinite precision with GMP which is a bit overkill
[17:02:50] <Tjoppen> kierank: don't use a counter
[17:03:10] <Tjoppen> do what I did in mpegtsenc.c - just calculate it correctly each time you need to write it
[17:05:14] <Tjoppen> get_pcr() = av_rescale(url_ftell(pb) + 11, 8 * PCR_TIME_BASE, ts->mux_rate) + ts->first_pcr
[17:05:18] <kierank> yeah i see
[17:05:23] <kierank> but that won't work for vbr
[17:05:49] <Tjoppen> ah, I see. well, at least use rationals
[17:06:11] <mru> live streaming is so much easier
[17:06:16] <mru> pcr = gettime();
[17:06:47] <spaam> kierank: going to fix ffmpegtsenc?
[17:07:07] <kierank> spaam: i'll mentor someone in gsoc
[17:07:22] <kierank> but I wrote my own muxer for the time being because i need full on the fly reconfig
[17:07:39] <spaam> ok :)
[17:07:54] <mru> I wrote a ts muxer once, I'd rather not do it again
[17:08:00] <mru> and no, it doesn't really work
[17:08:08] <Tjoppen> try to get < 10 fps muxing working as well. or VFR in general
[17:08:16] <mru> it was good enough for the particular needs I had at the time
[17:18:37] <kierank> also mru, maybe you'll know why no stb manufacturer seems to know what h.264 settings their boxes will decode
[17:18:47] <kierank> the answer always seems to be "try it and see if it works2
[17:19:09] <mru> incompetent vendors
[17:19:32] <mru> stb manufacturers just take a chip and drivers from broadcom or st and hope for the best
[17:19:47] <mru> bcm and st are hopeless at writing drivers
[17:19:52] <kierank> even providers which spend huge amounts of money on stbs can't get an answer
[17:20:37] <mru> the decoders are usually dsps with firmware blobs
[17:20:55] <mru> whoever writes the firmware might know the answer
[17:21:02] <mru> but you'll never find them
[17:21:14] <kierank> yeah by the time you've found them you could just try it yourself
[17:21:19] <av500> yep
[17:21:43] <av500> kierank: soon you will have fun to ask them what maximum bitrate for vp8 they support :)
[17:22:07] <kierank> av500: "the one that most people use"
[17:22:33] <av500> 54
[17:23:38] <kierank> vp8 will be the new vc-1
[17:23:51] <mru> of course
[17:24:04] <mru> annoying, proprietary, and doomed to die
[17:24:20] <kierank> well vc-1 was microsoft's attempt to tame mpeg
[17:24:45] <mru> they even got it into the bluray spec
[17:24:53] <mru> and still they gave up in the end
[17:24:55] <Flameeyes> j-b: around?
[17:31:09] <mmu_man> mru: "highly optimized" they say ? lol
[17:31:30] <mru> who about what?
[17:34:22] <mmu_man> -#if HAVE_NEON && HAVE_INLINE_ASM
[17:34:23] <mmu_man> +#if HAVE_NEON && HAVE_INLINE_ASM && HAVE_ARMVFP && 0
[17:34:24] <mmu_man> :))
[17:34:57] <mmu_man> probably they tried to work around a buggy gcc
[17:38:09] * elenril summons some reviews from depths of heck
[18:09:33] <j-b> Flameeyes: yes
[18:30:24] * elenril pokes kshishkov 
[18:44:30] <thresh> av500: just got the 101, yipeee
[18:49:41] <_av500_> thresh: great
[18:49:56] <_av500_> tonight i will start drinking away the rubles
[18:53:43] <thresh> I decided to change my habits and try the interface in ru_RU
[18:53:45] <thresh> bad idea :/
[19:01:48] <Flameeyes> j-b: what's the "g" at the end of the symbol names in vlc plugins? :|
[19:02:40] <elenril> g is the new cool letter
[19:02:59] <kierank> elenril: like x?
[19:03:10] <Tjoppen> gPlayer?
[19:03:53] <elenril> http://tvtropes.org/pmwiki/pmwiki.php/Main/ThereIsNoSuchThingAsNotability
[19:04:08] <elenrilg> copyright infringement!
[19:04:11] * kierank awaits the stab
[19:04:33] <elenril> bwahaha
[19:04:50] <j-b> Flameeyes: the version ?
[19:05:29] <Flameeyes> j-b: gha... base 36 encoded?
[19:05:46] <mru> base54 ftw
[19:05:54] <mru> then we can do rot26 on it
[19:07:05] <j-b> Flameeyes: vlc_entry__1_2_0g or something?
[19:07:54] <Flameeyes> 1__1__0g yes
[19:08:23] <Flameeyes> I guess now that g == 7 (wasn't entirely obvious before)
[19:09:21] <j-b> yes
[19:09:35] <j-b> those are ABI bumps, I believe
[19:09:37] <Flameeyes> any reason why it's not 1__1__7? :P
[19:09:49] <j-b> Flameeyes: no fucking idea
[19:09:59] <Flameeyes> heh
[19:10:23] <j-b> probably predates the 1.x days... When we had 0.x.y.z...
[19:10:43] <j-b> and so people don't think it is 1.1.7 ABI
[19:10:51] <j-b> but the 7th bump in the 1.1. branch
[19:10:58] <j-b> but your guess is as good as mine
[19:12:00] <Flameeyes> heh okay, guess I'll just add a [a-z] at the end of the regexp and match it that way ;)
[19:13:37] <Flameeyes> nah I can't believe it... gnome-vfs bundles libneon?!
[19:15:01] <spaam> zomg
[19:15:50] <elenril> wtf is with everyone doing vfs
[19:16:11] <elenril> can't they just write fuse modules or something
[19:17:07] <Flameeyes> elenril: they moved toward that now
[19:17:21] <elenril> sanity? in my gnome?
[19:17:25] <elenril> inconceivable!
[19:18:00] <j-b> Flameeyes: just remember that vlc is done by crazy French men that are as skilled as you and are stupid enough to go into the B2C business...
[19:19:33] <Flameeyes> j-b: right, and that would be the same class as the inventors of SECAM and Peritél? :P
[19:19:51] <j-b> nah... not _that_ crazy
[19:20:30] <kierank> the british are becoming the new french
[19:20:35] <kierank> we keep loads of random crap alive
[19:20:38] <kierank> like mheg
[19:20:42] <kierank> 1080i in europe
[19:20:53] <kierank> tv-anytime or whatever it's called
[19:22:12] <j-b> oh, yeah, I saw that crap @ W3C Web&TV workshop
[19:22:42] <kierank> did you see mpeg-7
[19:22:44] <Flameeyes> okay, my newest script can generate the collision detection database for Yamato's host system in less than 10 minutes
[19:22:46] <Flameeyes> THIS is an improvement :)
[19:23:02] <Flameeyes> [the original script on Enterprise took over 13 hours to finish a scan]
[19:23:58] <j-b> kierank: I had 2 people complaining that "VLC sucks, because it doesn't read .mp7"
[19:24:19] <mru> Flameeyes: enterprise stuff is meant to be slow :)
[19:24:22] <kierank> did you tell them to come back when mpeg-7 actually does something
[19:24:48] <kierank> or if mpeg-7 can be explained without 50 buzzwords
[19:25:02] <j-b> kierank: more or less... And they told me to implement mpeg21
[19:25:11] <j-b> I didn't even answer
[19:25:34] <kierank> lol
[19:27:31] <j-b> kierank: I tried to read the spec... I didn't even know where to start from
[19:29:22] <_av500_> j-b: its a meta spec, you need elenril to read it for you
[19:29:34] <kierank> j-b: do you still have a stand at cebit
[19:29:46] * kierank might go
[19:30:01] * elenril proves his awesome meta skillz by not stabbing _av500_ 
[19:30:24] <j-b> kierank: yes, a very small one, but yes
[19:30:42] <_av500_> j-b: you can stand on both legs in it?
[19:30:45] <j-b> _av500_: haha... Meta! But is is generic and abstracted?
[19:32:19] <_av500_> j-b: yes, 21 describes how to write a spec that describes how to write a spec that describes ...
[19:32:38] <_av500_> ... turtles
[19:33:02] <j-b> and unicorns?
[19:33:20] <thresh> bah, that bastard had already registered the device on his name :D
[19:33:35] <_av500_> `
[19:33:37] <_av500_> ?
[19:33:46] <_av500_> i gave it in sealed box
[19:34:02] <thresh> nah, I'm not blaming you :)
[19:34:11] <_av500_> but his name is the same
[19:34:13] <thresh> it's Kostya whos nuts are going to be kicked :)
[19:34:48] <kierank> j-b: what's the best day to go to cebit?
[19:35:10] <j-b> kierank: no idea. I am closing the FOSDEM things before looking at FOSDEM
[19:35:19] <_av500_> kierank: any day 2000 or 2001
[19:35:32] <Tjoppen> _av500_: specs all the way down?
[19:35:41] <j-b> kierank: but the more it will come near to the week-end, the more it will be crowded with clueless people
[19:35:46] <Tjoppen> the only thing I got out of wikipedia was "DRM"
[19:36:17] <kierank> j-b: how many tickets did they give you
[19:37:25] <j-b> I've not even looked at it... But too many is my guess
[19:42:00] <jannau> j-b: expect also clueless people on weekdays, i.e. people who have no idea what open source is or people who have $IDEA for mobile app and looking for devs
[19:42:21] <j-b> ofc
[19:53:37] * mru curses typedeffed pointers
[19:54:09] <elenril> those are the root of all that is evil
[19:55:11] <Flameeyes> elenril: no that's /opt
[19:55:45] <thresh> _av500_: now as a paying customer I demand you to fix all bugs
[19:55:48] <elenril> who uses opt
[19:55:50] <kierank> elenril: those are vla
[19:55:53] <kierank> VLAs
[19:55:54] <Flameeyes> elenril: prebuilt evil!
[19:56:15] <kierank> elenril: all proprietary software
[19:56:27] <elenril> yeah, but who uses proprietary software =p
[19:56:44] <mru> sensible people do when it's the best solution available
[19:56:59] <Flameeyes> mru++
[19:57:51] * elenril prefers watching some anime instead
[19:58:28] <Flameeyes> I'm lacking time to follow anime nowadays :( I'm keeping with stuff I can listen with half brain
[19:59:02] <mru> that's why he's here listening to elenril
[19:59:08] <BBB> does someone have time to create a git-formatted patch for the fix proposed in https://roundup.ffmpeg.org/issue2594 ?
[19:59:47] <thresh> lol, people use archos application "market" to do two things
[19:59:50] <Flameeyes> mru: waiting for libreoffice to complete build to run my collision detection script again :)
[19:59:51] <thresh> 1/ install angry birds
[19:59:56] <thresh> 2/ install google market
[20:00:34] <elenril> Flameeyes: the amount of good anime these days doesn't require much time ;)
[20:02:20] <j-b> Flameeyes: what is your collision detection script?
[20:03:33] <Flameeyes> j-b: it's one of the ruby-elf tools: it reads all the dynamic ELF objects in a system, skip over plugin interfaces, collapse libraries' variants, adds all that to a db, then mines the data from that db to produce a list of possible collisions between libraries in that system
[20:03:55] <j-b> Flameeyes: nice
[20:04:05] <Flameeyes> I started working on it at the time I debugged a crash in xine because of collisions, has turned out a number of issues with bundled libraries in Gentoo
[20:04:21] <Flameeyes> unfortunately most upstreams don't even care about those collisions in the first place :(
[20:04:45] <j-b> "how to be a good upstream"... Is there a guide for it?
[20:05:10] <thresh> Flameeyes: some time your package manager would be sane enough to have a require / provide for a set of symbols in a library
[20:05:19] <thresh> then, no sonames would be necessary
[20:05:33] <Flameeyes> j-b: a gentoo dev had that as a talk last year at fosdem... otherwise I don't think there are
[20:06:15] <thresh> in fact, our guys at ALT Linux had done just that in our fork of RPM
[20:09:24] <Flameeyes> thresh: not really.. sonames and package managers should solve different issues
[20:10:42] <j-b> Flameeyes: betelgeuse at g.o seems to
[20:11:50] <thresh> Flameeyes: yes, sure
[20:16:41] <_av500_> thresh: i dont know you any more :)
[20:17:21] <Flameeyes> j-b: yeah, me, lu_zero, mru and siretart were there en masse :D
[20:17:48] <thresh> _av500_: I knew there was a catch :)
[20:18:02] <_av500_> thresh: it was cheap :)
[20:18:28] <thresh> hehe
[20:18:40] <_av500_> cheap french stuff
[20:18:55] <j-b> Flameeyes: no presentation online
[20:19:08] <Flameeyes> j-b: uhm that's strange, the Debian team had it online
[20:19:14] <Flameeyes> I know I have it around, will upload
[20:19:51] <Flameeyes> will take a bit, since it's 519M and I have 32kib upstream though :P
[20:22:50] <j-b> 519M for a presentation?
[20:22:57] <kierank> video
[20:23:00] <thresh> it's in bink video, what do you expect
[20:23:07] <_av500_> xml video
[20:23:19] <_av500_> </pixel>
[20:23:31] <j-b> pfff, I don't want a 1h video that should be summarized in 10min
[20:23:35] <Flameeyes> j-b: OGV :P
[20:23:45] <thresh> j-b: then why did you watch Avatar?:)
[20:23:58] <Flameeyes> guess at a minimum I should recode it ;)
[20:23:59] <mru> avatar needs 10min?
[20:24:09] <thresh> mru: point taken, 3 minutes max
[20:24:14] <_av500_> blue pocahontas
[20:24:18] <_av500_> done
[20:24:41] <mru> that is a fair description
[20:25:02] <astrange> huh, i am an ffmpeg developer in atlanta, ga
[20:25:18] <_av500_> i feel for you
[20:25:36] <astrange> but i'm already employed
[20:25:45] <mru> see which is better
[20:26:11] <j-b> http://www.youtube.com/watch?v=XBKwPeKLa4Q then
[20:26:53] <mru> ugh @ sound quality
[20:28:35] <_av500_> ffaacenc?
[20:29:05] <thresh> last time I checked it only produced soundtrack for a swamp
[20:29:18] <thresh> aka croaking
[20:29:31] <thresh> it might fit that video though
[20:30:30] * _av500_ watches "how to fork your own upstream"
[20:31:04] <mru> by mark shuttleworth
[20:31:15] <thresh> yeah, ffmpeg devs need that
[20:31:19] <thresh> </troll>
[20:33:36] <CIA-38> ffmpeg: Justin Ruggles <justin.ruggles at gmail.com> master * rdda3f0ef48 ffmpeg/libavcodec/ (8 files in 2 dirs):
[20:33:36] <CIA-38> ffmpeg: Add x86-optimized versions of exponent_min().
[20:33:36] <CIA-38> ffmpeg: Signed-off-by: Ronald S. Bultje <rsbultje at gmail.com>
[20:33:54] <ruggles> \o/
[20:33:58] <BBB> ruggles: thanks, sorry I took so long to apply it
[20:34:09] <BBB> so how much more work until after is "done"?
[20:34:43] <ruggles> not much code writing left. mostly just getting patches through review.
[20:35:25] <Flameeyes> note to self: libreoffice might be slimmer, but it _still_ doesn't fit into tmpfs
[20:35:27] <ruggles> only big piece of code left to write is channel coupling. i got the syntax working yesterday, but now i have to actually generate the coupling channel and coordinates.
[20:35:42] <mru> Flameeyes: get more ram :)
[20:35:50] <Flameeyes> mru: yeah I should... but it's pricey
[20:36:16] <BBB> ruggles: oh that's pretty good, and how does ac3enc compare to "commercial" ac3 encoders then?
[20:36:48] <ruggles> i don't really know. i don't have any commercial ac3 encoders.
[20:36:53] <Flameeyes> mru: around €560 for another 16G :(
[20:36:56] <CIA-38> ffmpeg: Reimar Döffinger <Reimar.Doeffinger at gmx.de> master * r4a72765a1c ffmpeg/libavcodec/dvbsubdec.c:
[20:36:57] <CIA-38> ffmpeg: Do not fail DVB sub decoding because of a few padding bytes
[20:36:57] <CIA-38> ffmpeg: Instead of returning an error when bytes are left over, just return
[20:36:57] <CIA-38> ffmpeg: the number of actually used bytes as other decoders do.
[20:36:57] <CIA-38> ffmpeg: Instead add a special case so an error will be returned when none
[20:36:57] <CIA-38> ffmpeg: of the data looks valid to avoid making debugging a pain.
[20:36:58] <CIA-38> ffmpeg: Signed-off-by: Janne Grunau <janne-ffmpeg at jannau.net>
[20:37:05] <CIA-38> ffmpeg: Janne Grunau <janne-ffmpeg at jannau.net> master * r493aa30adf ffmpeg/libavcodec/dvbsubdec.c:
[20:37:05] <CIA-38> ffmpeg: dvbsubdec: check against buffer overreads
[20:37:05] <CIA-38> ffmpeg: Signed-off-by: Janne Grunau <janne-ffmpeg at jannau.net>
[20:37:06] <CIA-38> ffmpeg: Janne Grunau <janne-ffmpeg at jannau.net> master * r5c19f64c60 ffmpeg/doc/build_system.txt: document passing the fate samples location via make variable
[20:37:38] <ruggles> BBB: but as far as features affecting quality are concerned, once coupling is done it should be fairly close.
[20:39:21] <elenril> how good is ac3 compared to other formats?
[20:39:24] <elenril> like vorbis or aac
[20:39:53] <ruggles> elenril: not as good in the quality/bandwidth sense
[20:40:19] <Flameeyes> does this mean alsa-plugin's ac3 encoder could soon allow to have multichannel output over spdif? :P
[20:40:41] <ruggles> Flameeyes: why doesn't it now?
[20:40:54] <Flameeyes> ruggles: mostly because it explodes
[20:41:14] <Flameeyes> with various degrees of reasons
[20:41:32] <Flameeyes> with xine it's a race condiiton due to the different init calls between xine and alsa
[20:42:07] <ruggles> shouldn't have anything to do with what i'm doing in ffmpeg though...
[20:43:35] <Flameeyes> just hoping somebody is looking at the ac3 encoding ;)
[20:45:22] <ruggles> i only briefly looked at the alsa ac3 plugin several years ago. i thought it supported 5.1 ok.
[20:45:38] <ruggles> it seemed to work with mplayer anyway
[20:46:05] <Flameeyes> I think that's the only use case where it works :)
[20:47:19] <ruggles> does it work with just ffmpeg now that we have an spdif muxer and alsa output?
[20:48:09] <ruggles> i guess that would skip the plugin though...
[20:48:11] <Flameeyes> I'd have to re-connect a soundcard to tell :)
[20:50:23] <jannau> BBB: can you look at http://patches.ffmpeg.org/patch/167/ aac profiles
[20:58:11] <BBB> jannau: isn't that applied already?
[20:58:30] <BBB> hm, I guess not
[20:59:06] <BBB> jannau: it needs an extra one-liner that always sets avctx->profile to FF_PROFILE_AAC_LOW in aacenc_init()
[20:59:19] <BBB> jannau: otherwise the value will be undefined if avctx->profile wasn't explicitely set
[20:59:48] <BBB> jannau: and that's the only profile supported anyway
[21:04:11] <elenril> can i have an op in #ffmpeg?
[21:04:29] <mru> elenril: trolls?
[21:04:37] <elenril> also can we clone BBB so he'll review the rest of asf stuff?
[21:04:38] <elenril> mru: yes
[21:04:48] <elenril> or more like spam
[21:04:54] <j-b> Flameeyes: ok, after watching it, we are not bad upstream
[21:05:26] <Flameeyes> j-b: it wasn't as easy when I started mantaining vlc tho :P
[21:06:29] <j-b> Flameeyes: indeed, but it has changed quite a bit since I cleaned configure and packaging with courmisch
[21:06:43] <elenril> mru: thanks
[21:06:45] <Flameeyes> yep yep it was definitely a welcome cleanup :)
[21:07:32] <j-b> Flameeyes: btw, is there any correct way to warn all downstream developers in one time?
[21:07:49] <Flameeyes> j-b: make an -announce list :D
[21:07:57] <Flameeyes> that's what OpenSSL does fwiw
[21:09:02] <jannau> BBB: thanks, it wasn't entirely clear. I'll send an updated patch
[21:20:42] <barspi> hi… anyone in charge of the git repository configuration?
[21:21:02] <thresh> which one exactly?
[21:21:10] <jannau> barspi: sure
[21:21:18] <barspi> or who could tell me why "git archive —remote=git://git.ffmpeg.org/ffmpeg.git   will not work?
[21:21:34] <barspi> # git archive --format=tar  --remote=http://git.ffmpeg.org/ffmpeg.git  a1c1d3c003b0ec16fdb6574913781313fb2c7ab6   > tt.tar
[21:21:34] <barspi> fatal: Operation not supported by protocol.
[21:22:02] <barspi> I want an archive of *that specific* revision  (and no, I don't want to clone the whole git repo :-) )
[21:22:29] <barspi> but I'm a git newbie so maybe I'm doing something wrong
[21:22:41] <jannau> barspi: that repository was the old git svn clone and is discontinued
[21:22:56] <jannau> use git://git.ffmpeg.org/ffmpeg instead
[21:23:13] <barspi> hmm without the .git at the end?
[21:23:20] <jannau> hmm wait
[21:23:54] <barspi> I'm sorry I copied the wrong command form my screen (with http)
[21:24:04] <barspi> I really tried it with  git://  hehe
[21:24:29] <barspi> # git archive --format=tar  --remote="git://git.ffmpeg.org/ffmpeg.git/"  a1c1d3c003b0ec16fdb6574913781313fb2c7ab6   > tt.tar
[21:24:30] <barspi> fatal: The remote end hung up unexpectedly
[21:24:35] <barspi> same error
[21:24:47] <barspi> or rather, same result: an error :-)
[21:25:05] <barspi> so maybe the git server is not configured to support remote archiving?
[21:28:51] <jannau> barspi: yes, we don't allow remote archive generation
[21:29:21] <barspi> ohh
[21:29:28] <barspi> that sucks… can it be fixed? :-)
[21:30:29] <mru> btw ffmpeg.git and ffmpeg are the same now
[21:30:37] <mru> the old one is ffmpeg.svn
[21:30:53] <barspi> but  ffmpeg.svn is not up-to-last-minute, right?
[21:31:13] <mru> it's synced with the svn repo
[21:31:20] <mru> which is read-only
[21:31:55] * Daemon404 wonders why gcc does not yet have vmrs/vmsr instructions
[21:32:09] <mru> that's binutils, and use the pre-ual names
[21:32:28] <Daemon404> i ended up doing that
[21:32:32] <jannau> barspi: upload-archive is by default disabled in git daemon
[21:32:44] <Daemon404> any reason why it doesnt tho?
[21:32:45] <jannau> I'm unsure if we want to enable it
[21:32:50] <mru> Daemon404: the real question is why you are using those in the first place
[21:33:01] <Daemon404> i was just pokign around teh cpuid shit
[21:33:24] <mru> cpuid is privileged on arm
[21:33:27] <mru> don't ask me why
[21:33:28] <barspi> I'm not sure if that option is what I want. As I told you, I'm a git newbie :-)
[21:34:03] <jannau> barspi: do you have a reason why you don't want to clone the repo?
[21:34:16] <Daemon404> mru, that would explain what im seeing then
[21:34:19] <barspi> but I think it could be useful to allow an export of a certain revision (one which has not been specifically tagged or branched)
[21:34:35] <mru> Daemon404: SIGILL?
[21:34:43] <Daemon404> mru, yes
[21:34:57] <jannau> barspi: you'll have all revision in your repo clone
[21:35:12] <barspi> the reason is that I have a build script that depends on a certain revision, and I want to distribute that script to my team and they don't need the whoooooooole git tree
[21:35:24] <barspi> they just need to download that one and do a build
[21:35:55] <barspi> (also, I could distribute the whole export that I have locally archived myself, but that's evading the question/problem)
[21:36:09] <barspi> there's always 1000 ways to do something, but some ways are better than others :-)
[21:36:31] <barspi> something so simple which in SVN could be done with a svn export @rev
[21:36:33] <Daemon404> mru, i was just using it out of boredom btw (and to poke around a bit using gas-preprocessor.pl)
[21:37:08] <mru> Daemon404: are you on iphone?
[21:37:24] <Daemon404> nope. i have a few arm boards + android phone
[21:37:33] <mru> then why the preprocessor?
[21:38:00] <Daemon404> liek i said boredom, wanted to see wtf it did.
[21:38:23] <mru> it works around apple's rotten build tools
[21:38:29] <Daemon404> ah
[21:39:00] <Daemon404> and im lookign in to obtaining armcc atmto toy with at some point (can prolly through company)
[21:39:25] * Daemon404 is part way into his arm arch book
[21:45:59] <CIA-38> ffmpeg: Mans Rullgard <mans at mansr.com> master * r44adbebe17 ffmpeg/ (6 files in 2 dirs):
[21:45:59] <CIA-38> ffmpeg: Remove final semicolon from some macros
[21:45:59] <CIA-38> ffmpeg: This avoids double semicolons after macro expansion.
[21:45:59] <CIA-38> ffmpeg: Signed-off-by: Mans Rullgard <mans at mansr.com>
[21:46:09] <CIA-38> ffmpeg: Ronen Mizrahi <ronen at tversity.com> master * rdf211c3ab7 ffmpeg/libavcodec/dvbsub.c:
[21:46:09] <CIA-38> ffmpeg: dvbsubenc: Fix placement of the object version
[21:46:09] <CIA-38> ffmpeg: Signed-off-by: Mans Rullgard <mans at mansr.com>
[21:55:19] <CIA-38> ffmpeg: Peter Ross <pross at xvid.org> master * r12c14cd4a8 ffmpeg/libavformat/ (avformat.h version.h):
[21:55:19] <CIA-38> ffmpeg: add AV_DISPOSITION_HEARING_IMPAIRED and AV_DISPOSITION_VISUAL_IMPAIRED
[21:55:19] <CIA-38> ffmpeg: Signed-off-by: Janne Grunau <janne-ffmpeg at jannau.net>
[21:55:28] <CIA-38> ffmpeg: Peter Ross <pross at xvid.org> master * r5209149157 ffmpeg/libavformat/utils.c:
[21:55:28] <CIA-38> ffmpeg: make av_find_best_stream() ignore streams marked with AV_DISPOSITION_*_IMPAIRED
[21:55:28] <CIA-38> ffmpeg: Signed-off-by: Janne Grunau <janne-ffmpeg at jannau.net>
[21:55:31] <CIA-38> ffmpeg: Peter Ross <pross at xvid.org> master * r68137ba386 ffmpeg/libavformat/wtv.c:
[21:55:31] <CIA-38> ffmpeg: wtv: mark streams intended for hearing or visual impaired persons
[21:55:31] <CIA-38> ffmpeg: Signed-off-by: Janne Grunau <janne-ffmpeg at jannau.net>
[21:57:27] <barspi> so… jannau, do you think the archive option will be enabled or is it a no-no ?
[22:05:10] <jannau> mru: do you have an opinion on enabling upload-archive?
[22:05:26] <ruggles> would that be the same as a snapshot from gitweb?
[22:05:38] <mru> probably
[22:05:54] <mru> it's a matter of system load and bandwidth
[22:06:05] <mru> I doubt many will use it
[22:07:57] <jannau> maybe we could create nightly snapshots for git
[22:10:32] <_av500_> wont help ppl that need a specific rev
[22:18:34] <barspi> nightly snapshots could be cool :-)
[22:18:42] <barspi> but they will take space on your servers
[22:19:12] <barspi> I need this feature because I need certain ASF features which have only recently been added
[22:19:36] <barspi> and I know that the revision I used a few days ago works, but I can't guarantee that HEAD will always work
[22:19:42] <siretart> barspi: you mean something like this: https://launchpad.net/~motumedia/+archive/ffmpeg-daily/+packages?
[22:19:51] <barspi> so I want *that* revision specifically and it hasn't been tagged yet
[22:20:29] <barspi> (side note… the ffmpeg-devel channel seems a lot more friendly than the harsh mailing list hehehe)
[22:20:48] <elenril> ....so whay can't you just clone the whole repository
[22:22:01] <barspi> there's no point in doing that (which is like twice the size of a clean tree) when my clients just one a specific build of a specific revision
[22:22:35] <mru> do a shallow clone
[22:22:37] <barspi> I could clone the whole internet on my machine because I want a couple of photos, but that's besides the point and avoiding the question/problem
[22:23:26] <barspi> I read up on shallow clone, but it seems it works with a certain-depth-number  which I understand as "depth as of now"  (where now is moving in time because time runs forward)
[22:23:45] <barspi> so 2 levels as of today probably won't give me the same revision as 2 levels 6 months from now
[22:24:02] <jannau> mru: doesn't help since you can't specify which version you want
[22:24:13] <barspi> (plus I have no idea how many levels back from "now" to get to a1c1d3c003b0ec16fdb6574913781313fb2c7ab6)
[22:24:37] <mru> arithmetic in sha1 space can be a bit tricky, sure
[22:25:44] <barspi> I don't want to sound like a pesty geek, but I just so it would be something simple todo and that's why I'm so tough headed about it hahaha
[22:26:26] <elenril> looks to me like you're just creating artificial problems
[22:26:40] * jannau curses elenril
[22:27:28] <jannau> I've tried to clean patchwork but still more than 1 page
[22:27:34] <elenril> haha
[22:27:39] <barspi> haha I don't think so…  someone who is not interested in developing a project shouldn't have to clone a whole project's history/prehistory/and whatnot
[22:27:39] <elenril> jannau: go review my patches then
[22:27:51] <barspi> somebody just wants a certain revision…
[22:28:07] <elenril> barspi: well most people don't care
[22:28:13] <elenril> since the repository is tiny anyway
[22:28:23] <elenril> we're not living in the age of 1gb disks anymore
[22:29:12] <astrange> a git checkout with full history is the same size as an svn checkout
[22:29:24] <astrange> because svn never implemented a compressed text-base
[22:29:52] <_av500_> is it on the todo list?
[22:33:19] <Dark_Shikari> BBB: poke
[22:33:28] <BBB> oh, right, testing right this moment
[22:33:38] <BBB> (yes I forgot, I apologize)
[22:34:25] <elenril> jannau: you can remove Replace remaining occurrences of deprecated CH_* with AV_CH_*, it's been applied
[22:34:31] <Dark_Shikari> BBB: no problem
[22:34:44] <Dark_Shikari> also I found a way to save 2 clocks on rac_get
[22:34:47] <Dark_Shikari> er, two instructions
[22:34:52] <Dark_Shikari> but not sure what the cleanest way to do it is
[22:34:55] <Dark_Shikari>     if( av_builtin_constant_p(prob) && prob == 128 )
[22:34:55] <Dark_Shikari>         low = (high + 1) >> 1;
[22:34:55] <Dark_Shikari>     else
[22:34:56] <Dark_Shikari>         low = 1 + (((high - 1) * prob) >> 8);
[22:34:56] <BBB> 2 instructions is fabulous
[22:35:02] <Dark_Shikari> Not rac_get_prob.
[22:35:03] <Dark_Shikari> rac_get.
[22:35:08] <BBB> oh
[22:35:16] <Dark_Shikari> It's used in one place in speed-critical code (dct sign)
[22:35:47] <mru> the code I wrote in all asm?
[22:36:27] * BBB fears some version of gcc will not properly inline the prob==128 if prob=128, and actually compare 128 to 128
[22:36:41] <kierank> did google sponsor ffvp8's arm opts?
[22:36:48] <mru> kierank: arm did
[22:36:50] <barspi> the difference is not with svn checkout, but with svn export (which does not download the whole .svn stuff)
[22:36:55] <kierank> mru: ah
[22:37:04] * kierank doesn't see mru working on dead codecs without good reason
[22:37:32] <mru> a 4-figure sterling amount is a good reason to me :)
[22:37:57] <astrange> no sponsorship for decode_cabac_residual()?
[22:38:08] <barspi> and as for 1gb hard disks… the main problem is internet speed (the build script having to download a whole git repo clone takes much longer to execute)
[22:39:36] <barspi> anyway… I guess I'll script the 2-step and long process of doing a full clone and then a local archive...
[22:42:39] <BBB> astrange: sponsorship?
[22:51:17] <ruggles> mru: i already did send a new patch with a correct comment
[22:51:36] <kierank> we could do some blind ffmpeg vs ffac3enc tests
[22:52:19] <lu_zero> ?
[22:52:30] <kierank> i mean dolby
[22:52:32] <kierank> gah
[22:52:49] <mru> ruggles: yeah, see it
[22:52:53] <mru> ruggles: makes more sense now
[22:53:51] <ruggles> kierank: good idea. what i need right now is a nice sample encoded by dolby encoder at all bitrates it supports for stereo and 5.1.
[22:54:51] <ruggles> i have plenty of ac3 samples, but no source + sample.
[22:54:52] <BBB> Dark_Shikari: see ML
[22:55:29] <kierank> ruggles: http://www.neyrinck.com/en/downloads/dolby-digital
[22:55:36] <Dark_Shikari> BBB: Nice
[22:55:43] <Dark_Shikari> will get around to that in a bit.
[22:56:29] <ruggles> kierank: oh nice. 30 sec limit... but better than nothing.
[22:56:46] <kierank> ruggles: sometimes the drm doesn't work and lets you encode as much as you like
[22:56:59] <kierank> at least that's what it was like on the dolby e one
[22:57:13] <bcoudurier> wiat
[22:58:24] <bcoudurier> if you want samples, ask me
[22:58:28] <BBB> bcoudurier: oh, since you're here, should I go look for that old patch to set the raw video tag correctly? also, shouldn't that tag ever be set in the decoding case, since it basically just creates applications that work around bugs, so its only use case would be for ffmpeg -vtag abcd?
[23:00:52] <BBB> astrange: should I help preparing patches to submit h264-mt/h263-mt/etc-mt?
[23:01:14] <BBB> astrange: and yes I will keep bugging you until it's completely merged, this stuff is way too awesome to not merge right away
[23:04:38] <CIA-38> ffmpeg: Anton Khirnov <anton at khirnov.net> master * rc1fea23070 ffmpeg/libavformat/asfdec.c:
[23:04:39] <CIA-38> ffmpeg: asfdec: split asf_read_header()
[23:04:39] <CIA-38> ffmpeg: Only trivial splits are done here -- i.e. copy/paste + reindent +
[23:04:39] <CIA-38> ffmpeg: missing variable declarations.
[23:04:39] <CIA-38> ffmpeg: Signed-off-by: Ronald S. Bultje <rsbultje at gmail.com>
[23:05:19] <bcoudurier> BBB, I don't understand what you mean here
[23:05:32] <bcoudurier> the tag is used to workaround bugs sometimes
[23:05:42] <CIA-38> ffmpeg: Anton Khirnov <anton at khirnov.net> master * r0b1d291a71 ffmpeg/libavformat/asfdec.c:
[23:05:42] <CIA-38> ffmpeg: asfdec: deobfuscate reading video properties size
[23:05:42] <CIA-38> ffmpeg: This code will be later split out into a function which takes a 'size'
[23:05:42] <CIA-38> ffmpeg: argument, so I'm keeping the name 'sizeX' here.
[23:05:42] <CIA-38> ffmpeg: Signed-off-by: Ronald S. Bultje <rsbultje at gmail.com>
[23:08:17] <BBB> bcoudurier: right, I can see it being useful in certain scenarios, like wanting to force a fourcc on a quicktime/avi file, or some more stuff, but in the mov<->avi transcoding case, you can see that it introduces problems. so I don't think demuxers should set AVCodecContext->video_tag, or alternatively I think the "fourcc of video format in the demuxed file" vs. "force fourcc to be this one in the muxed file" should not automatically be the sam
[23:08:17] <BBB> in AVCodecContext... one solution is for demuxers to simply not set AVCodecContext->video_tag, do you have better solutions?
[23:09:06] <bcoudurier> do what you want and break everything including stream copy
[23:09:47] <atod> does anyone know where ffmpeg can be hacked to figure out h.264 references > 9. or would that be in libx264 also?
[23:09:54] <bcoudurier> I guess you have to learn the mistakes by doing them like previous people knowledgeable went though
[23:10:02] <bcoudurier> through
[23:10:30] <mru> and what do you do with formats like matroska where the codec identifier is a string?
[23:10:44] <mru> the 32-bit tag stuff reeks of avi-think
[23:11:33] <bcoudurier> mov uses 32 bit tag and ts as well
[23:11:40] <BBB> bcoudurier: well that one was obvious and coming. fine, be all arrogant about it, you say you sent a patch, I show interest, apparently I shouldn't?
[23:12:08] <mru> bcoudurier: mov uses _different_ tags than avi
[23:12:14] <mru> and ts doesn't require them
[23:12:25] <mru> and when present, they're from yet another set
[23:12:38] <mru> blindly copying them is beyond stupid
[23:12:39] <bcoudurier> ts requires them for some mappins
[23:12:48] <kierank> yeah for dirac
[23:12:50] <bcoudurier> like ATSC requires AC-3
[23:13:02] <bcoudurier> and dirac too that's correct
[23:13:20] <mru> ac3 uses a different identifier in atsc and dvb
[23:16:51] <CIA-38> ffmpeg: Justin Ruggles <justin.ruggles at gmail.com> master * rd4582889ee ffmpeg/libavcodec/ac3enc_fixed.c:
[23:16:51] <CIA-38> ffmpeg: ac3enc: remove right shifting from lshift_tab() and make lshift unsigned.
[23:16:51] <CIA-38> ffmpeg: Signed-off-by: Mans Rullgard <mans at mansr.com>
[23:17:03] <CIA-38> ffmpeg: Justin Ruggles <justin.ruggles at gmail.com> master * r626264b11b ffmpeg/libavcodec/ac3enc_fixed.c:
[23:17:03] <CIA-38> ffmpeg: ac3enc: Remove unneeded clipping of shift amount.
[23:17:03] <CIA-38> ffmpeg: s->windowed_samples will always have a range of [-32767,32767] due to the
[23:17:03] <CIA-38> ffmpeg: window function, so the return value from log2_tab() will always be in the
[23:17:04] <CIA-38> ffmpeg: range [0,14].
[23:17:04] <CIA-38> ffmpeg: Signed-off-by: Mans Rullgard <mans at mansr.com>
[23:18:16] <bcoudurier> anyway, mru, 32 bit is not adequate for matroska, and mxf uses 16 bytes integer
[23:18:24] <bcoudurier> I agree
[23:18:24] <mru> that's my point
[23:18:28] <mru> what do you do with them?
[23:18:55] <mru> I know preserving the exact avi tag sometimes has advantages
[23:18:56] <bcoudurier> well I think the best strategy is to override what's in codec_tag by default
[23:19:01] <bcoudurier> when muxing
[23:19:11] <bcoudurier> if user forces a new one, use it
[23:19:18] <mru> but the current way it's done is wrong
[23:19:31] <bcoudurier> mp4 muxer do not let the user specify it
[23:19:36] <BBB> bcoudurier: tat's the problem
[23:19:47] <BBB> bcoudurier: you don't know when it's forced and when it's set by a (which?) demuxer
[23:19:53] <bcoudurier> mov muxer will choose the default unless strict is specified
[23:20:28] <bcoudurier> that's about the stream copy case
[23:20:52] <BBB> so I say: split it into two - one is "forced by used", which is always used, and one is "set by demuxer", which is only used if the muxer doesn't know how to map codec_id to a tag by itself
[23:21:16] <BBB> (split into 2 = split AVCodecContext.video_tag into AVCodecContext.demux_video_tag and .force_video_tag)
[23:22:51] <BBB> we could even consider making .force_video_tag a codec private option, since it really only applies to a few muxers that use fourccs as codec identifiers, but that's a flamewar that I'll skip since I'm ignorant
[23:22:55] <bcoudurier> I'm not sure it's a lib problem, more an application problem
[23:23:18] <bcoudurier> some decoders need the tag to workaround bugs, application has to set it anyway
[23:24:14] <bcoudurier> when muxing, application can set it, and muxer will honor it or not (depending on strict)
[23:25:42] <BBB> I don't think applications should set it so easily, as per what mru just said => a movfourcc != an avifourcc
[23:26:05] <bcoudurier> why would application set it anyway
[23:26:26] <bcoudurier> unless for specific use case that are way to particular
[23:27:31] <bcoudurier> problem is ffmpeg here IMHO, always setting it even trans-formats
[23:27:46] <BBB> I agree
[23:27:53] <bcoudurier> moving that logic in libavformat was a bad choice and it broke the mov case
[23:27:58] <bcoudurier> and I'm pissed off
[23:28:17] <mru> given an AVCodecContext, there's now way to know what the codec_tag means
[23:28:25] <mru> for that you need to know what set it
[23:28:43] <bcoudurier> that's true
[23:28:58] <bcoudurier> you can move codec_tag to AVStream
[23:29:17] <bcoudurier> although decoders need it to decode some XVID or some other mpeg4 variants
[23:29:18] <mru> but that breaks the decoder workarounds triggered by specific tag values
[23:29:59] <BBB> "move into libavformat" == validate_codec_tag()?
[23:30:05] <BBB> that function looks fishy
[23:31:56] <bcoudurier> mru, that's why you would need both
[23:32:03] <bcoudurier> on in AVCodecContext and one in AVStream
[23:40:47] <BBB> alternatively you can simply create more codec_ids
[23:41:03] <mru> ?
[23:41:30] <BBB> CODEC_ID_XVID, CODEC_ID_DIVX for the divx/xvid-specific workarounds, same for VP30 and so on (quick grep showed some more)
[23:41:38] <BBB> maybe that's a bad idea, can quickly get out-of-hand
[23:42:01] <mru> that is ridiculous
[23:42:05] <mru> one codec, one id
[23:43:53] <BBB> is there a proper way to "port" commits from videolan.git to ffmpeg.git?
[23:44:02] <BBB> or just "resend the same patch+commitmsg"?
[23:44:07] <j-b> git remote add ...
[23:44:16] <j-b> git remote update
[23:44:19] <j-b> git cherry-pick
[23:45:20] <BBB> do you have a highlight set whenever someone says videolan, j-b? :-p
[23:46:20] <j-b> no
[23:46:31] <j-b> I have a script that tells me what is the channel most active
[23:48:40] <Jumpyshoes> that's pretty cool. xchat?
[23:49:04] * mru has 12 monitors on the wall, each showing a different channel
[23:49:34] <mmu> ah so that's what those beagleboards are doing the other 363 days of the year ?
[23:49:49] <kierank> mru: nice
[23:49:50] <mru> oh, and everything you hear on irc is true
[23:50:04] <mmu> of course it is
[23:50:33] <BBB> I don't believe that without pics
[23:50:39] <mru> nor should you
[23:50:50] * lu_zero won't believe w/out being there
[23:51:37] <BBB> hm, git cherry-pick is kinda nice
[23:51:40] <mru> if you ever come to visit, I'll make sure to hook up every monitor I have
[23:51:41] <BBB> sorry for the spam on -devel now
[23:52:32] <BBB> testing my git fu
[23:54:58] <BBB> ugh I didn't understand that 'y' is not the same as 'a', I forgot to send the rest :-p
[23:55:33] <mru> fu not so good
[23:55:41] <lu_zero> nite
[23:56:11] <BBB> bye lu_zero
[23:56:21] <BBB> mru: it's getting there...
[23:56:26] <BBB> I know what cherry-pick does now
[23:56:27] <BBB> I know -s
[23:58:29] <BBB> hm... merge
[23:58:31] <BBB> how do I merge
[23:58:47] <mru> rebase -i
[23:58:48] <BBB> extra handicap: I've got a baby on my lap