[FFmpeg-devel-irc] IRC log for 2010-03-04

[irc at mansr.com]

[00:28:45] <CIA-92> ffmpeg: stefano * r22191 /trunk/libavutil/pixdesc.c: (log message trimmed)
[00:28:46] <CIA-92> ffmpeg: Declare the PIX_FMT_GRAY8 pixel format as a paletted format. This is
[00:28:46] <CIA-92> ffmpeg: consistent with the allocation currently done for PIX_FMT_GRAY8
[00:28:46] <CIA-92> ffmpeg: pictures.
[00:28:46] <CIA-92> ffmpeg: No significant slow-downs have been measured.
[00:28:46] <CIA-92> ffmpeg: See the thread:
[00:28:47] <CIA-92> ffmpeg: Subject: [FFmpeg-devel] [PATCH] Is gray8 a paletted format?
[00:34:15] <mru> monty joins the fray: http://news.slashdot.org/comments.pl?sid=1570150&cid=31351360
[00:38:57] <j-b> you didn't see that one?
[00:39:15] <mru> didn't have time to read it until now
[00:39:17] <j-b> "Mans is a bad guy that doesn't like me"
[00:39:33] <j-b> that why he says that
[00:39:33] * mru has been busy enough keeping server alive
[00:40:03] <mru> and eating, and reading email, and updating that blasphemous article, etc
[00:40:14] <j-b> "Ogg was designed to stream, mkv was not."
[00:40:30] <mru> mkv was designed in a way that allows it
[00:40:34] <mru> ain't that enough?
[00:41:39] <j-b> "your arguments are not valid, you just don't like me"
[00:41:41] <j-b> pfff
[00:42:06] <mru> I expected nothing less from him
[00:42:17] <mru> but hopefully someone read it and learned something
[00:42:56] * Yuvi learned that 2004 was recently
[00:43:38] <Yuvi> and that ogg was widespread in 1996
[00:43:38] <mru> ?
[00:43:47] <j-b> lol :D
[00:43:56] <j-b> and that H264 is less good than Theora
[00:43:59] <mru> the first I heard of ogg was around 2000
[00:44:13] <Yuvi> "mkv's not been able to interleave until just recently" but maybe he's talking about something else
[00:44:26] <mru> I don't get that bit
[00:44:31] <mru> what is a mux if not interleaved?
[00:45:08] <Yuvi> avi, mov, mxf can be non interleaved
[00:45:55] <Yuvi> if you put all the audio packets before the video packets or something
[00:46:02] <Yuvi> I think one mxf-based spec even requires
[00:46:07] <Yuvi> it
[00:46:17] <j-b> is mxf royalty-free ?
[00:46:24] <mru> if you put the audio and video separately mp4 can get a *really* low overhead
[00:48:11] <Yuvi> timeline wise, vorbis started sometime around 1993, but wasn't standardized until 1998-2000 (when ogg was split off with basically no modifications)
[00:48:31] <Yuvi> mkv started sometime around 2002 and was basically done in 2003-4
[00:48:31] <mru> vorbis wasn't available to the masses until ~2001
[00:48:40] <mru> ogg was irrelevant before that
[00:48:47] <Yuvi> nut started 2003 and was finalized 2006
[00:48:53] <Yuvi> so they're all pretty close
[00:51:41] <mru> I added a mention of ASF
[00:51:46] <mru> that'll tickle 'em...
[00:51:57] <j-b> ASF isn't bad :)
[00:52:37] <mru> no, I just had a look at the spec and it's quite reasonable
[00:52:56] <j-b> it works pretty fine for streaming (ogg doesn't... chained-ogg)
[00:53:03] <mru> it's a bit microsofty of course...
[00:53:04] <j-b> it works pretty fine for file playback
[00:53:14] <j-b> and it can even have h264 in it :)
[00:53:19] <j-b> "I'd love to see your analysis of the Matroska container format."
[00:53:32] <mru> I should start charging money for these
[01:01:54] <iive> mru: actually there are very nice replies to that comment, unfortunately they are (still) low score. I wonder is john is hanging around here.
[01:02:12] <mru> yeah, I saw some positive replies too
[01:03:45] <mru> btw, 23% of the traffic to my blog is from google chrome
[01:03:51] <peloverde> mru: did the site just go down?
[01:04:04] <CIA-92> ffmpeg: michael * r22192 /trunk/libavcodec/h264.h: Optimize *_type init, 1.5 cpu cycles faster.
[01:04:05] <mru> it glitched
[01:09:11] <peloverde> the retards are out on full force spamming that entry about H.264 licensing
[01:09:32] <peloverde> sometimes I wonder if they are disingenuous or stupid or both
[01:12:00] <mru> who is TFA?
[01:15:07] <peloverde> any idea why the mpeg-4 systems patent pool shut down?
[01:15:21] <mru> part 1?
[01:15:59] <mru> everybody realised it was the worst spec ever written and used something else
[01:16:27] <peloverde> part 1 is still based on part 12
[01:16:35] <mru> part 1 can't be based on part 12
[01:16:39] <mru> part 12 is newer
[01:16:52] <mru> part 12 is the tiny sane subset of part 1
[01:17:03] <mru> rewritten in a way that can actually be understood
[01:17:06] <peloverde> part1 is the so-called mp4v1
[01:17:22] <mru> maybe they "backported" it
[01:19:02] <peloverde> Part 1 describes itself among other things as "a file format to contain the media information of an ISO/IEC 14496 presentation in a flexible, extensible format to facilitate interchange, management, editing, and presentation of the media specified in part 12 (ISO File Format), part 14 (MP4 File Format) and part 15 (AVC File Format) of ISO/IEC 14496"
[01:19:22] <mru> that must be from a revised version
[01:19:30] <peloverde> yes
[01:19:32] <mru> the original from ~2002 can't have said that
[01:19:40] <mru> the parts stopped at 6 or so then
[01:19:50] <peloverde> -14 still makes reference to -1 boxes
[01:20:15] <peloverde> -1 is still a mess
[01:21:02] <peloverde> also I think the parts stopped at 7 then
[01:21:21] <peloverde> because -7 is the weird mpeg-4 visual reference hardware
[01:21:54] <mru> I've never looked at 4-9
[01:22:19] <peloverde> -4 and -5 are critically important, reference software and conformance
[01:22:19] <mru> except whichever one is conformance testing
[01:22:50] <peloverde> they recently split audio conformance out into -26
[01:23:57] <peloverde> I have mixed feelings about that, when others were buying specs for me, getting things bundled was nice but split makes it easier to find things
[01:24:32] <peloverde> now they just need to split -3
[01:25:57] <peloverde> most of the patents on -1 are post 2000 which makes me think they are probably on weird mpeg-4 boxes that no one uses
[02:01:02] <CIA-92> ffmpeg: michael * r22193 /trunk/libavcodec/h264.h:
[02:01:02] <CIA-92> ffmpeg: Port Optimizations about *_type init from decode to filter code.
[02:01:02] <CIA-92> ffmpeg: 1 cpu cycle faster
[02:26:31] <mru> http://linuxhaters.blogspot.com/2010/03/tale-of-ogg.html
[02:31:40] <CIA-92> ffmpeg: alexc * r22194 /trunk/libavcodec/aac_ac3_parser.c:
[02:31:40] <CIA-92> ffmpeg: AAC parser: Don't write channels, sample rate, and frame size each frame.
[02:31:40] <CIA-92> ffmpeg: Thanks to backwards compatible HE-AAC signalling these values are unreliable.
[02:33:37] <CIA-92> ffmpeg: alexc * r22195 /trunk/libavcodec/aac_ac3_parser.c: Cosmetics: Re-indent after last commit.
[02:34:29] <peloverde> ^one step closer to SBR o.O
[03:07:25] <peloverde> HE-AAC try 5 sent :)
[03:18:38] <mru> http://embed.cs.utah.edu/embarrassing/jan_10/harvest/
[03:21:09] <ohsix> heh why did they bother with percentages
[03:21:19] <peloverde> This is the real reason to use clang: http://zi.fi/shots/clang.png
[03:26:11] <peloverde> Sadly for people stuck on x86-32 llvm 2.7 will probably still have shitty x87 support
[03:29:56] <mru> I'd rather not have the compiler second-guess what I might have meant
[03:30:48] <ohsix> what about the other 95%
[03:30:54] <peloverde> It's an error, not a warning, it still needs to be fixed for compilation to be successful
[03:31:22] <ohsix> oh nm, clang screenshot
[03:31:26] <mru> I've seen enough people who'd just do what the compiler suggests, right or wrong
[03:31:50] <mru> better not suggest anything, let the programmer figure out what's wrong
[03:32:04] <ohsix> same, its an old horror story from the vms + pl/i era too
[03:32:31] <ohsix> pl/i tried to tell you a _lot_ about errors that was applied verbatim heh
[03:32:43] <peloverde> I have trouble finding typos, I think I'm slightly dyslexic, seeing to two words above and below each other is a huge help
[03:33:02] <ohsix> and one of the versions on vms would automatically do it for you & mask that there ever was one
[03:33:08] <mru> if the compiler says an identifier is undeclared I'll double-check it
[03:38:15] <pengvado> "people stuck on x86-32" <-- does that mean stuck on x86-32 that are old enough to not have sse?
[03:38:55] <mru> or x86-32 systems using x87 parameter passing
[03:39:07] <ohsix> does clang use levenshtein distance or what to propose that correction
[03:42:52] <mru> it doesn't do it at all here
[03:48:00] <ohsix> heh http://embed.cs.utah.edu/embarrassing/jan_10/harvest/compare_suncc-5.10_gcc-head/
[04:02:41] <astrange> http://embed.cs.utah.edu/embarrassing/jan_10/harvest/compare_suncc-5.10_gcc-head/compare_A78EA1EC_disasm.shtml ??
[04:06:50] <mru> mov    %eax,0x0 ??
[04:07:09] <mru> omg, the value of zero changed!
[04:07:53] <ohsix> its radiation protection!!11
[04:08:10] <mru> seriously, wtf is that?
[04:08:47] <ohsix> probably droppings from one of the compiler passes after the one that removes null side effects
[04:09:01] <astrange> probably (0x0)
[04:09:04] <astrange> and that might be a relocation
[04:09:22] <ohsix> oh, good point
[04:09:37] <mru> absolute memory addressing?
[04:09:49] <ohsix> arg in fact i have some junk to look at again in light of that; didn't think about fixups
[04:11:20] * mru guesses there's a volatile global involved
[04:11:25] <mru> *never* use volatile
[04:11:28] <mru> it's always wrong
[04:11:56] <ohsix> the code for the case is there with the assembly
[04:12:15] <Dark_Shikari> mru: no, there are plenty of correct cases for volatile with multithreading
[04:12:28] <mru> Dark_Shikari: no
[04:12:46] <mru> volatile is nuking ants
[04:12:49] <Dark_Shikari> while( !flag ) {sleep();}
[04:12:53] <Dark_Shikari> you must say flag is volatile
[04:13:11] <mru> you shouldn't be doing that
[04:13:19] <Dark_Shikari> yes you shouldn't be doing spinlocks
[04:13:21] <mru> you should make sleep() and optimisation barrier instead
[04:13:31] <Dark_Shikari> so I have to modify the compiler?
[04:13:43] <mru> no
[04:13:48] <mru> just define some macros
[04:13:51] <Dark_Shikari> there are no cross-platform optimization barriers
[04:13:52] <Dark_Shikari> they do not exist
[04:13:58] <Dark_Shikari> there are no cross-platform memory fences
[04:14:07] <Dark_Shikari> welcome to our shitty world.
[04:14:08] <mru> an optimisation barrier in gcc is trivial: __asm__ volatile ("")
[04:14:24] <Dark_Shikari> wrong
[04:14:28] <Dark_Shikari> volatile does not mean it won't reorder
[04:14:33] <Dark_Shikari> it means it won't remove it if the output isn't used
[04:14:42] <Dark_Shikari> GCC can and does reorder volatile asm blocks
[04:14:50] <mru> never seen it do that
[04:14:53] <Dark_Shikari> I have
[04:15:06] <astrange> it will reorder scalar operations around them
[04:15:14] <ohsix> i remember an old thread on their ml about it doing that
[04:15:15] <mru> on the contrary, I've seen the presense of an asm block turn off lots of optimisation in that area
[04:15:24] <astrange> it won't reorder memory accesses around asm volatile ("" ::: "memory")
[04:15:29] <astrange> (i think)
[04:15:34] <mru> it ought not
[04:15:51] <mru> either way, you'll need proper hw memory barriers too
[04:16:10] <ohsix> the "all of memory is tainted" flag is newish isn't it? or was that for the stack
[04:16:28] <mru> memory clobbers don't usually apply to the stack
[04:16:33] <mru> which makes some kind of sense
[04:17:14] <ohsix> i just remember that recently a pseudoclobber was added recently for asm(), might be related; don't remember exactly what it pertained too
[04:19:58] <ohsix> theres some junk about reordering in the docs; Similarly, you can't expect a sequence of volatile asm instructions to remain perfectly consecutive. If you want consecutive output, use a single asm. Also, GCC will perform some optimizations across a volatile asm instruction; GCC does not “forget everything” when it encounters a volatile asm instruction the way some other compilers do.
[04:21:08] <mru> declaring variables volatile is still overkill in almost all situations
[04:22:33] <ohsix> oh nevermind; it was "cc", and not on x86
[04:23:21] <ohsix> re: memory clobber; If your assembler instructions access memory in an unpredictable fashion, add `memory' to the list of clobbered registers. This will cause GCC to not keep memory values cached in registers across the assembler instruction and not optimize stores or loads to that memory. You will also want to add the volatile keyword if the memory affected is not listed in the inputs or outputs of the asm, as the `memory' clobber does not count as a side
[04:56:40] <peloverde> Does configure work around clang having issues with out inline ASM or does clang actually build it now?
[04:59:38] <CIA-92> ffmpeg: alexc * r22196 /trunk/libavcodec/aac.c:
[04:59:39] <CIA-92> ffmpeg: AAC: Mark predictor functions av_always_inline.
[04:59:39] <CIA-92> ffmpeg: This results in a 50% speedup on main profile with no increase in binary size.
[05:00:07] <drv> wow
[05:01:23] <ohsix> req: cache footprint info as result of change
[05:03:09] <peloverde> ohsix: How can I get that?
[05:04:12] <ohsix> valgrind has a module to do it, but there are also perf counters on any recent cpu that'll let you count flushes or "bad" events and count them
[05:04:53] <ohsix> valgrind can emulate different cache sizes and junk though
[05:06:59] <ohsix> http://valgrind.org/docs/manual/cg-manual.html
[05:07:57] <ohsix> thats for hypothetical configs and annotation; you'd still probably want to use oprofile as well
[05:09:33] <ohsix> sudo opcontrol --init ; opcontrol -l will show all the events you can count on your cpu
[05:09:34] <peloverde> Does inline a function only called one place really have a signficant cache impact?
[05:10:16] <peloverde> And does inlining a function that is six fp-ops really have a significant cache impact?
[05:10:46] <ohsix> not unless its already close to overunning the cache already, but cache sizes vary, and it could impact the devices with small caches; you can find a lower bound though
[05:12:07] <ohsix> but still, unless you measure you never know where it is :P
[05:14:10] <ohsix> mru: apparently gcc will insert dup loads and movs to align things too
[05:15:05] <ohsix> at least; the docs for cachegrind seem to suggest as much
[05:32:26] <peloverde> ohsix: according to cachegrind my I1 miss rate increased from 0.10% to 0.12% and my D1 misrate increased from 2.0% to 2.2%
[05:34:07] <ohsix> nice, with the sizes it inferred from your cpu?
[05:34:55] <ohsix> it uses cpuid to read em' and use them as defaults
[05:39:20] <ohsix> btw thanks for looking, i'm not set up to check those things myself atm
[05:46:20] <peloverde> which whatever the defaults from my cpu were
[05:46:45] <ohsix> can you try with half & quarter what your cpu is?
[06:01:13] <bcoudurier> hi guys
[06:03:46] <peloverde> ohsix: results were comparable for quarter cache
[06:03:58] <ohsix> hm, nice
[06:04:28] <ohsix> what was quarter anyways? in l1/d1
[06:04:39] <superdump> hey bcoudurier
[06:05:30] <ohsix> and did cachegrind say it was actually using the cache sim :>
[06:06:45] <peloverde> I fed it the --I1, --D1, --L2 arguments and the numbers were different this time so it did something different
[06:07:00] <ohsix> oic
[06:07:23] <peloverde> 0.38%->0.39% and 2.9%->3.1%
[06:07:35] <peloverde> that's why I said comparable and not the same
[06:08:18] <ohsix> how big were they for the quarter?
[06:09:43] <peloverde> my quarter cache sizes are I1 8192 D1 8192 L2 1048576
[06:12:30] <ohsix> the l2 on the p3 was only 512k, so testing that is probably not much different
[06:13:04] <ohsix> at least the ones that ran at half clock speed :P later was only 256kb
[06:15:40] <ohsix> k6-2 only had 32k/32k for i/d, 128k of l2
[06:19:25] <ohsix> thanks for looking
[06:20:11] <ShadowJK> P3 came with 2 different sizes of L2 cache iirc
[06:20:11] <ShadowJK> the later probably had 256k?
[06:20:53] <ohsix> latter, right; but it ran at full speed
[06:52:32] <aaronl> what's depressing about that compiler comparison from earlier is that gcc-head is worse than gcc 3.4
[06:53:54] <ohsix> you don't want to get stuck in local minima ;]
[06:56:40] <elenril> Nut came ten years after Ogg was already widespread. And looks almost exactly like Ogg << lol
[06:57:23] <elenril> obvious troll is obvious
[06:57:53] <ohsix> was someone advocating nut or did he pick that up himself
[06:58:43] <elenril> i don't see anybody mentioning it before him
[06:58:51] <elenril> probably because nobody knows about it ;)
[07:00:30] <ohsix> huhu, he must be picking up the vernacular
[07:58:58] <relaxed> I think the nut comment was a poke at ffmpeg/mplayer devs.
[08:42:30] <KotH> ohayou
[08:43:45] <kshishkov> god morgon
[08:53:54] <CIA-92> ffmpeg: conrad * r22197 /trunk/libavformat/matroskaenc.c:
[08:53:54] <CIA-92> ffmpeg: Attempt seeking to write EBML master sizes even if streamed
[08:53:54] <CIA-92> ffmpeg: Most EBML masters are much smaller than IO_BUFFER_SIZE and thus the size
[08:53:54] <CIA-92> ffmpeg: can be updated. This makes parsing the resulting files easier.
[08:53:55] <CIA-92> ffmpeg: conrad * r22198 /trunk/libavformat/matroskaenc.c:
[08:53:55] <CIA-92> ffmpeg: Write the first seekhead if writing to a stream, we won't be able to seek
[08:53:56] <CIA-92> ffmpeg: back and write it at the end
[08:53:56] <CIA-92> ffmpeg: conrad * r22199 /trunk/ (libavformat/matroskaenc.c tests/ref/acodec/pcm): Simplify starting and ending clusters
[08:53:57] <CIA-92> ffmpeg: conrad * r22200 /trunk/libavformat/matroskaenc.c: Fix indentation
[08:53:57] <CIA-92> ffmpeg: conrad * r22201 /trunk/libavformat/matroskaenc.c:
[08:53:58] <CIA-92> ffmpeg: Ensure that we write clusters and blocks with known size when streaming
[08:53:58] <CIA-92> ffmpeg: Too many demuxers can't cope with clusters of unknown size.
[09:15:08] <CIA-92> ffmpeg: gb * r22202 /trunk/libavcodec/vaapi_h264.c:
[09:15:08] <CIA-92> ffmpeg: Cope with rev 22183:
[09:15:08] <CIA-92> ffmpeg: Reorder indexes in weight tables.
[09:16:16] <j-b> good morning
[09:16:22] <kshishkov> bonjour
[09:19:09] <KotH> salut
[09:21:23] <Yuvi> hm, I broke gcc 2.95
[09:21:46] <kshishkov> what, it's you who released 2.96?
[09:22:58] <Yuvi> guess it didn't have good support for compound literal arrays
[09:23:13] <peloverde> Yuvi, nice work on that theora stuff (aside from breaking 2.95 ;) )
[09:23:49] <Yuvi> peloverde: we're now ~3% faster than libtheora on my penryn, with at least another 15% possible :)
[09:24:15] <Dark_Shikari> now get it in before 0.6 ;)
[09:24:17] <Yuvi> anyone happen to know if changing it to int[3] would work?
[09:24:26] <Dark_Shikari> and then make an announcement ;)
[09:25:21] <kshishkov> "FFmpeg är snäbbare av libtheora"?
[09:25:25] <Yuvi> eh, let's see, I like the weird C there
[09:26:04] <peloverde> That is weird C, I like it
[09:26:34] <CIA-92> ffmpeg: conrad * r22203 /trunk/libavcodec/vp3.c: Maybe fix gcc 2.95
[09:31:18] <merbzt> snabbare
[09:31:59] <kshishkov> ok, it's not me who agreed to translate news from Swedish anyway
[09:49:39] <DonDiego> Yuvi: did you merge all your theora work now?
[09:50:03] <Yuvi> DonDiego: not yet, I'm going to fix ogg seeking and implement 4:2:2 and 4:4:4 before finishing
[09:50:09] <Yuvi> now that we're slightly faster than libtheora
[09:52:25] <DonDiego> but you merged all the speedups?
[09:53:14] <Yuvi> not yet, sorry
[09:54:34] <peloverde> Yuvi, 22203 didn't help
[09:54:40] <peloverde> http://fate.multimedia.cx/index.php?history=build&config_id=69
[09:55:40] <DonDiego> Yuvi: np, you are making great progress
[09:56:01] <Yuvi> darn, I was hoping 2.95 would accept that compound literal
[09:56:38] <DonDiego> keep me posted on your progress please
[09:57:01] <DonDiego> i'm interested and we would like to have your theora work in 0.6
[09:57:09] <DonDiego> "works with html 5"
[09:57:18] <DonDiego> the codename should be the motto as well :)
[09:57:26] <Yuvi> sure
[09:57:46] <Yuvi> hopefully I should have ogg seeking fixed for tomorrow, I've been pounding at it and cursing ogg for a bit now
[09:58:59] <Yuvi> and also, I just made our mkv muxer work well for live streaming so to erode that advantage of ogg :)
[10:00:23] <DonDiego> cool :)
[10:01:57] <CIA-92> ffmpeg: conrad * r22204 /trunk/libavcodec/vp3.c: Really fix 2.95
[10:07:42] <wbs> anyone running gentoo that could do a quick compile test to verify a detail for a (gentoo) bug report?
[10:08:51] <thresh> if gentoo/ia64 is acceptable, yes
[10:09:22] <wbs> I guess so, download http://albin.abo.fi/~mstorsjo/stailq.c and try to compile it (just gcc stailq.c -o stailq)
[10:11:28] <KotH> btw: did anyone ever do a patent search on vorbis or theora?
[10:11:40] <KotH> a non-xiph-sponsored search that is
[10:12:53] <thresh> wbs: stailq.c:21: error: expected expression before 'struct'
[10:13:00] <wbs> thresh: great, thanks. :-)
[10:13:02] <thresh> wbs: gcc version 4.4.3 (Gentoo 4.4.3 p1.0)
[10:13:04] <DonDiego> KotH: mozilla claim they did
[10:13:22] <wbs> thresh: gentoo ships broken libc headers, and that's a example to pinpoint it to them :-)
[10:14:02] <wbs> wonderful story; they noticed that sys/queue.h is upstream glibc is ancient, so they've copypasted stuff from newer freebsd versions into their own version. without actually checking that the copypasted stuff works ;P
[10:15:29] <andoma> what a shame
[10:15:35] <andoma> i'm a big fan of queue.h though
[10:16:07] <andoma> on OS/X they changed the order of arguments for some TAILQ-macros between 10.4 and 10.5
[10:16:09] * kshishkov is no fan of queues since they tend to be rather long here
[10:16:50] <wbs> I haven't actually used it myself, but I package some code that uses it
[10:18:21] <KotH> DonDiego: have they published any results?
[10:18:43] <Kovensky> http://blogs.perl.org/users/ovid/2010/03/linked-lists-have-now-been-patented.html
[10:27:02] <DonDiego> KotH: no, they haven't
[10:28:28] * KotH wonders why neither xiph nor mozilla publish their results
[10:28:51] <KotH> it smells like they found something that they shouldnt have
[10:29:28] <kshishkov> or on the contrary - they don't want to search for it in case they _can_ find that
[10:29:40] <kshishkov> quite a common practice
[10:30:27] * KotH wonders whether ffmtech has enough money already to conduct a patent search
[10:31:19] <kshishkov> no
[10:32:07] <kshishkov> from what I know it mostly depends on what amount of information you already know and can range from $10000 to +\infty
[10:33:05] <pross-au> $infinity?
[10:33:17] <elenril> ∞
[10:33:44] <kshishkov> pross-au: yes, like penalty for breeding rabbits in Australia
[10:34:19] <peloverde> IMHO it would be a waste of FFMtech's money
[10:34:37] <merbzt> I would not support that kind of task
[10:35:02] <kshishkov> it's both irrelevant to us and not very moral
[10:35:25] <KotH> why isnt it moral?
[10:35:44] <KotH> or do you mean it's moral to claim something w/o proving it
[10:36:01] <kshishkov> KotH, it looks like we are jealous and want to undermine it
[10:36:03] <merbzt> there is no reason for us to rain on their parade
[10:36:34] <pross-au> which task guys?
[10:36:43] <kshishkov> convincing them to that thing for themselves is right IMO
[10:36:56] <kshishkov> pross-au: patent search on Theora/Vorbis
[10:37:15] <pross-au> kshishkov: you want to prove Xiph wrong?
[10:37:34] <kshishkov> pross-au: not me, I don't care much about them
[10:37:34] <bilboed-pi> that smells like one massive waste of time/money
[10:37:42] <kshishkov> pross-au: have you seen that? http://wiki.multimedia.cx/index.php?title=Bink_Video_version_b
[10:38:15] <pross-au> kshishkov: yep and i was gonna ask, are you implementing a decoder, or just documenting it?
[10:38:35] <kshishkov> pross-au: not yet (on both) ;)
[10:38:58] <kshishkov> first one has to understand what and how it does
[10:39:41] <pross-au> Are you doing that?
[10:39:50] <kshishkov> yes, in free time
[10:39:58] <kshishkov> as you can see, nothing is known about it
[10:40:18] <pross-au> s/nothing/not much/
[10:40:32] <pross-au> um did that idb file help you?
[10:40:55] <kshishkov> of course
[10:41:39] <pross-au> Good to hear
[10:53:29] <wbs> pross-au: btw, are you aware that the bink audio decoder outputs a lot of noise if compiled without optimizations?
[10:54:12] <wbs> I build with --disable-optimizations --disable-stripping --enable-debug --disable-mmx --disable-asm, and do get the actual sound, but with a lot of noise on top
[10:55:06] <DonDiego> KotH: they claim that publishing results could undermine a defense in court, i.e. help attackers
[10:55:25] <pross-au> wbs: news to me. will check it out
[10:55:35] <kshishkov> wbs: it's not because of asm, I think, sice it plays fine on PowerPC
[10:55:38] <kshishkov> *since
[10:55:58] <kierank> [10:55] <@DonDiego> KotH: they claim that publishing results could undermine a defense in court, i.e. help attackers --> isn't that a bit of a circular argument
[10:56:39] <wbs> kshishkov: ok.. I just generally use that configure option to get quick rebuilds and sensible valgrind output when testing non-performance-critical stuff :-)
[10:57:09] <DonDiego> kierank: well, it gives the other side knowledge about your defense strategies
[10:57:36] <merbzt> pross-au: most likely the float2inst16 special scaling stuff
[10:58:18] <peloverde> float2int16c has bitten me in the ass numerous times
[10:58:29] <KotH> DonDiego: lol
[10:58:40] <KotH> DonDiego: if they found nothing -> no problem in court
[10:58:53] <merbzt> peloverde: I tried to get rid of it :/
[10:58:58] <KotH> DonDiego: if they found something -> there is even more a problem if they have to publish their results in court
[10:59:21] <peloverde> Isn't BBB working on making audioconvert not suck?
[10:59:51] <merbzt> peloverde: well moving the codec to output float would obsolete it
[11:00:34] <pross-au> merbzt: i was thinking of doing that...
[11:00:51] <merbzt> *moving all codecs
[11:01:40] <peloverde> the issue is the weird hacks float2int16c uses, it requires biased floats but is faster than generic C code
[11:02:20] <peloverde> And it doesn't help that lossy floatingpoint audio isn't well supported in FATE
[11:02:59] <merbzt> well all common archs have faster simd convert
[11:03:13] <peloverde> that is true
[11:03:15] <merbzt> only p2 might be faster in c
[11:03:37] <merbzt> "but think about the children!"
[11:04:21] <merbzt> anyway codecs should output in planar float mode or planar int16
[11:04:37] <peloverde> agreed
[11:04:50] <DonDiego> KotH: they argue along the lines of
[11:05:38] <DonDiego> the attackers will already know that they think patent x does not apply at all or that they don't practice the claims or somehow worked around them
[11:05:52] <DonDiego> it's a bit similar to not talking to the police
[11:08:04] <KotH> very twisted logic...
[11:08:25] <kierank> it seems so
[11:11:26] <DonDiego> the argument is that it gives attackers time and preparation
[11:11:58] <KotH> lol
[11:12:06] <KotH> that would be an issue, if there would be a time limit
[11:19:21] <DonDiego> there is
[11:19:44] <KotH> huh?
[11:19:45] <DonDiego> patent holders can prepare an attack with due time and then sue
[11:19:56] <DonDiego> that creates time pressure
[11:20:01] <KotH> and where is the time limit?
[11:20:30] <DonDiego> the deadlines during the trial
[11:20:45] <KotH> _during_ the trial, not upfront
[11:21:01] <DonDiego> what do you mean by "not upfront"?
[11:21:16] <KotH> if i would be holding, lets say 20 patents, i'd check whether vorbis or theora would infringe them
[11:21:36] <KotH> i'd really take my time to prepare for an upcoming trial, w/o telling anyone
[11:21:42] <KotH> and as soon as i smell money, i'd sue
[11:22:32] <KotH> i dont have to do all research during the trial. nobody says i have to come unprepared
[11:23:07] <peloverde> Is roundup down?
[11:23:17] <KotH> ofc, as soon as i'm in court, there are deadlines to deal with
[11:23:25] <peloverde> nevermind, it's working now
[11:23:36] <KotH> but they dont start until i actually sue someone
[11:27:36] <DonDiego> i understand their arguments, i'm not *terribly* convinced but i can see the merit
[11:27:41] <DonDiego> there is a tradeoff
[11:28:03] <DonDiego> from the outside you cannot tell if they found something or they found nothing
[11:28:25] <iive> peloverde: actually i think i've done tweak of float2int16c that eleminates the need of special scalling, aka it can work with different range, by changing the magic constant.
[11:28:27] <CIA-92> ffmpeg: alexc * r22205 /trunk/ffmpeg.c: ffmpeg.c: Don't use NULL for integer metadata flags.
[11:28:44] <peloverde> iive, good to hear
[11:29:23] <DonDiego> the tradeoff is between their defense and their credibility
[11:30:07] <DonDiego> i personally don't think the tradeoff is worth it
[11:31:45] <iive> peloverde: and i think i've posted that tweak on the maillist, so if you are up to the task.
[11:33:21] <kierank> [11:28] <@DonDiego> from the outside you cannot tell if they found something or they found nothing --> yet with "patented" standards you know where you stand since countless others will fall with you
[11:44:49] <superdump> kierank: mmm, and so there would be serious repercussions for anyone suing people for patent infringements
[11:45:48] <peloverde> still alcatel-lucent managed to attack mp3 from the outside
[11:46:06] <superdump> mmm
[11:50:16] <peloverde> DonDiego, I'm watching FOSDEM talks I missed and i can see you o.O
[11:50:46] <DonDiego> where?
[11:51:06] <DonDiego> distros vs. upstream?
[11:51:16] <peloverde> yep
[12:07:19] <mru> omg, "It is illegal for you to write a player even if you know how to write one except for the codecs and container formats developed by Xiph."
[12:08:29] <DonDiego> huh?
[12:09:08] <kshishkov> is that official Mozilla position?
[12:09:30] <bilboed-pi> mru, where on earth is that from ?
[12:09:49] <kierank> wow even gabest chimed in
[12:09:55] <mru> someone commenting on my blog
[12:11:37] <mru> notice how everybody who claims to have ever touched the ogg format hates it
[12:11:41] <mru> except monty
[12:11:52] <kshishkov> monty has not touched it
[12:12:01] <mru> I was getting to that
[12:12:33] <peloverde> I love the <I love vorbis but hate ogg> posts from various implementers
[12:12:59] <kshishkov> well, Xiph is trying to discourage them on Vorbis as well
[12:14:50] <pross-au> meh, i use chromium-browser
[12:15:12] <mru> I would, did it not require dbus
[12:16:18] <peloverde> I use chromium-browser but wish the ubuntu maintainer would rename chromium-codecs-ffmpeg-nonfree to something saner
[12:16:23] <siretart`> the ubuntu chromium package doesn't require dbus
[12:16:49] <mru> siretart`: how'd you get rid of it?
[12:17:17] <siretart`> mru: the package doesn't declare a dependency
[12:17:38] <siretart`> what does chromium use dbus for after all?
[12:17:44] <mru> no idea
[12:17:53] <mru> gentoo lists it as a dependency
[12:18:05] <siretart`> it doesn't seem very well integrated into gnome nor kde anyway
[12:18:06] <mru> I could force-install it without and see what happens
[12:18:52] <siretart`> DonDiego: do you remember the av_lock_mgr() patch for 0.5.1? it seems that the kde folks scream for that as well...
[12:20:20] <KotH> stupid question: what in the world could be patented in a file format?
[12:20:31] <mru> storing bits in a sequence
[12:20:32] <KotH> (disregarding all prior art and trivial patents)
[12:20:39] <pross-au> If video is important as the HTML5 supporters say, then the mozilla dev will either change their mind or find themselves with a diminishing user-base as people move to chrome
[12:20:58] <peloverde> The MPEG-4 scenegraph? (that no one uses in practice)
[12:21:06] <pross-au> KotH: novel chunking :D
[12:22:18] <peloverde> MPEG-4 Systems (-1) originally included a lot of flash like interactivity
[12:22:51] <peloverde> pross-au, there are a lot of rabid irrational firefox fans
[12:23:02] <kierank> and 3d and vr and all sorts of other crap
[12:24:28] <pross-au> peloverde: yeah, but who is listening to them?
[12:24:55] <pross-au> i dont see it translating into theora optimised graphics boards
[12:24:58] <peloverde> My guess (and only a guess) is if you stuck to a minimal mp4 (container not codec stack) it would be hard to step on a patent
[12:25:18] <pross-au> mru: nice article btw
[12:25:27] <peloverde> pross-au, what I'm implying is that these people will give firefox a long leash before jumping ship
[12:29:32] <mru> eeeww, chromium wants gconf too
[12:30:11] * siretart` doesn't find any key containing 'gconf' in his database
[12:30:40] <siretart`> err
[12:30:50] * siretart` doesn't find any key containing 'chrome' nor 'chromium' in his gconf database
[12:31:14] <peloverde> siretart`, my guess is it uses it to pull in gnome proxy settings or the like
[12:31:33] <peloverde> it really should exec gconftool-2
[12:32:20] <siretart`> oh right, the proxy settings dialog fires up the gnome settings dialog
[12:33:41] <mru> I'm forcing it, let's see what breaks
[12:34:40] <DonDiego> siretart`: what do you mean by "scream for that"?
[12:35:04] <CIA-92> ffmpeg: alexc * r22206 /trunk/libavcodec/aac.c:
[12:35:04] <CIA-92> ffmpeg: AAC: Return the number of bytes consumed in decoding a frame.
[12:35:04] <CIA-92> ffmpeg: The libfaad wrapper does this.
[12:35:31] <siretart`> DonDiego: the kdesupport package doesn't compile anymore :-)
[12:35:46] <siretart`> as, 0.5.1 seems to help them with that
[12:41:12] <DonDiego> oh, good :)
[12:42:03] <merbzt> some nice tree structure
[12:42:26] <DonDiego> siretart`: Yuvi keeps committing theora stuff, this is looking good for 0.6...
[12:43:01] <DonDiego> mru: did you make any more changes to your text?
[12:43:09] <peloverde> DonDiego, no comments so far on the latest SBR patch, I'm going to interpret that as a good thing
[12:43:58] <mru> DonDiego: yes, I made some changes
[12:44:19] <mru> Exception: Call to 'pkg-config --cflags gconf-2.0' returned exit status 1. while loading dependencies of base/base.gyp while loading dependencies of net/net.gyp while loading dependencies of app/app.gyp while loading dependencies of build/all.gyp while trying to load build/all.gyp
[12:44:22] <DonDiego> peloverde: excellent :)
[12:47:02] <siretart`> Yuvi++! :-)
[12:48:14] <siretart`> DonDiego: 0.5.1 uploaded to ubuntu
[12:51:31] <peloverde> Is thilo looking into the ALS icc-11.1 issue? it would clear up another yellow spot on fate for 0.6
[12:53:29] <DonDiego> siretart`: could you get the ubuntu chromium maintainers to call their ffmpeg packages something else than "nonfree"?
[12:53:58] <siretart`> DonDiego: there is no such package in ubuntu
[12:54:20] <peloverde> There is a chromium-team lp account with a chromium ppa
[12:54:21] <siretart`> however, there is a well known PPA carrying such packages
[12:54:44] <siretart`> I don't know the guy who is working on the packages
[12:54:56] <peloverde> It seems odd that there are two packages at all
[12:55:13] <siretart`> peloverde: yes, it seems that asac is working on 'official' packages
[12:55:37] <peloverde> all the formats supported by chromium-codecs-ffmpeg-nonfree are in the ffmpeg package in main
[12:55:45] <peloverde> so why does chromium do the weird split?
[12:56:01] <siretart`> because chromium doesn't work with ffmpeg 0.5? just a guess
[12:56:24] <CIA-92> libswscale: stefano * r30825 /trunk/libswscale/ (swscale-test-all.sh swscale-test.c): (log message trimmed)
[12:56:24] <CIA-92> libswscale: Make swscale-test take in input the name of the input and the output
[12:56:24] <CIA-92> libswscale: format.
[12:56:24] <CIA-92> libswscale: Make swscale-test only perform the test from the input to the output
[12:56:24] <CIA-92> libswscale: format rather than perform all.
[12:56:25] <CIA-92> libswscale: Also implement swscale-test-all.sh, for performing all the tests.
[12:56:26] <CIA-92> libswscale: Improve flexibility of the swscale-test tool, this way is simpler to
[12:56:26] <CIA-92> libswscale: stefano * r30826 /trunk/libswscale/swscale.c:
[12:56:27] <CIA-92> libswscale: Fill the r, g, b values used for computing the c->pal_yuv table in the
[12:56:27] <CIA-92> libswscale: case where the source format is PIX_FMT_GRAY8.
[12:56:28] <CIA-92> libswscale: This is required as PIX_FMT_GRAY8 has been declared as a paletted
[12:56:28] <CIA-92> libswscale: format in FFmpeg r22191, fix GRAY8 -> RGB conversion.
[12:56:29] <CIA-92> libswscale: stefano * r30827 /trunk/libswscale/ (swscale-test-all.sh swscale-test.c):
[12:56:29] <CIA-92> libswscale: Revert r30825, it was not supposed to be committed.
[12:56:30] <CIA-92> libswscale: 127.32L to me, beware when using git svn dcommit for committing stuff
[12:56:36] <peloverde> no i don't mean chromium-codecs-ffmpeg-nonfree vs ffmpeg, i mean chromium-codecs-ffmpeg-nonfree vs chromium-codecs-ffmpeg
[12:56:50] <peloverde> I understand that chromium-codecs-ffmpeg* needs the google patches
[12:56:54] <CIA-92> libswscale: to svn...
[12:57:05] <siretart`> then you understand more than me about it :-)
[12:58:20] <DonDiego> peloverde: what google patches?
[12:58:28] <DonDiego> and where are those packages you speak of?
[12:58:29] <peloverde> I opened up an inquiry on the name and this was the response: https://answers.launchpad.net/chromium-browser/+question/81283
[12:59:07] <peloverde> DonDiego, These patches: http://src.chromium.org/viewvc/chrome/trunk/deps/third_party/ffmpeg/patches/to_upstream/
[13:01:09] <DonDiego> are these the patches that already got merged or new ones?
[13:02:23] <peloverde> new ones/what was left of the last round
[13:02:31] <peloverde> there used to be somewhere around 50
[13:02:36] <superdump> peloverde: why not add Google Chrome to the projects using ffmpeg page too?
[13:02:56] <DonDiego> go right ahead
[13:03:09] <DonDiego> so, let's review and commit those patches :)
[13:03:17] <DonDiego> i see aac stuff, superdump, peloverde ?
[13:03:27] <peloverde> superdump, they are more or less the same thing?, I wasn't sure to list them separately or what
[13:03:36] <peloverde> DonDiego, 03 was fixed recently in a different manner
[13:03:57] <peloverde> DonDiego, and the bug only manifested with replacement bitsream reader they were using
[13:04:11] <superdump> peloverde: well, i'd be inclined to list Google Chrome over Chromium just because it's higher profile
[13:04:16] <superdump> but listing both should be fine
[13:04:26] <peloverde> 2 lines or 1?
[13:04:35] <superdump> or put them together as one line with two links
[13:04:36] <superdump> :)
[13:04:47] <peloverde> that's what I meant by one
[13:04:57] <peloverde> and in that case would it be under G or C
[13:05:20] <DonDiego> Chromium / Google Chrome
[13:05:26] <DonDiego> kshishkov: http://src.chromium.org/viewvc/chrome/trunk/deps/third_party/ffmpeg/patches/to_upstream/05_vc1_bsfs.patch?revision=39952&view=markup
[13:05:29] <DonDiego> this one is for you
[13:05:38] <peloverde> yes they have new BSFs
[13:06:18] <peloverde> DonDiego, 02_mov_dref_looping.patch was discussed once and rejected but i don't remember why
[13:07:05] <peloverde> 06+07 are about ogg needing big chunks of the decoder, blol
[13:07:33] <kshishkov> DonDiego: well, the question is why.
[13:07:54] <peloverde> kshishkov, presumably to pipe it off to some hardware decoder?
[13:08:10] <kshishkov> EDONTCARE then
[13:08:27] <DonDiego> bah
[13:08:34] <DonDiego> if it's useful to some people..
[13:08:51] <DonDiego> didn't we have some googlers on the channel at some point?
[13:09:26] <peloverde> schekus and fbachard sometimes lurk here
[13:09:42] <peloverde> they aren't on in their channel either right now
[13:09:51] <peloverde> probably because it is 5AM in california
[13:10:36] <DonDiego> mru: http://src.chromium.org/viewvc/chrome/trunk/deps/third_party/ffmpeg/patches/to_upstream/01_static_pthread_O2.patch?revision=39606&view=markup
[13:10:45] <DonDiego> the second configure hunk of this patch looks ok
[13:11:15] <mru> I don't know
[13:11:22] <mru> iirc there was more to it than that
[13:11:33] <DonDiego> peloverde: what about 03?
[13:11:52] <peloverde> The vehemently claim that for their benchmarks -O2 is faster than -O3
[13:12:13] <DonDiego> no, i mean patch 03-whatever
[13:12:17] <DonDiego> aac one
[13:12:29] <peloverde> <peloverde> DonDiego, 03 was fixed recently in a different manner
[13:12:34] <peloverde> <peloverde> DonDiego, and the bug only manifested with replacement bitsream reader they were using
[13:12:56] <DonDiego> oh, sorry, missed the scrollup
[13:13:35] <peloverde> It's a nastly flaw in the aac bitstream format that makes it zero padding unfriendly
[13:13:48] <siretart`> peloverde: excellent link. I've just subscribed there and comment on that as well
[13:14:27] <DonDiego> mru: there are two build system patches as well:
[13:14:29] <DonDiego> http://src.chromium.org/viewvc/chrome/trunk/deps/third_party/ffmpeg/patches/to_upstream/06_respect_flac_configure.patch?revision=40585&view=markup
[13:14:36] <DonDiego> http://src.chromium.org/viewvc/chrome/trunk/deps/third_party/ffmpeg/patches/to_upstream/07_respect_dirac_configure.patch?revision=40336&view=markup
[13:15:24] <peloverde> DonDiego, those increase coupling between lavf and lavc
[13:15:56] <mru> and they're wrong
[13:16:00] <peloverde> though arguably so do the proposed ways for dealing with HE-AAC
[13:16:06] <DonDiego> lavf depends on lavc anyway
[13:16:07] <mru> demuxing flac in ogg shouldn't require the flac decoder
[13:17:14] <mru> if it needs some header parsing function, that should be broken out and enabled separately
[13:17:58] <DonDiego> we should tell the google people that
[13:18:06] <DonDiego> does anybody have a contact?
[13:18:45] <peloverde> fbachard and scherkus or crbug.com
[13:19:07] <DonDiego> mru: what about the dirac one, that looks less harmful
[13:19:20] <mru> also wrong
[13:19:54] <mru> whatever it needs from the raw dirac "demuxer" should be factored out
[13:20:49] <mru> as a general rule, no *_encoder/decoder/muxer/demuxer should depend on another
[13:21:04] <mru> if there's common code they both need, that should be separated
[13:26:53] <CIA-92> ffmpeg: pross * r22207 /trunk/libavformat/bink.c: Guard against invalid memory read
[13:28:47] <CIA-92> ffmpeg: pross * r22208 /trunk/libavformat/bink.c: handle errors reported by av_get_packet() in Bink demuxer
[14:47:26] <DonDiego> mru: do comments not appear immediately on your blog?
[14:48:21] <mru> first-time commenters are moderated
[14:48:48] <mru> and I don't continuously monitor my email
[14:51:04] <kshishkov> trolling on Xiph formats - just cast a doubt they are not as good as advertised!
[14:51:05] <DonDiego> :)
[14:51:21] <DonDiego> mru: kevin granade wrote some good points that you could address
[14:51:46] <mru> I'll wait for the dust to settle, then write a response
[14:54:09] <DonDiego> he mentions more or less what i said
[14:54:22] <mru> he also misunderstood half the article
[14:54:31] <DonDiego> if you make the tone a bit more neutral it's more difficult for dissenters to dismiss what you wrote
[14:54:41] <DonDiego> also, comparisons with other containers are instructive
[14:54:57] <DonDiego> well, just make the article harder to misunderstand :)
[14:55:23] <DonDiego> it is a good article already, i'm very happy you wrote it, i'm just trying to help you make it even better
[14:55:44] <DonDiego> at some point you could merge it with the timestamp article into one coherent complete criticism
[14:55:55] <mru> some of the comments are way beyond the level of stupidity I expected
[14:56:03] <DonDiego> nah, it's ok
[14:56:28] <DonDiego> just present the trolls with facts
[14:56:41] <DonDiego> and ignore them if they continue beating their drums
[14:56:58] <mru> I have to stop somewhere
[14:57:07] <mru> I don't have time to explain every last detail
[14:57:20] <DonDiego> of course
[14:57:41] <DonDiego> but you know this has been a recurring topic over the years
[14:57:59] <DonDiego> if you extend it a bit you will not have to repeat yourself forever :)
[14:58:21] <mru> I'll try to extend it a bit later
[14:58:25] <mru> I have to do some real work now
[14:58:56] <jez9999> BBB: hey... see the patch to issue 1790
[14:59:17] <DonDiego> good
[14:59:31] <DonDiego> mru: and thanks again for the writeup, it's an enlightening read
[15:00:50] <mru> it feels a bit futile though
[15:01:18] <mru> those who understand it already agree, and those don't will never be swayed
[15:01:38] <DonDiego> i understand the feeling
[15:01:48] <DonDiego> but there are a lot in between that watch the discussion
[15:01:55] <DonDiego> without a stake in either position
[15:02:10] <DonDiego> they can use such texts to form an informed opinion
[15:02:30] <DonDiego> the more facts we give them, neutral facts, the more informed these opinions will be
[15:02:55] <DonDiego> IME neutral bystanders are best swayed by neutral factual information
[15:05:30] <BBB> jez9999: done
[15:06:02] <jez9999> BBB: don't you administer that file?
[15:06:18] <BBB> jez9999: yes, but martin wrote the patch so he may check it in for me
[15:06:24] <BBB> jez9999: don't worry, he'll apply in a second
[15:06:26] <BBB> he's quite fast
[15:06:44] <jez9999> ok
[15:06:56] <jez9999> the funny thing is, i experimented, and the exiting code seems to be interruptable anyway
[15:07:12] <jez9999> when i call thread.interrupt() in java and it's presumably sitting on select(), it does return
[15:08:09] <BBB> well yes
[15:08:12] <BBB> but we don't all use java
[15:08:21] <BBB> so this is better :)
[15:08:24] <jez9999> how does it work even in java though?
[15:08:39] <BBB> probably a kernel thing
[15:08:44] <BBB> ctrl-C also interrupts select() waits
[15:08:48] <BBB> probably same mechanism
[15:08:53] <jez9999> ah
[15:08:56] <BBB> but I have no idea of how that works
[15:09:04] <BBB> :)
[15:09:48] <wbs> jez9999/BBB: applied the select/url_interrupt_cb patch
[15:09:51] <CIA-92> ffmpeg: mstorsjo * r22209 /trunk/libavformat/rtpproto.c: Check url_interrupt_cb in rtp_read, wait in select for max 100 ms before rechecking url_interrupt_cb
[15:09:56] <BBB> jez9999: see?
[15:10:09] <jez9999> yup
[15:10:31] <jez9999> i'm still relying on my own build for IP filtering though.  o well.
[15:10:52] <BBB> we'll get there, I'm a bit slow at getting moving there
[15:22:37] <siretart`> does someone know the screencast software recordmydesktop? the created ogv fail to decode with ffmpeg :-(
[15:23:06] <kshishkov> sample please ;)
[15:23:40] <KotH> and upload them ;)
[15:23:56] <DonDiego> siretart`: do they work with something else?
[15:24:30] <siretart`> DonDiego: they work fine in totem
[15:24:47] <mru> wtf?
[15:25:16] <mru> you found a file that plays in totem?
[15:25:26] <siretart`> scary, no?
[15:26:27] <BBB> well look
[15:26:32] <BBB> gstreamer is designed around ogg
[15:26:50] <BBB> maybe recordmydesktop is gst as well?
[15:27:29] <KotH> o_0
[15:27:32] <KotH> around ogg?
[15:27:49] <KotH> i thought the mkv guys got gstreamer flying?
[15:27:56] <mru> I thought it was designed around hype
[15:28:14] <mru> no, mkv and gst are quite separate
[15:28:39] * KotH atleast remembers how the mcf guys went to build gstreamer after the mplayer-mcf cooperation broke up
[15:28:50] <mru> mkv was made by robux4 et al
[15:29:12] <BBB> I implemented mkv support in gst
[15:29:22] <BBB> long before the ffmpeg patch and non-c++ mplayer support
[15:29:33] <BBB> but it was not designed around it
[15:29:44] <BBB> they (mkv guys) wanted to, but there was no interest
[15:31:29] <siretart`> filed as https://roundup.ffmpeg.org/issue1793
[15:32:27] <siretart`> might be a dupe of #746, not sure though
[15:35:57] * mru writes recursive gas macros
[15:36:25] <kshishkov> do gas creators know of that possibility?
[15:36:40] <mru> probably
[15:36:48] <mru> you can also have macros defining macros
[15:36:49] * kshishkov suspects that is uses cpp as well
[15:36:53] <mru> recursively...
[15:36:56] <kshishkov> oh, lispy!
[15:39:08] <mru> throw in some .include directives for extra fun
[15:55:39] <twnqx> <yoann_> nooooo :( error
[15:55:39] <twnqx> <yoann_> /usr/local/arm/3.4.3/bin/arm-linux-as: option non reconnue '-HAVE_AV_CONFIG_H'
[15:55:39] <twnqx> <yoann_> make: *** [libavcodec/arm/dsputil_arm.o] Erreur 1
[15:55:52] <twnqx> hm... is there something passed on from C to as?
[15:56:19] <superdump> looks like it should maybe be -DHAVE_AV_CONFIG_H
[15:56:25] <mru> broken gcc
[15:56:57] <mru> we really only support gcc4 and armcc for arm
[15:58:21] <mru> older gcc versions are too crap to bother with
[16:02:00] <twnqx> http://www.engadget.com/2010/03/04/mios-tegra-powered-moov-v780-puts-maps-720p-video-and-the-int/ cute
[16:07:55] <kierank> twnqx: pricey
[16:08:21] <twnqx> yeah :X
[16:08:25] <twnqx> still cute
[16:11:03] <kshishkov> still, 720p on 800x480 screen is a bit overcalled
[16:12:07] <twnqx> also, from a tegra i'd expect 1080p
[16:12:17] <twnqx> (on the hdmi at least)
[16:15:55] <twnqx> what i really want... is that nokia netbook with a tegra2 mainboard
[17:36:28] <BBB> I hate it when I can't extract exe files to see their content
[17:36:34] <BBB> what do you people use?
[17:36:40] <kshishkov> with what?
[17:37:21] <kshishkov> there are many tools for many types for extraction
[17:37:25] <jai> extract exe files?
[17:37:34] <jai> do you mean unpacking?
[17:38:02] <mru> I guess he means a self-extracting compressed archive
[17:38:16] <jai> 7zip perhaps
[17:38:28] <kshishkov> unzip/unrar/cabextract usually enough
[17:42:19] * kshishkov wonders why his custom asm function works in all cases but when callee is compiled with gcc -O1
[17:43:24] <mru> cpu?
[17:43:30] <kshishkov> x86
[17:43:50] <mru> inline asm?
[17:44:03] <kshishkov> no, standalone
[17:44:16] <mru> did you mean _caller_ compiled with -O1?
[17:44:35] <kshishkov> ah, right
[17:44:53] <mru> you're probably clobbering a callee-saved register
[17:45:04] <mru> and gcc was only using it with -O1
[17:45:14] <kshishkov> those are?
[17:45:19] <mru> not a clue
[17:45:28] <mru> try saving all regs you use and see if that helps
[17:46:50] <Compn> bwaahahaha
[17:46:52] <Compn> http://web.archive.org/web/20000824073138/209.237.24.132/OnlineVideos/GiguQD3.mov
[17:46:58] * Compn is happy to find new samples
[17:48:23] <Compn> oh qdmc , nevermind
[17:49:42] <mru> btw, what's the matter with the cygwin/gcc4.4 fate build?
[18:19:57] <BBB> drv: do you still have that link from yesterday?
[18:25:11] <mru> lol http://stevehoffman.tv/forums/showpost.php?p=5094768&postcount=38
[18:26:31] <thresh> niiice
[18:26:31] <kshishkov> mru: that's why it's called "psychoacoustics" - it's all in a head of listener
[18:27:16] <mru> on a *really* cheap gadget I might believe there could be a difference
[18:27:34] <mru> decoding the compressed file will cause more power draw from the cpu
[18:27:46] <mru> if the power distribution is weak, this could affect the dacs
[18:29:02] <kshishkov> then 256k AAC must sound really awful there
[19:11:35] <CIA-92> ffmpeg: fenrir * r22210 /trunk/libavcodec/flashsv.c: Fixed buffer overread in flashsv decoder.
[19:12:37] <thresh> woah, laurent has an svn account?
[19:13:04] <kshishkov> since ages I think
[19:13:10] <CIA-92> ffmpeg: fenrir * r22211 /trunk/libavcodec/dxva2_h264.c: Fixed DXVA2 H264 hwaccel after luma/chroma_weight changes.
[19:13:17] <kshishkov> used mostly for Flash-related stuff patching though
[19:19:49] <mru> fenrir has not committed before jan 2010
[19:19:57] <mru> I don't think he has another account
[19:21:38] <kshishkov> indeed, but he send some patches though
[20:17:40] <Yuvi> gah, these recordmydesktop oggs are like not interleaved at all, but they're not chained either
[20:22:12] <mru> that's invalid according to some parts of the spec
[20:22:29] <mru> other parts could be interpreted as allowing it
[20:23:42] <mru> btw, what was the verdict on the continuation bug?
[20:23:47] <mru> is it still in libogg?
[20:24:52] <Yuvi> I would say yes, but I haven't reproduced it myself
[20:25:02] <mru> do you know what triggers it?
[20:25:30] <mru> easy enough to feed it dummy packets of the right sizes to make it happen if they are known
[20:25:30] <Yuvi> last time it came up some xiph people agreed but couldn't figure out where in libogg it happened
[20:25:40] <mru> great
[20:26:03] <Dark_Shikari> mru: another reason to hate C++
[20:26:09] <Dark_Shikari> doing a homework assignment, and apparently this is actually legal: http://pastebin.org/101298
[20:26:17] <Yuvi> probably if you feed random packets of mod 255 it'll trigger eventually
[20:27:19] <mru> Dark_Shikari: it's easy enough to follow the pointers, but it sucks that you can do such things
[20:27:24] <mru> just imagine the runtime overhead of that
[20:27:34] <Dark_Shikari> but what actually happens?
[20:27:45] <mru> compile and see
[20:27:46] <Dark_Shikari> it's completely non-obvious
[20:27:48] <Dark_Shikari> lol
[20:28:37] <mru> *ap = generic; copies 'generic' to wherever ap is pointing
[20:28:48] <mru> at that time it is point at the same thing cp is
[20:28:54] <Dark_Shikari> yes, but what happens if you copy a non-cow over a cow
[20:29:02] <Dark_Shikari> and then tell the cow to do something cow-speicifc?
[20:29:05] <ohsix> whats worse is the compiler cnt always figure out which method to call from the context
[20:29:12] <mru> either you get runtime conversion or an exception
[20:29:22] <mru> not sure which
[20:29:25] <Dark_Shikari> but you can't convert from Animal to Cow
[20:29:30] <Dark_Shikari> only from Cow to Animal
[20:29:34] <Dark_Shikari> subtyping isn't reversible
[20:29:36] <mru> but you can degrade the cow into an animal
[20:29:39] <mru> or a burger
[20:29:41] <Dark_Shikari> but animals can't moo
[20:29:55] <Dark_Shikari> also, the assignment says it won't runtime exception
[20:29:59] <Dark_Shikari> o.0
[20:30:06] <mru> it could be overloaded for Animal
[20:30:36] <Dark_Shikari> it could keep the moo function while overwriting the data that's shared
[20:30:42] <Dark_Shikari> i.e. cp->moo() will print "Bob"
[20:30:44] <mru> you don't know whether moo is virtual or not either
[20:30:52] <Dark_Shikari> it's virtual
[20:31:00] <Dark_Shikari> and only cows have it.
[20:31:03] <mru> you have the class definitions?
[20:31:13] <Dark_Shikari> no, it just says that it's virtual.
[20:31:28] <Dark_Shikari> I'm pretty sure it's going to print "Bob".
[20:31:35] <mru> why?
[20:31:36] <drv>  BBB: http://www.mindspring.com/~alanh/fracs.html
[20:31:46] <BBB> drv: thanks, I found it in my logs
[20:31:48] <BBB> long live logs
[20:31:52] <drv> :)
[20:31:55] <mru> if Animal doesn't have a moo() function it won't work
[20:31:57] <Dark_Shikari> because the string is a common member of all Animals
[20:32:04] <Dark_Shikari> moo is cow-only
[20:32:08] <Dark_Shikari> thus, the assignment will overwrite the string
[20:32:10] <Dark_Shikari> but not the moo
[20:32:16] <mru> not so hasty
[20:32:22] <Dark_Shikari> well, the assignment says it will not error
[20:32:23] <Dark_Shikari> and it will compile
[20:32:27] <Dark_Shikari> and it will run without errors
[20:32:41] <Dark_Shikari> oh wait, it says it "won't lead to type errors at runtime"
[20:32:45] <Dark_Shikari> it could lead to some other type of error.
[20:32:47] <mru> the question can't be answered without seeing the full source you're compiling
[20:33:12] <mru> you could get some weird virtual function exception
[20:36:37] * Dark_Shikari just writes it up
[20:37:50] <mru> daft course if you ask me
[20:38:35] <Yuvi> every time I think about implementing reading ogg skeleton to fix some problem with ogg, it turns out that skeleton doesn't actually handle that problem
[20:38:37] <ohsix> you can use the name of the class to find the right activation site if its ambiguous, but its still lame
[20:38:53] <Yuvi> I still haven't figured out why it exists
[20:39:25] <mru> I could say that about xiph itself
[20:43:30] <Dark_Shikari> mru: it prints bob.  tested it
[20:43:44] <mru> code?
[20:43:54] <Dark_Shikari> http://pastebin.org/101332
[20:43:56] <Dark_Shikari> I'm shit at C++
[20:44:31] <ohsix> best part of resolving those things is it'll try and find a type conversion path and stop at the first one that fits
[20:45:13] <mru> Dark_Shikari: what happens if you have moo() print something that only exists in Cow?
[20:45:22] <Dark_Shikari> that would be different and potentially fail horribly
[20:45:28] <Dark_Shikari> or probably it'll keep the name
[20:45:29] <Dark_Shikari> let me try
[20:45:30] <ohsix> like if a copy constructor can promote one type to another, it'll do it to resolve the signature
[20:45:56] <Dark_Shikari> Yes
[20:45:59] <Dark_Shikari> it works as I thought
[20:46:04] <mru> what does it do?
[20:46:07] <Dark_Shikari> if the value is only in cow, it'll print "Flossie"
[20:46:11] <Dark_Shikari> if the value is in both, it'll print "Bob"
[20:46:51] <mru> how is ->moo actually resolved?
[20:46:55] <mru> in asm
[20:47:41] <Dark_Shikari> I have no idea.
[20:47:44] <Dark_Shikari> let me look
[20:47:58] <Dark_Shikari> oh holy fuck name mangling
[20:48:12] <Dark_Shikari> wow that's a lot of asm
[20:48:16] <Dark_Shikari> er, if you want to look, feel free
[20:49:07] <Dark_Shikari> oh, it inlines everything
[20:49:09] <Dark_Shikari> it figures it out at compile time
[20:49:21] <Dark_Shikari> and all it does is print flossie and bob
[20:49:38] <mru> well, let's mess with it some more
[20:51:05] <Dark_Shikari> feel free, I'm done with that question =p
[20:51:06] <Dark_Shikari> fuck c++
[20:52:33] <DonDiego> Yuvi: they continue revving ogg, but going back and using something else is out of the question - who understands those guys...
[20:53:13] <mru> "it would break a million devices" apparently
[20:53:14] <mru> lol
[20:53:15] <Dark_Shikari> DonDiego: if you want to kill ogg, write competing applications that use something else
[20:53:22] <Dark_Shikari> i.e. icecast replacement, etc
[20:53:44] <Dark_Shikari> don't bitch, do.
[20:55:31] <mru> we should start an official "kill ogg" campaign
[20:55:44] <mru> facebook group, anyone?
[20:56:50] <Yuvi> DonDiego: well, I don't fully disagree that it became too late to update ogg after they stuffed theora in it
[20:56:56] <Yuvi> but fixing it then would've been nice
[20:57:14] <Yuvi> update it in incompatible ways that it
[20:57:29] <DonDiego> the installed base they talk about is bogus
[20:57:40] <mru> of course it is
[20:57:43] <DonDiego> there are more devices out there supporting mkv than ogg
[20:57:55] <Dark_Shikari> and devices that only do vorbis hardly count
[20:58:04] <DonDiego> if they start supporting mkv themselves
[20:58:10] <DonDiego> they suddenly will work on these devices
[20:58:18] <Dark_Shikari> if they support mkv, they will have to admit they made a mistake.
[20:58:25] <Dark_Shikari> But until pirates start using ogg, you probably don't have to worry.
[20:58:35] <Yuvi> are there hardware devices supporting mkv that support theora?
[20:58:40] <Dark_Shikari> doubtful
[20:58:59] <ohsix> audio devices don't count? heh; what about games that use ogg/vorbis too
[20:59:14] <Dark_Shikari> ohsix: what I mean is that they're talking about ogg in the context of things other than vorbis
[20:59:18] <mru> games don't count
[20:59:21] <mru> they're already made
[20:59:22] <Dark_Shikari> and yes, games don't count
[20:59:24] <Dark_Shikari> they're already made
[20:59:27] <Dark_Shikari> hence Bink's idea
[20:59:31] <mru> they'll still exist even if a new format is created
[20:59:31] <Dark_Shikari> no backwards compatibility whatsoever
[20:59:52] <ohsix> oic, i must have missed some context
[20:59:55] <Dark_Shikari> I'll make a prediction, by the way
[21:00:20] <Dark_Shikari> There will be no ASIC created in the next 3 years that does 1080p Theora decoding.
[21:00:46] <Dark_Shikari> (not one actually put to silicon and sold in a product, at least)
[21:00:47] <DonDiego> Yuvi: not that i know, but all you need to add in is another decoder, not a demuxer also
[21:01:04] <mru> well, asic decoding is on the way out
[21:01:12] <ohsix> ^
[21:01:12] <DonDiego> and if vorbis worked better in generic containers it would be considered an alternative
[21:01:14] <Dark_Shikari> mru: says the iphone
[21:01:21] <Dark_Shikari> says your set top box
[21:01:22] <mru> it's all semi-programmable accelerators now
[21:01:25] <Dark_Shikari> yes, which are all asics
[21:01:40] <ohsix> but the "s" part isn't theora, its "video"
[21:01:42] <mru> even existing ones could to some extent support theora
[21:01:42] <Dark_Shikari> the CABAC decoder does just CABAC
[21:01:54] <Dark_Shikari> mru: I doubt any idct hardware could
[21:01:57] <mru> what is theora MC like?
[21:02:03] <Dark_Shikari> it's basically a carbon copy of mpeg-2
[21:02:07] <Dark_Shikari> with a different C position
[21:02:12] <Dark_Shikari> (simpler C position, h264-style)
[21:02:24] <mru> so chances are existing MC accels could do it
[21:02:28] <Dark_Shikari> MC is fast though
[21:02:31] <mru> idct, probably not
[21:02:35] <Dark_Shikari> it's bilinear, that's like 5% of the total decoding time
[21:02:48] <Dark_Shikari> idct is more costly probably
[21:02:56] <Dark_Shikari> requires 32-bit math and can't be done by existing hardware
[21:02:57] <mru> MC is more than that on tiny systems
[21:03:10] <Dark_Shikari> I'd be more worried about entropy decoding
[21:03:21] <Dark_Shikari> my calculations show that for 1080p30, assuming every single dct coefficient slot is used
[21:03:26] <Dark_Shikari> and a 64-byte cacheline size
[21:03:31] <Dark_Shikari> the maximum memory bandwidth required is 6GBps
[21:03:44] <Dark_Shikari> for dct coeffs only
[21:03:55] <mru> new set top boxes have ddr3 memory
[21:04:05] <Dark_Shikari> yeah, ddr3 finally solves that
[21:04:07] <Dark_Shikari> it's 6.4GBps
[21:04:34] <mru> TI's coming chips support triple 1080p60 h264
[21:04:43] <mru> that's a lot of memory bandwidth
[21:04:54] <Dark_Shikari> h264 is much less than theora
[21:04:59] <Dark_Shikari> about two orders of magnitude less
[21:05:04] <DonDiego> Dark_Shikari: do you want to bet about that prediction?
[21:05:05] <mru> because it was designed to be efficient
[21:05:20] <mru> DonDiego: he'll be old enough to drink then...
[21:05:24] <Dark_Shikari> lol
[21:05:36] <Dark_Shikari> hmm, good question
[21:05:39] <Dark_Shikari> the annoying thing is that the lines between ASICs and DSPs are blurring as mru said
[21:06:00] <Dark_Shikari> so it might be hard to actually phrase the bet in a way that's relevant in 3 years
[21:06:16] <DonDiego> no, let's bet money, i'm poor :)
[21:06:23] <Dark_Shikari> lol, you think you'll win?
[21:06:30] <DonDiego> yes
[21:06:59] <DonDiego> ok, let's cut out the suspense
[21:07:01] <Dark_Shikari> that requires a lot of things to happen:
[21:07:02] <DonDiego> i know
[21:07:08] <DonDiego> http://www.elphel.com/
[21:07:11] <Dark_Shikari> 1) that theora actually succeed (and not, say vp8)
[21:07:26] <DonDiego> their cameras use theora
[21:07:29] <DonDiego> in hardware
[21:07:43] <Dark_Shikari> encoding?
[21:08:19] <DonDiego> it's a camera..
[21:08:31] <DonDiego> of course it encodes, what else would it do?
[21:08:41] <KotH> transmutate
[21:08:45] <Dark_Shikari> http://www3.elphel.com/sites/default/files/Elphel_Brochure.pdf
[21:08:47] <KotH> ;)
[21:08:48] <Dark_Shikari> I don't see anything about that here
[21:08:53] <DonDiego> http://www.google.com/search?q=theora%20site%3Aelphel.com&btnG=Google+Search
[21:08:53] <Dark_Shikari> nor do I see anything about an ASIC
[21:09:02] <DonDiego> http://www3.elphel.com/linuxdevices/articles/AT3888835064.html
[21:09:09] <Dark_Shikari> it says it captures to JP4 raw
[21:09:10] <DonDiego> http://www3.elphel.com/xilinx/publications/xcellonline/xcell_53/xc_video53.htm
[21:09:20] <Dark_Shikari> um, that's an FPGA, not an ASIC
[21:09:26] <DonDiego> bah
[21:09:38] <Dark_Shikari> the difference between an FPGA and an ASIC is 50 million dollars of tapeout costs
[21:09:42] <DonDiego> just admit defeat ;-p
[21:09:44] <Dark_Shikari> _that_ is what I am betting on
[21:10:00] <KotH> Dark_Shikari: it's 50k to 5mio
[21:10:01] <ohsix> goalposts being moved
[21:10:07] <Dark_Shikari> also, it says it only does 30fps in raw mode
[21:10:08] <KotH> Dark_Shikari: not 50M :=)
[21:10:15] <Dark_Shikari> so, again, no
[21:10:18] <Dark_Shikari> I said 1080p30
[21:10:21] <Dark_Shikari> it doesn't do 30fps outside of raw mode
[21:10:26] <DonDiego> haha
[21:10:38] <Dark_Shikari> because the encoder is too slow
[21:10:38] <DonDiego> admit you were surprised it even existed :)
[21:10:58] <Dark_Shikari> I'm actually surprised they managed to do it in a Spartan 3E
[21:11:03] <Dark_Shikari> that's what surprises me the most
[21:11:08] <Dark_Shikari> That's a fucking awful FPGA
[21:11:47] <Dark_Shikari> It's probably a very very bad encoder of course, but that's a given, cameras always are.
[21:12:07] <Dark_Shikari> good HD video encoders usually use something like a Virtex 4
[21:12:11] <Dark_Shikari> well, then again, it's not good.
[21:12:50] <ohsix> does anything beside the number of LUs have any bearing on it? the names go over speed classes and LUs
[21:13:05] <Dark_Shikari> I don't really know enough about FPGAs to say
[21:13:08] * twnqx has a virtex 5 devel board
[21:13:22] <Dark_Shikari> twngx: doesn't that thing have like 300k logic units?
[21:13:26] <twnqx> ya
[21:13:42] <Dark_Shikari> that is a freaking huge fpga
[21:13:42] <Dark_Shikari> spartan was like a few thousand I recall
[21:13:46] <twnqx> well, depending on the model, those are families
[21:13:53] <ohsix> what makes the good ones usually use virtex4 then, besides the numbers are bigger and you know 2 of their model names ;]
[21:13:54] <twnqx> spartan 3e is pretty big
[21:14:00] <Dark_Shikari> ohsix: more processing power
[21:14:09] <Dark_Shikari> Ateme uses TWO virtex 4s in their hardware encoders
[21:14:18] <twnqx> virtex4 is pretty old :P
[21:14:26] <Dark_Shikari> 60 RD calls per macroblock
[21:14:34] <Dark_Shikari> about 2-3 times more than x264 on max settings
[21:14:40] <Dark_Shikari> in realtime on 1080i30
[21:14:54] <Dark_Shikari> All at once, of course (yay for copy-pasting logic units)
[21:15:09] <ohsix> nice; that doesn't mean they "use" 2, people use fpga to keep the hardware malleable; time can make it better, what they probably do have is plenty of capacity to do even expensive things without a hw changeout
[21:15:36] <twnqx> spartan 3e ranges from 100k to 1.6m gate equivalents
[21:16:15] * twnqx uses spartan 3e on some hobby project
[21:16:28] <twnqx> but next project i'll try spartan 6 :]
[21:17:04] <twnqx> just need to figure where to buy them, none of my usual suppliers have them :(
[21:17:17] <ohsix> they can put cpu/dsp ip in next to their custom blocks too; those take up space but makes stuff way more maintainable
[21:17:26] <Dark_Shikari> ohsix: they do use 2
[21:17:28] <Dark_Shikari> they duplicate the encoder
[21:17:35] <Dark_Shikari> one works a few seconds ahead of the other for lookahead purposes.
[21:17:40] <mru> Dark_Shikari: I've seen the output of the elphel cams
[21:17:43] <mru> not impressive
[21:17:46] <Dark_Shikari> mru: not surprised
[21:17:48] <twnqx> virtex4s can already have a power pc core embedded, no need to waste fpga space on that
[21:17:49] <mru> hardly any mc
[21:17:53] <Dark_Shikari> also, I suspect that encoding is actually easier than decoding for theora
[21:18:02] <Dark_Shikari> because you can parallelize DCT coefficient creation, but not decoding.
[21:18:15] <Dark_Shikari> This would be solved if theora stored a pointer to the start of each set of DCT coeffs
[21:18:23] <Dark_Shikari> well, actually no, not even that, because of zero-runs
[21:18:26] <mru> I think some old linuxtag videos were made with those cameras
[21:18:30] <mru> 2007 or 2008
[21:18:35] <ohsix> twnqx: i'm thinking on situations in particular where the software is the only differentiation
[21:19:06] <twnqx> i wouldn't run the entropy encoding in hardware e.g.
[21:19:08] <ohsix> ie big magic box with a bunch of cards and memory; and the software that actually does something
[21:19:49] <twnqx> virtex 5/6 have dsp features, e.g. fast multipliers, as well
[21:19:55] <Dark_Shikari> twnqx; yes, I know ateme uses a bit cost approximation to avoid full cabac on every RD call
[21:20:03] <Dark_Shikari> i.e. not even what x264 does, a much more parallelizable option
[21:20:12] <Dark_Shikari> since huge amounts of linear stuff in fpgas sucks
[21:20:35] <twnqx> yeah :P
[21:25:25] <Dark_Shikari> mru: I'm guessing on that kind of fpga you can't get much of a fancy motion search.
[21:26:30] <twnqx> never looked into motion searching algorithms
[21:27:13] <twnqx> heh, Dark_Shikari... want a small spartan 3e to try out?
[21:27:34] <Dark_Shikari> I had one a while back, never used it
[21:27:37] <Dark_Shikari> I don't know verilog
[21:28:24] <twnqx> that's a problem then, unless you know VHDL :P
[21:29:03] <Dark_Shikari> nope =p
[21:29:14] <Dark_Shikari> could learn it at some point
[21:29:52] <twnqx> is there any description besides the code how motion search works in x264?
[21:30:29] <Dark_Shikari> http://akuvian.org/src/x264/overview_x264_v8_5.pdf talks about UMH
[21:30:37] <Dark_Shikari> the x264 motion search is not fancy
[21:30:41] <Dark_Shikari> the fanciest thing is tesa
[21:30:56] <Dark_Shikari> eventually I should make it fancy by adding hierarchical search or something
[21:37:23] <twnqx> just reading a few pages in seems to show name for a dozend software patents
[21:37:38] <Dark_Shikari> ?
[21:38:39] <BBB> http://www.ificandream.com/ <- that's ffmpeg
[21:39:03] <Dark_Shikari> BBB: you mean x264
[21:39:05] <Dark_Shikari> and swscale
[21:39:07] <Dark_Shikari> and some ffmpeg
[21:39:15] <BBB> Dark_Shikari: you know too much :) but yes
[21:39:17] <Dark_Shikari> I was at their set last week
[21:39:24] <Dark_Shikari> I work for them
[21:39:25] <BBB> I know you helped them :)
[21:39:33] <Dark_Shikari> good good =p
[21:39:40] <Dark_Shikari> so how are you involved in their plan to fill a house with cameras and sluts
[21:40:09] <BBB> I guess if I'm bored at night I can always watch the girls have a pillowfight & more
[21:40:16] <BBB> my wife might not agree with that
[21:40:24] <Dark_Shikari> lol
[21:40:34] <BBB> you know what I did btw
[21:40:37] <BBB> you suggested me :)
[21:40:56] <Dark_Shikari> Wait, which thing was it that you did
[21:40:59] <Dark_Shikari> I don't remember
[21:41:04] <BBB> lol
[21:41:50] <BBB> I did the rtsp and video/audio input a/v sync
[21:42:09] <Dark_Shikari> ahhh yes
[21:42:14] <Dark_Shikari> you got it working?
[21:42:20] <BBB> I think it works
[21:43:15] <BBB> "works for me"
[21:43:18] <BBB> and the video looks ok
[21:43:21] <BBB> so I think it works in general
[21:44:35] <Dark_Shikari> awesome.
[22:38:14] <mru> ouch, I ran valgrind on python
[22:50:43] <BBB> wbs: sorry I'm gonna be a pain today
[22:51:02] <BBB> I think it's because work is causing me headaches or so
[22:52:50] <janneg> mru: without suppressions file?
[22:53:38] <mru> only whatever valgrind has by default
[22:53:45] <mru> to squash the glibc errors
[22:53:49] <wbs> BBB: no problem, always good when someone questions the things I suggest :-) will get back to the issues tomorrow, though
[22:54:03] <BBB> sure
[22:54:04] <mru> I got a flurry of use-after-free errors
[22:54:05] <mru> scary
[22:56:05] <BBB> is memcpy(..,.., 0); defined?
[22:56:10] <BBB> man memcpy isn't really clear
[22:56:47] <ohsix> n = 0 so nothing is copied
[22:57:12] <BBB> so if (x) memcpy(la, lo, x); is redundant?
[22:57:18] <mru> yes
[22:57:45] <mru> the only thing undefined with memcpy is overlapping buffers
[22:57:52] <mru> and invalid buffers of course
[22:59:10] * BBB trying to simplify random pieces of code
[23:36:22] <CIA-92> ffmpeg: stefano * r22212 /trunk/ffprobe.c: Cosmetics: use consistent spacing in the ffprobe.c options table.