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

[irc at mansr.com]

[00:40:49] <peloverde> http://spectralhole.blogspot.com/2010/08/announcing-aacx.html
[00:47:58] <Dark_Shikari> mru: is there mpegvideo neon MC?
[00:48:11] <Dark_Shikari> e.g. for mpeg-2
[00:48:31] <Dark_Shikari> yup, looks so
[00:48:36] <Dark_Shikari> rnd and no_rnd
[00:48:52] <Dark_Shikari> er wait... I only see no_rnd variants.
[00:48:54] <Dark_Shikari> is there a rnd variant?
[01:04:00] <kierank> hmmm where's bcoudurier when you need him
[01:28:59] <saintdev> peloverde: \o/
[01:36:22] <saintdev> peloverde: what are the green lines on the bottom half?
[02:19:08] <saintdev> peloverde: your patch is a little broken. i assume libavcodec/aac.c is supposed to be libavcodec/aacdec.c ?
[03:06:46] <saintdev> also shouldn't there be more to this than just the extradata logging?
[03:16:53] <Dark_Shikari> does it track bit allocation?
[03:20:34] <saintdev> it doesn't track anything at the moment, because the patch to ffmpeg is b0rked
[06:55:43] <mru> mornings
[06:58:38] <superdump> morning
[07:00:43] <DonDiego> moin
[07:00:53] <kshishkov> god morgon
[07:01:37] <kshishkov> BTW, does anyone know details about that Real guy conversation with Jason?
[07:01:57] <mru> I imagine jason does
[07:02:00] <mru> Dark_Shikari: ^^
[07:02:15] <kshishkov> for some reason I also have such impression
[07:02:37] <Dark_Shikari> lol
[07:03:02] <DonDiego> what real guy, what conversation? :)
[07:03:16] <mru> or maybe the call is still buffering
[07:03:30] <kshishkov> you were going to be employed for enhancing Real Video 4 encoder, don't you remember?
[07:04:04] <Dark_Shikari> lol
[07:04:34] <kshishkov> or maybe they've lost codec sources and seeking to employ FFmpeg guy to recreate them?
[07:07:42] <kshishkov> or maybe that startup needs another H.264-ripoff video codec to grab Chinese market
[07:10:04] <CIA-92> ffmpeg: mru * r24708 /trunk/libavcodec/fft-test.c: fft-test: free buffers before exiting
[07:47:15] <KotH> salut
[07:51:38] <DonDiego> btw, i suggest renaming some of the vp56 files
[07:51:50] <DonDiego> to vpx if they are for vp8 as well
[07:52:04] <mru> does it matter?
[07:52:10] <DonDiego> and vp56rac.c seems like a bad name to me, i did not associate it with rangecoder
[07:52:16] <mru> vp8 includes parts of vp6
[07:52:18] <DonDiego> maybe that's just me though..
[07:53:01] <DonDiego> but some parts are strictly only for vp5/vp6
[07:53:08] <DonDiego> vp56data for example
[07:53:25] <DonDiego> while vp56rac is for all three
[07:53:30] * KotH would rename it to vp56x
[07:53:43] <mru> so they use the same rac
[07:53:45] <mru> big deal
[07:54:05] <kshishkov> vpx would cover theora as well
[07:54:30] <mru> vp5 and vp6 are almost the same
[07:54:31] * kshishkov renames vp6 to vp264
[07:54:34] <DonDiego> kshishkov: yes, so?
[07:54:44] <DonDiego> it's also called libvpx
[07:54:52] <mru> vp8 uses quite a lot from vp5/6
[07:55:07] <mru> there's hardly any of vp3 remaining in vp8
[07:55:10] <DonDiego> that's my point..
[07:55:20] <mru> vp56 uses the vp3 transform
[07:55:35] <mru> stuff is named according to the version where it was introduced
[07:55:46] <Dark_Shikari> what mru said
[07:55:46] <mru> or first reverse engineered, as the case may be
[07:55:50] <KotH> boys..why dont you use prussian blue?
[07:56:03] <mru> KotH: I prefer cerulean blue
[07:56:42] <DonDiego> geez
[07:57:01] <DonDiego> you're pulling the bikeshed card too early
[07:57:27] * kshishkov would rather stick to faluröda, as usual
[07:57:31] <DonDiego> it does not follow that anything you can bikeshed over is inherently pointless
[07:57:38] <KotH> DonDiego: well.. the discussion seems rather pointless to me
[07:57:39] <mru> vp56rac indicates it contains the rac introduced with vp5/6
[07:58:01] <kshishkov> DonDiego: remember Occam's Shovel - "don't rename files without great need"
[07:58:09] <DonDiego> if that is how it's meant to be understood, fine
[07:58:28] <DonDiego> kshishkov: you seem to have misunderstood a concept or two there..
[07:59:00] <kshishkov> otherwise you should start with mpegvideo.c since it's used for some non-mpeg video codecs as well
[07:59:34] <Dark_Shikari> lol
[07:59:37] <KotH> yes, lets rename it to *video.c
[07:59:43] <Dark_Shikari> h263mpeg4flvmpeg1mpeg2
[08:00:02] <DonDiego> invalid argument as well
[08:00:04] <kshishkov> KotH: videox.c
[08:00:09] <Dark_Shikari> lol!
[08:00:18] <DonDiego> stop working on ffmpeg immediately, there's people dying from hunger!
[08:00:22] <kshishkov> Dark_Shikari: ...rv34vc1 too
[08:00:35] <DonDiego> now shut up already
[08:00:38] <kshishkov> DonDiego: definitely not me, so I'll continue
[08:02:41] <Dark_Shikari> DonDiego: RED
[08:02:42] <KotH> kshishkov: no no, it has to have a * in the filename
[08:02:51] <Dark_Shikari> KotH: just to screw up every shell ever
[08:02:58] <KotH> exactly
[08:03:03] <DonDiego> geez
[08:03:07] <kshishkov> good for Windows too
[08:03:11] <DonDiego> shut up already
[08:03:22] <mru> we should add some files with \ in the name
[08:03:30] * KotH never said anything in the first place
[08:03:33] * KotH was just typing
[08:03:54] <mru> that's a type of saying
[08:03:57] <kshishkov> and one file named in Kanji specially for KotH, maybe rename rv3/4
[08:04:28] <mru> no, that should be named in simplified chinese
[08:04:36] <kshishkov> indeed
[08:04:42] <Dark_Shikari> no
[08:04:45] <Dark_Shikari> avs should be chinese
[08:05:03] <kshishkov> that too
[08:05:40] * kshishkov thinks it's time to RE some Russian codec and submit it in Cyrillic
[08:06:04] <kshishkov> maybe that wavelet codec
[08:06:13] <Dark_Shikari> SIF1 is dct-based
[08:06:54] <kshishkov> ok
[08:08:15] <lu_zero> kshishkov: are those interesting or just exotic?
[08:08:32] <kshishkov> lu_zero: exotic, of course
[08:17:45] <lu_zero> I wonder if gcc supports utf8 for the code
[08:18:06] <kshishkov> C# does
[08:18:17] <mru> lu_zero: go read the C99 spec
[08:18:18] <lu_zero> as python and perl
[08:18:22] <mru> it tells what you're allowed to do
[08:18:48] <lu_zero> mru: =)
[08:21:23] <mru> lu_zero: remember that for compiled languages like C it gets more complicated since the source/build character set might not be the same as the execution character set
[08:21:59] <_av500_> is that a cross charset issue?
[08:23:31] <mru> lu_zero: the source file is allowed to contain almost anything
[08:23:42] <mru> but obviously only certain characters are allowed in identifiers
[08:24:09] <lu_zero> that would be the interesting part
[08:24:13] <mru> and what happens to string literals using anything beyond 7-bit ascii is hard to predict
[08:24:34] <lu_zero> あ唖あ　
[08:24:47] <lu_zero> hm
[08:25:02] <kshishkov> works fine indeed
[08:25:05] <lu_zero> и=あ
[08:25:12] <kshishkov> не-а
[08:25:14] <mru> a C identifier is [A-Za-z_][A-Za-z0-9_]*
[08:25:20] <lu_zero> eh
[08:25:34] <lu_zero> so we cannot play using extended utf8
[08:25:41] <mru> not in identifiers
[08:25:46] <mru> that would be ridiculous
[08:25:46] <lu_zero> so a != a might be true
[08:25:57] <mru> ?
[08:26:02] <lu_zero> mru: perl6 let you that
[08:26:09] <mru> I don't care what perl6 does
[08:26:13] <mru> perl6 is vapourware
[08:26:17] <lu_zero> the second a being a not-quite-a-but-same-graphics
[08:26:26] <lu_zero> perl6 is a nice toy you can use
[08:26:51] <mru> oh, it has started condensing to a mist already?
[08:27:22] <lu_zero> it's more or less drinkable
[08:28:26] <lu_zero> you might emerge rakudo
[08:28:33] <lu_zero> and get something working
[08:28:37] <mru> I've heard of rakudo
[08:28:42] <mru> I have no interest in it
[08:30:27] <lu_zero> =)
[08:30:36] <lu_zero> too late?
[08:30:56] <mru> I use perl5 because it works and is available everywhere
[08:31:32] <mru> I'm not going to spend time learning something that a) isn't widely available, b) is a moving target, and c) doesn't solve any of my problems
[08:32:32] <lu_zero> =)
[08:32:57] <lu_zero> I watch it from time to time since is interesting but I'm still using mostly python
[08:33:13] <lu_zero> (because has a better interactive shell)
[08:33:23] <mru> why would I want that?
[08:33:27] <thresh> kshishkov: в Москве опять заработал завод по сжиганию фотографов
[08:34:06] <cartman> hi guys
[08:34:13] <kshishkov> merhaba
[08:34:26] <cartman> Is there a way so stream encrypted video somehow? via open technologies?
[08:34:38] <cartman> hola kshishkov ;P
[08:34:40] <mru> pipe it through ssh
[08:34:46] <cartman> mru: good idea
[08:35:02] <kshishkov> thresh: а еще кого?
[08:36:17] <lu_zero> hm
[08:36:25] <lu_zero> something broke irssi
[08:37:10] <cartman> I mean some kind of DRMd shit
[08:37:24] <cartman> content protection
[08:37:29] <iive> cartman: ssl ?
[08:37:31] <DonDiego> hmm, gas-preprocessor.pl is not working for me..
[08:37:34] <thresh> kshishkov: probably everyone else
[08:37:43] <DonDiego> has it been tested on OS X 10.4 PPC?
[08:37:47] <cartman> iive: ok but we need some kind of pay-per-view system
[08:37:53] <cartman> video should not be copied, easily
[08:38:03] <cartman> is there a protocol for that
[08:38:05] <kshishkov> thresh: это не ваш метод. Вот лагеря...
[08:38:05] <merbzt> cartman: well you need a solution for the key distribution, if you have that then you can stream in whatever way you prefer
[08:38:07] <cartman> maybe RTMP?
[08:38:19] <cartman> merbzt: some kind of FairPlay?
[08:38:33] <thresh> you can easily copy rtmp stream
[08:38:49] <iive> cartman: librtmp would eat you alive.
[08:38:52] <DonDiego> config.log:Unable to identify target architecture at /Users/diego/bin/gas-preprocessor.pl line 49.
[08:38:57] <kshishkov> not if you implement client by Adobe requirements
[08:39:00] <cartman> iive: lol
[08:39:18] <cartman> thresh: I just want casual user to copy it
[08:39:19] <merbzt> cartman: well just encrypt the steams you have then mux them in a container that can support it
[08:39:22] <merbzt> then stream
[08:39:24] <Yuvi> oh hm, I guess it ought to support native compilation
[08:39:24] <cartman> any system can be broken
[08:39:33] <cartman> merbzt: what container supports it?
[08:39:42] <kshishkov> ASF
[08:39:57] <iive> cartman: just using ssl and not storing it in file should be enough.
[08:39:58] <merbzt> ps/ts, asf, mov, mp4 should be able to handle it
[08:40:08] <kshishkov> patch for FFmpeg supporting encrypting in ASF is unwelcome though
[08:40:13] <cartman> iive, merbzt thanx
[08:40:18] <cartman> kshishkov: noted ;)
[08:40:27] <cartman> mp4 should be OK
[08:41:00] <wbs> mp4 isn't streamable though
[08:41:13] <iive> drm is fundamentally broken as the attacker is also the recipient. So if he can see it, he can break it. The point is to make it as hard as possible. Usually by hiding all details in hardware.
[08:41:18] <Yuvi> DonDiego: what does arch print
[08:41:26] <cartman> wbs: uh oh
[08:41:31] <iive> e.g. stb players with conax smartcards.
[08:41:32] <kshishkov> maybe ask Xiph for Ogg encyption? We all know Ogg is good for streaming
[08:41:34] <cartman> wbs: but supports encryption ok
[08:41:39] <mru> Yuvi: doesn't it try to guess from the compiler flags?
[08:41:46] <DonDiego> Yuvi: just running plain 'arch' on the console?
[08:41:47] <mru> which for native compilation wouldn't be set
[08:41:49] <cartman> thank you guys
[08:41:51] <Yuvi> mru: yes, but on a ppc host there is none
[08:41:53] <DonDiego> ppc
[08:43:56] <DonDiego> i'm using gcc 4.2, btw..
[08:44:20] <mru> DonDiego: no gsm for you then
[08:45:50] <DonDiego> mru: ?
[08:46:02] <mru> gsm decoder is broken with gcc 4.2 on ppc
[08:46:36] <kshishkov> I though he wanted FFmpeg for his iPhone 4
[08:46:39] <kshishkov> *thought
[08:46:42] <DonDiego> with or without gas-preprocessor?
[08:46:50] <mru> C code
[08:46:55] <DonDiego> i have no iphone
[08:47:08] <DonDiego> ouch :-/
[08:47:21] <DonDiego> maybe it's time to dig out that old gcc 4.0.x..
[08:47:22] <kshishkov> then why do you need gas-preprocessor?
[08:47:28] <mru> DonDiego: then you get no vp8
[08:47:40] <mru> kshishkov: gas-preprocessor is required on mac/ppc too
[08:48:09] <kshishkov> what for?
[08:48:15] <mru> for asm of course
[08:48:18] <DonDiego> Yuvi: any idea what might be going on? i'm trying to make sense of the perl, but it's, ummm, perl...
[08:48:32] <Yuvi> DonDiego: basically, it detects arch based on cflags
[08:48:32] <mru> DonDiego: we know what's going on
[08:48:39] <Yuvi> you're natively compiling, so there are none
[08:48:57] <DonDiego> so the tool is broken?
[08:49:45] <Yuvi> I'm deciding whether to look for __ppc__ or something in $cc -dM -E or assume `arch` if we don't find a known arch in cflags/binary name
[08:49:50] <cartman> does ffmpeg support any encryped media format, except of course DVD
[08:50:29] <mru> Yuvi: maybe add fallback to qx/arch/ or qx/uname -m/
[08:51:02] <mru> I'd look at arch and use that if ppc
[08:51:05] <mru> otherwise barf
[08:51:25] <mru> they don't have native build on arm
[08:51:38] <Yuvi> jailbroken does
[08:51:45] <mru> really?
[08:51:52] <mru> well, check for ppc or arm then
[08:52:02] <mru> reject anything else
[08:52:09] <mru> it doesn't make sense using it for others
[08:52:18] <Yuvi> yeah
[08:52:41] <mru> Yuvi: btw, I applied a different h264 idct8x8
[08:52:49] <mru> I happened to have a slightly faster one
[08:53:16] <Yuvi> ah cool, now I have to port it to x264 ;)
[08:53:45] <mru> it's ~5 cycles faster than yours
[08:54:15] <mru> the transform core
[08:54:21] <mru> the load/store parts are the same
[08:54:31] <Dark_Shikari> what was different about it?
[08:54:42] <mru> probably different scheduling
[08:55:02] <mru> those 3-insn macros really kill scheduling
[08:56:47] <DonDiego> Yuvi: let me know when you have committed a fix for the tool, i will test it right away
[08:56:54] <Dark_Shikari> maybe we need a neon version of that C64x asm thing
[08:56:58] <Dark_Shikari> where it auto-schedules for you
[08:57:06] <Dark_Shikari> but you tell it what instructions to use
[08:57:18] <mru> do you really believe that thing works?
[08:57:54] <mru> scheduling ties in with register allocation too
[08:58:00] <mru> which we know is hard
[08:58:24] <kshishkov> that's where combinatorics comes in handy
[08:58:30] <Dark_Shikari> only when you're nearly out of registers
[08:58:34] <mru> that's where a brain comes in handy
[08:58:49] <mru> Dark_Shikari: we're often using all or almost all registers
[08:59:15] <Yuvi> c64x has two separate register files, and separate alus for each set
[08:59:26] <mru> with two cross-paths
[08:59:41] <mru> any alu up can take one operand from the other register file
[08:59:44] <mru> *op
[08:59:50] <Yuvi> yeah, but it's definately still a hard problem for a scheduler
[09:00:02] <mru> even more so
[09:00:17] <Dark_Shikari> c64x is hard enough that it's hard for a _human_
[09:00:38] <mru> you have to look ahead a lot to know which register file to load stuff into
[09:00:53] <merbzt> peloverde: how high frequencies can you hear ?
[09:00:57] <mru> you can't just do dumb linear pass
[09:02:32] <Dark_Shikari> mru: can't you just, say, do two idct in parallel?
[09:02:46] <mru> that might not be optimal
[09:03:04] <Dark_Shikari> why wouldn't it be?
[09:03:29] <mru> and you'd have to structure the code that way at a high level too
[09:03:36] <mru> the compiler isn't going to do that for you
[09:03:51] <Dark_Shikari> of course
[09:03:57] <Dark_Shikari> I meant that would be an easy way to use it
[09:04:28] <mru> sometimes simply doing the same thing on both sides might be good enough
[09:04:35] <mru> or even optimal
[09:05:00] <mru> but suppose part of the function is load/store bound and another part is multiplication-bound
[09:05:24] <mru> then you'd want to use both ls units in that part and both multipliers in that part
[09:05:37] <mru> and they're not entirely symmetrical either
[09:05:45] <mru> a few things can only be done on one side or the other
[09:07:33] <Yuvi> DonDiego: should be fixed
[09:08:02] <Dark_Shikari> mru: and despite all these restrictions the c64x+ is one of the most power-hungry dsps >_>
[09:08:16] <mru> restrictions?
[09:09:01] <Dark_Shikari> you know, the separate register files, all this weird stuff
[09:09:40] <mru> blackfin is hardly any less weird
[09:09:52] <mru> it has like 5 different types of registers
[09:10:18] <mru> like m68k split data/pointer but worse
[09:10:44] <Dark_Shikari> lol
[09:10:57] <kshishkov> any sane DSP for comparison?
[09:12:55] <mru> C64x is rather sane as DSPs go
[09:12:59] <Dark_Shikari> gumboot would say videocore
[09:13:10] <mru> but it's not open
[09:13:15] <mru> we can't compare it
[09:13:28] <Dark_Shikari> Well, Gumboot is usually unusually willing to blab about it
[09:13:37] <Dark_Shikari> to the point where other people that work at his place get very worried about him =p
[09:13:47] <mru> but that just blabber
[09:14:07] <mru> until I have an arch ref manual, I'm not interested
[09:14:16] <Dark_Shikari> 512-bit SIMD is pretty nice though.
[09:14:19] <Dark_Shikari> is there any other dsp with that?
[09:14:22] <mru> if it's true
[09:14:39] <kshishkov> use 1024-bit SIMD with those 8x8 blocks
[09:15:24] <mru> ivahd has some pretty powerful simd inside
[09:15:34] <mru> but Dark_Shikari insists on calling it an asic
[09:15:41] <mru> in a snarky tone
[09:16:09] <Dark_Shikari> you can have both
[09:16:27] <Dark_Shikari> OMAP is a DSP with ASIC stuff
[09:16:41] <mru> now you're confusing terms again
[09:16:53] <mru> omap3 is an arm with an iva2 block
[09:17:01] <Dark_Shikari> well yes I know
[09:17:05] <mru> iva2 contains a c64x+ dsp and a leon accelerator
[09:17:08] <Dark_Shikari> yes
[09:17:18] <Dark_Shikari> I would define "asic stuff" as anything that isn't a synchronous instruction callable from the main CPU (and does specialized tasks)
[09:17:21] <Dark_Shikari> for example
[09:17:39] <Dark_Shikari> the AES unit in the new Intel chips is not that, because it's a set of instructions
[09:17:42] <mru> leon contains an arm968 and special blocks
[09:17:44] <Dark_Shikari> and you call them like any other instruction
[09:17:47] <mru> some of which are programmable
[09:17:54] <mru> the motion estimation engine for example
[09:18:14] <mru> Dark_Shikari: that's an absurd definition and distinction
[09:18:39] <Dark_Shikari> It doesn't matter how absurd it is
[09:18:44] <Dark_Shikari> from a practical perspective, it's all that matters
[09:18:50] <Dark_Shikari> because when programming, they're two very different things
[09:19:09] <mru> it's just asymmetric multi-processing
[09:19:13] <mru> nothing bad about that
[09:19:19] <Dark_Shikari> with each CPU being special-purpose
[09:19:25] <mru> you're just entrenched in x86-land
[09:20:20] <mru> and of course a design like ffmpeg or x264 assumes tightly coupled execution units
[09:28:55] <Dark_Shikari> you're missing the "AS"
[09:28:57] <Dark_Shikari> "application specific"
[09:29:05] <Dark_Shikari> if each CPU is special purpose, by definition, it's application specific
[09:29:07] <Dark_Shikari> and thus an ASIC
[09:29:42] <mru> yes, they're special-purpose for e.g. video processing
[09:30:01] <mru> some are indeed hardwired for specific standards
[09:30:04] <mru> but not all
[09:37:38] <CIA-92> ffmpeg: stefano * r24709 /trunk/ (5 files in 2 dirs):
[09:37:38] <CIA-92> ffmpeg: Deprecate avcodec_check_dimensions() in favor of the new function
[09:37:38] <CIA-92> ffmpeg: av_check_image_size() declared in libavcore/imgutils.h.
[09:37:38] <CIA-92> ffmpeg: stefano * r24710 /trunk/libavcore/imgutils.c: Clarify av_check_image_size() log message.
[09:37:39] <CIA-92> ffmpeg: stefano * r24711 /trunk/ (46 files in 3 dirs):
[09:37:40] <CIA-92> ffmpeg: Remove use of the deprecated function avcodec_check_dimensions(), use
[09:37:40] <CIA-92> ffmpeg: av_check_image_size() instead.
[09:43:27] <CIA-92> ffmpeg: stefano * r24712 /trunk/doc/APIchanges: Add APIchanges entry for the av_check_image_size() addition.
[09:56:34] <DonDiego>  /opt/local/include/zconf.h:373:6: warning: "_LARGEFILE64_SOURCE" is not defined
[09:56:57] <mru> wtf
[09:56:57] <DonDiego> mru: does this warrant adding _LARGEFILE64_SOURCE to CPPFLAGS?
[09:57:02] <mru> no
[09:57:52] <mru> we already add -D_FILE_OFFSET_BITS=64
[09:57:57] <mru> which is a bit more portable
[10:00:26] <mru> zlib is apparently broken, it's not our job to fix it
[10:00:37] <mru> why does it even care?
[10:00:44] <mru> it doesn't even do file io
[10:01:21] <twice11> Maybe ABI issues with off_t?
[10:01:53] <mru> well, those people are known to royally fuck up their interfaces
[10:01:58] <twice11> Hmm, no, off_t is influenced by _FILE_OFFSET_BITS, not _LARGEFILE64_SOURCE
[10:02:26] <CIA-92> ffmpeg: diego * r24713 /trunk/doc/general.texi: Extend the gas-preprocessor section with basic installation instructions.
[10:05:17] <cartman> hyc: ping
[10:09:04] <DonDiego> mru: http://pastebin.org/450614
[10:09:37] <DonDiego> huffman seems like a reasonably general thing to deserve its own config_ entry..
[10:11:57] <mru> ok
[10:17:22] <twnqx> DonDiego: another stupid legal question. if i intend to use GPL-enabled ffmpeg with a GPL app, but want that app to include a private key for data signing, can i exclude that key fromthe source distribution, even if the remaining compiled app will not fulfill the intended purpose any more?
[10:18:29] <mru> read the key from a file at runtime
[10:18:33] <mru> problem solved
[10:18:47] <twnqx> too easy to reverse engineer, then
[10:18:58] <mru> huh
[10:19:38] <mru> are you trying to hide a "secret" key in a gpl app?
[10:20:00] <mru> security by obscurity, without the obscurity
[10:20:12] <twnqx> what good would the key be to prove the data can be trusted if everyone could just sign any random data with it?
[10:20:34] <mru> what are you trying to achieve?
[10:21:15] * mru makes note not to trust any signed mail from twnqx 
[10:21:20] <twnqx> i want to replace an existing file fingerprinting tool with a libavformat/codec based one
[10:21:43] <twnqx> it sends the fingerprints, signed, to a server
[10:22:08] <ohsix> enroll user keys pki style
[10:22:25] <twnqx> not achievable in the intended context
[10:22:33] <twnqx> dunno if you ever heard of anidb.net's avdump
[10:22:57] <KotH> twnqx: are you working on anidb?
[10:23:14] <twnqx> "working on"... a contributor, at best
[10:23:26] <twnqx> but the current avdump can't handle .mkv with header compression
[10:23:36] <twnqx> it just crashes.
[10:23:39] <DonDiego> lu_zero: do you mind if i add an issue for the dct_quantize_altivec issue in roundup and assign it to you?
[10:23:50] <mru> what's the issue?
[10:24:02] <Dark_Shikari> now this is fun
[10:24:09] <Dark_Shikari> we can now Vuze to the hall of shame
[10:24:18] <Dark_Shikari> they're distributing a nonfree ffmpeg (compiled with libfaac) and give no credit
[10:24:36] <lu_zero> DonDiego: fine but would take a bit to check what's wrong with it
[10:24:40] <Dark_Shikari> *now add
[10:24:41] <Dark_Shikari> DonDiego: ^
[10:25:04] <DonDiego> lu_zero: same about the trillion decls before statements warnings in libpostproc..
[10:25:16] <ohsix> twnqx: you can't put a "use this as contributor key" somewhere on the submitters login thing
[10:25:33] <DonDiego> Dark_Shikari: yes?
[10:26:10] <Dark_Shikari> DonDiego: LGPL violation
[10:26:29] <DonDiego> is there an issue for it?
[10:26:32] <twnqx> ohsix: no, it's already to complex (run avdump.exe -ac nick:password file ...) for many people
[10:26:34] <Dark_Shikari> Someone should add it.
[10:27:17] <ohsix> seems the key might be better than the username thing, and you could separate the submission phases
[10:27:20] <CIA-92> ffmpeg: lu_zero * r24714 /trunk/libavformat/ (rtsp.c rtsp.h):
[10:27:20] <CIA-92> ffmpeg: Preserve status reason
[10:27:20] <CIA-92> ffmpeg: It is used to provide meaningful error messages.
[10:28:02] <J_Darnley> The (L)GPL requires someone to produce the source code upon request, doesn't it?
[10:28:19] <cartman> J_Darnley: it should be available without asking
[10:28:31] <Dark_Shikari> Or they should give (without asking) an offer to provide it.
[10:28:35] <DonDiego> J_Darnley: read it..
[10:29:11] <twnqx> maybe i should just read up which pieces are non-gpl and replace them :\
[10:29:19] <twnqx> err are gpl or worse
[10:29:26] <Dark_Shikari> well perhaps more importantly they're distributing a version which is inherently a gpl violation...
[10:29:32] <Dark_Shikari> anyways put up an issue
[10:30:06] <CIA-92> ffmpeg: diego * r24715 /trunk/ (configure libavcodec/Makefile): Add a CONFIG_ variable for generic Huffman routines.
[10:30:30] <J_Darnley> Okay I will
[10:33:49] <DonDiego> Dark_Shikari: seriously, what about vp56rac.c --> vp56rangecoder.c ?
[10:33:57] <mru> why?
[10:34:13] <mru> are you bored down in italy?
[10:34:24] <mru> so you entertain yourself by renaming files and sorting lists?
[10:34:46] <iive> DonDiego: the name is too short, it should be more deceptive. e.g. it would look better as vp5_and_vp6_range_coder.c
[10:35:05] <DonDiego> because it's more consistent with the other rangecoder
[10:35:17] <DonDiego> and because it's easier to guess what the file is supposed to contain
[10:35:18] <mru> maybe it's the one that's wrong
[10:35:26] <DonDiego> usability is not a bikeshed
[10:35:39] <mru> if you know vp6 you'll know what it means
[10:35:46] <mru> otherwise you don't care anyway
[10:36:03] <KotH> DonDiego: but it can easily become one
[10:36:03] <ohsix> isn't it a job for ctags if someone really wants some visibility beyond filenames
[10:36:18] <KotH> DonDiego: especially when people disagree what usability means... which is always the case
[10:36:27] <jai> the meaning is quite clear to those who work with that file
[10:36:36] <DonDiego> there are the people that want to learn their way around the codebase
[10:36:36] <mru> and that's what matters
[10:36:42] <Dark_Shikari> DonDiego: should we rename cabac to context_adaptive_binary_range_coder.c?
[10:36:53] <Dark_Shikari> or maybe cab_arithmetic_coder?
[10:37:03] <DonDiego> KotH: thanks for destroying any attempt at fruitful discussion, thx
[10:37:11] <ohsix> ar_cab
[10:37:15] <mru> DonDiego: there is no fruit on this tree
[10:37:21] <Dark_Shikari> we could rename it to vp56_cabac.c
[10:37:23] <Dark_Shikari> to piss off freetards
[10:37:36] <DonDiego> Dark_Shikari: that's a common abbreviation, but i have not encountered rac before
[10:37:43] <KotH> DonDiego: uhmm.. you shouldnt encode information of that level into filenames. such info belongs to a design describing document
[10:37:55] <Dark_Shikari> DonDiego: except you know, in 10000 places in ffmpeg
[10:38:03] <Dark_Shikari> should we rename "rl" to "runlength"?
[10:38:10] <jai> then you havent read the snow code for example
[10:38:19] <Dark_Shikari> or maybe to vlc.c?
[10:38:21] <Dark_Shikari> that would be more accurate
[10:38:24] <Dark_Shikari> or maybe to variable_length_code.c?
[10:38:31] <Dark_Shikari> or maybe we should change intmath to integer_math.c?
[10:38:41] <DonDiego> ok, whatever
[10:38:43] <Dark_Shikari> really, if you want to change this, you have to justify changing everything else.
[10:38:47] <Dark_Shikari> it's just not consistent.
[10:38:58] <Dark_Shikari> if anything, I would propose rangecoder -> rac for consistency's sake lol
[10:39:19] <Dark_Shikari> but it's mostly pointless, if there's no good reason to change it, don't.
[10:39:39] <mru> pointless renaming only makes history browsing harder
[10:40:02] <mru> and confuses everyone who was accustomed to the old name
[10:40:04] <Dark_Shikari> +1
[10:40:37] <mru> sometimes contents drift enough to make a name truly deceptive
[10:40:41] <mru> then it should be changed
[10:41:15] <J_Darnley> What's the correct type for a license violation bug report?
[10:41:16] <cartman> integer_math.c is spot on, good idea
[10:41:41] <mru> cartman: please don't feed this troll
[10:41:45] <cartman> ;>
[10:42:56] <J_Darnley> Issue created: https://roundup.ffmpeg.org/issue2150
[10:44:18] <DonDiego> J_Darnley: FFmpeg, not FFMpeg - and thanks for the issue entry
[10:45:02] <kshishkov> FF/mpeg
[10:45:06] <DonDiego> J_Darnley: could you add URLs to the places you got the package from?
[10:45:24] <J_Darnley> Its downloaded theough the vuze client
[10:45:30] <J_Darnley> *through
[10:45:31] <DonDiego> J_Darnley: the correct type is "none"
[10:45:42] <J_Darnley> I wouldn't let me choose none
[10:45:48] <DonDiego> "- no selection -"
[10:46:08] <J_Darnley> I had that
[10:46:11] <cartman> "http://flip.yellosoft.us/ is a handy tool for inverting a file. 0's flip to 1's, 1's flip to 0's."
[10:46:32] <DonDiego> ok, roundup sucks, so it's very much possible
[10:48:41] <DonDiego> mru: say, why did you revert the autoreconfiguration?
[10:49:13] <mru> because people complained
[10:49:29] <DonDiego> so?
[10:49:29] <mru> and I realised it was impossible to make it work correctly
[10:49:41] <DonDiego> people complain to you all the time and get ignored :)
[10:49:59] <mru> this time they had valid objections
[10:50:08] <mru> and I realised it was impossible to make it work correctly
[10:52:22] <cartman> mru: will you remove     check_cflags -Werror=missing-prototypes from configure, if I complain too much? :)
[10:52:28] <mru> no
[10:52:40] <cartman> why was I expecting that answer :-)
[10:52:40] <DonDiego> J_Darnley: also, i see nothing attached to the issue..
[10:52:45] <mru> there are no valid objections against that feature
[10:52:50] <J_Darnley> try again
[10:53:01] <DonDiego> got it now, thx
[10:53:07] <J_Darnley> the attachment was lost when it rejected the new issue
[10:53:14] <cartman> mru: :)
[11:06:57] <J_Darnley> I added a new note with a place where anyone can download the package from vuze.com
[11:15:28] <Compn> hmm, i never liked vuze
[11:18:48] <jai> no clue why someone would want to write a torrent client in java
[11:20:41] <Compn> cross-platform :P
[11:22:16] <jai> well there are decent native clients on most platforms anyway :)
[11:22:47] <Compn> source isnt in http://azureus.cvs.sourceforge.net/viewvc/azureus/plugins/
[11:24:22] <Compn>  #azureus-dev on freenode for devel channel
[11:24:39] <kshishkov> Compn: and reference BT client was written in Python IIRC
[11:24:39] <Compn> J_Darnley : if you wanted to ask them directly for the source ?
[11:26:48] <kierank> azeureus is  slow as hell
[11:27:10] <kierank> however, it can be patched to download pieces in order which is very useful
[11:27:31] * kshishkov is also concerned about memory usage
[11:27:48] <KotH> kierank: why use azureus, when the python bt client downloads twice as fast?
[11:28:01] * kshishkov used rtorrent
[11:28:04] <KotH> kierank: with a 10th of the memory consumption and even less of cpu
[11:28:08] <kierank> iirc the python bittorernt client is unsupported
[11:28:22] * Compn prefers to download rarest pieces first, in case of seeder absence
[11:28:23] <KotH> it works, it doesnt need support
[11:28:46] <kierank> i also can't be bothered to figure out who to patch rtorrent or the python client whereas someone wrote a 2 line patch for azeureus
[11:28:49] <kierank> s/who/how
[11:29:16] <KotH> patching python code is quite easy, even if you dont know python
[11:29:24] <kierank> but the codebase is massive
[11:29:28] <KotH> while with java you have to know java and xml in detail
[11:29:30] <KotH> lol
[11:29:39] <KotH> and the azureus code base isnt massive?
[11:29:44] <kshishkov> and less effort recompiling python :)
[11:29:45] <kierank> my point is that the work was already done in azereus
[11:30:03] <KotH> my point is that there is no point in using java ;)
[11:30:10] <Dark_Shikari> more importantly, it's a pile of proprietary crap
[11:30:18] <KotH> Dark_Shikari: hmm?
[11:30:22] <KotH> Dark_Shikari: azureus is gpl, no?
[11:30:25] <Dark_Shikari> wrong
[11:30:28] <Dark_Shikari> http://en.wikipedia.org/wiki/Vuze#License_change
[11:30:28] <KotH> o_0
[11:30:30] <Compn> it changed
[11:30:41] <Dark_Shikari> It's now proprietary
[11:30:50] <Dark_Shikari> It's also classified as adware.
[11:31:01] <KotH> wtf
[11:31:14] <Compn> they did that so they could offer official downloads from mpaa/riaa , i think
[11:31:15] <Dark_Shikari> This is what happens when free software gets eaten by the proprietary monster.
[11:31:17] <Compn> cant have open source drm
[11:31:21] <KotH> that's a very good reason not to touch it ever again
[11:31:52] <KotH> Compn: you cant have cliend side security
[11:32:29] <jai> kierank: libtorrent/rtorrent can handled ordering right?
[11:32:35] <kierank> dunno
[11:33:11] <Compn> so did anyone join #azureus-dev and ask them for plugin source?
[11:33:16] <DonDiego> can i borrow the local horde of trolls for a raid?
[11:33:30] <J_Darnley> Compn: Should I do it?
[11:33:31] <Dark_Shikari> DonDiego: which raid are you planning to go on?
[11:33:38] <DonDiego> i'm getting resistance to removing deps on ffmpeg internals on the mplayer-dev-eng ml..
[11:33:44] <Dark_Shikari> Trial of the FFcrusader?
[11:33:46] * Dark_Shikari runs
[11:33:56] <Compn> J_Darnley : if you have time, but otherwise one of us will get around to it
[11:34:06] <Dark_Shikari> DonDiego: then break those APIs repeatedly until they accept it
[11:34:09] <Compn> i will if you dont, is what i'm saying
[11:34:21] <Dark_Shikari> or even better, do what x264 does
[11:34:26] <kierank> i'll provide covering fire J_Darnley
[11:34:26] <Dark_Shikari> and detect mplayer and refuse to build
[11:34:34] <Dark_Shikari> forcing them to accept =p
[11:34:34] <DonDiego> it's about the libavutil/x86_cpu.h header, not really much to break there
[11:34:47] <DonDiego> but mplayer only compiles with libavutil in the source tree because of it
[11:34:48] <Dark_Shikari> oh.  cpu detection stuff
[11:34:59] <Dark_Shikari> libav*'s cpu detection handling is total bullshit anyways
[11:35:08] <Compn> didnt we already agree you could duplicate that header in mplayer? :P
[11:35:16] <KotH> DonDiego: what's the issue exactly?
[11:35:28] <kierank> J_Darnley, awww we forgot to sync watches
[11:35:37] <J_Darnley> :(
[11:36:52] <DonDiego> KotH: i'm getting irrational opposition to lessening ffmpeg dependencies
[11:37:14] <DonDiego> http://lists.mplayerhq.hu/pipermail/mplayer-dev-eng/2010-August/065652.html
[11:39:00] <KotH> DonDiego: add it to the source tree and be done with it
[11:39:20] <KotH> DonDiego: but be aware that you will get a lot of resistance the moment you try to remove lavc
[11:39:31] <DonDiego> KotH: as i said, there is irrational opposition
[11:39:36] <KotH> lol
[11:39:48] <KotH> filters depending on information from codecs is not irrational
[11:40:28] <KotH> and no, i dont even think that the x86_cpu.h opposition is irrational, they all have valid reasons
[11:40:35] <DonDiego> i'm talking about x86_cpu.h
[11:40:41] <KotH> i rather think that your calling them irrational is rather irrational
[11:40:47] <twnqx> there is a nice gain for motion compensated filters from the codec's motion vectors...
[11:42:04] <DonDiego> KotH: funny, if i mention library copies in here everybody goes "how dare you even think" and on dev-eng nobody bothers..
[11:42:09] <DonDiego> so who is irrational?
[11:42:21] <KotH> DonDiego: lol
[11:42:29] <KotH> DonDiego: 1) copying libraries is bad, even on -dev-eng
[11:43:04] <KotH> DonDiego: but you insisnt on removing dependency of lavu, hence copying the one small file is the lesser evil than fighting with you over yet another bikeshed
[11:43:14] <DonDiego> it seems you haven't read the thread ..
[11:43:23] <KotH> i've just read it
[11:43:26] <DonDiego> comment there instead of discussing here
[11:50:58] <KotH> DonDiego: er.. forget what i said...
[11:51:10] <KotH> DonDiego: after rereading i get what you were saying
[11:51:30] * KotH blames spaam 
[11:51:54] <spaam> dont blame me.. blame mru this time
[11:52:01] * mru blames spaam 
[11:52:04] <spaam> :(
[11:52:18] <cartman> asking again, if anyone have any ideas: does ffmpeg support any encrypted container?
[11:52:21] <cartman> except DVDs
[11:52:31] <KotH> afaik no
[11:52:42] <kshishkov> cartman: no DVDs either
[11:52:50] <cartman> kshishkov: true, forgot it :)
[11:52:59] <kshishkov> IIRC it can decrypt some ASFs though
[11:53:01] <mru> KotH: what's the -cryptokey option then?
[11:53:04] <KotH> there were patches to support zattoo, but the author didnt care enough about them go get them past michael
[11:53:08] <kshishkov> and MXF?
[11:53:10] <KotH> mru: it's an illusion
[11:53:10] <cartman> I remember seeing something like encrypted MXF streams
[11:53:12] <cartman> yeah!
[11:53:29] <cartman> MXF might be a streaming option then
[11:53:58] <iive> cartman: mxf is enough obfuscation on its own.
[11:54:08] * kshishkov tries to express strong disbelief in suitability
[11:54:15] <cartman> iive: we will work with a content provider
[11:54:22] <cartman> they need proof that content cannot be copied
[11:54:23] <kierank> vlc has some crypto
[11:54:28] <cartman> with a simple copy/paste
[11:54:36] <cartman> kierank: for which containers?
[11:54:46] <kierank> i think an old version of itunes
[11:54:52] <kierank> it breaks the drm
[11:55:13] <cartman> hmm
[11:56:24] <cartman> whole DRM thing is a mess
[11:57:06] <kierank> go and buy videoguard
[11:57:11] <kierank> problem solved
[11:57:21] <twice11> DRM on PCs can not work in my oppinion. If the processor gets the keys to decode a stream, a cracker can get it too.
[11:57:40] <cartman> twice11: I just need a protection against simple copy/pastew
[11:57:45] <cartman> maybe add some junk to headers :D
[11:58:01] <mru> xor it wit cartmancartmancartman...
[11:58:14] <cartman> that'll save me from copy/paste
[11:58:17] <cartman> ultra crypto
[11:58:20] <cartman> double rot11
[11:59:12] <twice11> So the idea is to use ffmpeg to display a video stream but you want it to not play the same data if found on your disk, right?
[11:59:24] <twice11> It's typically double rot13, though.
[12:00:04] <KotH> cartman: you want to distribute content to user, where it is decoded on the user side, and want to proove that the content cannot be copied?
[12:00:05] <twice11> So what you are looking for is transport obfuscation.
[12:00:12] <cartman> KotH: yup
[12:00:17] <KotH> cartman: do you also want to proove that the earth is flat?
[12:00:18] <cartman> but not ultra drm
[12:00:24] <cartman> we are talking about casual use
[12:00:49] <KotH> if you define it just cassualy, then no stream can be coppied... or all of them
[12:00:58] <KotH> if you can decode it, you can copy it
[12:01:05] <cartman> KotH: not via copy/paste
[12:01:09] <KotH> lol right
[12:01:11] <cartman> I just want to forbid that
[12:01:17] <twice11> You mean Ctrl+C, Ctrl+V?
[12:01:21] <cartman> people who can dump the stream should do
[12:01:23] <KotH> you cannot copy any stream with copy&paste, as no client i know about supports that :)
[12:01:25] <cartman> I salute them :OP
[12:01:26] <twice11> I never manage to do that on video streams.
[12:01:29] <kierank> what's wrong with rtmp
[12:01:40] <cartman> I want local file encryption :)
[12:01:44] <cartman> stream is second choice
[12:01:46] <kshishkov> kierank: everything!
[12:02:02] <kierank> use the adobe drm
[12:02:12] <kierank> that does some sort of local file encryption
[12:02:12] <twice11> So you want local file encryption, and have that file playing back, but not a copy?!
[12:02:36] <twice11> How are you going to find out which file is the original, playable file and which file is the copy?
[12:02:53] <mru> append _do_not_copy to the filename
[12:02:58] <mru> oh wait
[12:03:04] <mru> copies are called "copy of ..."
[12:03:05] <kshishkov> xor headers with its full name
[12:03:13] <twice11> Or is your intention to tie playback to a certain user? a certain computer?
[12:03:17] <mru> at least if you use ctrl-c/ctrl-v in windows
[12:03:29] <mru> so refuse to play if the filename is 'copy of *'
[12:03:30] <KotH> cartman: turkish customer?
[12:03:39] <cartman> KotH: indeed
[12:03:42] <twice11> mru: Only if you Ctrl+V in the same directory.
[12:03:57] <KotH> cartman: then i'd prove that with standard windows tools (ie wmp) it is not possible to copy it
[12:04:06] <KotH> cartman: that should be easy to proove
[12:04:09] <mru> cartman: so turkish security is good enough?
[12:04:11] <KotH> cartman: as wmp cannot do anything
[12:04:34] <KotH> mru: no, turkish people are generally digital immigrants or digital foreigners
[12:04:45] <KotH> mru: linux or oss doesnt exist there
[12:04:52] <KotH> mru: and computers cost twice as much as in .ch
[12:05:18] * KotH remembers seeing a dual speed ide cdrom for 90USD back in 2000/2001
[12:06:15] <kshishkov> KotH: at least Ukraine had two own Linux distros, one of them even pushed Ukrainian translations for some manpages to mainline
[12:06:36] * cartman goes to read about ISMACryp
[12:06:42] <cartman> you guys are too helpful
[12:06:44] <cartman> ;)
[12:06:52] <twice11> cartman: XOR the headers with the cluster/inode/whatever-the-filesystem-you-have-uses number.
[12:07:04] <twice11> Works until defrag...
[12:07:13] <KotH> cartman: taht's because the very task you are trying to do is ... futile
[12:07:27] <cartman> KotH: it should be futile
[12:07:28] <KotH> cartman: client side security does not work, not at all
[12:07:29] <kshishkov> for some reason I treat encryption as something to be broken, not used or added
[12:07:33] <cartman> it should be able to be copied
[12:07:41] <cartman> it should just prevent usual user
[12:07:45] <KotH> kshishkov: even pgp?
[12:08:01] <KotH> cartman: the usual user in .tr will not be able to copy it anways :)
[12:08:10] <cartman> KotH: sure?
[12:08:14] <cartman> a local file on usb disk
[12:08:17] <cartman> they'll just copy :)
[12:08:20] <KotH> cartman: at least not those i know
[12:08:34] <mru> KotH: http://xkcd.com/763/
[12:08:35] <KotH> they can hardly type their name correctly
[12:08:38] * cartman will install rootkit and disable file copy on *.mkv
[12:08:39] <kshishkov> KotH: I've never used it.
[12:08:51] <KotH> mru: way to advanced!
[12:08:55] <KotH> s/to/too/
[12:09:46] <KotH> mru: computer education level in .tr is lower than in .ch 20y ago
[12:10:03] <mru> so what's cartman doing here?
[12:10:07] <kshishkov> yes, we all know how it was in .ch 20 years ago
[12:10:14] <KotH> mru: coupled with the typical turkish behavior of bragging about what they can do, know etc...
[12:10:24] <twice11> cartman: As long as you don't know how to tell original from copy of the same data on the same computer, there is no encryption going to help.
[12:10:26] <cartman> mru: I am not educated
[12:10:28] <kshishkov> KotH: ever heard of Konrad Zuse?
[12:10:36] <mru> cartman: ah, that's ok then
[12:10:50] * cartman sniffs and go back to his cave
[12:10:57] <twice11> cartman: Just to make I point: *I* don't know how to tell original from copy.
[12:11:18] <KotH> mru: when my aunt (~70y old) asked for a computer, and i thaught here a week the most basic types of use, she became very confused that all those "specialists" knew less then she did
[12:11:21] <cartman> if you could play from memory
[12:11:23] <twice11> Except for the cluster/inode suggestion I made above.
[12:11:28] <cartman> you could progressively decrypt
[12:11:31] <KotH> kshishkov: what about him?
[12:11:40] <cartman> then people would only be able to dump the stream
[12:11:42] <cartman> not copy the file
[12:11:57] <kshishkov> KotH: he tried to push computer awareness level in .ch  long time ago
[12:12:02] <twice11> I think your task is *not* about streaming...
[12:12:03] <J_Darnley> LOL, an unofficial response: <The_8472> well, i guess it could be replaced if someone owning the respective copyrights complains.
[12:12:19] <KotH> kshishkov: .ch? you mean .de
[12:12:34] <cartman> Konrad Zuse the Suse Linux hacker
[12:12:35] <cartman> :p
[12:12:38] <mru> J_Darnley: funny
[12:12:52] <mru> I'll let my legal representative do the complaining
[12:13:05] <KotH> ouch
[12:13:07] <KotH> poor boys
[12:13:09] <twice11> Transport obfuscation is easy. Take for examples mru's suggestion.
[12:13:19] <twice11> cartman: That one was for you.
[12:13:39] <cartman> twice11: problem is we need offline playback
[12:15:02] <mru> disk is a form of transport
[12:15:08] <twice11> An offline player has only the data stored on the computer it is running on as input.
[12:15:08] <kshishkov> cartman: told you, encrypt header with full file name so it won't be played when moved or renamed
[12:15:23] <cartman> kshishkov: thats an idea as well
[12:15:27] <cartman> simple encryption
[12:15:44] <cartman> since I told the boss that DRM is dead end
[12:15:53] <twice11> So if you copy the whole environment, it will make the same decision about playability in the original and the copy.
[12:16:09] <merbzt> cartman: just hide the decryption key in the file header
[12:16:21] <twice11> So you need to include information outside of what is typically copied into encryption key derivation.
[12:16:34] <mru> merbzt: like that vividas thing
[12:16:40] <merbzt> yeah
[12:16:52] <twice11> That might be the file name, a hidden file in the user's profile, the computer name the file was downloaded on, or think of something else.
[12:16:54] <merbzt> mru: did you see there is a lavf demuxer for that nwo ?
[12:17:08] <mru> I saw someone picked up the pieces
[12:17:19] <cartman> merbzt: I would need a temp decrypted file right ?
[12:17:27] <twice11> Sending an encryption key together with the encrypted data somehow makes encryption pointless, doesn't it?
[12:17:36] <merbzt> cartman: depends on the player
[12:17:38] <mru> twice11: that's the point
[12:17:43] <cartman> merbzt: vlc.
[12:18:02] <cartman> twice11: I am not after a DRM
[12:18:03] <mru> cartman: write an input plugin that decrypts it
[12:18:06] <merbzt> cartman: and you have to use a vanilla version of that ?
[12:18:14] <cartman> merbzt: nope
[12:18:16] <cartman> can customize it
[12:18:40] <twice11> OTOH, having key base material in the file (like a nonce, or IV) which needs to be decoded by a authorized player knowing some super-secret master key makes a bit of sense.
[12:21:24] <twnqx> is libavcore new?
[12:21:31] <merbzt> 1-2 weeks
[12:21:48] * kshishkov still thinks it should be named libavutils
[12:22:23] <twice11> kshishkov: And what to put into libavutility and libavutilities?
[12:22:28] <twnqx> hm, still ffprobe_g: libavutil/mathematics.c:79: av_rescale_rnd: Assertion `c > 0' failed.
[12:22:49] <mru> did it dump a libavcore?
[12:23:10] <kshishkov> twice11: I'm not the one who decided that libs should behave like rabbits
[12:23:30] <twice11> But you suggested to have libavutil and libavutils, didn't you?
[12:23:45] <twnqx> what does av_rescale_rnd even do? and how do i get a backtrace on assert()?
[12:24:00] <twice11> if you run in gdb, you can backtrace it.
[12:24:02] <twnqx> oh, it's really just one function call...
[12:25:52] <twnqx> ./ffprobe_g -loglevel debug does not print extra things at all? that violates the manpage :X
[12:26:19] <mru> manpages have no authority
[12:26:24] <twnqx> *sigh*
[12:26:32] <twnqx> less ffprobe.c
[12:26:51] <kshishkov> twice11: I suggest rename libavcore to libavutils - first, it's easier to autocomplete libavcodec then, second - look at file names there
[12:30:08] <twnqx> main -> av_find_stream_info -> av_rescale_rnd -> assert -> boom
[12:30:16] <twnqx> that's pretty fast at least.
[12:30:24] <mru> there's always a boom
[12:30:38] <mru> Yuvi: is that you or an auto-join?
[12:38:11] <thresh> kshishkov: знаешь, как решить все проблемы милиции? переименовать её в полицию!
[12:39:24] <cartman> thats is so utf-8 of you
[12:41:44] <KotH> jo, er sötti liäber is88591 näh
[12:47:46] <kshishkov> thresh: редкий хрен не слаще хреновой редьки
[12:48:40] <twice11> kshishkov: Do you remember, we actually *have* libavutil already? So after your rename that makes libavutil and libavutils.
[12:50:43] <mru> twice11: I think that is point
[12:51:16] <twice11> And that was my point asking about libavutility and libavutilities too.
[12:51:28] <kshishkov> they will be introduced when needed
[12:51:57] <twice11> libavtool, libavtoolbox, libavtools
[12:52:21] <cartman> back in the time
[12:52:26] <cartman> there was a plan for mplayercc
[12:52:29] <cartman> ;)
[12:52:45] <twice11> cc = closed caption? carbon copy?
[12:52:56] <cartman> gcc replacement
[12:53:01] <twnqx> does any of you know OTYH how the call from av_find_stream_info to av_rescale_rnd can go? there must be some inlined function in between...
[12:54:13] <mru> grep is your friend
[12:54:18] <twnqx> well
[12:54:33] <twice11> twnqx: Recompile with -O0, I think that prevents all inlining.
[12:54:59] <twice11> I hope it doesn't break ffmpeg, though.
[12:55:15] <twnqx> let's see
[12:55:28] <twnqx> i gave no -O options actually...
[12:55:41] <twice11> Most projects default to -O2
[12:55:55] <twnqx> x86_64-pc-linux-gnu-gcc -I. -I"/home/charlie/Projects/ffmpeg/trunk" -D_ISOC99_SOURCE -D_POSIX_C_SOURCE=200112 -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -DPIC -DHAVE_AV_CONFIG_H -O0   -std=c99 -fomit-frame-pointer -fPIC -pthread -Wdeclaration-after-statement -Wall -Wno-parentheses -Wno-switch -Wdisabled-optimization -Wpointer-arith -Wredundant-decls -Wno-pointer-sign -Wcast-qual -Wwrite-strings -Wtype-limits -Wundef -Wmissing-prototypes -O3 -fno-math-e
[12:55:55] <twnqx> rrno -fno-signed-zeros -fno-tree-vectorize -Werror=implicit-function-declaration -Werror=missing-prototypes           -MMD -MF libavformat/apc.d -MT libavformat/apc.o -c -o libavformat/apc.o libavformat/apc.c
[12:56:02] <twnqx> this puts -O0 -O3 now... >_>
[12:57:12] <twice11> ./configure --disable-optimizations
[12:57:29] <twice11> will leave off the -O3, and on gcc that defaults to -O0
[12:57:43] <twnqx> i just removed it from config.mak
[12:59:29] <mru> you forgot -fno-bugs
[12:59:39] <twnqx> :P
[12:59:55] <twice11> -malign-features=0
[13:01:09] <twnqx> hm, so it's estimate_timings_from_bitrate
[13:02:21] <mru> 0bps?
[13:07:07] <twnqx> can i make gdb dump params with a backtrace?
[13:07:13] <mru> anyone want to fix the bugs in lavfi?
[13:07:51] <twice11> bt should dump the params if debugging info is available (was compiled with -g)
[13:08:01] <mru> it does
[13:13:40] <janneg> twnqx: looks like 0/x as timebase in the stream
[13:14:04] <twnqx> janneg: possibly a subtitle stream in avi..
[13:15:14] <twnqx> no, even with ffprobe_g gdb doesn't show the params
[13:15:34] <twnqx> maybe because of abort() instead of a=a/0
[13:15:39] <twnqx> :P
[13:16:09] <mru> it only shows what's available
[13:16:15] <twnqx> so - nothin
[13:16:40] <janneg> twnqx: http://pastie.org/1079533
[13:17:36] <twnqx> i'll try
[13:23:38] <twnqx> hm no, that did not help (yet)
[13:23:55] * twnqx adds a bit av_log glue
[13:43:51] <twnqx> argh
[13:44:02] <twnqx> just maybe... i've been stupid
[13:44:14] <twnqx> that patched stuff goes into libavformat...
[13:59:52] <twnqx> estimate: 10000000 400000 4294967294 <- i think the bitrate... is a bit off the scale :P
[14:00:17] <twnqx> and might just produce some integer overrun at some point.
[14:05:44] <twnqx> how can that even be.. the type is int... printed with %d.. and is positive?
[14:07:11] <twnqx> ah, again fooled by dynamic libs
[14:09:43] <twnqx> yeah, bitrate is -2
[14:11:22] <twnqx> janneg: change it to if (ic->bit_rate<=0) in your patch and it works.
[14:12:03] * twnqx headdesks
[14:12:07] * twnqx headdesks more
[14:12:17] * mru hands twnqx a bigger desk
[14:12:21] <twnqx> thanks...
[14:12:24] <mru> a sturdy marble one
[14:12:28] <twnqx> Input #0, ogg, from '/home/charlie/shinhp.avi':
[14:12:31] <twnqx> >_>
[14:12:34] <mru> :-)
[14:12:48] <mru> I had a file like that once too
[14:13:04] <mru> so I had to write a demuxer for it
[14:13:27] <twnqx> no, it's a regular ogg...
[14:13:37] <mru> this was a long, long time ago
[14:13:42] <twnqx> i see :P
[14:13:47] <mru> it was one of the first ogm files I came across
[14:13:56] <twnqx> was it also misnamed as avi?
[14:13:58] <mru> yes
[14:14:09] <twnqx> still i wonder
[14:14:15] <mru> I don't remember what it was
[14:14:19] <twnqx> how broken it can be to have a bitrate of -2
[14:14:19] <mru> some rubbish film
[14:14:31] <mru> about as broken as ogg
[14:15:01] <twnqx> the question is, would this patch janneg posted, in fixed form, be accepted?
[14:15:30] <mru> fixed patch and floating patch
[14:16:29] <twnqx> so let's see why the bitrate ends up as it does.
[14:16:45] <janneg> twnqx: change the "ic->bit_rate != 0" check in the if above
[14:17:39] <twnqx> first let's see if it's -2 to begin with
[14:19:43] <twnqx> aha. st->codec->bit_rate for the vorbis audio streams is -1 each
[14:20:00] <janneg> either the demuxer sets it in the format context to -2 or it has rubish in the stream
[14:20:04] <janneg> http://pastie.org/1079646
[14:20:51] <twnqx> http://pastie.org/1079648
[14:22:53] <twnqx> your suggestion wouldn't catch this, i'm afraqid
[14:25:27] <janneg> it should, the second hunk does
[14:27:10] <twnqx> true, yes it does
[14:27:27] <twnqx> would still be interesting to know where the -1 comes from
[14:29:48] <twnqx> shouldn't the ogg demuxer catch stuff such as negative bitrates?
[14:31:06] <janneg> I'm looking for it. I doubt it comes from libavformat/utils.c or oggdec.c
[14:31:13] <twnqx> no
[14:31:18] <twnqx> from oggparsevorbis.c
[14:31:49] <twnqx> and the doc before fixup_vorbis_headers is wrong, the nominal bitrate is used in the code, not the minimum
[14:33:00] <twnqx> apparently, nominal_bitrate is -1 here.
[14:34:16] <twnqx> well
[14:34:19] <twnqx> all three are -1
[14:34:22] <twnqx> congrats!
[14:34:40] <twnqx> MPlayer interrupted by signal 6 in module: demux_open
[14:34:40] <twnqx> - MPlayer crashed. This shouldn't happen.
[14:34:41] <twnqx> yey!
[14:34:51] <twnqx> hard to play this file.
[14:35:18] <twnqx> but ffplay plays it (now)
[14:47:44] * peloverde looks at the track record of vorbis_dec patches and wonders how long it will take the maintainer(s) to respond to this one
[14:48:10] <twnqx> luckily it's not the decoder.
[14:49:12] <twnqx> peloverde: do you think i should post the two fixes indepently?
[14:50:10] <peloverde> I don't know, I was looking at the OpenBSD thing and my still outstanding vorbis-float-types.diff
[14:50:11] <mru> peloverde: Yuvi _is_ maintainer
[14:50:33] <peloverde> Yes and he has responded to zero fo my last three vorbis_dec patches
[14:50:38] <mru> hmm
[14:51:09] <mru> he's usually not that slow
[14:51:12] <mru> Yuvi: !!!!
[14:51:18] <mru> or just apply it
[14:51:21] <peloverde> two were related to crashers, so I applied them anyway
[14:51:29] <twnqx> ah well. try 1: both in one.
[14:52:11] <twnqx> 4h driving from amsterdam to home... and then i'll check the response. bbl
[15:01:51] <_av500_> hmm, facedetection works well it seems: http://1.bp.blogspot.com/_RgcwZKak6mU/S-V5Vevk3rI/AAAAAAAAAQg/iXB_iAQyD7A/s1600/faces6.jpg
[15:03:31] <DonDiego> siretart: say, will the encoders make it into squeeze?
[15:05:11] <cartman> _av500_: that girl has two faces!
[15:05:17] <_av500_> 3!
[15:05:27] <cartman> wow
[15:05:35] <cartman> didn't see the 3rd one
[15:05:49] <_av500_> she hid it under the handbag
[15:06:03] <_av500_> but the clever algorithm found it nevertheless
[15:06:09] <cartman> yeah
[15:09:37] <kshishkov> that's why cameras without AF are better
[15:10:01] <_av500_> kshishkov: I have a lot of them :)
[15:11:49] <mru> _av500_: canon slr AF with all the smart stuff turned off is nice
[15:12:06] <_av500_> mru: center spot AF, yes
[15:12:13] <mru> that's all I use
[15:12:58] <_av500_> I tried eye control with girls, but kept focussing on the "wrong" body parts :)
[15:13:04] <mru> :-)
[15:33:07] <kshishkov> 1ll
[15:33:43] <_av500_> yep
[15:34:04] <kshishkov> (int256_t)1 is cooler though
[16:11:37] <CIA-92> ffmpeg: alexc * r24716 /trunk/libavcodec/vorbis_dec.c:
[16:11:38] <CIA-92> ffmpeg: vorbis_dec: Change partition_class[] to uint8_t.
[16:11:38] <CIA-92> ffmpeg: When sizeof(uint_fast8_t) >= sizeof(int) there are unintended size effects.
[16:12:15] <peloverde> If that screws things up more, feel free to revert it. My availability is going to be spotty for the next week.
[16:42:04] <peloverde> And the BSD targets start to turn green
[16:44:10] <wbs> \o/
[16:50:36] <j0sh> wbs: did you hear about the updated vp8 rtp proposal?
[16:50:43] <_av500_> and I thought it would be black and white with a red dot in the middle..
[16:51:02] <wbs> j0sh: no, I didn't
[16:51:39] <j0sh> slightly different now
[16:51:41] <j0sh> http://groups.google.com/a/webmproject.org/group/webm-discuss/browse_thread/thread/a13eba12d753964a#
[16:52:04] <saintd3v> peloverde: i think you added the wrong patch to your aacx repo. the one that is there doesn't apply, and only outputs the extradata.
[16:52:06] <j0sh> basically added something called an "aggregation unit"
[16:52:16] <peloverde> It has been updated
[16:52:25] <saintd3v> oh, ok :)
[16:53:46] <j0sh> its just a 11-byte length prefix
[16:54:26] <wbs> hmm, okay.. so it should be supported in the depacketizer, but we don't really need to use it in the packetizer
[16:54:35] <wbs> (but implementing it there for testing may help)
[16:55:00] <wbs> but it should only be used if you have two frames with the same timestamp anyway... which only happens with altref/golden?
[16:55:21] <wbs> or are there other cases with subsequent frames with the same timestamp?
[16:56:07] <wbs> and the handling of lost packets seems to have been loosened up, "If a lost packet is detected in the RTP stream, the application layer MUST decide how to handle the subsequent packets."
[16:56:12] <j0sh> it sounds like it was a feature requested by people doing rtc (low latency/video conferencing?)
[16:56:36] <j0sh> yeah lost packet handling sounds much more reasonable
[16:56:49] <wbs> well, we decide we just pass all the packets up to the decoder and hope it works - that's a valid strategy and satisfies the rfc? :-)
[16:57:07] <j0sh> we do need to add the length prefix to the packetizer
[16:57:36] <wbs> you should only add it if you've set the aggregate frames bit
[16:57:47] <j0sh> ahh
[16:57:49] <wbs> which there's only a point doing if you know you've got double frames with the same timestamp
[16:57:56] <j0sh> cool, then
[16:58:10] <wbs> so for the packetizer things actually get a bit simpler
[16:58:26] <j0sh> yeah, no keyframe marker
[17:04:58] <siretart> hrmpf. I missed diego. again
[17:05:43] <mru> peloverde: thanks for the vorbis fix
[17:17:55] <Honoome> siretart: I'm here :P
[17:20:06] <kshishkov> probably he meant another Diego from your country
[17:21:26] <Honoome> kshishkov: doubt so, DonDiego is not from my country :)
[17:21:45] <kshishkov> last time he joined chat from tiscali.it
[17:21:48] <mru> but he is _in_ your country
[17:22:24] <kshishkov> the same boot :)
[17:22:29] <siretart> hi Honoome :-)
[17:22:47] <Honoome> kshishkov: that's lu_zero's house :P
[17:25:28] <kshishkov> Honoome: see? That's definitely you country and not, say, Argentina
[17:25:59] <Honoome> althought he weather (at least here) could suggest that
[17:26:12] * Honoome wants his bloody vacations >_<
[17:27:05] <kshishkov> I'd like to experience that too. The only vacation I've ever had was four days at LinuxTag
[17:27:22] <mru> you should try it more often
[17:27:45] <Honoome> I'm swamped with work =_= I was supposed to take this week off and... I'm still working 16h/day
[17:27:54] <kierank> you should take a british vacation to spain
[17:28:02] <kierank> and eat british food in a foreign country
[17:28:13] <siretart> hi DonDiego
[17:28:42] <kshishkov> kierank: what is British food that can be called food by foreighner as well?
[17:28:50] <kierank> none
[17:29:07] <siretart> DonDiego: FYI, I've uploaded yesterday a copy of ffmpeg 0.5 with all (internal) encoders enabled for squeeze. exactly one day before the squeeze free (today), but it is going to make it
[17:29:10] * kshishkov has no intent to visit Spain though
[17:29:19] <kierank> visit usa?
[17:30:11] <kshishkov> almost no intent as well
[17:30:22] <kshishkov> Portugal is fine though
[17:30:29] <kierank> england?
[17:30:35] <kshishkov> unlikely
[17:30:45] <mru> nothing wrong with england
[17:30:53] <DonDiego> siretart: excellent :)
[17:30:56] <mru> well, no more than any other place
[17:31:04] <Honoome> mru: the driving
[17:31:04] <spaam> kshishkov: visit sweden ;)
[17:31:05] <kshishkov> mru: plumbing?
[17:31:08] <Honoome> that's totally wrong
[17:31:12] <mru> kshishkov: exists
[17:31:17] <kshishkov> spaam: jag vill garna
[17:31:33] <spaam> :D
[17:31:35] <kshishkov> mru: politics?
[17:31:46] <mru> kshishkov: no worse than other european countries
[17:32:07] <kshishkov> attitude to foreighners?
[17:32:10] <Honoome> you drive on the wrong side of the road! >_<
[17:32:18] <mru> kshishkov: no problem
[17:32:37] <kierank> there are lots of people from eastern europe here anyway
[17:32:52] <DonDiego> bye
[17:32:55] <mru> and spanish
[17:33:12] <kshishkov> kierank: that's what I call "problem"
[17:33:28] <mru> I have no problem with them
[17:34:19] <Scoops> Anyone here know much about RTP?
[17:34:26] <mru> the italians
[17:35:00] <Honoome> wbs and BBB are not italian
[17:35:14] <kshishkov> mru: when I studied visa requirements, UK ones were one of the strictest (maybe a little bit less strict than US but definitely stricter than Germany)
[17:35:14] * wbs has been to Italy once
[17:35:44] <kierank> kshishkov: you'd be fine
[17:35:46] <kshishkov> Honoome: wbs is from proper country with one major flaw to the East
[17:36:02] <mru> there's virtually no difference between sweden and uk
[17:36:07] <mru> or germany
[17:36:16] * Honoome insists: THE ROADS! >_<
[17:36:19] <mru> but se and uk are more alike
[17:36:29] <kshishkov> yes, Sweden has switched in October 1967
[17:36:36] <mru> Honoome: yes, some roads could use some repair
[17:36:41] <mru> but mostly they're adequate
[17:36:46] <Honoome> no I mean the side
[17:36:55] <Honoome> you drive on the bloody wrong side! >_<
[17:36:57] <mru> I've survived 5 years of reckless cycling on them
[17:37:19] <mru> we also gave you the wonderful word "bloody"
[17:37:23] <kierank> cycling on the road scares me like hell
[17:37:27] * kshishkov has been experiencing Ukrainian "roads" for lifetime
[17:37:32] <kierank> literally any second you could be crushed by a lorry
[17:37:37] <kierank> and the driver wouldn't even notidce
[17:37:44] <kshishkov> kierank: better lorry than truck :P
[17:37:44] <mru> kierank: then you're doing it wrong
[17:37:59] <mru> keep to the centre of your lane
[17:38:20] <kshishkov> and use reflectors
[17:38:40] <mru> the number one mistake cyclists make is keeping too close to the edge
[17:39:00] <kierank> but then you get a massive traffic jam behind you
[17:39:01] <mru> if you use as much space as a car, the cars will avoid you
[17:39:13] <mru> you can pull aside and let them overtake when it's safe
[17:39:30] <mru> besides, in heavy traffic I usually keep even pace with the cars
[17:39:34] <mru> or overtake them
[17:39:36] * kshishkov heard of special cyclist lanes and special cyclists roads
[17:39:43] <mru> those are murder
[17:40:15] <kierank> they have a lot of those in holland
[17:40:17] <mru> they are 1) too narrow, 2) full of pedestrians, 3) end in a tree
[17:41:19] <kshishkov> in Ukraine number of cyclists seem to correspond to the number of honest men in politics, so no problem
[17:44:10] <janneg> there was one before he was murdere^W^Wdied?
[17:44:40] <Scoops> Anyone, cyclist or non-cyclist, know much about RTP?
[17:44:56] <kshishkov> lu_zero or BBB do, ask them
[17:45:04] <mru> the italians, the swedes, and the dutch
[17:45:07] <kshishkov> and wbs probably may help
[17:45:11] <mru> Honoome: happy now?
[17:45:16] <Scoops> :)
[17:45:25] <kierank> Scoops: j0sh as well i think
[17:45:29] <mru> wait, wbs is finnish-swedish
[17:45:49] <kshishkov> that's almost the same thing
[17:46:02] <kshishkov> unlike finnish-finnish
[17:46:32] <wbs> Scoops: if you have something to ask, do ask, instead of asking if somebody knows
[17:46:47] <wbs> and if you've got something to ask, ask it on the channel instead of looking for someone to ask privately
[17:46:59] <Compn> heh
[17:47:23] * Compn finds it telling that the azureus dev is acting like generic lgpl violator, 'the sources are on google'
[17:47:39] <mru> Compn: he _is_ a generic violator
[17:47:57] <Compn> yes, but generally the open source projects act better than that
[17:48:08] <Scoops> OK: Is there a way to put a constant SSRC when streaming RTP, like a command line option?
[17:48:24] <wbs> nope
[17:48:40] <wbs> patch welcome if you can do it cleanly, though, although I fail to see the need for it
[17:48:54] <wbs> or, I guess it may be needed in some situation actually
[17:49:24] <Scoops> If I stream a bunch of files, I would like them all to have the same SSRC
[17:49:43] <wbs> you can hack it in via metadata, but I don't think that would be accepted. so then you'd have to add a public field in AVFormatContext for it or wait until private muxer parameters are implemented properly
[17:52:06] <Scoops> OK, let me look at the code again. I make a hack to do it, but it was a month ago, so I forgot whatI did :|
[18:44:11] <leandrosansilva_> Hello to all. After last API change in ffmpeg trunk, I can't compile ffmpeg with vpx anymore. Compilation error: libavcodec/libvpxdec.c:89: error: implicit declaration of function ‘av_check_image_size’
[18:54:14] <leandrosansilva_> if I disable libvpx support, it compiles fine. I'm using libvpx 0.9.0
[18:57:52] <peloverde> fixed in r24717
[18:57:56] <peloverde> Also don't use 0.9.0, use 0.9.1 or latest git
[18:58:14] <CIA-92> ffmpeg: alexc * r24717 /trunk/libavcodec/libvpxdec.c:
[18:58:15] <CIA-92> ffmpeg: libvpxdec: Fix "error: implicit declaration of function ?av_check_image_size?".
[18:58:15] <CIA-92> ffmpeg: av_check_image_size() is declared in libavcore/imgutils.h.
[19:01:21] <peloverde> Also if you are on x86/x86-64 consider using ffvp8
[19:01:46] <mru> neon is in the works
[19:02:02] <mru> some guy at TI is working on it
[19:05:00] <leandrosansilva_> thx.
[19:21:21] <peloverde> not interested in doing it yourself?
[19:21:38] <mru> he has time, I don't
[19:21:45] <mru> and he already started
[19:21:57] <mru> I'll help him fine-tune it
[19:28:35] <kshishkov> maybe FFmpeg will get NEON opts for VC-1 though :)
[19:32:34] <kierank> lego audio decoder needs neon opts
[19:32:54] <kshishkov> nope
[19:33:12] <kshishkov> but Bink Video is
[19:33:32] <kshishkov> (since it has shitty IDCT)
[19:33:37] <kierank> lego > all
[19:33:42] <kierank> this is why it needs neon
[19:33:51] <kierank> avx should also be designed around it
[19:35:41] <kshishkov> well, AVX is more or less like NEON (if it was damaged at birth by MMX)
[19:36:42] <mru> to be fair, the neon designers had both mmx/sse and altivec to avoid mistakes from
[19:37:25] <kshishkov> altivec is not that bad though (except for being reclusive)
[19:37:30] <Dark_Shikari> kshishkov: AVX has no int!
[19:37:41] <mru> altivec has some annoying shortcomings
[19:37:44] <Dark_Shikari> (said as if it was "PS3 has no games!!!")
[19:37:47] <mru> no unaligned load/store
[19:37:51] <Dark_Shikari> AVX  has no ints!
[19:38:07] <mru> and no direct core <-> altivec transfers
[19:38:22] <Dark_Shikari> mru: and its definition of alignment is incredibly stupid
[19:38:27] <mru> 16
[19:38:29] <Dark_Shikari> "alignment" means "alignment to the size of the data type"
[19:38:33] <Dark_Shikari> except in altivec.
[19:38:41] <mru> in altivec it's 16, no matter
[19:38:43] <Dark_Shikari> yup
[19:38:47] <Dark_Shikari> which, as I said, is braindead.
[19:38:51] <mru> yep
[19:38:52] <kshishkov> it's all 128-bit regs for data type :)
[19:39:21] <mru> there are very few glaring omissions in neon
[19:40:58] <Dark_Shikari> does neon have byte multiplies?
[19:41:03] <mru> yes
[19:41:07] <mru> both signed and unsigned
[19:41:13] <Dark_Shikari> does it have unsigned x signed?
[19:41:19] <mru> no, that's the missing one
[19:41:24] <Dark_Shikari> That's a rather important one
[19:41:28] <Dark_Shikari> also known as "interpolation filter"
[19:41:51] <Dark_Shikari> though you can probably avoid that as an issue just by using some subtracts.
[19:41:54] <mru> it has multiply-subtract
[19:41:58] <Dark_Shikari> ah, nice.
[19:42:07] <mru> so you store coeffs positive and use that
[19:42:24] <Dark_Shikari> I want a CPU that has an interpolation instruction.
[19:42:35] <mru> ivahd
[19:42:45] <Dark_Shikari> is it an instruction, or a separate cpu?
[19:43:03] <Dark_Shikari> It would be rather easy to do an instruction
[19:43:04] <mru> it's an instruction on one of the units
[19:43:11] <Dark_Shikari> inter6tap output, input, coeffs
[19:43:26] <Dark_Shikari> input is 8+5 pixels
[19:43:29] <Dark_Shikari> coeffs is the 6 coeffs
[19:44:26] <mru> of course it can be done
[19:44:43] <mru> the thing about a general-purpose cpu is that it is, well, general-purpose
[19:44:44] <kshishkov> feel free to design one
[19:44:59] <Dark_Shikari> mru: tell that to intel
[19:45:04] <Dark_Shikari> they don't seem to quite understand that
[19:45:12] <mru> if you piled on special instructions for every application imaginable, it would soon collapse under its own weight
[19:45:18] <Dark_Shikari> somewhere between their AES instructions
[19:45:25] <Dark_Shikari> their exhaustive motion search instruction (mpsadbw)
[19:45:38] <mru> aes as in galois field stuff?
[19:45:46] <Dark_Shikari> their next chips will have full AES hardware support
[19:45:49] <mru> aka polynomial mult
[19:45:53] <Dark_Shikari> i.e. a set of instructions necessary to implement all the main parts of AES in hardware
[19:45:57] <Dark_Shikari> for many different types of AES
[19:46:07] <Dark_Shikari> e.g. the different modes
[19:46:18] <mru> and the omap4 has an entire cortex-m3 to run crypto stuff
[19:46:55] <mru> those instructions are probably easy to implement
[19:47:04] <mru> and encryption is important
[19:47:13] <Dark_Shikari> so is video encoding and decoding
[19:47:18] <mru> yes, so?
[19:47:31] <Dark_Shikari> well, then again, they gave us psadbw
[19:47:45] <mru> the guys running ssl servers don't care how fast it can encode video
[19:48:02] <Dark_Shikari> and the guys running video servers don't care how fast it can do aes
[19:48:23] <mru> but they're buying the same hardware
[19:48:35] <mru> making different hw would make it more expensive for all
[19:49:03] <Dark_Shikari> I meant that there's no reason they can't add some other things useful for us, too =p
[19:49:42] <mru> they have to strike a balance somewhere
[19:49:51] <mru> chip space is limited
[19:50:07] <Dark_Shikari> I suspect it's more about buzzword compliance
[19:50:19] <Dark_Shikari> hence instructions like mpsadbw (great in marketing documents, useless in reality)
[19:50:30] <mru> what does it do?
[19:50:58] <Dark_Shikari> psadbw calculates the sum of the SADs of the pixels in the two 128-bit registers.  simple enough and very useful.
[19:51:07] <Dark_Shikari> mpsadbw does the following
[19:51:18] <Dark_Shikari> mpsadbw x,y ---> x is the source register (8 pixels of a block)
[19:51:25] <Dark_Shikari> and y represents 16 pixels of many different blocks
[19:51:34] <Dark_Shikari> and it calculates the SAD with y[0] through y[7]
[19:51:37] <Dark_Shikari> y[1] through y[8]
[19:51:38] <Dark_Shikari> etc etc
[19:51:42] <Dark_Shikari> for a total of 8 SADs
[19:52:09] <Dark_Shikari> this is useful if you're doing an exhaustive motion search where you want to test MVs <X,Y> ... <X+8,Y>.
[19:52:18] <Dark_Shikari> But exhaustive motion searches are completely fucking useless.
[19:53:02] <Dark_Shikari> and furthermore, our testing shows that the primary reason their instruction was a lot faster was because it avoided cacheline splits
[19:53:15] <Dark_Shikari> and if you modify the normal asm code to avoid cache splits, it's not much faster at all
[19:53:39] <mchinen> is AVCodecParserContext.pos used for anything besides setting the pos for index_entries seeking?
[19:53:41] <Dark_Shikari> furthermore, SEA is an algorithm for exhaustive motion search that is about 10x faster than the naive approach and makes this kind of thing 100% utterly useless.
[19:53:59] <Dark_Shikari> But you know, mru, this may be why Intel wants decoder-side motion search in h265 ;)
[19:54:08] <mru> huh?
[19:54:27] <Dark_Shikari> there are many proposals in h265 to have the decoder do a motion search to improve the accuracy of motion vector prediction
[19:54:32] <Dark_Shikari> at least one proposal involved an exhaustive search
[19:55:53] <Dark_Shikari> how it works:
[19:55:56] <Dark_Shikari> AA
[19:55:57] <Dark_Shikari> AN
[19:56:03] <Dark_Shikari> N is the current block to be decoded (not decoded yet)
[19:56:09] <Dark_Shikari> A are neighboring blocks whose decoded pixels are known
[19:56:17] <Dark_Shikari> the decoder picks a "template" of the As like this:
[19:56:18] <Dark_Shikari> AA
[19:56:19] <Dark_Shikari> A
[19:56:26] <Dark_Shikari> and does a motion search against the previous frame, starting at the predictor.
[19:56:37] <Dark_Shikari> the hope is that the motion vector from this is very close to what N wants.
[20:36:44] <twnqx> hm, 14k unread emails in ffmpeg-devel
[20:38:56] <elenril> inb4 overused memes
[21:05:10] <_av500_> Dark_Shikari: seen? https://review.webmproject.org/#change,118
[21:13:08] <janneg> mru: http://fate.ffmpeg.org/?asort=arch looks random. there's a x86_64 between bfin and mips64 and x86_64 and x86_32 are not sorted at all
[21:15:33] <_av500_> janneg: it sort by what mru thinks archs are worth :)
[21:16:49] <janneg> ah, that's the reason why armv7a is above armv5te
[21:17:59] <janneg> but still wondering why PathScale (tm) Compiler Suite Version 3.9.99-91fcc71 makes x86_64 better mips64 and ppc
[21:21:13] <janneg> _av500_: "The Man In The Yellow Hat" has "nice" comments: "No score; I would prefer that you didn't submit this"
[21:22:20] <mru> tmityh always says that
[21:22:23] <Dark_Shikari> _av500_: old news
[21:22:28] <_av500_> ok
[21:22:29] <Dark_Shikari> look at the progress (zero, basically)
[21:22:31] <Dark_Shikari> mru: ping
[21:22:32] <mru> I think it's a bot
[21:22:40] <_av500_> downvote me :)
[21:22:54] <Dark_Shikari> mru: question re arm idct code in ffmpeg (neon)
[21:22:57] <Dark_Shikari> for h264
[21:23:04] <mru> yes
[21:23:04] <Dark_Shikari> do you use the merged idct functions?  i.e. add_idct16_intra ?
[21:23:22] <mru> there's no choice, is there?
[21:23:29] <Dark_Shikari> no, you can either implement those or the old versions
[21:23:36] <Dark_Shikari> (but not a mix of the two)
[21:23:44] <Dark_Shikari> because they use different scan orders
[21:23:51] <mru> I remember you breaking it about a year ago
[21:23:51] <Dark_Shikari> and secondly, if you do, does neon do 2 4x4 idcts at once (given you have 128-bit registers) ?
[21:23:58] <Dark_Shikari> it was michael who broke it
[21:24:05] <mru> ah, could be
[21:24:09] <mru> well, someone did
[21:24:12] <Dark_Shikari> he added this weird system
[21:24:21] <Dark_Shikari> anyways, do you do two 4x4 idcts at once?
[21:24:29] <mru> I don't remember
[21:24:29] <Dark_Shikari> or do you do one 4x4 idct per nonzero?
[21:24:36] <Dark_Shikari> the code's that old eh =p
[21:24:56] <Dark_Shikari> yup.  doesn't do that.
[21:25:15] <Dark_Shikari> I'm trying to optimize the h264 decoder for the ipad, and by optimize, I mean optimize for the most ideal possible case
[21:25:21] <Dark_Shikari> no subpel, no deblock, baseline profile
[21:25:45] <Dark_Shikari> I haven't done an arm bench yet, but on x86 I'm up to about 45% of time being decode_cavlc_residual
[21:25:49] <Dark_Shikari> and about 30% being idct
[21:26:01] <Dark_Shikari> (hey, it's almost like flv all over again)
[21:26:10] <Dark_Shikari> or maybe it was 20% being idct another 10% being cavlc stuff
[21:26:13] <Dark_Shikari> Oh, and I did some hilarious hacks
[21:26:18] <Dark_Shikari> I swapped out chroma MC for mpeg-2 MC
[21:26:27] <Dark_Shikari> Which is perfectly valid and bit-exact if your MVs are fullpel only.
[21:26:31] <mru> h264 w/o subpel or deblock _is_ mpeg4
[21:26:37] <Dark_Shikari> Not quite.
[21:26:41] <Dark_Shikari> it's worse than mpeg-4
[21:26:42] <mru> and w/o cabac
[21:26:56] <Dark_Shikari> The reason for this is that we've built a lot of our system around h264
[21:27:04] <Dark_Shikari> and x264's features are far too useful to pass up
[21:27:10] <Dark_Shikari> e.g. error recovery, etc
[21:27:19] <Dark_Shikari> and dropping to FLV, even for a demo, would suck
[21:27:27] <janneg> mru: it's either DonDiego or a bot. it complained about trailing whitespace and tabs
[21:27:33] <Dark_Shikari> janneg: LOL
[21:29:04] <Dark_Shikari> mru: btw, what do you use to do profiles on arm?
[21:29:08] <Dark_Shikari> does oprofile work on arm?
[21:29:16] <janneg> yes
[21:30:22] <_av500_> yes
[21:42:55] <tourette> hi guys
[21:43:14] <tourette> anyone online who is working with the AC3 encoder code?
[21:43:28] <tourette> Just wondering about one compiler warning
[21:44:37] <Dark_Shikari> probably nobody has been "working with it" for at least 8 years... =p
[21:45:03] <tourette> well, no need to work with it something just works :)
[21:46:29] <J_Darnley> If you want to know about a warning, you need to tell us what it is
[21:46:49] <tourette> const int16 ff_ac3_floor_tab[8]= {
[21:46:49] <tourette>     0x2f0, 0x2b0, 0x270, 0x230, 0x1f0, 0x170, 0x0f0, 0xf800,
[21:46:49] <tourette> };
[21:46:53] <Dark_Shikari> J_Darnley: wrong.  we will use our psychic powers to figure out what he's talking about.
[21:47:25] <mru> janneg: sorting fixed
[21:47:36] <tourette> that one causes "warning C4309: 'initializing' : truncation of constant value" on MS compiler at least
[21:47:48] <janneg> mru: thanks
[21:47:48] <Dark_Shikari> >MS compiler
[21:48:04] <Dark_Shikari> there is no MS-made compiler that can compile ffmpeg
[21:48:23] <tourette> Parts of the code are compiling nicely :)
[21:49:01] <Dark_Shikari> But you're right, that's obviously a bug.
[21:49:08] <Dark_Shikari> Yes, parts work.  But MSVC doesn't support the language ffmpeg is written in.
[21:49:11] <Dark_Shikari> That is, C99.
[21:50:27] <peloverde> Despite the fact that they have no intentions of implementing c99, they are participating in c1X :(
[21:50:35] <tourette> yep, MS handles pretty much all things on their own way
[21:51:00] <Dark_Shikari> You would be better off using a real compiler.
[21:51:00] <tourette> but, back to the warning... should it be uint16 instead of the int16?
[21:51:12] <Dark_Shikari> tourette: I'm not quite sure.  Those values might be intended to be signed.
[21:51:20] <Dark_Shikari> and the last value negative.
[21:51:44] <Dark_Shikari> Best to ask the author.
[21:51:54] <Dark_Shikari> Or at least do an svn blame
[21:52:07] <mru> if it's negative, the magnitude is similar to the others
[21:53:17] <Dark_Shikari> It could be that the array was originally int
[21:53:20] <Dark_Shikari> and someone incorrectyl shrunk it
[21:54:39] <tourette> VLC seems to have it as uint16
[21:54:49] <tourette> static uint_16 floortab[] = { 0x2f0, 0x2b0, 0x270, 0x230, 0x1f0, 0x170, 0x0f0, 0xf800 };
[21:57:42] <peloverde> http://git.ffmpeg.org/?p=ffmpeg;a=commitdiff;h=414fb4a1b0f2831d5d2f690d29c110e6b0416d10
[21:57:43] <mru> it was changed from unsigned to signed in r6156
[21:58:09] <peloverde> The change was clearly intentional
[21:58:28] <peloverde> "Fix 2 bit allocation bugs.  One fix enables using a higher bandwidth code.  The other fixes an issue with floorcod=7."
[21:58:32] <tourette> yep, seems so
[21:58:40] <Dark_Shikari> Why is MSVC clipping the value though?
[21:58:49] <Dark_Shikari> "0xffff" is a perfectly valid signed 16-bit int.
[21:59:10] <mru> yes, but that is a positive integer constant
[21:59:26] <tourette> 63488
[21:59:31] <Dark_Shikari> no it isn't
[21:59:44] <Dark_Shikari> Or do we need to cast our constants too?
[22:00:04] <mru> 0xffff is a constant with the decimal value 65536
[22:00:07] <mru> 65535
[22:00:28] <lu_zero> Scoops: poing
[22:00:31] <Dark_Shikari> But it's declared as an int16_t
[22:00:37] <Dark_Shikari> What's (int16_t)0xffff?
[22:00:42] <Dark_Shikari> that isn't 65536.
[22:00:44] <tourette> and 2^16 / 2 is not that much
[22:00:47] <mru> no, the _constant_ isn't declared at all
[22:00:48] <mru> it just is
[22:00:54] <mru> integer constants have type int
[22:00:59] <mru> if the value fits in an int
[22:01:01] <Dark_Shikari> mru: yes, but then it's cast to int16_t
[22:01:06] <mru> no it's not
[22:01:12] <mru> it's implicitly converted
[22:01:14] <Dark_Shikari> sure, it's 65535 when declared
[22:01:20] <Dark_Shikari> and then it gets converted to int16_t
[22:01:23] <Dark_Shikari> because the array is int16_t
[22:01:28] <mru> and the compiler is warning about a change of sign during the implicit conversion
[22:01:34] <mru> gcc does that too sometimes
[22:01:34] <Dark_Shikari> Are you saying implicit conversion in C demands truncation????
[22:01:43] <mru> how the fuck else would it do it?
[22:01:51] <Dark_Shikari> Er.... reinterpret-cast?
[22:01:54] <Dark_Shikari> the obvious way?
[22:02:00] <mru> you can't fit more than 16 bits in a 16-bit space
[22:02:09] <Dark_Shikari> You don't saturate the value!
[22:02:17] <mru> nobody is doing that
[22:02:22] <Dark_Shikari> But that's what the error message said
[22:02:24] <mru> no
[22:02:31] <Dark_Shikari> that MSVC was clipping the value to within the range of a signed 16-bit int
[22:02:36] <Dark_Shikari> i.e. clipping it to 0x7fff
[22:02:57] <peloverde> It said truncating not clipping
[22:03:01] <mru> "truncation" there means dropping high bits
[22:03:10] <Dark_Shikari> So that means it got converted to 0x7f80
[22:03:13] <Dark_Shikari> from 0xff80
[22:03:15] <mru> no
[22:03:23] <Dark_Shikari> Then which high bit is being dropped?
[22:03:38] <mru> the high 16 zero bits in the 32-bit constant
[22:03:50] <Dark_Shikari> I mean in this case.
[22:03:54] <mru> me too
[22:03:59] <Dark_Shikari> But it isn't a 32-bit constant.
[22:04:03] <mru> 0xffff is a 32-bit constant
[22:04:04] <tourette> I guess I'll check with debugger what bits the compiler has eaten :)
[22:04:12] <Dark_Shikari> mru: by that definition, 0x1 is a 32-bit constant
[22:04:17] <mru> yes
[22:04:18] <mru> it is
[22:04:20] <Dark_Shikari> yes, I agree
[22:04:24] <Dark_Shikari> but then why doesn't the compiler complain about that?
[22:04:29] <mru> about what?
[22:04:30] <Dark_Shikari> truncating constant "0x1"?
[22:04:37] <roxfan> i don't get any warnings in msvc when i compile this:
[22:04:38] <roxfan>   short x = (short)0xFFFF;
[22:04:38] <Dark_Shikari> Because it's dropping the high 16 bits of that, too.
[22:04:40] <mru> it would, if you had a signed 1-bit type
[22:04:50] <Dark_Shikari> mru: you're beating around the bush
[22:04:53] <Dark_Shikari> in the current situation
[22:04:54] <mru> it only warns if the value is changed
[22:04:55] <Dark_Shikari> MSVC warns about 0xffff
[22:04:59] <Dark_Shikari> but not 0x7fff
[22:05:02] <Dark_Shikari> It says "truncation"
[22:05:05] <Dark_Shikari> "truncation" implies "lost bits"
[22:05:14] <mru> that's because 0x7fff fits in signed 16 bits as is
[22:05:19] <Dark_Shikari> therefore, 0x7fff is not losing bits
[22:05:21] <Dark_Shikari> and 0xffff is.
[22:05:23] <peloverde> Dark_Shikari: It has lost a bit, it lost one value bit to the sign bit
[22:05:25] <Dark_Shikari> Which bit in 0xfff is lost?
[22:05:26] <roxfan> warns when? show me the code
[22:05:27] <Dark_Shikari> *0xffff
[22:05:39] <Dark_Shikari> peloverde: Which means it was truncated to 0x7fff.
[22:05:55] <mru> no
[22:06:06] <mru> it means the bits were crammed as best it could into the space allotted
[22:06:13] <mru> and when doing so, the value changed
[22:06:16] <Dark_Shikari> And there may or may not have been actual truncation?
[22:07:29] <pengvado> it lost the sign bit, i.e. one of the zeros to the left of the 0xffff.
[22:08:06] <roxfan> i don't get a waring in VC9...
[22:08:30] <Dark_Shikari> makes sense.
[22:08:50] <roxfan> oh hey i do with /Wall
[22:09:01] <mru> the warning makes perfect sense
[22:09:15] <roxfan> but it still puts 0f800H in the assembly listing
[22:09:16] <Dark_Shikari> another brick in the /Wall
[22:09:51] <roxfan> and the binary as well
[22:10:08] <peloverde> Dark_Shikari: The compiler assumes we are stupif when you turn Wall on
[22:10:14] <peloverde> just like gcc's paren warnings
[22:10:22] <Dark_Shikari> I agree with the paren warnings
[22:10:26] <Dark_Shikari> it stops people from coding like derf.
[22:10:39] <peloverde> Product happens before sum
[22:10:47] <peloverde> I learned that in 4th grade
[22:11:14] <Dark_Shikari> that's not what I mean
[22:11:15] <peloverde> Should it also warn about a*b + c*d
[22:11:18] <Dark_Shikari> I mean the obscure >> ordering rules
[22:11:21] <Dark_Shikari> and &
[22:11:21] <Dark_Shikari> etc etc
[22:11:32] <Dark_Shikari> seriously, just go look at derf's code sometime and you will LOVE gcc for those warnings.
[22:11:33] <peloverde> a&b | c&d is the same thing
[22:11:43] * roxfan has been bitten by & and == priority not one time
[22:12:29] <Dark_Shikari> fyi -- derf codes with:
[22:12:29] <mru> http://26-26-54.hardwarebug.org/?id=3
[22:12:30] <Dark_Shikari> a) no spaces
[22:12:36] <Dark_Shikari> b) no descriptive variable names
[22:12:41] <Dark_Shikari> c) _a -style variable names
[22:12:44] <mru> sounds like niedermayer
[22:12:44] <Dark_Shikari> d) no extra parens, EVER
[22:12:52] <Dark_Shikari> no, he's a billion times worse than niedermayer
[22:13:41] <spaam> nice mru
[22:14:02] <peloverde> Then it sounds like the code would suck even with the parentheses
[22:14:19] <Dark_Shikari> peloverde: the lack of parens makes it worse
[22:14:38] <Dark_Shikari> here is prototypical derf code.
[22:14:39] <Dark_Shikari> if(l>14)_val=(_val>>l-14)+((_val&(1<<l-14)-1)+(1<<l-14)-1>>l-14);
[22:14:51] <peloverde> Lack of spaces and shitty variable names is far worse than assumes the reader knows order of operations
[22:15:02] <mru> anyway, that table value is written 0xf800 in the spec
[22:15:05] <Dark_Shikari> this is actually in celt.
[22:15:07] <mru> with no further explanation
[22:15:16] <Dark_Shikari> mru: lol!
[22:15:17] <peloverde> GCC has no business warning about "a&b | c&d"
[22:15:26] <Dark_Shikari> peloverde: what if I wrote
[22:15:30] <Dark_Shikari> a|b & c|d ?
[22:15:36] <Dark_Shikari> spaces can be misleading.
[22:16:02] <peloverde> In that case it should also warn about "a+b * c+d"
[22:16:09] <lu_zero>           
[22:16:16] <Dark_Shikari> yes, but order of arithmetic operations is intuitive from grade school
[22:16:19] <peloverde> I would actually support a warnign about misleading whitespace
[22:16:25] <Dark_Shikari> not all of us speak C as well as we speak english
[22:16:39] <mru> Dark_Shikari: order of logic operation is intuitive from only slightly later
[22:16:42] * lu_zero has the bane of the cables
[22:16:49] <peloverde> & | are boolean arithmetic
[22:16:55] <Dark_Shikari> mru: really?  I didn't know that & overrode |.
[22:17:01] <Dark_Shikari> I assumed they were like + and -.
[22:17:09] <mru> & is multiplication
[22:17:14] <mru> | is saturating addition
[22:17:18] <mru> ^ is wrapping addition
[22:17:19] <Dark_Shikari> lol
[22:17:23] <Dark_Shikari> that's one way of looking at it...
[22:17:28] <Dark_Shikari> Then what's division? ;)
[22:17:33] <mru> 32-bit simd on 1-bit elements
[22:17:36] <peloverde> a software loop
[22:18:08] <peloverde> Didn't you learn order of operations when you learned K-map and other logic reduction techniques?
[22:18:15] <Dark_Shikari> wtf is k-map?
[22:18:21] <mru> karnaugh map
[22:18:26] <Dark_Shikari> never even heard of it
[22:18:33] <Dark_Shikari> when I think of "logic reduction" I think of natural deduction
[22:18:39] <roxfan> writing logical expression as mul/add is pretty common, especially for engineers
[22:18:41] <mru> a very useful technique for reducing logic expressions
[22:18:42] <Dark_Shikari> and demorgan's laws etc etc
[22:19:13] <mru> peloverde: he never studied electrical engineering
[22:19:22] <Dark_Shikari> thank god
[22:19:24] <mru> that's where you learn the useful stuff
[22:19:31] <Dark_Shikari> after one course I wanted to kill EVERYONE
[22:19:38] <Dark_Shikari> they use fucking "j" for sqrt(-1)
[22:19:45] <mru> what else?
[22:19:50] <peloverde> It is the unit vector in the vertical direction
[22:19:51] <Dark_Shikari> 99% of EE is just math dressed up in bullshit to make it look complicated
[22:20:06] <mru> no, EE is maths made to work
[22:20:18] <Dark_Shikari> have you looked at any video coding paper by EEs lately?
[22:20:20] <twnqx> mru: i
[22:20:26] <mru> twnqx: i is current
[22:20:27] <Dark_Shikari> 99% of them consist of 7 pages of math to explain 2 sentences of concept
[22:20:29] <mru> everybody knows that
[22:20:34] <Dark_Shikari> mru: no, I is current.
[22:20:37] <Dark_Shikari> case-sensitivity!
[22:20:40] <mru> nope
[22:20:43] <mru> both are current
[22:20:46] <mru> different currents
[22:20:53] <peloverde> i is small signal current
[22:21:01] <mru> time-variant
[22:21:02] <Dark_Shikari> mru: they could have chosen something that didn't have collisions in the namespace
[22:21:10] <Dark_Shikari> imaginary numbers existed before electrical systems
[22:21:22] <mru> electricity existed before imaginary numbers
[22:21:35] <peloverde> j is the unit vector in the vertical direction
[22:21:39] <Dark_Shikari> It doesn't matter what existed if nobody was modelling it
[22:21:49] <peloverde> that's why j = sqrt(-1)
[22:21:57] <Dark_Shikari> peloverde: no, that would mean y = <0,1>
[22:22:24] <Dark_Shikari> also, i/j/k notation is retarded
[22:22:37] <Dark_Shikari> it's an overly verbose way of expressing vectors
[22:22:44] <mru> what would you say?
[22:22:50] <Dark_Shikari> <0,1,2>
[22:22:50] <Dark_Shikari> not
[22:22:54] <Dark_Shikari> 0i + 1j + 2k
[22:22:54] <mru> I can't think of anything _less_ verbose than a single letter
[22:23:06] <Dark_Shikari> As you can see, bracket notation is less verbose.
[22:23:26] <mru> only if you have all three together at all times
[22:23:37] <Dark_Shikari> If you're dealing with vectors, you generally stay in the same dimensionality.
[22:23:45] <Dark_Shikari> you don't randomly lose half of the vector every 2 steps
[22:24:20] <mru> but you align your coordinate system so stuff naturally falls long an axis if possible
[22:26:01] <peloverde> indeed
[22:26:25] <CIA-92> ffmpeg: mru * r24718 /trunk/libavfilter/avfilter.c: avfilter: free link in/out_formats in avfilter_destroy()
[22:26:29] <CIA-92> ffmpeg: mru * r24719 /trunk/libavfilter/avfilter.c: avfilter: do not crash on null link src/dst in avfilter_destroy()
[22:26:29] <CIA-92> ffmpeg: mru * r24720 /trunk/libavfilter/avfilter.c: avfilter: indent
[22:26:29] <CIA-92> ffmpeg: mru * r24721 /trunk/tools/lavfi-showfiltfmts.c: showfiltfmts: set media type of links to that of corresponding pad
[22:26:29] <CIA-92> ffmpeg: mru * r24722 /trunk/tools/lavfi-showfiltfmts.c: showfiltfmts: destroy filter context before exit
[22:26:43] <mru> hey look, some of us are fixing bugs
[22:27:05] <peloverde> You just dcomitted a patchset you sent out hours ago
[22:27:14] <mru> so?
[22:27:21] <mru> I still fixed it
[22:27:52] <peloverde> If I wanted to, I could save up my patches and commit them in the middle of an argument
[22:28:31] <mru> I committed them now because saste approved them now
[22:28:50] <peloverde> Also I unbroke *BSD today (for certain values of unbreak)
[22:28:57] <mru> yes, good job
[22:29:01] <Dark_Shikari> for certain values of *
[22:29:20] <mru> openbsd still fails wmavoice
[22:31:02] <peloverde> All I remember about compscis at my school was that they pissed and moaned all the way through computer architecture about why they needed to know anything from that class
[22:31:44] <Dark_Shikari> but that's the most interesting class.
[22:32:00] <mru> I remember one suggesting to calculate the parity of a byte with a loop
[22:32:09] <mru> rather than 3 shifts and xors
[22:32:21] <mru> and another had never heard of mmap
[22:32:28] <mru> I'm talking about the teachers here
[22:32:36] <lu_zero> brrr
[22:32:39] <Dark_Shikari> well then you had stupid teachers
[22:33:15] <mru> those can, do etc..
[22:36:53] <peloverde> any idea why openbsd is failing on wmavoice?
[22:37:43] <peloverde> Or why they don't switch to a more modern compiler like gcc 4.2 or clang?
[22:37:49] <Dark_Shikari> because they're openbsd
[22:38:23] <peloverde> (I'm assuming they object to GPLv3 out of principle)
[22:38:27] <mru> yes
[22:39:05] <mru> I may not like gplv3, but I see no reason not to use gcc because of it
[22:39:25] <peloverde> 4.2.1 is still much more recent and uses gplv2
[22:39:58] <Dark_Shikari> hmm.  I wish there was a really clean way in C to partially inline functions
[22:40:09] <peloverde> partially?
[22:40:28] <mru> impartially
[22:40:31] <Dark_Shikari> the only way to do it is via inlined wrappers/defines, which only is convenient for the first part of a function, not the last
[22:41:04] <Dark_Shikari> peloverde: http://pastebin.org/451754 example
[22:41:24] <Dark_Shikari> inline the first part of cabac residual (the coded block flag) and then call the rest of it
[22:41:31] <Dark_Shikari> I did this in vp8 as well
[22:41:50] <Dark_Shikari> very nice techique when you have a small part at the top of a function that can benefit from inlining, but for which the rest is _way_ too large to inline.
[22:42:43] <peloverde> I'm missing something here
[22:44:10] <Dark_Shikari> peloverde: generalized transformation
[22:44:20] <Dark_Shikari> functionA(params) {
[22:44:38] <Dark_Shikari> simple stuff; if(something) { early return } else { do complex stuff }; }
[22:44:49] <Dark_Shikari> transformation:
[22:45:10] <Dark_Shikari> av_noinline functionA_internal(params) {
[22:45:13] <Dark_Shikari> do complex stuff }
[22:45:25] <Dark_Shikari> av_always_inline functionA(params) {
[22:45:26] <Dark_Shikari> simple stuff;
[22:45:32] <Dark_Shikari> if(something) { early return }
[22:45:38] <Dark_Shikari> else {call functionA_internal(params);} }
[22:45:56] <Dark_Shikari> that is partial inlining.
[22:46:01] <peloverde> that seems fine
[22:46:04] <peloverde> totally doable
[22:46:09] <Dark_Shikari> it is.
[22:46:10] <Dark_Shikari> I'm
[22:46:22] <Dark_Shikari> I'm just saying that it's only convenient in some cases.
[22:46:34] <Dark_Shikari> and it would be nice to, say, be able to inline the end of a function.
[22:46:56] <Dark_Shikari> that would require much fancier compiler optimizations though, since you'd have to access stack variables in a function after you've left it
[22:47:12] <Dark_Shikari> Or move the stack variables up a level.  hmm, could do that
[22:47:20] <Dark_Shikari> but then of course you lose the convenient addressing
[22:54:43] <peloverde> sigh, it looks like chrome gave up on determining codec availability at runtime
[22:55:55] <Dark_Shikari> mru: updated that h264dsp split patch
[22:59:39] <lu_zero> ?//
[23:14:36] <peloverde> Stupid question... how do I turn assert()s on?
[23:15:13] <Dark_Shikari> #undef NDEBUG?
[23:15:52] <peloverde> Does that need to be before or after a specific include? Can I do it globally somewhere?
[23:16:17] <CIA-92> ffmpeg: stefano * r24723 /trunk/doc/indevs.texi:
[23:16:17] <CIA-92> ffmpeg: Rename the chapter Devices -> Input Devices, as the file is about
[23:16:17] <CIA-92> ffmpeg: input devices.
[23:16:17] <CIA-92> ffmpeg: stefano * r24724 /trunk/doc/ (indevs.texi outdevs.texi): Apply misc fixes spotted by Diego to indevs.texi and outdevs.texi.
[23:16:17] <CIA-92> ffmpeg: stefano * r24725 /trunk/doc/ (indevs.texi outdevs.texi):
[23:16:18] <CIA-92> ffmpeg: Remove audio_beos entries in indevs.texi and output.devs, BeOS audio
[23:16:19] <CIA-92> ffmpeg: support has been dropped.
[23:16:19] <CIA-92> ffmpeg: stefano * r24726 /trunk/doc/protocols.texi: Apply misc fixes spotted by Diego to protocols.texi.
[23:16:27] <Dark_Shikari> btw, imo, there should be two types of asserts
[23:16:37] <Dark_Shikari> paranoid asserts (disabled by default) and regular asserts( enabled by default)
[23:16:59] <Dark_Shikari> though ideally the latter would return some kind of error instead of dying
[23:17:17] <Dark_Shikari> we have at least some outsanding bugs of ffmpeg dying on invalid inputs due to asserts
[23:18:54] <peloverde> Wasn't there some patch about negative bitrates triggering asserts?
[23:19:08] <Dark_Shikari> there was some problem with invalid mkv files generating an assert somehow
[23:19:20] <twnqx> peloverde: yes. mine.
[23:20:44] <twnqx> hm, i still haven't tested that avi with subs...
[23:21:03] <peloverde> It looks like the same thing happens with negative samplerate
[23:21:30] <Dark_Shikari> Oh GCC, you coy little bitch.
[23:21:36] <Dark_Shikari> Thanks for unrolling my loop for no reason whatsoever.
[23:21:45] <twnqx> Oo
[23:22:14] <peloverde> http://code.google.com/p/chromium/issues/detail?id=42122
[23:22:26] <peloverde> We should open bugs for those
[23:23:13] <Dark_Shikari> +1
[23:23:59] <twnqx> hm
[23:24:33] <spaam> why dont they report it upstream?
[23:24:57] <peloverde> Because google isn't a good open source citizen
[23:29:09] <peloverde> May of the bugs occur in the ogg demuxer :(
[23:29:29] <twnqx> no
[23:29:36] <twnqx> the demuxer just reads the data
[23:29:40] <twnqx> GIGO
[23:29:56] <peloverde> no, there are segfaults in the demuxer
[23:30:05] <twnqx> oh.
[23:30:17] <twnqx> well, apply my patch, and you one more happy customer :P
[23:30:51] <spaam> charlie!
[23:30:57] <spaam> twnqx: :D
[23:32:39] <peloverde> A YouTube goon just admitted they switched to libvorbis encoding... from what I wonder
[23:32:49] <mru> ffvorbis
[23:32:52] <Dark_Shikari> ^
[23:33:02] <kierank> their aac encoder also needs fixing
[23:33:09] <peloverde> I was being facetious, since they won't admit they use ffmpeg
[23:33:11] <Dark_Shikari> s/fixing/throwing in a bin
[23:35:49] <mru> Dark_Shikari: your patch might need fixing for altivec
[23:35:55] <mru> sorry, didn't think of this sooner
[23:36:06] <Dark_Shikari> altivec doesn't have h264 pred code
[23:36:08] <Dark_Shikari> iirc
[23:36:11] <Dark_Shikari> I checked
[23:36:12] <mru> ok then
[23:36:58] <mru> apply it and watch fate
[23:37:04] <Dark_Shikari> ok
[23:37:11] <Dark_Shikari> oh btw, mru
[23:37:23] <Dark_Shikari> modifying get_ue_golomb to eliminate the LUT and go pure av_log2 is faster on core i7
[23:37:30] <Dark_Shikari> where builtin_clz takes 3 cycles
[23:37:34] <Dark_Shikari> it will almost surely be _way_ faster on arm.
[23:37:56] <peloverde> patches welcome
[23:38:05] <mru> yes please
[23:38:06] <Dark_Shikari> I've been sending some
[23:38:19] <Dark_Shikari> mru: this will devolve into bikesheds
[23:38:29] <Dark_Shikari> probably.
[23:38:35] <mru> make patch, benchmark, apply
[23:38:45] <Dark_Shikari> You want to stick ifdefs in golomb.h?
[23:39:12] <Dark_Shikari> I guess we could do #if HAVE_FAST_CLZ?
[23:39:24] <Dark_Shikari> dunno.
[23:39:42] <mru> probably
[23:39:56] <mru> that's enough for benchmarking at least
[23:40:00] <Dark_Shikari> then again, I'm able to cheat in my local patches
[23:40:07] <Dark_Shikari> we are able to guarantee no inside-packet errors occur
[23:40:10] <Dark_Shikari> and each slice fits in a packet
[23:40:14] <Dark_Shikari> so I can gut all error handling
[23:40:38] <Dark_Shikari> av_log2() for example does __builtin_clz(x|1) because clz isn't defined for x == 0
[23:40:43] <Dark_Shikari> which does seem a bit stupid imo
[23:41:13] <mru> that's because some cpus are that stupid
[23:41:30] <mru> I forgot which ones
[23:41:36] <Dark_Shikari> no, I mean that IMO it's fine for av_log2 to be undefined if the input is 0.
[23:41:45] <Dark_Shikari> and in our case, we can guarantee the input will never be 0.
[23:42:50] <mru> there may have been some case that relied on a specific log(0) value
[23:43:11] <mru> there was some discussion as I recall
[23:43:28] <Dark_Shikari> then that should be handled by the caller
[23:43:30] <Dark_Shikari> log(0) is not 1
[23:43:46] <mru> no, but the table-based av_log2 returns 1
[23:43:48] <mchinen> is lavx-gxf regression test broken?
[23:44:06] <Dark_Shikari> log(1) isn't 1 either
[23:44:54] <mru> so?
[23:45:03] <mru> if that's what the old fuction returns...
[23:45:39] <Dark_Shikari> oh my god gcc
[23:45:40] <Dark_Shikari>     if(buf&1) buf= -(buf>>1);
[23:45:40] <Dark_Shikari>     else      buf=  (buf>>1);
[23:45:44] <Dark_Shikari> gcc compiles this as a branch.
[23:45:55] <mru> actually, with |1 av_log2(0) == 0
[23:46:13] <mru> which is what the table-based one does