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

[irc at mansr.com]

[03:41:00] <CIA-63> ffmpeg: cehoyos * r25158 /trunk/libavformat/asfdec.c:
[03:41:00] <CIA-63> ffmpeg: Fix aspect ratio for files that have it stored in
[03:41:00] <CIA-63> ffmpeg: ff_asf_extended_content_header.
[03:41:00] <CIA-63> ffmpeg: Patch by Richard Buteau, rbuteau rgbnetworks com
[07:12:09] <lu_zero> good morning
[07:12:21] <kshishkov> buon giorno
[07:12:42] <lu_zero> god morgon kshishkov =)
[07:13:40] <kshishkov> det är riktig #ffmpeg-devel-se nu :)
[07:15:08] <spaam> Det är bra :)
[07:15:19] <kshishkov> javisst
[07:16:43] <andoma> hej alla :)
[07:16:49] <kshishkov> hejsan
[07:17:29] <wbs> gäsp
[07:18:44] <lu_zero> det -> this| är -> is is| riktig -> right? | nu -> now?
[07:19:47] <kshishkov> lu_zero: precis
[07:20:53] * lu_zero will master swedish misreading soon
[07:22:34] <spaam> ändra alla kommentarer i koden till svenska? :)
[07:23:53] <lu_zero> Kotändra -> ???
[07:24:03] <_av500_> gm
[07:24:06] <lu_zero> alla -> all?
[07:24:29] <lu_zero> kommentarer -> comments, koden -> code
[07:24:44] <wbs> lu_zero: du är ganska bra på det här :-)
[07:24:50] <lu_zero> till and i I couldn't guess
[07:25:02] <wbs> till -> to, i -> in
[07:25:10] <wbs> ändra -> change
[07:25:15] <lu_zero> ah
[07:25:33] <lu_zero> ändra isn't a same-form
[07:25:33] <spaam> change all the comments in the code to swedish :)
[07:26:02] <wbs> yeah, I guess it's the only word in that sentence that isn't directly related to the english counterpart :-)
[07:26:04] <lu_zero> spaam: I'll add some naive japanese just to make non utf-8 readers scream
[07:26:38] <spaam> lu_zero: sounds good : )
[07:26:47] <kshishkov> det passar bra
[07:27:56] <lu_zero> uhm
[07:28:11] <lu_zero> what bra means?
[07:28:21] <kshishkov> good
[07:28:32] <thresh> yes, bras are good
[07:28:36] <mru> mornings
[07:28:50] <mru> thresh: removing them is better
[07:29:12] <thresh> indeed
[07:29:14] <lu_zero> mru: depends on the situation
[07:29:28] <kshishkov> thresh: you may find other Swedish words for "good" amusing too
[07:29:34] <mru> lu_zero: situation is her bedroom
[07:30:09] <lu_zero> mru: ah, not hanging on a cliff, clinging on a bra
[07:30:33] <lu_zero> (no, never happened)
[07:34:11] <lu_zero> disturbing email of the day
[07:34:15] <lu_zero> http://i.somethingawful.com/u/elpintogrande/september10/wtfcontest/katie_beholder_big.jpg
[07:34:34] <lu_zero> (that's as a post scriptum of a mostly serious email)
[07:35:28] <kshishkov> is that the only thing making that mail _mostly_ serious?
[07:40:51] * _av500_ does not want to meet lu_zero pen friends
[07:41:20] <lu_zero> the email was about 3d printers, daily planning and stuff
[07:41:22] <lu_zero> and then
[07:41:31] <lu_zero> PS: [link]
[07:43:57] <_av500_> lu_zero: now, if only i could ..... https://code.google.com/p/chromium/issues/detail?id=1019
[07:45:47] <spaam> _av500_: fix that feature to ffmpeg also..
[07:45:56] <_av500_> right
[07:46:01] <_av500_> -o wallpaper
[07:46:08] <lu_zero> ...
[07:46:11] <lu_zero> please...
[07:46:11] <spaam> yeah
[07:46:17] <_av500_> --set-as-wallpaper
[07:46:20] <lu_zero> is that serious?
[07:46:34] <_av500_> lu_zero: ?
[07:46:35] <mru> looks like a troll thread to me
[07:46:38] <lu_zero> the bug
[07:46:45] <_av500_> they mark it as wontfix
[07:46:52] <lu_zero> I just noticed that firefox has it
[07:46:59] <_av500_> saying pl can save and then right click in explorer
[07:47:02] <mru> _av500_: -o x11:root
[07:47:08] <mru> we have -i x11:
[07:47:17] <_av500_> mru: yeah, works a charm in windows :)
[07:47:30] <_av500_> -o GDI:
[07:47:30] <mru> works in my windows
[07:47:37] <mru> my windows are all x
[07:47:51] <_av500_> -EIKNOW
[07:48:11] <_av500_> and like me, you never get to see the wallpaper anyway...
[07:48:16] * mru wants EIEIO as an error code
[07:48:28] <_av500_> -ETLDR
[07:48:37] <kshishkov> mru: what's it use outside farms?
[07:48:37] <_av500_> for bloat APIs
[07:49:11] <mru> eieio is my favourite ppc instruction
[07:49:34] <lu_zero> mru: no wayland for you yet?
[07:49:41] <lu_zero> mru: why?
[07:49:55] <mru> wayland?
[07:50:11] <lu_zero> mru: a bare to nothing server using egl
[07:50:28] <mru> X11 is fine
[07:50:31] <lu_zero> http://cgit.freedesktop.org/~krh/wayland/
[07:50:35] <kshishkov> mru: I thought it was alias for "register move"
[07:50:36] <mru> fdo, yuck
[07:50:37] <lu_zero> it's X11, mostly
[07:51:24] * thresh will comment on that chromium bug
[07:51:46] <_av500_> thresh: ask "what is wallpaper and how do i see it"
[07:51:50] <thresh> nah
[07:52:06] <thresh> i'll troll the developers
[07:52:13] <kshishkov> open new bug since chromium can't operate my coffee machine
[07:52:39] <_av500_> kshishkov: only features that are in FF and IE count
[07:52:43] <_av500_> like "crahs more"
[07:52:46] <_av500_> "use more mem"
[07:52:53] <kshishkov> "leaks memory"
[07:53:04] <lu_zero> _av500_: chrome can do better and leak processes
[07:53:16] * _av500_ has fond memory of leeks
[07:53:20] * _av500_ has fond memories of leeks
[07:53:33] <_av500_> inb4 mru
[07:53:51] <lu_zero> _av500_: http://www.youtube.com/watch?v=kbbA9BhCTko
[07:54:13] <mru> _av500_: I didn't know you'd been to Wales
[07:54:34] <_av500_> lu_zero: PPS?
[07:54:52] <lu_zero> leeks
[07:54:56] <_av500_> right
[07:57:20] <Tjoppen> grr.. my remuxed mpegts w subtitles doesn't work in vlc
[07:57:38] <_av500_> that fringe ipad app?
[07:57:42] <_av500_> who cares
[07:57:50] <Tjoppen> analyzing it reveals the original files has lots of padding packets for its subtitle streams, while the remuxed file does not
[08:00:31] <Tjoppen> would I be right in assuming padding is required for such sparse streams?
[08:03:43] <_av500_> thresh: :)
[08:07:13] <lu_zero> Tjoppen: try to see if that works
[08:20:33] <Tjoppen> I think I will.. just need to figure out where and what to do to the muxer
[08:21:10] <_av500_> Dark_Shikari: https://groups.google.com/a/webmproject.org/group/webm-discuss/browse_thread/thread/ce629208109d6df6?fwc=2&pli=1
[08:22:22] <Dark_Shikari> They'll just mutter "golden frames"a few times and disappear
[08:22:42] <_av500_> :)
[08:23:25] <Dark_Shikari> iirc the ratecontrol in vp8 is still per-frame, which is kind of hilariously awful
[08:23:36] <Dark_Shikari> It also plays the "let's re-encode the frame till it fits" game
[08:23:44] <Dark_Shikari> which is great when you need that frame to be done in 20ms
[08:24:13] <_av500_> still better than "generate random bitstream and see if it fits"
[08:24:49] <_av500_> which is how i would wrtie h266 encoder
[08:25:26] <mru> generate random decoders until one gives desired result
[08:25:32] <mru> replace encoder with /dev/random
[08:25:52] <_av500_> use one fixed bitstream
[08:26:06] <_av500_> and generate decoder per video
[08:26:40] <kshishkov> mru: congratulations! you've discovered genetic programming
[08:27:02] <kshishkov> _av500_: why do you need bitstream then?
[08:27:20] <_av500_> true
[08:28:05] <kshishkov> and IIUC, MPEG-4 standard was intended to be like that - generate decoder description as bitstream
[08:28:22] <_av500_> yes
[08:28:40] <_av500_> only define a VM, and let the bistream carry the decoder with it
[08:29:04] <_av500_> locats.java :)
[08:29:08] <_av500_> lolcats
[08:31:55] <kshishkov> essentially, vector formats are like that too
[08:32:07] <kshishkov> (unless XML-based)
[08:33:00] <kshishkov> though CPU that executes XML may be quite good x86 replacement
[08:33:16] <_av500_> mru: https://groups.google.com/a/webmproject.org/group/apps-devel/browse_thread/thread/e305990cf9372172#
[08:33:27] <_av500_> glad I never bought from them :)
[08:34:07] <Dark_Shikari> wtf is he on?
[08:34:10] <Dark_Shikari> push_neon?
[08:34:38] <mru> I think they're trying to save/restore neon regs once per frame or something
[08:34:42] <mru> a la michael
[08:34:48] <mru> it doesn't work
[08:35:04] <Dark_Shikari> if you require that the compiler not use them, it should work
[08:35:08] <mru> compilers sometimes use those regs
[08:35:19] <_av500_> Dark_Shikari: the fact that sasken is a "professional" codec company
[08:35:28] <mru> 54!
[08:35:29] <Dark_Shikari> also, the sig (LOL)
[08:35:32] <_av500_> yes
[08:35:54] <mru> and this is from a "senior" engineer
[08:35:55] <_av500_> its like the tata guy on ffdev
[08:36:16] <_av500_> mru: yes, sigh
[08:36:25] <_av500_> IIT graduates
[08:37:39] <cartman> wtf
[08:37:44] <cartman> my fate is on fire
[08:38:08] <mru> overheating?
[08:38:29] <cartman> http://fate.ffmpeg.org/x86_64-apple-darwin10-clang/20100923083337
[08:38:30] <cartman> w00t
[08:39:02] <cartman> dropped to 454 tests too, weird
[08:39:33] <mru> that is weird
[08:40:08] <mru> make: *** [tests/data/acodec.ref.wav] Error 1
[08:40:17] <mru> make: *** [tests/data/vsynth1.ref.yuv] Error 1
[08:40:22] <mru> explains it
[08:40:28] <cartman> mru: which is? :D
[08:40:56] <mru> all the encode/decode tests depend on those
[08:41:53] <mru> check if the machine is overheating
[08:42:11] <cartman> only asfdec.c is changed, doesn't make sense
[08:42:24] <mru> that's why I said check the hw
[08:42:54] <cartman> the machine is not hot at all
[08:44:06] <kshishkov> yes, Apple machines nowadays are not hot at all
[08:44:19] <mru> it would have cooled off by now
[08:44:27] <mru> what kind of machine is it?
[08:44:36] <cartman> mru: a macbook pro laptop
[08:44:39] <mru> lol
[08:45:01] <mru> probably inadequate cooling
[08:45:11] <mru> only intended to max out cpu in short bursts
[08:45:21] <cartman> it was working until today :P
[08:45:27] <cartman> I must have borked something
[08:48:52] <mru> did you change anything?
[08:49:56] <cartman> updated to clang trunk, thats the biggest change
[08:50:27] <mru> that could have broken stuff of course
[08:50:35] <cartman> ;>
[08:50:50] <mru> mine's on r114171
[08:51:21] <cartman> 114634 here
[08:51:26] <cartman> lots of changes :/
[08:55:26] <cartman> mru: is there way to manually run acodec.ref.wav part?
[08:55:31] <cartman> maybe the compiler crashes
[08:55:57] <mru> compiler isn't involved in that
[08:56:04] <j0sh> speaking of compiler crashes
[08:56:15] <cartman> mru: ok any manual way to see whats up?
[08:58:05] <j0sh> i may be doing something dumb, but ffmpeg sometimes seems to have trouble compiling on gcc 4.4.3/x64
[08:58:56] <j0sh> if i retry a few times it works
[08:59:01] <mru> seems stable enough for me
[08:59:01] * j0sh is highly unscientific
[08:59:23] <mru> is your hw ok?
[08:59:48] <j0sh> should be, its a vps on linode
[08:59:53] <j0sh> hmm i think i know why
[08:59:53] <mru> and how does it fail?
[09:00:02] <j0sh> i was doing -j 16
[09:00:15] <mru> out of memory?
[09:00:55] <j0sh> not sure, that's likely, i only have 512mb
[09:02:23] <cartman> :>
[09:03:17] <j0sh> yeah gcc just kills it with an internal error and no other info. prob memory
[09:04:45] <cartman> j0sh: -j16 means you have lots of cores, do you?
[09:07:34] <j0sh> cartman: i dont know how many cores i have, i just crank it up so it finishes faster :)
[09:07:54] <j0sh> probably quad, its a nehalem xeon
[09:07:59] <cartman> j0sh: that won't work usually
[09:08:11] <cartman> get more RAM too
[09:08:30] <cartman> make -j$(core_count +1) is the usual deal
[09:08:50] <mru> that +1 is so stupid
[09:08:56] <mru> there is no such "rule"
[09:08:57] <j0sh> good tip. its a VPS i have for testing random stuff, so my ram is limited
[09:09:03] <cartman> mru: right
[09:09:16] <mru> it depends on what the limiting factor is
[09:09:23] <cartman> i/o or cpu right
[09:09:25] <cartman> damn it ;)
[09:09:57] <mru> on my quadcore with ht build time drops nicely until -j6
[09:10:08] <mru> -j8 gives only a slight improvement
[09:10:15] <mru> -j9 a tiny bit more
[09:10:20] <cartman> I have quad-core i7
[09:10:24] <cartman> I am doing -j9
[09:10:36] <mru> quad-i7 here too
[09:10:52] <cartman> mru: using -j6 or 9?
[09:11:43] <mru> I usually use 4-6 inclusive
[09:11:48] <mru> depending on what else I'm doing
[09:12:02] <Dark_Shikari> I use 16
[09:12:10] <cartman> Dark_Shikari: core count?
[09:12:29] <cartman> mru: makes sense
[09:12:36] <Dark_Shikari> 4 cores + HT, so 8
[09:12:44] <cartman> and 16 is because? :D
[09:13:02] <mru> 4ht performs about like 5 or 6 real cores
[09:13:06] <mru> nowhere near 8
[09:13:20] <cartman> 8, only in the task manager :P
[09:13:26] <Dark_Shikari> mru: Yes, but you need 8 threads to have it perform like 6
[09:13:35] <Dark_Shikari> 6 threads will not fully utilize 4 HT cores
[09:13:37] <mru> Dark_Shikari: depends on the application
[09:13:50] <Dark_Shikari> it's physically impossible for less than 8 threads to saturate an i7 with HT
[09:13:52] <mru> make -j6 in ffmpeg fully loads 6 virtual cores
[09:14:00] <Dark_Shikari> yes, so you  have two not being loaded.
[09:14:20] <Dark_Shikari> in order to saturate a physical core, you need two threads going at once in the two virutal cores assigned to it.
[09:14:23] <mru> so I have a few cycles spare for doing other things
[09:14:27] <Dark_Shikari> ok, true.
[09:14:29] <Dark_Shikari> good point =p
[09:14:33] <Dark_Shikari> but I rarely have any compilation last more than 30 seconds
[09:14:37] <cartman> Dark_Shikari: why 16 still?
[09:14:50] <Dark_Shikari> It's probably faster than 8 because of disk reads blocking everything.
[09:14:52] <mru> I'd expect build time to increase after -j12 or so
[09:14:55] <Dark_Shikari> And I like powers of 2.
[09:14:58] <mru> I build in tmpfs
[09:15:12] <Dark_Shikari> I'm on windows.  Windows doesn't know what a tmpfs is.
[09:15:15] <mru> source and compilers are cached
[09:15:25] <mru> sucks being you then
[09:15:28] <twnqx> windows still knows ramdisks...
[09:15:49] <Dark_Shikari> ok, true
[09:16:00] <Dark_Shikari> Well, actually, seriously, I run "svn diff" before doing anything with a source tree.
[09:16:05] <Dark_Shikari> i.e. when starting up a computer, etc
[09:16:09] <Dark_Shikari> it loads all the source files into cache ;)
[09:16:25] <mru> my computer is always on
[09:16:37] <Dark_Shikari> yes, but things fall out of cache after playing civ5
[09:16:41] <Dark_Shikari> or processing large video files
[09:16:49] <Dark_Shikari> hell, encoding one y4m file will kick all my source code out of cache
[09:16:50] <mru> I have 12GB ram
[09:16:55] <CIA-63> ffmpeg: lucabe * r25159 /trunk/libavdevice/v4l2.c:
[09:16:55] <CIA-63> ffmpeg: Allow to set the frame rate in v4l2 devices
[09:16:55] <CIA-63> ffmpeg: Patch by Jos? Miguel Gon?alves (jose DOT goncalves AT inov DOT pt)
[09:16:58] <Dark_Shikari> and?
[09:17:02] <Dark_Shikari> one y4m file... =p
[09:17:09] <mru> I don't have many y4m files
[09:17:27] <Dark_Shikari> you don't write encoders
[09:17:53] <mru> no need to tell me
[09:18:36] <Dark_Shikari> also, windows has kind of bad caching
[09:18:50] <Dark_Shikari> encoding one file of size $diskcache is practically guaranteed to empty the disk cache of everything else
[09:19:04] <Dark_Shikari> it's basically LRU
[09:19:11] <mru> so it sucks being you
[09:19:30] <Dark_Shikari> actually, is linux's any better?
[09:19:58] <cartman> no, but at least Linux has a terminal :p
[09:20:33] <Dark_Shikari> linux doesn't have a terminal, linux is a kernel =p
[09:20:43] <cartman> rms/linux I mean
[09:21:02] <mru> what are those terminal drivers doing in the kernel then?
[09:21:36] <Dark_Shikari> because they need something to bloat the code with
[09:22:19] <mru> so how do you suggest talking to the hardware?
[09:22:29] <mru> and windows users should shut up about kernel bloat
[09:22:56] <Dark_Shikari> But Windows makes no pretention of ever being efficient or well written.
[09:23:05] <Dark_Shikari> It's _expected_ to be a bloated pile of dung.
[09:23:11] <mru> then why the fuck do you use it?
[09:23:23] <Dark_Shikari> Because I have a lot of apps that only run on windows, and I don't have many apps that only run on linux.
[09:24:20] <Dark_Shikari> And a VM works well for the latter.
[09:24:24] <Dark_Shikari> A VM can't really play 3D games.
[09:25:15] <Dark_Shikari> well, I guess paravirtualization a'la xen might have a chance.
[09:54:16] <CIA-63> ffmpeg: cehoyos * r25160 /trunk/libavformat/asfdec.c: Fix indentation after r25158.
[09:56:20] <CIA-63> ffmpeg: mru * r25161 /trunk/tests/ (regression-funcs.sh fate-run.sh): fate: print commands being executed with V=1
[10:27:27] <cartman> mru: so ./fate.sh fate.config V=1 ?
[10:27:43] <mru> no
[10:28:11] <cartman> obvious question coming up, how then?
[10:28:30] <mru> why would you run fate.sh manually anyway?
[10:28:54] <cartman> mru: why not?
[10:29:13] <mru> simpler to make fate in your usual build dir
[10:29:19] <mru> spares you a full rebuild
[10:29:34] <cartman> oh but how does it find fate.config ?
[10:29:41] <mru> none needed then
[10:29:50] <cartman> ah just the output
[10:31:34] <cartman> mru: and the path to fate-suite?
[10:31:56] <mru> configure --samples=/path/to/fate-suite
[10:32:08] <mru> or make fate SAMPLES=/path/to/fate-suite
[10:33:00] <cartman> thanks!
[10:33:49] <cartman> [NULL @ 0x101000000] [Eval @ 0x7fff5fbfd9d8] Undefined constant or missing '(' in 'si'
[10:33:52] <cartman> [NULL @ 0x101000000] Unable to parse option value "simple"
[10:33:54] <cartman> this is the first error
[10:34:11] <cartman> idct parsing is borked
[10:34:33] <cartman> option parsing is broken rather
[10:34:34] <cartman> :)
[10:35:42] <mru> what's with -no-integrated-as btw?
[10:35:53] <cartman> mru: doesn't compile otherwise
[10:35:57] <mru> does for me
[10:36:05] <cartman> didn't back then
[10:36:07] <cartman> lets see
[10:36:18] <mru> always did for me
[10:38:50] <cartman> libavcodec/x86/dsputil_mmx_avg_template.c:737:9: error: invalid instruction mnemonic 'pavgusb'
[10:40:18] <mru> osx retardedness?
[10:40:24] <cartman> bleh ;)
[10:40:51] <cartman> all errors point to pavgusb
[10:40:54] <cartman> whatever it is
[10:41:23] <mru> looks like some kind of vector average instruction
[10:43:22] <cartman> any ideas about the parsing problem, which file would be responsible for parsing options?
[10:43:33] <mru> clearly a miscompilation
[10:43:39] <cartman> yup
[10:43:41] <mru> it works fine with all other compilers
[10:43:43] <cartman> I'll try -O1 etc.
[10:43:48] <cartman> which file? :)
[10:43:52] <mru> eval.c probably
[10:43:56] <cartman> thanx
[10:45:11] <cartman> removing -O3 didn't make any change
[10:59:57] * lu_zero meanwhile is trying to teach neon to android...
[11:00:10] * lu_zero ponders about using another toolchain
[11:00:23] <mru> that's usually the easy choice
[11:00:51] <cartman> android knows neon already, no?
[11:00:56] <lu_zero> it's annoying if you want other people
[11:01:03] <lu_zero> cartman: the as is complaining
[11:01:05] <mru> other people are annoying
[11:01:13] <andoma> </quote>
[11:01:14] <cartman> mru: agreed
[11:01:50] <lu_zero> So there is a way to tell it to use neon, just not the usual one...
[11:02:30] <mru> if it worked the usual way, everybody would see that it's nothing special
[11:04:17] <DonDiego> jannau: latm!
[11:04:32] <DonDiego> i can see you procrastinating even from here..
[11:04:34] <DonDiego> :)
[11:04:57] <cartman> (gdb) print p->s
[11:04:57] <cartman> $9 = 0x100e00090 "si"
[11:05:02] <cartman> half parsed :D
[11:05:13] <mru> cartman: you're wasting your time
[11:05:17] * DonDiego sees jannau pay for his own beverages at next year's linuxtag - poor jannau ...
[11:05:19] <cartman> mru: why?
[11:05:49] <mru> have you tried very latest clang trunk for starters?
[11:05:58] <cartman> mru: sure?
[11:06:06] <cartman> I compile 2-3 times a day
[11:06:19] * mru curses viewvc
[11:06:20] <lu_zero> DonDiego: IFF he manages to get his git tree I'll pay for his beverages =P
[11:06:30] <mru> no way to see a nice list of commits
[11:06:32] * cartman goes back to gdb time waste session
[11:07:33] <DonDiego> lu_zero: git is stopping his important work..
[11:07:54] <lu_zero> latm vs git ..
[11:07:58] <lu_zero> hard choices...
[11:08:08] * mru doesn't care about latm
[11:11:22] <DonDiego> it's what separates ffmpeg from aac world domination
[11:12:57] <CIA-63> ffmpeg: michael * r25162 /trunk/libavfilter/avfilter.h:
[11:12:57] <CIA-63> ffmpeg: Correct terminology bug in poll_frame()
[11:12:57] <CIA-63> ffmpeg: it returns the number of samples not frames (for video sample=frame)
[11:16:14] <cartman> heh
[11:17:54] <mru> I see a few scary-looking commits in clang today
[11:23:38] <lu_zero> like?
[11:24:04] <mru> bunch things about rearranging branches
[11:29:34] <lu_zero> uhmm
[11:29:50] <lu_zero> NEON enabled              yes
[11:29:53] <lu_zero> yai!
[11:30:05] <cartman> mru: found it
[11:30:07] <cartman>             for(i=0; i<sizeof(buf)-1 && val[i] && val[i]!='+' && val[i]!='-'; i++)
[11:30:10] <cartman>                 buf[i]= val[i];
[11:30:18] <cartman> this part is possibly the problem
[11:30:21] <cartman> val = "simple"
[11:30:26] <cartman> but buf ends up being sÅŸi
[11:30:27] <cartman> si*
[11:30:32] <cartman> libavcodec/opt.c
[11:30:43] <cartman> line 154
[11:30:52] <cartman> work with -O1 broken with -O2
[11:30:53] <mru> I see nothing wrong with that line
[11:31:07] <cartman> well thats where simple becomes si
[11:31:09] <kurosu> cartman: pavgusb is a 3DNow instruction that lead to the SSE pavgb
[11:31:24] <cartman> kurosu: oh clang doesn't support 3DNow I think
[11:31:26] <kurosu> (predating it)
[11:31:48] <kurosu> disable 3Dnow then in configure
[11:31:55] <cartman> mru: compiling opt.c with -O1 fixes it
[11:31:58] <kurosu> (if that's possible, I don't know)
[11:32:11] <cartman> kurosu: I'll wait for them to fix their assembler
[11:32:12] <lu_zero> cartman: use delta to produce a reduced testcase
[11:32:27] <cartman> lu_zero: how can I know its miscompiled using delta?
[11:32:55] <cartman> I can report and they can do the hard work :P
[11:33:10] <lu_zero> as you wish, just report it ^^
[11:37:47] <cartman> http://llvm.org/bugs/show_bug.cgi?id=8212
[11:46:32] <Tjoppen> an update on my subtitle issues: adding padding packets didn't help
[11:47:12] <Tjoppen> I'm assuming it's OK to add them pretty much anywhere. I added them after each video packet. plays fine in ffplay
[11:48:43] <lu_zero> uhm
[11:48:48] <lu_zero> interesting...
[11:48:51] <lu_zero> brb
[11:49:11] <Tjoppen> I'm grabbing the vlc git. going to see if their demuxer might be the problem
[12:05:35] <Tjoppen> .. interesting. netbeans is automagically configuring and making vlc. just had to bootstrap and import it as a new project
[12:09:39] <kshishkov> sounds like another reason to avoid VLC
[12:10:26] <cartman> netbeans & vlc?
[12:10:26] <cartman> wtf
[12:11:53] <Tjoppen> it's actually one of the better ide's I've come across
[12:12:42] <Tjoppen> quite surprising, yes. sometimes it gets stuck parsing for a while though, such as when switching between my local ffmpeg branches
[13:29:27] <Tjoppen> interesting.. vlc has a rather big (360k) table for doing the PID -> stream mapping
[13:30:15] <kierank> what pid -> stream mapping?
[13:32:03] <Tjoppen> maybe I'm using the wrong words. but it needs to keep some state for each pid seen. lavf allocate such state dynamically afaict. vlc just allocates all 8192 entries
[13:32:24] <kierank> i see
[13:33:51] <Tjoppen> that demuxer is quite a bit larger too. mpegts.c is 1801 lines while vlc's ts.c is 4367
[13:35:21] <mru> the vlc ts demuxer is horribly complicated
[13:35:44] <Tjoppen> so I see. finding this bug is going to be.. nontrivial
[13:36:10] <Tjoppen> if it is that demuxer's fault. it might not be
[13:44:54] <merbzt> Tjoppen: port the tcvp demuxer to ffmpeg
[13:45:11] <lu_zero> the tcvp is better?
[13:46:39] <mru> some things are done more cleanly
[13:49:49] <Tjoppen> appearently the people who want this remuxing done think the file I have now looks OK. it seems more and more like vlc isn't doing what it should
[13:54:37] <lu_zero> tell vlc people to look into it
[13:57:50] <Tjoppen> I think I will
[15:05:16] <BBB> Dark_Shikari: if I do punpckldq xmm0, [mem], then mem has to be 16-byte aligned right? what if it isn't? is there a "punpckldq for unaligned memory"? or do I have to movdqu into a register first?
[15:20:55] <thresh> http://tortoisesvn.net/howpaypalscrewsopensourceprojects
[15:25:05] <kshishkov> what do you expect from payment system founded by ex-scammer?
[15:34:52] * BBB hates gdb
[15:35:28] <BBB> I get a segfault somewhere where it claims I'm reading from a NULL address, and then info-registers tells me the address at that line is perfectly valid
[15:35:31] <BBB> now what do I do??
[15:37:40] <mru> debug gdb
[15:37:49] <BBB> I want to kill gdb
[15:38:00] <mru> have you valground it?
[15:38:10] <BBB> I'll try
[15:38:54] <kierank> i had a problem like that once and updating gdb fixed it
[15:38:57] <iive> kshishkov: is he really ex- ?
[15:41:19] <BBB> lots of complaints about pred8x8_plane_c
[15:41:26] <BBB> my function runs find in valgrind
[15:57:47] <BBB> hm, apparently gdb was off a few instructions of where the problem actually occurred...
[15:58:53] <mru> that happens
[16:00:02] <BBB> gdb is really shitty sometimes
[16:00:27] <kierank> it also sometimes does multiple instructions when you try and step through one instruction
[16:02:51] <BBB> it almost works now
[16:03:01] <BBB> it's off a tiny bit for the new function I wrote, but mostly correct
[16:03:06] <pJok> kierank, its a feature, not a bug
[16:03:13] <BBB> and it looks like it's double the speed of the original :)
[16:03:25] <BBB> (that's still only 0.1% faster, but hey, 0.1%=0.1% :) )
[16:21:28] <jankowiak> Hi, I have a quick question, I have simple ffplay clone to play audio streams and I have been trying to figure out how to set a progress bar... I've tried a few variations using the get_audio_clock but it isn't working...
[16:22:45] <jankowiak> from what I have read the duration in the AVStream is the total length while get_audio_clock * AV_TIME_BASE should give me the current position
[16:22:59] <jankowiak> is this correct?
[16:23:11] <jankowiak> or I am doing this completely wrong?
[16:23:13] <kierank> pJok: huh?
[16:23:34] <mru> completely wrong channel methinks
[16:24:08] <jankowiak> which would the right channel be?
[16:24:12] <mru> #ffmpeg
[16:25:13] <jankowiak> thanks, I'll try there, though the last time I questions like this there they had sent me here...
[16:26:29] <BBB> this is for ffmpeg development, not developing applications with ffmpeg (?)
[16:27:25] <kierank> maybe there should be an "in between" channel
[16:30:12] <thresh> #devel-ffmpeg
[16:30:24] <mru> #dev-null
[16:31:19] <Compn> libav-users list is the in-between
[16:31:30] <Compn> mailing list anyways
[16:31:42] <mru> yes, but no such channel
[16:34:46] <J_Darnley> Make one?
[16:34:57] <mru> feel free
[16:36:32] <kierank> #libav-users?
[17:28:31] <kierank> it's mru's favourite person: http://www.xiph.org/video/vid1.shtml
[17:30:19] <kierank> html5, it just works (tm): http://dl.dropbox.com/u/2701213/xiph.png
[17:35:17] <Tjoppen> it just works
[17:48:26] <Tjoppen> crappy connection on their server :\
[17:48:59] <Tjoppen> 70 kBps? I am amused
[17:50:32] <kierank> Tjoppen: i meant the borked aspect ratio
[17:51:32] <kierank> ok, i visit the site again and it's out of sync...
[17:55:51] <Tjoppen> yes, I saw the aspect ratio problem
[18:01:01] <jenk> ok
[18:01:04] <jenk> i made #libav-users
[18:01:13] <jenk> because i wanted a channel to ask questions using libav* too
[18:01:29] <jenk> the documentation is pretty sparse
[18:01:32] <jenk> its hard to get into using it
[18:03:58] <kierank> you didn't register it
[18:04:50] <kierank> wow mru actually owns _troll_
[18:05:09] <mru> you hadn't noticed?
[18:05:22] <kierank> I thought you just change to it for trolling
[18:05:34] <kierank> just like i changed to kierankCDGS
[18:05:59] <mru> one does not preclude the other
[19:01:52] <cartman> my fate is green, clang regression is fixed \o/
[19:16:29] <_av500_> http://groups.google.com/group/shibboleth-users/browse_thread/thread/123bd2d82822a3a7?pli=1
[19:17:36] <thresh> _av500_: oh how awesome this e-mail is.
[19:18:33] <thresh> goat-time see like the wind, pole, and dragon?
[19:18:45] <thresh> it's even fun to decypher that!
[19:23:04] <cartman> _av500_: someone used Google Translate
[19:23:07] <cartman> I vomitted
[19:29:57] <Dark_Shikari> BBB: yes you have to movdqu first
[19:30:04] <Dark_Shikari> Note that this only applies to sse.
[19:30:08] <Dark_Shikari> the mmx version only loads 4 bytes
[19:30:14] <Dark_Shikari> the sse version should only load 8 bytes
[19:30:19] <Dark_Shikari> but it doesn't, it loads 16
[19:37:25] <mru> "Please apologize for your stupidity"
[19:38:08] * kshishkov lols at http://www.thinq.co.uk/2010/9/23/marvell-launches-triple-core-arm-chip/
[19:39:15] <cartman> kshishkov: battery will dry up in 5 minutes
[19:39:50] <mru> counting like that, omap4 is at least octocore
[19:39:54] * kshishkov suspects it will suck not only energy
[19:58:43] <_av500_> marvell-ous marketing vomit
[19:58:55] <_av500_> 2 cores and a 3rd aka dsp
[19:59:20] <_av500_> same as omap4, or snapdragon
[19:59:53] <wbs> does the current snapdragon have 2 cores, too? or some upcoming versions?
[20:00:03] <mru> omap4 has about a dozen little helper cores
[20:00:37] <lu_zero> little as scaled down arms or dsp or something?
[20:00:53] <_av500_> m3
[20:01:00] <_av500_> so arm7 like
[20:01:57] * cartman wonders about energy usage
[20:04:43] <_av500_> cartman: why?
[20:05:03] <_av500_> core that are unused sleep or are not powered
[20:08:46] <cartman> _av500_: wondering the extreme case like decoding 1080p etc.
[20:10:42] <cartman> _av500_: in the education sector, a minimum of 8 hours is required for any reading device.
[20:11:36] <lu_zero> cartman: 8hour ...
[20:11:48] <cartman> a school day is about 8 hours
[20:13:00] <cartman> iPad seems to be the battery king for now
[20:13:40] <mru> you wouldn't be reading 8h continously
[20:13:51] <cartman> true, device can sleep etc.
[20:14:01] <cartman> but many devices won't make it after 5 hours
[20:14:13] <mru> my archos5it lasts about 30 days on standby
[20:14:33] <cartman> mru: that has _av500_ module installed it seems
[20:14:48] <_av500_> :)
[20:24:09] <CIA-63> ffmpeg: reimar * r25163 /trunk/libavcodec/rawdec.c:
[20:24:09] <CIA-63> ffmpeg: rawdec: only allocate a full-frame size buffer if it actually will
[20:24:09] <CIA-63> ffmpeg: be used, place palette buffer in the context to simplify this.
[20:57:17] <cert_> hi
[20:58:06] <cert_> how can i get ffmpeg-devel with lucid to compile xbmc with external lib?
[20:58:22] <_av500_> yes
[21:01:18] * mru still hasn't managed to parse that question
[21:02:01] <cartman> cert_: better ask in #ubuntu
[21:05:33] <cert_> ok thank you
[21:34:28] <CIA-63> ffmpeg: mstorsjo * r25164 /trunk/ (5 files in 3 dirs): Add a G.722 encoder
[22:21:14] <Dark_Shikari> how do I make ffmpeg print AV_LOG_DEBUG messages?
[22:21:19] <Dark_Shikari> no -v value seems to do it
[22:21:49] <mru> -loglevel
[22:21:57] <mru> don't ask
[22:22:04] <Dark_Shikari> wait.  wtf is the difference between that and -v?
[22:22:12] <mru> ^^
[22:27:51] <Dark_Shikari> bah.  no response to my ML email
[22:27:53] <Dark_Shikari> and my patch still breaks shit subtly
[22:58:37] <lu_zero> uhm?
[22:58:42] <lu_zero> still the h264 one?
[23:01:00] <Dark_Shikari> oh, I have one that works now.
[23:01:02] <Dark_Shikari> http://pastebin.org/1130459
[23:01:04] <Dark_Shikari> looooooooooooooooooooooool
[23:01:46] <jenk> ?
[23:02:49] <Dark_Shikari> it's a downright braindamaged hack, but it works fully
[23:02:51] <Dark_Shikari> passes all the test cases
[23:07:31] <_av500_> and does what?
[23:07:55] <Dark_Shikari> makes h264 error concealment work correctly with drop frames
[23:07:57] <Dark_Shikari> *dropped
[23:08:05] <Dark_Shikari> currently, it "time warps" back to the end of the ref list
[23:08:37] <_av500_> ic
[23:09:12] <Dark_Shikari> I can upload a rather effective test clip
[23:09:52] <Dark_Shikari> this test clip has every 5th frame dropped, and then the encoder corrects the dropped frame
[23:09:59] <Dark_Shikari> if you play it in current ffmpeg, it will look hilariously awful
[23:10:07] <Dark_Shikari> if you apply that patch, the loss is almost invisible.
[23:11:05] <Dark_Shikari> http://www.mediafire.com/?6huh99qemkrp11y
[23:11:08] <Dark_Shikari> here's the test clip
[23:32:28] <lu_zero> what did you change?
[23:32:34] <Dark_Shikari> read the patch
[23:32:57] <lu_zero> I would if thunderbird isn't being killed by my qemu mailbox...
[23:33:09] * lu_zero starts purging
[23:36:22] <lu_zero> 18789 lu_zero   20   0 1853m 1.3g  15m D   88 67.2   0:29.51 thunderbird-bin
[23:36:30] <lu_zero> ....
[23:37:07] <Dark_Shikari> sounds like firefox
[23:37:55] <lu_zero>  3280 lu_zero   20   0 1037m 226m 4512 S    1 11.4   9:43.41 firefox
[23:38:06] <lu_zero> note the difference...
[23:46:20] <lu_zero> uhm
[23:46:24] <lu_zero> where is your patch?
[23:47:01] <Dark_Shikari> I just pasted it above...
[23:47:49] <lu_zero> thought you had posted it
[23:48:30] <Dark_Shikari> I did.  in irc
[23:50:49] <lu_zero> on the ml
[23:51:30] <Dark_Shikari> of course not
[23:51:32] <Dark_Shikari> it's a massive pile of hack
[23:54:20] <lu_zero> how do you plan to clean it up?
[23:54:46] <Dark_Shikari> I don't
[23:54:51] <Dark_Shikari> there's no "cleanup" to do
[23:54:54] <Dark_Shikari> it's as clean as it can possibly be
[23:55:09] <Dark_Shikari> it's the _wrong_ way to fix it, but it _works_, and michael won't respond to my email, so I won't try to make it right.
[23:56:11] <lu_zero> hopefully he'll catch the log and will reply =P
[23:56:25] <kierank> ^^ MICHAEL READ THIS
[23:56:26] <Dark_Shikari> michael: your code sucks and is broken.
[23:56:26] <kierank> ;)
[23:56:39] <Dark_Shikari> the error concealment code is completely broken and doesn't work with lost frames
[23:56:52] <Dark_Shikari> it doesn't even just assume the frame to be equal to the previous
[23:56:55] <Dark_Shikari> it just breaks horribly