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

[irc at mansr.com]

[06:04:06] <av500> Guten Morgen
[06:05:07] <kshishkov> god morgon
[06:07:02] <av500> lol, google is now pointing people to libavcodec/vp8dsp.c for VP8 documentation....
[06:07:26] <elenril> lol?
[06:07:37] <av500> Dark_Shikari: BBB: quick, change the bitstream to your liking :)
[06:08:00] <elenril> av500: link?
[06:08:22] <Dark_Shikari> lol
[06:08:36] <Dark_Shikari> I think that's a tactit admission that our code is better than theirs
[06:09:57] <hyc> cool
[06:10:11] <hyc> pipe all the comments thru piglatin
[06:10:24] <astrange> we have comments?
[06:10:35] <hyc> oh, never mind ;)
[06:11:57] <av500> elenril: http://groups.google.com/a/webmproject.org/group/codec-devel/browse_thread/thread/d370edb1c4bcd4f8?hl=en#
[06:15:27] <saintdev> oops, seems we forgot to copypasta the source in that part of the spec
[06:15:36] <KotH> lol
[06:27:53] <cartman> how lame
[07:58:29] <j0sh> wbs: nice job tracking down that leak
[08:01:48] <wbs> j0sh: it was quite easy to pinpoint with valgrind :-)
[08:03:06] <j0sh> wbs: all i was able to see was that it leaked 16 bytes of extradata
[08:03:27] <j0sh> gdb told me it was in the aac encoder, but other than that, no other info
[08:03:36] <j0sh> didnt feel like backtracking from there :)
[08:03:48] <wbs> j0sh: use --leak-check=full with valgrind, then it tells you the location of the leaked allocations :-)
[08:04:03] <j0sh> yeah thats what i did
[08:04:19] <wbs> you may need to compile without -fomit-frame-pointer in order to get proper backtraces in valgrind though
[08:05:01] <j0sh> thats probably it, i'm seeing compiler generated functions like T.676
[08:05:24] <j0sh> which is the entirety of the backtrace in ffmmpeg.c
[08:05:33] <wbs> ah
[08:06:11] <wbs> in my case, I got http://pastebin.org/386076
[08:07:40] <j0sh> mine looked pretty similar
[08:10:16] <j0sh> http://pastebin.org/386084
[08:10:17] <j0sh> ah well
[08:11:10] <wbs> after compiling without -fomit-frame-pointer, the same backtrace becomes http://pastebin.org/386088 instead
[08:11:17] <wbs> and then it's quite trivial to pinpoint the leak
[08:11:31] <j0sh> indeed, now i see
[08:12:31] <j0sh> well, fomit-frame-pointer is a good tip to know
[08:13:08] <astrange> --disable-optimizations or so
[08:13:30] <wbs> yeah, that can be used, too, but that disables a whole lot more
[08:14:39] <j0sh> i've never gotten --disable-optimizations to quite work
[08:14:59] <j0sh> usually have to --disable-mmx or something similar too
[08:15:29] <astrange> i think it works these days
[08:15:52] <astrange> --disable-asm works along with it if you need to debug into dsp (and don't want to read info registers)
[08:17:26] <j0sh> alright i'll keep that in mind whenever i start hacking on neon
[08:17:53] <j0sh> how to disable prettyprinted compilation in configure?
[08:18:00] <astrange> make V=1
[08:19:15] <j0sh> should that be documented somwhere? make --help doesn't mention anything
[08:19:35] <wbs> make --help just says make-specific options, but this is a ffmpeg-makefile specific thing
[08:19:53] <wbs> but yeah, I guess it should be documented somewhere. patch welcome, as always. :-)
[08:39:18] <j0sh> wbs: i'm going to bed, i'll fix the things you reviewed in the AM
[08:39:46] <wbs> j0sh: ok, no hurry, I guess it will take a while to discuss the timestamp handling issue, too
[08:40:27] <j0sh> yeah, setting the pts might not even be needed there. i'll play around with it
[08:40:58] <wbs> I do think it is needed, but it has to be done in a slightly different way
[08:41:08] <hyc> woohoo. ffserver seems to return HTTP 200 even when it fails
[08:41:56] <DonDiego> cartman: IIRC it was you that hosted the ffmpeg doxygen docs, right?
[08:42:09] <cartman> DonDiego: indeed
[08:42:12] <cartman> should still be working
[08:42:15] <av500> Dark_Shikari: nice score! :)
[08:42:22] <Dark_Shikari> ?
[08:42:22] <DonDiego> i have just finished setting it up on mphq
[08:42:27] <av500> Dark_Shikari: on vp8
[08:42:31] <Dark_Shikari> what about vp8
[08:42:40] <cartman> DonDiego: cool!
[08:42:42] <DonDiego> cartman: thanks for hosting it all this time
[08:42:47] <av500> Dark_Shikari: the comment on #vp8
[08:42:53] <DonDiego> you can of course keep hosting it if you want to
[08:42:56] <cartman> DonDiego: it was an honour =)
[08:42:56] <Dark_Shikari> =p
[08:43:02] <DonDiego> but there is now an official replacement
[08:43:05] <cartman> DonDiego: its a cron script, I'll let it run
[08:43:17] <DonDiego> sure, just to let you know...
[08:43:21] <cartman> cheers
[08:59:47] <CIA-99> ffmpeg: benoit * r24104 /trunk/libavcodec/zmbv.c:
[08:59:47] <CIA-99> ffmpeg: Remove a useless variable in zmbv decoder.
[08:59:47] <CIA-99> ffmpeg: Patch by Eli.Friedman (gmail)
[09:00:44] <CIA-99> ffmpeg: hyc * r24105 /trunk/ffserver.c: Fix "server too busy" status code
[09:21:48] <CIA-99> ffmpeg: diego * r24106 /trunk/doc: Ignore generated .pod files.
[09:21:49] <CIA-99> ffmpeg: hyc * r24107 /trunk/ffserver.c: Also use 503 for bandwidth limit exceeded
[12:06:30] <Tjoppen> av_pix_fmt_descriptors needs to be exported via some function or you can't access that information when linking to dlls
[12:07:05] <Tjoppen> assuming that user is supposed to be able to access it. ffmpeg and ffplay do
[12:09:30] <mru> seems to be working on fate
[12:10:31] <Tjoppen> the problem is linking i msvc
[12:10:34] <Tjoppen> *in
[12:11:03] <mru> don't do that then
[12:11:26] <mru> are you linking against the dlls directly or using the import libs?
[12:11:34] <Tjoppen> import libs. can't link against the dlls
[12:11:50] <mru> ok, wasn't sure what was possible
[12:12:01] <mru> windows dlls seem like huge, ugly monster hack to me
[12:12:09] <Tjoppen> it can't really generate stubs for accessing global arrays :o
[12:12:21] <Tjoppen> hence why a function is needed
[12:12:38] <mru> so how can it work when building ffmpeg normally?
[12:13:00] <Tjoppen> built in mingw, using ld instead lf link.exe
[12:13:05] <Tjoppen> *of
[12:13:23] <mru> and what does ld do differently?
[12:13:32] <Tjoppen> no idea. maybe doesn't use import libs?
[12:13:34] <hyc> current binutils claims to be able to link against DLLs directly
[12:13:46] <hyc> used to be that only worked for function references
[12:13:50] <Tjoppen> in fact: it does not use import libs because ffmpeg worked before I had set up %PATH% to point to lib.exe
[12:13:57] <hyc> seems that now they handle data refs too
[12:14:11] <mru> so how do data references get resolved?
[12:14:13] <mru> at runtime
[12:14:23] <Tjoppen> they can't. not in msvc anyway
[12:14:30] <hyc> dunno. that used to always require an import and a fixup.
[12:14:30] <Tjoppen> untill the ditch the need for import libs
[12:15:11] <mru> but how does it work at runtime when ld has done its magic?
[12:15:18] <Tjoppen> or maybe they could, in a rather roundabout way (have points the point to the arrays in the dll on startup)
[12:15:28] <Tjoppen> s/points/pointers
[12:15:56] <mru> ELF is just so much more elegant
[12:16:18] <hyc> they must add something to the crt startup code to relocate data references
[12:17:57] <Tjoppen> one part of it seems to be lots and lots of function stubs. check the exports of libs and you'll see lots of duplicates of all functions
[12:18:54] <mru> I know function calls go through a stub
[12:19:16] <hyc> those really aren't needed any more. even MSVC can call DLL functions without the stubs
[12:19:38] <mru> ELF lazy symbol resolution is neat
[12:20:36] <hyc> yeah, ELF does a lot of things pretty well
[12:20:45] <Tjoppen> yes, I think I've seen linking directly to dlls once or twice. unfortunately link.exe refuses to link with the libav* dlls. it thinks they are corrupt
[12:21:10] <hyc> but I think AIX has the best Unix file format
[12:21:16] <mru> really?
[12:21:23] <mru> aix is full of bizarre quirks
[12:21:25] <hyc> probably because it has a lot of ideas in common with mainframe formats
[12:22:01] <hyc> AIX exes can be relinked
[12:22:04] <mru> "It used to be said [...] that AIX looks like one space alien discovered Unix, and described it to another different space alien who then implemented AIX. But their universal translators were broken and they'd had to gesture a lot." -- Paul Tomblin
[12:22:58] <hyc> and object files are basically just a container without any other semantics
[12:23:17] <hyc> the linker deals with the actual objects - functions and variables
[12:23:40] <kshishkov> mru: look at another IBM creations
[12:23:41] <hyc> every symbol has its size, and the linker just pulls in what it wants from whatever files you give it
[12:24:36] <hyc> and everything is PIC by default, a shared lib can be linked dynamically or statically
[12:25:11] <mru> PIC is annoying
[12:25:15] <mru> it slows things down
[12:25:42] <mru> although on ppc64/power it doesn't really matter
[12:25:44] <hyc> yeah, I guess so. worse on x86.
[12:26:02] <mru> on ppc64 you always have a TOC anyway
[12:26:27] <mru> and there's some serious linker voodoo around calling external functions
[12:26:30] <mru> to set up the TOC pointer
[12:27:14] <mru> function descriptors...
[12:27:16] <mru> ugh
[12:27:22] <hyc> yeah... also reminiscent of mainframes
[12:27:43] <kshishkov> mru: what about PIC on MIPS?
[12:27:56] <mru> mips is also annoying
[12:27:59] <hyc> on 68K PIC was faster.
[12:28:11] <hyc> function references using PC-relative addressing
[12:28:27] <hyc> and variables using basereg-relative
[12:28:30] <mru> that doesn't work when start using shared libs
[12:29:16] <mru> which is why you need GOT/PLT/TOC indirection
[12:29:20] <hyc> true
[12:29:57] <mru> on mips each function with external linkage has a prologue to set up the GOT
[12:30:10] <DonDiego> Yuvi, are you ok with the doxy change to vp8.c from r23979?
[12:30:13] <hyc> sparc did that too
[12:30:20] <mru> calls from within the same object bypass the prologue
[12:30:24] <mru> since they have the same got
[12:30:57] <mru> ppc64 has the caller load the toc from the function descriptor before calling
[12:31:02] <mru> same end result
[12:31:10] <mru> but more code
[12:31:34] * kshishkov saw PIC in PPC code - brain-damaging
[12:31:58] * mru points at altivec fft
[12:32:02] <hyc> the prologue trick requires MMU games.
[12:32:17] <mru> not really
[12:32:33] <mru> to the code, it's all a flat address space
[12:32:39] <hyc> it uses fixed offsets, that are remapped for each process
[12:32:42] <kshishkov> only OS requires MMU games
[12:33:23] <mru> that's just describing virtual addresses as used on any sane OS
[12:33:59] <hyc> if the caller loads instead of callee, you can share without an MMU. which we did on 68000.
[12:34:35] <mru> mmu has nothing to do with this
[12:35:06] <mru> mmu-less shared libs are interesting in their own way of course
[12:35:29] <kshishkov> yes, like Windows ones
[12:36:13] <hyc> hmmm. yeah, having to run rebase was always such a treat.
[12:38:40] <mru> one thing I don't understand about the ppc abi is why the stack frame is described in such minute detail
[12:38:57] <hyc> setjmp/longjmp ?
[12:39:03] <mru> insisting on specific offsets being used to store each saved register
[12:39:04] <Tjoppen> I'll post a thread requesting the lavu API be extended with av_get_pix_fmt_descriptor()
[12:39:11] <mru> Tjoppen: please do
[12:39:17] <mru> it's a real problem and we need to fix it
[12:39:19] <Tjoppen> minor version bump as well I guess
[12:39:24] <hyc> I think all of the SVR4 ABI manuals go to that detail
[12:39:38] <hyc> I have i860, m68k, and sparc here
[12:39:41] <Tjoppen> I'll roll them into the same patch for atomicity :)
[12:41:15] <mru> hyc: but why does it matter?
[12:41:41] <mru> ARM abi allows you to use the stack in any manner you see fit
[12:41:51] <mru> as long as you maintain alignment
[12:42:49] <hyc> hmmm. probably to allow stack unwinding by standard tools
[12:45:38] <mru> somehow arm tools manage it just fine
[12:46:12] <mru> the debug notes for each function can specify where everything is saved
[12:48:51] <mru> imo it's better to put less constraints on the code
[12:55:53] <Tjoppen> thread posted
[12:56:08] <Tjoppen> ice cream in five minutes \o/
[12:56:50] * mru has ice cream in the freezer
[12:57:24] * kierank ate all his
[12:57:40] <mru> kierank: no supermarkets in your area?
[12:57:44] <av500> Tjoppen: you posted a whole thread? epic, with flames and bikesheds?
[13:01:11] <Tjoppen> oh yes
[13:01:29] <Tjoppen> sock puppets and all
[13:36:36] <CIA-99> ffmpeg: diego * r24108 /trunk/ (3 files in 2 dirs): Restore array sizes in doxygen parameter names.
[13:39:39] <DonDiego> BBB: are you ok with the doxy change to vp8.c from r23979?
[13:47:47] <BBB> uhm... does doxy not like [] in the comments?
[13:48:00] <mru> DonDiego: says so
[13:48:07] <BBB> can we escape it?
[13:50:47] <DonDiego> the problem is that you document two parameters where the function has only one
[13:51:24] <av500> according to what I read it meabs the function has to have 2 as well, no?
[13:51:36] <DonDiego> BBB: while we're at it, maybe you could fix the doxygen warnings about undocumented parameters in vp8.c?
[13:52:00] <BBB> oh, so it doesn't recognize?
[13:52:04] <BBB> how about the following:
[13:52:21] <BBB> change it so it says @param array [0] ac dequant factor, [1] dc dequant factor
[13:52:29] <BBB> or something like that
[13:53:10] <DonDiego> btw, can anybody see the mistake in r23983? afaict it's correct
[13:54:14] <mru> removing the comma looks correct
[13:54:20] <DonDiego> to me as well..
[13:54:35] <benoit-> FWIW, to me too.
[13:55:19] <benoit-> I'd be tempted to add an s to the first 'initialize' too.
[13:55:39] <BBB> DonDiego: keep it
[13:55:47] <BBB> benoit-: nooooooooooooooooooooooo
[13:55:51] <BBB> benoit-: not that discussion again :-p
[13:55:58] <DonDiego> BBB: keep what?
[13:56:05] <BBB> DonDiego: keep the commit
[13:56:10] <BBB> the commit is fine, the comma is wrong
[13:56:27] <benoit-> BBB: it seems I was not here when the first one took place :)
[13:56:51] <mru> benoit-: be very, very careful
[13:57:11] <benoit-> mru, BBB: oh, you mean that 3rd person thing?
[13:57:15] <benoit-> I didn't mean that
[13:57:37] <benoit-> we have a subject for this one... its '0/1'
[13:57:40] <benoit-> it's
[13:58:08] <mru> I'm not so sure the number should be treated as a subject
[13:58:43] <benoit-> mru: -1 is treated as such in the second part of the comment
[13:58:56] <benoit-> anyway, I don't care, really.
[13:59:06] <mru> that could be the error
[13:59:48] <benoit-> I picked the wrong one then :)
[14:00:02] <mru> people have an outstanding knack for doing that
[14:01:38] <benoit-> mru: in this case, both solutions would be ok... I mean, I would accept the two if it was in French, grammatically.
[14:10:32] <av500> stupid user question: how good is rtsp in ffmpeg compared to e.g. live555?
[14:11:12] <kierank> av500: --> #ffmpeg ;)
[14:13:19] <wbs> av500: in libavformat in general, I'd say it's decent for those formats/protocol variants that are supported
[14:13:30] <wbs> combined with ffplay there are a few gotchas
[14:13:51] <av500> ic
[14:21:19] <av500> hmm, m.youtube.com gives rtsp link with AAC LATM
[14:21:49] <wbs> yeah, that's one of the things we don't support yet :-)
[14:22:05] <kierank> hmmm so latm is used in the wild in something other than ts
[14:22:06] <wbs> don't know how much extra work it's on the rtp layer, but I'd figure it's easier once we have support for latm in general
[14:23:10] <av500> kierank: yes, I was surprised
[14:23:23] <av500> given that m.youtube is for like all the mobile phones out there...
[14:24:47] <mru> I thought google policy was do no evil...
[14:24:51] <mru> clearly that was a lie
[14:25:25] <av500> :)
[14:25:30] <av500> you caught them!
[14:25:44] <kshishkov> mru: it's ok until you think of it as an evil act
[15:01:39] <CIA-99> ffmpeg: rbultje * r24109 /trunk/libavcodec/wmavoice.c: Fix two doxy warnings.
[15:02:52] <CIA-99> ffmpeg: rbultje * r24110 /trunk/libavcodec/vp8.c: Add missing doxy for function arguments.
[15:30:39] <KotH> if i'd have to use a lossles encoding for RGB data in a comercial product, what would you recomend?
[15:31:13] <CIA-99> ffmpeg: mru * r24111 /trunk/Makefile: Beautify make messages when generating test data files
[15:31:14] <CIA-99> ffmpeg: mru * r24112 /trunk/Makefile: Clean up make rules for calling codec test scripts
[15:31:15] <CIA-99> ffmpeg: mru * r24113 /trunk/Makefile:
[15:31:15] <CIA-99> ffmpeg: Create the regtest reference files only when necessary
[15:31:15] <CIA-99> ffmpeg: This avoid recreating the ref files every time an individual test
[15:31:15] <CIA-99> ffmpeg: is run from the command line.
[15:31:35] <mru> KotH: depends on the requirements
[15:31:44] <mru> fast encoding? fast decoding? best compression?
[15:31:52] <mru> standard codec?
[15:32:26] <kshishkov> raw video - even commercial products should be able to understand it
[15:35:34] <KotH> mru: 640x480 @ 60fps RGB, probably higher resolution (but not that much higher, limited by camera size). being able to store it on not too large file
[15:35:49] <KotH> mru: currently it's mostly about a demonstrator, whether the project is feasible at all
[15:35:55] <KotH> ie, should be rather low cost
[15:36:01] <mru> sounds like you need realtime encoding
[15:36:12] <KotH> juup
[15:36:17] <mru> storage medium?
[15:36:25] <KotH> harddisk
[15:36:36] <KotH> so we can guestimate a 80MB/s
[15:36:47] <KotH> hmm..
[15:37:00] <mru> don't assume more than 30MB/s sustained writes to a disk
[15:37:08] <mru> they'll all do more in bursts
[15:37:16] <mru> and purely sequential writes
[15:37:23] * KotH isnt afraid of putting an SSD into such a device
[15:37:36] <mru> but once you fill up the write caches and have to do the odd seek, rates drop
[15:37:53] <KotH> those few bucks are much cheaper than developing a fast encoding scheme :)
[15:38:02] <mru> raid0 of 4 SSDs?
[15:38:05] <mru> that should be fast enough
[15:38:18] <KotH> even one should be enough
[15:38:30] <KotH> they have usually sustained write rates of 100MB/s
[15:38:33] <kshishkov> mru: raid of DDR :P
[15:38:36] <KotH> often much higher
[15:38:39] <mru> kshishkov: that exists
[15:38:48] <spaam> expensive ;D
[15:38:53] <kshishkov> mru: yes, and it's hard to beat that in speed
[15:39:10] <KotH> spaam: gues how much it'll cost if  have to code for one day
[15:39:27] <spaam> KotH: dunno.. tell us
[15:39:29] <KotH> mru: oh.. and i should be able to play it back with "standard" players (like mplayer ;)
[15:39:46] <mru> but not necessarily quicktime or wmp?
[15:40:02] <KotH> mru: customer asked for "if possible linux" :)
[15:40:47] <reynaldo> mornings
[15:40:55] <KotH> hey reynaldo!
[15:40:55] <mru> morning reynaldo
[15:41:09] <KotH> mru: beside: it's a demonstrator
[15:41:14] <mru> how's winter coming along?
[15:41:20] <spaam> KotH: if you buy 24SSD and put that in raid0.. you can write 2.0 gigabyte/sec ;)
[15:41:26] <reynaldo> hi there mru, KotH
[15:41:40] <reynaldo> mru: it keeps raining and raining..
[15:41:46] <reynaldo> quite boring, humid and cold
[15:41:48] <KotH> mru: first prio is getting a system that works.
[15:41:51] <mru> sunshine here
[15:41:56] <mru> although KotH won't believe that
[15:41:57] <KotH> reynaldo: come over here
[15:42:26] <reynaldo> oh, I would have to sell my kids to be able to afford the travel expenses :P
[15:42:29] <KotH> mru: i believe you, if you say sunshine... but i wouldnt belive if you'd say warm ;)
[15:42:31] <mru> ugh, next week I'll be working office hours again :-(
[15:42:31] <reynaldo> but thanks for the invite
[15:42:38] <KotH> reynaldo: i'd buy them ;)
[15:42:52] <mru> KotH: it's rather warm here
[15:42:55] <mru> 25 degrees or so
[15:43:04] * KotH doenst belive that
[15:43:11] <reynaldo> KotH: hehe, will keep that in mind :D
[15:43:27] <KotH> ROTFL
[15:43:33] <KotH> they want to use matlab for the demonstrator
[15:43:44] <mru> lol
[15:43:52] <KotH> so much for real time
[15:43:54] <reynaldo> kiss performance good bye then
[15:45:07] <reynaldo> what happened with the guy that wanted a QCELP encoder for his company?
[15:46:43] <KotH> has anyone ever worked with v4l?
[15:46:52] <mru> yes, sadly
[15:46:59] <mru> av500: ^^
[15:47:00] <KotH> what is your verdict?
[15:47:12] <spaam> reynaldo: hope that he make some patches  ;D
[15:47:13] <mru> it suffers from alsa syndrome
[15:47:15] <reynaldo> oh, that reminds me I need to get this isdb-t adapter working one of these days
[15:47:22] <KotH> mru: ?
[15:47:34] <mru> huge, complex interface that nobody understands
[15:47:41] <mru> and never quite works
[15:48:01] <spaam> haha
[15:48:17] <KotH> then, if you'd have to write a driver for a custom video device, would you use v4l or write full custom driver?
[15:48:21] <spaam> mru: so you can make it better if you get large number of $$$ ? ;)
[15:48:50] <KotH> spaam: given enough time and money, even you could make it better
[15:48:52] <mru> if you have a device that needs a driver, v4l2 is still the best choice
[15:48:57] <kshishkov> spaam: sure, just give enough to hire undertakers and priest
[15:49:00] <mru> driver interface proliferation is never good
[15:49:13] <KotH> ack
[15:49:19] <reynaldo> spaam: sure, it would be rather nice if he payed for developing a native encoder though
[15:49:27] <mru> it's not quite as bad as alsa
[15:49:35] <spaam> KotH: i like "even you" part ;D
[15:50:17] <spaam> kshishkov: hehe :) but do you think KotH can do it?:)
[15:50:18] <KotH> spaam: you arent so stupid taht you cannot hit the right keys on a kbd -> given enough money and time, even you can do it
[15:50:42] <mru> million monkeys, serial version
[15:50:44] <KotH> spaam: even if it needs a damn lot of money and more than hundred years
[15:50:58] <spaam> haha
[16:04:16] <KotH> how was that CCD -> RGB recoding process called?
[16:04:31] <KotH> CCD = CCD data
[16:05:13] <reynaldo> didn't know that existed as a named process
[16:15:20] <mru> KotH: bayer?
[16:17:37] <KotH> mru: demosaicing
[16:26:09] <KotH> does anyone here have any knowledge of the MIPI camera interface?
[16:34:42] <mru> sounds almost like midi
[16:34:49] <mru> musical instrument picture interface?
[16:34:55] <_av500_> almost
[16:35:11] <_av500_> KotH: i know mipi for displays
[16:35:18] <mru> _av500_: just reverse it then
[16:35:22] <_av500_> yes
[16:35:28] <_av500_> ipin
[16:35:31] <_av500_> ipim
[16:35:48] <KotH> _av500_: i could find very little information on it
[16:35:50] <_av500_> KotH: put GND to VCC and VCC to GND
[16:36:04] <KotH> _av500_: what kind of interface is it? how does it look like electrically? how logically?
[16:36:28] <_av500_> we use mipi sdi
[16:36:31] <_av500_> dsi
[16:36:35] <_av500_> mipi dsi
[16:36:36] <_av500_> serial
[16:37:01] <_av500_> omap3 trm has something about it
[16:37:07] <mru> hdcp over rs232
[16:37:54] <_av500_> KotH: ping me in office tomorrow
[16:45:14] <reynaldo> KotH: do you know how to calculate the reflector 'mesh' optimum spacing giving a desired frequency/wavelength range and a desing like the one descrived here?
[16:45:17] <reynaldo> http://uhfhdtvantenna.blogspot.com/
[16:45:55] <reynaldo> also the spacing between the reflector and the halfwave dipoles array, guess one should take that into account too
[16:46:22] <_av500_> yes
[16:46:42] <_av500_> ask a HAN
[16:46:49] <_av500_> HAM
[16:46:54] <reynaldo> I built one and I'm geting enough signal to be able to tune but the reception can still be greatly improved, I guess that adding a reflector might help
[16:47:59] <reynaldo> _av500_: oh, KotH is my EE of choice, has been for years
[16:49:32] <_av500_> im EE too, but have no idea about antenna design
[16:51:10] * mru has no idea about antenna design anymore
[16:51:29] <mru> there was something elegant about it
[16:51:53] <reynaldo> I think that reflector mesh interspacing is not rocket science, I thinnk to remember you can easily calculate it from wavelenght without knowing too much about antenna design
[16:52:10] <reynaldo> I thinnk/I seem
[16:54:44] <reynaldo> mru: sure, up to the point you put it somewhere visible :D
[16:55:48] <mru> one of the professors teaching that stuff was apparently particularly interested in physical manifestations of antennas
[16:55:57] <mru> to the point where he'd go around town taking pictures of them
[16:56:30] <mru> once he got in a bit of trouble when he was seen taking pictures of the antennas of some secret military installation
[16:56:52] <mru> he had no idea what it was, just thought their antenna looked interesting
[16:57:06] <KotH> _av500_: ack.. thanks!
[16:57:08] * j0sh thinks disgused cell phone towers are really cool
[16:57:29] <mru> disgusted?
[16:57:36] <j0sh> disguised*
[16:58:06] <KotH> reynaldo: uhm.. i could look it up, but i dont know it from the top of my head
[16:58:19] <KotH> reynaldo: i've never done any antenna design, but i've enough books :)
[16:59:16] <reynaldo> KotH: please do, I will keep googling while I wait
[16:59:20] <reynaldo> Its nothing urgent
[16:59:25] <mru> the only antenna I've ever designed and put to use consisted of a 10m wire to a tree
[16:59:55] <reynaldo> a random wire antenna?
[17:00:04] <mru> not random
[17:00:12] <reynaldo> I recently discovered thats an actual design
[17:00:14] <mru> it was exactly the wire I had at home that was long enough
[17:00:28] <kshishkov> the best kind of wire indeed
[17:01:09] <reynaldo> hi kshishkov
[17:02:27] <mru> http://www.theonion.com/video/new-apple-friend-bar-gives-customers-someone-to-ta,17693/
[17:02:33] <KotH> reynaldo: rothammel says 0.65\lambda for highest gain, usually between 0.1 and 0.3, at ca 0.2 you get very little influence on the antenna impedance
[17:04:15] <reynaldo> KotH: got it, then I guess one should aim for 0.2 if building a custom matching transformer its not desired
[17:04:39] <KotH> the impedance of the antenna is mostly dependent on the design of the elements
[17:05:08] <KotH> i could give you there hints too, but i'd have to read more on that kind of stuff
[17:05:23] <KotH> btw: isnt there any english equivalent of the rothammel?
[17:05:28] <reynaldo> that antenna is supposed to have 300 Ohms impedance, but I don't know if thats calculated or they are just whishfully threating it like a halfwave dipole
[17:05:49] <reynaldo> KotH: dunno
[17:07:25] <KotH> eh.. no
[17:07:30] <KotH> there is no ^^
[17:08:06] <KotH> maybe the arrl antenna book, but it looks rather thin
[17:09:43] * KotH puts it on his to buy list anyways
[17:16:25] <reynaldo> he, I found a neat fractal antenna design. I will try it out
[17:16:33] <reynaldo> http://www.instructables.com/id/How-to-make-a-fractal-antenna-for-HDTV-DTV-plus-/
[17:24:25] * KotH wouldnt trust an antenna design that has not been tested and measuremed by someone who knows his stuff
[17:26:39] <reynaldo> I'd trust whatever I can get to work well, antenna design has too much black magic into it
[17:26:59] <mru> nah, it's just maxwell's equations
[17:27:00] <reynaldo> for a mortal being like myself that is :)
[17:27:48] <KotH> mru: antenna simulation is still a lot of black magic
[17:28:11] <KotH> very few simulation tools get actually the right gain
[17:28:17] <KotH> most are 10-20% off
[17:28:24] <KotH> if not 50%
[17:32:29] <mru> does this look about right?  pcm_test_deps=$(echo pcm_{{a,mu}law,u8,s8,{s{16,24,32},f{32,64}}{be,le},s24daud,zork}_{en,de}coder)
[17:33:20] <KotH> it looks cryptic
[17:34:15] <mru> but much more compact than listing them all separately: pcm_alaw_encoder pcm_alaw_decoder pcm_mulaw_encoder pcm_mulaw_decoder pcm_u8_encoder pcm_u8_decoder pcm_s8_encoder pcm_s8_decoder pcm_s16be_encoder pcm_s16be_decoder pcm_s16le_encoder pcm_s16le_decoder pcm_s24be_encoder pcm_s24be_decoder pcm_s24le_encoder pcm_s24le_decoder pcm_s32be_encoder pcm_s32be_decoder pcm_s32le_encoder pcm_s32le_decoder pcm_f32be_encoder pcm_f32be_decoder pcm_f32le_encoder pc
[17:34:30] <pJok> mru, you got cut off there
[17:34:39] <mru> doesn't matter
[17:34:47] <mru> only proves my point
[17:50:19] <BBB> mru: [su]8 instead of s8,u8?
[17:50:23] <BBB> both 5 characters though...
[17:50:28] <CIA-99> ffmpeg: michael * r24114 /trunk/libavutil/random_seed.c: Change i to unsigned in get_generic_seed()
[17:53:46] <mru> BBB: not the same thing
[17:53:52] <mru> this is not pattern matching
[17:56:32] <CIA-99> ffmpeg: diego * r24115 /trunk/libavcodec/cook.c: Improve variable names in imlt_window_float() and mlt_compensate_output().
[18:07:40] <Vitor1001> mru: Any news on the new FATE?
[18:07:49] <mru> no
[18:09:36] <Vitor1001> mru: Would you ok a "make fate2" target?
[18:09:48] <mru> depends on what it did
[18:10:04] <Vitor1001> Same thing as "make fate" but for tests not in Mike's database.
[18:10:14] <mru> like what?
[18:10:31] <Vitor1001> mp3 fixed point
[18:10:39] <Vitor1001> http://wiki.multimedia.cx/index.php?title=FATE_Test_Coverage#TODO
[18:11:09] <Vitor1001> And first and foremost giving people the ability to add a test to it when mike is busy.
[18:12:00] <mru> s/when mike is busy//
[18:12:21] <Vitor1001> yes, exactly.
[18:13:33] <Vitor1001> So? Are you fine with it in principle as the build (and test) system maintainer?
[18:14:12] <DonDiego> we should move away from mike's fate
[18:14:20] <CIA-99> ffmpeg: michael * r24116 /trunk/libavutil/random_seed.c: Fix infinite loop with clock() returning (clock_t)-1.
[18:14:26] <Vitor1001> DonDiego: Looks more a long term goal.
[18:14:32] <DonDiego> we're at the whim of a single dev there
[18:15:24] <Vitor1001> DonDiego: How many times we needed to add a test and didn't because of it? If there were a "make fate2", we could at least add all that stuff there.
[18:15:37] <DonDiego> yes, excellent first step
[18:15:44] <Vitor1001> DonDiego: And try to convince mike to run "make fate2" in his farm.
[18:15:44] <DonDiego> everybody should be able to run fate locally
[18:15:54] <DonDiego> once that is done, doing the web stuff becomes trivial
[18:16:55] <Vitor1001> I agree... I'll look at this patch.
[18:17:40] <mru> not trivial, but it can be done later
[18:17:54] <mru> anyway, I'm messing with the regtests right now
[18:18:40] <Vitor1001> mru: So, do I give a try at it or do you want to try first?
[18:19:06] <mru> I'm in the middle of a cleanup operation right now
[18:19:14] <mru> anything you do now might not apply in 10 minutes
[18:19:33] <Vitor1001> ok.
[18:19:45] <Vitor1001> But looking at the Makefile, it sounds _really_ trivial :D
[18:20:04] <mru> I never said it was hard
[18:20:26] <mru> but there's a difference between grafting something on and properly integrating it
[18:28:28] <DonDiego> BBB: got you!
[18:28:51] <DonDiego> BBB: you introduced the bug i am flaming about with michael in r18351
[18:32:31] <Vitor1001> mru: Well, besides that, would you complain to use the following patch to test float codecs: http://ffmpeg.pastebin.com/kFBsVDxf ? Or do you find parsing the string too ugly?
[18:33:28] <Vitor1001> MAXDIST == 1 meaning no regression
[18:34:50] <mru> svn is evil
[18:35:07] <mru> it doesn't let me replace a directory with a file previously inside the directory
[18:35:24] <mru> git handles it no problem
[18:39:18] <DonDiego> what file would that be?
[18:40:05] <BBB> DonDiego: remove the comment
[18:40:16] <BBB> DonDiego: it's a static function where the pointer prototype already contains the comment
[18:40:19] <BBB> the comment is thus duplicate
[18:44:47] <CIA-99> ffmpeg: mru * r24117 /trunk/tests/ref/ (vsynth1/yuv vsynth2/yuv vsynth1/rgb vsynth2/rgb):
[18:44:47] <CIA-99> ffmpeg: regtest: put rgb and yuv reference files in correct place
[18:44:47] <CIA-99> ffmpeg: SVN design flaw requires deleting dirs in separate step
[18:44:47] <CIA-99> ffmpeg: mru * r24118 /trunk/tests/ref/ (vsynth1/yuv vsynth2/yuv vsynth1/rgb vsynth2/rgb): regtest: put rgb and yuv reference files in correct place
[18:44:51] <CIA-99> ffmpeg: mru * r24119 /trunk/configure:
[18:44:52] <CIA-99> ffmpeg: configure: add print_enabled() function
[18:44:52] <CIA-99> ffmpeg: The print_enabled() function prints all elements in a list which
[18:44:52] <CIA-99> ffmpeg: are enabled.
[18:44:52] <CIA-99> ffmpeg: mru * r24120 /trunk/ (Makefile configure):
[18:44:52] <CIA-99> ffmpeg: Move regression test dependencies to configure
[18:44:53] <CIA-99> ffmpeg: This allows expressing complex dependencies more easily.
[18:44:53] <CIA-99> ffmpeg: mru * r24121 /trunk/Makefile: Simplify regtest reference makefile dependencies
[18:45:52] * mru feels somewhat sorry for thilo
[18:46:09] <BBB> poor guy
[18:46:55] <mru> lol, svn dumped core
[18:47:16] <CIA-99> ffmpeg: diego * r24122 /trunk/Doxyfile: Do not generate documentation for .d files; they do not contain source code.
[18:47:24] <DonDiego> BBB: suggest that to thilo, he just volunteered to fix the issue(s)
[18:48:13] <BBB> well, I fixed wmavoice/vp8
[18:48:21] <BBB> did you figure out how to fix the remaining wmavoice issues?
[18:48:26] <BBB> according to the docs, I do it correctly
[18:48:42] <DonDiego> yes, saw it, thx
[18:50:04] <DonDiego> are you sure you are looking at the docs for the correct version of doxygen?
[18:50:15] <DonDiego> and where are those docs?
[18:51:30] <BBB> what you just told me in privmsg a few hours ago
[18:58:20] <DonDiego> BBB: do you need those explicit links?
[19:25:33] <DonDiego> the evil overlord has spoken: i must bend to his democratic powers or be gone...
[19:37:06] <DonDiego> i'm out for a beer in the sun
[19:37:12] <DonDiego> keep flaming without me ;)
[19:41:47] <mru> whaaaat???? debian /bin/sh doesn't support {} substitution
[19:50:13] <Rathann> isn't it dash nowadays?
[20:00:40] <mru> grmbl, it's not actually standard
[20:00:46] * mru should check better next time
[20:02:27] * Dark_Shikari reminds the arm people that x264 now needs new chroma MC asm
[20:02:32] <Dark_Shikari> and ppc
[20:02:41] <Dark_Shikari> (we're committing the patch to convert the internals to nv12)
[20:03:18] <mru> interesting
[20:03:54] <Dark_Shikari> it reduces L1 cache misses by 10% on x86
[20:04:25] <Dark_Shikari> ~1% overall performance boost
[20:04:33] <Dark_Shikari> ~4% on a Secret Chip With Less Cache.
[20:08:08] <Vitor1001> mru: you own me a beer
[20:08:16] <Vitor1001> ;)
[20:08:25] <mru> Vitor1001: can you prove there is _no_ system without abs()?
[20:08:39] * mru goes off to make a bsd fork without abs
[20:08:40] <Vitor1001> none that ffmpeg compiles...
[20:08:47] <Dark_Shikari> lol
[20:11:00] <mru> Vitor1001: but sure, I'll buy you a beer next time
[20:12:02] <Vitor1001> mru: Yeah, last time in paris we barely met...
[20:16:43] <CIA-99> ffmpeg: mru * r24123 /trunk/configure:
[20:16:43] <CIA-99> ffmpeg: configure: fix pcm test deps
[20:16:43] <CIA-99> ffmpeg: 10l to me for using non-standard shell syntax
[21:10:36] <Vitor1001> mru: That's what I mean with fate2 tests: http://ffmpeg.pastebin.com/gq0fUWac . What do you think?
[21:21:14] <mru> it's a bit hackish in some parts
[21:21:22] <mru> let's try to make it better
[21:58:09] <CIA-99> ffmpeg: bcoudurier * r24124 /trunk/libavformat/movenc.c:
[21:58:10] <CIA-99> ffmpeg: In mov muxer, write pixel aspect ratio tag in mov files.
[21:58:10] <CIA-99> ffmpeg: Based on a patch by Daniel Kristjansson, danielk at cuymedia dot net
[22:04:42] <CIA-99> ffmpeg: bcoudurier * r24125 /trunk/libavformat/mpegtsenc.c: In mpegts muxer, print VBR instead of dummy 1 when displaying muxrate
[22:23:21] <CIA-99> ffmpeg: stefano * r24126 /trunk/ (3 files in 2 dirs): Reindent after r24101.
[22:36:34] <CIA-99> ffmpeg: mru * r24127 /trunk/ (Makefile tests/seek-regression.sh tests/regression-funcs.sh): Change names of regtest output files to closer match the reference files
[22:40:45] <BBB> hm...
[22:40:52] <BBB> a segfault in fft_sse
[22:40:54] <BBB> :(
[22:42:24] <CIA-99> ffmpeg: mru * r24127 /trunk/ (Makefile tests/seek-regression.sh tests/regression-funcs.sh): Change names of regtest output files to closer match the reference files
[22:42:24] <CIA-99> ffmpeg: stefano * r24128 /trunk/libavutil/avutil.h:
[22:42:24] <CIA-99> ffmpeg: Bump minor after read/write_line() to av_read/write_image_line()
[22:42:24] <CIA-99> ffmpeg: rename, done in r24101.
[22:42:44] <CIA-99> ffmpeg: stefano * r24129 /trunk/doc/APIchanges: Update APIchanges after the recent avfilter.h and pixdesc.h changes.
[22:55:13] <CIA-99> ffmpeg: stefano * r24130 /trunk/doc/APIchanges: Perform minor style fixes.
[23:04:29] <mru> Vitor1001: still awake?
[23:04:38] <Vitor1001> mru: yes
[23:04:41] <Vitor1001> way too hot here
[23:06:15] <mru> for the off-by-one test, don't we need to set the threshold to 2 to be safe?
[23:06:25] <Vitor1001> why?
[23:06:38] <mru> in case the reference happens to be created on a machine that goes one way from some ideal and the tested system goes the other way
[23:06:40] <Vitor1001> Anyway, the threshold is a parameter of the function ($3)
[23:07:20] <Vitor1001> It is more based in testing. Mike tested and saw one is enough
[23:07:31] <mru> his testing was limited
[23:07:38] <Vitor1001> we just set it to the most restrictive that pass in all boxes.
[23:07:50] <Vitor1001> for instance, for amr, I think we will need way more than 1.
[23:08:16] <mru> well, then it's not really one-off anymore...
[23:08:32] <mru> in some cases it may be better to look at psnr
[23:08:41] <Vitor1001> Well, Mike called it this way and the name stick ;)
[23:08:57] <mru> it also depends on where the reference came from
[23:09:00] <Vitor1001> I think that while it is off by just one, it is better to look at it than psnr.
[23:09:19] <mru> sure, if it's off by one only
[23:09:29] <mru> but you said amr might need much more
[23:09:47] <Vitor1001> Yes, I have no good idea atm to test amr.
[23:10:21] <Vitor1001> But twinvq, mp3float, mp2float, mp1float, sipr, ra288, binkaudio, should be fine
[23:10:46] <Vitor1001> ok, maybe not ra288, but certainly everything not celp-related.
[23:11:02] <Vitor1001> The full list:
[23:11:19] <Vitor1001> ATRAC3, RealAudio Cooker, DCA (DTS), IMC, Musepack SV7 & SV8,  Nellymoser, QDesign,  Truespeech, Vorbis, WMA v1,  ATRAC1, WMAPro, TwinVQ, BinkAudio and float MP3 decoder
[23:11:37] <mru> anything using pseudo-random noise generators will depend on the implementation use to create the reference
[23:12:14] <Vitor1001> everything using a pseudo-random generator uses by now a integer-based prng with a fixed initial seed.
[23:12:25] <mru> yes, _our_ decoders do that
[23:12:34] <mru> if we use some official reference we don't know what it used
[23:13:00] <mru> like the aac test suite
[23:13:05] <Vitor1001> Ahh, my code is supposed to compare with a ffmpeg output "known work fine"
[23:13:13] <Vitor1001> test suites are a different thing.
[23:13:49] <Vitor1001> The goal is to catch an "optimization" that reduces quality of a few percent
[23:14:16] <Vitor1001> Like forgetting to properly round the last sample of each frame or something
[23:14:40] <Vitor1001> It is just to catch regressions.
[23:18:18] <mru> when official test suites exist we should try to use them
[23:19:27] <Vitor1001> I'm not sure. I normally like to know when a commit changed a file of more that -+1, even though it is officially still pass the tests.
[23:40:08] <CIA-99> ffmpeg: diego * r24131 /trunk/libavcodec/ (escape124.c fraps.c rl2.c): Add back previously removed non-existing function params in doxygen comments.
[23:51:59] <mru> Vitor1001: ok, here's my idea of how to do it: http://git.mansr.com/?p=ffmpeg.mru;a=summary
[23:52:24] <Vitor1001> I don't get the point of your last message.
[23:52:39] <mru> meta-not-getting-the-point...
[23:52:40] <Vitor1001> How else do you want to add a test instantly, with no intervention from mike?
[23:52:49] <mru> make fate-$newtest
[23:53:09] <mru> or plain old "make fate" which would include both mike's tests and the extras
[23:53:16] <Vitor1001> That work locally.
[23:53:35] <Vitor1001> I want it also to run in mike's ppc box in his basement that runs fate.
[23:53:52] <Vitor1001> As soon as I commit it.
[23:54:24] <mru> that's why we need to replace mike in the not-too-long term
[23:54:35] <mru> replace him with a script
[23:54:50] <Vitor1001> Yes, and in the very short term, I suggest "make fate2".
[23:55:10] <mru> anyway, separating those targets is easy to do or not do
[23:55:11] <Vitor1001> Three years ago, we were going to use lavfi in the not-too-long term too
[23:55:22] <mru> what do you think of the commits in my git?
[23:55:30] <Vitor1001> I like all of it.
[23:55:54] <Vitor1001> Where is the output file written?
[23:56:06] <mru> somewhere under tests/
[23:56:20] <mru> tests/data/fate/ apparently
[23:56:47] <mru> maybe we should delete the output afterwards
[23:56:48] <Vitor1001> I wanted to use a pipe to avoid it.
[23:56:51] <Vitor1001> Yes.
[23:56:57] <Vitor1001> At least in make clean
[23:57:02] <mru> it already does
[23:57:23] <Vitor1001> nice
[23:57:33] <mru> how about deleting the output on success and keeping it on failure?
[23:57:43] <mru> if it fails, you'll probably want to look at it
[23:57:54] <Vitor1001> Looks a good idea.
[23:58:12] <Vitor1001> BTW, "make V=2 fate" has atm the same effect as "make fate"
[23:58:23] <mru> iKnow
[23:58:33] <Vitor1001> When a test fails, I normally run it again with V=2 and then cut and paste it.
[23:58:54] <mru> I've done the same on occasion...
[23:59:02] <mru> I can fix that for fate
[23:59:37] <Vitor1001> That would be nice, but not really urgent.