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

[irc at mansr.com]

[00:00:21] <spaam> mru: some ppl say it like that :)
[00:04:39] <{V}> is FÃ¥n also a real word in .se or just an almost homophone (no pun intended) ?
[00:05:07] <mru> it's a word
[00:05:18] <mru> sort of, at least
[00:09:14] <{V}> is google translate correct when it says it means idiot?
[00:09:29] <mru> that's one meaning
[00:10:05] <{V}> punny
[00:19:33] <lu_zero> mru: where that?
[00:19:57] <lu_zero> we have a sockaddr_storage in os_support iric
[00:20:46] <mru> lu_zero: yes, and it's being triggered in error
[00:20:50] <mru> on qnx
[00:21:00] <lu_zero> qnx does have the struct...
[00:21:08] <mru> apparently, yes
[00:21:13] <lu_zero> but
[00:21:23] <mmu> who cares about QNX ? :p
[00:21:24] <lu_zero> in the obviously wrong header...
[00:21:33] <lu_zero> RIM does
[00:21:37] <lu_zero> oh well
[00:22:13] * lu_zero doesn't have a qnx available...
[00:22:17] * mru does
[00:22:23] <lu_zero> and the sources disappeared...
[00:22:38] <lu_zero> mind using either gcc -E or grep to figure where it got defined?
[00:24:01] <mru> it's in sys/socket.h but under _XOPEN_SOURCE >= 500
[00:24:13] <mru> and #if 1 for good measure
[00:25:20] <lu_zero> O_o
[00:26:53] <mru> what's worse is memalign() is broken
[00:27:07] <mru> it fails to align properly on certain magic sizes
[00:27:33] <lu_zero> ...
[00:27:39] <lu_zero> which qnx is that one?
[00:27:50] <mru> 6.5.something
[00:27:57] <mru> whatever was the latest a few months ago
[00:28:19] <mru> 32674, 94070, 143237, 532396, 573392 all fail to 16-byte align
[00:28:27] <mru> most likely others too
[00:28:49] <Anaerin> lu_zero, Want a QNX? here! ftp://213.191.222.2/Inet/QNX/
[00:29:11] <mru> qnx is free for non-commercial use
[00:29:14] <mru> but not open source
[00:29:36] <Anaerin> mru, I know. That's a link to the old "1.44mb floppy" QNX demo disk(s).
[00:29:42] <mru> ah
[00:33:17] <lu_zero> qnx apache sources are opensource...
[00:33:27] <lu_zero> pity nobody cared that much
[00:33:47] <mru> you still get some source
[00:33:57] <mru> most of the kernel for instance
[00:37:55] <lu_zero> anyway seems broken beyond normal checks...
[00:38:48] <mru> -D_QNX_SOURCE seems to take care of the headers
[00:40:34] <lu_zero> uh
[00:40:36] <lu_zero> right
[00:40:55] <lu_zero> that was something I had to do when playing with momentics
[00:41:04] <mru> buggy memalign is another matter
[00:45:41] <lu_zero> that should be reported
[00:45:57] <lu_zero> posix_memalign works better?
[00:46:01] <mru> same
[00:46:12] <mru> I suppose one is just a wrapper around the other
[00:49:40] <bcoudu> humm valgrind still broken on osx with xcode 4 :(
[00:51:12] <mru> one more qnx quirk: SA_RESTART isn't defined
[00:51:28] <mru> commented out in signal.h
[00:53:00] <DonDiego> gnite
[02:10:53] <Dark_Shikari> BBB: what's the x86_64 stuff in the top of your patch
[02:21:43] <TheFluff> does anyone know why almost every single packet and table field in the mpeg ts spec seems to have the mnemonic "bslbf"
[02:21:49] <TheFluff> (what does it even stand for)
[02:28:17] <bcoudu> see 2.2.6 Mnemonics :>
[02:28:29] <jannau> is american baidu down?
[02:28:34] <bcoudu> bitstring left bit first
[02:29:41] <TheFluff> oh ok
[02:29:51] <TheFluff> I skipped that part :V
[02:34:03] <jannau> lu_zero: I would settle for a QNX based tablet
[02:38:22] <CIA-38> ffmpeg: Mans Rullgard <mans at mansr.com> master * rd33ed7b367 ffmpeg/configure: Enable native build on QNX/x86
[02:38:53] <Dark_Shikari> wtf is QNX
[02:39:00] <mru> an OS
[02:41:03] <jannau> used by a canadian cell phone manufacturer
[02:43:03] <Dark_Shikari> an x86 cellphone?
[02:44:50] <{V}> probably not, QNX probably has a few platforms it runs on. It also didn't start life as a cellphone OS
[02:45:09] <mru> qnx runs on many platforms
[02:45:15] <mru> arm for instance
[02:46:51] <jannau> automotive is probably even after rim bought it the biggest market
[02:48:34] <lu_zero> ok I'm too tired to keep working on swscale...
[03:03:50] <peloverde> Has anyone looked into imdct-test failing on gcc-4.6?
[03:04:08] <mru> the failure pattern is interesting
[03:04:25] <peloverde> indeed
[03:14:03] <peloverde> FWIW, the acodec-wma crashes are also inside fft_sse.c
[03:30:03] <Dark_Shikari> BBB: ping
[03:35:05] <peloverde> ugh, putting printfs above the imdct unfolding makes it go away
[03:35:23] <mru> heisenbug
[03:36:25] <peloverde> actually no i was in the wrong build dir, it still is failing the same way :)
[03:36:55] <mru> clever bug, hiding in a different dir
[03:48:14] <peloverde> Dark_Shikari: pengvado: BBB: Is there a reason we don't mangle m1m1m1m1 in ff_imdct_calc_sse()?
[03:48:44] <peloverde> any other x86 experts are also welcome to chime in
[03:49:38] <Dark_Shikari> I don't know what MANGLE() is
[03:49:46] * Dark_Shikari does yasm only
[03:50:07] <mru> Dark_Shikari: it adds _ to a name if the platform needs that
[03:53:23] <peloverde> This patch makes everything play nice http://ffmpeg.pastebin.com/biJ2pytn
[03:54:12] <peloverde> the av_log is there to keep the optimizer from removing m1m1m1m1 too quickly
[03:56:46] <peloverde> who was defending inline asm this week?
[03:57:00] <mru> someone without much clue, obviously
[03:57:43] * peloverde ponders yasmizing the function
[03:58:08] <mru> what is the actual error in the generated code?
[03:58:23] <Yuvi> mru: it also forces global references to not use registers (which gcc often uses needlessly)
[03:58:48] <mru> Yuvi: no, MANGLE as such only adds the _
[04:00:36] <Yuvi> mru: that's what the macro does, but the reason to use it over "m"() is as I said
[04:00:53] <mru> that wasn't the question I answered
[04:01:25] <Yuvi> also doesn't it switch between PIC and non-PIC on x86-64?
[04:01:38] <mru> no
[04:02:38] <Yuvi> oh, LOCAL_MANGLE does that, which MANGLE uses...
[04:02:48] <mru> or it's the other way around
[04:02:51] <mru> I can't remember
[04:03:34] <peloverde> http://ffmpeg.pastebin.com/mZrVSq9Y
[04:06:08] <mru> where's the difference?
[04:10:31] <mru> I don't see any difference?
[04:10:50] <mru> is the relocation entry for that reference different?
[04:11:52] <mru> or is this built with the fix?
[04:13:34] <peloverde> this is built without the fix
[04:14:05] <mru> so tell me what's different between the two
[04:14:09] <mru> I don't see anything
[04:14:56] <peloverde> Ahh!
[04:15:10] <peloverde> gcc-4.6 onyl puts the first entry of m1m1m1m1 in rodata
[04:15:20] <mru> and I know why
[04:15:44] <mru> that "m" operand only references the first element
[04:15:59] <mru> *array means the first element of array
[04:16:22] <mru> does it work w/o the *?
[04:17:05] <peloverde> without the '*' I get "error: memory input 4 is not directly addressable"
[04:17:32] <Yuvi> so gcc-4.6 is being more strict about inline asm memory operands?
[04:17:44] <mru> try *(int (*)[4])m1m1m1m1
[04:19:23] <peloverde> still the same error
[04:21:21] <mru> yasm is obviously the best solution
[04:34:30] <peloverde> There should be a way to write that constraint properly but I have a feeling it blows up some version of gcc from 1952 which will make people upset
[04:39:02] <TheFluff> does anyone have the specification for m2ts
[04:39:15] <TheFluff> or actually all I want to know is where in the packet those four extra bytes go
[04:41:27] <pengvado> peloverde: no reason
[04:45:19] <Yuvi> mru: *(int (*)[4]) compiles on clang but causes it to copy 64 bits of the constant to the stack and use that (wtf?)
[04:47:48] <mru> add const
[04:49:21] <Yuvi> same thing
[04:50:21] <Yuvi> peloverde: only way I can think of is to use __int128_t
[04:53:54] <Yuvi> or if you're just fighting the optimizer to not eliminate m1m1m1m1, av_used or "X"(m1m1m1m1) should work
[05:08:25] <BBB> peloverde: if there's enough registers
[05:08:27] <BBB> Dark_Shikari: pong
[05:09:25] <Dark_Shikari> BBB: answer to my question from earlier?
[05:09:32] <BBB> let me backlog
[05:09:56] <BBB> what's the x86-64 stuff on top of my patch?
[05:09:56] <BBB> uh
[05:10:57] <BBB> which part? in dsputil_mmx.c or _yasm.asm?
[05:11:48] <Dark_Shikari> all the stuff at the top
[05:11:51] <Dark_Shikari> what's with mmx/sse depending on x86_64?
[05:12:21] <ifb> TheFluff: kierank's muxer has the extra 4 bytes at the beginning (before the sync byte)
[05:12:30] <BBB> Dark_Shikari: oh that
[05:13:01] <BBB> Dark_Shikari: since the function is so big, and the speed gain between sse/mmx is relatively small, I thought it'd be good to not have more than a single function of this type per arch
[05:13:12] <TheFluff> ifb: thanks
[05:13:15] <BBB> so for x86-32, the common denominator is mmx, for x86-64 hat's sse
[05:13:25] <BBB> Dark_Shikari: if you think that's bad, I can change it, but that was the logic
[05:13:33] <Dark_Shikari> this is dumb
[05:13:36] <Dark_Shikari> oh
[05:13:38] <Dark_Shikari> how large is it?
[05:13:47] <Dark_Shikari> thing is, we don't use that logic anywhere else in ffmpeg
[05:13:54] <BBB> 128 bytes x 22 plus 22x64 bytes
[05:13:57] <BBB> that's true
[05:14:15] <BBB> 4kb
[05:14:19] <Dark_Shikari> we template much larger things than that
[05:14:20] <BBB> a little over
[05:14:25] <BBB> 4.5kb basically
[05:14:45] <BBB> I can write two versions, one sse2 and one mmx for x86-32
[05:14:51] <BBB> it's pretty simple
[05:14:56] <BBB> I just figured it might be overkill
[05:14:59] <BBB> because it's barely faster
[05:15:06] <BBB> but if you think it's a good idea, I can do it
[05:15:24] <Dark_Shikari> I don't like introducing logical dependencies that don't make sense.
[05:21:41] <BBB> ok, will change thne
[05:21:44] * BBB goes to bed now
[05:21:45] <BBB> more tomorrow
[05:27:21] <Sean_McG> mru: first problem with running fate on Solaris -- assumes /bin/sh is bash :P
[06:48:20] <Dark_Shikari> so I'm about to try sendemail now
[06:48:23] <Dark_Shikari> what do I need other than from or to?
[06:48:27] <Dark_Shikari> do I need to run an smtp server?
[06:48:59] <drv> you can use gmail's, if you use that
[06:49:04] <saintdev> you need _an_ smtp server
[06:49:08] <saintdev> but what drv said
[06:49:09] <Dark_Shikari> what's gmail's?
[06:49:16] <Dark_Shikari> don't I need a username/password for it?
[06:49:24] <astrange> smtp.gmail.com, ssl, gmail account user and pass
[06:49:27] <drv> http://morefedora.blogspot.com/2009/02/configuring-git-send-email-to-use-gmail.html
[06:49:56] <astrange> i find send-email slightly annoying, because when i reply to the thread with an updated patch
[06:50:12] <astrange> my mail client sends it differently than send-email does (attachment instead of inline)
[06:51:36] <Dark_Shikari> what's thread=true?
[06:51:38] <saintdev> astrange: that's why i use git imap-send. Then i can just have it added as a draft
[07:12:38] <Dark_Shikari> ??
[07:12:41] <Dark_Shikari> when I use git-send email HEAD
[07:12:45] <Dark_Shikari> it says no patch files specified
[07:12:48] <Dark_Shikari> ... but I specified it.
[07:12:48] <elenril> it doesn't do anything
[07:12:49] <Dark_Shikari> "HEAD".
[07:12:55] <elenril> HEAD to what?
[07:12:59] <Dark_Shikari> Er, my current tree?
[07:13:01] <saintdev> Dark_Shikari: you have to feed it format-patch
[07:13:02] <Dark_Shikari> "master" doesn't work either.
[07:13:05] <Dark_Shikari> ... that's retarded
[07:13:10] <elenril> you have to specify a range of commits
[07:13:17] <elenril> e.g. HEAD..<some commit>
[07:13:21] <Dark_Shikari> how about just HEAD?
[07:13:22] <elenril> or just <some commit>
[07:13:26] <saintdev> erm, actually i guess that's just imap-send
[07:13:26] <Dark_Shikari> .... but I did
[07:13:30] <Dark_Shikari> git send-email HEAD
[07:13:35] <Dark_Shikari> HEAD is a commit
[07:13:36] <elenril> you mean HEAD^
[07:13:48] <elenril> yes and it means 'send all commits between HEAD and HEAD'
[07:13:49] <saintdev> Dark_Shikari: if you just give it one commit it's a "since this commit"
[07:13:52] <elenril> which is a noop
[07:14:09] <elenril> try git send-email -1
[07:14:19] <Dark_Shikari> HEAD^ works
[07:14:29] <elenril> send-email -<number> send latest <number> of commits
[07:14:41] <Dark_Shikari> Can't locate Net/SMTP/SSL.pm
[07:14:43] <Dark_Shikari> wtf
[07:15:34] <astrange> sudo perl -MCPAN -e 'install Net::SMTP::SSL'
[07:15:54] <elenril> aptitude install libnet-smtp-ssl-perl =p
[07:16:19] <Dark_Shikari> I'm not on Debian
[07:16:21] <saintdev> he's on cygwin
[07:16:45] <elenril> doesn't cygwin track dependencies?
[07:16:54] <Dark_Shikari> cygwin doesn't have that in its package manager
[07:17:08] <Dark_Shikari> Going to write /home/Jason/.cpan/Metadata
[07:17:08] <Dark_Shikari> Warning: Cannot install NET::SMTP::SSL, don't know what it is.
[07:17:46] <Dark_Shikari> It's Net::SMTP:SSL
[07:17:48] <Dark_Shikari> Capitalization matters.
[07:20:21] <Dark_Shikari> elenril: how do I force an install?
[07:20:27] <Dark_Shikari> it failed like 2 tests
[07:20:30] <Dark_Shikari> and won't install
[07:20:32] <Dark_Shikari> unless I "force"
[07:20:36] <Dark_Shikari> but I don't know how to force.
[07:20:40] <Dark_Shikari> er, astrange
[07:21:13] <astrange> i forget. if you do -e shell (or just 'sudo cpan') you get a console
[07:21:17] <astrange> which might tell you
[07:23:13] <Dark_Shikari> perl -MCPAN -e 'CPAN::Shell->force(qw(install IO::Socket::SSL));'
[07:24:50] <Dark_Shikari> bah I keep needing to install all these perl deps
[07:24:54] <Dark_Shikari> why doesn't git come with them :>
[07:26:34] <elenril> because it's not ffmpeg?
[07:27:15] <Dark_Shikari> I mean, not even the package has them as deps.
[07:27:16] <Dark_Shikari> The hell.
[07:27:32] <astrange> i think the packagers don't use gmail
[07:27:44] <Dark_Shikari> ... My first git-send-email!
[07:28:01] <elenril> yeah, just install postfix ;)
[07:28:12] <saintdev> jason at x264.com
[07:31:02] <Dark_Shikari> I'm cool, I have an official x264 email.
[07:31:05] <Dark_Shikari> Only two people do!
[07:31:38] <saintdev> yeah, who names their kid "Licensing" ?
[07:31:47] * Dark_Shikari smacks saintdev 
[07:32:38] <elenril> why's the name not set?
[07:33:15] <saintdev> Dark_Shikari: did you specify a TO: address?
[07:33:48] <saintdev> erm i mean from address
[07:33:52] <saintdev> gah
[07:34:25] <Dark_Shikari> elenril: how do I do that?
[07:35:06] <Dark_Shikari> BBB: ping, see ml
[07:35:08] <saintdev> Dark_Shikari: if you don't specify a from address, it should just use your name that's already set
[07:35:58] <Dark_Shikari> I did set a from address
[07:36:03] <elenril> don't do that
[07:36:11] <Dark_Shikari> ok
[07:36:18] <elenril> just let it use the commit name
[07:36:45] <pross-au> The Joy of Git(tm)
[07:51:10] * pross-au prefers git-mutt-patch: http://ffmpeg.pastebin.com/ynsEDpck (alternative to git-send-email)
[08:26:10] <Dark_Shikari> BBB: another thought, the edge emulation check in vp8 is being duplicated for chroma channels
[08:26:18] <Dark_Shikari> I HIGHLY doubt that's optimized out by gcc
[08:53:21] <peloverde> Is av_used a thing? grep isn't finding it
[08:57:36] <siretart> peloverde: there is av_unused, if there is a gcc attribute for it, I think libavutil/common.h would be the right place to implement it
[08:58:08] <Dark_Shikari> peloverde: av_used(x) does x = x
[08:58:09] <Dark_Shikari> iirc
[08:58:48] <peloverde> Dark_Shikari: I thought that was av_uninit()
[09:01:48] <Dark_Shikari> oh
[09:01:53] <Dark_Shikari> you're right
[09:02:22] <peloverde> What are the consequences of mangle? can it fuck shit up for PIC?
[09:03:40] <Dark_Shikari> I think MANGLE is for pic.
[09:05:00] <peloverde> what about "r"(m1m1m1m1) is that considered bad?
[09:06:21] <Yuvi> MANGLE forces non-PIC references on 32-bit
[09:07:25] <peloverde> what about "r"(m1m1m1m1)?
[09:08:11] <Yuvi> attribute_used is what I was thinking of for av_used
[09:08:52] <peloverde> cool, but the whole used/unused thing only comes into play with mangle, the optimizer is aware of variables that occur in constraints
[09:09:03] <Yuvi> yeah
[09:09:31] <Yuvi> thus the "X"(m1m1m1m1), which does MANGLE but not LOCAL_MANGLE
[09:09:35] <Dark_Shikari> m1m1m1m1m1m1m1m1?
[09:09:37] <Dark_Shikari> http://www.youtube.com/watch?v=kV4vHpqrj6E&t=0m10s
[09:10:02] <Yuvi> "r"(m1m1m1m1) will work obviously, it just needs to load the address into a register instead of using a memory operand
[09:10:10] <siretart> hm. it seems that MANGLE rather special cases x86_64 rather than 32 bit
[09:10:38] <siretart> however other arches puke at PIC in shared libraries as well, I wonder why this hasn't hit us so far
[09:11:01] <Yuvi> MANGLE's only used for x86 asm
[09:11:06] <Dark_Shikari> also http://www.youtube.com/watch?v=gUeeIjyI7QQ#t=0m13s
[09:11:09] <peloverde> "x"(m1m1m1m1) did not work for me
[09:11:40] <siretart> Yuvi: oh, interesting. perhaps this piece of information should then be added to libavutil/internal.h, I guess?
[09:12:52] <peloverde> I've always found gcc asm constraints to be poorly documented
[09:15:14] <Yuvi> hm, "X" gives an extra $ on x86 apparently, I guess I was thinking of something else
[09:15:48] <Yuvi> siretart: theoretically I guess any other inline asm could use it, it's just not done currently
[09:15:59] <Yuvi> since x86 is about it for large inline asm
[09:17:25] <siretart> yeah, I see that
[09:17:51] <peloverde> I really wish I remembered who was defending inline asm so I could make him fix this
[09:17:58] <Dark_Shikari> michael?
[09:27:50] <peloverde> mru: When are you going to ban hammer gabu?
[09:48:38] * thresh finds that amusing: http://twitter.com/#!/martinbogo/status/31253355032485888
[09:56:51] <Yuvi> peloverde: if you really want to use inline asm constraints, http://pastebin.com/q8zFrKJg should work but feels dirty
[09:58:39] <astrange> is something wrong with declaring m1m1m1m1 as __m128i?
[09:58:43] <astrange> that would fix it
[09:59:09] <Yuvi> __m128i isn't allowed to be initialized to anything
[10:00:16] <lu_zero> peloverde: where?
[10:01:28] <astrange> http://pastebin.com/94tDRGmf
[10:10:22] <Yuvi> looks like that works too
[10:11:39] <astrange> that typedef should be how gcc/icc define m128i, i didn't check though
[10:13:03] <Yuvi> btw, it seems that "%a0" / "X"(symbol) is the probably the correct inline asm syntax for this
[10:13:18] <Yuvi> which takes care of PIC and everything
[10:35:45] <thresh> bloody hpux aCC doesnt fail on unknown options :S
[10:36:32] <spaam> thresh: hpux? why are you using it?
[10:37:14] <thresh> spaam: because I can
[10:37:31] <spaam> ok :)
[11:08:42] <thresh> ROTFL, compiler segfaults on libavcodec/vorbis_enc.c :)
[12:42:44] <Compn> btw if mplayer docsgenerate is failing, i'm assuming ffmpeg's docsgenerate is also failing mru
[12:42:53] * Compn hasnt verified tho
[12:43:12] <Compn> anyone check if ffmpeg docs are being generated ?
[12:43:19] <Compn> updated that is
[13:08:10] <{V}> Compn, there was a small change to the use of texi2html which included bumping the required version to 1.78. Could that be the problem?
[13:15:06] <mru> could well be
[13:17:54] <mru> Sean_McG: none of our scripts require bash
[13:18:01] <mru> Sean_McG: they do require a posix shell
[13:18:05] <mru> which solaris /bin/sh is not
[13:18:15] <mru> you need to use /usr/xpg6/bin/sh there
[14:32:57] <BBB> Dark_Shikari: yeah, I think h264 and all mpeg decoders do chroma and luma all together as most-inner-loops, whereas I do them separately as most outer loops or so
[14:33:36] <BBB> Dark_Shikari: I think I tried to merge it the other way around but something didn't work quite right so I didn't do it, the code got more complex in another way, I forgot how exactly
[14:36:03] <Compn> {V} : mplayer script is unrelated problems anyways, just i think the scripts got reset
[14:36:11] <Compn> since i thought this bug was fixed long ago
[14:36:32] <{V}> kay
[14:36:57] <mru> reload and rejoice
[14:37:41] <Compn> e.g. mplayer script needs --yasm=''
[14:37:47] <Compn> ./configure --yasm=''
[14:37:55] <Compn> to skip the yasm check
[14:46:41] <kierank> Anaerin: can you post that mediaroom sample somewhere else
[15:40:35] <twnqx> ... interesting, just installing foobar2000 in wine crashed audacious
[15:46:52] <saste> lu_zero: please bump minor and add an APIchanges entry for av_dlog()
[15:47:17] <elenril> which reminds me, i probable have to do the same for all the avio_* stuff
[15:48:27] <lu_zero> elenril: mind merge all those changes in one?
[15:51:27] <elenril> sure, no point in five successive bumps ;)
[15:51:51] <kshishkov> bump once but += 5 instead
[15:52:56] * elenril bumps kshishkov on head
[15:54:47] * kshishkov reminds elenril that head is not mandatory to be FFmpeg developer
[15:56:46] * pJok julmusts kshishkov 
[15:56:56] * kshishkov accepts
[15:57:31] <kshishkov> please add a piece of julskinka on tunnbröd
[16:38:27] <uau> Kovensky: you talked before about needing a separate pkg-config binary for crosscompiling because of the default search directory - does PKG_CONFIG_LIBDIR not work for that?
[16:41:15] <mru> it still falls back on the compiled-in default iirc
[16:41:25] <mru> that, or totally ignore the env var
[16:41:57] <uau> the documentation for that says "Replaces the default pkg-config search directory, usually /usr/lib/pkgconfig"
[16:42:38] <mru> don't tell me you trust documentation
[16:42:38] <uau> PKG_CONFIG_LIBDIR=/tmp/ pkg-config --libs zlib
[16:42:38] <uau> Package zlib was not found in the pkg-config search path.
[16:43:08] <uau> doesn't fall back to the default
[16:43:24] <mru> then I guess they fixed it
[16:43:38] <mru> I know I've struggled with it picking up system libs no matter what I did
[16:44:20] <CIA-38> ffmpeg: Vasyl' Vavrychuk <vvavrychuk at gmail.com> master * r665132e620 ffmpeg/libavformat/ (mpeg.h mpegts.c):
[16:44:20] <CIA-38> ffmpeg: mpegts: remove get_pts duplicate of ff_parse_pes_pts.
[16:44:20] <CIA-38> ffmpeg: Signed-off-by: Vasyl' Vavrychuk <vvavrychuk at gmail.com>
[16:44:20] <CIA-38> ffmpeg: Signed-off-by: Mans Rullgard <mans at mansr.com>
[16:52:19] <uau> Sean_McG: btw if you're familiar with gcc development, do you know whether handling of the "restrict" keyword has been improved from the "totally useless crap" level?
[16:53:16] <uau> in gcc 4.5 it's still that - even blatant cases like "*a = 0; *b = 1; return *a;" are not optimized unless *both* a AND b are declared with "restrict"
[16:54:35] <BBB> uau: isn't that correct? although last time I checked even if you did add restrict it still wouldn't optimize
[16:58:04] <mru> damn, you're making go read the c99 spec on restrict _again_
[16:59:42] <uau> BBB: correct that it's only done if *both* have the restrict qualifier? not as far as i can see - the spec talks about "modifications" to an object accessed through a restrict pointer, and i don't see anything limiting that to "modifications done through another restrict pointer"
[17:01:11] <uau> if i read the spec correctly, then *either* a or b having the restrict qualifier should be enough to know that "return *a;" is equal to "return 0;"
[17:01:27] <BBB> uau: sounds like nitpicking to me. if restrict is of interest to you, you add it to _all_ objects that don't overlap with one another, not just one. if you don't care about restrict, then you don't (and don't get the optimization). if you're not sure if one object has no overlap but you're sure others do, you add it only to those some, and then gcc's behaviour is correct
[17:01:42] <BBB> what if you have *a, *b and *c, but only a and b are restrict?
[17:01:57] <BBB> to me that means "I'm sure a and b don't overlap with one another, but I have no idea what c points to"
[17:01:57] <mru> whatever it means exactly, it's still not quite what you want in many cases
[17:02:09] <BBB> because if you did know for sure, you'd have declared c as restrict also
[17:02:18] <BBB> and 2/3 being restrict still allows for optimizations
[17:02:32] <mru> I'd like a way to say that two pointers either point to entirely disjoint _or_ exactly overlapping objects
[17:03:12] <BBB> that'd be nice for things like interleave(dst, src1, src2); to make dst and src be the same pointer
[17:03:12] <uau> BBB: you're missing the point
[17:03:31] <uau> adding restrict to "all objects that don't overlap another" wouldn't work
[17:03:39] <BBB> uau: because?
[17:03:42] <uau> because there are still objects that do overlap something
[17:03:43] <Sean_McG> mru: Solaris /bin/sh doesn't like version.sh
[17:03:49] <mru> BBB: exactly, but interleave doesn't work that way
[17:03:59] <mru> you can't do an inplace interleave of arbitrary size
[17:04:01] <BBB> uh, well
[17:04:03] <uau> and now you couldn't tell that those don't overlap the object you're interested in
[17:04:05] <mru> unless you want log(n) runtime
[17:04:05] <BBB> sum(dst, src1, src2)
[17:04:13] <BBB> interleave was a bad example
[17:04:14] <mru> Sean_McG: solaris /bin/sh is not posix
[17:04:21] <mru> version.sh is posix
[17:04:22] <Sean_McG> aye, s'what I figured
[17:04:23] <BBB> anything where dst and src increment by the same stride per loop iteration
[17:04:36] <mru> yes
[17:04:47] <Sean_McG> can we patch it the same way configure is patched, to detect if it's broken?
[17:05:51] <mru> or have configure set SHELL in config.mak and use that to run version.sh
[17:07:07] <uau> BBB: so to clarify a bit more, telling the compiler that "these couple of objects don't alias *each other*" would be fairly useless, because that still leaves all the other objects in the program - if they're accessed at any point you couldn't be sure about the special objects any more
[17:07:13] <Sean_McG> hmm that might be a better idea
[17:07:30] <uau> you really to say that "these couple of objects don't alias *anything*"
[17:07:37] <BBB> uau: you're talking about thread-safety and that's a whole different issue anyway
[17:07:37] <uau> want to say
[17:07:55] <uau> BBB: where did you get that idea from? what i said had nothing to do with thread safety
[17:07:58] <mru> restrict has nothing to do with threads
[17:09:46] <BBB> "if they're accessed at any point you couldn't be sure about the special objects any more"
[17:09:52] <BBB> how else do I read that?
[17:10:34] <mru> my understanding after rereading the spec is that restrict promises that _no_ other pointer will alias the object while the restrict-qualified one is in scope
[17:10:43] <BBB> mru: I know that, but I can't read uau's response in any other way... anyway, restrict doesn't work, I generally just read values from pointers out in a temp var if I believe they are restrict
[17:10:47] <BBB> at least that always works as intended
[17:10:56] <uau> BBB: that if the program makes access through any other pointer it couldn't be sure about the state of the restrict-qualified object any more if restrict was only guaranteed to work between *two* qualified pointers
[17:12:42] <uau> and note that has a pretty big effect with for example function calls - if you have a restrict pointer in a block, and don't pass that pointer to functions, then you can know for sure that the functions don't change anything you access through the pointer
[17:32:09] <Sean_McG> I don't understand what M= from common.mak is supposed to do?
[17:32:49] <mru> that's for the pretty "CC file.c" output
[17:32:54] <Sean_McG> ahhhhh
[17:33:05] <Sean_McG> OK, cool
[17:33:11] <mru> I admit it's a bit non-obvious how it works
[17:40:25] <Anaerin> kierank, there are samples downloadable from http://dl.dropbox.com/u/16213885/Mythtv-NewMax/channel4_ctv_vlc_rawdump
[17:40:46] <kierank> thanks
[17:44:04] <Anaerin> kierank, I've updated the roundup issue, too, as the original message has been lost by it.
[17:58:57] <kierank> Anaerin: ah it's one of those ts files with some weird headers
[17:59:28] <mru> ts files don't have headers
[17:59:46] <kshishkov> do they have anything except CBR?
[18:00:06] <mru> PCR
[18:00:37] <mru> and strictly speaking, files don't have a bitrate
[18:00:44] <mru> they exist in their entirety all the time
[18:00:55] <kshishkov> streams
[18:01:37] <elenril> ts files are the beginning and the end!
[18:02:11] <kierank> in the beginning god created a ts file
[18:02:18] <kshishkov> and s/bitrate/requirements for data size for coding given amount of time/
[18:02:40] <kshishkov> kierank: and devil created perfect muxer for it as a reference implementation
[18:02:58] <kierank> what reference implementation
[18:03:18] <kierank> the reference implementation is useless
[18:03:19] <kshishkov> Hypothethical reference muxer
[18:04:27] <kierank> well anyway these days nobody follows the specs apparently
[18:04:48] <kshishkov> is it possible?
[18:04:57] <kierank> kshishkov: no idea
[18:05:04] <mru> to follow the spec?
[18:05:05] <kshishkov> to follow spect to the last letter and typo
[18:05:16] <kierank> ts muxing and hrd are not specs. They are analyzer compliance tasks
[18:05:35] <kierank> s/are not/do not involve following
[18:06:04] <mru> ts muxing is only hard when you don't have all the stream parameters
[18:06:08] <mru> and I mean all of them
[18:06:48] <kshishkov> i.e. only in practice
[18:06:48] <mru> if you have all the vbv buffer sizes, delays etc, it's not that complicated
[18:06:58] <mru> the hard part is estimating the unknown parameters
[18:07:00] <kierank> mru: yep, that's why in my muxer i cheated and made the user set all the params
[18:07:38] <mru> if you underestimated the buffer size for instance, you might suddenly find yourself with an underflow
[18:08:05] <kshishkov> mru: reminds me of popular FFmpeg message
[18:27:38] <spaam> which one?
[18:28:08] <kshishkov> about buffer underflow
[18:42:24] <chandoo> hi :)
[18:43:06] <kshishkov> ni hao
[18:59:28] <CIA-38> ffmpeg: Stefano Sabatini <stefano.sabatini-lala at poste.it> master * r13156f40e1 ffmpeg/ffplay.c:
[18:59:28] <CIA-38> ffmpeg: ffplay: in video_thread(), use av_dlog() for timestamp logging.
[18:59:28] <CIA-38> ffmpeg: Disable logging of rescaled timestamps if DEBUG is not enabled.
[18:59:28] <CIA-38> ffmpeg: Avoid debug log spamming with -loglevel debug.
[18:59:28] <CIA-38> ffmpeg: Signed-off-by: Mans Rullgard <mans at mansr.com>
[19:02:14] <Tjoppen> kshishkov: http://www.youtube.com/watch?v=C8Wu3Bps9ic
[19:08:23] <kshishkov> Tjoppen: tack, when I'll be ready to cook köttbullar I'll do them that way
[19:08:32] <kshishkov> but with lingonsylt
[19:09:04] <wbs> Tjoppen: lol
[19:09:15] <pJok> kshishkov, if you prefer hardcore swedish cooking, lookup ordinary swedish mealtime on youtube...
[19:09:53] <Tjoppen> pJok: that's exactly what I posted
[19:10:09] <pJok> ah
[19:10:15] <pJok> i didn't see your link actually :)
[19:10:53] <pJok> sidepork pandemonium is rather amusing
[19:11:09] * kshishkov ate köttbullar in Uppsala and different places in Stockholm including Skansen
[19:12:28] * _av500_ eats em at ikea
[19:12:41] <Tjoppen> I didn't eat sidfläsk until recently. oh, how I have missed out
[19:12:52] <Tjoppen> must try it with brown beans next time
[19:14:59] <pJok> Tjoppen, you certainly have... you can try a danish dish... sidfläsk med persiljesaus och potatis
[19:15:49] * kshishkov has vildsvinkorv
[19:16:41] <CIA-38> ffmpeg: Stefano Sabatini <stefano.sabatini-lala at poste.it> master * r2855080447 ffmpeg/ffplay.c:
[19:16:41] <CIA-38> ffmpeg: In ffplay:get_video_frame(), use frame->pkt_pts rather than reordered_opaque.
[19:16:41] <CIA-38> ffmpeg: AVCodecContext.reordered_opaque is deprecated for this specific use.
[19:16:41] <CIA-38> ffmpeg: Signed-off-by: Mans Rullgard <mans at mansr.com>
[19:36:37] <Tjoppen> wait a minute.. regular ordinary swedish meal time is shot in umeå
[19:37:01] <Tjoppen> that ica is just 50 from where I live. how come I haven't heard of this earlier?
[19:37:05] <Tjoppen> *50m
[19:37:33] * kshishkov notes to try visiting Umeå this summer
[19:50:25] <spaam> Tjoppen: fail på dig
[19:52:31] <pJok> Tjoppen, probably because its fairly new?
[19:53:11] <Tjoppen> aha
[19:53:34] <pJok> go eat with them? :P
[20:16:25] <CIA-38> ffmpeg: Jason Garrett-Glaser <jason at x264.com> master * r73be29b0c4 ffmpeg/libavcodec/vp8.c:
[20:16:25] <CIA-38> ffmpeg: Slightly simplify VP8 inter_predict
[20:16:25] <CIA-38> ffmpeg: Merge an if and a switch.
[20:19:09] <Tjoppen> hm, no gmaxwell here. just spotted a typo in the celt rfc
[20:19:38] <Tjoppen> one of the formulas in the pvq part has + instead of -, which led me to confusion
[20:19:58] <mru> Tjoppen: try in #vp8
[20:21:27] <Tjoppen> ok
[20:22:02] <mru> but he's not there either
[20:22:13] <Tjoppen> so I see
[20:22:36] <Tjoppen> monty's there though
[20:43:42] <_av500_> sorry in german: http://ahoipolloi.blogger.de/stories/1767834/
[20:45:22] <mru> hehe
[21:02:13] <Sean_McG> mru: to fix my /bin/sh issues, OK to write a patch that teaches configure to store $SHELL in config.mak?
[21:10:34] <mru> Sean_McG: do the tests in configure identify a working shell?
[21:11:42] <Sean_McG> yes, Sol10 has /bin/bash, but /bin/sh is not bash
[21:12:11] <mru> what I mean is, are the checks sufficient to reject /bin/sh?
[21:12:33] <Sean_McG> yes, it looks for a "broken shell", and then tries to run bash
[21:13:07] <mru> btw, doesn't solaris have a variable to request proper posix behaviour from /bin/sh?
[21:13:12] <mru> like irix and tru64 do
[21:13:17] <Sean_McG> don't know
[21:13:30] <mru> on irix setting _XPG=1 makes it behave
[21:13:43] <mru> on tru64 it's BIN_SH=xpg4
[21:13:44] * Sean_McG checks the manpage, but I'm betting the answer is no
[21:13:53] <mru> how rude of them
[21:14:30] <Sean_McG> ah... there's /usr/xpg4/bin/sh, but that's not guaranteed to be in the path, and it's also not /bin/sh ;)
[21:15:15] <mru> btw, you'll have to put /usr/xpg4/bin before /bin in your path
[21:15:25] <mru> otherwise some grep and sed commands we use will fail
[21:15:42] <Sean_McG> yeah and it is in my case, but scripts still ask for /bin/sh by name
[21:15:53] <mru> yes, different problem
[21:16:12] <mru> but the aforementioned unixes have ways of making /bin/sh a true posix shell
[21:16:49] <Sean_McG> yeah, looks like Sun failed at that one
[21:17:11] <mru> kind of weird
[21:17:25] <mru> they always led the way on ELF-related things
[21:17:47] <Sean_McG> so I think since configure identifies a working shell, I should just jam that into config.mak and then tell it to run version.sh to run with $SHELL
[21:17:47] <mru> and system-level stuff in general
[21:25:35] <mru> Sean_McG: does this work? http://pastebin.com/M8Ynu63m
[21:26:28] <Sean_McG> it's looks very similar to what I was just trying to write... but I think I like yours better.
[21:26:32] * Sean_McG tests
[21:27:23] <mru> SHELL in the normal environment usually means the user's interactive shell
[21:27:31] <mru> so I don't want to mess with that in the configure script
[21:27:51] <Sean_McG> aye, but what about just picking up what configure identifies?
[21:28:03] <mru> that's what my patch does
[21:28:07] <Sean_McG> OK
[21:29:37] <Sean_McG> hunh... Makefile hunk 1 failed... copy paste poop maybe?
[21:30:07] <mru> pastebin probably fucked with the text again
[21:30:40] <mru> http://pastie.org/1512922
[21:32:14] <mru> yeah, pastebin turns line breaks in to windows-style
[21:32:17] <mru> fuck pastebin
[21:35:03] <Sean_McG> sean at tsukimi:/var/opt/BUILD/ffmpeg-fate.amd64/src$ gpatch < /tmp/pastie-1512922.diff
[21:35:06] <Sean_McG> patching file Makefile
[21:35:08] <Sean_McG> Hunk #1 FAILED at 104.
[21:35:11] <Sean_McG> garrrrr
[21:35:57] <Sean_McG> this wouldn't happen to be a ffmpeg vs. ffmpeg.git thing would it?
[21:36:17] * Sean_McG fixes manually
[21:36:21] <mru> sorry, it's my fault
[21:36:33] <mru> copy&paste tabs from xterm doesn't always work
[21:37:57] <mru> fixed the pastie
[21:38:00] <Sean_McG> OK
[21:38:05] <mru> now md5 matches diff output
[21:42:19] <Sean_McG> mru: cheers dude, that works
[21:47:05] <Sean_McG> hrm, or maybe not
[21:47:29] <Sean_McG> sean at tsukimi:/var/opt/SOURCES/ffmpeg$ bash ./tests/fate.sh ~/Documents/ffmpeg-fate.cfg
[21:47:30] <spaam> haha
[21:47:32] <Sean_McG> Already up-to-date.
[21:47:34] <Sean_McG> /var/opt/BUILD/ffmpeg-fate.amd64/src/version.sh: syntax error at line 4: `revision=$' unexpected
[21:48:21] <mru> that's the fate.sh script running version.sh directly
[21:48:33] <Sean_McG> ah.
[21:48:51] <mru> I wonder how the solaris machines currently running fate do it
[21:54:52] <Sean_McG> they run OpenSolaris which is different (/bin/sh *is* bash)
[21:56:34] <mru> I see
[21:59:11] <mru> the fate system has lots of scripts
[21:59:33] <mru> I'm not sure I want to add the mess required to pass around a shell variable
[21:59:53] <mru> you could easily make your /bin/sh a proper shell
[22:00:09] <Sean_McG> I could, and risk breaking legacy scripts
[22:00:17] <mru> put a little wrapper around it checking for an env var and exec either the real thing or bash depending
[22:00:27] <Sean_McG> oh hrm.
[22:01:25] <mru> that way it would still be the same old shell for most things
[22:01:35] <peloverde> Is there a document that describes MANGLE? I feel like I'm still missing something
[22:01:47] <mru> peloverde: the header file that defines it
[22:01:51] <mru> it's quite simple really
[22:02:38] <mru> you probably want to use LOCAL_MANGLE here though
[22:02:46] <mru> since the variable in question is static to the file
[22:02:48] <peloverde> It's defined to two more macros, one of which doesn't seem to be defined anywhere
[22:02:50] <mru> hence no prefix
[22:03:35] <peloverde> I can't use local mangle because of DCE
[22:03:50] <mru> dce?
[22:04:25] <peloverde> dead code, unused static variables
[22:05:24] <uau> peloverde: i think the "right" answer to your problem would be what astrange said earlier, use a 128-bit type for the constant
[22:05:53] <mru> or convert it all to yasm
[22:05:56] <uau> and for the MANGLE hack av_unused should work
[22:06:13] <mru> no
[22:06:17] <mru> av_unused does something else
[22:06:25] <mru> av_used is what you want, if it exists
[22:06:28] <mru> if not, it should be added
[22:08:06] <uau> attribute_used is the right one i think
[22:08:15] <mru> yes, I noticed
[22:08:18] <mru> but that's ridiculous
[22:08:20] <mru> let's rename it
[22:08:20] <peloverde> according to the docs attribute used only applies to functions
[22:08:40] <mru> then docs are wrong
[22:09:00] <mru> my docs say it works on both
[22:09:11] <mru> `used' This attribute, attached to a variable, means that the variable must be emitted even if it appears that the variable is not referenced.
[22:09:48] <peloverde> sorry i was in the wrong file
[22:10:22] <uau> you were looking at the "attributes of functions" file and it only talked about functions?
[22:13:52] <Sean_McG> OK so it looks like fate is chugging along now, albeit with these local mods
[22:15:14] <Yuvi> mru: the systems that prefix "_" to symbols do it for static variables too
[22:15:24] <Dark_Shikari> mru: heh, you should see some of AMD's XOP instructions.
[22:15:27] <Dark_Shikari> I'm looking over them now
[22:15:47] <Dark_Shikari> one of them lets you perform a SIMD byte rotate, with a different arg per byte
[22:15:53] <Sean_McG> Yuvi: OS X is one of those, yes?
[22:16:02] <Dark_Shikari> and of course the insane shuffle that can perform a different operation per byte
[22:16:10] <Dark_Shikari> and they're finally adding multiply-accumulate after only 15 years
[22:16:38] <Yuvi> Sean_McG: yeah
[22:18:10] <Dark_Shikari> oh, I can't find the permute.  they only have floating point ones.  blah
[22:19:14] <Dark_Shikari> god avx is a mess.
[22:19:21] <peloverde> attribute_used + DECALARE_ALIGNED + const appears to be DECLARE_ASM_CONST()
[22:19:37] <peloverde> but it is only static on some platforms
[22:19:51] <mru> peloverde: I want to tidy up that mess
[22:20:17] <mru> I tried once but certain people prevented it
[22:20:54] <mru> Dark_Shikari: what's XOP?
[22:21:23] <peloverde> what do you mean by tidy?
[22:21:30] <mru> make less messy
[22:21:49] <Dark_Shikari> AMD's new instruction mess
[22:21:55] <Dark_Shikari> extension to AVX
[22:21:55] <peloverde> how so?
[22:22:02] <mru> Dark_Shikari: they're still playing the not-quite-intel game?
[22:22:04] <Dark_Shikari> Yes
[22:22:08] <Dark_Shikari> Well, here's what happened
[22:22:13] <Dark_Shikari> AMD was going to do SSE5, Intel was doing AVX
[22:22:19] <Dark_Shikari> Then AMD realized their SSE5 opcode design was shit
[22:22:23] <Dark_Shikari> and they adopted AVX's instead
[22:22:29] <Dark_Shikari> and tacked on their own instructions to it.
[22:23:05] <mru> Yuvi: are you sure?
[22:23:59] <hyc> Dark_Shikari: sure, but then Intel pulled a fast one and decided to drop FMA4 and only do FMA3
[22:24:05] <Dark_Shikari> hyc: that was another story
[22:24:07] <Dark_Shikari> which was hilarious
[22:24:08] <Yuvi> mru: on OS X, yes, and MANGLE is used on static const variables in other files, so...
[22:24:09] <mru> fma?
[22:24:14] <mru> Yuvi: ok
[22:24:14] <Dark_Shikari> mru: fused multiply-add
[22:24:18] <Dark_Shikari> FMA4 == 4-operand version
[22:24:30] <Dark_Shikari> FMA3 == 3-operand version, but with different variations on the instruction to allow for all the possibilities of FMA4
[22:24:39] <Dark_Shikari> i.e. pushing the complexity into the opcode instead of adding a 4th input reg
[22:24:41] <mru> scary stuff that
[22:24:45] <Dark_Shikari> So what happened was
[22:24:51] <Dark_Shikari> Intel said FMA4, AMD said FMA3
[22:24:57] <Dark_Shikari> then Intel figured "eh, FMA4 isn't very important, let's do FMA3."
[22:25:01] <mru> do you mean ieee754 fused multiply-add?
[22:25:04] <Dark_Shikari> AMD said "eh, FMA3 isn't very important, we'll be compatible and do FMA4."
[22:25:10] <Dark_Shikari> And they swapped.
[22:25:17] <Dark_Shikari> Now they're both still as incompatible.
[22:25:25] <Dark_Shikari> Just doing the opposite of what they previously did.
[22:25:27] <Sean_McG> lollerblade
[22:25:30] <Dark_Shikari> Yeah, IEEE iirc
[22:25:33] <mru> with no intermediate rounding
[22:25:40] <hyc> total flustercuck.
[22:25:56] <Dark_Shikari> the problem is that x86 doesn't have a central standards committee
[22:26:04] <Dark_Shikari> so even when AMD and Intel *want* to work together, they STILL FAIL.
[22:26:10] <mru> such instructions are annoying since if the compiler decides to use them, you suddenly get different results
[22:26:18] <Dark_Shikari> nobody is ever supposed to rely on float rounding
[22:26:38] <mru> no, but it's still annoying when things differ for no apparent reason
[22:26:50] <mru> makes checking things for correctness that much harder
[22:27:00] <uau> isn't that one of the instructions that C99 specifies in a way that you're supposed to be able to rely on
[22:27:21] <mru> autofail of the day: checking uint32_t is 32 bits... configure: error: could not compile program using uint32_t
[22:27:33] <Sean_McG> hahah
[22:27:45] <mru> it's fucking _defined_ to be 32 bits
[22:27:49] <hyc> lol
[22:27:56] <mru> if you have the type, it's _guaranteed_ to be exactly 32 bits
[22:28:28] <uau> Dark_Shikari: btw there is stuff that depends on exact float rounding - and that's why it is specified by standards
[22:28:44] <hyc> mru: you on a TOPS10 box? ;)
[22:29:01] <mru> cross-compiling
[22:32:14] <Dark_Shikari> mru: LOL
[22:32:20] <peloverde> Here is a goofy question, should there be some sort of mangle that is LOCAL_MANGLE when DECALRE_ASM_CONST is static and MANGLE when it isn't?
[22:32:34] <DonDiego> peloverde: seen the aac ltp patch already?
[22:33:11] <mru> peloverde: no, MANGLE should always be used
[22:33:23] <peloverde> mru: why?
[22:33:27] <mru> LOCAL_MANGLE is for local names only
[22:33:27] <peloverde> DonDiego: yes
[22:33:32] <mru> don't know when you'd use it
[22:33:55] <peloverde> THEN WHY WERE PEOPLE TELLING ME I WANTED LOCAL_MANGLE INSTEAD!!!!?
[22:34:03] <mru> because I misremembered
[22:34:04] <mru> sorry
[22:34:10] <peloverde> it's ok
[22:34:21] <peloverde> this is just a little frustrating
[22:34:41] <mru> I know, it's inline asm
[23:09:01] <Anaerin> kierank, It's a RTP stream, with an MPEG-TS container inside. FFMpeg used to identify it as H.264 and two AAC streams (and one unknown stream, probably closed captions). Now it gives a weird codec ID (1024) and a stream type of [0][0][0][0]
[23:09:27] <kierank> rtp :/
[23:13:26] <lu_zero> Anaerin: mind trying a small patch?
[23:13:34] <Anaerin> Not at all.
[23:13:40] <lu_zero> and/or giving me the url?
[23:13:57] <Anaerin> The URL is multicast, and ISP limited, unfortunately.
[23:14:35] <lu_zero> free.fr?
[23:14:40] <Anaerin> I've got some wireshark captures.
[23:14:47] <Anaerin> No, Sasktel Max.
[23:15:06] <lu_zero> good, another field to test it =)
[23:15:21] <j-b> BBB: does lavc support AMR-WB+ ?
[23:15:44] <BBB> doesn't sound familiar
[23:15:47] <lu_zero> http://article.gmane.org/gmane.comp.video.ffmpeg.devel/52488
[23:15:47] <BBB> only AMR-WB afaik
[23:15:51] <BBB> what is amrwb+?
[23:15:57] <Dark_Shikari> One better.
[23:16:20] <j-b> BBB: bigger, faster, more stupid :D
[23:16:32] <BBB> Dark_Shikari: that is amrwb++
[23:16:38] <BBB> amrwb+ sounds like a parsing error
[23:16:41] <j-b> half-one better :)
[23:17:00] <Sean_McG> hmmmm, same fails as Linux when I run fate on Sol10 with gcc 4.6
[23:17:01] <lu_zero> I planned to push this on the tree once tested ^^;
[23:17:57] <lu_zero> (while I'm hacking the slightly more uniform solution)
[23:19:25] <Dark_Shikari> BBB: http://pastebin.com/UBrDYB1e bench please, I can't get my stddev low enough today
[23:21:09] <Anaerin> Patch applied, making now.
[23:23:33] <kierank> j-b: ^ there's the guy you want to ask about amr-wb+
[23:23:48] <superdump> who?
[23:24:08] <kierank> you
[23:24:11] <j-b> well, lavf/isom.c doesn't know sawp, so I guess there is a reason
[23:26:53] <BBB> Dark_Shikari: that shouldn't matter, the function is inlined so luma/chroma is always expanded in the generated asm already (I checked that)
[23:27:15] <Dark_Shikari> Merged
[23:27:26] <Dark_Shikari> in current code, the emu edge checks get repeated
[23:27:29] <Dark_Shikari> along with the mv0  check
[23:27:39] <Dark_Shikari> it would be better to merge luma/chroma too but that would be uglier
[23:27:55] <Dark_Shikari> my benches suggest it's a bit faster, but I can't be sure
[23:28:38] <j-b> kierank: the code tells me it isn't supported
[23:29:27] <superdump> there isn't a wb+ decoder in ffmpeg to my knowledge :) unless someone sneaked one in while i was away
[23:29:44] <Anaerin> lu_zero, Patch (applied to latest trunk with fuzzing) broke the build: libavformat/mpegts.c: In function âff_mpegts_parse_openâ: | libavformat/mpegts.c:1802: error: implicit declaration of function âmpegts_set_serviceâ
[23:29:52] <lu_zero> uhm?
[23:29:54] <lu_zero> wait
[23:30:10] <lu_zero> let me update it
[23:30:17] <Anaerin> Thanks. :)
[23:30:32] * mru read that as "illicit declaration" at first
[23:30:50] * mru makes note to include such an error message if he ever writes a compiler
[23:31:10] <Anaerin> Along with "Unlawful instruction"s?
[23:33:25] <BBB> Dark_Shikari: it's probably slightly faster, it'd be nice if we could prevent the code duplication but I guess that's hard... in principle I'm ok with it, I'll benchmark it in a little (working on finishing your comments on my emu_edge patch right now)
[23:33:36] <Dark_Shikari> ok
[23:34:00] <lu_zero> mpegts_set_service doesn't exist...
[23:35:36] <Anaerin> That could be a problem.
[23:35:46] <lu_zero> drop that line and tell me if it works
[23:36:22] <Anaerin> So, essentially, set auto_guess to 0
[23:36:48] <Anaerin> okay, passed that point. still Make'ing
[23:39:40] <lu_zero> Anaerin: you'll be around tomorrow?
[23:40:03] <Anaerin> No, actually. I'm headed out of town 'til Tuesday night.
[23:40:13] <lu_zero> and/or you'd be able to give me a vpn to try myself some stuff?
[23:40:17] <lu_zero> I see
[23:41:13] <Anaerin> I don't have the upstream to provide a VPN, unfortunately. But you can use those stream captures, combined with rtpdump, to play it back locally to create a "virtual stream"
[23:52:40] <lu_zero> Anaerin: I'll look into it
[23:56:15] <Anaerin> lu_zero, Thanks. Here's the output from an older ffprobe run on these streams, if that helps: http://pastebin.com/WZVLX2Hq
[23:57:29] <lu_zero> the changed bettered the situation somehow?
[23:57:50] <lu_zero> uhmm
[23:57:52] <Anaerin> Right now, ffprobe is just sitting there, with no "probing stream" information at all.
[23:57:59] <lu_zero> I see...
[23:58:20] <Anaerin> (Using loglevel debug)
[23:59:33] <Anaerin> ...And still sitting there...
[23:59:44] <lu_zero> I see