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

[irc at mansr.com]

[00:04:23] <kierank> http://www.youtube.com/watch?v=1Nrk3zOUhxc
[00:36:44] <Dark_Shikari> astrange: yeah, this reduces it from 16 unpredictable branches to N predictable ones, where N is the number of coded blocks
[00:41:33] <iive> Dark_Shikari: i have idea for much smaller optimization. in the single case. the old code is if( nnz) { if(nnz==1) {idct_dc} else {idct} } . Here the problem is that you have 2 branches to get to the most common and slow case. it can be just one.
[00:42:34] <iive> if (nnz>1) {idct} else if(nnz==1) {idct_dc}
[00:43:48] <Dark_Shikari> no, the most common case is no idct probably
[00:44:00] <iive> it is also the fastest.
[01:50:16] <BBB> ruggles: can you review "[PATCH 1/2] spdifenc: IEC 61937 encapsulation of DTS-HD for HDMI" and see if it makes sense?
[01:50:44] <mru> Dark_Shikari: I'll create those macros next week if you need them
[01:51:11] <Dark_Shikari> mru: it's not critical, but they REALLY should eixst.
[01:51:13] <Dark_Shikari> *exist
[01:51:16] <Dark_Shikari> I can't imagine why they wouldn't.
[01:52:51] <mru> never got round to doing it
[01:53:01] <Dark_Shikari> can you do it sometime then?
[01:53:17] <mru> sure, next week
[01:53:22] <Dark_Shikari> k
[01:53:27] <mru> at fosdem now
[01:55:45] <Dark_Shikari> k
[03:06:10] <Daemon405> oh mru. poke.
[03:06:18] <Daemon405> i was told to poke you for arm docs
[05:28:56] <Dark_Shikari> BBB: another patch up for review...
[08:02:30] <elenril> Flameeyes: ping
[08:38:28] <_av500_> gm
[08:47:15] <Dark_Shikari> die gcc die
[08:47:16] <Dark_Shikari>   36b5:       c1 eb 08                shr    ebx,0x8
[08:47:17] <Dark_Shikari>   36b8:       85 db                   test   ebx,ebx
[08:51:01] <iive> 4.5?
[08:51:49] <Dark_Shikari> 4.3.4
[08:57:23] <astrange> i think i saw a commit about that, but i don't remember if it was in 4.5 or 4.6
[08:58:18] <Dark_Shikari> hmm, another annoying thing I ran into
[08:58:27] <Dark_Shikari> if I loop over 4 dct blocks (x = 0; x < 4; x++), gcc unrolls my loop
[08:58:30] <Dark_Shikari> this is good, it helps speed.
[08:58:38] <Dark_Shikari> if I add an early termination condition, i.e. if(!nnz4) break;
[08:58:40] <Dark_Shikari> this helps too, it's good
[08:58:45] <Dark_Shikari> But now we have two REDUNDANT termination conditions
[08:58:47] <Dark_Shikari> the x<4 is needless.
[08:58:56] <Dark_Shikari> ... but if I remove the x<4, gcc isn't smart enough to unroll anymore.
[08:59:02] <Dark_Shikari> Since, naturally, it doesn't know the loop can only go 4 times.
[08:59:14] <Dark_Shikari> So one has to actively keep redundant information in the code to make gcc generate fast code, ugh.
[10:30:48] <Dark_Shikari> mru: can you review the MC chroma NEON patch on x264-devel?
[10:31:23] <mmu_man_> plop from the Haiku booth at FOSDEM (in front of AW1.117)
[10:31:37] <mmu_man_> building ffmpeg on Haiku atm
[10:32:34] <kshishkov> Dark_Shikari: too hard to review anything here, too noisy
[10:34:48] <Dark_Shikari> is mru at fosdem?
[10:36:28] <_av500_> yes
[10:36:53] <_av500_> all the cool people are
[10:37:09] <peloverde> I wish I was
[10:37:52] <_av500_> you was last year, it does not rub off so quickly
[10:38:57] <thresh> _av500_: hey. Met another Kostya yet? :)
[10:39:40] <_av500_> thresh: nope
[10:39:46] <_av500_> but i am not at the booth
[10:39:53] <_av500_> personell there has been instructed
[10:41:13] <mmu_man_> it worked actually \o/
[10:48:24] <mru> Dark_Shikari: I'll look at it later, hard to focus here at fosdem
[10:48:33] <Dark_Shikari> k, no problem
[10:48:34] <Dark_Shikari> no rush
[10:48:38] <elenril> how do i disable all warning except deprecations?
[10:48:39] <Dark_Shikari> already told the author review would be delayed
[10:49:40] <mru> elenril: -w -Wdeprecated ?
[10:49:49] <mru> or similar
[10:52:05] <elenril> doesn't work
[10:52:13] <elenril> good old grep to the rescue
[11:13:03] <siretart> FFmpeg BOF starting right now!
[11:13:43] <Dark_Shikari> BOF?
[11:15:11] <siretart> birds of a feather session
[11:19:41] <elenril> http://pastebin.com/eh4Sx3gi << why doesn't this work?
[11:19:45] * elenril fails at macros
[11:20:57] <_av500_> siretart: ben is heading your way
[11:26:03] <spaam> elenril: yo dude.. can you try use an empty line between the stuff you quote and your text? :)
[11:30:47] <_av500_>  
[11:30:48] <_av500_> ok
[12:13:25] <_av500_> thresh: no pickup yet :(
[12:17:57] <thresh> _av500_: meh :/
[13:07:32] <Dark_Shikari> fucking facepalmy facepalm
[13:07:40] <Dark_Shikari> someone was using libx264 through lavc and they got vbv underflows every time
[13:07:48] <Dark_Shikari> turned out that rc_initial_buffer_occupancy is by default 0 in libavcodec (?!?!!)
[13:07:56] <Dark_Shikari> i.e. vbv starts empty, i.e. impossible situation
[13:08:00] <Dark_Shikari> ... but why doesn't ffmpeg break?
[13:08:03] <Dark_Shikari> because ffmpeg.c sets it.
[13:08:18] <Dark_Shikari> The only thing worse than non-codec-specific defaults is defaults which are broken and have to be fixed by the calling app.
[13:08:21] <Dark_Shikari> for fuck's sake.
[13:08:39] <Dark_Shikari> (and by broken defaults, I mean defaults that don't even tell you that they're broken, and just silently fail)
[13:08:47] <elenril> send patches!
[13:16:26] <elenril> ok, time to whore some git blame points
[13:18:34] <elenril>  156 files changed, 3828 insertions(+), 3741 deletions(-) bwahahaha
[13:31:01] <lu_zero> uhm
[13:31:37] <spaam> elenril: Nice
[13:33:18] <Flameeyes> elenril: pong
[13:33:45] <elenril> Flameeyes: you said something about interlib ff_ dependencies
[13:33:58] <elenril> how do i find those?
[13:35:31] <Flameeyes> elenril: I posted about it one or two weeks ago.. sec
[13:35:55] <Flameeyes> search for "Interlib non-public dependencies"
[13:36:37] <CIA-38> ffmpeg: Alexander Strange <astrange at ithinksw.com> master * re8dcd73058 ffmpeg/libavcodec/vp3.c:
[13:36:38] <CIA-38> ffmpeg: vp3: Factor out expression
[13:36:38] <CIA-38> ffmpeg: Signed-off-by: Ronald S. Bultje <rsbultje at gmail.com>
[13:36:49] <CIA-38> ffmpeg: James Zern <jzern at google.com> master * r60ff9de6ff ffmpeg/cmdutils.c:
[13:36:49] <CIA-38> ffmpeg: cmdutils: fix codec-specific options from preset
[13:36:49] <CIA-38> ffmpeg: Using a preset file caused the address of a stack variable to be stored
[13:36:49] <CIA-38> ffmpeg: in opt_names/values. This change causes the strings to be dup'd then
[13:36:50] <CIA-38> ffmpeg: freed in uninit_opts.
[13:36:50] <CIA-38> ffmpeg: Signed-off-by: Ronald S. Bultje <rsbultje at gmail.com>
[13:36:52] <CIA-38> ffmpeg: Alexander Strange <astrange at ithinksw.com> master * redbb0c0708 ffmpeg/libavcodec/vp3.c:
[13:36:52] <CIA-38> ffmpeg: vp3: Move table allocation code into a new function
[13:36:52] <CIA-38> ffmpeg: Signed-off-by: Ronald S. Bultje <rsbultje at gmail.com>
[13:36:54] <CIA-38> ffmpeg: James Zern <jzern at google.com> master * r3a6a9cdf5b ffmpeg/ (cmdutils.c ffmpeg.c):
[13:36:54] <CIA-38> ffmpeg: cmdutils: fix opt_values leak
[13:36:54] <CIA-38> ffmpeg: Add free to uninit_opts and relocate opt_names to same
[13:36:54] <CIA-38> ffmpeg: Signed-off-by: Ronald S. Bultje <rsbultje at gmail.com>
[13:36:56] <CIA-38> ffmpeg: Peter Ross <pross at xvid.org> master * re4f85b8499 ffmpeg/libavformat/wtv.c:
[13:36:56] <CIA-38> ffmpeg: wtv: do not use flag in stream_guid chunk to determine if stream is valid, as this method is unreliable
[13:36:56] <CIA-38> ffmpeg: This fixes roundup issue 2556.
[13:36:56] <CIA-38> ffmpeg: Signed-off-by: Ronald S. Bultje <rsbultje at gmail.com>
[13:37:05] <CIA-38> ffmpeg: Kieran Kunhya <kieran at kunhya.com> master * rf4a86bc981 ffmpeg/libavcodec/mpegaudiodec.c:
[13:37:05] <CIA-38> ffmpeg: Set channel_layout for mpegaudio
[13:37:05] <CIA-38> ffmpeg: Signed-off-by: Ronald S. Bultje <rsbultje at gmail.com>
[13:37:07] <CIA-38> ffmpeg: Nicolas George <nicolas.george at normalesup.org> master * rad3cffb68f ffmpeg/libavformat/tcp.c:
[13:37:07] <CIA-38> ffmpeg: Non-blocking protocol: TCP
[13:37:07] <CIA-38> ffmpeg: Signed-off-by: Nicolas George <nicolas.george at normalesup.org>
[13:37:07] <CIA-38> ffmpeg: Signed-off-by: Ronald S. Bultje <rsbultje at gmail.com>
[13:37:08] <CIA-38> ffmpeg: Anton Khirnov <anton at khirnov.net> master * r5a6de4e7e8 ffmpeg/libavformat/mp3enc.c:
[13:37:08] <CIA-38> ffmpeg: mp3enc: write ISO8859-1 instead of UTF-16 when possible
[13:37:08] <CIA-38> ffmpeg: Signed-off-by: Ronald S. Bultje <rsbultje at gmail.com>
[13:37:12] <CIA-38> ffmpeg: Nicolas George <nicolas.george at normalesup.org> master * rfe174fc8fc ffmpeg/ (doc/APIchanges libavformat/avio.h):
[13:37:12] <CIA-38> ffmpeg: Non-blocking protocols: flag and documentation
[13:37:12] <CIA-38> ffmpeg: Signed-off-by: Nicolas George <nicolas.george at normalesup.org>
[13:37:12] <CIA-38> ffmpeg: Signed-off-by: Ronald S. Bultje <rsbultje at gmail.com>
[13:37:14] <CIA-38> ffmpeg: Peter Ross <pross at xvid.org> master * r74571e333c ffmpeg/libavformat/wtv.c:
[13:37:14] <CIA-38> ffmpeg: reindent after last commit
[13:37:14] <CIA-38> ffmpeg: Signed-off-by: Ronald S. Bultje <rsbultje at gmail.com>
[13:37:16] <CIA-38> ffmpeg: Anton Khirnov <anton at khirnov.net> master * rc2fcd0a7a4 ffmpeg/ (14 files in 2 dirs):
[13:37:16] <CIA-38> ffmpeg: Replace remaining occurrences of deprecated CH_* with AV_CH_*
[13:37:16] <CIA-38> ffmpeg: Signed-off-by: Ronald S. Bultje <rsbultje at gmail.com>
[13:37:19] <CIA-38> ffmpeg: Nicolas George <nicolas.george at normalesup.org> master * r90441276e4 ffmpeg/libavformat/ (avio.c avio.h):
[13:37:19] <CIA-38> ffmpeg: Non-blocking protocol: core wrapper functions
[13:37:19] <CIA-38> ffmpeg: Signed-off-by: Nicolas George <nicolas.george at normalesup.org>
[13:41:10] <elenril> Flameeyes: http://blog.flameeyes.eu/2011/01/20/hide-those-symbols this?
[13:41:23] <Flameeyes> elenril: nope on the ffmpeg-devel mailing list ;)
[13:42:01] <elenril> heh
[13:42:15] <elenril> i guess i'll read that anyway
[13:43:20] <elenril> Flameeyes: were all those patches applied btw?
[13:43:31] <Flameeyes> elenril: probably not all, let me see which ones are not merged yet
[13:43:34] <elenril> i think at least the id3v2 one wasn't
[13:44:00] <elenril> ha, found it
[13:47:26] <elenril> so what should we do with all the url_ stuff
[13:48:33] <elenril> it's semi-public now
[13:49:45] <Flameeyes> I suppose rename and alias it?
[13:50:52] <elenril> well it's consistenly using the url_ prefix :)
[13:51:16] <elenril> we could just declare it as yet another lavf-reserved prefix
[13:51:25] <BBB> s/url_/avio_/g
[13:51:25] <Flameeyes> likely colliding with other stuff
[13:51:30] <BBB> url_ is too generic
[13:51:35] <Flameeyes> what BBB said
[13:51:50] <BBB> ffmpeg's "namespace" is av{,format,codec,filter,io}_*
[13:52:13] <BBB> we can add more things inside that {} if necessary
[13:52:24] <BBB> but url doesn't fit that description :-p
[13:52:38] <Flameeyes> don't underestimate the nastiness of symbol collisions!
[13:52:47] <BBB> I've seen it happen once or twice
[13:53:03] <BBB> it's nearly impossible to figure out on released software
[13:53:26] <BBB> in debugging mode, it's not too difficult, but then again, how many contributors debug a version of ffmpeg linked to 20 external libs?
[13:53:40] <BBB> we don't, and that's exactly why this is problematic :-p
[13:53:52] <Flameeyes> BBB: I learnt about it when I maintained xine
[13:54:00] <Flameeyes> because of ffmpeg's linking to faad
[13:54:45] <Flameeyes> xine (or amarok) crashed when reproducing an aac file.. but only on some systems.. but not on mine
[13:54:59] <BBB> kshishkov: I think reimar and I are right, I know it's unlikely but src+offset can overflow if src is in the address space 0xffffxxxx
[13:55:19] <BBB> kshishkov: please change it :-p and I'll apply, I'm in commit-mode anyway now
[13:55:27] <Flameeyes> until I tried the -Bdirect patches coming from suse... and when looking at that I could see the symbols being loaded from the wrong objet
[13:55:31] <Flameeyes> *object
[13:55:53] <BBB> and you go like "YOU FUCKING #$^&#%^#%"
[13:56:09] <Flameeyes> BBB: the good news are that I have tools to be able to find those situations before they even cause runtime failures :D
[13:56:34] <Flameeyes> the sad news is that one xiph^Wghostscript idiot could have preemptively solved a bug three years ago but decided to ignore me
[13:58:40] <elenril> BBB: feel like reading and applying my avio patches? ;)
[13:58:55] <Flameeyes> elenril: http://paste.pocoo.org/show/333063/ these are those not merged and still applying fine
[13:59:47] <BBB> ignore freeing opt_names?
[14:00:05] <BBB> but yes they should be static
[14:00:16] <BBB> that patch likely doesn't apply anymore, please re-check
[14:00:41] <Flameeyes> elenril: uhm you probably don't want to break ABI there, so you'd need compatibility aliases until the abi is actually bumped, or am I missing something?
[14:01:06] <Flameeyes> yes I was missing a hunk while searching, sorry
[14:01:07] <elenril> Flameeyes: they're there
[14:01:09] <BBB> he's right, I think mplayer uses it
[14:01:34] <Flameeyes> BBB: more than that, put_buffer is actually quite used in the wild (see the other post on the ml with the list of used non-prefixed symbols)
[14:01:35] <BBB> also "      Make inter_rvlc and intra_rvlc static tables." had a comment that you should be looking at
[14:02:14] <Flameeyes> BBB: let me check
[14:02:26] <BBB> ff_init_cabac_encoder is part of the h264 "encoder"
[14:02:31] <BBB> we should be removing that kind of code
[14:02:35] <BBB> anyone interested?
[14:02:48] <Flameeyes> BBB: uhm I think I also replied
[14:02:53] <BBB> I don't see your reply
[14:03:12] <BBB> maybe I screwed up and deleted the email on my iphone
[14:03:24] <BBB> iphone/gmail can fuck up threading or delete individual messages
[14:03:45] <Flameeyes> let me see if I find the one I sent
[14:03:54] * Flameeyes is hating on OpenSSH today
[14:04:44] <Flameeyes> BBB: for whatever reason it ended up just to you rather than to the list, and it was mostly a TODO for myself to make sure that they won't cause increase in the code size
[14:04:51] <Flameeyes> give me a moment to restore a sane openssh on my systems
[14:08:57] <BBB> ok :)
[14:09:09] <BBB> that one I received, but that was indeed not a new patch
[14:14:07] <elenril> +2011-02-XX - XXXXXXX - lavf 52.XX.0 - avio.h
[14:14:12] * elenril diagnoses BBB with ADHD
[14:15:02] <BBB> ?
[14:15:09] <elenril> this is what you just committed
[14:15:10] <BBB> I did that?
[14:15:13] <BBB> oops
[14:15:19] <elenril> fe174fc8fc4bbdb050014a945de7eb9b28ba358e
[14:17:31] <BBB> got it, will fix
[14:19:55] <BBB> adhd fixed
[14:20:07] <CIA-38> ffmpeg: Ronald S. Bultje <rsbultje at gmail.com> master * refdd67cb00 ffmpeg/ (doc/APIchanges libavformat/version.h): Update MINOR and set git rev for non-blocking flag API addition.
[14:20:18] <BBB> long live cocaine^dritalin
[14:20:32] * Flameeyes mutters something bad about openssh
[14:21:01] <elenril> Flameeyes: what did it do to you?
[14:21:58] <Flameeyes> elenril: I use my main box via ssh.. usually it's all fine, today I connect, launch a sync, it freezes
[14:22:12] <Flameeyes> I reboot, try again, it freezes
[14:22:53] * elenril used to see some freezing when running commands with long output, like dmesg
[14:23:05] <elenril> then they just disappeared after a reboot
[14:23:16] <Flameeyes> I kill it, rebuild without hpn (a Gentoo feature), and still again
[14:24:59] <Flameeyes> ah shmuck, I don't have !env_reset on raven, it's still hpn-enabled.. disabling it again
[14:28:55] <elenril> wtf is an avf_ prefix
[14:30:07] * elenril and git blames lu_zero
[14:30:40] <elenril> eew, what are those ffserver-specific hacks doing in avformat.h
[14:35:43] <Flameeyes> BBB: okay.. my patch there can't make the situation worse than it was before given that inter_rvlc is used only together with inter_rvlc_run and inter_rvlc_level to declare a (non-static) rvlc_rl_inter
[14:36:13] <Flameeyes> which is only ever used in mpeg4videodec
[14:36:34] <Flameeyes> the same goes for intra
[14:40:32] <elenril> BBB: still slighly hyperactive, you forgot the date ;)
[14:45:48] <BBB> elenril: we need a git pull checker script or so
[14:46:21] <elenril> indeed
[14:46:52] <CIA-38> ffmpeg: Ronald S. Bultje <rsbultje at gmail.com> master * rae0f8a1a33 ffmpeg/doc/APIchanges: Fill in missing date.
[14:47:45] <elenril> that's all folks, no more unprefixed functions in avformat.h
[14:48:47] <Flameeyes> BBB: you got mail
[14:50:16] <BBB> Flameeyes: oh, only one, I misread my own grep indeed
[14:50:24] <BBB> keep it as a header, it's fine then
[14:50:28] <Flameeyes> BBB: I suggest you add --color=auto to your grep alias :D
[14:50:57] <Flameeyes> BBB: I'm still not sure why they're emitted on mpeg4video.o if they are only used by videodec though
[14:52:40] <BBB> don't know
[14:53:13] <BBB> will commit
[14:55:08] <BBB> done
[14:55:13] <CIA-38> ffmpeg: Diego Elio Pettenò <flameeyes at gmail.com> master * r84ae8936f6 ffmpeg/libavcodec/ (mpeg4data.h mpeg4video.h):
[14:55:13] <CIA-38> ffmpeg: Make inter_rvlc and intra_rvlc static tables.
[14:55:13] <CIA-38> ffmpeg: Signed-off-by: Ronald S. Bultje <rsbultje at gmail.com>
[14:55:40] <Flameeyes> thanks, will see if it makes some difference to actually move those tables though
[14:55:47] <BBB> it won't make a difference
[14:55:52] <BBB> we do this for a lot of files
[14:55:59] <BBB> (formats/codecs/...)
[14:56:06] <BBB> e.g. wmavoice, lots of other decoders also
[15:07:32] <Flameeyes> it does make a slight different: it increases the code size by 12 bytes and reduces the data size
[15:40:52] <BBB> Flameeyes: stripped or unstripped binary?
[15:41:09] <Flameeyes> BBB: both unstripped
[15:43:22] <Flameeyes> BBB: fwiw it should make the same exact difference on the stripped ones, just the overhead would be smaller
[15:43:36] <BBB> can you strip them and re-check?
[15:43:54] <BBB> (nobody cares much about datasize on an unstripped binary; if you did, you'd strip them)
[15:45:53] <Flameeyes> sure... not sure if you got what my stats meant though ;)
[15:45:55] <BBB> elenril: probably stupid, but as you deprecate symbols and add av_() variants, can you also ensure that there's doxy in them so we actually know what they do?
[15:46:02] <Flameeyes> http://paste.pocoo.org/show/333102/
[15:46:20] <Flameeyes> BBB: rbelf-size only counts allocated sections, *not* the whole file's size
[15:46:30] <Flameeyes> the stuff that's stripped is never allocated
[15:48:29] <BBB> I see
[15:48:35] <BBB> I guess I still don't really know what it means
[15:48:38] <BBB> the filesize is identical
[15:48:42] <BBB> rodata is slightly changed...
[15:49:06] <BBB> so bak is with header, non-bak is in source file?
[15:49:20] <Flameeyes> yes
[15:49:55] <Flameeyes> sections in the file are 4KiB-padded, thys why filesize is the same
[15:52:18] <Flameeyes> as I said it's mostly a point of discussion; if it's just those two symbols it makes no difference
[15:52:22] <Flameeyes> but 10 symbols like these? 100?
[15:52:39] <_av500_> thresh: we are go!!!!
[15:55:40] <Flameeyes> _av500_: you're gone?
[15:57:07] <BBB> Flameeyes: it makes no sense that moving a table from h to c would change anything, except ordering...
[15:57:28] <Flameeyes> BBB: sure it makes, if you also make it static contextually
[15:57:35] <Flameeyes> a static symbol is not exposed
[15:57:52] <BBB> it is already static and const
[15:57:55] <Flameeyes> which means that the compiler can trick it a bit further _and_ you no longer have it on the PLT
[15:58:01] <Flameeyes> the RLTable objects aren't
[15:58:29] <BBB> ah
[15:58:42] <thresh> _av500_: crap :/
[15:59:02] <BBB> so make them staticconst
[15:59:08] <BBB> in the hdr
[15:59:09] <Flameeyes> they don't seem to be const
[15:59:16] <Flameeyes> and no I can't make them staticconst in the header
[15:59:22] <BBB> ?
[15:59:24] <Flameeyes> because the header is included by _another_ source file
[15:59:39] <Flameeyes> which means that you have mpeg4video.o exposing the two symbols and mpeg4videodec.o using them
[15:59:44] <Flameeyes> mpeg4video.o does not use them at all
[15:59:52] <Flameeyes> which is why I thought it was absurd
[16:04:27] <BBB> i will chech, 1 sec
[16:13:47] <BBB> I see...
[16:13:49] <BBB> hmm...
[16:13:50] <BBB> sucks
[16:13:55] <BBB> I don't want to add tables into source files
[16:13:59] <BBB> I hate that
[16:14:03] <BBB> can we make a new .h file?
[16:23:07] <kierank> any good presentations at fosdem
[16:24:29] <Flameeyes> BBB: sure thing
[16:44:21] <CIA-38> ffmpeg: Anssi Hannula <anssi.hannula at iki.fi> master * r48545a8f72 ffmpeg/configure:
[16:44:21] <CIA-38> ffmpeg: configure: check yasm/nasm for working pextrd opcode
[16:44:21] <CIA-38> ffmpeg: NASM versions older than 2.08 fail to build ffmpeg with several
[16:44:21] <CIA-38> ffmpeg: "error: operation size not specified" errors but this is not caught in
[16:44:21] <CIA-38> ffmpeg: configure.
[16:44:22] <CIA-38> ffmpeg: Fix that by checking if "pextrd [eax], xmm0, 1" works in configure.
[16:44:22] <CIA-38> ffmpeg: Signed-off-by: Ronald S. Bultje <rsbultje at gmail.com>
[16:48:34] <kierank> "Sorry for the delays but encoding 1080i streams in Theora takes a lot of CPU power."
[16:49:25] <JEEB> LOL
[16:55:11] <Flameeyes> michaelni: let's be clear you can dislike a change as much as you wish and call it bad, but that change isn't by itself "wrong". Especially not when I have made it clear that it's _not_ to be applied but just a point open for discussion.
[16:59:24] <ohsix> isn't it implicit that one phase is for comments/discussion, and another is for requesting it be added?
[17:00:34] <Flameeyes> ohsix: more or less, sometimes it's better to make it clear — in this case I was looking for comments on the general effect of doing the change, rather than simply having it reviewed
[17:01:01] <Flameeyes> as it makes no sense whatsoever to do it for just two symbols: the changes are so small that don't warrant even the commit effort
[17:12:12] <michaelni> Flameeyes, it says [PATCH] not [RFC] in the subj
[17:12:33] <michaelni> and it is by itself wrong btw
[17:14:14] <Flameeyes> and if you can see my own reply to the patch says I forgot an RFC in it
[17:15:07] <Flameeyes> so instead of digging your own grave by upsetting more people who are not really concerned with the whole powergames at hand, you'd better read and explain yourself
[17:16:04] <michaelni> Flameeyes, ive just now looked at the reply
[17:17:16] <michaelni> Flameeyes, its because this table belongs to mpeg4 not just the decoder
[17:17:38] <michaelni> the encoder side is not implemented, true but its not a big thing to implement
[17:17:56] <michaelni> and it feels quite wrong to me to move such a table to the decoder
[17:18:00] <Flameeyes> michaelni: that doesn't really mean that the patch is wrong; that means the patch is unclean
[17:18:33] <michaelni> well so its unclean, wherfes the difference?
[17:19:12] <ohsix> fit for purpose :D
[17:20:02] <Flameeyes> michaelni: take a suggestion from a neutral person in the whole mess: take a vacation.
[17:20:57] <michaelni> Flameeyes, not an option
[17:21:01] <Flameeyes> _I_ am not partial to either side in general; _I_ haven't accused you of rejecting my patches; _I_ have submitted a patch that you shot down, and then you basically told me you're treating me like shit because somebody else accuses you of something?
[17:21:19] <Flameeyes> I guess that means 'congrats, you just gave one more people an idea on the situation'
[17:21:32] <ohsix> fwiw i didn't know the mail was marked PATCH vs. RFC or otherwise when i made my comment
[17:21:33] <michaelni> i just explained why i thinl the patch is ehm unclean
[17:21:58] <Flameeyes> michaelni: sure, you did here, so what's the bloody point of the reply to my request on ml?
[17:22:16] <Flameeyes> you could well have left it without reply after explaining it here, I was satisfied enough
[17:22:46] <michaelni> have people become so sensitive to flames?
[17:23:26] <elenril> err....the message wasn't clear enough?
[17:23:30] <ohsix> perhaps they're dessicated and highly flamable
[17:23:42] <Flameeyes> I'm not "people"; I'm a specific person who's just trying to lend a hand from time to time in the little extra time I got
[17:24:35] <michaelni> ohsix, you are trolling like always but this time you have a point
[17:24:56] <ohsix> :\
[17:25:03] <elenril> haha
[17:27:00] <elenril> michaelni: where does find_info_tag belong then?
[17:28:06] <michaelni> if its small and usefull outside MM then libavutil if its big and messy libavcore
[17:28:37] <elenril> what if it's big and messy, yet useful outside MM?
[17:28:55] <michaelni> cleanup :)
[17:29:16] <elenril> :effort:
[17:29:35] * elenril has science to do
[17:29:42] <BBB> what kind of science?
[17:29:49] <michaelni> put in avcore when uncertain
[17:30:05] <michaelni> we can move to avutil easier than the other way around
[17:30:07] <elenril> BBB: exams
[17:30:15] <BBB> elenril: in ... what subject?
[17:30:18] <elenril> quantum field theory in curved spacetime
[17:30:28] <elenril> aka the most obscure shamanism ever
[17:32:18] <BBB> that sounds like stuff where you need imagination of 17 dimensions
[17:32:20] <michaelni> elenril, sounds like mixing QM with gravity, do we alraedy have a consistent theory about that that matches reality?
[17:33:27] <elenril> no and no
[17:33:49] <elenril> or well it kinda is mixing QM with gravity, but gravity isn't quantised
[17:33:59] <michaelni> ok so you do an exam of self inconsistent math that doesnt match reality?
[17:34:05] <elenril> it's just there as a classical background
[17:34:50] <michaelni> elenril, are there any experiments that suggest gravity needs to be quantized?
[17:34:53] <elenril> well....thing is, this theory is pretty much untestable under normal circumstances
[17:35:13] <elenril> we'd need some microscopic black holes around ;)
[17:35:28] <elenril> michaelni: general relativity by itself predicts singularities
[17:35:44] * michaelni is interrested in this stuff but doesnt have the math/physics background knowledge sadly
[17:35:48] <elenril> most physicists don't believe it's possible for "real" singularities to exist
[17:36:29] <michaelni> belive has historically not been very reliable
[17:36:32] <elenril> therefore it's expected that a theory that quantises gravity would remove those singularitites
[17:36:53] <kierank> michaelni: http://ocw.mit.edu/
[17:37:36] <michaelni> kierank, thanks, now i know what ill do when i resign :)
[17:43:28] <elenril> saste: care to rebase-resend/ping the av_parse_time patch?
[17:44:12] <elenril> or is there a reason it wasn't applied?
[17:44:27] <iive> michaelni: create artificial black hole and throw root team in it?
[17:45:15] <spaam> kierank: something you read time to time?
[17:45:42] <kierank> the lectures are interesting
[17:45:50] <elenril> kierank: btw how are your studies going?
[17:51:08] * elenril make food
[18:30:02] * Compn sends big quote mail to -devel
[18:36:16] <_av500_> thresh: no, the transaction is a go!
[18:36:26] <_av500_> he came with password and rubels
[18:37:28] <thresh> _av500_: ha awesome, now you can buy our oil as well!
[18:37:50] <j-b> 'lo trolls
[18:38:40] <_av500_> j-b: hi
[18:38:44] <_av500_> thresh: ok, will do
[18:43:22] <mru> j-b: ping
[18:44:23] <j-b> pong
[18:45:10] <mru> j-b: dinner @ thai city, gretrystraat 43, 20:30
[18:45:55] <j-b> might be doable
[18:50:19] <wbs> would anyone be interested in applying the movie source avfilter patch? it was ok'd sometimes last week
[18:50:29] <mru> j-b: btw your phone is off
[18:50:59] <wbs> sure, saste could set up a libavfilter repo somewhere as "subsystem maintainer", but stuff should be pulled into the main repo at some time, and that one should be on the "please merge to master"-queue now
[18:52:35] <Daemon404> mru, !
[18:52:41] <Daemon404> happen to see my poke yesterday?
[18:53:16] <mru> Daemon404: you had some arm query?
[18:53:47] <Daemon404> mru, i was told to poke you for arm specs/docs (instructions, regs, etc)
[18:54:52] <mru> Daemon404: infocenter.arm.com
[18:55:02] <mru> has all the docs
[18:55:10] <Daemon404> i know, do not want (tm)
[18:55:16] <j-b> mru: I know...
[18:55:17] <Daemon404> very annoying to read, couldnt find any pdfs
[18:55:34] <Daemon404> i might end up going through my company trying to obtain paper versions
[18:55:40] <Daemon404> cause paper is infinitely nicer
[18:55:56] <mru> there are pdfs of most docs
[18:56:03] <mru> some are only pdf
[18:56:20] <Daemon404> i might need to get a decent ebook reader
[18:56:25] <Daemon404> pdfs on monitor = :(
[18:56:37] <mru> I don't think they still do paper books
[18:56:45] <Daemon404> that's a shame
[18:56:51] <Daemon404> i always learn better from paper stuff usually
[18:56:57] <Daemon404> doont ask me why.
[18:57:07] <mru> buy a printer
[18:57:21] <Daemon404> i own about 10 of those
[18:59:49] <mru> then I'm afraid I can't help much
[19:00:32] <mru> I'd dcc you some paper but firewall won't allow it
[19:01:40] <mru> j-b: well, come if you can, otherwise maybe we can meet later
[19:02:15] <mru> j-b: will you turn the phone back on?
[19:02:34] <Daemon404> lul
[19:02:56] <Daemon404> hmm which pdf should i be looking at for good descriptions of instructions, registers etc
[19:03:02] <Daemon404> tech ref pdf doesnt seem to be what i want
[19:04:14] <mru> arch ref is the one you want
[19:05:50] <Daemon404> mru, i need a login :V
[19:05:53] <j-b> mru: no, my operator blocked my international roaming
[19:06:50] <j-b> mru: I will move now then
[19:06:53] <_av500_> j-b: u are french, its normal
[19:07:38] <j-b> :)
[19:07:43] <j-b> 20:30, I will be there.
[19:07:51] <_av500_> have fun
[19:08:05] <_av500_> try not to do a revolution
[19:08:21] * elenril overthrows _av500_ 
[19:08:24] <thresh> "reports says French people finished ffmpeg coup"
[19:08:35] <elenril> _av500_: you're not there?
[19:08:44] <j-b> C U soon
[19:09:21] <_av500_> elenril: on my way back
[19:12:08] * Daemon404 waits for slow pdf to dl
[19:15:31] <Daemon404> mru, thanks, this is the exact doc i wanted
[19:30:14] <elenril> I found more than one project taking a library originally in a number of source files, concatenating all of them together, and then building it in a single object file
[19:30:18] <elenril> Flameeyes: ^lolwut?
[19:51:07] <Flameeyes> elenril: yes I know it's a mess but sme people used to do that
[19:51:43] <wbs> although butt ugly, I guess it's a covenient way to bundle a library ;P
[19:52:08] * elenril bundles wbs to rtmpdump
[19:52:16] <wbs> :-(
[19:52:39] <elenril> is it that bad?
[19:53:28] <wbs> nah, it's decent, there's a few quirks I haven't had time to weed out though
[19:53:58] <elenril> wait, i thought you implemented all this stuff in ffmpeg
[19:54:03] <jannau> sigh, more than 300 unread mails on ffmpeg-devel
[19:54:20] <elenril> hi jannau
[19:54:25] <wbs> elenril: no, I've merely fixed 1-2 bugs in the lavf native rtmp code (written by kostya), I've worked most on rtsp/rtp
[19:54:55] <elenril> oh
[19:55:07] <wbs> jannau: I usually dread not watching the ML for a few hours, since it takes forever to catch up again
[19:56:59] * elenril tries to parse Flameeyes' inline symbols mail
[19:57:16] * elenril should learn more elf-fu
[19:57:47] * jannau is on his way back from fosdem and hasn't checked mails mails since friday
[19:58:14] <wbs> jannau: ugh, that'll take a while ;P
[19:58:17] <elenril> feel free to skip all the drama
[19:58:25] <elenril> that's like half of it ;)
[19:59:47] <jannau> I still have 4 hours of train ride home and I've seen already parts of the drama
[20:00:09] * elenril feels he's getting too many branches
[20:00:26] <wbs> elenril: how many do you have?
[20:00:45] <elenril> 16
[20:00:54] <elenril> but some/more are old cruft
[20:00:58] <elenril> s/more/most
[20:01:22] <wbs> I've got 37 ffmpeg branches locally, 55 in my private archive repo
[20:01:26] <elenril> o_0
[20:01:34] * _av500_ waves to jannau in 1st class
[20:01:57] <wbs> some just old cruft, some unfinished features, some almost-finished features, some useful for creating more/less broken output for testing certain conditions, etc
[20:01:58] <thresh> wifi in trains?
[20:02:18] <elenril> хихи in trains
[20:02:26] <thresh> whut?
[20:02:29] <_av500_> 3g
[20:03:12] <thresh> i've got a data plan from my cell provider. 8 euro / month for 128 kbit/sec
[20:03:24] <thresh> they call it 'broadband mobile internet'
[20:03:46] <elenril> sound oxymoron-ish
[20:03:47] <wbs> thresh: here we pay ~13 euro / month for unlimited, full speed mobile internet
[20:04:13] <jannau> we could have made ad-hoc wifi in the train from brussels to cologne/franktfurt
[20:04:17] <_av500_> i am on edge now, not really fast either
[20:04:22] <_av500_> but the train runs 300 atm
[20:04:24] <jannau> it was full of fosdem
[20:04:50] <thresh> wbs: :S
[20:05:11] <thresh> well the catch in my case is they limit the speed to 64 kbit/sec after first gigabyte
[20:05:17] <thresh> cheapskates
[20:05:36] <jannau> here is is more like 15-30 € for 5G
[20:05:46] <wbs> thresh: many operators do something similar here, but at least one still has totally unlimited use
[20:06:14] <_av500_> you can use bottle of wodka as potable hotspot
[20:08:07] <thresh> _av500_: yep, that's what we do when there is a lot of time to be wasted and you have nothing to do, e.g. traveling by train
[20:08:15] <thresh> also call it 'the time machine'
[20:10:30] <_av500_> ic
[20:30:24] <spaam> elenril_: yo?
[20:30:39] * elenril_ kicks freenode
[20:31:32] <spaam> :)
[20:46:28] <jannau> what's the sudden interest in libfaac on libav-user?
[20:51:49] <peloverde> "since FAAC is an LGPL modification of the ref s/w), it looks like we may get clearance from 'legal' to use libfaac also."
[20:52:10] <peloverde> what? it's impossible to satisfy both licenses simultaneously
[20:55:02] <jannau> es exactly
[20:55:05] <jannau> yes
[20:55:12] <jannau> stupid 3g
[21:08:14] <elenril> wtf, arpi commenting on my patches
[21:08:20] <elenril> what did i ever do to him
[21:11:10] <merbanan> are the comments valid ?
[21:11:38] <elenril> a little nitpicky, but yes
[21:13:14] <merbanan> just address them then, end of story
[21:17:46] <CIA-38> ffmpeg: Reimar Döffinger <git at videolan.org> master * ra351110eea ffmpeg/libavformat/ (8 files):
[21:17:46] <CIA-38> ffmpeg: Always use av_set_pts_info to set the stream time base.
[21:17:46] <CIA-38> ffmpeg: Signed-off-by: Ronald S. Bultje <rsbultje at gmail.com>
[21:17:49] <CIA-38> ffmpeg: Sascha Sommer <saschasommer at freenet.de> master * red19fafd48 ffmpeg/ (libavcodec/avcodec.h libavformat/isom.c libavformat/mov.c):
[21:17:49] <CIA-38> ffmpeg: pass QDMC extradata to the decoder
[21:17:49] <CIA-38> ffmpeg: Makes playing QDMC files in MPlayer work when using the libavformat demuxer.
[21:17:49] <CIA-38> ffmpeg: Problem was that the extradata was not passed from demuxer to decoder.
[21:17:49] <CIA-38> ffmpeg: Signed-off-by: Ronald S. Bultje <rsbultje at gmail.com>
[21:17:53] <CIA-38> ffmpeg: Reimar Döffinger <Reimar.Doeffinger at gmx.de> master * rb3190529df ffmpeg/libavformat/ (avformat.h utils.c):
[21:17:53] <CIA-38> ffmpeg: Make av_set_pts_info keep previous time base if new one is invalid.
[21:17:53] <CIA-38> ffmpeg: Fixes issue 2475.
[21:17:53] <CIA-38> ffmpeg: Signed-off-by: Ronald S. Bultje <rsbultje at gmail.com>
[21:18:29] <BBB> elenril: that's fantastic, a real contribution from him, that's exactly what we wanted :)
[21:18:32] <BBB> (not even joking!)
[21:22:35] <elenril> libavformat/mpeg.c:405:17: warning: implicit declaration of function 'ff_reduce_index' is invalid in C99 [-Wimplicit-function-declaration]
[21:22:40] <elenril> who did that?
[21:22:58] * elenril found this while searching for more includes he missed
[21:23:19] <spaam> maybe arpi wants to join the ffmpeg team ;D
[21:24:53] <thresh> or have a right of voice in fflames
[21:24:58] <BBB> elenril: you, you moved ff_reduce_index from avformat.h to internal.h
[21:25:03] <BBB> elenril: I didn't apply that yet
[21:25:23] <elenril> oops :)
[21:25:38] * BBB slaps elenril 
[21:25:50] <elenril> but we have so many warnings
[21:26:26] <BBB> 2>&1|grep ff_reduce or 2>&1 | grep ff_the_other_symbol
[21:26:30] <jannau> that's supposed to be an error
[21:26:52] <elenril> i did grep implicit now
[21:27:10] <jannau> get a compiler which supports -Werror=implicit-function-declaration
[21:27:35] * elenril uses clang
[21:27:38] <elenril> it has nice colors
[21:28:17] <spaam> so thats why you use it? :)
[21:28:25] <elenril> of course
[21:28:33] <drv> colorgcc ;)
[21:28:43] <elenril> is there any other factor in choosing a compiler?
[21:29:06] <spaam> i dont think so
[21:31:48] <BBB> elenril: generates faster code?
[21:31:56] <BBB> then again who needs fast code
[21:32:13] <elenril> fast code is overrated
[21:44:55] <_av500_> home
[21:58:13] <jannau> currently 13 minutes late but 1/2 coach for me alone