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

[irc at mansr.com]

[00:12:37] <saintd3v> peloverde: so do both long and short windows belong to a window group?
[00:13:24] <peloverde> saintdev: Each frame is either one long window or eight short windows, the eight short windows are divided into groups
[00:14:49] <saintd3v> ok, that's what i guessed. what do the groups signify? is each group one temporal block?
[00:16:53] <peloverde> each window is a complete MDCT window
[00:17:13] <peloverde> Windows in the same group have identical scalefactors
[00:17:54] <peloverde> (as well as identical stereocoding status)
[00:22:45] * Honoome wonders what in the mind of humans make them think that theycan make a difference all at once, after five years of nobody caring enough to force a _small_ change? =_= 
[00:54:32] <hemanthm> NAMES ffmpeg-devel
[03:05:40] <saintdev> peloverde: would you be ok with http://pastebin.org/389742
[03:07:45] <peloverde> In principle I have no problem with it but it seems unnecessary until there is a second psymodel available
[03:08:28] <saintdev> true
[07:17:49] <av500> so, now I have all 5 utube 4k samples downloaded
[07:20:06] <kshishkov> can your player handle them in native resolution?
[07:21:23] <av500> not yet
[07:21:34] <av500> I might have to hook a few players together
[07:22:24] <kshishkov> archos videowall?
[07:22:32] <mru> mornings
[07:22:38] <av500> greets
[07:22:49] <Yuvi> why does this guy on the ML keep insisting that a C99 compiler can't use posix functions...
[07:23:14] <av500> because he can?
[07:24:24] <av500> nice, ffplay segfaults on these 4k clips
[07:25:09] <av500> in libavfilter
[07:25:31] <kshishkov> goda morgnar, mru
[07:25:47] <kshishkov> av500: probably swscaler issue
[07:25:48] <mru> kshishkov: in the office already?
[07:25:56] <kshishkov> mru: of course, unlike you
[07:26:07] <av500> mru: a, the german fif
[07:26:09] <av500> gig
[07:26:20] <thresh> moroning
[07:26:22] * av500 must wake up
[07:26:30] <av500> mru: ah, the german gig
[07:26:44] <av500> kshishkov: I hope your offices are airconned
[07:26:50] <kshishkov> av500: I'd say it was just for my entertainment but who cares about me?
[07:26:51] * mru blames the french woman who was supposed to fetch him...
[07:27:05] <kshishkov> mru: I can tell her
[07:27:15] <thresh> don't tell me about air conditioning :(
[07:27:24] <av500> 29.7 here...
[07:27:29] * mru hopes there is air conditioning
[07:27:36] <mru> oh yeah...
[07:27:38] <kshishkov> thresh: you don't like fairy tales?
[07:27:43] <mru> av500: wtf did you do to the trains last night?
[07:27:43] <av500> mru: the air is in a condition!
[07:27:44] <kshishkov> mru: there is
[07:27:56] <av500> mru: some ppl got grilled at 50°....
[07:27:57] <thresh> kshishkov: i'd enjoy airy ones now
[07:28:19] <mru> all trains from FRA were at least 1h delayed
[07:28:42] <av500> heat
[07:28:43] <thresh> maybe they started to melt.
[07:28:53] <mru> I managed to get a on a crowded ICE to mannheim
[07:29:02] <av500> german trains run well in extreme balmy wheather only...
[07:29:08] <mru> caught a delayed connection from there
[07:29:31] <mru> they apologised for the delay, caused by an interruption of service
[07:30:31] <mru> seriously, that's what they said
[07:30:54] <superdump> there has been a delay
[07:31:02] <superdump> it was caused by something that caused a delay
[07:31:12] <kshishkov> by definition
[07:31:15] <superdump> have a nice delay
[07:31:39] <mru> or does "betriebsabbruch" (iirc) mean something else?
[07:32:54] <superdump> google translate says "demolition company"
[07:33:08] <mru> that sounds wrong to me
[07:33:12] <mru> but I'm not german...
[07:33:13] <superdump> probably
[07:33:23] <av500> interruption of service
[07:33:29] <av500> or something like that
[07:33:34] <mru> like I said
[07:34:01] <twice11> interruption od service would be "Betriebsunterbrechung".
[07:34:22] <twice11> "Betriebsabbruch" would be more like "termination of service".
[07:34:37] <mru> but then there should've been no train at all
[07:35:07] <twice11> Maybe it was too hot for the guys to use the right word.
[07:35:20] <mru> the train was nice and cool
[07:35:26] <mru> the second one
[07:35:30] <av500> you lucky bastard :)
[07:35:31] <mru> the first one was too crowded
[07:35:49] <mru> not melting, but not nice either
[07:36:02] <mru> melting ice...
[07:36:05] <mru> hmm
[07:37:41] * av500 ponders grabbing the new laptop and going to the cellar
[07:37:59] <mru> your dungeon has wifi?
[07:38:14] <av500> I can run a cable there as well
[07:38:21] <av500> it has cat6
[07:38:27] <kshishkov> mru: the most crowded train I've seen here is Strasbourg-Offenburg regional train
[07:53:36] * mru facepalms at the c99 "discussion"
[08:13:09] <av500> meh, utube 4k samples are blocky
[08:13:22] <kierank> it's a total waste of time
[08:13:30] <kierank> someone should upload crowdrun
[08:13:54] <av500> they might look good when downscaled to 1080
[08:38:36] * av500 likes the almost poetic: "[PATCH] flvdec.c consider nondecreasing dts order"
[09:01:07] <CIA-99> ffmpeg: benoit * r24209 /trunk/libavcodec/dca.c:
[09:01:07] <CIA-99> ffmpeg: Move XCH parameters into context structure.
[09:01:07] <CIA-99> ffmpeg: Patch by Nick Brereton $name AT n$surname DOT net
[09:07:26] * mru sorts frames in condescending order
[09:07:50] * kshishkov sees that IRL
[09:10:01] * twice11 prefers noncendensing order :)
[09:10:12] * twice11 prefers noncondensing order, sorry, typo.
[09:11:46] <CIA-99> ffmpeg: benoit * r24210 /trunk/libavcodec/dca.c:
[09:11:46] <CIA-99> ffmpeg: Fix side channels when XCh extension is present.
[09:11:46] <CIA-99> ffmpeg: Patch by Nick Brereton $name AT n$surname DOT net
[09:33:44] <markuman> what did you know about the [h264 @ 0xa00dbc0]missing picture in access unit... messages? is the h264 decoder still looking for a pair of frames?
[09:52:40] <CIA-99> ffmpeg: diego * r24211 /trunk: Ignore directory with generated Doxygen documentation.
[10:18:11] <CIA-99> ffmpeg: lu_zero * r24212 /trunk/libavformat/rtsp.c:
[10:18:12] <CIA-99> ffmpeg: Report when a method gets an error status code
[10:18:12] <CIA-99> ffmpeg: That makes easier understand what went wrong.
[10:18:12] <CIA-99> ffmpeg: In debug mode the whole reply gets printed.
[10:43:26] <lu_zero> hi
[10:44:38] <mru> lo
[10:44:43] * kshishkov thinks it's really good idea to make useful commit before "hi"
[10:50:03] <lu_zero> kshishkov: how are you? =)
[10:59:44] <lu_zero> interesting, there is something wrong in h264_parser.c
[11:00:41] <lu_zero> the h264 elementary stream doesn't seem seekable anymore
[11:00:42] <twnqx> Stream #0.2: Subtitle: [0][0][0][0] / 0x0000 Unsupported codec (id=94212) for input stream 2 <-- hm. what kind of subs could that be?
[11:01:18] <twnqx> (in mkv)
[11:01:46] <av500> hmm
[11:01:50] <lu_zero> twnqx: the 0x0000 is telling that it didn't pick anything
[11:01:58] <Compn> twnqx : use mplayer
[11:02:10] * Compn dislikes ffmpeg error messages
[11:02:31] <Compn> mplayer -demuxer mkv that is
[11:02:51] <twnqx> Compn: rebuilding mplayer. my installed binary was linked against an obsolete x264...
[11:03:03] <twnqx> geh, and it doesn't compile
[11:03:46] <twnqx> hm. mkvinfo says S_TEXT/ASS
[11:03:49] <Compn> build static, keep old binaries :P
[11:03:56] <Compn> ass parser isnt in yet
[11:04:18] <twnqx> huh. i'm pretty sure ffprobe identified it earlier
[11:12:59] <lu_zero> twnqx: if it did then we have a problem
[12:09:25] <lu_zero> cartman: what's up?
[12:09:45] <cartman> lu_zero: sky is up
[12:09:47] <cartman> and hello! :)
[12:11:05] <lu_zero> =)
[12:30:10] <av500> DonDiego: no more typos in commit messages, just use: http://whatthecommit.com/
[12:33:14] <CIA-99> ffmpeg: benoit * r24213 /trunk/libavcodec/dca.c:
[12:33:14] <CIA-99> ffmpeg: Use math constant instead of hardcoded rounded value for sqrt(0.5).
[12:33:14] <CIA-99> ffmpeg: Patch by Christophe.Gisquet (gmail)
[12:34:23] <ohsix> ispell hook! or an $EDITOR/VISUAL that does it for you
[12:41:40] <DonDiego> stop bullshitting me with typos already, that's not what i was talking about
[12:41:49] <av500> iKnow
[12:42:11] <ohsix> pancreas
[12:44:04] <DonDiego> ohsix: wtf?
[12:46:53] <benoit-> mru: any way to have make fate verbose, instead of tiny ?
[12:47:10] <benoit-> (already tried V=... of course)
[12:47:59] <mru> I'll fix that
[12:48:26] <benoit-> thanks
[12:48:38] <mru> tonight hopefully
[12:48:50] * mru has a dayjob of sorts for a while
[12:49:29] <benoit-> mru: no problem, I'm in no hurry
[12:51:02] <DonDiego> mru: what are you doing?
[12:51:48] <benoit-> DonDiego: sorting :)
[12:51:53] <kshishkov> DonDiego: sitting and typing
[12:51:55] <mru> DonDiego: writing code
[12:52:02] <mru> well, no actual coding done yet
[12:52:03] <av500> DonDiego: ashishting
[12:52:49] <mru> so how do I get ubuntu to not shove a huge window in my face every time I plug in a usb flash stick?
[12:53:01] <av500> close eyes quickly
[12:53:19] <av500> mru: they make you uses ubuntu? I hope they pay well
[12:53:37] <mru> it was the most sane CD they had on hand
[12:53:47] <kshishkov> sane?
[12:53:55] <mru> if it gets too annoying I'll replace it with something else
[12:56:08] <DonDiego> i use ubuntu at work
[12:56:15] <DonDiego> replace gnome with something else
[12:56:20] <DonDiego> awesome comes to mind
[12:56:37] <mru> not to my mind
[12:56:55] <mru> software rarely is the adjectives in its name
[12:57:10] <janneg> killall -15 hald-addon-storage maybe
[12:57:25] <mru> I found a setting to not open the window at least
[12:57:29] <mru> now it only auto-mounts it
[12:57:33] <ohsix> mru: in that huge window it pops up, go to Edit -> Preferences, Media tab
[12:57:44] <mru> ohsix: yeah, I found that
[12:57:48] <ohsix> yar there; and hal is dead
[12:57:55] <mru> what if I want to enable it again then?
[12:58:02] <mru> when the window is no longer popping up?
[12:58:10] <av500> why would you?
[12:58:22] <ohsix> thats the file browser; you can just open one of them again from Places
[12:58:22] <kshishkov> any folder window may be good for that
[12:58:44] <ohsix> i only mentioned it in the manner i did cuz you did already :P (and calling it nautilus is probably useless)
[13:07:47] <jai> awesome is pretty good
[13:08:09] <mru> isn't one of those silly tiling window managers?
[13:08:41] <mru> ohsix: is it still nautilus?? UGH!!!
[13:09:03] <ohsix> heh, its not as its been in the past; they've thrown most of it out
[13:09:21] <ohsix> press f3 and its like xtree gold!
[13:10:05] <ohsix> and it has tabs and a crumb bar
[13:10:19] <mru> my file manager is called coreutils
[13:10:25] <av500> mc ftw
[13:10:27] * thresh uses zsh
[13:10:39] <thresh> so i can interactively manage my files
[13:10:41] <mru> mc was only good because the dos shell is so shitty
[13:10:47] <av500> thresh: not zsh uses you?
[13:11:05] <mru> thresh: zsh still needs coreutils or equivalent
[13:11:09] <ohsix> it doesn't select the extension when you rename stuff either \m/
[13:11:28] <jai> mru: yeah
[13:11:44] <mru> well, I _want_ overlapping windows at times
[13:11:57] <mru> it's rare for all of a window to contain useful information
[13:12:31] <av500> e.g. MS window
[13:12:54] <ohsix> if its not a terminal window you could probably say its mostly wasted space and useless information :P
[13:13:50] <jai> mru: you can float windows with awesome
[13:14:05] <jai> stuff like gimp would be a pain otherwise
[13:14:41] <mru> is it as customisable as emacs?
[13:14:48] <mru> if not, I'll not consider it
[13:14:54] <jai> mru: of course
[13:15:05] <jai> the config is written in lua
[13:15:13] <mru> blegh
[13:15:18] <jai> quite readable imho
[13:15:32] <mru> it's bloody object oriented
[13:16:00] <jai> http://git.naquadah.org/?p=awesome.git;a=blob;f=awesomerc.lua.in
[13:16:06] <jai> ^ thats what it looks like
[13:16:12] <mru> I know what lua looks like
[13:16:19] <mru> it looks like any other OO lang
[13:16:39] <jai> i meant the overall configuration :)
[13:17:06] <jai> again, i dont know much about why lua sucks, but it seems to fit in quite well
[13:17:37] <jai> you could even write widgets in < 10loc
[13:18:26] * kshishkov thinks the only good object-oriented language for window managers was Smalltalk
[13:19:02] * mru likes his lisp-based wm
[13:19:12] <mru> it makes sense with a functional language
[13:19:16] <mru> events trigger functions
[13:19:46] <jai> mru: which one? sawfish? stumpwm?
[13:19:57] <mru> sawfish
[13:20:02] <jai> k
[13:20:16] <mru> been using it for a decade or so
[13:20:19] <mru> got used to it
[13:20:35] <mru> and I have a minimally intrusive configuration
[13:21:08] <ohsix> sawfish ftw
[13:21:47] <av500> mru: so why dont you use it then?
[13:25:15] <mru> av500: I do on my computers
[13:25:40] <mru> I just got dumped in front of a pc with nothing sane on it
[13:27:02] <av500> apt get install sawfish?
[13:27:04] <kshishkov> yes, IT guy said he can't install Gentoo there
[13:27:09] <av500> lol
[13:27:16] <av500> mru: quit!
[13:27:18] <mru> nobody said such thing
[13:27:36] <av500> so, install gentoo...
[13:27:46] <av500> and take the rest of the week off while it compiles...
[13:27:46] <mru> but ubuntu is half-sane compared to the rpm distros and quick to install compared to gentoo
[13:28:10] <kshishkov> mru: I just said you may like it more when that PC was assembled for you
[13:28:17] * av500 uses an insane rpm distro
[13:28:31] <kshishkov> av500: caldera openlinux?
[13:28:45] <mru> kshishkov: yes
[13:28:46] * lu_zero should come up with better install media for gentoo
[13:29:00] <mru> lu_zero: I'm quite happy with it as is when I have the time
[13:29:27] <lu_zero> av500: updating a single fresh install of ubuntu made me reconsider how gentoo is slow to install ^^
[13:29:35] <lu_zero> still we can do way better =P
[13:30:03] <mru> untarring a stage3 is fast
[13:30:07] <mru> but it's rather minimal
[13:30:16] <av500> lu_zero: I have no idea how slow gentoo is too install, all the docs made my tl;dr...
[13:30:18] <av500> me
[13:30:44] <jai> you cant use your laptop?
[13:30:57] <mru> I don't think they'd like that
[13:31:09] <jai> ah, enterprise security
[13:31:17] <av500> jai: laptop does not run visual source safe
[13:31:28] <jai> av500: lolwat
[13:31:40] <av500> like the deadly joke, they let him work only on one line at a time
[13:32:03] <lu_zero> mru: where did you ended up now?
[13:32:19] <kshishkov> lu_zero: closer to Italy, rejoice
[13:32:43] <lu_zero> how closer?
[13:32:57] <mru> a few metres from kshishkov
[13:33:03] <lu_zero> ah
[13:33:53] <lu_zero> mru: stage4 are the way =P
[13:34:32] <mru> normally stage3 is about what I want
[13:34:44] <lu_zero> =)
[13:34:48] <mru> since I'd be tweaking the flags and recompiling almost everything anyway
[13:35:00] <mru> but get a pc up and running quickly, something more complete would be nice
[13:35:19] <kshishkov> live CD
[13:46:40] <pross-au> utt
[13:47:53] * kshishkov tries to guess what mailer pross-au uses
[13:48:49] <pross-au> yes, um, showing my noobness here. all the cool people seem to use gmail
[13:49:34] <elenril> nah, gmail fails at threading
[13:50:44] <kierank> this thread gets better: http://forum.doom9.org/showthread.php?p=1416686
[13:50:54] <kierank> introducing an audiophile
[13:51:55] <ohsix> almost all the junk he mentions have nothing to do with extra dynamic range olol
[13:55:38] <mru> I bet all that audio he's processing came off 16-bit CDs in the first place
[13:56:36] <pJok> mru, remember that the loudspeaker cords have to be polarized and you have to use the speaker cables for a while before they sound their best...
[13:57:33] <KotH> pross-au: the cool people have their own mailserver
[13:58:01] * KotH wouldnt trust any us company with any private data
[13:59:43] <av500> KotH: you trusted DHL with your home address :)
[14:02:58] <pross-au> KotH: another reason why i wont outsource my brain
[14:35:51] <KotH> av500: not only my home adress, but also my phone number is publicly available online
[14:37:42] <mru> as is mine
[14:37:45] <mru> just ask whois
[14:39:12] <benoit-> I guess we're quite a lot in this case
[14:41:46] <KotH> mru: interestingly, hardly anyone knows about whois...even sysadmins
[14:41:53] <KotH> mru: seems to be a dark art or something
[14:42:09] <mru> my mother knows about it
[14:42:13] <mru> and I didn't tell her
[14:43:32] <benoit-> KotH: snail mail spammers do know about it though...
[14:43:45] <KotH> huh?
[14:43:53] <KotH> never got snail spam that way
[14:44:20] <benoit-> I already received two letters to renew my domain name that way
[14:44:38] <benoit-> KotH: with really high pricing BTW
[14:44:39] <KotH> thought dead family members (who've not even had a mail adress) get a wining notification every three months by snail mail
[14:44:48] <KotH> lol
[14:45:00] <kierank> the domain letters make it look like it's from the official NIC
[14:45:02] <KotH> do you have .com domain or somethign?
[14:45:38] <benoit-> KotH: .org
[14:45:40] <KotH> kierank: just because it's something official looking it does not mean it is official
[14:46:00] <mru> I get the domain scams about once a year
[14:46:10] <KotH> kierank: unless of course it's an official looking death sentence signed by me personally... then i'd run and hide ;)
[14:46:16] <benoit-> kierank: just as official as winning notification by email, huh? :)
[14:46:36] <benoit-> mru: same here
[15:05:11] <twnqx> ok, i'm worried now... trying to compile the latest mkvtoolnix, i get
[15:05:14] <twnqx> In file included from src/common/common.h:14:
[15:05:14] <twnqx> cc1plus: internal compiler error: Segmentation fault
[15:05:19] <twnqx> :(
[15:05:21] <lu_zero> cc1plus
[15:07:39] <lu_zero> which version of gcc?
[15:08:57] <twnqx> 4.3.4
[15:10:47] <lu_zero> uh
[15:10:53] <lu_zero> the memory is fine?
[15:14:15] <Honoome> twnqx: I think I know that one
[15:14:52] <Honoome> twnqx: http://bugs.gentoo.org/show_bug.cgi?id=311595 maybe
[15:15:58] <twnqx> lu_zero: ECC memory with no NMIs, no MCE, and nothing else
[15:16:39] <twnqx> Honoome: yes, excactly that one.
[15:17:09] <twnqx> well, upgrading to 4.4.3 and checking again.
[15:17:28] <Honoome> twnqx: 4.4.3 has the same trouble
[15:21:22] <twnqx> :\
[15:21:43] <spaam> :|
[15:21:47] <microchip_> :\
[16:30:58] <lu_zero> g++ ... soon with even more C++ magic dust
[17:05:26] <BBB> Dark_Shikari: how do I do an or in a yasm macro? like ifidn %1, mmx || idn %1, 3dnow
[17:10:35] <Yuvi> BBB: don't think you can do that, would this be for 64-bit vs. 128 bit registers?
[17:22:47] <BBB> Yuvi: no, for reusing some code for 3dnow and mmx
[17:22:51] <BBB> but not mmxext
[17:23:13] <Yuvi> what's different with mmx2?
[17:23:23] <BBB> pmaxusb is available
[17:24:07] <BBB> btw my guess is that the filter_mbedge calculation of w1/2/3 can only be done in word, not byte, am I right?
[17:24:35] <Yuvi> yes, the *27 etc needs word expansion
[17:25:44] <Yuvi> what do you do without pmaxusb?
[17:25:44] <Yuvi> could you make it a macro and %define PMAXUSB to the mmx/3dnow emulation, or is the mmx version much different?
[17:31:19] <BBB> the mmx version is quite different
[17:31:35] <BBB> (pipelining)
[17:31:50] <BBB> I guess I could do without that...
[17:32:10] <Yuvi> well, do you care about the pII?
[17:32:16] <Yuvi> (much)
[17:32:21] <Yuvi> apparently some opera users do
[17:32:53] <kshishkov> give them IE3
[17:33:22] <Honoome> pll?
[17:33:24] <CIA-99> libswscale: benoit * r31722 /trunk/libswscale/yuv2rgb.c:
[17:33:24] <CIA-99> libswscale: Change the type of Y table to pointer to void in fill_table().
[17:33:24] <CIA-99> libswscale: This fixes warnings about wrong type being used, e.g.:
[17:33:24] <CIA-99> libswscale: libswscale/yuv2rgb.c: In function ?ff_yuv2rgb_c_init_tables?:
[17:33:24] <CIA-99> libswscale: libswscale/yuv2rgb.c:778: warning: passing argument 4 of ?fill_table? from incompatible pointer type
[17:33:24] <CIA-99> libswscale: libswscale/yuv2rgb.c:598: note: expected ?uint8_t *? but argument is of type ?uint16_t *?
[17:33:41] <BBB> libvpx has some bug reports about pre-SSE MMX users
[17:33:43] <BBB> so they do exist
[17:33:57] <Honoome> ah p2 /me was at a los
[17:34:14] <BBB> and if we're gonna claim that we're faster than libvpx, we'd better be faster across a wide range of cpus
[17:34:42] <DonDiego> focus on the relevant cpus first
[17:34:43] <Honoome> I thought some embedded via cpus are non-sse mmx-capable?
[17:34:48] <kshishkov> like Z80
[17:34:52] <DonDiego> and those that will be relevant in the future
[17:35:01] <kshishkov> Honoome: wrong - ARM!
[17:35:03] * DonDiego writes that on a non-relevant cpu
[17:35:05] <BBB> DonDiego: working on it
[17:35:08] <DonDiego> :)
[17:35:14] <BBB> inner loopfilter is done
[17:35:14] <BBB> w
[17:35:17] <BBB> orking on mbedge now
[17:35:26] <BBB> than after that do the chroma loopfilter
[17:35:33] <BBB> which is pretty much a copy of the above 2
[17:35:35] <BBB> then we're done
[17:35:37] <BBB> so almost there...
[18:07:43] <Yuvi> _av500_: do you know about any problems with android's toolchain and movw/movt relocations from .rodata?
[18:08:58] <av500> Yuvi: err
[18:09:12] <av500> not that I know of
[18:10:15] <Yuvi> hm, a user is having problems with it in x264 and claims it only goes away if he moves the data to .text, even with static libs...
[18:11:02] <av500> sorry, no idea
[18:11:37] <Dark_Shikari> BBB: ?
[18:11:53] <BBB> hi
[18:12:24] <BBB> Dark_Shikari: ifidn %1, mmx || idn %1, 3dnow
[18:12:28] <BBB> can I do something like that?
[18:12:32] <Dark_Shikari> why not just do
[18:12:34] <Dark_Shikari> %if 3 ?
[18:12:40] <Dark_Shikari> er, %if %d
[18:12:42] <Dark_Shikari> %3
[18:12:45] <Dark_Shikari> and make it a function argument
[18:12:47] <Dark_Shikari> er, macro argument
[18:12:59] <BBB> ah, i.e. make arg 3 optional?
[18:13:03] <Dark_Shikari> no, just make it 1 or 0
[18:13:05] <BBB> ah
[18:13:06] <BBB> ok
[18:13:19] <BBB> but so in short, yasm does not have an or directive for macros?
[18:13:59] <Dark_Shikari> I don't know, I don't think so
[18:14:19] <BBB> did you check the assembly itself? did it look ok? :-p
[18:14:20] <Dark_Shikari> or, it kinda does, but it can't or between %ifidns
[18:14:24] <Dark_Shikari> no
[18:14:32] <Dark_Shikari> lemme do that.
[18:14:34] <Yuvi> it has the standard || but only for numbers
[18:16:11] <Dark_Shikari> BBB: nice transpose
[18:16:14] <Dark_Shikari> for sse2
[18:16:57] <Dark_Shikari> suggestion:
[18:17:02] <Dark_Shikari> %ifdef ARCH_X86_64
[18:17:06] <Dark_Shikari> mova m8, [pb_80]
[18:17:14] <Dark_Shikari> %define myvar m8
[18:17:16] <Dark_Shikari> %else
[18:17:19] <Dark_Shikari> %define myvar [pb_80]
[18:17:20] <Dark_Shikari> %endif
[18:17:24] <BBB> good point
[18:17:31] <Dark_Shikari> Actually, that should be %ifdef m8
[18:17:35] <Dark_Shikari> since it shouldn't apply for mmx.
[18:17:50] <Dark_Shikari> pb_80 chosen because it's used more than once.
[18:18:34] <Dark_Shikari> SPLATB_REG -- make an ssse3 version of the function
[18:18:40] <Dark_Shikari> where SPLATB does pshufb reg, ZERO
[18:18:47] <Dark_Shikari> And no other change.
[18:18:56] <Dark_Shikari> i.e. everything else is still sse2.
[18:19:04] <BBB> hm... ok
[18:19:38] <Dark_Shikari> where is WRITE_4x2D defined?
[18:19:40] <Dark_Shikari> it isn't in your patch.
[18:19:52] <BBB> it's already there, up just before the simple loopfilter
[18:20:28] <Dark_Shikari> btw, feel free to optimize my WHT code since as Yuvi said, it'd be better to avoid pextrw on old cpus.
[18:20:30] <BBB> it does movd [..], reg; punpckhdq reg, reg; movd[..], reg
[18:20:50] <BBB> ok, I'll look at that (after loopfilter)
[18:20:51] <Dark_Shikari> Where is your simple loopfilter?
[18:20:53] <Dark_Shikari> it isn't in vp8dsp.
[18:21:03] <BBB> should be
[18:21:13] <Dark_Shikari> I just did an svn up
[18:21:16] <BBB> %macro SIMPLE_LOOPFILTER 3
[18:21:21] <BBB> there
[18:21:50] <Dark_Shikari> No it isn't there
[18:21:54] <Dark_Shikari> I'm at r24213.
[18:22:13] <Dark_Shikari> oh ignore me.  fuck my two local versions.
[18:22:24] <Dark_Shikari> ok, found.
[18:22:55] <Dark_Shikari> would it be feasible to make macros for the load-transpose and such in this loopfilter, too?
[18:23:14] <DonDiego> BBB: libavcodec/wmavoice.c:1906: warning: format ‘%lu’ expects type ‘long unsigned int’, but argument 5 has type ‘unsigned int’
[18:23:21] <DonDiego> BBB: x86_32 only?
[18:23:25] <BBB> maybe... I think they are reused for mbedge, so I probably should
[18:24:12] <BBB> DonDiego: my stupid compiler makes sizeof() long
[18:24:24] <BBB> DonDiego: maybe %z?
[18:24:59] <Dark_Shikari> BBB: two things to note:
[18:25:12] <BBB> DonDiego: try making it %zu
[18:25:16] <CIA-99> ffmpeg: alexc * r24214 /trunk/libavcodec/aacdec.c:
[18:25:16] <CIA-99> ffmpeg: aacdec: Remove the warning about non-meaningful window transitions.
[18:25:17] <CIA-99> ffmpeg: It created false positives on seeks and where the first frame is STOP or SHORT.
[18:25:17] <CIA-99> ffmpeg: It failed to warn in illegal SHORT->LONG transitions. In general it created
[18:25:17] <CIA-99> ffmpeg: much confusion and many junk bug reports from the users.
[18:25:21] <Dark_Shikari> 1) as a general note, mmx functions will often never be used on x86_64 because sse2 is faster on all cpus, and all x86_64 cpus have sse2.
[18:25:34] <Dark_Shikari> as you'll note, in x264, some mmx functions are just ifdeffed away on x86_64.
[18:25:44] <Dark_Shikari> now, second fact which may be useful
[18:26:01] <Dark_Shikari> 2) on x86_64, don't use the stack, just use more mm registers
[18:26:02] <DonDiego> BBB: better ask one of the c wizards
[18:26:04] <Dark_Shikari> for sse2
[18:26:08] <Dark_Shikari> (for backing stuff up)
[18:26:13] * DonDiego looks sideways at mru
[18:26:19] <Dark_Shikari> so %define the locations in the stack or whatever
[18:26:32] <BBB> ah, and on arch_64, use the reg instead of the stack
[18:26:41] <BBB> that's a good idea
[18:26:58] <Dark_Shikari> note a) this only works for sse2
[18:27:07] <Dark_Shikari> b) if you wanted you could just not compile the mmx code on x86_64
[18:27:11] <Dark_Shikari> if that made things any easier.
[18:27:18] * Dark_Shikari reads the actual code
[18:27:21] <BBB> ok, I'll look at that
[18:27:27] <Dark_Shikari> "flim"... is this a word?
[18:27:29] <Dark_Shikari> or a byte?
[18:27:36] <Dark_Shikari> oh, I was looking at the simple one
[18:27:51] <Dark_Shikari> can you use SPLATB on lines 1215-1226 in the simple one?
[18:27:54] <Dark_Shikari> "splat register with flim"
[18:28:03] <Dark_Shikari> oh, you already did.
[18:28:28] <BBB> I'd probably apply that separately, but yes
[18:31:15] <Dark_Shikari> besides that, can't see anything else.  your patch is officially cool.
[18:32:00] <BBB> \o/
[18:32:07] <Dark_Shikari> hah, found a suboptimality
[18:32:10] <Dark_Shikari> +    mova             m7, [rsp+mmsize*3]
[18:32:11] <Dark_Shikari> +    pandn            m7, m6
[18:32:15] <Dark_Shikari> m6 is then never used again.
[18:32:27] <Dark_Shikari> why not swap the two and do pandn m6, [rsp+mmsize*3] ?
[18:32:37] <BBB> that's not the same
[18:32:40] <BBB> it's not pand, it's pandn
[18:32:54] <Dark_Shikari> pandn does.... pand with not SOMETHING?
[18:33:06] <BBB> pandn x, y does ~x & y
[18:33:16] <_skal_> so tricky
[18:33:17] <Dark_Shikari> ok
[18:33:33] <BBB> ~x & y !=  x & ~y
[18:33:46] <Dark_Shikari> lines 380-382 of your patch have a lot of linear dependency.  is there no way to avoid that¿
[18:33:58] <Dark_Shikari> how about this, would this be the same?
[18:34:01] <Dark_Shikari> paddsb m7, m1
[18:34:04] <Dark_Shikari> paddsb m1, m1
[18:34:09] <Dark_Shikari> paddsb m7, m1
[18:34:25] <_skal_> nope
[18:34:31] <Dark_Shikari> why not?
[18:34:35] <_skal_> saturation isn't the same
[18:34:37] <Dark_Shikari> why not?
[18:34:43] <Dark_Shikari> I chose the order specifically so that it was
[18:34:51] <Dark_Shikari> if m1 saturates, m7 will saturate
[18:35:18] <Dark_Shikari> I think.
[18:35:22] <BBB> if m7 is -128, adding 127
[18:35:29] <BBB> add 127 -> -1, add 127 -> 126
[18:35:31] <_skal_> think m7=-1, m1 = 64
[18:35:34] <BBB> adding 3x 127 -> 127
[18:35:50] <CIA-99> ffmpeg: diego * r24215 /trunk/Doxyfile: Turn off the useless default chatter that doxygen prints to the console.
[18:35:56] <Dark_Shikari> how about abusing the fact that is4tap is only 0 and 1 then?
[18:36:01] <Dark_Shikari> oh
[18:36:01] <Dark_Shikari> I see
[18:36:07] <Dark_Shikari> is4tap is p1-q1
[18:36:42] <Dark_Shikari> I fail to see how the current one even saturates correctly.
[18:36:51] <Dark_Shikari> suppose p1-q1 is B and q0 - p0 is A
[18:36:54] <Dark_Shikari> i.e. 3*A + B
[18:37:05] <Dark_Shikari> we are doing
[18:37:07] <Dark_Shikari> B += A
[18:37:09] <Dark_Shikari> B += A
[18:37:11] <Dark_Shikari> B += A
[18:37:12] <CIA-99> ffmpeg: diego * r24216 /trunk/Doxyfile:
[18:37:12] <CIA-99> ffmpeg: Do not generate LaTeX Doxygen documentation by default.
[18:37:12] <CIA-99> ffmpeg: Our general use case just requires HTML documentation, so skip the extra step.
[18:37:41] <Dark_Shikari> hmm.  maybe it works.
[18:37:46] <BBB> B is saturated by itself in the spec also
[18:37:54] <BBB> so it's clip(3*a+clip(b))
[18:38:07] <Dark_Shikari> that's silly.
[18:38:27] <BBB> yeah, but convenient
[18:38:40] <BBB> you can see how the spec was built around simd, rather than the other way around ;)
[18:38:46] <Dark_Shikari> not convenient
[18:38:53] <BBB> the mbedge is worse
[18:38:53] <Dark_Shikari> convenient would be if the saturation was in the middle.
[18:39:09] <Dark_Shikari> thus not requiring a 5-cycle-long dependency chain
[18:39:28] <Dark_Shikari> make that 8 cycles
[18:39:59] <BBB> true
[18:40:52] <_skal_> you could intersperse the mova m5, [pb_f8] in middle i guess
[18:41:09] <Dark_Shikari> not really useful
[18:41:12] <Dark_Shikari> the cpu already does speculative loads
[18:41:58] <Dark_Shikari> _skal_: oh yeah, one thing I was going to bug you about since you're the youtube google guy
[18:42:02] <Dark_Shikari> http://www.youtube.com/watch?v=4vlVudQSj90
[18:42:08] <Dark_Shikari> a guy uploaded a 1080p screen capture and youtube somehow totally broke the scaling
[18:42:18] <Dark_Shikari> it seems a bit odd, so I figured I might as well poke you about it.
[18:42:54] <Dark_Shikari> BBB: why psrlq for lines 408-409?
[18:42:59] <Dark_Shikari> for sse, shouldn't it be psrldq?
[18:43:00] <Dark_Shikari> or what
[18:43:49] <_skal_> "This video has been removed by the user. "
[18:43:54] <_skal_> damned, *so* bad? :)
[18:44:01] <Dark_Shikari> _skal_: blegh, he removed it?
[18:44:04] <Dark_Shikari> does youtube keep backups? =p
[18:44:21] <Yuvi> google delete data?
[18:44:23] <Dark_Shikari> the scaling looked like someone had done a point resize down to ~720p
[18:44:23] <Yuvi> never!
[18:44:26] <Dark_Shikari> and then point resized back up
[18:44:30] <Dark_Shikari> But the source video was fine
[18:46:03] <Dark_Shikari> BBB: fyi, psrldq is slower than psrlq on some chips, so don't use it if you can avoid it, I'd just like to know why you can use psrlq
[18:48:47] <_skal_> btw i played with the idea of keeping pb_80 as sole constant, in a reg this week-end
[18:48:55] <_skal_> http://pastebin.com/MZ4NAcBn
[18:49:00] <_skal_> not sure how it helps, but hey
[18:49:10] <_skal_> in case.
[18:50:55] <Dark_Shikari> 32-bit isn't that important
[18:52:57] <CIA-99> ffmpeg: alexc * r24217 /trunk/ (9 files in 3 dirs):
[18:52:57] <CIA-99> ffmpeg: Split the ADTS header decoder off of the ADTS parser.
[18:52:57] <CIA-99> ffmpeg: The AAC decoder and ADTS-to-ASC BSF both require the header decoder
[18:52:57] <CIA-99> ffmpeg: but not full parsing capabilities.
[18:54:09] <Dark_Shikari> btw, BBB, I guess it's obvious, but just to put it on the table, the mmx chroma one shouldn't do anything special (since, well, duh)
[18:55:06] <Dark_Shikari> should just loop over the channels
[18:55:23] <mru> DonDiego: you looked my way...
[18:57:23] * kshishkov would like glance detector working over hundreds of kilometers too
[19:05:55] <BBB> Dark_Shikari: I can use either
[19:06:17] <BBB> Dark_Shikari: I cleared the least-significant bit, so psrlw x, 1, psrld, psrlq, psrldq all do the same thing
[19:06:24] <Dark_Shikari> ok
[19:06:30] <BBB> psrlq is just random
[19:06:34] <BBB> I could've chosen psrlw also
[19:06:42] <BBB> not sure why I chose psrlq
[19:08:03] <BBB> and for the chroma one, I'll use the same code, but I need to change the C prototype first
[19:14:53] <DonDiego> mru: i thought you might be able to suggest the right printf length specifier for a 'sizeof(float)' operation
[19:15:31] <DonDiego> r
[19:16:59] <mru> z of course
[19:17:12] <mru> it is specifically for size_t arguments
[19:17:22] <Vitor1001> DonDiego: cast it to an int, it will fit ;)
[19:17:27] <mru> and type type of a sizeof expression is size_t
[19:18:42] <BBB> DonDiego: change to %zu is fine with me, feel free to apply
[19:37:27] <CIA-99> ffmpeg: diego * r24218 /trunk/libavcodec/wmavoice.c:
[19:37:27] <CIA-99> ffmpeg: Use correct length modifier for size comparison in printf expression, fixes:
[19:37:27] <CIA-99> ffmpeg: libavcodec/wmavoice.c:1906: warning: format `%lu' expects type `long unsigned int', but argument 5 has type `unsigned int'
[19:37:27] <CIA-99> ffmpeg: approved by Ronald and Mans on IRC
[19:46:23] <Honoome> mru: won't that depend on whether you enable -std=mingwbrokenstd? :P
[19:46:57] <mru> :-)
[19:47:28] <mru> the z modifier is c99 though
[19:48:06] <Honoome> I _really_ wonder how that guy wrote the autotools book o_O
[19:48:22] <mru> explains a thing or two about autotools
[19:48:31] <mru> or about the guy
[19:48:33] <mru> not sure which
[19:50:35] * Honoome sighs, as he's not a native speaker
[19:55:08] <CIA-99> ffmpeg: mru * r24219 /trunk/libavcodec/avfft.c: avfft: make init functions return NULL on failure as intended
[20:17:56] <kierank> is there any way to get gdb to break when a register equals a certain value
[20:18:10] <mru> not efficiently
[20:18:20] <mru> since the cpu doesn't have a trap for that
[20:18:38] <kierank> what's the inefficient way?
[20:18:46] <mru> single-step and test
[20:18:54] <mru> which can be automated
[20:19:01] <mru> but is a few million times slower
[20:25:12] <CIA-99> ffmpeg: mru * r24220 /trunk/tests/ (4 files in 2 dirs):
[20:25:13] <CIA-99> ffmpeg: fate: add vp8 bilinear tests
[20:25:13] <CIA-99> ffmpeg: Mike added these some time ago, and I forgot to update here.
[20:27:53] <hyc> the gdb watch command will do it for you. and yes, millions of times slower.
[20:30:09] <jb_vacation> Compn: I am away these days, sorry...
[20:30:46] <Honoome> jb_vacation: not in venice again, I suppose?
[20:36:24] <jb_vacation> Honoome: south of France
[20:36:31] <Honoome> kk :)
[20:37:02] <mru> africa?
[20:37:06] <jb_vacation> I wouldn't do the same mistake twice ;)
[20:37:19] <mru> africa is south of france
[20:38:59] <Honoome> :P
[21:03:43] <CIA-99> ffmpeg: vitor * r24221 /trunk/tests/fate2.mak: Add TrueSpeech regtest
[21:18:00] <CIA-99> ffmpeg: mru * r24222 /trunk/configure:
[21:18:00] <CIA-99> ffmpeg: configure: match regtest ref files more strictly
[21:18:00] <CIA-99> ffmpeg: Only names consisting of letters, numbers, hyphens, and underscores
[21:18:00] <CIA-99> ffmpeg: are allowed.
[21:23:57] <CIA-99> ffmpeg: cehoyos * r24223 /trunk/libavcodec/ (libvpxenc.c options.c):
[21:23:57] <CIA-99> ffmpeg: Do not map video quantizer scale (from 1-51 to 0-63) for libvpx anymore.
[21:23:57] <CIA-99> ffmpeg: Patch by James Zern, jzern google
[21:36:37] <CIA-99> ffmpeg: alexc * r24224 /trunk/libavcodec/aacdec.c: aacdec: Use a LUT to generate CCE scale.
[21:36:38] <CIA-99> ffmpeg: alexc * r24225 /trunk/libavcodec/aacdec.c: aacdec: Eliminate the use of doubles in decode_cce().
[21:37:12] <CIA-99> ffmpeg: alexc * r24226 /trunk/libavcodec/aacdec.c: aacdec: Eliminate the use of doubles in the MAIN predictor.
[22:07:18] <kierank> will audio decoders start using avframe eventually?
[22:21:05] <BBB> yes
[22:32:44] <bcoudurier> hi g uys
[22:39:43] <Honoome> what if there were kde devs in here?
[22:40:10] <kierank> mru would banish them because they'd talk about c++ a lot
[22:40:11] <_skal_> 'lut Baptiste
[22:40:16] <Honoome> kierank: rotfl
[22:40:30] <kierank> the one i met a few years ago did
[22:41:08] <Honoome> kierank: but me and mru always talk about C++... laughing at its users
[22:41:14] <hyc> C >> C++
[22:42:43] <kierank> hehe for some random reason I always thought librtmp was c++
[22:48:41] <bcoudurier> hey _skal_
[22:48:52] <bcoudurier> content de te voir ici :)
[22:55:40] <BBB> oh boy, they talk french
[22:55:48] <BBB> mais non!
[22:58:18] <astrange> where's the master logo image?
[23:15:22] <peloverde> astrange: svn://svn.ffmpeg.org/ffmpeg.org trunk/src/ffmpeg-logo.svg
[23:29:16] <Compn> _skal_ : btw did google/youtube ever give up their non-working-in-ffmpeg samples ?
[23:29:50] <Compn> _skal_ : i've mailed one google guy but he cant get thru to youtube or something
[23:30:14] <Compn> _skal_ : if you know any contacts or are still working there could you get official response ? :)
[23:31:34] <kierank> they probably have hundreds of thousands of non-working samples
[23:33:08] <Compn> goody
[23:33:22] <Dark_Shikari> which they have repeatedly refused to give out
[23:33:30] <Dark_Shikari> because it would require them to publicly admit they use ffmpeg.
[23:33:58] <Compn> _skal_ : also unnofficially, get one of them ffmpeg devs to submit a bunch of patches anonymously
[23:34:01] <Compn> :)
[23:34:04] <Compn> just to piss Dark_Shikari off
[23:34:09] <Compn> i'm sure they got x264 patches too
[23:34:49] <kierank> iirc their x264 has a poc which increments in a weird way
[23:35:22] <kierank> can't remember what it does though
[23:36:29] <Compn> Dark_Shikari : so mr knows everything bout youtube/google, hows the webm patent pool going so far ?
[23:37:19] <Dark_Shikari> they won't tell anyone
[23:37:27] <Dark_Shikari> ask google
[23:37:29] <Dark_Shikari> maybe they'll tell you
[23:37:31] <bcoudurier> lol
[23:37:38] <kierank> ask mpeg-la
[23:37:48] <Compn> yeah i meant 3rd party seeking money like mpeg-la
[23:39:10] * Compn thinks up other things to troll Dark_Shikari with
[23:54:00] <_skal_> That's a lot of questions, and it's not like Dark needs answers to quote Google in his announcements
[23:54:05] <_skal_> so.