[FFmpeg-devel-irc] IRC log for 2010-02-24

irc at mansr.com irc at mansr.com
Thu Feb 25 01:00:53 CET 2010


[00:35:29] <felipec> it looks like H.263 and H.264 parsers are doing half the job (not really updating the fields they parse): http://article.gmane.org/gmane.comp.video.ffmpeg.devel/104777
[00:40:13] <felipec> are there bitstream regression tests for H.263, H.264 and MPEG-4? if so, where are the streams?
[00:40:26] <Dark_Shikari> there are tons of regression tests for the decoders
[00:41:29] <felipec> Dark_Shikari: cool, that's what I thought :) but I can't seem to find the data
[00:41:40] <Dark_Shikari> http://fate.multimedia.cx/
[00:42:06] <Dark_Shikari> http://www.mediafire.com/download.php?mi2zjoynymi has 90 megs of regression test files
[00:46:46] <felipec> Dark_Shikari: thanks
[00:46:52] <felipec> downloading
[00:46:58] <Dark_Shikari> note there are no hashes with them.
[00:47:07] <Dark_Shikari> You can generate the hashes by using JM and hashing the output YUV files.
[00:49:30] <felipec> Dark_Shikari: JM?
[00:49:35] <Dark_Shikari> the official reference decoder
[00:49:48] <Dark_Shikari> though you're not testing the decoder
[00:49:53] <Dark_Shikari> so you probably don't need the hashes
[00:50:46] <felipec> Dark_Shikari: well, I want to test the parsers... so testing the decoders would be a good start
[00:51:11] <Dark_Shikari> the decoders are tested automatically by fate
[00:52:38] <felipec> Dark_Shikari: yeah, but if I modify the parser and fate finds out that the decoder is broken, that would help :)
[01:09:59] <J_Darnley> If I wanted to get a commit reverted, should I discuss as a reply on -cvslog or on -devel?
[01:12:33] <Dark_Shikari> cvslog
[01:13:47] <Kovensky> >cvs
[01:17:56] <J_Darnley> okay, thanks
[01:38:35] <troy_s> Anyone know why I keep getting "libavformat/allformats.c:175: error: ‘CONFIG_RTSP_MUXER’ undeclared (first use in this function)" errors with SVN?
[01:38:52] <mru> make config
[01:39:26] <troy_s> mru: Then make alone I assume?
[01:39:37] <mru> yes
[01:39:46] <mru> make config reruns configure with same flags as last time
[01:39:53] <troy_s> mru: You are terrific sir. Thank you kindly.
[01:40:10] <troy_s> mru: So every svn up I need to follow with a make config correct?
[01:40:34] <mru> only when new stuff is added to config.h
[01:41:25] <Honoome> mru: does make -j14 config all work? :P
[01:41:43] <mru> not sure
[01:42:02] <mru> probably not
[01:42:33] <mru> there's no dependency between config and other stuff
[01:43:44] <ohsix> is that the same target thats run when maintainer mode is enabled and the build files need to be regenerated?
[01:43:59] <mru> eh?
[01:44:04] * ShadowJK is starting to suspect the bottleneck for screencapture is in x11grab rather than the video codecs
[01:44:04] <mru> this ain't autohell, dude
[01:44:51] <ramiro> ShadowJK: what does profiling say?
[01:45:33] <Honoome> (forced) maintainer mode is one of the worst features in autotools
[01:45:46] <ramiro> I still don't know what maintainer mode is...
[01:47:31] <Honoome> ramiro: basically it adds rules so that changing any of the “original” files (Makefile.am, configure.ac) rebuilds the involved autotools “automagically” and eventually re-run ./configure
[01:47:50] <mru> including cryptic failure at the end
[01:48:25] <Honoome> unfortunately this breaks in a looot of cases
[01:48:35] <Honoome> not only it might very well fail to rebuild anything if the autotools aren't available
[01:48:35] <Honoome> sometimes it tries to rebuild with a slightly-different version of autotools because distributions package different versions
[01:48:41] <ramiro> Honoome: ah, so that's why when I type make it configures again...
[01:48:47] <Honoome> other times it fails because the versions don't match
[01:49:23] <Honoome> and finally, since autotools developers can't work their shit together, and every distribution has its own wrapper to support multiple automake (and autoconf) versions, they can even rebuild the stuff with *totally different* versions
[01:49:29] <Honoome> ramiro: yeppers
[01:50:20] <Kovensky> the best thing is when an upstream package comes with a broken configure script
[01:50:45] <Honoome> Kovensky: don't get me started
[01:50:49] <Yuvi> my favorite use of autotools is mozilla's
[01:50:51] <Honoome> I could start ranting now and finish next week
[01:50:52] <Kovensky> < Honoome> (forced) maintainer mode is one of the worst features in autotools <-- it is forced? D:
[01:50:56] <Kovensky> I thought only autogen enabled that
[01:51:12] <Honoome> Yuvi: NOOOOOOOOO >_< please don't even name that one! it's real autoshit! It's still based on autoconf 2.13!! >_<
[01:51:22] <Yuvi> Honoome: hehe
[01:51:26] <Kovensky> lol
[01:51:35] * Kovensky maintains an autotools-based build system ._.
[01:51:47] <ramiro> Kovensky: what for?
[01:51:52] <Honoome> Kovensky: uhm see here's the catch: a long time ago, it wasn't available; then they added AM_MAINTAINER_MODE that _allowed_ it optionally
[01:51:53] <Kovensky> ffms2
[01:52:18] <ramiro> Kovensky: you're an ffms2 developer too?
[01:52:20] <Honoome> then they decided that it was too variable, and made it _the default_ without any way to disable it *unless* you call AM_MAINTAINER_MODE, which then adds you the *option* to turn it off
[01:52:42] <Kovensky> ramiro: not really, I just do build system stuff
[01:52:55] <Kovensky> Honoome: ._.
[01:53:03] <Honoome> Kovensky: I started writing this ;) http://www.flameeyes.eu/autotools-mythbuster/index.html I actually think autotools can work fine… but upstream sucks at getting their shit together
[01:53:04] <ramiro> Kovensky: last time I tried ffms2 it was cmake, why do you do autotools-based stuff?
[01:53:20] <mru> Honoome: upstream sucks, and all the users suck
[01:53:21] <Kovensky> ramiro: because the cmake stuff was very broken
[01:53:37] <Dark_Shikari> ramiro: they swapped away from cmake
[01:53:39] <mru> cmake is _more_ broken than autohell
[01:53:58] <Honoome> mru: most of… not all of it… and it's still better than half the custom build systems out there, or those based on scons, imake, cmake, …
[01:53:59] <Kovensky> the best part of cmake is option passing
[01:54:01] <Kovensky> there is none
[01:54:03] <ramiro> Dark_Shikari, Kovensky: oh, nice choise. going from cmake to autotools =)
[01:54:08] <Kovensky> unless you use a variable
[01:54:18] <Kovensky> -D VARIABLE_NAME:type=value
[01:54:30] <Kovensky> and there is no way to know what are the variables without reading source
[01:54:33] <Honoome> cmake had the chance to learn about the mistakes about autotools usage both up- and down- stream and get it right
[01:54:44] <Honoome> they didn't do that :|
[01:54:54] <ohsix> configure scripts are generated files; usually only generated for disttribution, you're supposed to bootstrap it yourself if its from source control
[01:55:06] <Dark_Shikari> ramiro: I'm not an ffms dev >_
[01:55:09] <ramiro> ohsix: not in FFmpeg...
[01:55:39] <Honoome> I'm curious to see what Nokia will do with their buildsystem instead… not that I'd like to depend on Qt… but it might get some people re-think about cmake if they do it right
[01:55:46] <ramiro> Dark_Shikari: but you're a strong supported... You should point them away from those bad choices...
[01:55:53] <ramiro> s/supported/supporter/
[01:56:04] <Kovensky> ohsix: I committed the generated configure script and stuff because I didn't want to hear from MSYS users ._.
[01:56:08] <ohsix> ramiro: he was talking about "broken" configure scripts
[01:56:11] <Dark_Shikari> ramiro: configure is better than cmake
[01:56:12] * Honoome is a build system otaku, if somebody didn't notice
[01:56:16] <Dark_Shikari> if it works, it works
[01:56:17] <Kovensky> MSYS is USELESS for almost everything
[01:56:32] <Dark_Shikari> ramiro: here's the most important thing
[01:56:35] <Dark_Shikari> WINDOWS DOES NOT HAVE PKG-CONFIG.
[01:56:37] <ramiro> Kovensky: what? how's that?
[01:56:38] <Dark_Shikari> aka you are fucked
[01:56:48] <ohsix> Kovensky: heh; then you could just preconfigure it for msys and export a tree with config.h and templated files already configured
[01:57:02] <ramiro> Dark_Shikari: pkg-config works on Windows... I've used it before.
[01:57:17] <CIA-92> ffmpeg: michael * r22012 /trunk/libavcodec/h264.h: Remove unused variable. Seems i forgot to commit this.
[01:57:18] * mru must dust off the mips/irix machine one day
[01:57:48] <Dark_Shikari> ramiro: it works
[01:57:51] <Dark_Shikari> but nobody has it installed
[01:57:59] <ramiro> hmmm. so you install it?
[01:58:22] <CIA-92> ffmpeg: michael * r22013 /trunk/libavcodec/h264.h: Replace /2 by faster >>1 as the mvd values are now all positive.
[01:58:24] <ramiro> I admit it was a pain though
[01:58:33] <Kovensky> yes, at least gtk has precompiled pkg-config packages that work fine on msys
[02:00:20] <ohsix> you can always put a pkg-config at the front of your path that emulates it :>
[02:00:24] <mru> autoconf isn't a terrible _idea_
[02:00:43] <mru> it's just that they made every mistake possible in the implementation
[02:01:27] <ohsix> they were trying to write their sendmail.cf and they ended up with a configuration management tool
[02:01:36] <mru> ohsix: on linux I've put a pkg-config at the front of the path that removes all the broken flags
[02:02:07] <ohsix> heh word; i've done the same, once it calls out to any app like that you can easily fudge it if you need to; which is nice to be able to do
[02:02:21] <Honoome> mru: which broken flags?
[02:02:35] <mru> like -L/usr/lib when cross-compiling
[02:02:56] <Honoome> blah that stuff is a bad one, we really should have $CHOST-prefixed pkg-config scripts for the cross-compile
[02:03:07] <ramiro> mru: what about the sysroot option for pkg-config?
[02:03:12] <mru> doesn't work
[02:03:16] <ramiro> at all?
[02:03:41] <mru> nope
[02:04:20] <Honoome> ramiro: I think there's a pkg-config bug on bugs.fd.o : “pkg-config is broken for cross-compile”
[02:04:31] <mru> I have to first twiddle the environment to point at the cross-root
[02:04:39] <mru> then I filter the output through sed "s!\\(-[IL]\\)\\(/lib\\|/usr\\)!\\1${ROOT}\\2!"
[02:04:43] <ohsix> that kind of idea is kind of leaky Honoome; you have the same problem you do int he first place, its hard to slot software in, it makes building single trees with all supported software easy though
[02:05:31] <ohsix> pc files are generally configured like the .h.in files for paths and stuff and maybe some extra cflags
[02:05:38] <mru> then I have a pageful of autoconf cache variable overrides
[02:05:40] <Honoome> ohsix: hm? what do you mean? you got arm-linux-pkg-config that looks for stuff in /usr/arm-linux-pkg-config/lib/pkgconfig rather than /usr/lib/pkgconfig
[02:05:59] <Kovensky> < Honoome> blah that stuff is a bad one, we really should have $CHOST-prefixed pkg-config scripts for the cross-compile <-- yes, autotools checks for that when on cross-compile mode
[02:06:01] <mru> Honoome: that's not where my cross-root is
[02:06:05] <Kovensky> and that's also how x264 does it
[02:06:11] <Honoome> mru: or whatever else you configure it to :)
[02:06:11] <mru> I have about a dozen differnt cross-roots
[02:06:19] <mru> many of them the same platform
[02:06:23] <Kovensky> I have a patch on my own mplayer tree that also uses $CHOST-pkg-config, and a patch for ffmpeg's configure that I've been too lazy to send to ML
[02:06:24] <mru> but very different configurations
[02:06:25] <Honoome> mru: you have PKG_CONFIG_PATH to look stuff up ;)
[02:06:39] <mru> yes, I twiddle that one in my wrapper script
[02:06:47] <mru> but it still spits out -L/usr/lib
[02:07:00] <mru> and then libtool puts -L/usr/lib back
[02:07:09] <mru> so I have to wrap the compiler in a script to filter it out again
[02:07:11] <Kovensky> PKG_CONFIG_PATH doesn't make it ignore the default path
[02:07:33] <Kovensky> ./configure  --with-pc-path=/usr/local/i686-mingw32/lib/pkgconfig --enable-indirect-deps --program-prefix=i686-mingw32-
[02:07:40] <Kovensky> ^ the line I used to build my pkg-config
[02:08:05] <mru> that's too rigid
[02:08:27] <Kovensky> that's ofc not the main pkg-config, but the one that is used when cross-compiling
[02:08:42] <mru> as I said, I have about a dozen cross-roots
[02:08:50] <mru> some use the same tool prefix
[02:09:03] <Kovensky> it is a problem if they use the same prefix
[02:09:09] <Honoome> mru: yeah I know quite a few problems… one of the problems is with .la files, and another is with gentoo's insistance on using stupid ldscripts for /usr/lib/libfoo.so instead of not adding it at all if the library is in /lib :(
[02:09:18] <mru> I delete .la files
[02:09:28] <Kovensky> libtool is FUCKING ANNOYING <_<
[02:09:36] <ohsix> heh yea libtool is annoying
[02:09:49] <Kovensky> I had to workaround like 3 windows bugs in libtool in the build system
[02:09:52] <mru> so far I've found two things that broke from deleting .la files
[02:09:58] <Kovensky> all very well known bugs that are either WONTFIX or just plain stupid
[02:10:04] <mru> imagemagick and librep
[02:11:38] <Kovensky> well, bed time ._.
[02:11:40] * Kovensky is off
[02:14:52] <Honoome> mru: and libtool's own macros =_=
[02:15:18] <mru> yeah, of course
[02:15:57] <mru> but my system is happy with no other .la files than libltdl.la in /usr/lib
[02:16:48] <mru> imagemagick uses some misguided dynamic loader for various components
[02:17:18] <ohsix> one thing that bugs me is packages that use autoconf but basically build only one place, or they dont support any of the compiler versions or linkers the scripts do; so its just as fragile and much more noisy than a nieve build script which you can always force if push comes to shove
[02:17:21] <mru> and somehow it fails if the .la files for those are deleted
[02:19:16] <ohsix> naive :<
[02:20:03] <ohsix> it would be way cool if there was something less messy that would let you do the same sort of stuff with host triplets and platform configuration
[02:20:32] <Honoome> ohsix: would be nicer already of people learnt not to just use autoscan
[02:20:43] <Honoome> or stopped testing for 20 functions when they use only two
[02:20:50] <Honoome> and don't even provide replacement, but just fail anyway if they are missing
[02:21:06] <Honoome> and started using non-recursive automake
[02:21:08] <ohsix> same idea though
[02:21:25] <mru> or checking for fortran, c++, and ada when they only need c
[02:21:27] <ohsix> the breakage anyways; might as well not even start
[02:21:34] <Honoome> mru: that's an old libtool bug
[02:21:34] <mru> and FAILING if one is missing
[02:21:40] <Honoome> it's fixed if you use libtool 2
[02:22:13] <ohsix> mru: doesn't that work right if you use AM_PROG_CC?
[02:22:21] <ohsix> right/as expected
[02:22:24] <mru> don't know
[02:22:34] <mru> I've just been annoyed by packages failing to build for no reason
[02:22:40] <Honoome> it's old libtool bugs
[02:22:46] <ohsix> i remember seeing that a few times but it was fromd efaults when stuff was omitted
[02:22:48] <Honoome> pre-1.5, it checked and failed if C++ compiler wasn't found
[02:23:04] <Honoome> for 1.5 it still checked C++ and Fortran but didn't die
[02:23:13] <Honoome> 2.x does not check for C++ or Fortran by default
[02:23:29] <Honoome> [and caused quite a bit of trouble as quite a few packages used C++ and never used AC_PROG_CXX =_=]
[02:23:48] <mru> I was getting to that part
[02:23:51] <Honoome> problem is you have to get upstream to release tarballs using *updated autotools chains* rather than the crappy stuff that comes with RHEL5
[02:23:57] <mru> that upgrading any piece of that crap breaks everything
[02:24:22] <Honoome> one more reason why they should stop pretending they are standalone projects and just make it *one fucking big project*
[02:24:51] <Honoome> remove the redundancies, reduce the code, possibly get to pre-define special routes…
[02:25:16] <Honoome> and the other thing that needs to die is gnulib
[02:25:28] <Honoome> nice idea when you first look at it, a nasty can of worms when you actually see it used
[02:26:08] <mru> gnulib?
[02:26:54] <Honoome> mru: replacement functions for stuff that is not supported by older C libraries and similar
[02:29:10] <Honoome> mru: there, I posted a draft I had laying around for a while: http://blog.flameeyes.eu/2010/02/24/reinventing-lots-of-little-wheels
[02:49:31] * Honoome wonders if mru is trying to save his kittens from being killed by the gnulib users
[06:13:50] <elenril> J_Darnley: why do you want to revert that patch?
[06:14:04] <elenril> /morning/
[06:14:54] <kshishkov> (is it?)
[06:15:46] <CIA-92> ffmpeg: ramiro * r22014 /trunk/ffprobe.c: FFprobe: take only one input file.
[06:15:58] * elenril thinks it is
[06:16:32] <kshishkov> any hard evidence?
[06:17:03] <elenril> CTCP TIME reply from kshishkov: Wed Feb 24 08:16:03 2010
[06:17:03] <mru> birds are singing
[06:17:41] <kshishkov> mru: birds are coughing
[06:18:07] <kshishkov> elenril: looks like morning has nothing in common with time of day on IRC
[06:18:31] <elenril> ofc it does
[06:18:42] <elenril> morning is when i say it's morning
[06:18:52] <byteme`> Hi I'm a computer science student.  Looking to join an OSS project and contribute
[06:19:48] <kshishkov> send a patch, it's a good gesture
[06:20:17] <kshishkov> elenril: ok, you said so on your own free will. I'll take a note.
[06:20:18] <elenril> if there's someone active enough to apply it =p
[06:20:35] <elenril> btw <insert usual question here>
[06:21:01] <Dark_Shikari> byteme`: both x264 and ffmpeg are good targets for contributions ;)
[06:21:09] <Dark_Shikari> the most important thing is:
[06:21:17] <Dark_Shikari> 1) figure out how things work, preferably by asking questions until you do
[06:21:28] <Dark_Shikari> 2) there are no stupid questions, only stupid people
[06:21:43] <Dark_Shikari> 3) start small.  find something little you want to do first.
[06:22:01] <kshishkov> elenril: told you, wait for benoit-. Or give me the reference to the thread where that patch is (and was okayed)
[06:22:55] <byteme`> Dark_Shikari: okay.
[06:23:15] <elenril> kshishkov: http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/2010-February/083341.html
[06:23:59] <elenril> http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/2010-February/083590.html
[06:24:17] <Dark_Shikari> byteme`: it also depends what you want to do and are interested in, of course
[06:24:23] <byteme`> Dark_Shikari: Currently, I've been looking at the 'small tasks' page on the wiki to get some ideas on contributions.  The LZW encoder being extended to support GIF sounds interesting
[06:24:34] <Dark_Shikari> I'd probably divide tasks into the following:
[06:24:39] <elenril> http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/2010-February/083705.html
[06:24:43] <Dark_Shikari> 1) deep magic fun encoder stuff
[06:24:48] <Dark_Shikari> 2) black magic assembly stuff
[06:24:56] <Dark_Shikari> 3) decoder stuff
[06:24:58] <Dark_Shikari> 4) muxer/demuxer stuff
[06:25:12] <Dark_Shikari> 5) bugfixing (a little of everything)
[06:25:42] <Dark_Shikari> notably the main difference between encoding and decoding being that in decoding it's a 1-dimensional problem: all you care about is efficiency, basically, since there's only one right way to do it.
[06:25:51] <Dark_Shikari> in encoding, it's a 2-D problem: you have to do it fast, and well.
[06:26:18] <mru> just use a space-filling hilbert curve, problem solved
[06:26:59] <Dark_Shikari> lol
[06:26:59] <byteme`> Porting missing decoders/demuxers from other projects seems interesting as well
[06:27:08] <byteme`> I'm not sure if I'm advanced enough to handle writing an encoder yet.
[06:27:10] <Dark_Shikari> yeah, though they have to be lgpl-compatible
[06:27:14] <Dark_Shikari> well, WRITING an encoder is hard
[06:27:19] <Dark_Shikari> but jumping into an existing encoder is much easier
[06:27:26] <Dark_Shikari> you can blackbox everything scary and poke at one little thing
[06:27:31] <Dark_Shikari> also, have you thought of summer of code?
[06:27:37] <kshishkov> elenril: ok, I ignored most of those links
[06:27:54] * elenril expected as much =p
[06:28:00] <CIA-92> ffmpeg: kostya * r22015 /trunk/libavformat/ (nut.c nut.h nutenc.c nutdec.c):
[06:28:00] <CIA-92> ffmpeg: Introduce metadata conversion table for NUT encoder.
[06:28:00] <CIA-92> ffmpeg: Patch by Anton Khirnov (wyskas, do no evil mail)
[06:28:00] <CIA-92> ffmpeg: Thread "[PATCH] nut metadata conversion table"
[06:28:23] <elenril> o_0 thanks
[06:28:24] <byteme`> Dark_Shikari: haven't thought about it.  This is my first attempt at trying to join an OSS project.
[06:29:35] <elenril> actually it's not just muxer, the table applies to demuxer too
[06:30:03] <mru> (join byteme` (match-attr 'oss (get-projects)))
[06:30:12] <Dark_Shikari> lol
[06:30:23] <Dark_Shikari> Haskell > lisp
[06:30:36] <byteme`> I'm looking at the SoC wiki page... lots of interseting projects attempted/completed the last few years
[06:30:37] * mru is hacking gcc rtl atm
[06:30:47] <Dark_Shikari> byteme`: here's a paste from an email to a student that asked me a few questions a while back
[06:30:51] <Dark_Shikari> http://pastebin.com/59qGQj7D
[06:31:03] <Dark_Shikari> I think it's a bit relevant here.
[06:31:15] <thresh> moroning
[06:31:35] <kshishkov> elenril: corrected. Wait another month for other patches to apply or ask you know who
[06:31:37] * kierank can vouch for what Dark_Shikari said
[06:31:54] <Dark_Shikari> also, kierank is one of those guys who played the "ask questions for 3 weeks until he understood everything" game
[06:32:16] <byteme`> Dark_Shikari: that email is very inspiring
[06:32:16] <kshishkov> Dark_Shikari: writing encoder is easy, the hard stuff is to make it perform well
[06:32:33] <Dark_Shikari> indeed.
[06:32:39] <mru> writing bitstream formatter is easy
[06:32:43] <Dark_Shikari> though writing the framework for a big encoder can be scary
[06:32:45] <mru> figuring out what to feed it is hard
[06:33:01] <byteme`> I'm actually a junior right now.
[06:33:12] <Dark_Shikari> which university?
[06:33:19] <byteme`> I don't particularly find my classes that difficult so hopefully I can find something challenging in a project
[06:33:24] <byteme`> Regis University
[06:33:46] <mru> staying connected can be enough of a challenge at times
[06:34:05] <mru> comcast...
[06:34:07] <byteme`> hmmmm nice irc client crash...
[06:34:13] <Dark_Shikari> lol
[06:34:16] <Dark_Shikari> 14:33 <@mru> staying connected can be enough of a challenge at times
[06:34:18] <kierank> mru: it's comcastic
[06:34:29] <pJok> mornings
[06:34:36] <byteme`> Anyway, I go to Regis University
[06:34:43] <mru> where's that?
[06:34:48] <byteme`> it's not a well known school, but the only school I could get into
[06:34:50] <Dark_Shikari> http://en.wikipedia.org/wiki/Regis_University
[06:34:56] <byteme`> It's a private university in Colorado
[06:35:06] <Dark_Shikari> started by the jesuits.  doesn't sound too bad, the jesuits were pretty awesome.
[06:35:49] * elenril wonders how does git-svn react to svn prop changes
[06:36:02] <mru> it doesn't
[06:36:04] <kshishkov> compare to http://en.wikipedia.org/wiki/Kharkiv_Polytechnical_Institute
[06:36:24] <byteme`> After I graduate, I'm going to apply for graduate MSCS at University of Colorado at Boulder or possibly Colorado State University Masters in CompSci
[06:36:34] <Dark_Shikari> kshishkov: LOL at the comments people are stuffing in the article
[06:36:40] <Dark_Shikari> National Technical University "Kharkiv Polytechnical Institute" is one of the oldest technical universities in Ukraine and one of the finest in eastern and southern Europe. {Wishful thinking, check the ratings.}
[06:36:41] <kierank> lol
[06:37:00] * Dark_Shikari has http://en.wikipedia.org/wiki/Harvey_Mudd_College
[06:37:25] <kshishkov> Dark_Shikari: well, finest = easy to get in, very hard to get thrown out
[06:37:30] <Dark_Shikari> LOL
[06:37:48] <byteme`> Anyway my name is Jeff, nice to meet you all :)
[06:38:38] <byteme`> Dark_Shikari: I sent myself a copy of that email you posted so I can refer to it for inspiration
[06:38:46] <Dark_Shikari> if you like encoder stuff, might want to drop by #x264 + #x264dev as well
[06:38:53] <Dark_Shikari> byteme`: I can send you the whole email, it has a lot of info on SoC and similar
[06:39:04] <byteme`> sure
[06:39:06] <Dark_Shikari> email?
[06:39:12] <byteme`> want me to pm it?
[06:39:26] <byteme`> jeff2321 at gmail.com
[06:39:35] <Dark_Shikari> sent
[06:39:40] <byteme`> thanks man :)
[06:39:42] <kshishkov> spam to follow
[06:39:56] <Dark_Shikari> lol
[06:39:58] <byteme`> I've had that email for a long time
[06:40:01] <Dark_Shikari> it's true, this channel is publicly logged
[06:40:05] <byteme`> it gets spammed anyway
[06:40:06] <Dark_Shikari> not like anyone cares
[06:40:10] <Dark_Shikari> everyone gets massive spam these days
[06:40:15] <Dark_Shikari> good thing for gmail's amazing spam filter.
[06:40:27] <kierank> i get weird spam after being in x264 git
[06:40:36] <kierank> about lists of hospitals
[06:40:50] <Dark_Shikari> lol
[06:41:15] <mru> kierank: be in x264 too long and you'll need 'em
[06:41:30] * kshishkov has an alternative address "kostya.forjunk" but it gets spam only once a week
[06:41:33] <byteme`> another idea I had was a new gui for vlc
[06:41:55] <byteme`> but perhaps people like the gui the way it is
[06:42:40] * kshishkov prefers default MPlayer gui
[06:43:05] <kierank> as long it as it's not obnoxious like powerdvd or totalmedia theatre
[06:43:08] <elenril> weren't you saying you don't use mplayer?
[06:43:13] * mru watches it mostly in md5
[06:43:23] <byteme`> well I was thinking a different gui for htpc deployments
[06:43:33] <Dark_Shikari> we call that mythtv
[06:43:36] <kshishkov> elenril: FFplay lacks good video output
[06:43:40] <mru> and xbmc
[06:43:41] <Dark_Shikari> or xbmc
[06:43:48] <mru> xor?
[06:44:01] <kshishkov> elenril: but if that's fixed, I'll gladly drop MPlayer
[06:45:19] <kierank> Dark_Shikari: also, *only* 1/5th of x264
[06:45:20] <Dark_Shikari> dropping mplayer is a bad idea, it might break when it hits the floor
[06:45:30] <Dark_Shikari> kierank: I think LOC wise that's not unreasonable
[06:45:43] <kierank> i would have thought it was more
[06:45:50] <benoit-> good morning
[06:45:55] <benoit-> (or whatever)
[06:46:01] * elenril thinks mplayer doesn't die when it's dropped
[06:46:25] <kshishkov> Dark_Shikari: no, it's all parts tightly hacked together
[06:46:45] <kshishkov> the only way to break it is to make it use only public APIs for all libs
[06:46:50] <Dark_Shikari> kierank: think of all the parts that I have mostly not touched
[06:46:54] <Dark_Shikari> encoder.c, set.c, VLC tables
[06:46:55] <Dark_Shikari> powerpc asm
[06:46:56] <kshishkov> benoit-: your patch monkey skills are needed
[06:46:58] <Dark_Shikari> sparc asm
[06:47:08] <Dark_Shikari> lots of C implementations of DSP functions
[06:47:11] <Dark_Shikari> which nobody will ever modify ever
[06:47:51] <benoit-> kshishkov: well, my coding skills are needed too here...
[06:48:16] <benoit-> I have no time to test things enough before checking code in; so I prefer not checking in
[06:48:48] <kshishkov> benoit-: where you are going to apply those skills?
[06:50:13] <benoit-> kshishkov: at my workplace
[06:50:30] <benoit-> (sorry, my sentence was unclear)
[06:50:45] <kshishkov> benoit-: ok, tell that to elenril
[06:51:14] * elenril bashes head against wall ;)
[06:52:01] <benoit-> kshishkov: I saw that yesterday
[06:52:34] <benoit-> elenril: ping some of your patches that need to be applied; I'll see if I find some time to do it this morning
[06:59:15] <elenril> done
[07:05:17] <byteme`> Dark_Shikari: looks like you are in Australia.  I visited Sydney last year -- should an amazing place.
[07:05:23] <byteme`> s/should/such/
[07:05:38] <kshishkov> wrong
[07:06:13] <kshishkov> it's just his proxy has an Australian domain name
[07:06:20] <Dark_Shikari> byteme`: nope
[07:06:25] <Dark_Shikari> my remote shell has an AU domain
[07:06:28] <byteme`> oh
[07:06:31] <Dark_Shikari> it's based on michigan or so
[07:06:32] <byteme`> hehe :)P
[07:06:33] <Dark_Shikari> Harvey Mudd is in Claremont, CA
[07:06:59] <byteme`> is it good to use a shell to access irc?
[07:07:05] <byteme`> hmmm
[07:07:05] <kshishkov> yes
[07:07:16] <Dark_Shikari> extremely good
[07:07:17] <Dark_Shikari> 1) you never log off
[07:07:20] <Dark_Shikari> 2) you never miss anything
[07:07:24] <byteme`> I've got one... let me switch to it
[07:07:26] <Dark_Shikari> 3) when you get on in the morning, you can see what you missed
[07:07:33] <Dark_Shikari> 4) you get to use irssi, the IRC client of the future!
[07:07:42] <byteme`> I'll just put irssi in a screen
[07:07:50] <kierank> #4 is why i haven't asked checkers for a bnc
[07:07:52] <kshishkov> 5) you are not restricted by stupid filtering rules of the local machine
[07:08:06] <Dark_Shikari> 6) you can access your IRC from anywhere
[07:08:08] <Dark_Shikari> so not only do you not miss anything
[07:08:13] <Dark_Shikari> but you can "not miss anything" from anywhere
[07:09:00] <byteme`> comcast tends to go down late at night
[07:09:10] <byteme`> which is another problem
[07:09:29] <kshishkov> well, saying "comcast" is enough
[07:09:47] <Dark_Shikari> lol
[07:09:51] <byteme`> there we go
[07:09:52] <Dark_Shikari> that's another reason to use a remote shell
[07:09:55] <kierank> comcast engineering at the higher level is supposedly very good
[07:10:03] <Dark_Shikari> comcast was even worse for me
[07:10:04] <kierank> and they're making an effort with things like ipv6 and dnssec
[07:10:04] <Dark_Shikari> here's how bad it was
[07:10:12] <Dark_Shikari> you connect to IRC, and it SPAMMED YOU WITH RST PACKETS
[07:10:14] <Dark_Shikari> disconnecting you completely
[07:10:21] <Dark_Shikari> I had to use a remote shell over an encrypted connection
[07:10:23] <Dark_Shikari> to even access IRC
[07:10:28] <Dark_Shikari> anything else would RST-dump me
[07:10:32] <Dark_Shikari> last I tried, they still did this
[07:10:44] <Dark_Shikari> it even RST dumped me if I connected to IRC via telnet, manually, by typing in commands
[07:10:46] <kierank> maybe it was an anti-botnet feature
[07:10:54] <byteme`> wow
[07:10:56] <elenril> at least freenode supports ssl now
[07:10:56] <thresh> OMG, RST packets, cant resist them!
[07:11:24] <byteme`> I'm going to yell at my friend that works at comcast then
[07:11:37] <byteme`> he's a senior network guy at comcast here in colorado
[07:11:43] <Dark_Shikari> byteme`: it might no longer be true
[07:11:46] <Dark_Shikari> I don't use comcast myself
[07:11:48] <Dark_Shikari> I use a university connection
[07:12:05] <Dark_Shikari> I wouldn't harass him until I go back home for the summer and confirm it again ;)
[07:12:15] <kierank> everyone should use linksys, the worlds largest isp
[07:12:17] <Dark_Shikari> I mean, I really hate when people bug report things that I fixed 6 months ago
[07:12:22] <Dark_Shikari> so I don't do it to anyone else either
[07:12:26] <Dark_Shikari> kierank: +1
[07:12:32] <kierank> 100% reliable
[07:12:33] <byteme`> I usually give him crap anyway :)
[07:12:38] <byteme`> just beause he works at comcast
[07:12:41] <kshishkov> here we mostly stuck with D-link, it seems
[07:12:52] <Dark_Shikari> I like my uni connection
[07:12:57] <Dark_Shikari> 1gbit down, limited to 100mb by wires
[07:13:14] <Dark_Shikari> couple-millisecond ping to many places on the west coast
[07:13:22] <byteme`> my comcast line has better bandwidth than my university
[07:13:23] <Dark_Shikari> .... and slower upload than a comcast connection.
[07:13:24] <kierank> I plugged into the lan at cern once
[07:13:27] * kshishkov cannot say anything about his uni connection as it's well-hidden from students
[07:13:40] <elenril> why slow upload?
[07:13:46] <kshishkov> kierank: and then HL happened?
[07:14:06] * elenril has 100mb/100mb on uni connection
[07:14:08] <kierank> the guy was giving a presentation about the european academic networks and their superior capacity and I said yeah because all those torrents need their bandwidth
[07:14:19] <kierank> screw the lhc data
[07:14:20] <byteme`> haha
[07:15:24] <Dark_Shikari> if I can't download a 1080p movie faster than I can watch it
[07:15:27] <Dark_Shikari> the connection is too slow.
[07:16:14] <kierank> do you not have usage limits?
[07:16:18] <Dark_Shikari> nope
[07:16:30] <Dark_Shikari> heavily limited upload, 500kbps only
[07:16:32] <kshishkov> Dark_Shikari: try that with raw 1080p movies
[07:16:33] <Dark_Shikari> but unlimited DL
[07:16:38] <Dark_Shikari> kshishkov: I did, big buck bunny
[07:17:14] <Dark_Shikari> the funny thing is our internet is so fast that you can get to the top of the usage chart in about 2 hours
[07:17:33] <kshishkov> here upload is not so limited
[07:17:42] <kshishkov> if you know that download is 1mbps
[07:31:52] <CIA-92> ffmpeg: benoit * r22016 /trunk/libavformat/asfdec.c:
[07:31:52] <CIA-92> ffmpeg: asfdec: only unicode tags must have even length.
[07:31:52] <CIA-92> ffmpeg: Patch from: Anton Khirnov wyskas gmail
[07:33:07] <CIA-92> ffmpeg: benoit * r22017 /trunk/libavformat/asfdec.c:
[07:33:07] <CIA-92> ffmpeg: asfdec: fix a memleak.
[07:33:07] <CIA-92> ffmpeg: Patch from Anton Khirnov wyskas gmail
[07:33:36] <kshishkov> hmm, too many elenril patches applied this month
[07:33:56] * elenril stabs kshishkov 
[07:33:59] <elenril> benoit-: thanks
[07:34:07] <CIA-92> ffmpeg: benoit * r22018 /trunk/libavformat/asfdec.c:
[07:34:07] <CIA-92> ffmpeg: asfdec: add a debug message about skipped tags.
[07:34:07] <CIA-92> ffmpeg: Patch from Anton Khirnov wyskas gmail
[07:35:01] <CIA-92> ffmpeg: benoit * r22019 /trunk/libavformat/asfdec.c:
[07:35:02] <CIA-92> ffmpeg: asfdec: skip byte array tags.
[07:35:02] <CIA-92> ffmpeg: Patch from Anton Khirnov wyskas gmail
[07:38:31] <benoit-> elenril: I thought you had more than this four ones, didn't you ?
[07:39:17] <elenril> yes, there's one trivial documentation patch (mention that metadata tags are UTF-8)
[07:39:53] <elenril> and patches in "asf - read/write metadata as UTF-16", but i'm yet to decipher which ones are OK'ed
[07:46:29] * elenril goes to school, bbl
[08:28:52] * av500 sets this as new browser homepage: http://bijint.com/en/
[08:35:32] <superdump> av500: ?
[08:35:43] <superdump> is that just a girl holding up a sign saying the time on it?
[08:35:49] <superdump> that updates every minute
[08:36:29] <av500> yes
[08:37:12] <av500> I guess ffmpeg devs will prefer the http://bijint.com/jp/ version though
[08:37:23] <benoit-> meaning that you interrupt what you're doing every minute to be sure not to lose one pic ?
[08:37:25] <byteme`> that url doesn't even render in my browser
[08:37:36] <benoit-> BTW, hi Rob
[08:38:59] <Dark_Shikari> superdump: lol
[08:39:17] <superdump> hey benoit-
[08:39:20] <Dark_Shikari> they really went through and had her hold up every single one?
[08:39:38] <superdump> it's a different girl now
[08:39:49] <superdump> maybe they just stood in a city and asked someone to hold the sign
[08:39:55] * av500 waits for the android app, his mobile carrier rejoices
[08:40:01] <Dark_Shikari> looks the same to me
[08:40:11] <Dark_Shikari> oh wait, you're right
[08:40:23] <thresh> :)
[08:40:36] <av500> and you even get to know her blood type!
[08:40:40] <Dark_Shikari> this is japan
[08:40:44] <Dark_Shikari> blood type is more important than your age
[08:40:48] <kierank> ?
[08:41:03] <Dark_Shikari> http://en.wikipedia.org/wiki/Blood_types_in_Japanese_culture
[08:42:04] <kierank> i can safely say that doesn't match
[08:43:53] <KotH> there are about a dozen girls
[08:44:09] <andoma> KotH: you have watched all night?
[08:44:15] <KotH> and yes, they took quite a few fotos :)
[08:44:21] <KotH> andoma: nah..
[08:44:25] <andoma> :)
[08:44:34] <KotH> andoma: i had it open a whole weekend ;)
[08:45:39] <KotH> Dark_Shikari: erhmm... bloodtype is like zodiac signs in european culture
[08:45:54] <KotH> Dark_Shikari: people do ask about it, but nobody really believes...
[08:46:03] <Dark_Shikari> KotH: of course
[08:46:16] <Dark_Shikari> but EVERYTHING has blood types
[08:46:23] <Dark_Shikari> like holy shit they put blood types next to every anime character
[08:46:31] <Dark_Shikari> in america we don't put zodiac signs next to each TV show character
[08:46:46] <Dark_Shikari> (nor in europe)
[08:46:48] <KotH> american fail, then
[08:46:50] <KotH> ;)
[08:47:13] <av500> well, bart simpson is a virgin, no?
[08:48:04] <peloverde_> blood types are fairly common on american TV but not for creepy japanese reasons, we just have too many medical shows
[08:48:39] <KotH> lol
[08:49:09] * KotH thinks that usians are way more creepy than japanese
[08:49:17] <av500> like cell phone reception, matching blood is never there when you need it
[08:49:30] * thresh doesnt even know his blood type
[08:49:52] <KotH> thresh: you'll die a horrible death!
[08:50:21] * av500 has cold blood
[08:50:41] <Dark_Shikari> peloverde_: It's lupus!
[08:51:25] <superdump> lol
[08:51:41] <superdump> necrotising fasciitis
[08:51:56] <superdump> auto-immune disease! :o
[08:56:49] <Dark_Shikari> interesting, that site only lets you access the current image
[08:56:52] <Dark_Shikari> you get 403 on any other image
[08:57:05] <av500> you get a few back
[08:57:54] <Dark_Shikari> ah
[08:58:06] <Dark_Shikari> still, must require some smart rotating http server script
[08:58:48] <av500> there is user timezone to take into account, no?
[08:59:24] <Dark_Shikari> yeah it must do that too
[08:59:29] <Dark_Shikari> or maybe it only allows a few minutes per hour
[08:59:53] <av500> no
[08:59:54] <Dark_Shikari> it could parse the time in the user GET
[09:08:57] <av500> Dark_Shikari: http://forum.archosfans.com/viewtopic.php?p=206352#p206352
[09:09:48] <Dark_Shikari> :)
[09:37:59] <twnqx> interesting blog article, Dark_Shikari
[09:38:22] <twnqx> and interesting comments on it as well
[09:38:41] <Dark_Shikari> superdump: http://bijint.com/jp/pages/iphone/bisei.html
[09:38:43] <Dark_Shikari> they have an iphone app
[09:39:40] <superdump> well i don't particularly want it
[09:39:46] <Dark_Shikari> I know, I'm just pointing it out ;)
[09:39:53] <Dark_Shikari> thought it was funny
[09:39:53] <superdump> i was just wondering what the point of it was
[09:39:55] <superdump> :)
[09:40:16] * av500 wonders why they dont have an anime version....
[09:40:38] <av500> oops: http://bijint.com/jp/pages/iphone/pixiv.html
[09:40:44] <DonDiego> twnqx: what blog post?
[09:40:58] <av500> DonDiego: http://x264dev.multimedia.cx/?p=292
[09:41:03] <twnqx> the one from two days ago
[09:41:32] <av500> twnqx: thats a clear description :)
[09:41:44] <twnqx> you posted the link already :P
[09:41:52] <twnqx> "The best choice will always be a deeply patent-encumbered format until someone gets rid of software patents"
[09:42:14] <Dark_Shikari> aka "screw the US, you guys suck"
[09:42:17] <twnqx> isn't it more like "the best ideas are sadly patended, and other ideas just are too inferior"?
[09:42:26] <Dark_Shikari> no, more like "good ideas will always be patented"
[09:42:35] <twnqx> hm
[09:42:40] <Yuvi> Dark_Shikari: you're included, you haven't moved yet :P
[09:42:53] <Dark_Shikari> Yuvi: self-deprecation is allowed
[09:43:16] <peloverde> If it's a US vs elsewhere thing then why are so many german patents listed in the mpeg-la list?
[09:43:37] <av500> peloverde: h264 cost money in .eu too
[09:43:39] <Dark_Shikari> peloverde: hardware is separate
[09:43:45] <Dark_Shikari> EU prohibits patents on computer programs
[09:43:48] <Dark_Shikari> this does not apply to hardware
[09:43:53] <Dark_Shikari> it also probably doesn't apply to computers distributed with software
[09:44:00] <Dark_Shikari> so for example, VLC should be fine
[09:44:04] <Dark_Shikari> but if I sell a computer with VLC on it, it may not be fine
[09:44:12] <Dark_Shikari> and if I sell an ipod with a hardware decoder, it's definitely not fine
[09:44:22] <Dark_Shikari> but it's much more _reasonable_, because if you sell hardware, you can afford to pay licensing fees
[09:44:25] <av500> ipod with sw decoder is also not fine
[09:44:26] <Dark_Shikari> while software has zero duplication cost
[09:44:40] <Dark_Shikari> and thus it's not reasonable to expect all distributors of software to be able to pay
[09:44:47] <Dark_Shikari> it's still not optimal, but a far better option than what's in the US.
[09:44:54] <av500> and it is not reasonable to go after e.g. vlc
[09:45:15] <Dark_Shikari> mpeg-la are pretty smart.  they don't want to make enemies of open source, it's biting the hand that feeds them
[09:45:40] <av500> right
[09:45:54] <Dark_Shikari> smarter than adobe ;)
[09:50:48] <twnqx> so it would be possible to sell a hardware with a h264 license, but no h264 application installed, and it would still cover any app that a user might want to install?
[09:51:01] <Dark_Shikari> Probably.
[09:51:04] <Dark_Shikari> You'd probably have to ask mpeg-la.
[09:51:17] <twnqx> and fraunhofer et al for mp3, etc >_>
[09:51:45] <twnqx> is alac patented?
[09:52:49] <Dark_Shikari> fraunhofer is much more annoying than mpeg-la
[09:52:53] <Dark_Shikari> same with via licensing and aac
[09:53:18] <av500> dont forget sisvel for mp3, most annoying
[09:54:21] <peloverde> I don't understand why people even bother with mp3 anymore, the format is retarded and the licensing is a mess
[09:54:37] <Dark_Shikari> flash doesn't support vorbis
[09:54:40] <Dark_Shikari> there are no good open source aac encoders
[09:54:44] <Dark_Shikari> libmp3lame is better than libfaac and ffaac
[09:54:49] <av500> peloverde: ???
[09:54:58] <Dark_Shikari> and aac is no better than mp3 licensing wise
[09:54:59] <peloverde> nero is gratis
[09:55:04] <Dark_Shikari> no it isn't!
[09:55:08] <Dark_Shikari> nero is non-commercial only
[09:55:19] <peloverde> They will sell you a commercial license
[09:55:26] <Dark_Shikari> In theory
[09:55:35] <Dark_Shikari> but a lot of people want free software solutions
[09:55:52] <Dark_Shikari> now stop being lazy and work on the aac encoder! :)
[09:56:11] <peloverde> All these people who want free software solutions seem unwilling to pay
[09:57:37] <Dark_Shikari> Well, nobody's paying for x264, and we seem to be doing fine.
[09:58:00] <peloverde> I thought you were pulling down reasonable money to work on x264
[09:58:09] <Dark_Shikari> yes, but not for any quality-related stuff
[09:58:12] <Dark_Shikari> mostly for niche features
[09:58:29] <Dark_Shikari> like low latency, bitrate reconfig, etc
[09:58:36] <av500> most users cannot judge quality anyway...
[09:58:44] <Dark_Shikari> Making x264 Good (TM) came for free.  mostly
[09:58:50] <Dark_Shikari> AQ was paid for, but that's about it
[09:59:02] <Dark_Shikari> AQ came because Avail Media was annoyed at grass in football games looking awful
[09:59:13] <av500> --nice-grass
[10:00:04] <Dark_Shikari> and it's not really as much money as I'd like anyways :/
[10:00:54] <Dark_Shikari> seriously though, you can't get money by doing nothing and promising work when the money comes
[10:01:32] <peloverde> yes but i'm getting money for decoding
[10:01:39] <peloverde> so why bother with the encoder
[10:02:32] <Dark_Shikari> because this is free software.  money is the icing, not the cake.
[10:03:39] <peloverde> Says the man working for corecodec and selling non-free licenses to is program
[10:03:53] <Dark_Shikari> working for them?  I wrote asm for them over a summer
[10:03:55] <Dark_Shikari> that was about it
[10:04:00] <Dark_Shikari> and I said THIS is free software
[10:04:03] <Dark_Shikari> coreavc is not free software
[10:04:06] <Dark_Shikari> therefore, the same rules don't apply
[10:04:27] <Dark_Shikari> working on free software doesn't preclude working on other things too.
[10:06:35] <Dark_Shikari> but when you're working on free software, sitting around whining and refusing to work on X because nobody will give you money is simply stupid.
[10:07:07] <pross-au> Q: to support seeking in bink, i need to know the audio PTS of the frame being seeked to. the only way to caclulate the PTS, is to process first 4 bytes of each prior frame. This involves a lot of seeking, especially for big files. Any ideas how i can implement this neatly?
[10:07:07] <Dark_Shikari> it's fine to admit that X isn't your thing, and that you're not interested.  But in that case we better find someone else to do it.
[10:07:33] <Dark_Shikari> pross-au: well, good thing bink files aren't usually very long...
[10:08:03] <peloverde> If somebody wants to work on the AAC encoder, they are more than welcome to
[10:08:04] <pross-au> Dark_Shikari: the diablo cutscenes are huge man
[10:08:09] <Dark_Shikari> they're like 5 minutes
[10:08:41] <pross-au> 7!
[10:08:47] <Dark_Shikari> lol
[10:08:54] <Dark_Shikari> and they're like, sub-SD
[10:09:13] <pross-au> But Patent Free
[10:09:20] <av500> Dark_Shikari: but one day utube will switch to bink-HD, we better be prepared
[10:09:51] <pross-au> Quality, Patent-Encumbered or Fast. Pick two.
[10:10:07] <Dark_Shikari> you mean patent-free
[10:10:12] <Dark_Shikari> you mixed that one up.
[10:10:24] <av500> pross-au: I pick Quality and Fast :)
[10:10:31] <Dark_Shikari> lol
[10:10:35] <pross-au> Dark_Shikari: arh crap
[10:10:42] <pross-au> You know what i mean
[10:10:44] <Dark_Shikari> I don't think that works well either
[10:10:49] <Dark_Shikari> what's patent-free, quality, but not fast?
[10:10:52] <Dark_Shikari> certainly not dirac
[10:10:57] <av500> raw YUV
[10:10:57] <Dark_Shikari> that's patent-free, not quality, not fast
[10:11:01] <Dark_Shikari> lol
[10:11:08] <Dark_Shikari> But raw YUV is fast.
[10:11:21] <merbzt1> quality is awesome
[10:11:45] <av500> merbzt1: some of it could use a blocking filter though
[10:12:08] <av500> inb4 xkcd
[10:35:22] <pross-au> Seeking in bink videos looks ugly
[10:36:07] <Dark_Shikari> they do have keyframes though right?
[10:44:57] * Kovensky wonders about flac seeking
[10:45:12] <elenril> Kovensky: patches welcome ;)
[10:45:30] <Kovensky> :P
[10:45:48] <av500> flac cannot seek?
[10:45:51] * elenril wonders how to handle -ss when copying chapters
[10:45:54] <elenril> av500: no
[10:45:55] <Kovensky> I already spent like 2 hours yesterday adding TTA support to mplayer's mkv demuxer, and that was with libavformat copypasta
[10:45:58] <Kovensky> lol
[10:46:00] <Kovensky> av500: no, it can't seek OR tell
[10:46:24] <elenril> Justin said it was on his todo list
[10:46:38] <av500> hmm, it seeks here nicely
[10:46:52] <Kovensky> * elenril wonders how to handle -ss when copying chapters <-- the same way mkvmerge does: shift chapters
[10:46:58] <Kovensky> av500: mplayer? try -demuxer lavf :)
[10:47:10] <av500> Kovensky: no, my own player/demuxer
[10:47:25] <Kovensky> o
[10:47:28] <elenril> Kovensky: well obviously
[10:47:52] <elenril> but ffmpeg just parses -ss argument when handling -i and then throws it away
[10:48:22] <elenril> so this will require some :effort:
[10:48:43] <elenril> or a brain, but those are hard to get lately
[10:52:13] <pross-au> Dark_Shikari: yeah it has them, but kshishkov is part of 'equality for frame-types' movement.
[10:52:21] <pross-au> so all frames are treated as KEY
[10:52:58] * elenril always thought kshishkov was evil
[10:55:13] * av500 thought no key frames at all was the new rage these days...
[10:56:54] <elenril> only for 1337 formats liek x264
[10:57:09] <CIA-92> ffmpeg: cehoyos * r22020 /trunk/ (libavformat/mpegtsenc.c tests/ref/lavf/ts):
[10:57:09] <CIA-92> ffmpeg: Correctly increment continuity_counter in PCR packets.
[10:57:09] <CIA-92> ffmpeg: Patch by Yann Coupin, yann.coupin+ffmpeg gmail
[11:02:12] <Kovensky> elenril: you forgot the .
[11:02:40] <elenril> lol
[11:04:12] * elenril lols at http://kovensky.project357.com/stats/ffmpeg-devel.html
[11:04:45] <kshishkov> pross-au: you have LSB in seektable offsets to tell you whether that's keyframe or not
[11:04:49] <elenril> most used words: michael
[11:06:11] <pross-au> I am yet to find a sample file that has LSB set
[11:06:26] <kshishkov> there is - for the first frame
[11:06:31] <pross-au> Yeah
[11:07:21] <pross-au> seeking is a pain kshishkov, because we need to calculate audio pts (and that involves seeking)
[11:07:32] <av500> Kovensky: you have to ignore "_" when making the stats
[11:07:33] <kshishkov> the rest is obviously treatead as P-frames
[11:07:45] <Dark_Shikari> lol bink
[11:07:55] <kshishkov> pross-au: what about quick and dirty approximation as frame number * constant ?
[11:07:59] <Kovensky> av500: lol
[11:08:07] <Kovensky> av500: pisg is p. dumb :/
[11:08:13] <pross-au> That trick cross my mind kshishkov
[11:11:33] <kshishkov> at least for video you have to decode whole frame to tell whether it's real P-frame or not, so seeking may be not worth bothering
[11:12:52] <pross-au> So the LSB 'keyframe' flag does not always mary up with the Bink Video content
[11:13:07] <kshishkov> it is
[11:13:23] <pross-au> that's an incomplete sentence kshishkov
[11:13:38] <kshishkov> it is not :)
[11:13:45] <pross-au> it does not!
[11:14:01] <kshishkov> your time is over
[11:14:08] <pross-au> True
[11:14:33] <kshishkov> another 5 minutes cost ten quid
[11:14:51] <pross-au> i dont think seeking to an 'estimated by constant' audio pts is going to work
[11:15:07] <kshishkov> true, some frames lack audio
[11:15:12] <pross-au> the audio is not distributed evenly across the file. audio gets lumped at the beginning
[11:15:32] <pross-au> of course, we will fix that with the FFmpeg Bink A/V encoder right?
[11:16:27] <kshishkov> right
[11:16:33] <kshishkov> draft Dark_Shikari
[11:18:04] <kshishkov> I think that simply seeking to the beginning in Bink files should be enough
[11:19:19] <pross-au> kshishkov: ok
[11:25:42] <kshishkov> I'm uploading BIKb sample with sound for you
[11:26:04] <kshishkov> it does not play audio well either
[11:28:52] <kshishkov> pross-au: incoming/bink/NWCLOGO.BIK
[11:29:50] <J_Darnley> elenril: was the email not clear enough?
[11:30:50] <pross-au> Oh cool
[11:31:25] <CIA-92> ffmpeg: pross * r22021 /trunk/libavformat/bink.c: set AVINDEX_KEYFRAME correctly for bink
[11:33:17] <pross-au> kshishkov: which game?
[11:33:28] <kshishkov> silly question
[11:33:55] <kshishkov> the same for which you have that demo with BIKb files
[11:34:07] <pross-au> searching 'NWCLOGO.BIK' via Bing.com yields nothing
[11:34:10] <kshishkov> (how many games by New World Computing you know anyway?)
[11:34:21] <pross-au> Zero
[11:34:24] <pross-au> Haha
[11:34:25] <kshishkov> search at Bink.com
[11:35:25] <kshishkov> it was in single video archive along with other Binks and Smackers
[11:35:29] <pross-au> in your expedition, did you find any other bink versions?
[11:35:45] <kshishkov> not much
[11:35:54] <kshishkov> all seems to play fine
[11:36:07] <pross-au> No 'a'
[11:36:09] <kshishkov> though there is one BIKh sample with minor artifacts
[11:36:15] <kshishkov> not at all
[11:37:17] <kshishkov> theoretically if someone could sort that list of games using Bink by year...
[11:39:51] <Dark_Shikari> that would be a long list
[11:40:05] <pross-au> its published on their website Dark_Shikari
[11:40:30] <pross-au> one would need to scrape it, and then run some queries on mobygames
[11:43:56] <byteme`> hmm
[11:44:21] <CIA-92> ffmpeg: pross * r22022 /trunk/libavformat/bink.c: low-complexity Bink file seeking
[11:44:58] <kshishkov> < CIA-92> ffmpeg: pross * r22023 /trunk/libavformat/bink.c: HEv1 Bink file seeking
[11:45:39] <pross-au> HEv1?
[11:45:58] <kshishkov> yes, "low-complexity" makes me think of AAC
[11:46:10] <pross-au> we'll i have a complex version working, but its ugly
[11:47:20] <pross-au> it seeks through the file at read_header() time. so... need to write a 'index cache' type thing for it
[11:49:09] <kshishkov> nah, it won't work fine with Bink Streaming Server
[11:51:48] <pross-au> Bwahaha
[11:52:34] <CIA-92> ffmpeg: pross * r22023 /trunk/libavcodec/mmvideo.c: it is not necessary to display the decoder name, as av_log() automatically prints the context
[11:53:16] <pross-au> ^^^^ there's about 100 instances like this through libavcodec
[11:53:27] <kshishkov> mostly for old codecs
[11:53:38] <pross-au> correct
[11:53:51] <pross-au> 'classics'
[11:53:55] <kshishkov> someone should update them a bit
[11:54:21] <pross-au> Update? How?
[11:54:23] <kshishkov> do you consider Mike as a living classic since many of those are his creation?
[11:55:10] <kshishkov> update = use new features like bytestream, rewrite messages, throw out useless checks, whatever
[11:58:08] <pross-au> It will happen when the supply of interesting new codecs drys up.
[11:58:23] <kshishkov> heh
[11:58:47] <pross-au> Think peak oil :D
[11:58:51] <pross-au> Peak Codec :D
[12:00:26] <merbzt1> :)
[12:00:40] <merbzt1> I think we have reached it
[12:01:08] <merbzt1> what interesting stuff is left ?
[12:01:18] <kshishkov> Windows Media stuff
[12:01:20] <merbzt1> wmalossless, indeo4
[12:01:22] <kshishkov> voice codecs
[12:01:29] <byteme`> voip codecs?
[12:01:29] <merbzt1> g72*
[12:01:31] <kshishkov> screen codecs
[12:01:34] <pross-au> Bink is comparable to the oil underneath an antarctica. Its a long way to go, for very little...
[12:01:59] <kshishkov> pross-au: then BIKb is an oil on Mars
[12:02:13] <pross-au> Indeed
[12:02:35] <byteme`> g729 would be nice but it's heavily patented
[12:03:18] <av500> so?
[12:03:29] <Compn> there are still a bunch of codecs to go :)
[12:03:32] <kshishkov> some people may want Apple Indermediate and ProRes codecs
[12:03:44] <Compn> we havent run out yet
[12:03:50] <pross-au> Compn <- Climate Change Skeptic
[12:03:53] <kshishkov> too bad
[12:04:05] <byteme`> av500: doesn't that present an issue?  ( I'm really new to media formats when it comes to legal licensing issues )
[12:04:25] <merbzt1> byteme`: for us it doesn't matter
[12:04:34] <kshishkov> byteme`: our position on patents in expressed in your nickname
[12:04:40] <byteme`> haha
[12:04:45] <byteme`> cool :)
[12:07:54] <av500> byteme`: it is not illegal to write source code for patented stuff
[12:08:53] <byteme`> good to know. I really need to read up more on licensing before I speak about it again :)
[12:10:35] <byteme`> av500: so lets just say I was a genius and implemented a G729 encoder from the patent spec... would some US company try and sue me for submitting an encoder patch to the ffmpeg devel mailing list?
[12:10:51] <kshishkov> no
[12:11:04] <byteme`> ok
[12:14:57] <Dark_Shikari> byteme`: patents apply to use
[12:15:01] <Dark_Shikari> not to writing code
[12:15:07] <Dark_Shikari> code is a description of an implementation, not an implementation
[12:15:19] <kshishkov> especially when there's standard
[12:15:24] <Dark_Shikari> of course
[12:15:28] <Dark_Shikari> since the standard itself is basically code
[12:15:59] <Dark_Shikari> if a company uses a G729 encoder in ffmpeg, they may (depending on the country) need to pay license fees
[12:16:02] <Dark_Shikari> but it's their responsibility, not ours
[12:16:23] <Dark_Shikari> no open source project in history has ever gotten a patent lawsuit, AFAIK.
[12:17:03] <Dark_Shikari> there's been dmca stuff and similar (e.g. threats over rtmpdump), but patent lawsuits are always aimed at users (primarily companies), if at all.
[12:17:22] <byteme`> that is good to know :)
[12:17:26] <Dark_Shikari> users/distributors
[12:17:46] <Dark_Shikari> ffmpeg policy is basically "we don't give a fuck about patents, the US is a crappy country anyways"
[12:18:01] <byteme`> haha
[12:18:18] <byteme`> yeah I don't like how there are 20 million lawyers these days
[12:18:37] <byteme`> I read an article that says you have a 1 and 4 chance of getting sued in your lifetime
[12:18:45] <byteme`> if you live in the US
[12:19:34] <byteme`> that statistic increases if you start a business by another 10-15% according to the article.
[12:20:20] <Dark_Shikari> hmm, that sounds a bit high.
[12:20:31] <Dark_Shikari> Like maybe something from a legal office trying to promote themselves ;)
[12:22:56] <byteme`> heh :)
[12:30:59] <av500> byteme`: if you are a foreign country doing business in the us, chances are 500% your will get sued...
[12:31:05] <av500> err, foreign company :)
[12:31:23] <byteme`> I'm a poor US citizen ( college student )
[12:31:33] <av500> byteme`: you are safe (for now)
[12:31:38] <byteme`> heh
[12:31:45] * kshishkov is safer anyway
[12:32:15] <av500> kshishkov is is safe haven
[12:32:19] <av500> is in
[12:32:43] <kshishkov> we have low standards compared to Australia though
[13:12:26] <CIA-92> ffmpeg: kostya * r22024 /trunk/libavcodec/vc1dec.c:
[13:12:26] <CIA-92> ffmpeg: ff_msmpeg4_decode_init() calls ff_h263_decode_init() which calls
[13:12:26] <CIA-92> ffmpeg: MPV_common_init(), so calling both is redundant and leads to memory
[13:12:26] <CIA-92> ffmpeg: leaks in WMV3/VC-1 decoder. Thus use only the first function in
[13:12:26] <CIA-92> ffmpeg: WMV3/VC-1 decoder initialization.
[13:12:46] <beaver> www.search2.net
[13:13:00] <CIA-92> ffmpeg: michael * r22025 /trunk/libavcodec/h264_cabac.c: Replace ad-hoc fill rectangle by fill_rectangle().
[14:23:24] <DonDiego> byteme`: unfortunately people are driven by unreasonable fear when nothing more than a word from a legal context is used against them..
[14:23:46] <DonDiego> are you afraid of holding hands in public? kissing? drinking beer?
[14:24:07] <DonDiego> there *are* places where you can go to prison for any of them...
[14:24:23] <kshishkov> DonDiego: in US for the last thing I heard
[14:25:05] <DonDiego> nobody is kept awake at night in euroope because they drink beer in public
[14:25:13] <DonDiego> even though you cannot do it in the US
[14:25:43] <DonDiego> but when they might infringe a us patent, suddenly they *are* kept awake at night..
[14:25:47] * DonDiego shakes his head
[14:26:14] <kshishkov> DonDiego: because lawyers are US mafia
[14:26:25] <DonDiego> no
[14:26:33] <DonDiego> it's people being irrational
[14:27:19] <Honoome> DonDiego: companies generally have a good reason for that
[14:27:29] <Honoome> (they sell goods/services in the US as well)
[14:27:55] <Honoome> but yeah, it's irrational for private, single people to get upset about US patents while living in a (sorta) more free side of the world
[14:28:04] <Honoome> I say that sorta in context of latest Google's official blog post
[14:28:34] <kshishkov> they have blog?
[14:28:45] <Honoome> kshishkov: they have many blogs
[14:28:50] <KotH> DonDiego: i dont think it's irrational
[14:29:08] <KotH> DonDiego: us companies are known to apply us law in any other country as well
[14:29:10] <Honoome> kshishkov: http://googleblog.blogspot.com/2010/02/serious-threat-to-web-in-italy.html?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+blogspot%2FMKuf+%28Official+Google+Blog%29&utm_content=Google+Reader
[14:29:19] <KotH> DonDiego: or you get sued in the us
[14:29:24] <KotH> DonDiego: just think of CERN
[14:29:41] <Honoome> KotH: that applies to companies and not individuals though, doesn't it?
[14:29:50] <KotH> Honoome: think of decss
[14:29:58] <DonDiego> KotH: nonsense
[14:30:09] <DonDiego> of course us law applies when you do business in the usa
[14:30:11] <DonDiego> not before
[14:30:21] <kshishkov> think of TPB
[14:30:33] <Honoome> KotH: ah forgot rule number one: don't ever enter american soil
[14:30:40] <mru> KotH: and CERN didn't seem to care much, did they?
[14:30:54] <KotH> mru: actually they do
[14:30:55] <DonDiego> kshishkov: TPB is still running ...
[14:31:05] <KotH> mru: part of their coils are produced at fermilab
[14:31:07] <Honoome> KotH: beside, doesn't decss have to do with DMCA and not patents?
[14:31:09] <DonDiego> what happened with cern?
[14:31:39] <KotH> Honoome: yes, it was a dmca claim, not patent. but it shows that even individuals can get sued
[14:31:56] <Honoome> KotH: different kinds of laws though
[14:32:01] <KotH> DonDiego: they got sued for "endangering the world by willfully producing black holes"
[14:32:08] <Honoome> I think DMCA was classed as a criminal offense (jail sentence) but patents iirc are not
[14:32:52] <kshishkov> KotH: one has to try hard to prove he is a patented idiot...
[14:33:30] <DonDiego> KotH: where did individuals get sued?
[14:34:00] <KotH> DonDiego: as i said, decss
[14:34:10] <KotH> DonDiego: yes, i know the outcome of the whole issue
[14:34:12] <kshishkov> TPB as well
[14:34:28] <KotH> kshishkov: in that field, mininova too
[14:34:28] <DonDiego> but you are getting things wrong
[14:34:40] <DonDiego> dvd jon was sued in their *home* country
[14:34:41] <Honoome> neither applied to patents
[14:34:50] <DonDiego> TPB as well
[14:34:57] <DonDiego> and nothing to do with patents, yes
[14:35:02] <DonDiego> and this is the problem
[14:35:04] <DonDiego> people
[14:35:11] <DonDiego> *please* try to get a clue
[14:35:20] <KotH> DonDiego: nope, the first trial was in the us
[14:35:26] <kshishkov> Salem?
[14:35:31] <DonDiego> patents != copyright != trademarks
[14:35:31] <KotH> DonDiego: the second and third was in .nl
[14:35:42] <DonDiego> KotH: what trial
[14:35:51] <KotH> DonDiego: on decss
[14:36:07] <DonDiego> it's not constructive to start talking about decss or TPB when the topic are patents
[14:36:16] <KotH> DonDiego: i might not have a clue on legal stuff, but i follow what's happening in the world
[14:36:16] <DonDiego> it only leads to one thing: more confusion
[14:36:32] <DonDiego> you must differentiate between these issues
[14:36:38] <KotH> DonDiego: i know that most of it is just hot air, but that does not mean that people do not have a reason to fear us companies
[14:36:47] <DonDiego> fsk
[14:36:50] <DonDiego> fsck
[14:36:57] * KotH checks DonDiegos harddisks
[14:37:00] <DonDiego> stop spreading FUD already
[14:37:46] <kshishkov> KotH: actually patents unlike copyright are local, i.e. valid only in one country. You can do what you want outside it and won't get sued.
[14:37:50] * KotH spreads chocolate instead
[14:37:59] <KotH> kshishkov: not true
[14:38:00] <DonDiego> *local* laws is what you have to take into account
[14:38:07] <KotH> kshishkov: there are a lot of countries with patent treaties
[14:38:29] <kshishkov> KotH: still that requires patent issued there
[14:38:31] <KotH> kshishkov: ie, if you get sued over a patent in country A, that has effects in country B too
[14:38:38] <DonDiego> that makes them *local* patents
[14:38:41] <mru> I'll enforce yours if you enforce mine?
[14:38:48] <KotH> mru: juup
[14:38:49] <DonDiego> so repeat after me please:
[14:39:02] <DonDiego> *local* laws is what you have to take into account
[14:39:04] <KotH> mru: and all of your patents are valid here too
[14:39:15] <KotH> *local* laws is what you have to take into account
[14:39:23] <KotH> DonDiego: happy? ;)
[14:39:41] <DonDiego> you get *stoned* for extramarital affairs in iran
[14:39:44] <mru> there's only one letter difference between law and flaw...
[14:39:46] <KotH> DonDiego: you know where i stand regarding patent and similar issues
[14:39:47] <kshishkov> no go study Paris Convention
[14:40:00] <kshishkov> mru: in practice there's even less difference
[14:40:07] <DonDiego> so do people in, e.g. france, fear for their lives when they have an affair? - no
[14:40:20] <mru> they fear their wives though
[14:40:29] <mru> well, not in france actually
[14:40:30] <kshishkov> *local* laws is what you have to take into account :)
[14:40:48] <DonDiego> neither should somebody in, say, japan, fear that they might get sued for dmca infringement
[14:40:59] <DonDiego> when they circumvent decss
[14:41:07] <DonDiego> dmca is a US law, does not apply in japan
[14:41:08] <KotH> DonDiego: actually, you do
[14:41:16] <DonDiego> NOOOOOOOOOOOOOOOO
[14:41:21] <KotH> DonDiego: .jp has a treaty on dmca with the us :)
[14:41:43] <DonDiego> but then it becomes a LLLLLLLLOOOOOOOOOCCCCCCCCAAAAAAAAALLLLLLLL  law !!!!!!!!!!!!
[14:41:49] <KotH> yeah
[14:41:50] <DonDiego> is that so hard to understand
[14:42:07] <DonDiego> i'm harping about this because
[14:42:09] <kshishkov> until ACTA comes and it all becomes *global* law
[14:42:29] <DonDiego> people really do fear non-local laws that do not apply to them
[14:42:38] <kshishkov> not here
[14:42:42] <DonDiego> and they believe the FUD
[14:42:48] <KotH> DonDiego: i do not fear the law
[14:42:54] <DonDiego> and they stop living as free people
[14:42:55] <KotH> DonDiego: i do fear a company sueing me
[14:42:59] <KotH> DonDiego: that's a big difference
[14:43:14] <DonDiego> a us company? suing you in .ch? for what?
[14:43:18] <KotH> DonDiego: or as the germans put it: recht haben und recht bekommen sind zwei verschiedene dinge
[14:43:22] <kshishkov> for chocolate
[14:43:31] <DonDiego> WTF
[14:43:39] <kshishkov> KotH: they say so in Odessa too. Really
[14:43:41] <KotH> DonDiego: erhm...
[14:43:42] <DonDiego> attila, please don
[14:43:45] <DonDiego> 't be stupid
[14:43:59] <DonDiego> of course a court can make a wrong decision
[14:44:04] <KotH> DonDiego: you know which name will first pop up if someone want to take down ffmpeg or mplayer?
[14:44:10] <DonDiego> but that decision will have to be based on *local* law
[14:44:20] <DonDiego> mine probably
[14:44:22] <DonDiego> :)
[14:44:24] <KotH> DonDiego: yeah sure... and who is going to pay for my lawyer?
[14:44:28] <kshishkov> KotH: reregister everything to Gerard Lantau
[14:44:49] <DonDiego> we have lawyers
[14:45:08] <DonDiego> they are us lawyers, so they can battle the us companies you are afraid of..
[14:45:11] * DonDiego shakes his head
[14:45:15] * KotH notelement we
[14:45:29] <DonDiego> sure you are element of that group
[14:45:49] <DonDiego> if you worry, send them the papers already..
[14:45:51] <KotH> does the fslc handle everything around ffmpeg/mplayer?
[14:45:55] <DonDiego> yes
[14:46:00] <DonDiego> SFLC
[14:46:08] <CIA-92> ffmpeg: ramiro * r22026 /trunk/ffplay.c:
[14:46:08] <CIA-92> ffmpeg: Clear freed pointer in ffplay.c.
[14:46:08] <CIA-92> ffmpeg: Fixes a crash when audio stream is cycled twice.
[14:46:24] <DonDiego> but for some reason they have no reach into china
[14:46:29] <KotH> DonDiego: only if they handle cases in .ch too
[14:46:45] <DonDiego> ask
[14:46:58] <kshishkov> DonDiego: local laws - foreign barbarians has nothing to do in CHina
[14:46:59] <DonDiego> but stop spreading FUD already please
[14:47:11] <DonDiego> worry about *local* laws
[14:47:21] <DonDiego> and tell people to worry about *local* laws
[14:47:23] <KotH> DonDiego: again
[14:47:27] * av500 spreads FUDge
[14:47:33] <DonDiego> this is one of those urban horror stories
[14:47:36] <KotH> DonDiego: you know where i stand in issues around patents and copyright
[14:47:40] <DonDiego> that people keep spreading
[14:48:16] <KotH> DonDiego: and you know what i think about companies trying to demand stuff of ffmpeg/mplayer
[14:48:44] <DonDiego> what i know is that you are spreading FUD here by making unqualified statements, sorry for sounding harsh
[14:49:45] <KotH> hmm..
[14:49:55] <KotH> i guess it's time that we drink some tea together
[14:50:57] <DonDiego> no, seriously, think about it
[14:51:11] <DonDiego> this is driving me mad
[14:51:25] <KotH> dont worry about that, you are quite mad already ;->
[14:52:40] <DonDiego> http://en.wikipedia.org/wiki/Urban_legend
[14:52:57] <DonDiego> seriously, you are contributing to the urban legends of the multimedia hacker space
[14:52:57] <KotH> DonDiego: btw: have you seen/read the new oreilly book on ip in oss?
[14:53:00] <DonDiego> stop it
[14:53:11] <DonDiego> spread clue, not FUD
[14:53:24] <DonDiego> i saw you had it in your hand at fosdem
[14:53:28] * KotH continues to spread chocolate for world peace
[14:53:49] <KotH> i had a quick look at it, 99% us law in it
[14:54:14] <KotH> do you know lawyers specialized in ip stuff from europe?
[14:54:37] <KotH> i'd be interested to put together some text about european regulations on ip in contrast to that book
[14:54:49] <DonDiego> there was one that wrote for german linux magazine
[14:54:59] <KotH> hmm... right
[14:55:50] <DonDiego> people read so much about us law that they end up believing it applies to them
[14:55:57] <DonDiego> witness what just happened here...
[14:56:32] <kshishkov> KotH: wipo.int
[14:56:58] <KotH> kshishkov: the wipo isnt interested in any such text
[14:57:41] <KotH> the wipo is a mostly us controlled organization that tries to enforce us ideas of copyright, unfair use and patents onto the world
[14:57:58] <kshishkov> you forgot trademarks
[14:58:04] <janneg> Till Jaeger from http://www.jbb.de/ has worked for Harald Welte in the gpl-violations cases
[14:58:51] <janneg> http://www.jbb.de/rechtsthemen/open-source/
[14:58:56] <janneg> KotH: ^^^
[15:00:46] * KotH takes notes
[15:01:07] <janneg> KotH: http://www.ifosslr.org/ifosslr might be interested in that text
[15:03:44] <janneg> http://www.fsfeurope.org/ftf is probably helpfull too
[15:05:47] <KotH> hmm.. interesting
[15:05:49] <KotH> danke!
[15:06:38] <janneg> https://lists.gpl-violations.org/mailman/listinfo/legal
[15:06:57] <DonDiego> and now get informed and please stop spreading misinformation, thank you
[15:07:35] <KotH> janneg: i'm not interested in subscribing yet another mailinglist i have no time to read :)
[15:07:53] * KotH reads up on usb and continues spreading chocolate
[15:13:26] <elenril> J_Darnley: no, i don't understand how it interferes with your patch
[15:23:16] <kshishkov> wow, donated NEON code make me feel like _I_ know how write ARM assembly
[15:23:57] <mru> it's not pretty
[15:24:09] <mru> maybe I should just do it properly from scratch instead
[15:24:16] <mru> probably quicker than fixing that stuff
[15:24:38] <mru> it requires massive reformatting too
[15:26:22] * KotH notes, having 67k mails in an imap folder is not very fast
[15:27:07] * av500 59k in his ffmpeg imap folder
[15:27:18] <av500> works for me
[15:27:34] <KotH> yeah.. but it takes ages to build the cache
[15:27:48] <thresh> mutt?
[15:27:51] * KotH wonders why imap isnt compressed already
[15:27:57] <KotH> thresh: i dont like mutt
[15:28:04] <thresh> mutt is notoriously slow with imap, though
[15:28:16] <KotH> nothing is fast with imap
[15:28:55] <thresh> KotH: kmail is pretty much okay
[15:28:57] <mru> 92k mails in my ffmpeg folder
[15:29:09] <thresh> no idea how many messages i've got though, probably some tens of thousands
[15:31:47] <KotH> thresh: it has a k as its first letter -> not ok
[15:32:06] <KotH> and we are talking about ~700k mails
[15:32:07] * thresh suspects KotH doesnt run kernel too
[15:32:13] <thresh> yeah, same here, corporate stuff
[15:32:24] <thresh> ah nevermind, me stupid
[15:32:25] <KotH> thresh: i have a system that is completely gnome and kde free
[15:32:33] <KotH> thresh: and i want it to stay like that
[15:32:50] <thresh> here, have your 100 oils
[15:32:55] <elenril> kde too? what do you use for pdfs?
[15:33:11] <thresh> *cough* xpdf *cough* ?
[15:33:18] * elenril found a good enough replacement for almost everything except okular and okteta
[15:34:07] <mru> xpdf is fine
[15:34:08] <elenril> xpdf fails at ui
[15:34:14] <KotH> the only bloat left on my system are eterm and firefox
[15:34:21] <av500> thresh: kmail as in KDE mail?
[15:34:29] <thresh> yes
[15:34:31] <mru> KotH: eterm? are you mad?
[15:34:33] * elenril throws uzbl at KotH 
[15:34:39] <elenril> and urxvt
[15:34:42] <KotH> mru: you should know that answer :)
[15:34:49] <mru> "yes"
[15:34:52] <av500> o/ JIHAD
[15:35:01] <KotH> \o JIHAD!
[15:35:25] <av500> thresh: then yours must be a magical one
[15:36:53] <thresh> av500: could be. thunderbird was the worst one :S
[15:37:30] * av500 prefers tb over kmail any day
[15:37:42] * KotH learned to hate tb
[15:38:02] * av500 remembers kmail when it used to *block* on reading imap folders...
[15:38:23] <mru> pine ftw
[15:38:38] <av500> not telnet to imap server?
[15:38:51] * mru has done that too on occasion
[15:38:58] <mru> openssl connect, actually
[15:41:41] * mru checks dependencies of chromium
[15:41:54] <Honoome> mru: they are scary scary scary
[15:41:58] <mru> OMFG, dbus _and_ gconf
[15:42:06] <mru> firefox it'll be then
[15:44:46] * elenril thought everything requires dbus these days
[15:45:40] <mru> no, not everything
[15:45:52] <Honoome> elenril: but leave it to ubuntu and everything will require couchdb
[15:46:02] <elenril> lol
[15:46:02] <mru> only the bloated stuff needs it
[15:46:27] <Honoome> now I could see the point for couchdb but…
[15:46:29] <Honoome> HTTP?! really?!
[15:46:58] <mru> the very concept of dbus scares me
[15:48:13] * elenril runs aptitude why dbus
[15:48:56] <elenril> wpasupplicant Depends    libdbus-1-3 o_0
[15:49:29] <thresh> yeah, it has dbus interface to communicate with NM for instance
[15:49:57] * elenril wonders why would anyone want to communicate with nm
[15:52:13] <KotH> dbus' original use (namely communicating hw events to software) was good.. did it quite well actually
[15:52:27] <KotH> but making a full fledged ipc system out of dbus was a big big mistake
[15:52:38] <mru> I don't want my web browser talking to my dhcp client
[15:52:54] <KotH> why not?
[15:53:02] <mru> it has no business doing that
[15:53:05] <KotH> then your webserver would know that you've lost your connectivity
[15:53:12] * elenril doesn't want his webbrowser talking to anything
[15:53:24] * elenril installed tomoyo specifically because of that
[15:53:50] <mru> if connect() works, link is up, otherwise not
[15:53:51] <mru> simple
[15:54:04] <av500> elenril: she keeps you safe? http://images.google.com/images?q=tomoyo
[15:54:36] <elenril> av500: sure she does http://tomoyo.sourceforge.jp/
[15:54:48] <av500> mru: dont you want your compromised webbrowser plugin to talk to your router to open up some ports?
[16:04:20] * Kovensky prefers sakura
[16:05:37] <twnqx> [aac @ 0x684cc0]More than one AAC RDB per ADTS frame is not implemented. Update your FFmpeg version to the newest one from SVN. If the problem still occurs, it means that your file has a
[16:05:37] <twnqx>  feature which has not been implemented.
[16:05:39] <twnqx> :(
[16:10:06] <felipec> is there a way to run fate just once with a git repo I already have? (not pull or anything)
[16:10:47] <mru> if only it used pkgconfig I'm sure that would be trivial
[16:17:02] <CIA-92> ffmpeg: michael * r22027 /trunk/libavcodec/h264_cabac.c:
[16:17:02] <CIA-92> ffmpeg: Replace mvd>2 + mvd>32 by MIN((mvd+28)*17>>9, 2)
[16:17:02] <CIA-92> ffmpeg: same speed as far as i can meassure but it might have fewer branches on some
[16:17:02] <CIA-92> ffmpeg: archs.
[16:17:02] <CIA-92> ffmpeg: Idea from x264 / jason
[16:20:15] <J_Darnley> elenril: it looks wrong to write the same string twice into a file and it looks wrong to say that lavf is the encoder
[16:22:59] <elenril> encoder is just a generic tag name, means muxer for global metadata, encoder for per-stream
[16:23:19] <elenril> (and in many formats it actually is called encoder)
[16:25:09] <elenril> as for writing it twice, i don't see anything really wrong with that
[16:25:57] <elenril> feel free to add an exception for it though
[16:26:21] <elenril> imo it's still better than adding exceptions to at least avi, id3, nut and asf muxers
[16:36:24] <J_Darnley> okay then
[17:42:19] <BBB> elenril, I forgot the patches, any more I should apply?
[17:42:28] <BBB> elenril, and could you comment on the issue raised on cvslog?
[17:43:24] <kshishkov> I think Benoit has applied his yearly quota of patches already
[17:44:40] * elenril slaps kshishkov 
[17:44:52] <elenril> BBB: i already talked with J_Darnley about that
[17:45:55] <kshishkov> elenril: if you'd started earlier you could get write account by now
[17:46:03] <elenril> if you have time, i'd like to have "mention that metadata tags are UTF-8" applied
[17:46:22] <elenril> and patches 01 and 06 from " asf - read/write metadata as UTF-16"
[17:46:41] <elenril> kshishkov: earlier?
[17:46:53] <kshishkov> yep, several years ago
[17:47:12] * elenril was a n00b several years ago
[17:47:23] <elenril> used windoze even
[17:47:26] * kshishkov started in 2004 and got account in 2006 (after ~1.5 years)
[17:48:16] * elenril can live without an account just fine as long as his patches get applied
[17:53:19] * Honoome wonders where Baptiste is
[17:53:35] <kshishkov> USA probably
[17:53:58] <Honoome> kshishkov: more where did he disappear to as I'm waiting for you to be sure not to get Michael's rebus wrong
[17:54:02] <Honoome> but on this note, I'll go fetch my coffee
[17:54:57] * Kovensky goes fetch coffee too
[17:55:59] <kshishkov> Kovensky: local or good one?
[17:57:26] <Kovensky> whatever's on the kitchen ._.
[17:57:32] <Kovensky> but it seems that we ran out of coffee
[17:57:50] <kshishkov> who has ever heard of Brazilian coffee anyway?
[17:58:09] <BBB> elenril, forward me the relevant msg with attachment, or some way to identify the message in my inbox
[17:58:21] <BBB> elenril, lots of msgs/patches, not much time :)
[17:58:37] <kshishkov> BBB: "silence elenril about this patch" should fit them all
[17:59:34] <elenril> BBB: http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/2010-February/083705.html
[18:00:00] <elenril> patches 01 and 06 from http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/2010-February/083703.html
[18:02:18] <BBB> applied that first one
[18:02:35] <CIA-92> ffmpeg: rbultje * r22028 /trunk/libavformat/avformat.h:
[18:02:35] <CIA-92> ffmpeg: Mention that metadata tags are (unvalidated) UTF-8.
[18:02:35] <CIA-92> ffmpeg: Patch by Anton Khirnov <wyskas gmail com>.
[18:05:06] <BBB> they are attached as 6-1
[18:05:10] <BBB> should I apply 1-6 or 6-1?
[18:05:16] <BBB> i.e. what order?
[18:06:54] <CIA-92> ffmpeg: michael * r22029 /trunk/libavcodec/h264_cabac.c:
[18:06:54] <CIA-92> ffmpeg: Factorize common code from the top of decode_cabac_mb_mvd()
[18:06:54] <CIA-92> ffmpeg: 10-15 cpu cycles faster.
[18:07:39] <Kovensky> <@kshishkov> who has ever heard of Brazilian coffee anyway? <-- there's some propaganda here that says that brazilian coffee is the best or one of the best in the world, but that everything goes to exports and we drink shitty (insert random other south american country) coffee
[18:09:19] <CIA-92> ffmpeg: rbultje * r22030 /trunk/libavutil/common.h:
[18:09:19] <CIA-92> ffmpeg: Add PUT_UTF16() macro.
[18:09:19] <CIA-92> ffmpeg: Patch by Anton Khirnov <wyskas gmail com>.
[18:10:37] <CIA-92> ffmpeg: rbultje * r22031 /trunk/libavformat/asfenc.c:
[18:10:37] <CIA-92> ffmpeg: Eliminate put_str16().
[18:10:37] <CIA-92> ffmpeg: Patch by Anton Khirnov <wyskas gmail com>.
[18:10:57] <elenril> BBB: 1 and 6
[18:11:13] <elenril> i'm not yet sure if the other are oked :)
[18:11:17] <BBB> elenril, are you SURE that patch 3 doesn't break the demuxer?
[18:11:23] <troy_s> Yuvi: Are my eyes deceiving me or did the 16-235 non stretch get pushed to main?
[18:11:24] <BBB> oh! I just started applying them
[18:11:25] <BBB> dude
[18:11:35] <BBB> be clearer :)
[18:11:53] <elenril> sorry
[18:12:05] <elenril> it's probably ok though
[18:12:30] <kshishkov> Kovensky: Colombian coffee seems to be better. Not that I drink any.
[18:13:14] <elenril> BBB: 0003-asf-don-t-add-WM-prefix-to-all-tags.patch
[18:13:17] <elenril> this one?
[18:13:25] <elenril> why should it break the demuxer?
[18:13:36] <BBB> because the demuxer uses that metadata conv table also
[18:14:03] <BBB> michael ok'ed it
[18:14:09] <BBB> I'm just asking because I'm too lazy to check
[18:14:23] <BBB> and honestly, one thread per patch is better
[18:14:34] <BBB> don't do this again, I can barely keep up with this...
[18:14:50] <elenril> most of these don't make any sense by themselves
[18:17:37] <BBB> 1-3 applied
[18:17:38] <BBB> anything else?
[18:17:38] <CIA-92> ffmpeg: michael * r22032 /trunk/libavcodec/h264_cabac.c: switch back to (amvd>2)+(amvd>32), its 5 cpu cycles faster now.
[18:17:40] <BBB> 6?
[18:17:43] <elenril> yes
[18:18:08] <BBB> 4 and 5?
[18:18:10] <BBB> no?
[18:18:24] <CIA-92> ffmpeg: rbultje * r22033 /trunk/libavformat/ (asf.c asfenc.c):
[18:18:24] <CIA-92> ffmpeg: Don't add WM prefixes to all written ASF tags.
[18:18:24] <CIA-92> ffmpeg: Patch by Anton Khirnov <wyskas gmail com>.
[18:18:29] <elenril> no, don't apply them yet
[18:18:30] <kshishkov> not approved maybe
[18:18:58] <kshishkov> elenril: I've always wanted to ask why your nickname sounds like certain cat food brand
[18:19:56] <BBB> ok done
[18:20:16] <elenril> kshishkov: i want to know that too
[18:20:52] <CIA-92> ffmpeg: rbultje * r22034 /trunk/libavformat/asfdec.c:
[18:20:52] <CIA-92> ffmpeg: Read ASF metadata as proper UTF-16 and spit it out as proper UTF-8 in our
[18:20:52] <CIA-92> ffmpeg: metadata system.
[18:20:52] <CIA-92> ffmpeg: Patch by Anton Khirnov <wyskas gmail com>.
[18:20:59] <elenril> but there are ThingsManWasNotMeantToKnow
[18:21:01] <elenril> BBB: thanks
[18:21:43] <kshishkov> elenril: good explanation. I'll file it into HilariousInHindsight category
[18:22:21] <BBB> all applied except 4/5
[18:22:28] <BBB> please start a new thread
[18:22:31] <BBB> I'm confused
[18:23:01] * BBB goes for lunch
[18:31:50] * kshishkov notes a good slogan "Confused? Go for lunch!"
[18:35:11] * elenril goes for dinner
[18:50:50] <CIA-92> ffmpeg: michael * r22035 /trunk/libavcodec/h264_cabac.c:
[18:50:50] <CIA-92> ffmpeg: Calculate mvd without abs()
[18:50:50] <CIA-92> ffmpeg: same speed (ask gcc why, i dont know)
[18:52:16] <kshishkov> oh gcc, why?
[18:55:42] <Dark_Shikari> that's _good_
[18:55:48] <Dark_Shikari> it means gcc did it well the first time ;)
[18:56:07] <kshishkov> it's quantum fluctuation
[19:21:53] <BBB> so that doesn't worek
[19:22:42] <BBB> oops
[19:23:05] * BBB hates it when stuff is behind other windows but in focus
[19:23:23] * elenril <3 sloppy focus
[19:23:49] <_av500_> focus follow mouse, no?
[19:24:22] <_av500_> elenril: asfdec reads the ID3/TXXX tags?
[19:24:37] <kshishkov> _av500_: yes, into mousehole as well
[19:24:52] <elenril> av500: yes, except windows retain focus when mouse is over desktop
[19:25:07] <elenril> av500: no, it doesn't
[19:25:16] <BBB> _av500_, you're confused x 5
[19:25:18] <elenril> give me specs and samples and i might implement it
[19:25:28] <_av500_> specs is easy
[19:25:33] <BBB> _av500_, no linux here, also I barely use my mouse, and I switch virtual desktops like 10x per minute
[19:25:58] <Dark_Shikari> get a bigger monitor
[19:26:00] <kshishkov> fingers stuck on Alt and Tab?
[19:26:05] <_av500_> elenril: use ID3/TPE1 as if it were WM/Artist
[19:26:18] <_av500_> but sample I only have your broken one
[19:26:29] <BBB> Dark_Shikari, laptop
[19:26:35] <BBB> kshishkov, yes
[19:27:16] <BBB> actually
[19:27:22] * elenril has a big monitor and 10 virtual desktops
[19:27:22] <BBB> I'm getting a new laptop in ~3 months
[19:27:30] <BBB> should I go for a 17" or 15"?
[19:27:33] <_av500_> why 3?
[19:27:35] <elenril> _av500_: err why do you need it if you have no samples
[19:27:36] <BBB> I'm wondering if 17" is like overkilling it
[19:27:54] <kshishkov> no
[19:27:57] <mru> for a laptop anything about 13" is too big
[19:28:07] <_av500_> 3pounds ftw
[19:28:10] <BBB> nah, I work on it all day
[19:28:12] <BBB> need bigger
[19:28:18] <kshishkov> 30" tablet please
[19:28:30] <mru> BBB: then you need a desktop
[19:28:37] * mru has 2x24" on desk
[19:28:39] <_av500_> kshishkov: you use that in .ua public transport please :)
[19:29:07] <kshishkov> _av500_: you use .ua public transport please
[19:29:55] <_av500_> not without my 30" tablet to defend myself
[19:30:26] <ohsix> just in glass a 30" tablet would weigh a ton
[19:31:07] <_av500_> for small values of ton
[19:31:54] <ohsix> 1 30" standard glass weight plus mechanics ton
[19:32:37] <kshishkov> mechanics?
[19:33:04] <ohsix> 3m and stuff has some pretty magical glass, but over a certain size  you just have to make it thicker or its own lack of rigidity will imperil it
[19:33:09] <kshishkov> cogwheels and levers?
[19:33:34] <ohsix> and steam whistles
[19:33:44] <_av500_> kshishkov: it needs a fruit crate around the glass
[19:34:59] <kshishkov> ecodesign?
[19:35:16] <_av500_> cupertino design
[20:25:41] <BBB> mru, not portable enough
[20:25:56] <BBB> mru, you forget that I work at university most of the day, and at home in the weekend
[20:25:59] <BBB> don't want 2 computers
[20:26:02] <BBB> or come into uni weekends
[20:26:04] <BBB> so laptop
[20:26:18] <mru> but you _need_ 2 computers
[20:26:34] * byteme` has 2x24" as well
[20:26:44] <ohsix> i ended up with a 15" i'd thought would be too small/low res; but i use it nearly 24/7 now
[20:26:49] <mru> byteme`: do you have 6 virtual desktops on each too?
[20:26:56] <byteme`> yes
[20:26:58] <byteme`> I use fluxbox
[20:27:09] <mru> xinerama or separate?
[20:27:16] <byteme`> xinerama
[20:27:23] <mru> separate here
[20:27:27] <byteme`> had to play with the nvidia drivers a bit
[20:27:27] <mru> it's fantastic
[20:27:42] <ohsix> my desktop has a 2048x1152 cute lcd <3 its almost threatening after using the laptop for a while
[20:27:51] <mru> it's a bit annoying that firefox refuses to run on both screens
[20:28:22] * mru has a 2048x1152 too
[20:28:25] <ohsix> do you use dmx or anything with the separate servers?
[20:28:28] <byteme`> I'm basically at 3840x1200
[20:28:40] <mru> single server
[20:28:42] <BBB> mru, why 2 computers?
[20:28:44] <mru> multiple screens
[20:28:47] <BBB> to work on 2 a the same time?
[20:28:50] <BBB> then get 2 laptops
[20:29:04] <byteme`> I may add a 3rd screen for a mac
[20:29:07] <mru> BBB: laptop for portable needs and desktop for real computing
[20:29:08] <byteme`> 3rd 24"
[20:29:09] <ohsix> oh, ic
[20:29:15] <BBB> mru, maybe, used to have it
[20:29:21] <BBB> mru, but manhattan apts are small
[20:29:25] <BBB> mru: so no, not for now
[20:29:27] <ohsix> those samsung panels rule btw :O
[20:29:36] <_av500_> BBB: get small laptop then
[20:29:47] <BBB> big laptop is still small
[20:29:51] <byteme`> <-- Dell 2407 LCD
[20:29:56] <byteme`> they are cheap now
[20:30:16] <_av500_> BBB: but desktop can render BBB while you are away :)
[20:30:39] <ohsix> byteme`: heh, only because you cant really buy the one that was worth ownning anymore :O though last i looked they still had a -HC version
[20:30:39] <BBB> like I said, no space
[20:30:53] <BBB> manhattan apts are too expensive to waste space on a big fat desktop computer
[20:31:05] <byteme`> ohsix: I got mine from ebay
[20:31:56] <ohsix> you could always waste some space on an external monitor and play up portability for a smaller form factor
[20:32:35] <ohsix> my 15" has a keypad and everything, i <3 its cheapness
[20:34:08] <Kovensky> http://www.boingboing.net/2010/02/24/ip-alliance-says-tha.html <-- /facepalm
[20:35:21] <elenril> lawl
[20:35:33] <ohsix> well they have a point with all the red baiting going around
[20:35:51] <ohsix> at least one nutters will take at face value ;]
[20:36:31] <byteme`> for a laptop I have the Dell 1569 studio
[20:37:41] <Kovensky> http://www.economist.com/business-finance/displaystory.cfm?story_id=15570585
[20:38:48] <CIA-92> ffmpeg: michael * r22036 /trunk/libavcodec/rectangle.h: Extend fill_rectangle() support for 16bit
[20:39:31] <CIA-92> ffmpeg: michael * r22037 /trunk/libavutil/intreadwrite.h: AV_COPY16() & AV_ZERO16()
[20:40:58] <Dark_Shikari> hmm, michael must be doing something interesting ;)
[20:41:03] * Dark_Shikari guesses mvd-related
[20:43:43] <j-b> did anyone worked on VP6 interlaced?
[20:43:59] <CIA-92> ffmpeg: michael * r22038 /trunk/libavcodec/ (h264.c h264.h h264_cabac.c):
[20:43:59] <CIA-92> ffmpeg: Change mvd_cache & mvd_table to 8bit, this is overall a bit faster
[20:43:59] <CIA-92> ffmpeg: for high resolution videos.
[20:43:59] <CIA-92> ffmpeg: about 20cycles faster per MB for cathederal.
[20:44:34] <Kovensky> http://m.news.com/2166-12_3-10458570-71.html <-- /facepalm2
[20:44:47] <Kovensky> * Dark_Shikari guesses mvd-related <-- how did you know D:
[20:51:07] <BBB> j-b: no that I've heard of
[20:51:13] <BBB> I thought vp8 was the new shit anyway
[20:52:07] <j-b> BBB: ok, that is what I thought.
[20:53:00] <j-b> I just had a sample in my incoming
[20:53:46] <elenril> w00tness, mkvenc writes AV_NOPTS as duration
[20:54:15] <BBB> that's pretty cool
[20:54:23] <BBB> ffmpeg-specific feature!!!
[20:54:25] <elenril> isn't it
[20:54:37] <BBB> I bet that only ffmpeg can decode that duration correctly
[20:54:56] * elenril doesn't know about that
[20:55:07] <elenril> i don't want to run ffplay as it can crash X
[20:55:12] <elenril> mplayer doesn't play it
[20:55:15] <BBB> lol :)
[21:01:10] <Kovensky> http://blogs.gnome.org/seth/2010/02/23/i-did-the-worst-design-of-my-life-within-gnome/
[21:01:32] <mru> gnome is the worst "design" in many people's lives
[21:06:43] <elenril> anyone knows where is duration set?
[21:09:35] <elenril> nvm, i think i got it
[21:10:22] <ohsix> heh @ the icon thing; it always sort of bothered me the way they'd stream in when you opened a menu; and it used too change the menu width too
[21:12:52] <mru> does michael have a 64-bit machine?
[21:13:21] <ohsix> he has babbages machine
[21:13:31] <mru> 'cause he just broke all 32-bit builds
[21:13:44] <elenril> w00t!
[21:13:52] <mru> fate is crying
[21:14:19] <_av500_> isnt 32bit really 90s...
[21:15:54] <BBB> Kovensky, seth is a hero in many ways, although I often disagree with him
[21:16:04] <BBB> but seth did design most of gnome2's UI stuff
[21:16:07] <BBB> he really is quite good
[21:16:12] <Dark_Shikari> Kovensky: psychic powers
[21:16:28] <Kovensky> Dark_Shikari: oh you
[21:16:31] <Kovensky> BBB: heh
[21:23:25] <ohsix> i dont much mind if something like the icon thing happens as long as its evident the turnover is high; the higher it is the better the chance they have at doing novel things instead of dum things
[21:23:47] <_av500_> what is the icon thing? gnome has icons now?
[21:23:51] <ohsix> i'm biased though, i did hate the flow in width changw
[21:24:03] <elenril> Yuvi: you're maintaining matroskaenc, right?
[21:24:22] <Yuvi> elenril: yeah
[21:25:58] <Compn> blah, sbr aac stream http://amber.streamguys.com:4210/
[21:26:01] <Compn> but it plays ok
[21:26:05] <elenril> when transcoding with -ss, i get duration=(uint64_t)-1
[21:26:30] <elenril> Yuvi: i think the problem is that mkvmuxcontext.duration is unsigned
[21:26:44] <elenril> can you look at it?
[21:27:53] <Yuvi> do all pkt->pts have values?
[21:27:57] <elenril> yes
[21:28:02] <elenril> but soem of them are negative
[21:28:57] <Yuvi> hm, negative pts will cause more problems than just duration calculation
[21:29:23] <elenril> i thought negative pts are allowed
[21:31:26] <janneg> Linuxtag Call for Projects: http://wiki.linuxtag.org/w/fp:Call_for_Projects
[21:34:59] <byteme`> can I ask a non-ffmpeg related question? It is Linux related
[21:35:28] <byteme`> actually nevermind
[21:35:35] * byteme` needs to rtfm more
[21:36:46] <elenril> hmm, you were right, there's more things broken than just duration
[21:38:10] <janneg> and I need help rendering Big Buck Bunny. ETA 150 days at the current pace
[21:38:37] <ohsix> janneg: amazon s2
[21:39:13] <kierank> you mean ec2
[21:39:37] <ohsix> yea that; but you'll beed to store it somewhere too :>
[21:40:36] <janneg> ohsix: are you going to sponser 1800$?
[21:41:25] <ohsix> amazon might
[21:41:46] <ohsix> osuosl might too
[21:44:24] <Kovensky> thresh: http://www.boingboing.net/2010/02/23/dude-in-moscow-hacks.html <-- lolrussia
[21:46:38] <byteme`> did google just change the layout of their search results?
[21:46:39] <byteme`> hrm
[21:47:48] <thresh> Kovensky: yeah the guy's awesome
[21:48:12] <thresh> there are even photos of that billboard
[21:56:44] <CIA-92> ffmpeg: michael * r22039 /trunk/libavcodec/rectangle.h: Try to fix 100l compilation failure on some systems.
[22:04:32] <Dark_Shikari> good job michael ;)
[22:05:30] <mru> a few of the tests pass actually
[22:06:00] <siretart> Dark_Shikari: I'm currently testing your proposed libx264 backport for libx264. it seems that the 'baseline' and 'main' presets won't work: http://pbot.rmdir.de/6e6695ad8137b28cbcfbc9bc71242786
[22:06:46] <CIA-92> ffmpeg: michael * r22040 /trunk/libavcodec/rectangle.h: Fix doxy and assert().
[22:07:13] <Dark_Shikari> siretart: that's not how they work
[22:07:18] <Dark_Shikari> baseline, main, and high are modifier presets
[22:07:23] <Dark_Shikari> -vpre hq -vpre baseline
[22:07:29] <Dark_Shikari> or -vpre normal -vpre high
[22:07:30] <Dark_Shikari> or whatnot
[22:07:38] <Kovensky> http://www.ironicsans.com/2010/02/they_dont_make_computer_manual.html :D
[22:07:43] <Dark_Shikari> If you want a better system, we just exposed libx264's presets directly in the API
[22:07:50] <Dark_Shikari> and you could modify ffmpeg to use them directly
[22:07:52] <siretart> oh, I see. that's not exactly clear to me after reading the manpage
[22:07:59] <Dark_Shikari> of course it's not clear.  it's fucking awful
[22:08:05] <Dark_Shikari> you have two options:
[22:08:18] <Dark_Shikari> 1) pasteeater has a patch that he submitted to the ML that replaces the presets with new ones
[22:08:23] <Dark_Shikari> these new ones are equivalent (as best as possible) to the x264 presets
[22:08:28] <Dark_Shikari> and have "firstpass" versions of each one
[22:08:34] <Dark_Shikari> well actually that doesn't fix the baseline/high issue either :/
[22:08:41] <Dark_Shikari> 2) make a patch to use the libx264 presets
[22:08:51] <Dark_Shikari> this would require an API change at a minimum
[22:09:02] <Dark_Shikari> in fact it would probably require codec-specific defaults to work right :/
[22:10:03] <siretart> anyway, it seems that at least for simple invocations, your libx264 backport works fine
[22:11:16] <Dark_Shikari> btw, that's how it's always worked
[22:11:19] <Dark_Shikari> since the presets were created
[22:12:03] <Yuvi> elenril: negative dts is fine (and works with matroska since it's ignored)
[22:12:03] <Yuvi> negative pts can't be directly stored in any container afaik, and the only meaning I can think of is "start playback at this non-keyframe after decoding its dependencies"
[22:12:03] <Yuvi> so I guess it can be implied from an edit list (mov/mp4), ordered chapters (mkv), or ogg skeleton, but probably very few players actually work correctly
[22:14:04] <elenril> well ffmpeg obviously produces it when using -ss
[22:14:10] <Yuvi> -vcodec copy?
[22:14:12] <CIA-92> ffmpeg: michael * r22041 /trunk/libavcodec/rectangle.h: 3rd and hopefully last 100l fix.
[22:14:12] <elenril> so this is a bug in ffmpeg?
[22:14:19] <elenril> no, -vcodec libx264
[22:14:33] <Yuvi> it's a bug somewhere, not sure exactly where
[22:16:46] <mru> 3rd time lucky
[22:24:18] <Yuvi> elenril: from what source?
[22:28:14] <elenril> mkv
[22:28:25] <elenril> you can't reproduce?
[22:28:31] <Yuvi> nope
[22:41:07] <CIA-92> ffmpeg: siretart * r22042 /branches/0.5/ (20 files in 3 dirs):
[22:41:07] <CIA-92> ffmpeg: backport libx264.c from trunk
[22:41:07] <CIA-92> ffmpeg: now compiles with x264 API versions 65 up to 85
[22:41:07] <CIA-92> ffmpeg: patch prepared by darkshikari
[22:42:08] <siretart> good night
[22:42:12] <Dark_Shikari> \o/
[23:14:53] <janneg> http://www.jannau.net/bbb_videowall/
[23:17:22] <elenril> hmm, weird, now i can't reproduce it myself
[23:19:51] <janneg> mru, _av500_: instructions and status for rendering Big Buck Bunny are here http://www.jannau.net/bbb_videowall/
[23:21:08] <peloverde> janneg, what does "complete with rendering error already in the source file" mean?
[23:24:05] <janneg> peloverde: look at http://www.jannau.net/peach_2700x1440/01_intro_03_0001.png and you'll see
[23:24:56] <janneg> the eyes stay at the same position
[23:26:38] <peloverde> that's creepy but I'm still slightly confused about the "already in the source file" part? is it a bug in BBB itself?
[23:26:52] <mru> yes, big bug bunny
[23:28:10] <janneg> peloverde: it is bug in the production files from the project site and probably also on the dvd
[23:29:59] <janneg> i.e. they haven't published the corresponding source files
[23:32:03] <Dark_Shikari> which means it's not open source!~!11!
[23:40:50] <mru> boo, closed-source bunny :-(
[23:41:07] <mru> bunnies _want_ to be free!
[23:43:28] <_av500_> janneg: thx, will look into it
[23:49:56] <janneg> bah, the OOM killing gets annoying, could only render frame 1 of 02_rabbit/04.blend
[23:52:52] <janneg> I could try to add swap but I fear that the rendering speed will decrease from very slow to 1/ludicrous spped
[23:53:41] <CIA-92> ffmpeg: stefano * r22043 /trunk/libavutil/fifo.h:
[23:53:41] <CIA-92> ffmpeg: Extend doxy for the src parameter of av_fifo_generic_write().
[23:53:41] <CIA-92> ffmpeg: @patchby Tomas H?rdin |tomas dot hardin at codemill dot se|
[23:54:16] <iive> janneg: you may give a try to the compressed in memory swap
[23:54:36] <iive> in case the data is highly redundant.
[23:55:14] <_av500_> janneg: what mem do you need?
[23:57:40] <CIA-92> ffmpeg: alexc * r22044 /trunk/libavcodec/aac.c: (log message trimmed)
[23:57:40] <CIA-92> ffmpeg: aac: Keep decode_band_types() from eating all padding at the end of a buffer.
[23:57:40] <CIA-92> ffmpeg: Due to a shortcoming in the AAC specification, if an all zero buffer is
[23:57:40] <CIA-92> ffmpeg: fed to section data decoding it will never terminate. That means without
[23:57:40] <CIA-92> ffmpeg: a buffer exhaustion check decode_band_types() will consume all input
[23:57:41] <CIA-92> ffmpeg: buffer padding. Worse if a get_bits() implementation that returns zeros
[23:57:42] <CIA-92> ffmpeg: when padding is exhausted is used, the function will never terminate.


More information about the FFmpeg-devel-irc mailing list