[FFmpeg-devel-irc] IRC log for 2010-07-06

[irc at mansr.com]

[00:07:07] <CIA-99> ffmpeg: mru * r24068 /trunk/libavcodec/aacenc.c:
[00:07:07] <CIA-99> ffmpeg: aacenc: replace VLA with fixed size
[00:07:07] <CIA-99> ffmpeg: Number of channels is restricted to 6 so the size is acceptable
[00:07:07] <CIA-99> ffmpeg: for the stack.
[00:10:00] <Honoome> I hate summer >_<
[00:10:25] <mru> heat knock out your server?
[00:10:41] <Honoome> no it's knocking out me :/
[00:11:39] <Honoome> and I can't get to my office where I have firefox (yamato is online, and building... it's _hot_) here I don't have it and the tyan website fails
[00:12:38] <mru> feel free to investigate the fate failures
[00:12:49] <Honoome> which fate failures?
[00:12:58] * Honoome hopes nothing related to tablegen
[00:13:05] <mru> regtest-mxf and one other
[00:13:15] <mru> a commit by stefano broke them
[00:13:30] <Honoome> mxf reminds me of something
[00:13:41] <mru> r24066 is the bad one
[00:14:18] <Honoome> oh by the way, the util-linux-ng rewritten buildsystem is published, and Kay Sievers seems to be in favour of it :P
[00:14:30] <mru> :-)
[00:14:51] <mru> he seems mostly resonable from what I've seen
[00:15:18] <Honoome> yeah, he just dislike hacks, can't blame him
[00:15:53] <mru> if everybody did that, the world would be a better place
[00:16:59] <Honoome> most people are too busy with correcting people with "it's GNU/Linux.."
[00:18:41] <Honoome> or in the case of monty trying to get back "his"sql :P
[00:20:31] <Katrinplommon> is there anyone in here who is unemployed with alot of time on their hands and likes looking into odd vcd standards from the mid 1990s
[00:23:25] <Katrinplommon> or where is the correct place to paste codec requests on the official forum?
[03:29:05] <peloverde> Katrinplommon: Format requests can be filed in the bug tracker
[03:29:49] <peloverde> http://roundup.ffmpeg.org
[03:42:13] <Dark_Shikari> Yuvi: thought on storing words for deblocking
[03:42:51] <Dark_Shikari> if the deblocking filter stores 2 bytes, it might be better to store 1 byte at a time when on mb edge
[03:42:54] <Dark_Shikari> in case it crosses a cacheline
[03:42:55] <Dark_Shikari> (on intel)
[03:43:14] <Dark_Shikari> cost of normal store: 1 clock
[03:43:18] <Dark_Shikari> cost of cacheline store: 14 clocks
[03:43:26] <Dark_Shikari> amortized for mbedges: 1 * 0.75 + 14 * 0.25
[03:43:40] <Dark_Shikari> = 4.25 clocks
[03:43:43] <Katrinplommon> peloverde it's very weird that roundup is in the chrome virus filter
[03:44:29] <Dark_Shikari> storing byte-at-a-time will save 2.25 clocks amortized, times 16 = 32.5 clocks per edge
[03:44:46] <Dark_Shikari> one could even detect cacheline-split if one wanted
[03:51:07] <peloverde> Katrinplommon: That's the expired certificate warning
[03:55:04] <Katrinplommon> so it's nothing to worry about then
[03:57:36] <peloverde> correct
[04:07:54] <Katrinplommon> https://roundup.ffmpeg.org/issue2073
[04:07:58] <Katrinplommon> joy to the world.
[04:08:11] <Katrinplommon> probably very easy for a skilled ffmpeg coder to ad
[04:08:25] <Katrinplommon> More a question of interest;)
[04:09:10] <peloverde> mike likes old game formats
[04:09:29] <Katrinplommon> yeah i just mailed him a pile of converted 3DO videos i've been going through
[04:10:01] <Katrinplommon> pity his wiki doesn't have any irc chan cause i'm mainly just intersted in game formats
[04:10:44] <Katrinplommon> this is what a 3DO .film file looks like after being converted to xvid with ffmpeg http://www.youtube.com/watch?v=DjO9HlDBoiE :)
[04:11:54] <Katrinplommon> only about 10 3do games used .film so it's very fun when you actually find something that ffmpeg eats:)
[04:12:53] <peloverde> If the FFmpeg decoder is old enough you should be able to directly upload to youtube
[04:24:03] <Katrinplommon> nah it's too dated
[04:24:10] <Katrinplommon> black screen+audio
[05:19:42] <Tjoppen> god morgon
[05:20:29] <av500> gm
[05:20:44] <kshishkov> god morgon
[05:21:35] <thresh> moroning
[05:21:44] <Compn> and good night
[05:21:49] <Compn> way too late for me :P
[05:22:03] <Tjoppen> :)
[05:22:22] * Compn dreams of multimedia formulas and codecs
[07:41:39] <CIA-99> ffmpeg: diego * r24069 /trunk/libavcodec/h264.h:
[07:41:39] <CIA-99> ffmpeg: Add av_unused to decode_mb_skip declaration to fix the following warning:
[07:41:39] <CIA-99> ffmpeg: libavcodec/h264.h:1260: warning: ?decode_mb_skip? defined but not used
[07:41:39] <CIA-99> ffmpeg: patch by Eli Friedman, eli.friedman gmail com
[09:18:33] <lu_zero> hi Honoome
[09:18:46] <Honoome> need caffeine
[09:44:43] <Tjoppen> looking a bit at dolby-e. might have patch the mpegts demuxer to handle it
[09:45:56] <Tjoppen> I assume it wouldn't be too much of a problem adding CODEC_ID_DOLBY_E and an entry in on of the tables in mpegts.c
[09:46:52] <Tjoppen> apart from there being no decoder or encoder of course..
[09:50:18] <mru> adding an ID for a (to be) major codec without having a decoder should be ok
[09:51:46] <mru> http://www.linuxjournal.com/content/openofficeorg-use-gstreamer-multimedia
[09:53:17] <KotH> this sint something new
[09:53:30] <mru> shows my ignorance of openoffice
[09:53:30] <KotH> oo on debian had a gstreamer dependency for at least a year
[09:53:56] <KotH> well... how many people do actually know what kind of framework is up to the task?
[09:54:22] <KotH> everyone talks about gstreamer, it cannot be that bad!
[09:54:24] <Tjoppen> mru: cool. we could trivially add the ability to remux mpegts <-> mxf with dolby-e :)
[09:54:53] <Tjoppen> looks like kierank has done some RE work on it
[09:55:35] <mru> < av500> will we have DSP accelarated spell checking soon?
[09:55:45] <av500> heh
[09:56:19] <kshishkov> Digital Simian Processing?
[09:56:28] <mru> KotH: a framework must both provide a frame _and_ work
[09:56:32] <mru> gst is all frame and no work
[09:57:23] <av500> ffmpeg is all work and no frame...
[09:57:47] <KotH> mru: yes, but you've to start to think like a mere mortal coder, not like an ffmpeg coder
[09:58:13] <mru> mortal coders produce only mortal apps
[09:58:16] <KotH> mru: for a mere mortal, ffmpeg, if he ever heard about it, is a very low level, dubious, half complete, cryptic library that is very hard to use
[09:58:44] <mru> the last part of that, from dubious and on, fits gst as well
[10:10:56] <av500> mru: <amaraemerson>  hi guys, building libvpx with different compilers and optimizations, the resulting encoders produce ifferent files
[10:11:02] <av500> specifically, enabling ARM neon vectorisation causes vastly improved performance but the file is about 30% larger. it's still playable
[10:11:17] <mru> someone is doing something horribly wrong
[10:11:25] <av500> of course
[10:11:52] <mru> I guess he's talking about the neon asm in libvpx
[10:12:12] <mru> merely enabling neon in the compiler wouldn't give a speedup
[10:32:46] <lu_zero> btw
[10:33:14] <lu_zero> to split an mpeg2video+audio in mpeg I had to resort to mencoder...
[10:33:25] <lu_zero> ffmpeg does not streamcopy correctly ^^;
[10:33:37] <mru> tell us something new
[10:34:08] <lu_zero> the streams in esof are eventually working properly
[10:34:21] <lu_zero> we had to accomodate a _bit_ of network glitches
[10:52:25] <Honoome> and some sleep calls in a custom demuxer using posix mqs... just to say
[10:55:28] <lu_zero> Honoome: I'll replace it with something saner soon
[10:56:20] <lu_zero> still we'll need to reconsider that lock
[11:21:05] <Katrinplommon> https://roundup.ffmpeg.org/issue2073
[11:21:34] <Katrinplommon> hmm what should i do, the movie file on the disc is a 600meg chunk that gets errors when i extract it with isobuster
[11:21:39] <Katrinplommon> so making a sample is impossible
[11:21:47] <Katrinplommon> should i just upload the whole thing somewhere
[11:23:37] <KotH> Katrinplommon: how about starting with what carl eugen requested?
[11:23:52] <KotH> Katrinplommon: and beside, this is a development channel, not a user support channel
[11:24:03] <KotH> Katrinplommon: such questions belong to #ffmpeg
[11:24:20] <Katrinplommon> ok
[11:33:24] <mru> Dark_Shikari: ping
[11:43:57] <CIA-99> ffmpeg: mru * r24070 /trunk/libavformat/file.c: file_protocol: remove redundant #include sys/time.h
[11:43:58] <CIA-99> ffmpeg: mru * r24071 /trunk/libavformat/rtpenc.c: rtpenc: remove unnecessary #include unistd.h
[11:43:59] <CIA-99> ffmpeg: mru * r24072 /trunk/libavformat/os_support.c: os_support: include some headers only when needed
[11:50:29] <Honoome> mru: are you doing that by hand or you found a lint-like tool that does it?
[11:50:58] <mru> I found them when building for a target that doesn't have those headers
[11:51:13] <Honoome> kk
[11:51:30] * Honoome really needs to find a tool that can list those itself...and then run it on multiple OSes
[11:51:38] <Honoome> FreeBSD is known for not including the stuff it needs
[11:51:42] <mru> yeah
[11:51:47] <mru> contrary to specs
[11:52:43] <kshishkov> that's why it's "Free" BSD, free of stuff
[11:52:44] <Honoome> heh... well if I find another project including <malloc.h> I'll cry though
[11:53:00] <mru> we only do it conditionally
[11:53:09] <Honoome> mru: is there any target still needing that?
[11:53:18] <Honoome> [please don't say mingw...]
[11:53:20] <mru> you never know
[11:53:30] <mru> if the header exists, including it won't do any harm
[11:53:40] <Honoome> depends how you check whether it exists
[11:53:52] <mru> try to include in a test
[11:54:03] <Honoome> some projects used to check its presence with test -f /usr/include/malloc.h ... on fbsd it causes #error :P
[11:54:15] <mru> lol
[11:54:23] <mru> well, we check_header it
[11:54:57] <Honoome> still afaik it's only ever needed by way-too-old glibc-versions, and all the modern systems support malloc() in stdlib.h.... so myself I try to stay away from it
[11:55:01] <av500> mru: [13:54] <amaraemerson> manual assembly is 70% faster than generic, gcc autovec is 5% faster (don't think it's really doing much neon), and armcc is about 30% faster than _manual_ assembly, but it produces a larger video file
[11:55:04] <mru> nonstandard things like memalign() are often declared in malloc.h
[11:55:14] <BastyCDGS> hey @ all
[11:55:25] * av500 hides
[11:55:30] <mru> av500: well, that's coming from an arm employee
[11:55:31] <kshishkov> Honoome: other *BSDs also have problems with it, like MacOSX
[11:55:50] <Honoome> kshishkov: osx is 99% fbsd for the libc if I recall correctly
[11:55:54] <mru> av500: ask if those figures are on real code or some synthetic test case used to show off the compiler
[11:56:03] <av500> mru: you can tell that by the a's r's and m's in the name :)
[11:56:15] <av500> mru: libvpx
[11:56:16] <mru> av500: no, from the hostname
[11:56:17] <BastyCDGS> hope you are all fine
[11:56:28] <mru> BastyCDGS: we were, until you arrived :-)
[11:56:39] <_troll_> precautionary measure
[11:56:44] <BastyCDGS> *gg*
[12:15:11] <av500> _troll_: http://www.flickr.com/photos/av500/sets/72157624309805057/
[12:16:52] <kierank> i see a suprising number of macs
[12:17:17] <janneg> av500: the camera is too old to have colours?
[12:17:26] <av500> yeah, they held a mac addicts self help meeting
[12:17:32] <av500> janneg: yep
[12:17:57] <kshishkov> av500: where's the biggest FFmpeg contributor (i.e. you)?
[12:18:12] <av500> there was no mirror
[12:18:33] <av500> I can photoshop myself in....
[12:18:54] <thresh> ha nice t-shirts
[12:19:34] <kshishkov> guess what troll made them?
[12:19:46] * _troll_ waves
[12:19:47] <thresh> there is only one _troll_ in here!
[12:20:11] * av500 votes for the _troll_
[12:20:28] <kshishkov> av500: you should feed him instead
[12:21:12] * av500 feeds the troll with neon intrinsics
[12:21:35] * _troll_ spits
[12:22:01] * kshishkov offers troll altivec ABI instead
[12:22:27] * _troll_ chokes
[12:23:04] <kierank> what about amiga?
[12:23:06] * kshishkov adds Loongson MMX for a side dish
[12:23:50] <av500> kierank: he got that already today...
[12:24:35] <av500> kshishkov: btw, did you upgrade to the NanoNote yet?
[12:25:12] <kshishkov> av500: yes, of course. But if people see *you* using it, it would be more impressive
[12:25:42] <av500> I had one here in my pocket, cant find it atm....
[12:26:00] <kshishkov> use brush and tweezers
[12:26:27] <kshishkov> well, in theory it should be an interesting player
[12:26:55] <_troll_> if they stuck a real SoC and a better display in it, it might be interesting
[12:27:10] <av500> and a different case and ....
[12:27:24] <av500> i heard pandora ships....
[12:27:35] <kshishkov> anything to say about those XBurst CPUs though?
[12:27:43] <_troll_> yuck
[12:27:53] <_troll_> reminds me of netburst
[12:28:04] <kshishkov> could remind of Loongson
[12:28:10] * _troll_ is not impressed with chinese mips clones
[12:28:49] <kshishkov> av500: still, have you found any usage for it except for trolling?
[12:29:34] <av500> no, I dont have one
[12:30:39] * kshishkov thinks what exotic CPU arch to pursue next
[12:30:57] <_troll_> VAX
[12:31:06] <av500> Z1?
[12:31:39] * kshishkov thinks what exotic and portable CPU arch to pursue next. With FFmpeg running on it.
[12:32:00] <av500> put VAX on VAZ
[12:32:05] <_troll_> there is only one viable portable cpu
[12:32:20] * kshishkov has BBB6 and BBC4
[12:37:17] <CIA-99> ffmpeg: mru * r24073 /trunk/libavfilter/vf_pad.c: vf_pad: restore use of _CCIR colourspace conversion macros
[12:37:23] <Tjoppen> av500: a little hard with only 64 words RAM. and float only :)
[12:38:08] <av500> so I guess large precomputed tables are a out...
[12:38:28] <_troll_> a.out?
[12:38:49] <av500> hey, thats my filename as well!
[12:40:39] * kshishkov thought that was a format
[12:41:16] <Tjoppen> http://www.iwi.uni-hannover.de/lv/ueinedv/z1-demo2.avi
[12:41:38] <Tjoppen> all computers should be operated via crank
[12:42:32] <kshishkov> those were called arithmometers
[12:43:22] <kshishkov> Russian ones were most advanced ones (since they were invented by some KTH graduate)
[12:45:31] <Tjoppen> well, no. the z1 is programmable
[12:46:10] <Tjoppen> you can even do loops, if you join ends the tape togeter
[12:48:17] * _troll_ joins the tape ends into a möbius strip
[12:48:47] <av500> _troll_: go write code that executes from both LTR and RTL :)
[12:49:01] <_troll_> of course, no fun otherwise
[12:49:04] <Tjoppen> like certain bacterial dna
[12:49:10] <kshishkov> _troll_, it won't work - punch tapes had special column to prevent that
[12:49:20] <Tjoppen> can be read six or twelve ways. I forget which
[12:49:31] * av500 gives the punch tape punch a punch
[13:05:18] <CIA-99> ffmpeg: mru * r24074 /trunk/libavcodec/ (libxvidff.c utils.c): Move av_tempfile() to libxvidff.c as only the xvid wrapper needs it
[13:23:35] <CIA-99> ffmpeg: mru * r24075 /trunk/libavcodec/ (libxvid_internal.h libxvid_rc.c libxvidff.c): Rename av_tempfile() to ff_tempfile()
[13:41:30] <BBB> merbanan: I just arrived at work ;)
[13:41:48] <BBB> ohwell
[13:41:54] <merbanan> :)
[13:49:13] <mchinen> anyone know why time_base for mp3s at 44100 sample rate produce have values like 1/90000 which cause rounding errors?
[13:49:59] <mchinen> thinking about changing this to be multiples of the sample rate instead
[13:50:35] <kshishkov> IIRC it's standard clock for MPEG
[13:51:08] <mchinen> ah
[13:51:43] <mchinen> to get sample accurate dts right now I have to do some weird rounding hacks
[13:53:02] <kshishkov> sounds like an overkill, your next task will be "pixel-accurate seeking"
[13:53:11] <mchinen> haha
[13:53:25] <mchinen> but for audacity we need sample accurate seeking
[13:53:44] <mchinen> or else make the user wait till the entire file loads
[13:54:03] <BBB> 1/90k for mp3 sounds weird
[13:54:05] <BBB> you can change it
[13:54:10] <BBB> for mp2-in-mpeg, 1/90000 is normal
[13:54:25] <BBB> that's mpeg clockrate and it's about as exact as pts/dts will ever get in there
[13:55:15] <av500> mchinen: ???
[13:55:56] <av500> for sample accurate seek in mp3 you have to parse the file anyway, no?
[13:56:34] <mchinen> av500: yes but av_seek_frame does this for you
[13:57:22] <mchinen> and if you have cbr, no you don't with the changes i hopefully will commit
[13:59:40] <av500> mchinen: how do you know it is CBR?
[14:00:52] <merbanan> xing header
[14:00:52] <mchinen> assume a framesize by looking at the first few and compute desired length till end of file.  If the real filesize is off by less than one frame its most likely cbr
[14:01:18] <mchinen> yeah or some header thing if it exists
[14:01:22] <pross-au> xing headers!!
[14:01:28] <mchinen> i don't know if we have parsers for this?
[14:01:40] <kshishkov> unlikely
[14:01:55] <av500> VBRI header ftw!
[14:02:08] <av500> merbanan: XING header is in every CBR mp3?
[14:02:24] <kshishkov> nope
[14:02:42] <kshishkov> only the ones produced by certain encoders
[14:02:50] <av500> iKnow
[14:03:21] <kshishkov> av500: that is lawsuit-firendly trademark you've just used
[14:03:29] <av500> ?
[14:03:47] <av500> it is not a trademark
[14:03:56] <kshishkov> tell that to Apple lawyers
[14:04:09] <av500> apple invented the Fraunhofer VBRI tag?
[14:04:32] <av500> the conspiracy is deeper than me thought....
[14:04:58] <kshishkov> I meant "lowercase-i-before-uppercase-letter" word
[14:05:58] <merbanan> av500: YES!!!
[14:06:11] <jai> the mp3 demuxer can parse xing and vbri
[14:06:17] <jai> we cant write them out though
[14:07:20] <mchinen> okay good, that'll help too.
[14:07:55] <lu_zero> BBB: you around?
[14:08:26] <Honoome> kshishkov: is it just me or apple had a huge "in your face cisco" moment by renaming the iPhoneOS into iOS? :P given that Cisco was the one having a trademark over iPhone iirc
[14:08:57] <kshishkov> Honoome: it's just you
[14:09:11] <BBB> lu_zero: a little
[14:09:21] <BBB> I'll look at the mpeg thing after the worldcup game
[14:09:21] <lu_zero> cisco will produce a touch table called ipad
[14:09:32] <BBB> ?
[14:09:39] <kierank> Honoome: they have a licensing agreement
[14:09:47] <Honoome> kierank: yeah I know that
[14:09:47] <lu_zero> BBB: ok =)
[14:10:06] <Honoome> but it was just funny to think after that mess that they called it iOS... given that IOS for me reminds of something else :P
[14:10:25] <av500> Honoome: sjobs did not care about you...
[14:13:46] <mru> Honoome: cisco?
[14:13:53] <Honoome> mru: yeah
[14:29:21] <CIA-99> ffmpeg: mru * r24076 /trunk/libavformat/file.c: Add #ifdefs around code specific to file and pipe protocols
[15:03:35] <Compn> DonDiego : any idea why we are keeping these samples >> http://samples.mplayerhq.hu/mov/animatrix/
[15:03:44] <Compn> i dont see any bugzilla or roundup, havent searched the lists tho
[15:04:22] <KotH> hmm.. because tehy are animatrix?
[15:04:33] <DonDiego> try playing them
[15:04:50] <DonDiego> they are tricky beasts
[15:04:54] <KotH> hmm.. 2008?
[15:04:57] <DonDiego> edit lists and whatnot
[15:04:59] <Compn> ah editl ist
[15:05:01] <KotH> they are quite new... too new actually
[15:05:13] <KotH> Compn: feel free to relable the directory :)
[15:05:48] <Compn> i'll just move it from there to editlist dir :)
[15:05:57] <KotH> or that :)
[15:06:04] <DonDiego> no, check them first
[15:06:12] * Compn wonders why he didnt think to play them first
[15:08:31] <KotH> probably because elenril infected you with his lazynes
[15:08:51] <Compn> DonDiego : would symlinks to editlist dir be good or would that screw up mirroring ?
[15:09:04] * elenril throws some tropes at KotH 
[15:09:27] <DonDiego> no, mirroring can handle that
[15:10:03] <av500> DonDiego: http://www.flickr.com/photos/av500/sets/72157624309805057/
[15:10:29] <DonDiego> seen those, neat
[15:11:10] <DonDiego> http://www.flickr.com/photos/av500/4767125825/in/set-72157624309805057/
[15:11:17] <DonDiego> lol at beos
[15:11:32] <av500> well, it is true
[15:11:41] * Compn pretends he remembers how to symlink
[15:11:55] <Compn> ln -s something something
[15:12:03] <av500> like copy
[15:12:06] <av500> src dst
[15:12:14] <KotH> DonDiego: you removed beos support?
[15:12:26] <av500> KotH: look at the picture
[15:12:33] <kshishkov> yep, in mmu_man online presence
[15:12:38] <av500> the reflection in his glasses has the commit message
[15:13:05] * KotH enlarges the picture
[15:13:17] <av500> you needs some CSI foo of course...
[15:13:18] * KotH sees the secret message inbetween the pixels
[15:13:53] * KotH starts to fear for av500 
[15:14:21] <kshishkov> why? because he's the biggest FFmpeg contributor?
[15:15:42] <DonDiego> how can i commit individual diff hunks with git?
[15:15:49] <Honoome> DonDiego: git add -p
[15:15:56] * DonDiego tries
[15:16:43] <Compn> hooray, animatrix samples symlinked into editlist
[15:16:56] <av500> commit!
[15:26:51] <BBB> Vitor1001: did I mention that inline asm (or maybe it's float asm) is headache-inducing?
[15:26:56] <BBB> I'm getting a headache when reading it :-p
[15:27:20] <mru> inline asm is nightmare
[15:27:52] <av500> mru: the arm fellow finally found out that armcc was slower than gcc for libvpx :)
[15:27:53] <BBB> so why do we do it
[15:27:58] <av500> for the decoder...
[15:28:06] <av500> suddenly, speed did not matter any more..... :)
[15:28:52] <mru> armcc slower than gcc is unusual
[15:29:10] <mru> 5-10% faster is typical
[15:29:40] <av500> well, I do not think he know much (yet), gg puts him as recently graduated...
[15:29:46] <BBB> libvpx is written in a very obscure way
[15:29:52] <BBB> might change how compilers apply optimizations
[15:29:58] <BBB> their loops are really really really weird
[15:30:33] <av500> really?
[15:30:48] <BBB> imo
[15:30:53] <BBB> different than usual
[15:31:01] <mru> armcc does best on canned benchmarks
[15:31:16] <mru> but then so does gcc
[15:31:31] * kshishkov gets a fresh can of FFmpeg
[15:31:51] <av500> mru: http://ffmpeg.pastebin.com/GPtiRNt9
[15:31:56] <mru> kshishkov: shall I bring you some spam?
[15:32:25] <kshishkov> mru: yes, please
[15:33:03] <BBB> pengvado: why if it's ==7?
[15:33:28] <BBB> I thought 0-7 were caller-save (or whatever you call that)
[15:33:34] <mru> "armcc is about 30% faster than _manual_ assembly, but it produces a larger video file"
[15:33:46] <mru> that means it generated fast code doing the wrong thing
[15:34:01] <BBB> it means, more logically, that the settings were wrong
[15:34:02] <kshishkov> sounds like icc
[15:34:04] <mru> it's easy to be fast if you don't need to be correct
[15:34:05] <BBB> or different
[15:34:50] <mru> a simple way to make it appear ludicrously fast would be to have the block compare functions always return zero
[15:35:06] <mru> then ME would "finish" immediately
[15:35:19] <mru> the rest would still produce a valid file
[15:35:27] <mru> albeit with horribly bad motion vectors
[15:35:30] <av500> mru: I assume something like that
[15:35:43] <pengvado> 0-5 are caller-saved on win64
[15:35:52] <mru> and that would indeed make the encoded file larger if targeting constant quality
[15:35:52] <kshishkov> personally I consider (0,0) to be rather neat motion vector
[15:36:19] <av500> mru: but I had not time today for xkcd #368
[15:36:29] <av500> err 386
[15:37:41] <mru> av500: too busy with 598?
[15:38:13] <av500> indeed
[15:38:39] <mru> where's this discussion happening anyway?
[15:38:44] <kshishkov> mru: please do panel 3 from todays Dilbert strip
[15:38:47] * mru sees trolling potential
[15:39:36] <av500> #vp9
[15:39:38] <av500> #vp8
[15:39:56] <kshishkov> stick to vp7
[15:40:17] <mru> that channel is full of trolls already :-)
[15:40:26] <av500> yes
[15:40:52] <av500> it is slowly being taken over by ffdevs
[15:41:22] <jai> av500: epic tshirts btw
[15:41:36] <av500> jai: we had one for you as well
[15:41:42] <BBB> link to dilbert strip with troll?
[15:42:02] <jai> av500: orly :)
[15:42:30] <av500> former gsoc student have free entry to the booth....
[15:42:31] <spaam> BBB: http://www.dilbert.com/dyn/str_strip/000000000/00000000/0000000/000000/90000/3000/900/93946/93946.strip.gif
[15:42:48] <spaam> oh
[15:42:56] <BBB> heh :)
[15:43:53] <av500> finally: gopher for android... http://gopher.floodgap.com/overbite/
[15:44:16] <lu_zero> av500: please...
[15:45:01] <Vitor1001> BBB: sorry, was away from the keyboard
[15:45:06] <BBB> is ok
[15:45:19] <BBB> all I said was that the simd inline code is headache-inducing :-p
[15:45:29] <Vitor1001> BBB: Why?
[15:45:36] <BBB> I don't know yet
[15:45:39] <Vitor1001> It is almost the same as non-inline.
[15:45:42] <BBB> but I got a headache while reading it ;)
[15:45:50] <Vitor1001> Is it "op input, output" the problem?
[15:45:59] <BBB> it might just be my head
[15:46:38] <spaam> ffmpeg website need gopher support
[15:46:45] <spaam> ;)
[15:47:10] <BBB> Vitor1001: what are the BYTTERFLY2/3/4/5?
[15:47:26] <BBB> are they direct copies of similar operations in the C file?
[15:47:36] <Vitor1001> BBB: mostly so.
[15:47:41] <Vitor1001> See libavcodec/dct32.c
[15:48:06] <lu_zero> that reminds me that I have to find a weekend to prepare the foundation website
[15:48:19] <BBB> that's only BF/BF0/1/2
[15:48:26] <lu_zero> assuming everybody stated their opinion on the mockups
[15:48:30] <av500> ?
[15:48:40] <BBB> lu_zero: yes, very pretty, please finish that :)
[15:48:47] <lu_zero> =P
[15:49:08] <Vitor1001> Mostly BUTTERFLY* are different version of BF().
[15:54:21] <Vitor1001> BBB: Actually, it applies basically BF() to four consecutive vectors BF(a[0],b[0],c[0],1);BF(a[1],b[-1],c[1],1); BF(a[2],b[-2],c[2],1); BF(a[3],b[-3],c[3],1).
[15:55:07] <Vitor1001> When the three components of a[] and b[] overlap, I have to special case it.
[16:00:08] <BBB> got it
[16:00:24] <Vitor1001> Note that the xorps trick is a multiplication by {-1, -1, 1,1}
[16:00:50] <Vitor1001> BBB: Actually, it was pretty close to the C code until I started removing shuffles ;)
[16:01:15] <BBB> right now it's not at all close to the c code :-p
[16:01:50] <BBB> so basiclly the only thing I find unexpected is the high amount of stores to memory and loads from memory, I assume each of these are actually necessary given lack of registers or so?
[16:02:49] <Vitor1001> Yes. Unfortunately, I cannot fit all the 32 floats in the registers without having no further register to do the calculations.
[16:04:56] <BBB> for example at the bottom:
[16:04:57] <BBB> +        "addss    60(%1),  %%xmm0           \n\t"
[16:04:57] <BBB> +        "movl     60(%1),      %0           \n\t"
[16:05:11] <BBB> I'm wondering if that slows it down any
[16:05:56] <BBB> I guess it's ok... is this the expected ~4x faster than C code?
[16:06:12] <Vitor1001> just a min.
[16:06:42] <Vitor1001> That big block at the end is code that is hard to SIMD-fy.
[16:06:55] <mru> try harder
[16:06:58] <Vitor1001> The only reason I wrote it in asm is to be sure gcc will not screw it up.
[16:07:17] <Vitor1001> mru: Last time I did I got something 40% slower, but full SIMD
[16:07:34] <mru> then you didn't try hard enough
[16:07:39] <Vitor1001> Actually, gcc gave me a hand writing this block.
[16:07:54] <Vitor1001> mru: Wanna see the C code?
[16:10:25] <Vitor1001> mru: http://ffmpeg.pastebin.ca/1895535
[16:11:11] <Vitor1001> BBB: That big block at the end will not be much faster than C. It is not SIMD.
[16:16:03] <mru> inline asm, ugh
[16:16:11] <BBB> pastebin.ca is always so slow for me :(
[16:16:45] <spaam> pastie.org is nice ;)
[16:16:49] <av500> pastebin.com
[16:17:59] <BBB> PERM should be simd'able
[16:18:21] <BBB> not sure about those odd serial adds
[16:18:52] * BBB will have to think a little, and probably read some more float simd
[16:19:10] <Vitor1001> BBB: Perm got slower: http://ffmpeg.pastebin.com/vMVr66LE
[16:19:39] <hyc> hmm, I'm feeling dense. I don't understand how this patch helps to get what I want. https://lists.mplayerhq.hu/pipermail/ffmpeg-devel/2010-July/092509.html
[16:19:46] <Vitor1001> BBB: err, http://ffmpeg.pastebin.com/6nVixzR5
[16:21:46] <pengvado> how much faster does it get on x86_64 where you can fit all the samples in regs at once?
[16:22:36] <hyc> let's see. ok, scale w:h can be arithmetic expressions instead of simple integers, and you can get the input video's W and H. hmmm.
[16:23:03] <Vitor1001> pengvado: No idea, I don't have a 64-bit dev environment.
[16:23:41] <Vitor1001> It should avoid some 6 stores.
[16:24:38] <Vitor1001> BBB: It is hard to beat C PERM() because the C version is just 4 adds.
[16:25:49] <Vitor1001> pengvado: The non-simd part has a considerable register-pressure itoh...
[16:47:23] <BBB> Vitor1001: I'd say in the end that I could look more into it, but you're smart enough to have done a good at that yourself, probably better than me, so it basically looks good to me, provided that you add a one-or-two line comment as for what BUTTERFLY1/2/3/4/5/6/7/8/9 are and why/how they are different
[16:47:31] <BBB> and besides, who cares, it's faster \o/
[16:47:52] <Vitor1001> BBB: Nice. I was doing exactly that.
[16:48:04] <BBB> ty
[16:48:10] <Vitor1001> And BTW, your comment about why so many different macros gave me an idea:
[16:48:35] <Vitor1001> BBB: http://ffmpeg.pastebin.com/vfNrRVqu
[16:48:53] <Vitor1001> Way more readable this way :D
[16:49:14] <BBB> much better :)
[16:50:44] * BBB goes on to review spyfeng's work then
[16:51:57] <Vitor1001> BBB: Thanks!
[16:52:11] <BBB> so I see we all move down the same path
[16:52:15] <BBB> we start at a voice codec
[16:52:17] <BBB> then we start doing simd
[16:52:20] <BBB> what comes next?
[16:52:32] <Vitor1001> BBB: Buy a beagle board ;)
[16:52:44] <BBB> 3) buy beagle board, 4) $$$profit
[16:52:49] <BBB> somehow it doesn't connect
[16:53:12] <BBB> I'll just buy a new iphone4g and do neon on there :-p
[16:53:20] <Vitor1001> BBB: Looks good too
[16:53:26] <Vitor1001> But a BB is way cheaper
[16:53:31] <BBB> really?
[16:53:32] <BBB> how much
[16:53:41] <BBB> the advantage of an iphone4g is that it makes phone calls
[16:53:52] <BBB> and it gets you girls
[16:53:52] <Vitor1001> $150
[16:54:11] <BBB> girls dig the iphone much more than a beagleboard, I bet
[16:54:33] <Vitor1001> _And_ if you get girls using a beagle board, that would be really impressive ;)
[16:54:40] <BBB> very true
[16:54:41] <Honoome> BBB: depends if you attach the beagleboard to a real beagle
[16:54:46] <BBB> heh :)
[16:54:48] <Honoome> and use it to make it speak
[16:54:56] <BBB> mru: I guess we'll need a guid to best neon programming from you ;)
[16:58:04] <Transport> http://www.arm.com/community/partners/display_product/rw/ProductId/4353/ looks better kited out than a beagle board though!
[16:59:49] <CIA-99> ffmpeg: vitor * r24077 /trunk/libavcodec/ (fft.h x86/fft.c x86/fft.h dct.c x86/fft_sse.c): SSE optimized 32-point DCT
[17:14:15] * Vitor1001 brakes FATE again :p
[17:15:30] <mru> fix it
[17:16:12] <Vitor1001> mru: I want your opinion: it is braking because fft_sse.c is only configured if CONFIG_YASM
[17:16:13] <mru> is it really that hard to test things before committing them?
[17:16:38] <Vitor1001> mru: Compile it no matter if have yasm or not or put the dct32 in its own file?
[17:17:15] <Vitor1001> mru: Do you want me to test every non-obviously yasm-related patch with --disable-yasm?
[17:17:41] <mru> no, but I want you to think about it
[17:17:57] <Vitor1001> mru: Maybe a script that try every possible parameter combination to configure.
[17:18:31] <Vitor1001> I wasn't expecting a .c file full of inline asm being conditional to YASM.
[17:18:46] <Vitor1001> Even thought it makes sense after the fact...
[17:18:55] <mru> I'd simply move the dct32 to a separate file
[17:19:03] <mru> it's not like the file will be small...
[17:19:38] <mru> and why the #include common.h?
[17:22:01] <mru> you are however missing includes for libavutil/mem.h and stdint.h
[17:22:19] <Vitor1001> ok, will try to fix all of it.
[17:22:34] <mru> so why did you #include common.h?
[17:23:49] <Vitor1001> Because some old version of it used FFSWAP().
[17:31:22] <Vitor1001> mru: Is "SSE-OBJS-$(HAVE_DCT)" well defined in ffmpeg makefiles?
[17:32:11] <mru> no, it's CONFIG_DCT
[17:32:34] <Vitor1001> And SSE-OBJS?
[17:33:31] <Vitor1001> mru: Finally got it to compile. No, SSE-OBJS does not exist.
[17:33:42] <mru> indeed it doesn't
[17:33:49] <Vitor1001> Should I add it?
[17:34:24] <mru> all the existing sse code uses MMX-OBJS
[17:34:36] <Vitor1001> not the yasm ones.
[17:34:42] <Vitor1001> Ok, I'll use MMX-OBJS.
[17:34:47] <mru> they do too
[17:34:52] <mru> just with more indirection
[17:35:03] <Vitor1001> YASM-OBJS-FFT-$(HAVE_SSE)
[17:35:11] <Vitor1001> They are not compiled if there is no SSE support.
[17:35:32] <mru> right
[17:35:46] <mru> just use MMX for now
[17:35:49] <Vitor1001> Ok.
[17:36:22] <mru> like add it next to x86/fft.o
[17:36:30] <mru> or not
[17:36:36] <mru> use CONFIG_DCT of course
[17:36:42] <mru> no, that will break
[17:36:43] <Vitor1001> mru: Any comment: http://ffmpeg.pastebin.com/Fwi7Smxx ?
[17:37:18] <mru> that will fail with fft on and dct off
[17:37:22] <Vitor1001> I did a svn cp to revert my patch to fft_sse.c.
[17:37:36] <Vitor1001> Why?
[17:37:36] <mru> I don't care about that
[17:37:46] <mru> because fft.c references it
[17:38:00] <mru> with only a HAVE_SSE guarding it
[17:43:03] <Vitor1001> mru: Ok, indeed.
[17:43:10] <Vitor1001> mru: This one should be better: http://ffmpeg.pastebin.com/TjdhNrmi
[17:43:38] <mru> no
[17:43:43] <Vitor1001> Why?
[17:43:44] <mru> that will break if sse is disabled
[17:43:59] <mru> if (HAVE_MMX)     ff_dct_init_mmx(s);
[17:44:06] <mru> and that line is correct
[17:44:32] <mru> just stick an #if CONFIG_DCT around the function in fft.c
[17:46:23] <Vitor1001> ok, will commit it then.
[17:46:25] <Vitor1001> Thanks.
[17:46:39] <Vitor1001> Ow, btw, do you prefer dct32_mmx.c?
[17:46:48] <mru> it's sse code inside
[17:47:03] <Vitor1001> In case someone add other x86 optimizations to it...
[17:47:11] <mru> they can go in a separate file
[17:47:32] <Vitor1001> ok. Will commit them.
[17:47:55] <mru> but why did you do this in inline asm?
[17:47:58] <mru> why not yasm?
[17:49:14] <CIA-99> ffmpeg: vitor * r24078 /trunk/libavcodec/x86/ (Makefile fft.c dct32_sse.c fft_sse.c):
[17:49:15] <CIA-99> ffmpeg: Move SSE optimized 32-point DCT to its own file. Should fix breakage with YASM
[17:49:15] <CIA-99> ffmpeg: disabled.
[17:50:27] <Vitor1001> mru: It will not give us headaches with not enough registers anysoon...
[17:50:47] <mru> it will give other headaches
[17:50:48] <Vitor1001> mru: So I supposed that for this case, yasm/inline is just bikeshed.
[17:51:10] <mru> you have the clobber issue
[17:51:21] <mru> and the fact that inline asm is a monster to read
[17:51:57] <Vitor1001> Just because the "\n\t" ?
[17:52:07] <mru> because of everything
[17:52:19] <mru> scrolling around to see wtf %3 is
[17:52:25] <mru> all the quotes and \n\t
[17:52:39] <mru> lack of syntax highlighting
[17:52:49] <mru> generally awkward asm syntax
[17:52:55] <mru> should I go on?
[17:53:02] <mru> portability issues
[17:53:27] <Vitor1001> I will learn yasm someday ;)
[17:53:30] <Vitor1001> brb, dinner...
[17:53:38] <mru> today is a good day
[17:55:01] <thresh> to die
[18:08:11] <BBB> Vitor1001: learn it
[18:08:13] <BBB> yasm is awesome
[18:51:04] <Dark_Shikari> mru: pong
[18:51:30] <Dark_Shikari> BBB: http://pastebin.org/384636
[18:54:12] <_av500_> Dark_Shikari: BBB is watching the game
[18:54:36] <mru> Dark_Shikari: would you pop in to coredev for a bit?
[19:49:14] <kierank> i can't wait to hear what bizzare reason ffdshow will give for not removing faad
[19:49:35] <J_Darnley> "better quality"
[19:49:42] <kierank> "bugs"
[19:49:56] <kierank> I'm going to make the patch and shove it down their throats if necessary
[19:50:11] <J_Darnley> not limited to 16bit output
[19:50:39] <kierank> hmmm maybe that's why they don't use lavc's ac3 decoder
[19:51:19] <kierank> clsid will come up with some bizzare reason
[19:51:34] <Dark_Shikari> they don't even use ffmpeg
[19:51:41] <Dark_Shikari> they use their insane fork
[19:54:41] <mru> is there a name for the letters gcc allows in the %0 things in inline asm?
[19:54:58] <mru> like %h0 for the ah register (iirc)
[19:56:06] <kierank> wtf why does ffdshow need tremor
[19:59:35] <Dark_Shikari> kierank: to make it bigger
[20:00:05] <kierank> same goes with libdts/liba52 and others
[20:00:38] * kierank considers creating ffdshow-debloat
[20:01:37] <elenril> kierank: mplayer? ;)
[20:01:50] <kierank> elenril: note the "dshow"
[20:02:18] <elenril> kierank: note the ;)
[20:02:29] <elenril> anyways, isn't dshow deprecated?
[20:02:33] <kierank> yes
[20:02:54] * kierank decides not to create ffdshow-debloat but instead start a flamewar on doom9
[20:03:11] * elenril approves
[20:03:17] <elenril> trolling is more fun
[20:05:22] <kierank> neuron2 will lock it anyway
[20:06:15] <elenril> where did you get that nut file from
[20:06:26] <Compn> does ffdshow have any patches for ffmpeg/mplayer ?
[20:06:28] * Compn goes afk
[20:06:38] <kierank> doubt it
[20:06:44] <kierank> probably destructive patches
[20:06:59] <Dark_Shikari> Compn: they maintain their own fork
[20:07:12] <Dark_Shikari> as in, so many changes that they have to go to great effort to merge updates
[20:07:27] <elenril> yay for open development
[20:08:01] <kierank> the same guy that runs the ffdshow fork did the same thing to mpc many years ago and now only he knows how to update mpc-hc's ffmpeg :/
[20:09:19] <elenril> do they have a web interface for their repo?
[20:10:04] <kierank> yes
[20:10:16] <kierank> ffflame on http://forum.doom9.org/showthread.php?p=1415132#post1415132
[20:10:53] <peloverde> nice\
[20:11:17] <elenril> where's aac?
[20:11:17] <kierank> also the repo's been checking out for 20 minutes now...
[20:11:22] <kierank> whoops
[20:11:32] <kierank> fixed
[20:13:57] <spaam> kierank: good luck with that :)
[20:14:49] <kierank> I will reply with a similar level of logic to the answers
[20:16:50] <elenril> InsaneTrollLogic?
[20:17:12] <twnqx> â„¢
[20:17:13] * elenril should write an irssi script for autogenerating tvtropes links
[20:17:58] <kierank> elenril: yes. if the logic is super twisted i'll invoke the rule about not arguing with stupid people
[20:22:38] <merbanan> libdts/dca has several bugs that causes wrong decoding
[20:22:48] <merbanan> the LFE channel is silent
[20:22:57] <merbanan> just a small detail
[20:23:48] <merbanan> and no Xch support either
[20:24:29] <twnqx> lol, no LFE?
[20:24:45] <merbanan> there is a LFE channel, it's just very silent
[20:25:01] * elenril recalls some problems with downmixing dts in lavc
[20:25:20] <merbanan> the ffmpeg decoder is like 100% faster also
[20:27:10] <peloverde> ffdshow internals are hideous
[20:32:01] <Vitor1001> kierank: Funny thing you started your message with MP1/2/3. Until very recently, mp3lib was _way_ faster.
[20:32:39] <kierank> well it's more a case of duplication than speed
[20:32:54] <kierank> mp3 isn't really going to be taxing on any x86 in the last 10 years
[20:33:27] <Vitor1001> kierank: Yes, but they can always cry about battery life or stealing cycles from h264 decode.
[20:33:44] <Vitor1001> kierank: it's harder to argue with "it's much faster!"
[23:23:47] <Compn> kierank / Dark_Shikari : you know faad supports a few formats not supported by ffaac right ? latm , sbr/ssr etc
[23:23:56] <Compn> or was latm just added hmm
[23:24:17] <mru> we support sbr
[23:24:26] <mru> so stop trolling
[23:24:36] <peloverde> We have supported SBR for months (ages in FFmpeg time)
[23:24:58] <peloverde> Point to SSR in the wild if you think it is important
[23:25:17] <peloverde> janneg: LATM ping?
[23:26:03] <kierank> Compn: latm doesn't work in ffdshow though
[23:26:17] <mru> so that argument is invalid
[23:29:44] <janneg> loas demuxer works on samples extracted from DVB captures, trying to integrate it into the mpeg-ts demuxer atm
[23:29:53] <Compn> mru / peloverde : erm, sorry, i forgot which 3 letter acronymn was supported :P
[23:30:49] <janneg> I probably should clean it up and submit it first
[23:33:07] <janneg> does anyone has loas/latm samples with more than 1 program/stream?
[23:37:10] <kierank> i would speculate bbc hd on dvb-t2 has multiple streams
[23:37:25] <kierank> one normal and one audio description
[23:37:37] <kierank> but afaik there are no decent usb receivers yet
[23:42:46] <janneg> kierank: but probably two different loas on different pids with one audio stream each