[FFmpeg-devel-irc] IRC log for 2010-09-11

[irc at mansr.com]

[01:25:08] <astrange> bleh, yasm doesn't support dwarf2 on macho and doesn't use it for much on elf
[03:00:05] <BBB> astrange: it (somehow) does insert debug symbols for me (macho64)... is that something else?
[03:01:13] <astrange> symbol names but not line numbers
[03:01:18] <astrange> it supports that on linux
[03:03:04] <BBB> hm, indeed
[03:03:24] <BBB> I guess I never noticed since the line is pretty obvious from the asm statement :-p
[03:03:39] * BBB doesn't feel like contributing to a tool that should_just_work[tm]
[03:04:14] <BBB> otherwise we'll get into that recursive thing where I wanted to write a video editor but all media platforms sucked so I went into .. [and so on]
[03:16:03] <peloverde> We should troll google into fixing yasm
[08:08:27] <mru> morning
[08:08:54] <_av500_> gm
[08:10:41] <spaam> god morgon mru :)
[08:30:58] <funman> moroning
[08:58:17] * mru curses glibc
[09:00:14] * funman gives a nail and some ulrich drepper's hairs to mru
[09:33:09] <CIA-63> ffmpeg: mru * r25103 /trunk/libavcodec/tta.c: tta: remove stray semicolon
[10:24:54] <CIA-63> ffmpeg: mstorsjo * r25104 /trunk/tests/ (ref/fate/g722dec-1 fate2.mak): Add a FATE test for the G.722 decoder
[13:26:39] <kshishkov> wbs: http://shishkov.homeunix.net/wbs.jpg
[14:02:28] <KotH> anyone here ever had the prob that hdd A (1TB) somehow got teh content of hdd B (2TB) after a reboot?
[14:02:45] <KotH> and yes, both fs are fine, according to fsck
[14:02:53] <mru> you mean the device names got swapped?
[14:03:13] <KotH> nope, the content got somehow dublicated
[14:03:29] <mru> something managed to fit 2TB on a 1TB disk?
[14:03:31] <KotH> i suspected the same first, but putting the hdd into another pc showed a different picture
[14:03:50] <kshishkov> silly RAID mode?
[14:03:55] <mru> the contents were copied?
[14:04:01] <KotH> df reports different amounts of diskusage, but ls reports the same files
[14:04:02] <mru> not just reading wrong disk?
[14:04:15] <KotH> yes, i am not reading the wrong disk
[14:04:24] <mru> I meant kernel reading wrong disk somehow
[14:04:40] <KotH> i put it into another pc
[14:04:42] <KotH> same result
[14:04:56] * KotH is clueless how that could have happend
[14:04:59] <mru> you must have done something to make that happen
[14:05:07] <KotH> but what?
[14:05:21] <mru> are the raw contents of the disks identical?
[14:05:26] <mru> or did just the files get copied?
[14:05:51] <KotH> still checking
[14:06:13] <mru> whichever the case, you must have mistyped some command or something
[14:06:22] <mru> nothing would do that on its own
[14:06:25] <KotH> what is strange, according to my logs, the contens of both disks were as expected this morning at 06:35 (CEST)
[14:07:04] <mru> maybe that girl you brought home last night wasn't quite what she seemed
[14:07:30] <KotH> the only thing that has happend today is 1) i unplugged all disks, 2) plugged them back in 3) run fsck over most disks (had not rebooted for quite a while)
[14:07:43] <mru> you still run fsck?
[14:07:51] <mru> what crackpot filesystem do you use?
[14:07:59] <KotH> ext3 :)
[14:08:23] <mru> why so primitive?
[14:08:31] * KotH doesnt trust ext4
[14:08:36] * mru neither
[14:08:41] <mru> so I use xfs
[14:08:45] <mru> works like a charm
[14:08:58] * KotH doesnt trust filesystems that he doesnt understand and cannot fix by hand if necessary
[14:09:05] <kshishkov> why not zfs? works like Sun
[14:09:15] <KotH> s/sun/oracle/
[14:09:30] * KotH wonders if fsck messed up
[14:09:44] <mru> fsck should never copy files from one disk to another
[14:10:09] <mru> so your disks were fscked up, eh?
[14:10:15] <KotH> ^^'
[14:15:41] <spaam> KotH: so you are using fat32?
[14:17:46] * kshishkov once had file gaining unknown attribute on ext3 so it could be read only with filesystem remounted as ext2
[14:19:17] <KotH> this is fucking insane...
[14:19:37] <kshishkov> so what?
[14:19:42] <KotH> next thing pigs will be flying in my room
[14:20:13] <kshishkov> you should live a month or so in Turkey to gain more strength against insanity
[14:20:26] * kshishkov won't object flying pigs
[14:21:49] * KotH goes to get some chocolate cake
[14:23:32] <kshishkov> Schwarzwald one?
[14:23:38] <cartman> mru: any idea why g722 test failed?
[14:24:04] <cartman> /Users/cartman/Sources/fate-test/fate-suite/g722/conf-adminmenu-162.g722: No such file or directory
[14:24:11] <cartman> uh
[14:24:13] <cartman> nm
[14:24:14] <cartman> me stupid
[14:24:24] <KotH> kshishkov: sprüngli trüfftorte
[14:25:05] <kshishkov> KotH: sounds more truffly than chocolatey
[14:30:47] <CIA-63> ffmpeg: mstorsjo * r25104 /trunk/tests/ (ref/fate/g722dec-1 fate2.mak): Add a FATE test for the G.722 decoder
[14:38:06] <CIA-63> libswscale: ramiro * r32155 /trunk/libswscale/rgb2rgb_template.c: rgb2rgb: remove unused yvu9toyv12 function
[14:38:07] <CIA-63> libswscale: ramiro * r32156 /trunk/libswscale/swscale.c:
[14:38:07] <CIA-63> libswscale: swscale: remove unused code
[14:38:07] <CIA-63> libswscale: yvu9ToYv12Wrapper() used to support yv12 with the chroma planes either in the
[14:38:07] <CIA-63> libswscale: uv order or the vu order. FFmpeg no longer has a pixel format in vu order.
[14:38:09] <CIA-63> libswscale: ramiro * r32157 /trunk/libswscale/swscale.c: indent
[14:54:56] <cartman> there goes the green light
[14:55:39] <kshishkov> looks like SheevaPlug is resting
[15:26:37] <mru> kshishkov: yes, it is
[15:27:25] <kshishkov> maybe it\s just new tech - self-bricking device
[15:28:24] <mru> no, I know what's wrong
[15:28:37] <kshishkov> chipset, PSU and idea?
[15:28:39] <mru> but I can't reset it from .de
[15:28:53] <janneg> kshishkov: good for the manufacturer. I'll bet you could sell quite a few licenses if you patent it now
[15:29:24] <janneg> unless marvell has already a patent
[15:29:38] <kshishkov> mru: why don't you have special networked device for interrupting power on all other devices?
[15:29:51] <mru> janneg: maxtor did that with hard drives
[15:30:00] <kshishkov> janneg: probably a lot of companies have it now
[15:30:01] <mru> kshishkov: that would be convenient
[15:30:09] <mru> but I don't have one of those
[15:30:27] <kshishkov> mru: Fujitsu MPG were also very good hard-drives, aka "will live only till the end of warranty"
[15:30:36] <kshishkov> uhm, solder one
[15:31:07] <mru> :effort:
[15:31:41] <kshishkov> mru: still it should be fun
[15:31:58] <mru> not really
[15:49:36] <janneg> mru: if you have a reliable machine with usb http://www.amazon.de/6-fach-Steckdose-Silvershield-programmierbar-%C3%9Cberspannungsschutz/dp/B0010NY8YA/ is an affordable solution
[15:54:05] <janneg> the control application is even in portage. sys-power/sispmctl
[15:58:26] <mru> janneg: I'd need more than 6-way
[15:58:34] <mru> to cover everything
[15:59:07] <mru> but price is reasonable
[15:59:23] <mru> I should get something like that
[16:00:19] <janneg> buy more than one or live with switching some devices in groups
[16:03:01] <kshishkov> it's unlikely you need to control much more devices often enough
[16:30:17] <CIA-63> ffmpeg: cehoyos * r25105 /trunk/libavformat/ (id3v2.c avformat.h):
[16:30:17] <CIA-63> ffmpeg: Read all id3v2 tags at the beginning of mp3 files.
[16:30:17] <CIA-63> ffmpeg: Patch by David Byron, dbyron dbyron com
[16:45:10] <CIA-63> ffmpeg: stefano * r25106 /trunk/libavdevice/v4l2.c: Cosmetics: apply minor style fixes.
[17:02:05] <wbs> kshishkov: oh, nice :-)
[17:06:20] <mru> wbs: http://farm4.static.flickr.com/3506/4065707084_0d522ee198_o.jpg
[17:06:35] <wbs> haha :-)
[17:07:28] <mru> so you recognise it
[17:07:38] <wbs> yes, it's my evil twin brother ;P
[17:08:50] <kshishkov> too bad those two relate to different Storsjö, making it all wbs' cousin at most
[17:10:05] <mru> nitpicking
[17:10:24] <kshishkov> mru: yes, a must for good FFmpeg dev
[17:11:27] <mru> but his brother isn't an ffmpeg dev
[17:12:16] <kshishkov> neither is yours and I'm just lucky not to have a brother
[17:13:14] <mru> they're not that bad
[17:13:19] <mru> sisters are much more trouble
[17:13:54] <kshishkov> MPFC says "Beware of llama!"
[17:14:59] <kshishkov> still, the most horrible thing is grannies
[17:17:51] * mru has no grannies
[17:17:54] <mru> anymore
[17:19:18] <Compn> ffmpeg cant streamcopy rm very well :P
[17:19:34] <mru> can it copy _anything_?
[17:19:46] <Compn> it can copy it into an unplayable file
[17:19:48] <kshishkov> rawvideo
[17:20:20] <kshishkov> Compn: lavc RM muxer is not very good (as well as known RM spec)
[17:20:22] <Compn> no one cares about rm muxing :)
[17:20:42] <mru> someone should fix the demuxer
[17:20:49] <mru> pts are fucked
[17:21:06] <Compn> yeah ran across that non monotone pts too
[17:21:44] <Compn> mru : going to make some roundup issues for it ?
[17:21:45] <Compn> hehe
[17:21:55] * Compn passes the buck
[17:22:13] <kshishkov> mru: both me and BBB are disresponsible for RM demuxing
[17:24:00] <cartman> wut*
[17:24:05] <cartman> I mean hello!
[19:57:53] <CIA-63> ffmpeg: jbr * r25107 /trunk/ (libavcodec/g726.c tests/ref/acodec/g726): Set a constant frame size for encoding G.726 audio.
[20:05:49] <merbanan> umm, how much is left to create a complete sip stack now ?
[20:06:28] <merbanan> with g723.1 we should be able to communicate with almost everything
[20:14:00] <j0sh> merbanan: the sip protocol implementation itself :)
[20:14:43] <j0sh> i suppose to start off we could patch in support for a sip stack like sofia until we have a native implementation
[20:16:34] <KotH> a sip stack in ffmpeg?
[20:16:42] <KotH> you're sure you want something that evil?
[20:17:16] <mru> maybe we could have just one sip, not a whole stack of them
[20:17:29] <wbs> don't think it fits straight into the current design and interfaces, but you might be able to design one reusing a lot of code from lavf/lavc
[20:19:12] <elenril> KotH: what's evil about it?
[20:20:24] <j0sh> better than H.323, imo
[20:20:46] <j0sh> reading h323 call flows makes me want to dig my eyes out
[21:06:12] <astrange> ffplay -vf hflip something.h264 crashes immediately :/
[21:06:15] <astrange> er, vflip
[21:06:43] <mru> libavfi is full of bugs
[21:07:17] <astrange> i think h264 just can't handle its output picture having negative stride
[21:07:44] <mru> that would be a bug
[21:07:47] <mru> find and fix
[21:10:41] <Dark_Shikari> a lot of x264's asm assumes positive stride (on 64-bit, iirc)
[21:10:52] <Dark_Shikari> "int stride"
[21:11:23] <astrange> divx too
[21:11:37] <Dark_Shikari> IMO it would be better just to do a memcpy for vflip
[21:11:48] <Dark_Shikari> there's a lot of premature optimization going on in libavfilter
[21:11:57] <Dark_Shikari> it would be _better_ to avoid it, but speed is rarely that critical, and it breaks other things in the meantime
[21:12:32] <Dark_Shikari> astrange: on 64-bit?
[21:13:19] <astrange> yes, in pred8x8_128_dc_c and ff_put_pixels_clamped_mmx respectively
[21:13:38] <Dark_Shikari> o.0 it crashes in a C function?
[21:14:46] <Dark_Shikari> oh fuck, another one of those functions that doesn't use aliasing-avoidance macros.
[21:14:55] <pengvado> why would '-vf vflip' affect the stride of images allocated by the decoder?
[21:15:54] <astrange> direct rendering
[21:17:45] <pengvado> is that kind of direct rendering useful?
[22:09:34] <Compn> aww
[22:09:44] <Compn> nm
[22:09:52] <Compn> did you guys already talk about stefano's mail ?
[22:10:58] <wbs> j-b: hey.. would it be possible to add a proper update mode to the vlc installer for windows, instead of having to uninstall and do a full reinstall? :-)
[22:11:32] <j-b> wbs: if we had time, yes
[22:11:49] <j-b> wbs: the problem would be to manage all binary diffs from all versions
[22:12:28] <kierank> I think he just means an installer that can overwrite the current vlc installation
[22:12:34] <wbs> yeah
[22:12:36] <kierank> instead of uninstall and reinstall
[22:12:41] <j-b> but, even now, it could done more automatically... I'll do something when I'll move to .msi
[22:12:51] <wbs> so one doesn't have to re-setup the file type associations etc
[22:12:57] <j-b> kierank: I'll think about something this week then
[22:13:00] <kierank> hehe msi, have fun with that j-b
[22:17:20] <j-b> kierank: missing some good Open Source solution for it
[22:18:15] <wbs> what does it use at the moment? nsis?
[22:19:20] <kierank> j-b: except you'll tear your hair out trying to get msi to work
[22:19:24] <kierank> ;)
[22:26:38] <j-b> wbs: unfortunately yes.
[22:26:51] <j-b> kierank: btw, I went to IBC and I might have good news
[22:27:47] <kierank> it already started?
[22:28:06] <kierank> hmm apparently it has