[FFmpeg-devel-irc] IRC log for 2011-02-11

[irc at mansr.com]

[00:07:12] <j-b> Jumpyshoes: no, irssi
[00:07:34] <mru> the one client to rule them all
[00:09:25] <mru> #define ONE((INT32) 1)
[00:11:26] <Jumpyshoes> j-b: oh, i see
[00:19:03] <CIA-38> ffmpeg: Jason Garrett-Glaser <jason at x264.com> master * rf3d09d44b7 ffmpeg/libavcodec/vp8.c:
[00:19:03] <CIA-38> ffmpeg: VP8: optimized mv prediction and decoding
[00:19:03] <CIA-38> ffmpeg: Merge find_near_mvs and mv bitstream decoding: don't do prediction steps
[00:19:03] <CIA-38> ffmpeg: until absolutely necessary.
[00:22:30] <Kovensky> 20:49.51 mru: oh, and everything you hear on irc is true <-- how do you hear written text? :)
[00:22:34] <Kovensky> 20:58.48 mru: rebase -i <-- that's not a merge =p
[00:23:10] <mru> rebase -i is the answer he was looking for
[00:23:26] <mru> and re hearing on irc, that's the point
[00:23:53] <Kovensky> heh
[00:24:14] <Kovensky> there is a way to workaround that though
[00:24:17] * Kovensky points to festival
[00:24:57] <mru> so text2speech makes things come true?
[00:25:24] <Kovensky> well, it makes hearing irc come true :)
[00:26:28] <kierank> or we could have an #ffmpeg-devel skype like we did in #x264
[00:27:33] <Kovensky> voice chat doesn't work very well with more than 5 people involved
[00:27:47] <kierank> it was alright when we did it
[00:28:08] <Kovensky> it was terrible when I tried that :>
[00:28:17] <kierank> though it managed to be exactly like #x264 somehow. discussion of touhou interspersed with discussion of x264
[00:28:22] <Kovensky> heh
[00:28:36] <Kovensky> live imitates irc!
[00:28:38] <Kovensky> life*
[00:30:45] <Kovensky> the only time I've used voice chat effectively with more than 10 people was in an eve fleet, since there's a clear hierarchy and rules to follow
[00:30:52] <Kovensky> not much unlike military radio
[00:31:15] <kierank> I always though multiplayer fps voice chat would be like military radio
[00:31:18] <kierank> how wrong was I
[00:31:38] <Kovensky> lol
[00:31:56] <Kovensky> no, it's just people cursing each other and competing for the biggest cluster f bomb
[00:32:06] <kierank> it's only good if it's people you know
[00:34:02] <merbanan>  my name is Benjamin-san
[00:35:52] <ubitux> is there a way in the probe function to ask for more data?
[00:37:30] <ubitux> also, how to handle if the header is at the end of the file?
[00:37:59] <kierank> merbanan: ?
[00:38:38] <merbanan> from devel
[00:40:45] <BBB> merbanan: I saw that, that was funny
[00:46:18] <Kovensky> merbanan: Benさん
[00:46:20] * Kovensky runs
[00:46:58] * kierank has no idea what that means
[00:47:21] <Kovensky> "bensan"
[00:47:52] <kierank> well i still have no idea what the context is
[00:48:09] <mru> kierank: someone called merbanan benjamin-san on the ml
[00:48:29] <beastd> not it should read: ベンさん
[00:48:33] <kierank> ah i see it
[00:48:50] <kierank> last question: what does the suffix -san mean?
[00:48:58] <mru> something japanese
[00:49:07] <mru> that's usually all you need to know
[00:49:08] <beastd> mr (or ms in depending on the gender)
[00:49:12] <Kovensky> japanese has a bunch of suffixes you put after names called "honorifics"
[00:49:15] <Kovensky> "-san" is the "default" one
[00:49:23] <kierank> I see
[00:50:14] <Kovensky> there's, -kun, -sama and a bunch of other ones and they imply a certain relationship between you and the mentioned person, -san is almost always the "neutral" one
[00:51:12] <roxfan> suddenly, japanese lessons in my #ffmpeg-devel
[00:52:09] <Kovensky> video codec development is anime-driven
[00:52:16] <roxfan> true
[00:54:16] <BBB> mru: hah, I figured it out, it's squash!
[00:54:22] <BBB> mru: can I commit the rest?
[00:55:43] <Dark_Shikari> kierank:
[00:55:44] <Kovensky> kierank: to make it weirder to westerners, not using any honorifics at all (specially if you're using the person's given name instead of family name) is the most intimate way to refer to someone
[00:55:46] <Dark_Shikari> -san (neutral, respect)
[00:55:52] <Dark_Shikari> -kun (friend)
[00:55:57] <Dark_Shikari> -chan (don't use this unless you're an anime character)
[00:56:00] <Dark_Shikari> or you're mocking someone
[00:56:11] <kierank> -sama?
[00:56:12] <Kovensky> -kun can also be used for subordinates
[00:56:16] <Dark_Shikari> -sama (great respect, e.g. to a teacher, leader, etc)
[00:56:34] <mru> and the negatives?
[00:56:41] <mru> how do you address someone you dislike
[00:56:43] <mru> ?
[00:56:55] <merbanan> don't answer him
[00:57:05] <mru> is there a way?
[00:57:10] <mru> I'm just curious
[00:57:17] <merbanan> or we will hear him saying it all the day
[00:57:19] <Dark_Shikari> I don't think they know what "not being respectful" means.
[00:57:19] <Kovensky> AFAIK there's no specific one for that
[00:57:24] <Dark_Shikari> they're Japanese
[00:57:24] * BBB gives mru the look
[00:57:26] <merbanan> lol
[00:57:30] <mru> merbanan: come on, I'm not 12 anymore
[00:57:41] <mru> Dark_Shikari: I'm not surprised
[00:57:45] <BBB> he will say it very specifically to one person
[00:58:08] <Kovensky> most of the time when someone is trying to be disrespectful it's either through sarcasm or through disrespectful pronouns
[00:58:09] <beastd> well, if you use the wrong suffix or none. or if you use kisama instead of anata (you) ;)
[00:58:38] <merbanan> someone go commit the LTP stuff
[00:58:49] <Kovensky> beastd watches too much shounen
[00:58:50] * Kovensky runs
[00:59:14] <BBB> merbanan: ok, will do tonight
[00:59:18] <BBB> looking at the bink patch now
[00:59:19] <BBB> +dinner
[01:02:42] * beastd runs opposite direction
[01:18:23] <mru> 52 insertions(+), 111 deletions(-), 30% faster
[01:18:50] <mru> qualcomm not so good at optimising...
[01:20:37] <kierank> optimising what?
[01:20:44] <mru> libjpeg
[01:33:05] <bcoudurier> are you optimizing libjpeg ?
[01:33:25] <mru> there are those who pay for that
[01:33:34] <bcoudurier> rofl
[01:33:35] <mru> and it's laughably easy
[01:33:45] <bcoudurier> can you optimize zlib ?
[01:33:48] <bcoudurier> encoding
[01:33:57] <bcoudurier> png is so slow ...
[01:34:16] <bcoudurier> although I guess multi frame threading should be implemented
[01:34:24] <kierank> optimize iff
[01:34:31] <kierank> most important codec
[01:37:38] <BBB> wasn't basty doing that?
[01:38:01] <bcoudurier> well png is one rgb codec supported by quicktime
[01:38:13] <bcoudurier> handy when doing some funky stuff with logo, text etc..
[01:38:23] <kierank> BBB: yes
[01:44:07] <BBB> merbanan: there's rob's comment which was not really addressed
[01:44:12] <BBB> merbanan: what do I do with it?
[01:44:25] <mru> ignore it :)
[01:44:30] <BBB> mru: use libjpeg-mmx, part of mjpeg.sourceforge.net/, about 2x as fast as libjpeg with same api
[01:44:50] <mru> not on arm
[01:44:54] <BBB> (unfortunately only x86)
[01:44:55] <BBB> oh
[01:44:59] <BBB> I should've known :-p
[01:45:17] <mru> there are about 142 different libjpeg forks
[01:45:21] <mru> and forks of forks
[01:45:23] <BBB> I guess
[01:45:25] <BBB> so
[01:45:27] <mru> and spoons
[01:45:29] <BBB> ignore superdump's comment?
[01:45:36] <mru> of course not
[01:46:07] <BBB> so not apply?
[01:46:56] <mru> I don't even know which patch you're talking about
[01:47:03] <mru> ignore me
[01:48:38] <kierank> [01:46] mru: there are about 142 different libjpeg forks --> what about wrappers?
[01:48:44] <kierank> i know you'd love a nice wrapper mru
[01:50:46] <saintd3v> LibJpegKit ?
[02:18:21] <BBB> mru: are the vorbis_dec.c cosmetics ok?
[02:18:25] <BBB> mru: I merged 1/5+2/5
[02:34:54] <CIA-38> ffmpeg: Alexander Strasser <eclipse7 at gmx.net> master * r07f06540f6 ffmpeg/libavcodec/vorbis_dec.c:
[02:34:54] <CIA-38> ffmpeg: vorbis dec: Delete useless scopes, and reindent after scope deletion
[02:34:54] <CIA-38> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni at gmx.at>
[02:34:54] <CIA-38> ffmpeg: Signed-off-by: Ronald S. Bultje <rsbultje at gmail.com>
[02:35:07] <CIA-38> ffmpeg: Alexander Strasser <eclipse7 at gmx.net> master * r97f5f97108 ffmpeg/libavcodec/vorbis_dec.c:
[02:35:07] <CIA-38> ffmpeg: vorbis dec: cosmetics: Indent CPP cond properly
[02:35:07] <CIA-38> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni at gmx.at>
[02:35:07] <CIA-38> ffmpeg: Signed-off-by: Ronald S. Bultje <rsbultje at gmail.com>
[02:35:09] <CIA-38> ffmpeg: Alexander Strasser <eclipse7 at gmx.net> master * r4f03c5d793 ffmpeg/libavcodec/vorbis_dec.c:
[02:35:09] <CIA-38> ffmpeg: vorbis dec: cosmetics: Indent consistently
[02:35:09] <CIA-38> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni at gmx.at>
[02:35:09] <CIA-38> ffmpeg: Signed-off-by: Ronald S. Bultje <rsbultje at gmail.com>
[02:35:11] <CIA-38> ffmpeg: Alexander Strasser <eclipse7 at gmx.net> master * r0605cb4332 ffmpeg/libavcodec/vorbis_dec.c:
[02:35:11] <CIA-38> ffmpeg: vorbis dec: Remove obsolete comment
[02:35:11] <CIA-38> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni at gmx.at>
[02:35:11] <CIA-38> ffmpeg: Signed-off-by: Ronald S. Bultje <rsbultje at gmail.com>
[02:35:15] <CIA-38> ffmpeg: Anton Khirnov <anton at khirnov.net> master * rb0294c80d3 ffmpeg/libavformat/ (avformat.h version.h):
[02:35:15] <CIA-38> ffmpeg: lavf: deprecate AVFormatContext.index_built
[02:35:15] <CIA-38> ffmpeg: it's not touched anywhere in ffmpeg, the code setting it was removed
[02:35:15] <CIA-38> ffmpeg: over two years ago (e9b78eeba22b050810a507e69df1b652e56ab62b).
[02:35:16] <CIA-38> ffmpeg: Signed-off-by: Ronald S. Bultje <rsbultje at gmail.com>
[02:53:19] <barspi> hi kids, it's me again!  this time trying to report an apparent bug in the configure script for the case when you are compiling for darwin/arm and you need the gas-preprocessor.pl
[02:53:39] <barspi> anyone around who is responsible for the configure script?
[02:57:41] <barspi> I think mru could be the guy :-)
[03:00:25] <mru> describe the problem
[03:01:05] <barspi> I'm trying to compile for iphone with the gas-preprocessor  (this works in the 0.6.1 version, but the configure script in HEAD has changed)
[03:01:10] <barspi> in particular this line:
[03:01:24] <barspi> if enabled asm; the
[03:01:25] <barspi>     as=${gas:=$as}
[03:01:36] <barspi> I had to turn around the default
[03:01:44] <barspi> as=${as:=$gas}
[03:02:09] <barspi> because otherwise it ignores the —as  parameter I give
[03:02:23] <barspi> it just tries to use the hardcoded $gas instead of my --as
[03:02:59] <barspi> if I modify this line, it works perfectly
[03:03:35] <mru> what are you setting with --as?
[03:03:54] <mru> your change will break when the defaults (without --as) are ok
[03:03:55] <barspi> ./gas-preprocessor.pl /Developer/Platforms/iPhoneOS.platform/Developer/usr/bin/arm-apple-darwin10-gcc-4.2.1
[03:04:05] <barspi> I'm sorry   ../gas-preprocessor.pl /Developer/Platforms/iPhoneOS.platform/Developer/usr/bin/arm-apple-darwin10-gcc-4.2.1
[03:04:38] <mru> why?
[03:04:56] <barspi> but the thing is… If I explicitly pass a —as "bla bla bla" parameter, shouldn't use mine instead of the internal, hardcoded gas variable?
[03:05:11] <mru> does the default not work?
[03:05:29] <barspi> nope….
[03:05:30] <barspi> GNU assembler not found, install gas-preprocessor
[03:05:30] <barspi> If you think configure made a mistake, make sure you are using the latest
[03:05:34] <barspi> etc etc
[03:05:57] <mru> your suggested change is wrong either way
[03:06:03] <barspi> the hardcoded one tries to use $cc  instead of arm-apple-darwin.xxxxx
[03:06:13] <mru> and what is $cc?
[03:06:24] <mru> it should work
[03:06:41] <barspi> I don;t claim to undersand all the subtleties of what's going on… but the default just doesn't work and if I use my old and trusty —as  configuretion it does work
[03:06:49] <barspi> let's see
[03:07:28] <barspi> this is my  —cc='/Developer/Platforms/iPhoneOS.platform/Developer/usr/bin/gcc-4.2 -arch armv6'
[03:07:52] <mru> that should work
[03:08:15] <barspi> then, the new configure does
[03:08:17] <barspi>    darwin)
[03:08:17] <barspi>        enable malloc_aligned
[03:08:17] <barspi>        gas="gas-preprocessor.pl $cc"
[03:08:22] <mru> I know that
[03:08:25] <mru> that's intentional
[03:08:31] <barspi> it hardcodes it.. and completely ignores whatever  —as I pass on the command line
[03:08:55] <barspi> I'm not against having a "hardcoded default" (either one that works or not), but it should let me use my --as
[03:09:06] <mru> why do you need to use --as?
[03:10:01] <barspi> well… it's the one that works :-)  it's the way to do it that appears all over the internet for the last couple of years as the "way to build ffmpeg for ios devices"
[03:10:19] <mru> those instructions are old and wrong
[03:10:21] <barspi> you must use the gas-preprocessor, and bla bla bla and use configure with all those parameters
[03:10:49] <barspi> they may be old but they work and the default doesn't :-(
[03:11:02] <barspi> at least for certain (mine?) cases
[03:11:55] <barspi> this is a clean git clone, with a gas-preprocessor.pl installed, on an up-to-date mac, with the latest Xcode installed in the standard apple-santified way
[03:12:21] <barspi> i think I don't have any special configuration...
[03:12:35] <barspi> and it's been compiling like that (ffmpeg 0.6.x) for several months
[03:12:45] <barspi> but the new configure script fails :-(
[03:12:46] <mru> 1) find someone who can touch a mac without puking (i.e. not me), 2) explain the problem _in detail_, 3) hope for a solution
[03:13:33] <barspi> oh… I just thought you were the one who added that line because of  http://lists.mplayerhq.hu/pipermail/ffmpeg-cvslog/2010-July/030747.html
[03:14:41] <mru> that doesn't mean I'll go anywhere near a mac
[03:15:10] <barspi> I won't question that :-)
[03:16:00] <barspi> my question is about the reason of not letting me define my own —as  (if I don't, it's ok to use a working/non-working/sometimes-working default)
[03:16:21] <barspi> but if I *do* explicitly use —as, I should be able to use mine and not the hardcoded one
[03:16:40] <barspi> like the rest of the cofnigure script (I can provide my own cc, or my own prefix directories, etc)
[03:16:48] <mru> if you're a mac user you should be used to doing as you're told
[03:17:05] <barspi> haha
[03:17:22] <barspi> I'm not completely a mac user, but i'm developing mac/ios apps :-)
[03:17:46] <mru> that's unfortunate for you
[03:18:45] <astrange> BBB: could you look for the reason in encoding why MPV_frame_end gets called but ff_draw_horiz_band doesn't? or rather, the draw_edges bits of them don't
[03:20:35] <barspi> there's an interesting idiosyncrasy in the ffmpeg community of avoiding/evading a problem with answers of the kind "you are doing it wrong" (very Steve Jobsy I must say)
[03:20:53] <Yuvi> barspi: put gas-preprocessor in /usr/local/bin or similar?
[03:21:05] <barspi> hmm I'll try that Yuvi
[03:21:23] <barspi> so far I had it in the project root, and the one above it (from where I call the build script)
[03:21:50] <astrange> does llvm-mc do ARM yet?
[03:22:05] <mru> mc?
[03:22:10] <Yuvi> there's work on it
[03:22:12] <Yuvi> haven't tried it
[03:22:34] <astrange> the llvm gas replacement
[03:22:38] <astrange> guess it stands for machine code
[03:24:52] <barspi> Yuvi: I put the gas-preprocessor on the path and it seems to be working
[03:25:40] <mru> you're right that an explicit --as should take precedence, but I can't think of a sane way to do that
[03:25:59] <mru> and when building for ios, using $cc is the only thing that will work anyhow
[03:26:16] <barspi> stil… if I'd like to *explicitly* use  —as 'stupid-preprocessor  /stupid/path/to/non/working/asm/just/for/fun'   I should be able to do it
[03:26:53] <mru> I agree in principle
[03:26:55] <barspi> doesn't it work as all the other defaults?  (if it's given in the command line, use that one, if not, use default?)
[03:27:00] <mru> but in practice you'll never need to do that
[03:29:06] <barspi> I may want to use a different version of gcc/asm for a different SDK or architecture  or whatever
[03:29:17] <mru> that would be ill-advised
[03:29:34] <mru> mixing versions is not a good idea
[03:32:04] <barspi> ok… want to see more fun stuff? ;-)
[03:32:28] <barspi> using the default configure file, putting gas-preprocessor.pl under /opt/local/bin (which is in the path)
[03:32:33] <barspi> -rw-r--r--   1 barspi  staff  625456 Feb 11 01:31 libavcodec.a
[03:32:39] <barspi> I'm sorry
[03:32:47] <barspi> -rw-r--r--   1 barspi  staff  944208 Feb 11 01:26 libavcodec.a
[03:32:57] <barspi> so, 944K for the libavcodec.a
[03:33:09] <mru> so?
[03:33:24] <barspi> using my modified configure (which calls  '../gas-preprocessor.pl /Developer/Platforms/iPhoneOS.platform/Developer/usr/bin/arm-apple-darwin10-gcc-4.2.1')
[03:33:32] <barspi> the libavcodec.a measures 625K
[03:33:41] <barspi> (the line i copied first)
[03:33:50] <mru> means nothing
[03:33:52] <barspi> so arm-apple-darwin.xxxx must be doing some better optimizations
[03:33:56] <barspi> than jsut using gcc
[03:34:05] <barspi> means the file is 2/3 the size
[03:34:21] <mru> no
[03:34:28] <barspi> no?
[03:34:48] <mru> the only difference is what assembles the .S files
[03:34:57] <mru> those are not touched by the optimiser
[03:35:18] <mru> I suspect you have different amount of debugging symbols or similar
[03:36:10] <barspi> the point is:  by specifying my own —as line (and having the configure script respect that), the file is 2/3 the size of what I get when using the default hardcoded configure
[03:36:20] <barspi> everything else is the same
[03:36:32] <Compn> how did you come to the conclusion that smaller = more optimized ? lol
[03:36:43] <barspi> I'm not sure how all the internal stuff is working
[03:36:54] <Compn> you should benchmark it to see which is faster
[03:36:58] <barspi> in my particular case smaller == better
[03:36:59] <Compn> instead of guessing
[03:37:08] <Compn> and coming in here and guessing at that...
[03:37:29] <mru> there are two possible explanations:
[03:37:33] <barspi> it's like talking to a stone wall or some character form alice in wonderland
[03:37:37] <mru> 1) the smaller one is missing debugging symbols
[03:38:03] <mru> 2) the smaller one is missing large numbers of asm functions
[03:38:19] <mru> if 1, there's no problem
[03:38:23] <mru> if 2, you have a problem
[03:38:24] <barspi> I'm using exactly the same configure line in both cases (exactly the same enabled/disabled options)
[03:38:43] <mru> compare the final stripped binaries instead
[03:38:51] <Compn> well the configure line means nothing, you have to compare the configure.log
[03:38:58] <Sean_McG> does the apple linker do deadstripping?
[03:39:25] <barspi> the *only* difference is that by using the obligatory hardcoded —as   I get one file, and by using my own specified —as  I get a different result (a better one for my case, but that's besides the point)
[03:39:50] <barspi> the point being, if the user provides —as, let him have it
[03:40:02] * mru suspects the "better" one is failing and thus disabling all asm
[03:40:02] <barspi> if the user doesn't provide —as, do whatever you want in the script :-)
[03:40:45] <barspi> I'll test that suspiction later
[03:40:54] <Yuvi> Sean_McG: only with .subsections_via_symbols which the .S files don't set
[03:41:03] <barspi> in my particular case, i want small size, I don't care much about performance
[03:41:23] <Sean_McG> Yuvi: ah... yeah and I was thinking it's probably hard to deadstrip a library
[03:49:42] <Yuvi> astrange: looks like llvm-mc for arm doesn't really work at all
[03:50:59] <barspi> ok, for all the naysayers… I've hardcoded most stuff so the *aboslutely only difference is what I'm passing to gas-preprocessor.pl'
[03:51:05] <barspi> original configure script from git clone will do
[03:51:06] <barspi>   gas-preprocessor.pl /Developer/Platforms/iPhoneOS.platform/Developer/usr/bin/gcc-4.2 -arch armv6
[03:51:06] <barspi> libavcodec.a size 944K
[03:51:18] <barspi> hardcoding the variable gas to what I wanted:
[03:51:19] <barspi>   gas-preprocessor.pl /Developer/Platforms/iPhoneOS.platform/Developer/usr/bin/arm-apple-darwin10-gcc-4.2.1
[03:51:19] <barspi> libavcodec.a size 625K
[03:51:34] <barspi> . . . *everything else* is equal. the only difference is the parameter to gas-preprocessor.pl
[03:51:35] <barspi> Will both versions *perform* with equal speed/cpu consumption?  I'll tell you in a while  :-)
[05:35:12] <barspi> http://xkcd.com/386/
[05:51:55] <bcoudu> yo guys
[05:52:17] <bcoudu> who is motivated to write some code to compute the poc in the h264 raw demuxer ? :)
[05:53:37] <_av500_> poc?
[05:54:17] <Dark_Shikari> bcoudu: what do you need poc for?
[05:54:27] <bcoudu> compute the pts
[05:54:42] <Dark_Shikari> why do you need to compute it?
[05:54:45] <Dark_Shikari> just call the header parser
[05:54:47] <bcoudu> stream copy
[05:54:53] <Dark_Shikari> call the header parser
[05:55:01] <Dark_Shikari> doesn't it already do that?
[05:55:08] <bcoudu> nope
[05:55:15] <_av500_> i guess he wants the reordering
[05:55:28] <bcoudu> I guess the parser could do it
[06:07:13] <thresh> moroning
[06:16:55] <_av500_> (good morning
[06:28:23] <kshishkov> mate!
[06:28:52] <pross-au> G'day
[06:29:58] <kshishkov> where's an updated patch, I'm eager to have official BIK-b support
[06:30:31] <_av500_> kshishkov: but what are we going to talk here about then?
[06:30:56] <kshishkov> DNF is not released yet
[06:31:06] <_av500_> but soon, no?
[06:31:29] <kshishkov> and there are some other game video codecs - from Z for example
[06:31:58] <drv> bink B has different audio too IIRC
[06:51:25] <thresh> _av500_: what max bitrate would you suggest for 720p h264 on 101?
[06:51:52] <thresh> bloody thing is slow with raw h264 mp4 from my camera :)
[06:54:50] <_av500_> thresh: is your cam 60fps?
[06:54:52] <_av500_> some are
[06:54:56] <_av500_> thats too much
[06:55:11] <thresh> _av500_: well it can shoot in 60fps, but i'm using 720p at 30
[06:55:19] <_av500_> thresh: its not only bitrate, also the tools
[06:55:24] <_av500_> and num ref frames and such
[06:55:50] <thresh> I see, I'll doublecheck the params
[06:59:27] <elenril> lol at today's xkcd
[06:59:30] <elenril> also morning
[07:11:48] <thresh> _av500_: yeah a tiny bit slow with 8000kbit/s Video: h264, yuv420p, 1280x720 [PAR 1:1 DAR 16:9], 8029 kb/s, 29.97 fps, 29.97 tbr, 90k tbn, 59.94 tbc
[07:12:00] <thresh> I wonder if VLC would be better
[07:12:06] <thresh> oh wait there is no VLC :(
[07:22:23] <superdump> ?
[07:26:32] <thresh> superdump: there is not VLC for google evil OS
[07:26:49] <thresh> -t
[07:28:26] <superdump> ah
[07:28:57] <superdump> well i assume that it is possible to build an apk for personal use
[07:31:28] <av500> thresh: less mbit please
[07:31:46] <av500> thresh: j-b is working on vlc for evilOS
[07:31:57] <av500> but it wont use the dsp and stuff
[07:32:37] <thresh> iKnow
[07:34:18] <thresh> well they said there is an API to use OpenMAX, but barely documented
[07:45:40] <ubitux> i'm working on a XM demuxer/decoder, do you know if anyone is on it? and if no, if it's worth the effort?
[07:46:24] <ubitux> (fasttracker II, some kind of common mid)
[07:56:42] <siretart> ubitux: wow, that reminds me of old times...
[07:57:01] <siretart> ubitux: IIRC, there was a GSoC project for midi/tracker files
[07:57:12] <ubitux> oh?
[07:57:18] <ubitux> and what comes out?
[07:57:25] <av500CDGS> nuthin
[07:57:27] <siretart> sorry, I didn't follow it
[07:57:47] <av500CDGS> the amiga asm code converted to C never made it into any repo
[07:58:57] <ubitux> i'm worried about a few things, especially that kind of things: The above formulas DO work as long as you don't replace "*2^" by "shl" (the result of 2^(...) is a floating point number).
[07:59:13] <av500CDGS> run
[07:59:15] <ubitux> (formula is: Frequency = 8363*2^((6*12*16*4 - Period) / (12*16*4)))
[07:59:29] <ubitux> but well, i want to do it :p
[07:59:42] <av500CDGS> ubitux: you need to have libavseq 1st
[07:59:53] <av500CDGS> ubitux: its all on the mailing list from last summer
[08:00:37] <av500CDGS> ubitux: http://lists.mplayerhq.hu/pipermail/ffmpeg-soc/2010-July/009403.html
[08:01:29] <ubitux> mmmh ok
[08:02:13] <ubitux> i just wanted to support XM but i guess it won't be accepted with a proper libavsequencer integration in parallel?
[08:04:27] <siretart> ubitux: I guess that depends. and surely nobody would mind if you would develop it in a developer branch/repository
[08:06:17] <av500> ubitux: well, the gsoc guy had like million lines of code that he wanted to dump into ffmpeg, so having it all restructured and put into a proper lib was the only way
[08:06:34] <spaam> av500 ubitux : with avseq. ffmpeg source code will be twice the size..
[08:06:50] <av500> spaam: if you add all the different formats, yes
[08:07:06] <spaam> av500: ofc.
[08:07:17] <spaam> we cant leave some formats alone. ;)
[08:07:25] <spaam> :)
[08:10:01] <spaam> ubitux: and basty did have a amiga group called CDGS.. he was the only member.
[08:11:10] <ubitux> well… is it worth the effort trying to get libavseq upstream so i can add just a xm format?
[08:11:26] <ubitux> i don't think there is much point in trying to add more than midi and xm
[08:11:35] <av500> what about MOD?
[08:12:02] <ubitux> i don't know
[08:12:28] <spaam> ubitux: https://github.com/BastyCDGS/ffmpeg-soc/tree/master/libavsequencer
[08:12:36] <spaam> his code
[08:12:47] <ubitux> yes i saw that
[08:13:15] <ubitux> av500: well yeah maybe, there are 1538 XM and 375 MOD in the keygenmusic pack
[08:13:39] * av500 has no idea about procedurally generated music
[08:18:24] <kshishkov> av500: it's called MPEG-4 SAOL
[08:18:52] <kshishkov> IIRC reference implementation reads input and generates C program for generating output
[08:19:32] <av500> damn, so we need ffcc before we can implement it
[08:24:15] <kshishkov> not necessarily - we can just use some bytecode
[08:28:45] <thresh> epic fail for nokia today
[08:30:08] <kshishkov> after epic success yesterday?
[08:30:20] <thresh> not really
[08:30:30] <thresh> they dumped meego and going for windows phone
[08:30:47] <kshishkov> first part is epic success, the second is epic fail
[08:31:07] <thresh> well almost anything is better than windows phone
[08:31:08] <av500> what is epic success?
[08:31:17] <kshishkov> ditching meego
[08:31:30] <av500> ture
[08:31:32] <av500> true even
[08:32:23] <cartman> moin
[08:32:31] <kshishkov> grüß dich
[08:32:50] <kshishkov> cartman: and when you greet KotH use word "moinli"
[08:34:12] * kshishkov lols at todays Dilbert
[08:34:30] <cartman> KotH: günaydın!
[08:34:47] <cartman> lol indeed
[08:34:58] <kshishkov> cartman: he's in .ch, use "günaydınli"
[08:35:03] <cartman> :D
[08:40:52] <spaam> kshishkov: how does it go with rewrite of rm*.c? :)
[08:42:44] <kshishkov> spaam: only rm rm*.c works for a moment
[08:46:19] <spaam> maybe you should add "buffering..." stuff in the code.  then everything should work? :)
[08:47:26] <j-b> waouw -mt is getting merged? FFX 4 is going out soon, with DNF mode, too?
[08:49:10] <thresh> j-b: some say ffmpeg devs heard about Duke Nukem Forever coming out, and they wanted to be faster in merging -mt
[08:49:38] <j-b> thresh: there are no other rationale explanation
[08:50:13] <kshishkov> since DNF release was a major deadline term we should see a lot of activity soon
[08:50:24] <KotH> günaydin arkadaslar!
[08:50:35] <spaam> kshishkov: working rm stuff ? ;D
[08:51:01] <KotH> can someone help a blind man find the documentation of the gas .code directive?
[08:52:02] <kshishkov> spaam: not even thinking about it
[08:52:57] <spaam> KotH: ask our wonderful friend MÃ¥ns
[08:53:12] <spaam> kshishkov: come on. you can get a trocadero for it ;)
[08:54:06] <KotH> spaam: the blind man found it himself after stumbling in the dark for hours
[08:54:26] <kshishkov> spaam: unlikely. Though I'd like to come and buy some at any Hemköp/ICA/Coop/Prism/whatever
[09:02:38] <cartman> KotH: do you know Adnan Hodjca?
[09:02:43] <cartman> s/c//
[09:02:55] <KotH> nope
[09:03:04] <cartman> KotH: Harun Yahya?!
[09:03:08] <KotH> though i think i've heard the name somewhen
[09:03:17] <cartman> the man who denies the Darwin and evolution
[09:03:30] <KotH> ah.. now that rings a bell!
[09:03:41] <cartman> KotH: http://alkislarlayasiyorum.com/icerik/43884/
[09:03:46] <av500> cartman: the email client? it exists!!!
[09:03:59] <cartman> av500: he is now an email client too? :D
[09:04:12] * KotH will watch taht at home
[09:04:26] <cartman> its an mp3 ;)
[09:04:52] <spaam> astrange: gj with -mt btw :)
[09:16:45] <spaam> BBB astrange : whats left to get h264-mt stuff commited? :)
[09:21:22] <cartman> nice
[09:21:26] <cartman> all VP8 tests broken
[09:22:20] <Dark_Shikari> just on clang?
[09:22:42] <cartman> seems so
[09:24:01] <cartman> now to debug that ahem
[09:36:35] <cartman> Dark_Shikari:
[09:36:38] <cartman> its your commit
[09:36:47] <cartman> VP8: optimized mv prediction and decoding
[09:37:08] <saintdev> STRING HIM UP
[09:37:09] <saintdev> =P
[09:37:10] <Dark_Shikari> I know.
[09:37:19] <cartman> bisect rocks :P
[09:37:20] <Dark_Shikari> It's not my fault that a shitty compiler fails on my nice patch.
[09:37:24] <Dark_Shikari> Er, you didn't need bisect
[09:37:28] <Dark_Shikari> I figured that out in 7 seconds
[09:38:05] <spaam> cartman: 2slow
[09:38:07] <cartman> Dark_Shikari: nice now fix it
[09:38:12] <cartman> clang is not your mom's compiler
[09:38:14] <Dark_Shikari> I could care less about clang
[09:38:23] <Dark_Shikari> get clang devs to fix the bugs in their compiler
[09:38:25] <cartman> nice attitude
[09:38:36] <Dark_Shikari> nobody actually compiles ffmpeg with clang
[09:38:38] <Dark_Shikari> so it's not a user-facing issue
[09:38:40] <cartman> huh?
[09:38:40] <cartman> wtf
[09:38:44] <cartman> even mru does
[09:38:48] <Dark_Shikari> Sure, for FATE
[09:38:50] <Dark_Shikari> Not for real usage
[09:38:51] <bilboed-tp> or file a bug report with clang/llvm
[09:38:59] <Dark_Shikari> I'll leave it to a clang-related person to fix.
[09:39:06] <Dark_Shikari> I don't even have it installed.
[09:39:07] <cartman> sigh
[09:39:13] <Dark_Shikari> And installing clang on win32 is probably hard
[09:39:17] <Dark_Shikari> I don't think I could get it to work last time I tried
[09:39:21] <cartman> ok
[09:39:36] <Yuvi> near_mv isn't guaranteed to be 32-bit aligned
[09:39:57] <Dark_Shikari> yes it is
[09:40:00] <Dark_Shikari> typedef struct { int16_t x; int16_t y;
[09:40:01] <Dark_Shikari> } DECLARE_ALIGNED(4, , VP56mv);
[09:40:10] <Yuvi> ah
[09:49:33] <Dark_Shikari> does AV_RN/etc use alias intrinsics on clang?
[09:49:52] <superdump> mru: re: those rockbox patches - i think one can run configure through the Android.mk
[09:51:11] <Yuvi> I don't think llvm has aliasing optimizations that would break even *(uint32_t*)
[09:53:08] <av500> superdump: i guess you could touch a .configured or so
[09:57:42] <pross-au> CD pross-au
[09:57:48] <pross-au> oops
[09:59:07] <kshishkov> bink?
[10:01:40] <pross-au> Ah, yes, i gotta run another test
[10:01:49] <pross-au> i have incorporated your changes ksh
[10:02:27] <pross-au> whats this about bink-b audio?
[10:02:47] <kshishkov> dunno
[10:03:52] <kshishkov> I don't remember having any problems with audio there
[10:04:59] <pross-au> How does it feel, to be the King Bink
[10:06:09] <kshishkov> good - we beat RAD tools by the number of supported Bink versions :)
[10:06:56] <pross-au> to be fair
[10:07:02] <pross-au> there are dct coefficient overflows
[10:07:03] <kshishkov> and it supports our reputation as ultimate game video convertor
[10:07:09] <pross-au> (which im working on)
[10:07:14] <kshishkov> yay!
[10:07:56] <Tjoppen> what other interesting game formats are left?
[10:08:03] <kshishkov> tons
[10:08:05] <pross-au> Yeah finnishing off the Z video decoder is important to me
[10:08:23] <av500> kshishkov: what about the Pong game format?
[10:08:52] <kshishkov> pross-au: aha, incoming/bink/NWCLOGO.BIK has totally scrambled sound
[10:08:53] <av500> can ffmpeg play that pong sound when you feed it the wikipedia article about it?
[10:09:13] <kshishkov> av500: why should it?
[10:09:30] <pross-au> kshishkov: okay
[10:09:32] * kshishkov remembers we don't have 16-bit VQA support either
[10:09:55] <Tjoppen> the pixel format choosing logic for auto-inserted filters needs improving
[10:10:15] <pross-au> SMUSH
[10:10:29] <pross-au> ^ that's a popular format
[10:10:33] <Tjoppen> I just discovered that cropping uyvy422 causes ffmpeg to auto-convert the video to yuv420p rather than yuv422p
[10:10:34] <kshishkov> iKnow
[10:11:01] <kshishkov> pross-au: patch is on the list, hopefully I'll rewrite it with current coding standards in mind
[10:11:17] <kshishkov> and I want Discworld Noir cutscenes support
[10:11:19] <merbzt> Tjoppen: colorspace negotiation might be a NP complete problem :)
[10:11:22] <Tjoppen> similarly for mjpeg (and probably other codecs) where it prefers choosing yuvj420p rather than yuvj422p because the former is first in the pixel format list
[10:11:40] <pross-au> Cool
[10:11:51] <kshishkov> merbzt: it doesn't matter much
[10:11:57] <Tjoppen> merbzt: actually, no :)
[10:12:25] <Tjoppen> just pick whichever has the same or higher subsampling
[10:12:34] <Tjoppen> higher as in, prefer 4:4:4 to 4:2:0
[10:12:49] <Tjoppen> if 4:2:2 is unavailable
[10:13:23] <Tjoppen> there are corner cases I guess, like 4:2:0 vs 4:1:1
[10:15:01] <kshishkov> 420 is better
[10:18:11] <Tjoppen> depends on what your target codec is. but in that case maybe it'd pick the appropriate pixel format
[10:21:31] <kshishkov> yes, that's the case - format negotiations should be started from the last filter
[10:30:56] <Tjoppen> my use case is simple: crop vbi lines from uyvy422 rawvideo
[10:35:51] <Tjoppen> I suspect vf_crop.c shouldn't have much trouble handling that colorspace though, since it already handles rgba
[10:50:23] <Tjoppen> woo
[10:50:37] <Tjoppen> adding PIX_FMT_UYVY422 to vf_crop.c was enough :)
[10:51:47] <Tjoppen> I discovered a possible bug though - going via yuv422p caused the output to differ. shouldn't going uyvy422 -> yuv422p and back  just rearrange the bytes?
[10:52:22] <Tjoppen> a few pixels in each frame ended up with +-1 luma
[10:52:57] <merbzt> it probably took a detour through libswscale
[10:53:37] <Tjoppen> yes, I know that
[10:54:18] <merbzt> rm libswscale *
[10:54:18] <Tjoppen> question is, why did swscale mess up?
[10:54:39] * Tjoppen looks at swscale_template.c and cries a little
[10:55:22] <merbzt> I assume it actually performed a resample step
[10:56:37] <merbzt> and then rounding causing the diff
[10:58:12] <Tjoppen> makes sense
[10:58:22] <kshishkov> unlike swscale sources
[10:58:24] <Tjoppen> I presumme sws doesn't have regressions
[10:58:39] <kshishkov> it has
[10:58:48] <kshishkov> there is swscale-test.c
[10:59:10] <kshishkov> it calculates difference on different rescaling and/or converting operations
[10:59:33] <kshishkov> but it's "too long; didn't run" situation
[11:00:15] <kshishkov> and there's that lavf-pixfmt test probably
[11:00:30] <Tjoppen> I'd image it being very useful to make sure things like 8bit -> 16bit -> 8bit results in the same output. the same for repacking conversions like uyvy <-> 422p and uyyvyy <-> 411p
[11:01:07] <Tjoppen> but then again, I fear swscale isn't built to be able to easily plug in alternate algorithms for certain cases
[11:02:18] <kshishkov> s/to easily plug in alternate algorithms for certain cases//
[11:03:01] <Tjoppen> heh
[11:04:04] <kshishkov> I've dabbled a bit in its sources
[11:04:04] <Tjoppen> I was a little bit inspired to come up with a runtime optimization thing based on a paper me and a friend implemented for optimizing boolean operations on compressed binary indexes in databases. the ideas are similar
[11:04:44] <Tjoppen> it's a little hard to explain though.. but basically revolves around selecting appropriate formats in each step so cetains algorithms can be chosed
[11:04:47] <Tjoppen> *chosen
[11:05:02] <Tjoppen> then you choose between optimizing for speed or quality
[11:05:03] <kshishkov> patchiswelcome
[11:05:28] <Tjoppen> yeah, it's not happening any time soon :)
[11:05:41] <pross-au> AVPATCHISWELCOME
[11:05:46] <kshishkov> polish your Cinepak encoder then
[11:05:58] <kshishkov> pross-au: that's applicable to you as well
[11:06:35] <Tjoppen> well, a side project I have now is to write an encoder for my atari video decoder. it outputs 128 colors at the amazing resolution of 8x6 pixels
[11:07:32] <Tjoppen> with self modifying code I might be able to cram it up to 10x8 or so
[11:07:57] <kshishkov> use RNG
[11:24:08] <Tjoppen> feeding the decoder with its own machine code produces intersting results
[11:29:03] <j-b> av500: http://magsoft.dinauz.org/videolan/vlc-android/vlc-android-archos101.3gp
[11:33:49] <av500> j-b: nice!!!!
[11:34:10] <av500> please make sure you use only this product for all publicity vids you make :)
[11:34:24] <av500> j-b: and please use the intent to hide the buttons
[11:34:38] <j-b> av500: well, this is very likely the reference board for us, so yes.
[11:34:49] <av500> :)
[11:34:56] <j-b> av500: and I couldn't understand your last sentence
[11:34:59] <j-b> intent?
[11:35:11] <av500> I gave you once what you need to do to hide our buttonbar
[11:35:15] <kshishkov> av500: do you have your players with non-glare screens?
[11:35:25] <av500> kshishkov: you can always sandblast them
[11:35:29] <j-b> av500: and I forgot :)
[11:35:32] * j-b is b ad
[11:35:40] <superdump> j-bad?
[11:35:51] <j-b> :)
[11:36:21] <superdump> it was good to finally meet you at fosdem j-b, though it was only brief and i don't think you really got my name as it was a big group
[11:36:32] <superdump> so perhaps s/meet/see/
[11:37:01] <j-b> I know your name and see who you are :)
[11:37:19] <superdump> then meet it is :)
[11:37:23] <av500> j-b: did you see Diego or you missed him again?
[11:37:44] <j-b> av500: I did!
[11:37:47] <j-b> incredible?
[11:37:54] <merbzt> I missed j-b :/
[11:38:04] <kshishkov> did he agree to proofread French in VLC sources?
[11:38:07] <merbzt> and f revol
[11:38:15] <j-b> kshishkov: :)
[11:38:22] <kshishkov> merbzt: Revol was at Haiku stand so no wonder
[11:38:42] <av500> he was waiting for ffmpeg to compile all the time
[11:38:59] <av500> j-b: see you pm and print and frame it
[11:39:03] <av500> your
[11:39:07] <kshishkov> j-b: I'm pretty sure we also talked at FOSDEM but were not properly introduced to each other
[11:39:31] <j-b> kshishkov: I'm French, i don't need "proper introduction" :D
[11:39:37] <j-b> av500: forwarded to the right guys
[11:40:06] <kshishkov> j-b: well, I consider any VLC guy to be French by default
[11:40:42] <bilboed-tp> don't they have some swiss, belgian and quebec people also ? :)
[11:40:53] <superdump> j-b: one time i was on-site with a french client and they did this thing where anyone visiting went around the whole room, said hello to and shook hands with everyone
[11:41:24] <av500> superdump: yes, they do that
[11:41:25] <j-b> kshishkov: lol. This isn't true. We have .de, .fi, .nl and .uk in the core team.
[11:41:26] <superdump> it was quite strange considering every single one of them were not seen again throughout the day
[11:41:47] <kshishkov> j-b: .de? As Jean-Paul .de?
[11:41:53] <av500> superdump: same when I visit our paris HQ, everybody comes in shakes hand in the morning
[11:42:09] <superdump> some people were abstaining because of swine flu :B
[11:42:16] <j-b> kshishkov: Felix
[11:42:22] <av500> while I just sit there any try to wake up
[11:42:36] <bilboed-tp> superdump, is that when they kiss instead of shaking hands ?
[11:42:48] <superdump> bilboed-tp: french kiss!
[11:43:03] <bilboed-tp> no, not that one
[11:43:07] <bilboed-tp> the cheek kiss
[11:43:09] <bilboed-tp> la bise quoi
[11:43:37] <j-b> av500: they will add it to the next build
[11:43:51] <superdump> j-b: is there some semi-offical vlc ppa for ubuntu?
[11:44:15] <j-b> superdump: https://launchpad.net/~videolan/+archive/master-daily ?
[11:44:15] <kshishkov> superdump: ask next about autotools
[11:44:50] <superdump> ha
[11:45:26] <superdump> j-b: i mostly wanted 'most recent release as ubuntu's package is out of date'
[11:45:33] <superdump> but hey, dailies will do
[11:46:03] <j-b> superdump: sudo add-apt-repository ppa:n-muench/vlc will get the stable version
[11:46:18] <superdump> ta
[11:48:17] <uau> superdump: are you doing some kind of player comparison?
[11:49:05] <superdump> i just find that it is useful to have multiple players around when testing stuff
[11:49:08] <superdump> not using it right now
[11:53:41] <uau> btw does any player other than mplayer2 use ffmpeg frame discarding functionality for exact seeks?
[11:53:55] <uau> adding the exact seek support uncovered a bug in ffmpeg-mt at least
[11:54:53] <bilboed-tp> what do you mean  by "frame discarding functionality" ?
[11:55:53] <av500> seek to non-iframe I guess
[11:56:04] <uau> bilboed-tp: the skip_frame field, to speed up decoding from keyframe to the target frame
[11:56:07] <av500> seek to previous iframe and drop all frames up to ...
[11:56:20] <j-b> uau: vlc --ffmpeg-skip-frame
[11:56:26] <bilboed-tp> uau, yah, we use it in gst-ffmpeg, works fine
[11:57:37] <bilboed-tp> oh wait, no
[11:59:43] <uau> j-b: that's constantly-on framedrop?
[12:00:33] <uau> with probably really ugly result as frames are dropped at an uneven rate?
[13:05:00] <CIA-38> ffmpeg: Peter Ross <pross at xvid.org> master * re00f41d574 ffmpeg/ (5 files in 3 dirs):
[13:05:00] <CIA-38> ffmpeg: Bink version 'b' video decoder
[13:05:00] <CIA-38> ffmpeg: Based on original patch by Kostya Shishkov
[13:05:00] <CIA-38> ffmpeg: Signed-off-by: Janne Grunau <janne-ffmpeg at jannau.net>
[13:05:10] <CIA-38> ffmpeg: Peter Ross <pross at xvid.org> master * radb1ad0d80 ffmpeg/libavcodec/bink.c:
[13:05:10] <CIA-38> ffmpeg: bink: reindent after last commit
[13:05:10] <CIA-38> ffmpeg: Signed-off-by: Janne Grunau <janne-ffmpeg at jannau.net>
[13:05:20] <jannau> kshishkov: bink-b pushed \o/
[13:05:28] <kshishkov> jannau: oink! thank you
[13:09:03] * Flameeyes laughs at all those people deluding themselves in thinking Nokia was interested in free software for freedom, or those who call for Nokia to bankrupt for "selling" to MS.
[13:09:20] * av500 joins in
[13:10:26] <Flameeyes> although I have to say it's bitter laughs
[13:10:42] <Flameeyes> mostly because these people think they can shape the world — without factoring in business sense and requirements
[13:23:55] <j-b> Flameeyes: well, the upside for MS is amazing, with almost NO risk. While for Nokia, the upside is more than limited...
[13:24:11] <Flameeyes> j-b: depends what you count as baseline
[13:24:30] <Flameeyes> baseline "what nokia promised", yes there is little upside, same goes for "how nokia appears to kde guys"
[13:24:51] <Flameeyes> but baseline "what nokia really is" and "how common people feel about nokia", upside is far from limited
[13:25:30] <j-b> Flameeyes: oh, I don't care about FOSS here. At ALL.
[13:25:38] <Flameeyes> seriously, they obsoleted an €650 phone in three months?
[13:25:52] <mru> cartman: vp8 tests pass with clang -O1, fail with -O2
[13:26:04] <j-b> Flameeyes: Nokia wins almost nothing from a WP7, which is a very very small platform. M$ Wins huge on that
[13:26:43] <Flameeyes> j-b: people like Nokia phones but hate the software... this will at least give them a chance
[13:26:50] <Flameeyes> but yes, I see that the next move might actually be a merger
[13:27:13] <cartman> mru: optimifail
[13:27:17] <kshishkov> and there was VLC for WinCE so j-b cannot care less
[13:27:39] <j-b> Flameeyes: well, they didn't even managed to force M$ to allow native code and the ovi store...
[13:27:47] <j-b> kshishkov: there still is. Just no interface.
[13:27:53] <mru> cartman: could still be an ffbug
[13:28:06] <cartman> mru: sure :)
[13:28:52] <Flameeyes> j-b: not sure how bad would be for the ovi store to be missing, ya know
[13:30:14] <j-b> Flameeyes: well, they just killed the whole ecosystem, while they could have asked for some counterparts
[13:30:44] <av500> Flameeyes: obsoleted what 650€ phone?
[13:30:46] <Flameeyes> j-b: I think for Nokia was either that or filing for bankrupcy
[13:30:47] <av500> the n900?
[13:30:49] <Flameeyes> av500: E75
[13:31:00] <mru> the n900 was obsoleted in 3 weeks
[13:31:11] <thresh> +1
[13:31:12] <av500> Flameeyes: why is it obsolete?
[13:31:28] <jannau> symbian is dead
[13:31:30] <j-b> Flameeyes: bankrupcy? I hope you are kidding. Numbers are falling down, but are still high
[13:31:40] <j-b> jannau: and Meego too now
[13:31:50] <j-b> not that I particularly care
[13:31:54] <Flameeyes> av500: [beside the fact that it's bloody fragile] about three months after the italian release date, they released Ovi Maps... but it didn't cover E75 at all..
[13:31:54] <av500> Flameeyes: why is it obsolete?
[13:31:58] <mru> nokia will on making "feature phones" for teenagers
[13:32:02] <mru> +keep
[13:32:08] <Flameeyes> on the other hand they covered the much cheaper E72
[13:32:13] <av500> ic
[13:32:26] <Flameeyes> and the E75 was a failure under many povs
[13:32:29] <av500> but that sounds like typical $random phone maker decision
[13:32:41] <Flameeyes> that's the typical Nokia decision
[13:32:50] <jannau> s/phone maker/big company/
[13:33:00] <j-b> +1
[13:33:15] <j-b> av500: doesn't change much for us... Android is the clear winner
[13:33:29] <thresh> but it sucks
[13:33:37] <av500> j-b: I did you fear for VLC at all :)
[13:33:40] <mru> android sucks less with each update
[13:33:51] <av500> so its like windows :)
[13:33:56] <mru> and apple are clearly afraid of it
[13:34:05] <mru> apple are safe of course
[13:34:08] <j-b> av500: I don't fear for VLC. Why should I?
[13:34:10] <mru> they have their loyal fans
[13:34:26] <av500> j-b: [14:33:15] <j-b> av500: doesn't change much for us
[13:34:42] <thresh> I only have 2.2 on this device
[13:34:48] <thresh> youknowho, gimme 3.0 :P
[13:35:07] <j-b> av500: yes, not much changes so, I can't fear.
[13:35:19] <j-b> av500: and this isn't even my $day_job
[13:35:27] <j-b> even though i would love to
[13:37:58] <av500> thresh: again, ask your russian hacker friends to get us the source code
[13:40:06] <thresh> :)
[13:47:45] <Kovensky> kshishkov: that "nice formatting" thing on the rockplayer patch looks like code my C professor writes
[13:48:20] <kshishkov> Kovensky: probably I won't trust him either
[13:48:24] <mru> Kovensky: you should've seen the code mine wrote
[13:48:42] <av500> mine looked all like pascal, wait, it was pascal
[13:48:45] <Kovensky> well, that's when he didn't accidentally write pascal instead :>
[13:48:45] * elenril summons some reviews
[13:48:47] <mru> he placed all braces and semicolons to the far right
[13:48:56] <Kovensky> av500: lol
[13:49:04] <elenril> which one is right......oh wait, what?
[13:49:18] <mru> if (foo)                            {
[13:49:24] <mru>     bar();                          ;
[13:49:30] <mru>                                      }
[13:49:31] <mru> etc
[13:49:43] <mru> actually, he'd fold the ;} onto one line
[13:49:45] <Kovensky> av500: mine wrote for loops with the index starting at i and ending at <= length (yes he wrote past the end of the array and left the first entry unused, and yes he didn't believe me when I told him that was invalid and would crash on a non-debug build if he was unlucky enough)
[13:50:06] <Kovensky> actually, a crash would've been lucky :)
[13:50:06] <mru> smells like fortran
[13:50:18] <elenril> also are we merging lavco or what?
[13:50:30] <elenril> it's conflicting with my lavf api cleanups
[13:50:36] <av500> yes, we are merging libavcodec with windows phone 7
[13:50:41] <Kovensky> int i, a[8]; for (i = 1; i <= 8; i++) { a[i] = 0 } // <-- enjoy your infinite loop \o/
[13:50:46] * elenril merges av500 with /dev/null
[13:50:49] <Kovensky> wait, forgot a semicolon
[13:50:56] <av500> elenril: no space left on device
[13:51:12] <elenril> av500: chapter muxing for asf where
[13:51:18] <av500> here?
[13:51:23] <elenril> send patches!
[13:51:24] <mru> Kovensky: on a boring day I made an emacs function to reformat code in that weird style
[13:51:27] <mru> and back
[13:51:53] <Kovensky> 10:49.44 Kovensky: av500: mine wrote for loops with the index starting at i <-- er, starting at 1
[13:52:16] <av500> Kovensky: for(i=i; .... is much more fun
[13:52:24] <Kovensky> mru: are you sure that wasn't Dev-C++'s doing
[13:52:34] <mru> I'm quite sure
[13:52:35] <Kovensky> mru: Dev-C++ can and does make weird formatting like that
[13:52:42] <Kovensky> it pretty much filters its indentation through rand()
[13:52:42] <mru> we talked about it
[13:52:48] <mru> he was even proud of it
[13:52:56] <mru> he was a bit quirky like that
[13:52:59] <mru> but a nice guy
[13:53:04] <Kovensky> lol
[13:53:17] <Kovensky> that C professor was also my class's Java professor
[13:53:32] <mru> http://hardwarebug.org/files/henrik.el
[13:53:35] <av500> mru: have that macro, I need to send a patch to -devel
[13:53:37] <Kovensky> last time I checked last year, my classmates still didn't properly know how to instantiate objects
[13:53:37] <mru> no idea if it still works
[13:53:47] <kshishkov> Kovensky: same with me but he knew both quite well
[13:53:48] <Kovensky> (the Java class was in 2009)
[13:54:14] <elenril> how do you improperly instantiate an object?
[13:54:29] <Kovensky> elenril: by not instantiating it for instance
[13:54:39] <av500> delete( new <object> );
[13:54:39] <kshishkov> mru: I think I can guess your professor's name
[13:54:48] <Kovensky> in C++ you get a class on stack with the default constructor, in Java you get a null reference
[13:55:08] <Kovensky> talking about C++, I really cringed when he showed that Borland abomination and said that was C++
[13:55:19] <Kovensky> sure, it might have been C++'s syntax, but it was just Delphi with a different syntax
[13:55:43] <kshishkov> well, it was decent C++ before Builder
[13:55:52] <Kovensky> the thing is, he didn't say that syntax was C++, he said the thing itself was C++, and that the major advantage of C++ over C is that you can write GUI programs in it and not in C
[13:55:56] <kshishkov> (as much as C++ can be decent of course)
[13:56:33] <Kovensky> my classmates also insist that netbeans and dev-c++ are compilers and still didn't understand what an IDE is after years of me trying to correct them
[13:56:55] * mru still does not understand what an IDE _does_
[13:57:10] <mru> an IDE _is_ annoying, that I know
[13:57:12] <Kovensky> look cute
[13:57:14] <j-b> autocomplete
[13:57:24] <Kovensky> and have a button to compile
[13:57:25] <elenril> poor man's regexps
[13:57:33] <thresh> mru: that's how everyone else call that OS you're using to do everything
[13:57:35] <Kovensky> without having to deal with scary makefiles and compiler commands
[13:57:49] <bilboed-tp> the whole point of an IDE is to hide all the warnings that a compiler will give you
[13:57:49] <Kovensky> Eight Megabytes And Constantly Swapping <-- lol
[13:58:08] <mru> escape meta alt control shift
[13:58:13] <cartman> lets you do clipboardinheritance
[13:58:18] <mru> emacs makes any computer slow
[13:58:31] <Kovensky> I lost my .emacs.d :(
[13:58:35] <Kovensky> too lazy to remake it
[13:58:39] <mru> want mine?
[13:58:45] <Kovensky> sure
[13:58:50] <mru> I'm not
[13:58:50] <Kovensky> does it have a nice cperl-mode setup btw?
[13:58:53] <kshishkov> make EMACS regenerate it
[13:58:54] <cartman> mru: github it
[13:59:02] <mru> it has weird stuff in it
[13:59:09] <cartman> mru: its emacs
[13:59:10] <cartman> doh
[13:59:12] <Kovensky> mine also had lots of cruft =p
[13:59:27] <lu_zero> btw
[13:59:30] * Kovensky is using vim for now
[13:59:38] <lu_zero> you should really provide the configuration for emacs
[13:59:50] <lu_zero> and I should put somewhere the bare conf for vim
[13:59:53] <Kovensky> vim's vimrcexample is almost perfect, you just need to add the tab setup lines
[14:00:06] <Kovensky> well, I also set nobackup
[14:00:07] <kshishkov> Kovensky: did your .emacs.d contain ELisp reimplementation of vim?
[14:00:08] <lu_zero> Kovensky: and the space cleaning function
[14:00:33] <mru> space cleaning hack: enter and exit picture-mode
[14:02:26] <Flameeyes> isn't there already a .dir-settings.el?
[14:02:33] <Orphis> Alright, cygwin is just made of fail
[14:02:45] <lu_zero> Orphis: sadly ^^;
[14:03:06] <Kovensky> I still prefer cygwin to anything else on windows just because of properly supporting unicode filenames :(
[14:03:23] <Orphis> When something is mysteriously not working occasionnaly, there's no one to help or anything
[14:03:46] <Orphis> I get a "vfork: resource not available" occasionnaly
[14:04:20] <Kovensky> try closing everything cygwin-related, opening \cygwin\bin\ash.exe and running rebaseall in it
[14:04:45] <cartman> and peflagsall
[14:04:50] <Kovensky> I usually have to do that on new installs, specially if I install / use python because for some reason it ships python pre-broken and you need to rebase the dlls to fix it
[14:09:46] <Zor> elenril: can I pull a specific commit from another repo into my own in git? (JEEB says to harass you)
[14:10:20] <Orphis> I've did that a few times already
[14:10:31] <Orphis> But it doesn't fix it
[14:10:36] <Kovensky> Zor: yes
[14:10:44] <Kovensky> Zor: git cherry-pick <commit hash>
[14:10:58] <Kovensky> if you have that repo as one of your remotes and it is fetched, git will find the commit in it
[14:11:10] * elenril promotes Kovensky to his spokesperson
[14:11:32] <Kovensky> `git remote add -f remote_name git://address` <-- to add and automatically `git fetch` a new remote
[14:11:38] <Zor> Kovensky: excellent
[14:11:40] <Zor> thanks
[14:13:39] <j-b> kierank: "Each project gets 500 visitor tickets for free"
[14:14:18] <av500> lol
[14:14:26] <av500> sell them and you can have a $big booth
[14:15:15] <j-b> you are more evil than a Frenchman
[14:15:42] <kshishkov> j-b: was that a compliment?
[14:19:52] <lu_zero> kshishkov: obviously
[14:24:48] <j-b> av500: 34EUR /ticket? seriously?
[14:28:30] <av500> its a serious, professional trade show
[14:29:43] <CIA-38> ffmpeg: Stefano Sabatini <stefano.sabatini-lala at poste.it> master * raa8ac53b51 ffmpeg/doc/filters.texi:
[14:29:43] <CIA-38> ffmpeg: Update overlay documentation after movie syntax update.
[14:29:43] <CIA-38> ffmpeg: Overlay documentation is still using the old unsupported syntax.
[14:29:43] <CIA-38> ffmpeg: Signed-off-by: Mans Rullgard <mans at mansr.com>
[14:30:31] <kshishkov> av500: 206bit?
[14:30:42] <mru> 26-bit
[14:31:03] <j-b> ok, "vbv-delay" patch status?
[14:31:23] <jannau> bikeshedding
[14:31:47] <mru> the correct solution is to make encoders output AVPacket and set it there
[14:31:51] <mru> but that's a lot of work
[14:32:00] <kshishkov> mru: that makes no sense. Even PDPs operated on 36-bit IIRC
[14:32:55] <j-b> jannau: pfff
[14:34:11] <kshishkov> j-b: unfortunately since the split time we don't have so great bikesheds :(
[14:37:18] <lu_zero> I'm not complaining a lot
[14:41:04] <Orphis> Kovensky: I still get the same error with cygwin
[14:41:18] <Kovensky> :S
[14:42:39] <Orphis> I think I'll be moving the build to a real linux box and transfer the binaries only to run the tests on Windows
[14:43:54] <kshishkov> http://www.mpegla.com/main/pid/vp8/default.aspx <- av500 rejoice!
[14:44:20] <lu_zero> kshishkov: what?
[14:44:26] <cartman> niceeee
[14:44:47] <mru> seriously, they're doing the right thing
[14:44:59] <cartman> it was about time
[14:44:59] <mru> if someone does have patents, they'll surface sooner or later
[14:45:07] <mru> better to encourage them to come forth now
[14:45:14] <av500> yes
[14:45:27] <lu_zero> and hammer them like wack-a-mole?
[14:45:32] * kshishkov remembers the reason why Archos players support VP8
[14:46:17] <cartman> kshishkov: why?
[14:46:34] <av500> because we pay H264 royalties :)
[14:46:38] <cartman> no patent thing?
[14:46:41] <cartman> av500: ah
[14:47:13] <cartman> must be royal pain in the ass
[14:47:15] <cartman> *giggle*
[14:47:21] * kshishkov wonders what would Firefox do when enough VP8 are gathered
[14:47:35] <cartman> back to MNG
[14:47:39] <mru> this should be fun
[14:48:04] <cartman> this is a such a fucked up day
[14:48:12] <cartman> even GTK+ 3 is released
[14:48:16] * mru trolls #vp8 with the link
[14:48:26] <cartman> mru: do what you are good at :D
[14:48:59] <mru> so we'll have nokia phones running gtk3 on winphone playing vp8?
[14:48:59] <j-b> kshishkov: oh, lol...
[14:49:10] <cartman> mru: who knows
[14:50:45] <Tjoppen> the w3c html5 workshop appearently considered h.261
[14:51:06] <Tjoppen> re: MNG
[14:51:07] <cartman> they considered VP3/Theora too
[14:52:07] <av500> I guess they considered ascii art too
[14:54:50] * kshishkov goes to asciimation.co.nz, blames av500
[14:56:23] <kierank> w3c could have considered bink
[14:56:49] <j-b> nut/ffv1
[14:57:16] <kshishkov> Snow+Sonic+NUT
[14:57:41] <av500> flash!
[14:57:51] <av500> they should have standardized flash
[14:58:21] * av500 smells API wars coming up
[14:58:38] <lu_zero> where?
[14:58:40] <lu_zero> and why?
[14:59:06] <spaam> on ml..
[14:59:08] <elenril> that would make a nice movie title
[14:59:23] <elenril> FFmpeg III: The API Wars.
[14:59:24] <lu_zero> spaam: which thread?
[15:00:11] <kshishkov> av500: well, it's all in SWF spec, open standard for what it worth. So Firefox may support FLV for <video>
[15:00:14] <spaam> lu_zero: "ABI and forkS" and/related to  "Pass VBV delay to the calling application via ctx"
[15:01:19] <kierank> kshishkov: what about the patents
[15:01:28] <Kovensky> some_struct *iter = &{ NULL, option_list }; // <-- is this even valid C?
[15:01:29] <lu_zero> yawn
[15:01:42] <kshishkov> kierank: Steve Jobs was right
[15:01:55] * kierank joins #vp8 to see the flames
[15:02:07] <kshishkov> Kovensky: looks like valid C++2010 at least
[15:02:12] * Kovensky joins kierank in joining
[15:02:21] <Kovensky> kshishkov: would gcc eat that from a .c file? =p
[15:02:26] <Kovensky> would clang?
[15:03:40] * Kovensky is trying to iterate through a linked list and thought that syntax as a way to make the "head" of the iterator on the stack
[15:03:52] <Kovensky> it looks valid to me, but you never know ._.
[15:04:08] <Kovensky> well, it doens't look valid, it looks like it should / could be valid =p
[15:04:29] <kshishkov> just try it
[15:05:30] <mru> that doesn't look like valid C
[15:05:50] <mru> some_struct *iter = (some_struct *){ stuff }; is valid
[15:07:01] <kierank> doesn't matter anyway. vp8 is still a niche product whatever.
[15:07:11] <Kovensky> mru: wouldn't that convert the struct itself to a pointer, instead of making a pointer to the struct?
[15:07:13] <mru> wrong, it's sub-niche
[15:07:27] <mru> Kovensky: what do you want to do?
[15:07:50] <Kovensky> some_struct is a linked list struct
[15:08:06] <Kovensky> I want to iterate through it but without special casing the first element
[15:08:35] <mru> I don't understand
[15:08:51] <Kovensky> hm, I'll just finish writing the loop then pastebin
[15:09:01] <Kovensky> then I can actually explain it
[15:09:14] <mru> maybe then you won't need to explain it
[15:09:30] <cartman> have a nice weekend!
[15:09:51] <Kovensky> or that
[15:09:51] <Kovensky> :>
[15:10:36] <kshishkov> mru: I'd call that unsweeped corner, not sub-niche
[15:10:56] * mru gets out the hoover
[15:11:04] * lu_zero calls it possible new and untapped market
[15:13:43] <kshishkov> lu_zero: where sane people don't dare to thread?
[15:34:24] <kierank> j-b: why did you call mpeg-la patent trolls?
[15:34:53] <j-b> kierank: because they are :D
[15:35:12] <j-b> for a broad definition of "patent trolls", but yes
[15:35:19] <kshishkov> j-b: they are patent troll middlemen
[15:36:17] <j-b> same business
[15:36:38] <mru> I don't see them doing any harm
[15:36:42] <kshishkov> j-b: nope, it's even better
[15:36:46] <mru> the patents are already there
[15:37:10] <kshishkov> mostly in H.264 pool
[15:41:19] <mru> BBB: please comment on my pending vp8 patches
[15:41:29] <mru> http://patches.ffmpeg.org/patch/755/
[15:41:34] <mru> http://patches.ffmpeg.org/patch/756/
[15:43:41] <BBB> don
[15:43:42] <BBB> done
[15:46:59] <mru> kshishkov: care to take a look at the first of those?
[15:47:06] <mru> you already acked the second one
[15:47:34] <kshishkov> asm seems to be the same as in third patch
[15:47:51] <mru> pretty much, yes
[15:48:00] <kshishkov> so ok with me
[15:52:20] <BBB> i think the whole nokia+wimo is funny
[15:52:41] <mru> kshishkov: here's a nice one: PLD [R0, R3]
[15:52:42] <BBB> so what's left of meego now? wasn't that the gnome desktop based on qt, or so?
[15:52:44] <mru> r0 and r3 are pointers
[15:53:27] <kierank> BBB: vp8 is even funnier
[15:53:58] <kshishkov> mru: it's funny if if makes any differences on certain CPU models
[15:54:02] <kshishkov> *if it
[15:54:11] <superdump> BBB: it rather seems that symbian will be scrapped, meego will continue to be developed for 'future platforms'
[15:54:31] <superdump> in short it seems that windows phone is a stopgap because they need to release some products and meego isn't ready
[15:54:43] <superdump> and i guess if meego doesn't prove itself, it too will be binned from the nokia side
[15:55:52] <BBB> superdump: that's exactly the problem
[15:56:07] <BBB> superdump: meego or maemo have been around for what, 8 years now?
[15:56:15] <BBB> they'll be dead-on-arrival
[15:56:20] <BBB> or won't arrive at all
[15:56:30] <superdump> yeah, but maemo/meego themselves weren't the problem from what i can tell
[15:56:46] <BBB> I'm not crazy, I'm an airplane!
[15:57:12] <superdump> the processes forced upon the developers due to being funded by nokia was the real problem
[15:57:42] <bilboed-tp> BBB, they haven't. maemo was started 6 years ago and it was restarted at least 3 times from scratch due to incompetent finish bureaucracy
[15:57:52] <bilboed-tp> BBB, hadn't they done that... we would have the dream platform by now
[15:57:55] <bilboed-tp> (sucks)
[15:57:57] <superdump> basically growing very large, trying to cope with it by developing features and shovelling them into lots of different but very similar products
[15:58:01] <av500> it was restarted again 6mo ago when they decided that native apps were bad
[15:58:23] <av500> and had to retool for QML+javascript
[15:58:28] <BBB> bilboed-tp: I started gradschool 6 years ago, and by then some certain company was already doing contract work on some platform for some finnish company
[15:58:41] <BBB> but doesn't matter
[15:58:44] * kierank doesn't care for mobile phones
[15:58:49] <kierank> best option
[15:59:03] <av500> http://qt.nokia.com/products/qt-quick/
[15:59:07] <BBB> what android and ios teach us is that stuff isn't built by dreaming things up. it's done by f&cking hard work :)
[15:59:19] <BBB> wimo is wonderful but _already_ too late
[15:59:25] <BBB> and then there's webos/meego :-p
[15:59:26] <superdump> + a metric fuckton of bureaucracy
[15:59:36] <bilboed-tp> it's bureaucracy that killed it
[15:59:40] <BBB> meego is just Yet Another Me-Too
[15:59:53] <kshishkov> BBB: postgrad students in .ua are supposed to produce thesis in 3 years after enrollment (and they study at the same time too)
[16:00:05] <BBB> kshishkov: doesn't that depend on the field?
[16:00:27] <kshishkov> BBB: 5 years for medical stuff IIRC
[16:00:28] <av500> BBB: post grad in agriculture have even less time
[16:00:34] <BBB> kshishkov: here math/economy is 3 years, biology is ~6 on average (I was 5 1/2 and the first in my program, and third or fourth in the whole year)
[16:00:37] <av500> so much for field work
[16:00:46] <kshishkov> av500: you mean "got your shovel"?
[16:00:53] <av500> yep
[16:02:10] <BBB> The Wall Street Journal is always right-on: "But the biggest loser is MeeGo, the ugly, unloved step child of operating systems."
[16:02:18] <BBB> gotta love those damn americans
[16:02:37] <BBB> "So MeeGo to No Go."
[16:04:06] <kshishkov> BBB: was wrong, 3 or 4 years at most for everybody
[16:04:29] <kshishkov> BBB: 4 years if you work somewhere else officially
[16:04:49] <BBB> PS, if Nokia is so big on "open video codecs" (weren't they or their contracters pimping theora 6 years ago?), and vp8 is the new open video future, then what does that mean for vp8 support in WiMo on Nokia phones?
[16:04:52] <BBB> bilboed-tp: ^^
[16:04:59] <BBB> I foresee a problem
[16:05:14] <bilboed-tp> what are you talking about ?
[16:05:36] <bilboed-tp> could you stop using double-entendre and express yourself clearly ?
[16:05:57] <bilboed-tp> N has never pushed open video codecs.
[16:05:59] <kshishkov> BBB: h.264 plugin of course
[16:09:40] <merbzt> bilboed-tp: not really true, they "pushed" for MVC
[16:10:18] <kierank> i wonder why mpeg-la is calling for an mvc patent pool when the codecs are shipping already
[16:10:32] <bilboed-tp> merbzt, you mean the 'heavily-patented extension to H264' ? Wouldn't call that 'open'
[16:10:39] <mru> no, not that one
[16:11:00] <bilboed-tp> in real news, mubarak finally stepped down
[16:12:42] <mru> I thought he'd hang on for another week
[16:13:13] <bilboed-tp> must have been the nokia/microsoft announcement that pushed him to leave
[16:13:44] <kierank> nah he saw the vp8 patent pool call
[16:13:55] <bilboed-tp> :)
[16:14:00] <BBB> mru: should I bother looking into clang 2.8 or just assume it's a compiler bug?
[16:14:08] <BBB> suse clang 2.9 works fine, it seems
[16:14:22] <BBB> I can't find any eays way to install clang 2.9 locally
[16:14:26] <mru> BBB: no, it hasn't built that rev yet
[16:14:27] <BBB> don't want to do too much effort
[16:14:34] <BBB> oh, I see
[16:14:43] * BBB goes try clang 2.8 then
[16:14:46] <BBB> let's see if it fails
[16:15:12] <BBB> wbs: ping :-p
[16:16:45] <BBB> co clang 2.8 doesn't support "pavgusb" in inline asm?
[16:18:39] <merbzt> bilboed-tp: not the extension, Nokia submitted their own codec as proposal for the H264 standardization process
[16:18:49] <bilboed-tp> ah
[16:18:56] <merbzt> thus open in that meaning
[16:19:13] <bilboed-tp> I thought you meant something theora like
[16:19:29] <mru> wasn't there a rumour that nokia had patents on theora?
[16:19:40] <av500> [17:17:10] <dwd> Robot101, On the plus side, Collabora should be able to take over Nokia in a couple of hours at this rate.
[16:19:48] <bilboed-tp> lol
[16:20:43] <bilboed-tp> nokia has so many patents... I'd be amazed they didn't have some on everything tech-related out there
[16:55:30] <mru> kshishkov: could you please ok the vp56 arm patch on the ml?
[16:58:59] <spaam> mru: i can do it ;)
[16:59:49] <kierank> spaam: stick to your traffic shaping
[17:00:45] <spaam> kierank: pfff  i dont do that kind of things..  our cutomers can do it if they want.. :P
[17:01:27] <kierank> ah so you're just shifting the responsibility
[17:01:27] <mru> is this another "guns don't kill people" speech?
[17:01:49] <spaam> kierank: i just help them to identify the traffic ;)
[17:02:02] <spaam> mru: nope.. kierank blame me for stuff.
[17:02:23] <mru> I don't pull the trigger, the firing squad does that... I only name the dissidents
[17:03:15] <spaam> im the good guy :)
[17:04:53] <spaam> time to go home :)
[17:08:04] <kierank> spaam: continue to kid yourself
[17:09:11] <av500> what traffic doth spaam shape?
[17:09:30] <BBB> oh hell this is painful
[17:09:36] <BBB> clang 2.8 doesn't support 3dnow inline asm
[17:09:40] <BBB> and I have to ifdef everything out
[17:09:47] <BBB> can't believe nobody ever noticed
[17:09:47] <mru> BBB: --disable-asm
[17:09:53] <mru> still triggers bug on 2.9
[17:11:40] <BBB> almost done
[17:11:44] <BBB> only swscale left now
[17:12:07] <mru> BBB: hunting that vp8 bug?
[17:12:50] <BBB> yeah
[17:13:07] <mru> build with --disable-asm
[17:14:03] <BBB> damnit
[17:14:08] <BBB> 2.8 doesn't trigger it either :-p
[17:14:20] * BBB goes consider if he wants to install 2.9
[17:19:36] <kshishkov> mru: okayed
[17:20:45] <CIA-38> ffmpeg: Mans Rullgard <mans at mansr.com> master * r7da48fd011 ffmpeg/libavcodec/ (arm/vp56_arith.h vp56.h):
[17:20:45] <CIA-38> ffmpeg: ARM optimised vp56_rac_get_prob()
[17:20:45] <CIA-38> ffmpeg: Approximately 3% faster on Cortex-A8.
[17:20:45] <CIA-38> ffmpeg: Signed-off-by: Mans Rullgard <mans at mansr.com>
[17:20:57] <CIA-38> ffmpeg: Mans Rullgard <mans at mansr.com> master * ra7878c9f73 ffmpeg/ (6 files in 3 dirs):
[17:20:57] <CIA-38> ffmpeg: VP8: ARM optimised decode_block_coeffs_internal
[17:20:57] <CIA-38> ffmpeg: Approximately 5% faster on Cortex-A8.
[17:20:57] <CIA-38> ffmpeg: Signed-off-by: Mans Rullgard <mans at mansr.com>
[17:22:15] <pJok> kshishkov, uh nice... bink b \o/
[17:22:57] <kshishkov> pJok: yes, it was the whole point
[17:28:12] * mru stabs over-commented code
[17:29:08] <pJok> mru, code can never me too commented...
[17:31:05] <mru> https://github.com/CyanogenMod/android_external_jpeg/blob/gingerbread/asm/armv7/jdcolor-armv7.S
[17:31:08] <mru> that code
[17:33:09] <mru> many of the comments are of course wrong
[17:36:28] <kierank> av500: what nationality wrote that code
[17:36:38] <kierank> you are the arbiter of these things
[17:36:54] <mru> the jpeg code?
[17:37:38] <kierank> yes
[17:37:47] <mru> no idea who wrote it
[17:37:51] <mru> it comes from qualcomm
[17:37:56] <mru> and it sucks
[17:38:24] <kierank> av500 can use magic to tell whether it was indian, chinese, american
[17:38:38] <mru> this looks american to me actually
[17:38:55] <mru> judging by the comment style
[17:43:55] <pJok> mru, you are right... too much commenty stuff
[17:49:34] * mru stabs ijg some more
[17:49:50] <mru> the trolls didn't include configure.{in,ac}
[18:10:38] <mru> BBB: figured it out
[18:12:28] <BBB> \o/
[18:15:12] * jannau too
[18:40:31] <BBB> mru: thanks, now it works as expected
[18:41:04] <spaam> av500: ppl use our products to  do stuff with their internet traffic ;)
[18:47:01] <CIA-38> ffmpeg: Mans Rullgard <mans at mansr.com> master * r4b884207eb ffmpeg/configure:
[18:47:01] <CIA-38> ffmpeg: configure: remove early check_deps $ARCH_EXT_LIST
[18:47:01] <CIA-38> ffmpeg: The early disabling of irrelevant arch extensions is no longer
[18:47:01] <CIA-38> ffmpeg: required, and removing it makes dependencies involving these
[18:47:01] <CIA-38> ffmpeg: work as expected.
[18:47:02] <CIA-38> ffmpeg: Signed-off-by: Mans Rullgard <mans at mansr.com>
[19:10:05] <KotH> .o0(where is cartman when you need him?)
[19:12:31] <pJok> KotH, out with kenny and the other guys?
[19:15:23] <KotH> how can he?
[19:15:26] <KotH> i need him!
[19:15:29] <KotH> now!
[19:15:30] <KotH> ^^'
[19:26:12] <lu_zero_> how
[19:28:35] <j-b> wbs: no idea what OS he is on
[19:30:07] <kierank> is there an interchange format for dvb subtitles
[19:32:37] <Tjoppen> mpegps?
[19:32:45] <mru> hardly
[19:32:55] <Tjoppen> ts it is then :p
[19:37:12] <kierank> well closed captions have scc files but dvb has nothing
[19:38:44] <Tjoppen> I tried googling around (no ffmpeg on this machine), but ts seems to be pretty much the only place where they're used? maybe I missed something?
[19:39:43] <mru> dvb == ts
[19:40:20] <kierank> rhozet seems to have made a .dvb file format for subtitle interchange
[19:40:56] <kierank> mru: there's also dvb in mp4
[19:40:58] <kierank> but nobody uses that
[19:41:04] <mru> kierank: that's still ts
[19:41:05] <Tjoppen> mru: yes, but surely there are other containers that can mux bitmap subtitles?
[19:41:10] <mru> ts wrapped in mp4
[19:41:17] <_av500_> mru: wow, that is well commented
[19:41:27] <mru> Tjoppen: dvb subs are not bitmap
[19:41:43] <mru> they are ridiculously complicated
[19:42:03] <Tjoppen> uhm.. aren't they the ones that are RLE:ed 2/4/8-bit bitmaps?
[19:42:11] <mru> that'd dvd
[19:42:16] <Tjoppen> aha
[19:42:50] <mru> dvb is an entire rendering system with embedded fonts and whatnot
[19:43:37] <mru> of course nobody ever uses more than about 1% of the capabilities
[20:00:39] <mru> why must everybody so totally misunderstand mpeg-la?
[20:01:02] <Dark_Shikari> hacker news seems to have gotten it right
[20:01:40] <mru> "MPEG LA – the patent pool organization that controls the H.264 video codec – is collecting patents for what can only be described as an attack on the competing VP8 codec"
[20:01:44] <mru> how wrong can it get?
[20:01:54] <mru> 1) they don't control anything
[20:02:05] <mru> 2) vp8 is not "competing" with them
[20:02:10] <kshishkov> mru: 1) wait till Stallman and Xiph awake
[20:02:17] <kshishkov> mru: 2) get tons of lulz
[20:02:30] <Dark_Shikari> mru: the top HN comments are not saying that
[20:02:37] <Dark_Shikari> only stupid people are saying that
[20:02:50] <mru> I know, but stupid people are in abundance
[20:02:58] <Dark_Shikari> They always are.  You can't get rid of them
[20:04:38] <_av500_> mru: you can spend ages just to explain what mpegla does
[20:04:41] <iive> isn't vp8 compete with h264?
[20:04:48] <mru> iive: possibly
[20:04:56] <mru> iive: but that doesn't mean it competes with _mpegla_
[20:05:14] <mru> mpeg-la will set up pools for any patented standard
[20:05:29] <mru> they don't care
[20:05:36] <pJok> mru, considering they pooled together for 1394, you're right about that
[20:06:28] <_av500_> we should get patents on bikeshedding and pool them in mpegla
[20:06:34] <mru> patent pools make life easier for both patent holders and licensees
[20:06:36] <iive> mru: the quote doesn't explicitly say they compete with mpegla. it allows correct interpretation.
[20:06:42] <_av500_> but we would never agree
[20:06:51] <mru> mpeg-la is just a middle-man who takes a cut of the transaction
[20:07:15] <_av500_> and its frakin 25cents....
[20:07:34] <BBB> wbs: if you could fix that, that'd be fantastic
[20:07:46] <BBB> wbs: otherwise I might revert your priv_data removal patch :-p
[20:07:48] <mru> given the patent system, the service they provide is well worth the cost
[20:08:14] <mru> imagine chasing down each of those hundreds of patents separately, then negotiating licensing terms with each
[20:08:17] <mru> nightmare
[20:08:23] <_av500_> yup
[20:08:39] <_av500_> and if you get sued, you cannot even reveal how much the others charge you
[20:08:44] <_av500_> with the pool you can
[20:08:51] <wbs> BBB: which will make lavf crash on all _normal_ rtsp streams, too, due to trying to free the RTSPStreams for mepgts
[20:08:52] <mru> the pool is open
[20:09:12] <mru> of course I'd much rather see the uspto shut down
[20:09:13] <BBB> wbs: only on mpegts streams, no? :-p
[20:09:18] <mru> but that's not going to happen anytime soon
[20:09:18] <_av500_> if a non pool patent owner sues you, the court can look at the pool and award damages
[20:09:28] <BBB> wbs: oh right, now on all - ohwell, double free doesn't crash
[20:09:31] * BBB runs
[20:09:34] <_av500_> if there is no pool, they can ask for anything
[20:10:31] <wbs> BBB: but yes, it should be quite solveable via AVStream->id, but do you have samples that I can try it on?
[20:10:47] <wbs> oh, now I see the mail too, thanks :-)
[20:14:24] <BBB> :)
[20:14:56] <Dark_Shikari> someone is trying to post a patch to ffmpeg-devel but they need the moderator to approve their subscription
[20:15:00] <Dark_Shikari> can someone do that?
[20:15:12] <mru> doen
[20:15:15] <mru> done even
[20:16:40] <bcoudurier> morning
[20:17:08] <Compn> how about readding michaelni to list admins? or you guys talk about that stuff in private ?
[20:18:40] <mru> we don't want trolls on the list
[20:18:53] <Compn> michaelni has said a few times he wouldnt unban gabu
[20:19:00] <mru> I don't believe that
[20:19:34] <Compn> well it sounds like you have issues then
[20:19:43] <mru> what other reason would he have for poking around the admin pages 5 minutes after gabu was put on moderation?
[20:19:45] <Compn> if you cant trust michael, who can you trust
[20:19:54] <iive> if he unbans gabu, you would have valid reason to keep him away from admin.
[20:20:00] <Compn> well he thought it was arpi
[20:20:01] <mru> prior to that, he hadn't touched for something like 6 months
[20:20:03] <mru> minimum
[20:20:03] <Compn> remember his confusion ?
[20:20:10] <Compn> because of the poorly written mail
[20:20:11] <iive> mru: to found out if arpi is banned. of course.
[20:20:23] <mru> yeah, right
[20:20:33] <mru> I'm not discussing this further
[20:20:38] <Compn> fair enough
[20:21:08] <Compn> cant say i didnt try...
[20:22:27] <BBB> elenril: can you ping patches directly? I don't know which ones are uncommitted, sorry
[20:22:39] <BBB> elenril: it's a little chaotic if you don't pay continuous attention :)
[20:23:02] <_av500_> BBB: the new system, it fails!
[20:23:09] <mru> elenril: please go over your patches in patchwork and make sure all actually committed ones are marked as such
[20:23:13] <mru> same for superseded
[20:23:24] <BBB> _av500_: yeah, we're all gonna die!!
[20:23:29] <_av500_> omg
[20:23:32] * _av500_ runs
[20:23:37] <Compn> is there a link to the patchwork somewhere on ffmpeg.org ?
[20:23:38] <BBB> there is no place to hide!
[20:23:44] <BBB> Compn: don't think so
[20:23:48] * Compn hasnt looked at it yet
[20:23:56] <Compn> where would you put something like that ?
[20:24:05] <BBB> dunno
[20:24:08] <BBB> maybe the developer section?
[20:24:14] <Compn> is roundup linked there ?
[20:24:16] <BBB> same place as a multimedia wiki link
[20:24:21] <BBB> yeah
[20:24:29] <Compn> patches welcome BBB
[20:24:31] <Compn> :P
[20:27:19] <BBB> Compn: /me lazy
[20:27:35] * Compn lazy too
[20:27:38] * elenril busy hating on solid state physics :/
[20:27:55] <BBB> lu_zero_: as for the "why this hack" - I don't actually remember :)
[20:28:02] <BBB> I'll try to dig in my memory
[20:31:55] <elenril> wow, an actually readable -map documentation
[20:32:12] <elenril> somebody commit that asap!
[20:32:32] <mru> I never bothered figuring out what -map does, so I can't review it
[20:33:21] <elenril> it does :magic:
[20:33:45] <mru> I know the general idea of what it does
[20:33:59] <mru> picking streams from inputs and assigning to outputs
[20:34:03] * Compn avoids -map , for fear of breaking something
[20:34:05] <mru> but the way it does it seems mostly random
[20:34:30] <mru> it's been years since I tried to use it
[20:34:36] <Compn> did ffmpeg get multiple input files yet ?
[20:34:40] <Compn> whered that patch go?
[20:34:44] <mru> it always had
[20:34:45] <Compn> or is that playlist related
[20:35:00] <Compn> oh really, what am i thinking then
[20:35:05] <mru> it used to have multiple outputs too, but someone broke that
[20:35:23] <Compn> ah nm, i'm dumb then
[20:38:06] <michaelni> <mru> what other reason would he have for poking around the admin pages 5 minutes after gabu was put on moderation?
[20:38:17] <michaelni> i did not poke around
[20:38:57] <michaelni> IIRC i got a mail from arpi that i interpreted that arpi was baned and i looked at the page and saw that iam not admin anymore
[20:40:01] <michaelni> anyway ive been disconnected from irc thanks to shitty lan cable for a moment, i hope ive not missed any important trolling
[20:40:07] <Dark_Shikari> don't think so.
[20:40:20] <Dark_Shikari> there's an interesting thread on the topic of signalling fps in vfr mode for x264.
[20:40:21] <michaelni> ill be back in 30min or so need to leave
[20:40:25] <Dark_Shikari> x264 uses fps to calculate level
[20:40:39] <Dark_Shikari> but in vfr mode, the fps gets set to 1 / timebase which is totally borked whne timebase is microseconds or whatever
[20:41:44] <Dark_Shikari> (it's probably lavc-api-related)
[20:42:32] <Compn> mru : oh, i meant concatenating files
[20:42:45] <bcoudurier> Dark_Shikari, what do you want as timebase ?
[20:42:56] <bcoudurier> and what's borked about it ?
[20:42:57] <Dark_Shikari> timebase should be the real timebase
[20:42:59] <Dark_Shikari> timebase is fine
[20:43:05] <Dark_Shikari> the problem is that ffmpeg sets fps to 1 / timebase
[20:43:08] <Dark_Shikari> thus, for a vfr stream
[20:43:10] <Compn> which mencoder has had for a while...
[20:43:11] <Dark_Shikari> fps is, say, 1 million
[20:43:29] <mru> what do you need to know? average frame rate?
[20:43:40] <bcoudurier> how do you specify the timestamps timebase using libx264
[20:43:57] <Dark_Shikari> You set timebase_num and timebase_den
[20:43:58] <Dark_Shikari> mru: we don't
[20:44:06] <Dark_Shikari> the problem is that:
[20:44:12] <Dark_Shikari> 1) an encoder must calculate the correct level before encoding starts.
[20:44:15] <Dark_Shikari> it can't go back and change it later
[20:44:24] <Dark_Shikari> 2) you've told the encoder the fps is 1 million
[20:44:33] <Dark_Shikari> 3) it uses this and says "no level can possibly match your stream" and defaults to 5.1.
[20:44:40] <Dark_Shikari> TECHNICALLY, peak fps would be most accurate.
[20:44:50] <elenril> Compn: send patches
[20:44:52] <Dark_Shikari> Practically, it'd be better to just do "25fps" than to say 1 million fps.
[20:45:05] <mru> naturally
[20:45:08] <bcoudurier> well actually I'd like the encoder to fail
[20:45:16] <Compn> elenril : there were concat patches
[20:45:29] <mru> chained ogg ftw
[20:45:34] <Compn> elenril : i'm trying to find out if they were rejected/reviewed whatnot
[20:45:37] <elenril> you mean the playlist ones?
[20:45:40] <BBB> ruggles: do you think you should also update the documentation for SSE2/SSE2SLOW in lavu/cpu.h?
[20:45:49] <elenril> they weren't very nice afaik
[20:45:50] <Compn> might be related to playlists , yeah
[20:46:02] * Compn wants playlist support too :)
[20:46:11] <bcoudurier> IMHO fps should not be set in that case
[20:46:16] <bcoudurier> but timebase should always be set
[20:46:16] * Compn not care about chained ogg tho
[20:46:23] <elenril> and from what i saw they weren't generic enough to be useful for stuff like matroska ordered chapters etc
[20:46:26] <bcoudurier> setting fps for VFR makes no sense to me
[20:46:34] <bcoudurier> or set it to the average
[20:46:48] <Dark_Shikari> bcoudurier: how is the encoder supposed to figure out the level to use?
[20:47:05] <Dark_Shikari> In 2-pass mode it could look at the stats, I guess.
[20:47:19] <bcoudurier> well if there are constraints it should require the level
[20:47:22] <Compn> Dark_Shikari : somewhat unrelated, should there be a limit to hte max fps ? e.g. no more 1million fps ?
[20:47:24] <bcoudurier> and if it cannot guess
[20:47:35] <bcoudurier> otherwise you could create invalid bitstreams
[20:48:04] <bcoudurier> do the h264 spec mention how to handle vfr ?
[20:48:12] <Dark_Shikari> Barely.
[20:48:15] <Dark_Shikari> At best, obfuscated.
[20:48:23] <Dark_Shikari> The level section talks constantly about framerate.
[20:54:46] <bcoudurier> :(
[20:58:46] <michaelni> Dark_Shikari, our API lacks a peak fps. But even if the av-encoder API had one i dont know how ffmpeg.c could set it without scanning the whole input file
[20:59:04] <Dark_Shikari> I know, I'm not asking for that
[20:59:13] <Dark_Shikari> I'm asking "if our input is VFR, and our timebase is crazy, what fps do we give the encoder"
[20:59:25] <Dark_Shikari> and what are the boundaries of "crazy"?
[20:59:32] <Dark_Shikari> is 100fps crazy? 200? 1000?
[20:59:50] <michaelni> AVStream.r_frame_rate
[20:59:59] <Dark_Shikari> what is that?
[21:00:01] <Dark_Shikari> i.e. what does it represent
[21:00:20] <michaelni> best guess of the least crazy timebase that can represent all frames exactly
[21:00:34] <michaelni> its a guess aka it can be wrong
[21:00:57] <Dark_Shikari> how is it calculated ?
[21:01:09] <michaelni> see av_find_stream_info
[21:01:11] <Dark_Shikari> what is it typically?
[21:01:36] <michaelni> typically like 25 or 30 or 24000/1001 or so
[21:01:44] <michaelni> but as said it can be nonsense too
[21:01:47] <Dark_Shikari> hmmph
[21:01:50] <michaelni> like 1000000
[21:02:00] <Dark_Shikari> But wait.  the encoder doesn't know the avstream.
[21:02:12] <michaelni> and for vfr that has a minute of 25fps and then 30 it will be 25
[21:02:25] <michaelni> its just based on the first few frames
[21:02:34] <Dark_Shikari> can lavc access the avstream?
[21:02:55] <michaelni> no
[21:03:15] <Dark_Shikari> well that doesn't work very well then?
[21:05:51] <michaelni> ffmpeg.c should maybe set time_base to 1/r_frame_rate, dunno if it doesnt or if r_frame_rate if silly too to begin with
[21:06:03] <Dark_Shikari> timebase shouldn't be changed
[21:06:10] <Dark_Shikari> if it's milliseconds it should stay ms
[21:06:27] <michaelni> you cant do that for some cases
[21:06:29] <michaelni> like avi
[21:07:34] <Dark_Shikari> yes, of course
[21:07:37] <Dark_Shikari> but where possible, it shouldn't be changed
[21:09:33] <michaelni> of course
[21:10:02] <michaelni> i think we might have some bug there in ffmpeg.c in relation to this
[21:10:34] <michaelni> but fixing this isnt all that easy
[21:10:55] <michaelni> some codecs (older ones) only support some fps / timebase values
[21:11:08] <kierank> bcoudurier: is there a spec that describes how drop frame works for different framerates (i.e 24/1.001 , 30/1.001, 60,1.001)?
[21:11:48] <bcoudurier> if you mean timecode drop frame is only allowed with 30000/1001
[21:12:13] <kierank> there's a 60/1.001 drop frame apparently
[21:12:21] <kierank> but maybe it's just unofficial
[21:12:28] <bcoudurier> it's not official
[21:12:50] <Dark_Shikari> divVerent: http://pastebin.com/3tPkjeet
[21:12:52] <bcoudurier> did you read that in some document ?
[21:13:00] <bcoudurier> SMPTE 12M is the reference
[21:13:02] <kierank> bcoudurier: can't remember where I read it
[21:15:21] <bcoudurier> ok it seems s12m-2008 added 60000/1001
[21:15:26] <bcoudurier> same mechanism
[21:15:30] <ruggles> BBB: i was considering that. maybe separate the flags above 16-bits as special-case flags and document them better.
[21:16:08] <bcoudurier> progressive 60000/1001 only though
[21:16:10] <kierank> [21:15] bcoudurier: ok it seems s12m-2008 added 60000/1001 --> do you know which part?
[21:16:57] <bcoudurier> section 5.2
[21:16:58] <divVerent> one thing to reply... yes, there are two open questions
[21:16:59] <BBB> ruggles: we don't even need an organization for that (16bit or whatever), but the documentation could be better now
[21:17:02] <divVerent> 1. what fps to set for VFR
[21:17:05] <divVerent> 2. how to detect VFR
[21:17:08] <BBB> ruggles: I'll apply the patch regardless, but for some future patch :)
[21:18:08] <kierank> divVerent: everything is vfr unless proven otherwise
[21:18:14] <kierank> by codec or container
[21:18:17] <divVerent> as for 1.: I suppose anything from 23.98 to 60 will be "good enough" for this
[21:18:34] <divVerent> as for 2.: for x264's purposes, treating anything as VFR indeed won't hurt much
[21:18:50] <divVerent> but a "somewhat good" frame rate estimate would be very useful for x264 initialization
[21:19:02] <ruggles> BBB: thanks. i have 2 patches pending where sse2 is slower on athlon64
[21:19:12] <divVerent> its main purpose seems to be decision of the H.264 level, and calculation of the default minimum keyframe interval
[21:19:19] <divVerent> the latter being skipped by ffmpeg having a hardcoded default
[21:19:28] <saintd3v> peloverde_: when you store he-aac in adts is AOT minus 1 still AOT_LC-1 ?
[21:19:31] <BBB> ruggles: great, (or, well, no, I wish it were faster, but thanks for testing and making us select the fastest anyway)
[21:20:10] <divVerent> kierank: however, how would you "prove it otherwise"? Even a low-fps time base could be VFR
[21:20:16] <divVerent> e.g. if mplayer's "decimate" filter was used
[21:20:29] <kierank> divVerent: proven otherwise by a flag in the container or codec
[21:20:51] <kierank> saintd3v: everyone seems to just flag their he-aac audio as aac-lc at the adts level
[21:21:05] <divVerent> kierank: that would consider my encodes CFR :P
[21:21:14] <divVerent> as the MP4 codec does not have the VFR flag set in libavformat
[21:21:18] <divVerent> *MP4 container
[21:21:21] <bcoudurier> would it be unreasonable to not set the fps and assume level based on everything else ?
[21:21:43] <divVerent> bcoudurier: this is what x264 does in level calculation if fps are not set
[21:22:00] <divVerent> not sure if not setting fps at all has any negative impact otherwise, though
[21:22:18] <bcoudurier> vfr flag ?
[21:22:36] <bcoudurier> oh yes
[21:22:40] <saintd3v> kierank: thanks. what i figured, as storing the extension audio type would be kind of silly. but you never know.
[21:23:02] <divVerent> bcoudurier: mp4 (movenc.c) does not have AVFMT_VARIABLE_FPS set
[21:23:12] <bcoudurier> yes
[21:23:14] <divVerent> yet e.g. my Blackberry Bold 9000 plays VFR MP4 files written by libavformat just fine
[21:23:27] <divVerent> I have read somewhere that the only reason why the flag isn't set is lack of support of negative pts
[21:23:52] <bcoudurier> negative dts
[21:24:20] <kierank> divVerent: ask vfr_maniac, he knows a lot more about mp4 and vfr
[21:24:29] <divVerent> so basically, I wouldn't like anything making it entirely impossible to make VFR MP4 files
[21:24:32] <VFR_maniac> !
[21:25:41] <divVerent> currently, to write working VFR MP4 files with libavcodec/libavformat, all one has to do is to do a nasty hack to set display duration of the first frame to "some nonzero value", so dts initialization doesn't create a row of equal pts which libavformat will later choke on
[21:26:00] <divVerent> which incidentally is the other code that uses "time base <= 1ms" as a heuristics to detect VFR :P
[21:26:02] <Dark_Shikari> Oh hey, it's VFR_maniac.
[21:26:06] <Dark_Shikari> How relevant.
[21:26:24] <bcoudurier> divVerent, just use -vsync 0
[21:26:46] <divVerent> I am not using ffmpeg.c, though
[21:26:59] <bcoudurier> then it doesnt matter
[21:27:09] <bcoudurier> the muxer will work just fine
[21:27:20] <divVerent> it does not unless you specify the per-frame duration for the first frame
[21:27:36] <bcoudurier> humm no
[21:27:47] <bcoudurier> duration is only used for the last frame
[21:27:48] <divVerent> but this is an unrelated issue
[21:28:02] <bcoudurier> otherwise it uses curdts - lastdts
[21:28:07] <bcoudurier> which is the correct way
[21:28:10] <divVerent> nope
[21:28:19] <bcoudurier> nope what ?
[21:28:20] <divVerent> libavformat/utils.c
[21:28:51] <bcoudurier> that's not the muxer
[21:28:55] <divVerent> compute_pkt_fields()
[21:29:00] <divVerent> is part of the muxer
[21:29:03] <bcoudurier> and why don't you set the timestamps ?
[21:29:06] <bcoudurier> not it's not
[21:29:08] <divVerent> I set the pts
[21:29:10] <divVerent> I cannot set dts
[21:29:12] <bcoudurier> x264 gives you the pts
[21:29:15] <bcoudurier> you can set dts
[21:29:17] <bcoudurier> you know the delay
[21:29:18] <divVerent> as I don't get them from libavcodec
[21:29:21] <bcoudurier> and you have the pts
[21:29:27] <divVerent> I don't use x264 directly, I use libavcodec
[21:29:30] <bcoudurier> yes
[21:29:36] <bcoudurier> you have the pts _and_ the delay
[21:29:46] <bcoudurier> first dts == -delay
[21:29:57] <divVerent> but this isn't allowed for mp4?
[21:30:05] <bcoudurier> mp4 doesn't use dts
[21:30:14] <bcoudurier> it uses frmae duration
[21:30:21] <bcoudurier> frame duration is curdts - lastdts
[21:30:26] <bcoudurier> according to specs
[21:30:57] <divVerent> "Number of frames the decoded output will be delayed relative to the encoded input."
[21:30:59] <bcoudurier> well more nextdts - curdts
[21:31:00] <divVerent> but I am doing VFR :(
[21:31:12] <divVerent> description of AVCodecContext::delay
[21:32:05] * lu_zero_ wakes up
[21:32:17] <bcoudurier> all right then, add AVFrame.dts field and set it :)
[21:32:37] <divVerent> my problem is, I just don't know the proper dts
[21:32:40] <bcoudurier> althought I'm curious what x264 uses as first dts
[21:32:50] <bcoudurier> x264 is supposed to return it
[21:32:57] <bcoudurier> I guess you can simulate the behaviour
[21:33:06] <bcoudurier> althought using it directly would be better
[21:33:10] <divVerent> oh, you mean adding the dts so it ends up in coded_frame
[21:33:17] <divVerent> that would probably be somewhat sane :P
[21:33:29] <bcoudurier> yes
[21:33:50] <divVerent> my current code basically "helps" the hack in libavformat/utils.c so its "regeneration" of dts from pts actually works
[21:33:59] <divVerent> is a workaround I want to eventually kill
[21:34:09] <mccoffein> hi
[21:34:10] <divVerent> it "helps" it by setting the duration of the first frame
[21:34:43] <bcoudurier> yes
[21:35:09] <bcoudurier> well although it's better to always set the duration of the frame like I said
[21:35:12] <bcoudurier> it's needed for the last frame
[21:35:26] <divVerent> sure, if I knew it :P
[21:35:28] <bcoudurier> even if it's allowed to be 0
[21:35:36] <bcoudurier> well you know it from the input
[21:35:44] <bcoudurier> don't you ?
[21:35:48] <divVerent> I am working on a video output driver for mplayer to feed ffmpeg
[21:35:59] <divVerent> I do not have duration info there, as far as I know
[21:36:21] <divVerent> and what makes it more evil: I need duration of the *packet*, not of the *frame*
[21:36:26] <bcoudurier> humm well it's next pts - curpts
[21:36:33] <divVerent> I already noticed that the packet doesn't necessarily contain the frame I just encoded
[21:36:43] <bcoudurier> right
[21:37:06] <bcoudurier> well I believe adding AVFrame.dts is sane
[21:37:18] <bcoudurier> and would spare you problems :>
[21:37:50] <divVerent> but anyway, this is the smallest of my problems :P
[21:37:56] <divVerent> but would eventually be the right thing to do in ffmpeg
[21:38:52] <divVerent> http://paste.pocoo.org/show/336755/ - this is my code BTW, which I eventually want to get rid of (e.g. by getting proper dts from ffmpeg)
[21:39:10] <divVerent> the chain of if conditions is exactly the failure condition of libavformat
[21:40:03] <divVerent> (as I want to avoid doing such a hack unless I absolutely have to)
[21:40:59] <divVerent> BTW... slightly off topic, but what IS a good VFR time base?
[21:41:16] <bcoudurier> a timebase that can accurately represent all your timestamps
[21:41:36] <divVerent> 24000fps seems somewhat good, as it can handle NTSC 24/1.001, PAL 25, and a lot of typical "computer frame rates" without ANY loss
[21:41:42] <bcoudurier> and this applies to cfr as well
[21:41:43] <divVerent> however, it can't handle NTSC 30/1.001
[21:41:46] <BBB> wbs: did you test that pressing 'a' switches correctly to the next audio stream with that patch?
[21:41:58] <divVerent> but... I also know that the time base shouldn't have a denominator larger than 32767 :P
[21:41:58] <bcoudurier> ie 1/1000 is crap
[21:42:01] <BBB> wbs: and does -ast work correctly, i.e. start at the correct audiostream
[21:42:06] <bcoudurier> 1/1000000
[21:42:14] <divVerent> fails for some containers I tried :P
[21:42:14] <bcoudurier> should be safe
[21:42:17] <BBB> wbs: and subscribe etc. is done correctly so ffplay only downloads that stresm we actually listen to at that time?
[21:42:23] <bcoudurier> what fails ?
[21:42:28] <divVerent> IIRC mp4
[21:42:43] <bcoudurier> it shouldn't
[21:42:47] <wbs> BBB: yes
[21:42:49] <BBB> wbs: particularly that last one
[21:43:08] <BBB> wbs: you're not looping for building up the subscribe, so I'm affraid something like ffmpeg, which tries to download all streams and not just one, will still fail
[21:43:23] <BBB> wbs: for ffmpeg, the subscribe string should basically enable all of them if we transcode all of them
[21:43:41] <wbs> BBB: uh, I do exactly the same as before, except using ->id instead of ->priv_data to identify them?
[21:43:58] <wbs> BBB: the subscribe commands are identical to before all of the priv_data restructuring
[21:44:12] <BBB> hm, oh, you didn't remove the second loop anymore
[21:44:14] <BBB> then it's fine
[21:44:16] <BBB> sorry, missed it
[21:44:29] <BBB> so can I drop the other two patches then?
[21:44:37] <wbs> yes, they can be dropped
[21:44:43] <divVerent> mpegvideo_enc.c e.g. allows at most a denominator of 65535
[21:44:49] <divVerent> because it is stored in 16 bit, I suppose
[21:45:00] <divVerent> but I _think_ I saw this error with 32767 somewhere too
[21:45:13] <bcoudurier> oh you meant mpeg-4 video
[21:45:46] <divVerent> but anyway, the extra range from 32768 to 65535 doesn't contain any good "generic" time base numbers anyway
[21:46:14] <BBB> hm the stream won't play here now
[21:46:15] <BBB> odd
[21:46:26] <wbs> yeah, the first stream doesn't seem to give any packets
[21:46:30] <wbs> but with -ast 1 it works
[21:47:04] <wbs> and you can switch streams with 'a' once, but once you switch to stream 0, you never get any more packets, and switching streams doesn't work (since the read function doesn't return and resubscribe)
[21:52:43] <BBB> hm, indeed
[21:52:44] <BBB> weird
[21:52:48] <BBB> well, switching 2-3 works, so that's ok
[21:53:13] <wbs> yeah, they're probably just not pushing any content into the lowest bandwidth version.. annoying ;P
[21:53:26] <wbs> it's very low bandwidth at least ;P
[21:54:39] <BBB> that is true
[21:55:03] <BBB> I can just see how the brits would defend this as "cutting public spending by having extra-low bandwidth streams"
[21:55:11] * BBB gives mru the look
[21:55:54] <mru> the bbc actually cares a little about quality
[21:56:15] <mru> they have _much_ better picture than the commercial channels
[21:56:34] <kierank> mru: have you seen the 1080i at 3mbit they push now
[21:56:42] <kierank> mru: but yes on SD they're ok
[21:56:47] <BBB> but does it look as good as that blonde dumb bimbo that is really pretty on fox news?
[21:57:08] <mru> kierank: haven't seen those streams
[21:57:32] <kierank> mru: on dvb-t2 they've dropped to main profile
[21:58:14] <mru> I don't think we have that here yet
[21:58:24] <BBB> wbs: thanks for fixing btw
[21:58:36] <mru> the order they introduce new things across the uk is weird
[21:58:42] <mru> first they do greater london
[21:58:54] <mru> then they do some welsh backwater regions
[21:59:04] <mru> then english backwaters and scotland
[21:59:16] <mru> then places apart from london where people actually live
[21:59:17] <BBB> ruggles, wbs: pushed
[21:59:18] <CIA-38> ffmpeg: Justin Ruggles <justin.ruggles at gmail.com> master * r74b1f96859 ffmpeg/libavutil/x86/cpu.c:
[21:59:18] <CIA-38> ffmpeg: Add check for Athlon64 and similar AMD processors with slow SSE2.
[21:59:18] <CIA-38> ffmpeg: Signed-off-by: Ronald S. Bultje <rsbultje at gmail.com>
[21:59:27] <kshishkov> mru: Leeds?
[21:59:28] <CIA-38> ffmpeg: Martin Storsjö <martin at martin.st> master * rb2dd842d21 ffmpeg/libavformat/ (rdt.c rtsp.c rtspdec.c): (log message trimmed)
[21:59:28] <CIA-38> ffmpeg: rtsp/rdt: Assign the RTSPStream index to AVStream->id
[21:59:28] <CIA-38> ffmpeg: This is used for mapping AVStreams back to their corresponding
[21:59:28] <CIA-38> ffmpeg: RTSPStream. Since d9c0510, the RTSPStream pointer isn't stored in
[21:59:29] <CIA-38> ffmpeg: AVStream->priv_data any longer, breaking this mapping from AVStreams
[21:59:29] <CIA-38> ffmpeg: to RTSPStreams.
[21:59:30] <CIA-38> ffmpeg: Also, we don't need to clear the priv_data in rdt cleanup any longer,
[21:59:30] <CIA-38> ffmpeg: Ronald S. Bultje <rsbultje at gmail.com> master * r2a03e87330 ffmpeg/libavcodec/avcodec.h: Add missing terminating backslash
[21:59:37] <kierank> kshishkov: nobody lives there
[22:00:15] * mru has been to bradford once
[22:00:18] <mru> omg what a depressing place
[22:00:36] <kierank> dover is worse
[22:00:44] <kshishkov> mru: you know one guy from Newcastle
[22:01:07] <mru> never been there
[22:03:52] <kshishkov> mru: he's not eager to return there either. He settled in Germany for now
[22:04:27] <mru> who are you referring to?
[22:04:43] <kshishkov> Ivan from work
[22:04:48] <mru> isn't he from london?
[22:04:59] <kshishkov> not at all - Newcastle
[22:05:12] <mru> he doesn't have a newcastle accent
[22:05:41] <ruggles> apparently my last name comes from Rugeley in Staffordshire.
[22:06:09] <mru> I've changed trains in stafford once
[22:06:53] <kshishkov> and there's a guy from Derby
[22:07:27] <_av500_> and newcastle brown ale
[22:07:48] <mru> _av500_: straight from the pond
[22:08:17] <_av500_> it was the beer in the junior commons room
[22:08:48] <kshishkov> _av500_: remember where you live, it's not beer by your local standards
[22:08:59] <_av500_> yup
[23:07:38] <bcoudurier> is there a way to update the regression ref easily ?
[23:07:54] <mru> yes
[23:08:03] <mru> copy the +++ file from the diff to the --- one
[23:08:18] <bcoudurier> ok, but I have 10*2 files to update
[23:08:24] <bcoudurier> vsynth1 and vsynth2
[23:08:28] <mru> cp *
[23:08:34] <mru> names are same
[23:08:37] <bcoudurier> the suite fails at the first filaing
[23:08:42] <mru> make -k
[23:09:05] <bcoudurier> ahhhh
[23:09:07] <bcoudurier> my saviour
[23:09:08] <bcoudurier> thank
[23:11:23] <bcoudurier> humm qtrle test is borked, it doesn't actually test qtrle, it tests mpeg4 :)
[23:15:10] <mru> hmm
[23:21:07] <bcoudurier> patch sent
[23:32:33] <ruggles> bcoudurier: thanks. i noticed that a while ago and replied to the original commit in ffmpeg-cvslog but never got a response.
[23:33:41] <spaam> nice m2ts patch.... ;D
[23:34:38] <kierank> spaam: should rewrite the muxer first before doing that
[23:34:57] <kierank> blu-ray players are picky as hell
[23:35:31] <bcoudurier> I guess the guy tested his code
[23:35:35] <mru> I don't understand how they manage to write the players like that
[23:35:36] <bcoudurier> if he needed it
[23:35:44] <mru> you've got to try _really_ hard to be that picky
[23:36:23] <bcoudurier> mru the original file is yuv
[23:36:23] <bcoudurier> to compare back you need yuv
[23:36:26] <ruggles> the patch seems like a backwards diff...
[23:36:39] <mru> he noticed
[23:36:41] <spaam> but his patch is a bit wrong.. he remove stuff.. :)
[23:37:05] <spaam> oh
[23:37:37] <mru> bcoudurier: right
[23:37:39] <bcoudurier> mru, I guess the good way of doing it would be to convert the test file in rgb
[23:37:46] <mru> I see the other rgb codecs do the same
[23:37:46] <bcoudurier> encode, decode, verify the lossless
[23:37:50] <bcoudurier> (qtrle is lossless)
[23:37:56] <spaam> is there a big diff between m2ts and ts?
[23:38:03] <mru> spaam: 4 bytes
[23:38:04] <spaam> container wise..
[23:38:06] <kierank> there's loads of silly things like new descriptors
[23:38:07] <spaam> ok
[23:38:11] <kierank> and a different timing model
[23:38:29] <mru> kierank: somehow I doubt that patch contains all that
[23:38:40] <kierank> of course
[23:38:47] <mru> particularly since the existing muxer has no timing model at all
[23:39:13] <bcoudurier> ask him how he tested it
[23:39:24] <bcoudurier> I guess it works for him
[23:39:38] <kierank> iirc you also have to pad to a mod 16 number of packets
[23:39:39] <mru> you'd be surprised what people submit
[23:40:05] <mru> presumably ffmpeg reads whatever it spits out
[23:41:07] <mru> bcoudurier: verifying it really is lossless would be nice, but we'll do that another time
[23:41:14] <mru> along with other similar cases
[23:41:52] <kierank> "The first two bits are reserved for a copyright and should set to 11" --> that's wrong
[23:44:34] <kierank> aahhhh thought he looked familiar: http://doom10.org/index.php?topic=1277.msg6342#new
[23:47:33] <CIA-38> ffmpeg: Baptiste Coudurier <baptiste.coudurier at gmail.com> master * r646739a0a8 ffmpeg/tests/ (codec-regression.sh ref/vsynth1/qtrle ref/vsynth2/qtrle):
[23:47:33] <CIA-38> ffmpeg: Fix qtrle regression test, actually test qtrle.
[23:47:33] <CIA-38> ffmpeg: Signed-off-by: Mans Rullgard <mans at mansr.com>