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

[irc at mansr.com]

[00:00:21] <Dark_Shikari> hmm.  what's the best way to sum up the size of .o files in a folder?
[00:00:24] <Dark_Shikari> i.e. "du", but only for .o files
[00:00:36] <janneg> du -s *.o
[00:00:36] <mika_video> So here we do have a case where the ABI comptibility has been broken but the MAJOR version number has stayed the same.
[00:00:43] <Dark_Shikari> it's -c
[00:00:54] <Dark_Shikari> du -b -c folder/*.o | tail --lines=1
[00:01:13] <mru> mika_video: which commit?
[00:01:34] <mika_video> mru: I do not undetstand your comment "mru> mika_video: which commit?"
[00:01:43] <Yuvi> mika_video: um, git blame shows the only change in fields before codec_type were const changes and void* -> uint8_t*
[00:01:50] * mru gives up
[00:01:51] <Yuvi> since ~2002
[00:02:51] <Yuvi> and nothing since 2008, when the major version was bumped
[00:02:58] <mika_video> I was trying to find out why the delho demo program does not work. The delphi header were downloaded from page: http://www.iversenit.dk/dev/ffmpeg-headers/
[00:04:50] <mika_video> <mru>:  is it somehow hard to translate these 52.0.0 and 52.55.0 versin numbers of libavcodec to some revision numbers you seem to want to know ?
[00:07:01] <peloverde> mika_video, http://git.ffmpeg.org/?p=ffmpeg;a=history;f=libavcodec/avcodec.h;h=43a069550833188536926b99f90c6875fce319a3;hb=HEAD
[00:08:34] <Yuvi> oh I'm slightly wrong, r4168 went from int -> AVRational, still well before major version 52 though
[00:10:21] <Yuvi> mika_video: svn blame libavcodec/avcodec.h will show you when LIBAVCODEC_VERSION_MAJOR, _MINOR, and _MICRO were bumped
[00:12:46] <mika_video> here you can see the 52.0.0 I was refering to: http://git.ffmpeg.org/?p=ffmpeg;a=blobdiff;f=libavcodec/avcodec.h;h=43a069550833188536926b99f90c6875fce319a3;hp=05f79c87a1dc0ef62e61452621f5196f9f59ad08;hb=HEAD;hpb=56e20eeb030ad46c6bd3cc50f18048442141a2c5
[00:15:58] <mika_video> is there a way to download, say version 52.0.0 of avcodec.h ?
[00:16:38] <peloverde> the "raw" link on gitweb
[00:17:08] <mika_video> <peloverde>: any URL wow to get that ?
[00:19:19] <Yuvi> the only potential abi breaks I see are avcodec_find_best_pix_fmt, subtitle stuff, SAMPLE_FMT_S24, and error_resilience -> error_recognition
[00:19:36] <mru> renaming doesn't break abi
[00:19:41] <Yuvi> or that last one is api not abi
[00:21:06] <mika_video> <Yuvi>: then how can you expkain this: In avcodec version 52.0.0 the codex_type field of struct AVCodecContext was at offset 0xE0 but in version 52.55.0 it is located at offset 0xdc ?
[00:21:10] <peloverde> http://git.ffmpeg.org/?p=ffmpeg;a=blob_plain;f=libavcodec/avcodec.h;h=05f79c87a1dc0ef62e61452621f5196f9f59ad08;hb=05f79c87a1dc0ef62e61452621f5196f9f59ad08
[00:21:25] <Yuvi> mika_video: you're doing something wrong
[00:21:41] <mru> like talking about a field that doesn't exist :-)
[00:21:54] <mika_video> And I do not know how to make those version numbers into revision numbers since I can see here that many of you here like to refer to revision numbers instead.
[00:22:29] <mru> mika_video: how do you know the offset is different? do you have both versions of the file? if so, please pastebin a diff
[00:23:32] <Yuvi> and all of that (except the subtitle stuff) happened soon enough after the 52 bump that it should be part of the 52 abi
[00:23:40] <mika_video> <Yuvi>: I was wondering why a program written in Dephi does not work.  So I wrote a small test program in C to print offsets to all structure members and compared that with the same information from the delphi program and found out that the codex_type field has moved
[00:23:50] <janneg> git annotate --reverse only lists fields under LIBAVCODEC_VERSION_MAJOR < 52 as removed
[00:24:29] <janneg> mika_video: there is no field codex_type. do you mean codec_type
[00:25:43] <mika_video> mru: I have a C-language version of the 52.55.0 But I have a delphi version of 52.0.0. Unfortunately it makes no sense to fiff between a C language .h file and a delphi .pas file
[00:26:27] <mru> maybe the .pas is broken
[00:26:30] <janneg> so you use different compilers to compile completly different files
[00:26:30] <mika_video> mru: so to make such diff'ing meaningful I would need to download the C-language .h version of 52.0.0 - but I do not know how to do that
[00:26:37] <Dark_Shikari> mru: not "maybe"
[00:26:38] <Dark_Shikari> it _is_
[00:26:55] <mru> we don't know which version of the .h is was made from, so we can't say for sure
[00:27:31] <mru> but c and pascal probably use different field packing rules
[00:27:45] <mru> a naive translation would probably not work so well
[00:28:00] <mika_video> the .pas file has this: LIBAVCODEC_VERSION_MAJOR = 52;  LIBAVCODEC_VERSION_MINOR = 0;   LIBAVCODEC_VERSION_MICRO = 0;
[00:28:12] <mru> we got that
[00:28:24] <mru> doesn't mean much
[00:29:12] <mika_video> that translation is not done by me. I will next write a tool that prints offsets of both the C -language .h version and the .pas version used by delphi and tells whether there are any differences and lists them if there is
[00:29:13] <janneg> http://git.ffmpeg.org/?p=ffmpeg;a=tree;h=be7f65a11136664312b8b765034c757a5c25123e;hb=0472f3ecb8d65997f6de234110c5de06dc38a8f6
[00:29:37] <mru> so you _do_ have the C file for both revisions??
[00:29:50] <mika_video> <janneg>: yes, codec_type is what I mean
[00:30:03] <Dark_Shikari> mru: he doesn't understand what "independent variable" means
[00:30:07] <Dark_Shikari> or "control"
[00:30:14] <mru> or "version"
[00:30:17] <mru> or "file"
[00:30:20] <mru> or "pascal sucks"
[00:30:22] <mika_video> <mru>: NO. I have the C version of only 52.55.0
[00:30:51] <janneg> mika_video: http://git.ffmpeg.org/?p=ffmpeg;a=blob_plain;f=libavcodec/avcodec.h;hb=0472f3ecb8d65997f6de234110c5de06dc38a8f6
[00:31:05] <Dark_Shikari> mru: http://www.actsofgord.com/Annoy/chapter03.php first entry
[00:31:44] <mru> lol
[00:31:56] <Dark_Shikari> (that entire site is an absolute hoot, but that's the most relevant one)
[00:32:38] <mika_video> <mru>: That "pascal sucks" is a common misunderstandiong of C programmers, and it is correct if you think about some very outdated version of pascal that was standardized by ISO orgainzation in 1970 or something. Nowadays it's object pascal (the difference being more than between C and C++) and the hardest part of writing a vido app in Delphi is to get the ap and the C library to correctly understand each other
[00:33:10] <Dark_Shikari> "object pascal" sounds worse than pascal
[00:33:16] <mru> but, but... why is the lib in C if pascal is so great?
[00:33:19] * mru is puzzled
[00:33:30] <Dark_Shikari> I mean, I find this argument funny
[00:33:41] <mika_video> <mru>: ask yourself: why did you write it in C ?
[00:33:51] <Dark_Shikari> "C programmers think pascal is crap because it's outdated, but just like C was updated to C++, pascal was updated with object pascal!"
[00:34:01] <ramiro> oh, come on. let's not start this...
[00:34:02] <Dark_Shikari> But wait.  If they're C programmers, that means they don't like C++, or otherwise they would be using C++.
[00:34:07] <ramiro> it's annoying noise
[00:34:25] <Dark_Shikari> ramiro: I agree, let's take advantage of the intellectual osmosis argument.
[00:34:53] <mru> ramiro: come on, can't we have a little bit of fun?
[00:45:51] <mika_video> the diff between avcodec.h versions 52.0.0 and 52.58.0 is here: http://pastebin.com/zPXEZ1pb
[00:46:08] <mru> that's not what I requested
[00:46:38] <mru> I asked for the diff between the files you claim give different offsets
[00:46:41] <mika_video> <mru>: what then ?
[00:52:07] <mika_video> mru: I believe that if you compile two C programs, one using 52.0.0 and the other using, say, 52.58.0, the two programs will see the same fieldname at different offsets. If I am wrong here, then someone made a bad mistake ttranslating that .h to delphi. And if they tested their delphi app ata all, such mistake would make itself known immediately
[00:52:50] <mru> well, try it
[00:53:26] <mru> Catastrophic error: could not set locale "" to allow processing of multibyte characters
[00:53:29] <mru> lol
[00:53:43] <mika_video> Well, to create an app in C that only needs avcodec.h but does not actually do anything with video data, what else do I need to #include or link, or is avcodec.h alone enough ?
[00:54:01] <mru> didn't you say you had such an offset-printing app already?
[00:54:27] <ramiro> mika_video: this is outside the scope of this channel. try asking on the libav-user mailinglist.
[00:56:30] <mika_video> mru: so far the process is quite long. 1. I use an external app to convert .h to .xml ... then I have a delphi app to read that xml and produce an iclude file for a C program, and then I can use gcc to compile a skeleton C app that has #include showfields.inc (the app uses some C macros to print out offsets and sizes with every field name listed in showfields.inc)
[00:57:12] <Dark_Shikari> lol
[00:57:23] <mika_video> <ramiro>: would it be considered on-topic after proving that there was a change wich breaks ABI but MAJOR version number stayed the same ?
[00:57:34] <Dark_Shikari> sure, if you do so with a C compiler
[00:57:37] <Dark_Shikari> with the C language
[00:57:39] <Dark_Shikari> including a C header
[00:57:43] <mru> we're waiting for that proof...
[00:58:22] <mika_video> Well, can pastebin accept .zip files (a nice way to package .c and .c files etc.
[00:58:39] <ramiro> what would you want to put there?
[01:00:14] <mika_video> <ramiro>: a main program file in .c then two versions of avcodec.h, at least one renamed and also the struct name renamed, an include file that when #included in the C main program, will cause the C app to print a list of fields and their offsets.
[01:00:51] <mika_video> Or, if the two versions of the C app are compiled separately, tthen the renaming is not needed
[01:07:07] <bcoudurier> hi guys
[01:07:14] <Dark_Shikari> hi bcoudurier's autojoin script
[01:07:26] <mru> yay, the script is back
[01:07:31] <bcoudurier> nope
[01:08:58] <mika_video> so: what are the minimum requrements to create a working C program where I #include "avcodec.h". What else I absolutely must #include too to make it work ?
[01:09:57] <Yuvi> mika_video: http://www.pastie.org/871392
[01:10:27] <bcoudurier> it seems gmaxwell find the ogg muxer code horrible, does anyone know what's so horrible about it ? I just asked him as well
[01:10:46] <Yuvi> bcoudurier: it has 10-20% overhead for vorbis
[01:11:43] <Yuvi> bcoudurier: I did http://www.pastie.org/871394 to fix that, but it needs to interleave pages based on start time not granule
[01:11:47] <mru> it's an ogg muxer, of course it's horrible
[01:12:13] <Yuvi> (not rebased on today's fix yet)
[01:13:11] <Dark_Shikari> Yuvi: did you get gmaxwell's message?
[01:13:28] <Yuvi> yeah, bcoudurier applied the fix before I really looked at it
[01:13:40] <bcoudurier> yeah, there was an odd case
[01:13:58] <bcoudurier> so it does pack multiple packets in one page ?
[01:14:11] <Yuvi> for audio only
[01:14:21] <bcoudurier> btw Yuvi I have problem decoding theora here
[01:14:34] <bcoudurier> picture is garbage with latest svn
[01:14:57] <mika_video> showoffs.c:8: error: ‘AVCodecContext’ has no member named ‘codec_type’
[01:15:02] <bcoudurier> [theora @ 0x2499350]error in unpack_block_qpis
[01:15:06] <bcoudurier> vlc plays fine though
[01:15:24] <bcoudurier> Yuvi, that needs a parser
[01:16:57] <Yuvi> bcoudurier: link to file? mine work
[01:17:26] <Yuvi> and how would a parser help in the muxing case? the muxer still needs to know the individual packet sizes and pack them together itself
[01:17:50] <bcoudurier> decoding
[01:18:05] <CIA-92> ffmpeg: mru * r22565 /trunk/ (13 files in 5 dirs):
[01:18:05] <CIA-92> ffmpeg: Move H264 dsputil functions into their own struct
[01:18:05] <CIA-92> ffmpeg: This moves the H264-specific functions from DSPContext to the new
[01:18:05] <CIA-92> ffmpeg: H264DSPContext. The code is made conditional on CONFIG_H264DSP
[01:18:05] <CIA-92> ffmpeg: which is set by the codecs requiring it.
[01:18:06] <CIA-92> ffmpeg: The qpel and chroma MC functions are not moved as these are used by
[01:18:07] <CIA-92> ffmpeg: non-h264 code.
[01:19:07] <Dark_Shikari> mru: btw, the last entry on http://www.actsofgord.com/Annoy/chapter13.php is very very useful as well
[01:19:11] <Dark_Shikari> the "retarded monkey" approach
[01:19:26] <Dark_Shikari> "that ffmpeg looks like it was configured by a retarded monkey"
[01:19:31] <Dark_Shikari> "what, I didn't--"
[01:19:36] <Dark_Shikari> "I didn't blame you, I blamed a retarded monkey."
[01:19:48] <Yuvi> bcoudurier: sorry, I don't understand where the parser is coming in
[01:24:33] <mika_video> showoffs.c:3:32: error: libavcodec/avcodec.h:file not found. What??? - can gcc not understand symbolic links on linux ? (I just did ln -s libavcodec.h versions/avcodec_52_58_00.h, after renaming the original)
[01:24:59] <ohsix> heh
[01:25:32] <mru> maybe you're the one not understanding symlinks
[01:26:58] <bcoudurier> Yuvi, it seems the parsing will be done according to the lacing values
[01:28:00] <Yuvi> that happens in the ogg demuxer, it recombines the packets as written
[01:28:56] <bcoudurier> yes
[01:29:00] <mika_video> cannot get that example program compiled. using that #include <libavcodec/avcodec.h> the gcc cannot find even avcodec.h. And if I change that to #include "libavcodec/avcodec.h" then gcc can find avcodec.h but hen it complains libavcodec/avcodec.h:30:30: error: libavutil/avutil.h - file not found
[01:29:37] <ohsix> how do i shot web
[01:29:50] <mika_video> I thibnk it needs some compiler switch to make gcc search the correct path for int's #include's
[01:29:56] <Yuvi> it's actually impossible to parse a raw theora stream into packets, I think it is for vorbis as well
[01:32:16] <mika_video> <Yuvi>: how to get your example to compile. Is it possible even without a makefile ?
[01:33:05] <Yuvi> mika_video: http://gcc.gnu.org/onlinedocs/cpp/Search-Path.html add -I<path>
[01:33:29] <mika_video> I am now trying to compile on linux. But my own test program was compiled on windows using the mingw-gcc and the only way to get it compile ok, was to spy on what commend line the gnu make gives to gcc, and then copy and modify that to get my own C app compiled
[01:36:00] <mika_video> Yuvi: I tried gcc -I./ -I./libavutil/ -o showoffs showoffs.c - taht removes most of the error messages, but it still complains this: ./libavutil/pixfmt.h:32:32: error: libavutil/avconfig.h: file not found
[01:36:29] <Dark_Shikari> ohsix: ¯\(º_o)/¯
[01:38:11] <mika_video> how do I order make to not actually do anything but instead output all the command it *would* do if invoked normally ?
[01:40:31] <Yuvi> bcoudurier: also, another bug (I think): eos is written on multiple pages if the packet spans more than one
[01:40:53] <Yuvi> or no, the current code is fine, it's my code that does that
[01:41:40] <bcoudurier> ah ok
[01:41:56] <ramiro> bcoudurier: hi
[01:42:07] <bcoudurier> hi ramiro
[02:09:21] <mika_video> It seems you guys here are right and whoever made that .h to .pas conversion, made a mistake. I am surpised of that, because if that guy had test his program, such a mistake would show up immediately !
[02:10:00] <mika_video> Well, I am just surprised that some people just post code on the net and do not even test their apps to run correctly !
[02:59:53] <ramiro> mika_video: that's pretty common...
[03:00:55] <ramiro> mru: if you want more examples of sucky pkg-config usage, try liborc + schroedinger 1.0.9
[03:01:22] <ramiro> mru: and even more fun from freedesktop.org: http://www.mail-archive.com/schrodinger-devel@lists.sourceforge.net/msg00292.html
[03:01:35] <ramiro> "lost the home directory
[03:01:43] <ramiro> in a power outage"
[03:01:45] <ramiro> incredible...
[03:03:33] <astrange> with git you don't have to bother with redundant storage
[03:04:07] <ramiro> that doesn't make it ok to loose an open-source project because of a power outage =)
[03:04:48] <Dark_Shikari> "lose data in a power outage"
[03:04:48] <Dark_Shikari> lol
[03:05:06] <ramiro> orc has a library and a compiler. but - as is usual from freedesktop - they forgot that people might want to cross-compile
[03:06:06] <ramiro> so libschroedinger uses the compiler and the library, I can run orcc.exe with wine, but not the w64 version...
[03:25:39] <mru> they clearly don't care
[03:45:07] <ramiro> liborc is great. it's not designed for static libraries *and* for cross-compilation!
[03:45:34] <ramiro> much like liboil. I opened a bug because it didn't build with --disable-shared --enable-static and it was WONTFIXed...
[03:53:24] <mru> like anything from the fdo vicinity
[03:56:24] <mru> liboil always makes me think of snake oil
[04:13:01] <ramiro> notabug http://bugs.freedesktop.org/show_bug.cgi?id=27103
[05:55:00] <pJok> mornings
[06:39:57] <pJok> god morgon, kshishkov :)
[06:54:39] <kshishkov> god morgon, pJok
[06:55:10] <thresh> moroning, Kostya
[06:56:23] <kshishkov> told you, it's idioting here
[06:57:44] <thresh> whatever floats your boat :)
[06:58:40] <kshishkov> whatever floats and it's not cream
[07:08:52] <KotH> en wunderschöne guete morge!
[07:11:56] <av500> guten morgen
[07:12:20] <kshishkov> any reasons to think so?
[07:13:47] <kshishkov> for example, "I've managed to render 40 frames for BBB this morning on machine with 3G RAM. All of them were black though"
[07:13:49] <pJok> sun is shining, its not bitterly cold or blistering hot outside
[07:14:00] <pJok> i almost slept a full night
[07:14:08] <pJok> thats almost a good morning for me
[07:14:26] <kshishkov> accepted
[07:15:25] <av500> guten morgen (try2, kshishkov excluded)
[07:16:09] <kshishkov> av500, you forgot to add "I say so on my own free will and without any duress"
[07:17:09] <av500> I can run it thru /tools/good_morning_check maybe?
[07:19:08] <pJok> and i got a seat on the train... thats more than to be said for the people who are next to me :D
[07:19:59] <kshishkov> pJok: at least it's not that lucky occasion as here
[07:20:54] <pJok> well, i get on on the station before the next biggest and two stations before the biggest exchange of passengers
[07:21:24] <pJok> so i usually get a seat at least at the next biggest exchange if i didn't get one at the station i got on
[07:21:30] <kshishkov> Malmö kg Kobenhavn?
[07:22:02] <pJok> lund and malmö
[07:22:19] <pJok> train stops at helsingborg, landskrona, lund and malmö
[07:22:53] * av500 will be in Kobenhav in June it seems
[07:22:56] * kshishkov once went from Göteborg to Copenhagen by Öresundståg
[07:26:08] <pJok> same route as i take every morning
[07:29:57] <KotH> kshishkov: i think you should start with meditations or something
[07:30:18] <KotH> kshishkov: because it's a wonderfull morning, you just dont want to see it ;->
[07:30:48] <kshishkov> KotH: it's a bit spoiled by Ukraine around me
[07:31:13] <kshishkov> try living here for a week for starters
[07:31:25] <twnqx> i almost did that for ~2mnoth
[07:31:27] <twnqx> :S
[07:31:38] <twnqx> but then i refused that resident engineer position
[07:32:20] <kshishkov> just in case, Kiev != Ukraine
[07:32:34] <twnqx> so kiev would have been acceptable?
[07:33:42] <kshishkov> compared to other places here - yes
[07:33:54] <kshishkov> many people try to live there
[07:35:17] <KotH> then why dont you move to kiev?
[07:35:55] <KotH> there you could live a happy life until we get the rescue team formed and equipped
[07:36:34] <kshishkov> KotH: it's hard
[07:37:14] <kshishkov> not to mention that real estate prices there are higher than in Europe
[07:37:42] * KotH doesnt believe that
[07:37:47] <KotH> unless you dont count zürich to be in europe
[07:38:07] <av500> http://www.economist.com/research/articlesBySubject/displaystory.cfm?subjectid=7933596&story_id=15659589
[07:38:18] <av500> about expensive cities
[07:39:38] <av500> we actually thought about setting up a team in kiev. laber was cheap, but all the other stuff around that made it a nogo in the end
[07:39:43] <kshishkov> food is rather cheap here, some other things too
[07:41:18] <KotH> av500: i dont think that tokyo is that expensive
[07:41:52] <KotH> av500: when i did my internship there, tokyo was cheaper than zürich, which in turn is a lot cheaper than london, for example
[07:42:11] <kshishkov> hmm, a year ago Kiev was on 46-th place in global cost of real estate rating
[07:42:24] <thresh> suppose now it's waaay higher
[07:42:38] <av500> kshishkov: could have been the expensive mafia bribes in the end :)
[07:43:32] <kshishkov> http://www.globalpropertyguide.com/Europe/rent/
[07:43:40] <kshishkov> 7th place, yay!
[07:44:58] <av500> but u still dont beat paris!
[07:44:58] <kshishkov> but if you compare hotel prices Copenhagen may get 0th place
[07:48:43] <KotH> kshishkov: .ch is at 4th place...so stop complaining!
[07:49:59] <kshishkov> KotH: an average income here is < 200 Eur/month (300 for Kiev though)
[07:50:10] <thresh> duh, we're third
[07:50:25] <thresh> wait what, 4k euro per month? wtf?
[07:50:25] <kshishkov> and I don't complain - it's the thing you have to be proud about
[07:51:56] <pross-au> 4k euro a month!
[07:51:58] <pross-au> FFS
[07:52:52] <thresh> well that price is probably valid if you live near Kremlin
[07:53:22] <kshishkov> look at square meter prices
[07:53:52] <andoma> sweden is not even in there
[07:54:19] <thresh> kshishkov: yeah, the price is normal for Moscow centre
[07:55:24] <kshishkov> thresh: yes since you have Khanty-Mansiysk to cover those prices
[07:55:51] <thresh> yeah, though living in moscow centre is kind of stupid
[07:56:01] <kshishkov> tell that to Putin
[07:56:20] <thresh> he lives in Barviha
[07:56:52] <pross-au> paying about ~800 eu/month here
[07:57:52] <kshishkov> thresh: I thought it was Yeltsin's residence and your current Prime Minister lives in St.Putinsburg
[08:00:08] <kshishkov> pross-au: any codecs you'd like to have REd?
[08:00:24] <pross-au> MicroTalk
[08:00:42] <pross-au> Toilet also needs cleaning kshishkov
[08:00:55] <kshishkov> from spiders?
[08:01:01] <pross-au> them too!
[09:22:26] <hyc> wbs: fyi, librtmp publish/RTMP_Write is working now
[09:22:40] <wbs> hyc: great :-)
[09:23:02] <kshishkov> *now* who's copying stuff ;-)
[09:23:11] <wbs> that's at least one showstopper less for integrating it for my part
[09:23:18] <hyc> lol
[09:26:14] <hyc> kshishkov: I'm ashamed to admit, I couldn't even copy your routine, due to other bugs in my code
[09:26:35] <hyc> my SendPacket was spitting out wrong timestamps...
[09:26:51] <kshishkov> it's not mine though
[09:28:27] <hyc> no? anyway I would never have seen the problem if it weren't for wbs asking about RTMP_Write
[09:29:00] <kshishkov> it was some other guy who wanted to have publishing, I just assisted getting it to SVN
[09:30:16] <hyc> ahh. well, now it's in 2 SVNs. :P
[09:30:38] <kshishkov> fine with me
[09:31:20] <kshishkov> and I suspect we got C version of RTMP client earlier than you :P
[09:32:31] <hyc> heh heh. looks like it.
[09:33:05] <hyc> well, that was before I had any choice in the matter....
[09:33:48] <hyc> C++ < C  ;)
[09:34:16] <kshishkov> depends on how compiler does it ;)
[09:34:42] <hyc> the original version of this code was awful, using that Boost crap
[09:34:55] <hyc> it's like nobody knows how to write a single honest line of code these days
[09:35:19] <hyc> they all need to instantiate this or that stupid class / template / whatever
[09:35:29] * kshishkov turned from C++ in times when STL began to be remotely consistent between compilers
[09:36:00] <wbs> I use C++ for my own applications, but really prefer C for libraries
[09:36:27] <hyc> I find that C++ just obfuscates
[09:36:52] <hyc> but whatever, yeah, certainly for low level code, there's no benefit from C++
[09:37:14] <kshishkov> from my experience Java now is also mostly a cartload of commons-* libs to do some simple task
[09:39:11] <kshishkov> Boost is used to minimize the difference between C++ and Java
[09:39:45] <hyc> no wonder I didn't like it. ;)
[09:40:14] <kshishkov> maybe you are a programmer and not a code monkey
[09:40:42] <hyc> is code monkey just a step up from script kiddie?
[09:40:51] <kshishkov> ook
[09:42:05] <pJok> afternoon jai :)
[09:42:21] <jai> good afternoon pJok :)
[09:43:18] <kshishkov> jai: it's too early for that there
[09:43:43] <jai> kshishkov: well, it is afternoon here :)
[09:43:56] <kshishkov> so I gather
[09:44:29] <jai> ooh, filter for changing the aspect ratio
[09:44:32] <kshishkov> I wonder if you also have the same word for morning and evening
[09:45:12] <jai> kshishkov: different words for all phases of the day
[09:45:19] <kshishkov> godd
[09:45:21] <kshishkov> *good
[09:46:46] <hyc> for what it's worth, testing against rtmplite isn't always so great either
[09:46:56] <hyc> http://code.google.com/p/rtmplite/issues/detail?id=1#c0
[09:47:29] <hyc> the maintainer doesn't seem to pay attention or actually do any maintaining...
[09:47:43] <kshishkov> "worksforme"
[09:48:05] <kshishkov> in terms "it does all _I_ need, no need to bother about somebody else"
[09:48:53] <hyc> the other reason it took me so long to get the publish timestamps right is that rtmplite was recording them incorrectly
[09:49:08] <hyc> I guess I could post another issue there, but seems futile
[09:49:29] <kshishkov> why not get something else?
[09:49:34] <kshishkov> Red5 for example?
[09:49:49] <hyc> too big. don't want to spend the time figuring out how to configure it
[09:49:53] * kshishkov used mostly some simple RTMP servers in Ruby and Perl
[09:51:34] <hyc> from where?
[09:52:25] <kshishkov> rubyizumi or something from googlecode
[09:52:38] <kshishkov> and random RTMP links
[09:53:44] <hyc> yeah, I've done plenty of those. seems like there's never one just when you want it though.
[09:55:17] <hyc> it's gotten easier lately, stream-recorder.com forum usually has a lot of URLs to try
[09:59:35] <merbzt> janneg: the torrent doesn't work
[09:59:52] <merbzt> got the box working with 4gb of memory now
[10:00:13] <merbzt> so it should be able to do somework
[10:03:27] <superdump> i should get my i7 churning
[10:03:31] <superdump> it's not doing anything
[10:03:44] <superdump> what do i need to do? and what are we rendering?
[10:03:51] * kshishkov has idle BeagleBoard
[10:04:40] <hyc> kshishkov: any plans for it? I have two AI TouchBooks here
[10:04:57] <hyc> they're actually the reason I started hacking on rtmpdump...
[10:06:13] <twnqx> anyone fit with git here? i reverted a patch and got a new git revision... how do i kill all traces of that and go back to before reverting?
[10:06:28] <wbs> twnqx: reset <hash>
[10:06:42] <wbs> and you probably want --hard if you don't want to keep the changed files in the work area
[10:06:43] <av500> hyc: send one to me of course :)
[10:06:49] <twnqx> thanks
[10:07:29] <hyc> av500: heh, I thought you already had something
[10:07:48] <merbzt> twnqx: "git check sheet" is an ok short reference
[10:07:55] <av500> of course I have "something", but dont we always want more? :)
[10:08:11] <hyc> lol. Yes! which is why I'm keeping both of mine. ;)
[10:26:05] <superdump> merbzt , janneg : what are we rendering and what's needed to do it?
[10:33:29] <merbzt> superdump: BBB in 2*HD I think
[10:33:45] <superdump> any good reason?
[10:33:56] <merbzt> for the screen wall
[10:34:26] <superdump> mmm
[10:34:32] <superdump> well, where are the instructions?
[10:35:50] <merbzt> http://jannau.net/bbb_videowall/
[10:37:49] <superdump> does janne have somewhere to which i can upload the images once they're done
[10:37:59] <superdump> i won't have enough webspace anywhere
[10:38:12] <merbzt> I think so
[10:38:18] <superdump> ok
[10:38:28] <superdump> i'll get it going in a minute then
[10:38:46] <merbzt> I don't get the torrent working ;/
[10:41:51] <superdump> maybe the tracker is down
[10:42:49] <superdump> working for me now
[10:43:14] <superdump> have you set up port forwarding/upnp for your torrent client?
[10:48:03] <merbzt> nope
[10:50:09] <merbzt> guess it's blocked
[11:49:21] <mru> av500: is your arm/h264 build issue fixed?
[12:01:32] <mcgeagh> hello all. Im wondering if any work is going on, or planned to, for incorporating OpenMAX into ffmpeg???
[12:01:42] <mru> no
[12:01:54] <av500> mru: I did not retest yet
[12:02:15] <av500> I package a svn snapshot, so I'd need to repeat that
[12:02:39] <mru> just shout if it's still broken next time you try it
[12:02:43] <av500> yup
[12:02:48] <av500> shout I will :)
[12:02:56] <mru> no doubt
[12:03:31] <mcgeagh> mru, has there been any discussion about ever incorporating it in the forseeable future?
[12:03:58] <mru> that's not likely
[12:04:06] <mru> that it'll happen
[12:04:19] <mru> openmax is a pile 'o stink
[12:04:22] <thresh> even if someone sends a patch?
[12:04:27] <mru> even then
[12:04:45] <jai> does anyone have h/w with support?
[12:04:47] <mcgeagh> oh, is it that bad?
[12:04:59] <thresh> jai: many people have n900 ;-)
[12:05:01] <mru> the API, if you can call it that, is a mess
[12:05:31] <mru> when I looked at it, it wasn't even obvious _what_ the api was
[12:05:34] <bilboed-tp> you want to stay away from openmax... really
[12:05:40] <jai> thresh: hmm,k
[12:05:46] <mru> and the ARM code I looked at was totally unreadable
[12:05:48] <av500> bilboed-tp: come on, just another sandal, no? :)
[12:06:35] <av500> or was it a shoe?
[12:06:44] <bilboed-tp> it's seriously bad
[12:06:45] <mru> both, and a boot outside of that
[12:07:00] <bilboed-tp> it's just a collection of .h
[12:07:03] <mcgeagh> ok, so if i do it (regardless if its a good idea or not) your not interested in it
[12:07:06] <thresh> well, there is some support in VLC nowadays for that
[12:07:06] <bilboed-tp> no reference implementation
[12:07:23] <mcgeagh> i know gstreamer supports it
[12:07:30] <av500> and gg made that the default for android /sigh....
[12:07:41] <mru> gst likes a mess
[12:07:55] <mcgeagh> k, so no pollutants in ffmpeg
[12:08:01] <mcgeagh> got it
[12:08:05] <bilboed-tp> mcgeagh, there's a gstreamer plugin that attempts to support it ... yes
[12:08:11] <av500> mcgeagh: why are you interested in it?
[12:08:33] <mru> he's been misled to believe it would be useful, of course
[12:08:42] <mcgeagh> yep
[12:08:50] <mru> mcgeagh: are you talking about omx IL or DL btw?
[12:08:53] <mru> or AL?
[12:08:54] <mcgeagh> that and, i have hardware that supports it
[12:09:01] <mru> and which version?
[12:09:03] <kshishkov> mru: next thing you'll hear about IPP H.264 decoder again
[12:09:05] <av500> mcgeagh: hw?
[12:09:09] <mcgeagh> so instead of getting codecs specific for the platform, wanted to get ffmpeg to support it too
[12:09:15] <av500> ???
[12:09:16] <mcgeagh> IL
[12:09:21] <mru> kshishkov: ipp does have fast mpeg2 idct
[12:09:38] <mcgeagh> i cant say on hw
[12:09:43] <av500> mcgeagh: what hw?
[12:09:52] <mcgeagh> and im assuming 1.1 version, but will check
[12:10:09] <mru> the goal of ffmpeg isn't to be a wrapper for other libs
[12:10:14] <mru> there's gst for that :-)
[12:10:16] <mcgeagh> the hw isnt released yet so cannot talk about the hw
[12:10:22] <av500> cpu?
[12:10:29] <mcgeagh> arm
[12:10:33] <av500> orly...
[12:10:37] <thresh> :-)
[12:10:45] <av500> not leg?
[12:11:09] <av500> mcgeagh: and you have openmax codecs, or you want to write some?
[12:11:31] <kshishkov> av500: that's why some of us call it not mere CPU but whole Acorn RISC Machine :P
[12:13:32] <av500> mcgeagh: of course you could write a wrapper that would make openmax codecs callable via lavc API
[12:14:07] <av500> but unless you plan to use ffplay a lot, this wrapper could also be outside...
[12:14:31] <av500> i.e. in your multimedia app
[12:46:47] <KotH>  Subject: Re: [gst-devel] How can I have two main loops in my program??
[12:46:57] <KotH> (no comment)
[12:47:13] <kshishkov> cheapskate
[12:48:31] <av500> KotH: actually, we have that :)
[12:49:05] <bilboed-tp> KotH, that guy is made of fail
[12:50:59] <KotH> bilboed-tp: i've not read the discussion, just saw that subject scrolling by in my procmail.log
[12:51:18] <bilboed-tp> KotH, the subject sums it up indeed :)
[12:51:19] <KotH> av500: er.. you're a comercial company... i expect worse of you
[12:51:33] <kshishkov> I suspect he'll ask for _nested_ loops next
[12:52:42] <av500> KotH: actually, it was a nested mainloop construct that in the end we never used :)
[12:52:54] <av500> nested ftw!
[12:56:21] * kshishkov wonders if somebody's told him to add another label and jump instruction
[15:49:46] <CIA-92> ffmpeg: rbultje * r22566 /trunk/ffmpeg.c:
[15:49:46] <CIA-92> ffmpeg: Typo: if output (video) stream's pix_fmt is not set, then the stream cannot
[15:49:46] <CIA-92> ffmpeg: be ENcoded, not DEcoded.
[17:03:22] <superdump> peloverde: ping?
[17:03:56] <kshishkov> you'd better use piNGGG with higher frequencies coded with SBR
[17:04:46] <kshishkov> or PS (ping stereo)
[17:20:15] <peloverde> superdump, pong
[17:42:01] <peloverde> IE 9 announced H.264+AAC support, nice!
[17:42:40] <BBB> wooh
[17:42:43] <BBB> what other formats?
[17:42:46] <BBB> WMV, I suppose?
[17:43:26] <peloverde> I don't see anything about WM{A,V} but it wouldn't surprise me
[17:43:52] <Dark_Shikari> wait, with HTML5 video?
[17:44:24] <peloverde> yes
[17:44:27] <Dark_Shikari> lol
[17:44:31] <Dark_Shikari> oh god the drama will be funny =p
[17:44:38] <thresh> yeah mozilla is fucked
[17:44:42] <Dark_Shikari> Yeah
[17:44:45] <Dark_Shikari> I saw this coming a mile away
[17:44:46] <jai> more like butthurt
[17:44:47] <mru> \o/
[17:44:49] <Dark_Shikari> I kept telling people this
[17:44:53] <thresh> well everyone did i suppose
[17:44:56] <Dark_Shikari> IE9 is going to support H.264/AAC
[17:44:57] <Dark_Shikari> ... and it did
[17:45:09] <Dark_Shikari> when it's going to come out?
[17:45:23] <twnqx> how DARE they support non-free codecs
[17:45:32] <mru> microsoft have realised that no matter how hard they push vc1, h264 is the de facto standard
[17:45:41] <Dark_Shikari> mru: they realized that 3-4 years ago imo
[17:45:48] <mru> yes
[17:45:49] <Dark_Shikari> they've written their own h264 encoder since, and it's pretty good
[17:45:54] <Dark_Shikari> and silverlight now does h264 standard
[17:46:05] <mru> exactly
[17:46:16] <peloverde> Dark_Shikari, their encoder seems like crap, it's limited to 4GB memory
[17:46:20] <peloverde> what is this, 1982
[17:46:31] <Dark_Shikari> peloverde: why would you need 4GB of memory for encoding?
[17:46:31] <mru> why would an encoder need more than 4GB memory?
[17:47:00] <peloverde> Above HD resolutions?
[17:47:22] <Dark_Shikari> peloverde: x264 can do 4K without more than 2GB memory
[17:47:24] <mru> we're not encoding at 32k just yet
[17:47:47] <twnqx> x264 can also to 720p at >2GB :]
[17:47:50] <twnqx> do*
[17:47:53] <Dark_Shikari> yes, yes, if you want to use rc-lookahead 250
[17:47:55] <Dark_Shikari> for NO REASON WHATSOEVER
[17:48:20] <twnqx> full GOP lookahead!
[17:48:32] <peloverde> They have a KB article about it, which implies it is an issue for some of their customers
[17:48:56] <Dark_Shikari> lol
[17:48:57] <mru> customer == idiot
[17:49:04] <mru> ms customer doubly so
[17:49:22] <peloverde> It just seems silly that their code isn't 64-bit clean
[17:49:31] <mru> it's of course possible, perhaps even likely, that the ms encoder is so rubbish it really needs that much memory
[17:49:41] <mru> peloverde: silly and predictable
[17:50:05] <twnqx> you think there are chances to trade memory for speed? or is it plain bad code?
[17:51:06] <Dark_Shikari> there are ways to trade memory for "speed"
[17:51:12] <Dark_Shikari> but once you consider cache effects, they're all worthless
[17:51:22] <Dark_Shikari> e.g. I tried making a LUT for bit cost of 4x4 dct blocks with CAVLC
[17:51:32] <mru> yes, you can trade memory for speed
[17:51:32] <Dark_Shikari> it saved a ton of time, but the cache pressure and misses were enough to exactly cancel it out
[17:51:36] <mru> give up some speed, use more ram
[17:51:40] <Dark_Shikari> lol
[17:52:33] <twnqx> you need to run it on one of those parisc monster with HUGE l3 caches
[17:52:49] <twnqx> then again, it'll still use to SIMD and higher clock speeds
[17:52:50] <mru> and no simd
[17:52:53] <twnqx> lose*
[17:53:08] <BBB> omg @ libv4l
[17:53:35] <mru> what's he getting at?
[17:53:46] <mru> is he talking about cameras with mpeg output?
[17:54:03] <BBB> issue1816
[17:54:09] <mru> I saw the email
[17:54:19] <mru> but it doesn't make much sense
[17:54:37] <mru> using a library to perform a few ioctl() calls seems pointless
[17:55:13] <thresh> it does some colorspace conversion so you don't need to actually do it in your app
[17:55:19] <thresh> (among other things)
[17:55:24] <thresh> of course, i don't know if it's fast enough
[17:55:38] <mru> great, so you get to convert colourspace twice
[17:55:54] <BBB> what I find hilarious is that for any "problem" that Linux developers invent, they will write a new "libXYZ" that will fix it
[17:55:59] <BBB> then they advertise it EVERYWHERE
[17:56:01] <BBB> USE LIBXYZ
[17:56:19] <BBB> reminds me of early days of libalsa
[17:56:52] <mru> alsa is crap through and through
[17:57:02] <mru> the driver side isn't totally bad
[17:57:14] <BBB> they fixed libalsa by making pulseaudio
[17:57:19] <BBB> ...
[17:57:20] <mru> all the layers they plaster on top in libalsa make it bad
[17:57:32] <BBB> I wonder how people will fix pulseaudio
[17:57:38] <BBB> I'm sure they will write a gstreamer plugin for it
[17:57:39] <elenril> what's so bad about alsa?
[17:57:46] <BBB> layeritus
[17:57:47] <mru> http://blogs.adobe.com/penguin.swf/linuxaudio.png
[17:57:50] <thresh> yeah, IIRC gspca developers moved out all the code to do conversions out of kernel so there was no other chance to get it working except creating a library to do so
[17:58:03] <mru> what conversions?
[17:58:21] <mru> having colourspace conversion in kernel is obviously wrong
[17:58:28] <thresh> colorspace
[17:58:31] <mru> that was a mistake in the original v4l "design"
[17:58:39] <Dark_Shikari> >implying v4l was designed
[17:58:49] <mru> hence the scarequotes
[17:59:00] <thresh> http://hansdegoede.livejournal.com/3636.html will probably explain better
[17:59:04] <janneg> for example raw bayer data
[17:59:04] <thresh> and other hans posts
[17:59:10] <kshishkov> BBB: I fixed it - sudo apt-get remove pulseaudio
[17:59:15] <janneg> or encoded jpeg
[17:59:20] <BBB> kshishkov: I installed macosx
[17:59:23] <mru> if raw bayer is all you get from the hw, then that's what the kernel should expose
[17:59:27] <BBB> or rather, I bought a mac
[17:59:41] <mru> are you insane?
[18:00:00] <kshishkov> BBB: that too, but on Linux I had to remove pulseaudio since it screw something
[18:00:01] <janneg> and it does now
[18:00:19] <mru> I haven't removed pulseaudio
[18:00:22] <mru> I never installed it
[18:00:25] <mru> never will
[18:00:45] <BBB> IIRC pulse was my reason to stop developing gnome
[18:01:19] <kshishkov> and not millions of crappy plugin libs required everywhere?
[18:01:27] <BBB> that too
[18:01:50] <kshishkov> the only good point about Gnome that it sucks differently from KDE
[18:01:53] <BBB> libv4l is a silly idea, userspace devices seem more likely
[18:02:03] <BBB> libalsa same thing
[18:02:26] <elenril> kde3 didn't suck so much
[18:02:47] <thresh> userspace devices?
[18:02:49] * Kovensky thinks OSSv4 is the only sane thing
[18:03:03] <peloverde> The OSS team has shown they aren't trustworthy
[18:03:44] <thresh> the thing i miss most in linux is /dev/ethN
[18:03:50] <kshishkov> WinAPI is saner - for each block WavePrepareDevice(); WaveWriteOutput(); WaveUnprepareDevice();
[18:03:51] <Kovensky> peloverde: ?
[18:03:59] <BBB> thresh: you know how certain things in /dev/ can run in userspace
[18:04:07] <BBB> thresh: open("/dev/that");
[18:04:23] <BBB> instead of v4l_open("/dev/video");
[18:04:45] <mru> mmap(/dev/mem) ftw
[18:05:01] <peloverde> Kovensky, They changed the license when they were popular and tried to sell closed drivers
[18:05:06] <BBB> point being, writing a userspace WRAPPER for kernel "bugs" is always wrong
[18:05:14] <kshishkov> well, Gatos driver creators proposed to use some internal script command language instead of ioctls too
[18:05:30] <mru> and look how far it got them
[18:05:33] <Kovensky> <@peloverde> Kovensky, They changed the license when they were popular and tried to sell closed drivers <-- oh, that
[18:05:56] <Kovensky> I thought it was some other problem after they re-opened ._.
[18:06:10] <kshishkov> yes, ALSA
[18:06:47] <kshishkov> since evil SuSe devs pushed it into kernel nobody cares much about OSS
[18:07:09] <mru> greg kh is very evil
[18:07:32] * Kovensky is confuzzled
[18:07:33] <kshishkov> who's that?
[18:07:36] <BBB> the oss4 (?) guys did a good effort to try to push it
[18:07:39] <mru> the evil suse dev
[18:07:46] <BBB> they contacted me and offered oney for me to write gst plugins
[18:07:50] <BBB> *money
[18:07:52] <kshishkov> well, suse is known for other great evils
[18:07:55] <BBB> I almost did it
[18:08:12] <BBB> maybe I should've
[18:08:21] <mru> I don't give a toss about that patent deal they struck with ms
[18:08:22] * Kovensky only knew greg kh as the staging guy
[18:08:49] <mru> more recently he pushed "devtmpfs" against half the maintainer's will
[18:09:09] <mru> devfs was bad the first time, it'll be bad every time
[18:09:46] <mru> oh, and he's a freetard of highest class
[18:10:14] <kshishkov> mru: I heard you also enjoyed chatting with Joerg Schillig
[18:10:34] <Kovensky> lol
[18:10:35] <mru> hehe
[18:10:42] <mru> schilling is fun
[18:10:50] <mru> one of the best trolls ever
[18:11:17] <kshishkov> have you told him how you record your DVDs?
[18:11:30] <elenril> is that the cdrtool guy?
[18:11:33] <mru> yes
[18:17:32] <janneg> cdrecord
[18:18:13] <Dark_Shikari> ok, so this is getting more and more weird
[18:18:18] <jai> thats part of crtools
[18:18:21] <jai> *cdrtools
[18:18:22] <Dark_Shikari> yesterday I spent 30 minutes talking about low latency VNC-style streaming with an autodesk guy
[18:18:30] <Dark_Shikari> 15 minutes later, he says "want to fly up to san francisco?"
[18:18:32] * jai remembers the whole cddl thing
[18:18:51] <Dark_Shikari> apparently they're using ultra-low-latency video streaming for demos of their products
[18:19:03] <Dark_Shikari> so you can try autocad without buying it or downloading a gigantic demo of fail
[18:20:46] <Dark_Shikari> well, whatever it is, I'm getting a lot of free junkets
[18:21:06] <kshishkov> yes, so he wants low-latency wireless communication with you
[18:21:14] <jai> Dark_Shikari: buy everyone a beer :)
[18:21:30] <Dark_Shikari> lol
[18:21:40] <Dark_Shikari> technically, I'm still a bit too young ;)
[18:21:51] <kshishkov> emigrate to Russia
[18:21:53] <Dark_Shikari> (isn't the US great)
[18:21:58] <jai> Dark_Shikari: you can have yourself some cranberry juice
[18:22:11] <Dark_Shikari> lol
[18:22:53] <kshishkov> Dark_Shikari: in Russia you also have bottled water with local vodka brands (produced by them)
[18:22:53] <BBB> so you can vote
[18:22:56] <BBB> carry guns
[18:22:59] <BBB> but you cannot drink?
[18:23:01] <Dark_Shikari> correct!
[18:23:03] <Dark_Shikari> US is great.
[18:23:03] <BBB> LOVE this country
[18:23:06] <BBB> :)
[18:23:23] <kshishkov> BBB: I'd prefer working Systembolaget to that
[18:23:29] <BBB> let's not forget the drive car & have sex
[18:23:58] <BBB> thank god they don't drive manuals here
[18:24:05] <BBB> imagine the accidents
[18:24:17] <jai> BBB: unlike your home country, in this case the constitution was drafted by prudes :)
[18:24:56] <kshishkov> BBB: I've heard that the most terrible drivers are French (even worse than Russians)
[18:25:05] <jai> BBB: btw, we drive manual transmission here
[18:25:24] <mru> BBB: yeah, driving a manual while having sex is dangerous
[18:25:27] <kshishkov> jai: and you still have original Jeep model in production as well
[18:25:35] <jai> kshishkov: of course :)
[18:25:42] <mru> american gals can only handle one stick at a time, apparently
[18:26:05] <BBB> okaaaaaaaaaay
[18:26:14] * BBB takes a break
[18:26:20] <mru> too rude for this channel?
[18:26:21] <jai> lol
[18:26:26] <BBB> :)
[18:27:16] <jai> #ffmpeg-devel | age-limit >=18
[18:27:30] <kshishkov> BBB: you have an opportunity to talk about voice codecs now
[18:27:36] <mru> hey, it's not like I'm posting ascii-porn...
[18:27:46] <kshishkov> mru: IIRC you did once
[18:27:54] <mru> in this channel?
[18:27:56] <jai> mru: throw some of that in too once in a while
[18:28:06] <mru> I've done that in other channels
[18:28:19] <mru> but I don't think you're in those
[18:33:44] <CIA-92> ffmpeg: victor * r22567 /trunk/doc/general.texi: Add compilation hints for Cygwin 1.7 and remove the ones for 1.5
[18:36:58] <jai> doesnt 1.7 use a buggy gcc by default?
[18:38:25] <kshishkov> don't they all?
[18:38:34] <kshishkov> along with crippled libs
[18:39:55] <ramiro> and it's rather annoying to remove the default gcc...
[18:40:47] <ramiro> a bunch of packages implicitly include gcc. there is no simple way to remove them besides cycling through "install", "update", "keep", "skip". if you click once too much, you have to go through "install" again, which re-selects all gcc packages...
[18:41:12] <mru> gaaah, I hate the cygwin installer
[18:41:22] <mru> thankfully I'll probably never have to touch it again
[18:41:35] <ramiro> they should port apt-get to cygwin.
[18:41:46] <mru> I'm not a fan of that either
[18:42:01] <ramiro> it's better than cygwin's installer at least.
[18:42:13] <mru> even rpm beats cygwin
[18:43:05] <jai> ramiro: why dont people just use mingw+msys?
[18:43:18] <mru> probably because mingw doesn't actually work
[18:43:30] <mru> cygwin looks like and behaves almost like unix
[18:43:33] <peloverde> mingw + msys is a mess to install and update
[18:43:45] <jai> has worked so far for me
[18:43:48] <jai> peloverde: ok
[18:43:49] <ramiro> and lacks a handful of functionality...
[18:43:57] <mru> it's dreadfully slow, and some things don't work quite right
[18:44:11] <jai> peloverde: tbh, i update it once every 6 months or so :)
[18:44:16] <mru> but if you're stuck on a windows machine you can at least get some work done
[18:44:26] <jai> mru: i always found cygwin to be much slower in comparison
[18:44:33] <mru> I'm talking about cygwin
[18:44:45] <mru> mingw may be a hair faster but lacks much more functionality
[18:44:46] <jai> ah
[18:44:55] <peloverde> for cygwin you download setup.exe and select what you want from the package manger, for mingw I always wind up needing 2 dozen installers and zip files to get what i need
[18:45:10] <mru> sockets and pipes tend to break outside of cygwin
[18:45:49] <ramiro> peloverde: I only need one installer (msys itself). the rest is just tar xfvj...
[18:45:58] <kshishkov> do cygwin-compiled progs still require cygwin1.dll?
[18:46:04] <mru> yes
[18:46:05] <ramiro> kshishkov: you can cross-compile to mingw
[18:46:12] <mru> that's where all the magic lives
[18:46:13] <peloverde> you still need to track down all the tarballs and update them manually
[18:46:28] <kshishkov> ramiro: I've always used msys+mingw
[18:46:31] <mru> you can easily build for non-cygwin under cygwin
[18:46:45] <ramiro> peloverde: yes, that's true... annoying, but I know the subset needed for ffmpeg, and that's all I need =)
[18:47:14] <jai> i think coreutils and zlib should be enough?
[18:47:22] <jai> on top of stock msys
[18:47:24] <ramiro> well, now that virtualbox is good enough on windows, there's no reason to use either msys or cygwin...
[18:47:41] <mru> there's also no reason to use windows in the first place
[18:47:44] <ramiro> jai: now yes (actually only pr.exe from coreutils)
[18:47:56] <peloverde> office in wine is still super buggy for me
[18:48:03] <kshishkov> mru: not all people are free
[18:48:04] <peloverde> ^ = reason to use windows
[18:48:08] <mru> why would you run office?
[18:48:10] <jai> except for QA which you have to do as windows maintainer ;)
[18:48:13] <jai> ramiro: ^
[18:48:26] <peloverde> mru, MPEG working documents are all .doc
[18:48:38] <mru> they load fine in openoffice
[18:48:47] <peloverde> The always come up mangled for me
[18:49:06] <kshishkov> missing fonts maybe
[18:49:21] <mru> I always export to pdf first thing
[18:49:28] <jai> 3gpp specs seemed to be a bit off when it comes to layout in openoffice
[18:49:32] <jai> though its readable
[18:49:36] <mru> I cannot stand reading a document in ooffice or msword
[18:50:37] <kshishkov> and some people use it for reading _books_
[18:50:50] <ramiro> -freorder-functions? I don't need that for the fate boxes...
[18:52:43] <peloverde> This is not usable at all: http://i.imgur.com/yMDKG.png
[18:53:12] <mru> where's the file?
[18:53:31] <Kovensky> -fomg-fast?
[18:55:23] <peloverde> That one isn't publicly available, here is the 3GPP version it does the same thing: http://www.3gpp.org/ftp/Specs/archive/26_series/26.404/26404-900.zip
[18:56:39] <peloverde> My OO.o rendering of it: http://i.imgur.com/YUFaz.png
[18:56:53] <peloverde> abiword and kword do no better
[18:57:03] <ramiro> peloverde: and google docs?
[18:57:19] <peloverde> ramiro, google docs is terrible too
[18:57:21] <kierank> seems to work ok in staroffice (but might be because i'm on windows)
[18:57:22] <jai> i still somehow manage 3gpp specs with abiword though :)
[18:57:53] <kshishkov> so it may be fonts issue after all
[18:58:50] <peloverde> OO.o should be able to handle it with their symbol font
[18:59:28] <kierank> it appears as a picture, not an equation in staroffice for some reason
[18:59:37] <mru> hmm, I get a few <?> characters
[19:01:12] <mru> gaah, oo is stuck in a loop popping up a message complaining about bad JRE
[19:01:35] <kshishkov> it's true though
[19:04:40] <mru> all the bad characters inside some kind of "picture"
[19:05:14] <peloverde> Here is the google docs pitiful attempt: http://i.imgur.com/Mt6hl.png
[19:05:14] <kshishkov> IIRC it also renders equations as vector graphics
[19:07:36] <peloverde> I also tried pulling the updated ttf-opensymbol from the latest OO.o nightly
[19:08:06] <kshishkov> it may need original symbol ffonts instead
[19:10:23] <mru> I have every font package in gentoo installed, and some more
[19:11:08] <peloverde> (I also have a bunch of opentype fonts that cause OO.o to shit itself when it touches them)
[19:15:17] <BBB> Vitor1001: did you have a chance to look at that crazy rdft scheme yet?
[19:16:50] <Vitor1001> BBB: I gave a look, but didn't yet got what that was supposed to do :(
[19:17:27] <Vitor1001> It certainly do a phase shift
[19:17:56] <Vitor1001> ie., writing everything as a sum of sinuses and then changing all the sinuses to cosinus
[19:18:13] <peloverde> I thought we established it was a hilbert transform? (or is this something else)?
[19:18:16] <Kovensky> math D:
[19:18:22] <BBB> peloverde: something else, I think
[19:18:31] <BBB> peloverde: or maybe not
[19:18:32] <BBB> wait
[19:18:37] <BBB> this was the complex code
[19:18:42] <BBB> was that a hilbert?
[19:18:56] * Vitor1001 has to read what a hilbert transform is
[19:18:59] <Vitor1001> :(
[19:19:13] <Vitor1001> Sorry, but today I'm somewhat you of time...
[19:19:14] <kshishkov> it's all on wikipedia
[19:19:16] <peloverde> The hilbert changed the reals to imaginary in the fourier domain then inverse transformed
[19:19:37] <kshishkov> what for?
[19:19:42] <Vitor1001> peloverde: Than it is it, because that is what the code does...
[19:19:46] <Vitor1001> bbl...
[19:28:55] <BBB> is it because of that convolution stuff at the end of the wikipedia article?
[19:29:03] <BBB> because that'd fit the numbers I see after the phase shift
[19:30:03] <BBB> which are maximal (~1.0) for the peaks (left of the DFT approx.) and lows (right of the DFT approx.), i.e. the result would be that the DFT approx. is shifted to become more like the actual 2/(n*pi)
[19:30:14] <BBB> but as always, I have no idea what I'm doing
[19:34:29] <kshishkov> lab rule - if you don't know what you're doing then do it thoroughly
[19:34:57] <peloverde> Honestly, we always did Hilbert transform the last week of the semester so I never really learned it
[19:35:12] <DonDiego> bye
[19:35:15] <kshishkov> always?
[19:35:22] <peloverde> I had it in two classes
[19:35:39] <peloverde> Signal Processing and Communication Systems
[19:36:01] <kshishkov> we had only Hadamard transform (mentioned once) at Computer Graphics
[19:36:51] <mru> I only remember hilbert mentioned in passing
[19:37:02] <peloverde> I vaguely remember needing a hilbert transform for single sideband modulation
[19:43:05] <BBB> peloverde: but what does it do?
[19:43:39] <BBB> is it a particularly good way of removing noise equally without caring about "level" of noise per frequency?
[19:43:52] * BBB mumbles hocuspocus
[19:43:58] * BBB needs to read a signalprocessing book, yes I know
[19:44:15] <kshishkov> dspguide.com or something
[19:44:39] <kshishkov> all chapters in PDF, free download IIRC
[19:47:20] <BBB> hilbert only occurs once
[19:47:23] <BBB> and that's a mention
[19:47:26] <BBB> without any information :)
[19:58:15] <peloverde> I don't know, i haven't done anything with it in a long tim
[19:58:18] <peloverde> *time
[19:58:42] <kshishkov> everybody else simply haven't done anything with it
[20:02:04] <peloverde> "You use the Hilbert transform to extract instantaneous phase information, obtain the envelope of an oscillating signal, obtain single-sideband spectra, detect echoes, and reduce sampling rates."
[20:02:30] <_av500_> peloverde: svn add hilbert.c?
[20:02:34] <kshishkov> envelope or echoes seems plausible
[20:03:01] <thresh> http://farm5.static.flickr.com/4014/4438147379_4be8e401d3.jpg ta-duh.
[20:03:34] <_av500_> thresh: you hilbert transformed your screen?
[20:04:16] <thresh> kind of. i'd call it 'punch transform'.
[20:04:38] <_av500_> a dirac impulse?
[20:06:32] <peloverde> since the output is eventually treated as an angle i'm pretty sure it's extracting phase
[20:07:42] <ramiro> if we create a LinkedIn account (and Facebook and whatnot) for FFmpeg's lists, will that make the lists immune to invitations?
[20:08:54] <peloverde> Is there an arctan in there at all?
[20:09:45] <kshishkov> why? it has poles
[20:10:56] <peloverde> instantaneous phase is atan2(H(f)(t), f(t))
[20:11:24] <peloverde> Can I see that chunk of code again?
[20:57:42] <bcoudurier> hi guys
[21:11:32] <elenril> hi bcoudurier's onjoin script
[21:11:42] <andoma> :)
[21:11:47] <elenril> bcoudurier: can you review/apply Honoome's patch for s/author/artist in movdec?
[21:12:37] <bcoudurier> oh, sorry but who is Honoome ?
[21:12:56] <elenril> the other Diego
[21:14:10] <elenril> Date: Fri, 19 Feb 2010 14:42:52 +0100,  Fix metadata mapping for author/artist
[21:14:20] <bcoudurier> movdec is good
[21:14:31] <bcoudurier> movenc is not, "auth" should be author obviously
[21:14:41] <ohsix> bcoudurier: Honoome = flameeyes from gentoo
[21:15:06] <elenril> well we don't have an 'author' tag
[21:15:54] <elenril> btw why isn't all metadata exported in movdec?
[21:23:46] <CIA-92> ffmpeg: mru * r22568 /trunk/configure:
[21:23:46] <CIA-92> ffmpeg: configure: do not use $_
[21:23:46] <CIA-92> ffmpeg: Both bash and ksh abuse this variable even in POSIX mode, leading
[21:23:46] <CIA-92> ffmpeg: to unpleasant surprises.
[21:23:46] <CIA-92> ffmpeg: mru * r22569 /trunk/ (10 files in 10 dirs): Move arch-specific makefile parts into $arch/Makefile
[21:23:47] <CIA-92> ffmpeg: mru * r22570 /trunk/libavcodec/ (6 files in 6 dirs): Simplify arch-specific object file lists
[21:46:25] <CIA-92> ffmpeg: mru * r22571 /trunk/libavformat/utils.c:
[21:46:25] <CIA-92> ffmpeg: Fix erroneous behaviour when format probe hits end of file
[21:46:25] <CIA-92> ffmpeg: If the format probe hits end of file, do not add the error code
[21:46:25] <CIA-92> ffmpeg: to the buffer position. This is obviously wrong, and with a
[21:46:25] <CIA-92> ffmpeg: small input file would cause a negative buffer overflow.
[21:46:26] <CIA-92> ffmpeg: Fixes issue 1818.
[21:46:52] <BBB> shit he left
[21:52:40] <mru> who?
[21:55:09] <BBB> peloverde
[21:55:45] <BBB> I think he's right, and the specific application appears to be noise reduction using an iterative wiener filter (??), at least I have a paper describing that which appears to match my implementation pretty closely
[22:17:20] <superdump> BBB: does that involve throwing sausages at something?
[22:29:13] <bcoudurier> Yuvi, are you there ?
[22:29:24] <Yuvi> bcoudurier: yo
[22:29:33] <bcoudurier> elenril, feel free to expert everything but many atoms contain only data
[22:30:05] <bcoudurier> I've merged your patch and fixed problems
[22:30:05] <bcoudurier> thanks for the work
[22:30:05] <bcoudurier> I've a few concerns though
[22:30:05] <Yuvi> yay
[22:30:07] <bcoudurier> since granule must be strictly monotone
[22:30:13] <bcoudurier> this seriously reduce the packing
[22:30:21] <Yuvi> only within a stream
[22:30:22] <bcoudurier> no
[22:30:22] <bcoudurier> oggz-validate complains
[22:30:29] <bcoudurier> if video granule < audio granule
[22:30:34] <bcoudurier> err >
[22:31:14] <bcoudurier> so except if it is a oggz-validate problem
[22:31:14] <bcoudurier> it's not possible
[22:31:14] <bcoudurier> what do you think ?
[22:35:44] * Terminating due to: TERM
[22:36:01] * /join #ffmpeg-devel ...
[22:36:03] *** TOPIC: Welcome to the FFmpeg development channel. That is, development of FFmpeg, not using FFmpeg, nor libav*. | Users should redirect their questions to #ffmpeg | FFmpeg 0.5.1 has been released! | this chat is now publicly logged.
[22:36:03] *** TOPICINFO: superdump!~rob at unaffiliated/superdump, 1267604523
[22:36:21] <_av500_> but granule is opaque to the muxer, no?
[22:36:25] <bcoudurier> Ogg does not have a concept of 'time': it only knows
[22:36:25] <bcoudurier>    about sequentially increasing, unitless position markers.
[22:36:26] <mru> yes
[22:36:30] <bcoudurier> rfc
[22:37:21] <_av500_> so it cannot know granule relatipnshop btween streams
[22:37:33] <mru> that never stopped xiph before
[22:37:51] <_av500_> :)
[22:39:52] <mru> "logical stream data pages are arranged in a physical bitstream in strict non-decreasing order by chronological absolute time as specified by the granule position"
[22:39:56] <mru> http://xiph.org/ogg/doc/ogg-multiplex.html
[22:40:09] <Yuvi> anyway, my only argument for interleaving based on start time was that I thought players (vlc) didn't like the additional buffering needed for audio
[22:40:32] <mru> nobody likes ogg
[22:41:18] <bcoudurier> well actually the packing is not that bad
[22:41:26] <bcoudurier> you don't need a parser to extract frames
[22:41:31] <bcoudurier> not like PS or TS
[22:41:31] <mru> uh?  it's the most terrible one ever devised
[22:41:41] <bcoudurier> PS and TS add parser overhead
[22:41:45] <mru> you don't need that with mp4 of mkv either
[22:41:50] <bcoudurier> nope
[22:41:54] <bcoudurier> I'm comparing to PS and TS
[22:42:03] <mru> that's a bad idea
[22:42:07] <bcoudurier> the PES packing is not convenient
[22:42:08] <mru> they solve a different problem
[22:42:14] <Yuvi> oh
[22:42:27] <bcoudurier> especially when startcodes are hard to find
[22:42:32] <Yuvi> the issue with the file I was trying is that all audio pages had a granulepos of 0
[22:42:41] <mru> that's not very valid
[22:44:17] <mru> "the only requirement is that page n of a logical bitstream follow page n-1 in the physical bitstream. There are no restrictions on intervening pages belonging to other logical bitstreams"
[22:49:04] <mru> http://xiph.org/ogg/doc/oggstream.html
[22:49:04] <mru> lovely inconsistency
[22:49:04] <mru> non-monotone muxing also breaks bisection seeking of course
[22:49:04] <_av500_> just do it per stream :)
[22:49:04] <Yuvi> _av500_: that's actually more work in the muxer
[22:49:04] <Yuvi> well, than what happens now
[22:49:04] <Yuvi> bcoudurier: anyway the answer from #theora is that granule interleaving is a must regardless of the rfc
[22:49:04] <mru> and regardless of that other page explicitly stating the opposite
[22:49:04] <bcoudurier> Yuvi, between streams ?
[22:49:04] <Yuvi> bcoudurier: yep
[22:49:04] <bcoudurier> ah ok
[22:49:04] * Terminating due to: __DIE__
[22:49:56] * /join #ffmpeg-devel ...
[22:49:56] *** TOPIC: Welcome to the FFmpeg development channel. That is, development of FFmpeg, not using FFmpeg, nor libav*. | Users should redirect their questions to #ffmpeg | FFmpeg 0.5.1 has been released! | this chat is now publicly logged.
[22:49:56] *** TOPICINFO: superdump!~rob at unaffiliated/superdump, 1267604523
[23:07:25] <twnqx> oh wow
[23:07:25] <twnqx> a file that freezes the h264 decoder
[23:09:09] <twnqx> [h264 @ 0xad3aa0]illegal short term buffer state detected??,?% 8 0
[23:09:09] <twnqx> mh
[23:09:09] <twnqx> oh wow
[23:09:09] <twnqx> seeking in this file is not a good idea either :P
[23:25:52] * Terminating due to: __DIE__
[23:52:41] * /join #ffmpeg-devel ...
[23:52:43] *** TOPIC: Welcome to the FFmpeg development channel. That is, development of FFmpeg, not using FFmpeg, nor libav*. | Users should redirect their questions to #ffmpeg | FFmpeg 0.5.1 has been released! | this chat is now publicly logged.
[23:52:43] *** TOPICINFO: superdump!~rob at unaffiliated/superdump, 1267604523
[23:53:27] <mru> bcoudurier: who's that?
[23:53:53] <bcoudurier> someone in #theora
[23:54:15] <iive> lol
[23:54:44] <mru> someone proved him wrong?