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

[irc at mansr.com]

[00:10:58] <CIA-38> ffmpeg: Mans Rullgard <mans at mansr.com> master * ra0f9c8ce37 ffmpeg/Makefile:
[00:10:58] <CIA-38> ffmpeg: Auto-generate dependencies for documentation
[00:10:58] <CIA-38> ffmpeg: Signed-off-by: Mans Rullgard <mans at mansr.com>
[00:51:25] <Dark_Shikari> BBB: bench my patch please
[01:02:18] <BBB> Dark_Shikari: ok
[01:07:26] <Dark_Shikari> So, interesting
[01:07:33] <Dark_Shikari> nVidia wants to get nvcuenc into ffmpeg
[01:07:35] <Dark_Shikari> their cuda encoder
[01:07:51] <mru> info ffmpeg?
[01:07:52] <mru> makes no sense
[01:07:59] <Dark_Shikari> So ffmpeg can call it
[01:08:06] <Dark_Shikari> currently there is no open solution for using their encoder on linux
[01:08:16] <Dark_Shikari> This would be the first case of committed code in ffmpeg calling a PROPRIETARY dll.
[01:08:17] <mru> call as external lib, sure
[01:08:20] <Dark_Shikari> Yes, that's the idea.
[01:08:27] <mru> that I don't mind
[01:08:35] <mru> and what about vdpau?
[01:08:42] <mru> isn't that proprietary?
[01:08:42] <kierank> dxva as well
[01:08:48] <mru> and that
[01:08:53] <Dark_Shikari> they're system libs, so the (l)gpl treats them differently
[01:08:56] <Dark_Shikari> you can call them from gpl code too
[01:09:09] <mru> spare me this discussion
[01:09:13] <Dark_Shikari> here's the question
[01:09:20] <Dark_Shikari> is it possible to compile ffmpeg with libx264 and nvcuenc?
[01:09:30] <Dark_Shikari> x264 is GPL, GPL prohibits linking to proprietary code.
[01:09:38] <Dark_Shikari> LGPL would seem fine.
[01:09:44] <mru> x264 is not linked to proprietary in that case
[01:09:50] <Dark_Shikari> Of course this would be terribly annoying if it _was_ a problem.
[01:09:54] <mru> ffmpeg links to A and B
[01:10:02] <mru> does not imply A links to B or vice versa
[01:10:21] <Dark_Shikari> ffmpeg linking to x264 means ffmpeg has to be GPL.
[01:10:24] <Dark_Shikari> i.e. --enable-gpl
[01:10:31] <Dark_Shikari> that means a GPL ffmpeg is linking to B (nvcuenc)
[01:10:54] <mru> if ffmpeg chooses to link to something proprietary it bloody well just gave itself permission to do that
[01:11:12] <Dark_Shikari> I'm confused.
[01:11:15] <mru> and what defines a "system lib"?
[01:11:42] * Dark_Shikari goes to check with people who know more.
[01:11:59] * mru hates such legal wrangling
[01:12:07] <mru> it's not better than the mpaa
[01:12:12] * Dark_Shikari does too, so I'd like to know if there's an issue before we start.
[01:15:17] <mru> I can assure that some freetard will kick up a fuss
[01:21:04] <BBB> Dark_Shikari: done, let me finish feeding baby and i will pastebin it
[01:21:09] <Dark_Shikari> k
[01:21:28] <BBB> its 3 cycles faster or so
[01:21:39] <Dark_Shikari> 3?!?!
[01:21:42] <Dark_Shikari> It was about 30 here
[01:21:55] <BBB> 30 dezicycles
[01:21:59] <BBB> 3 cycles
[01:22:03] <BBB> ?
[01:22:14] <mru> isn't it time we fixed that misspelling btw?
[01:22:20] <BBB> :-p
[01:22:31] <BBB> nah, its fun
[01:23:03] <Dark_Shikari> lol
[01:23:37] <Jumpyshoes> dezicycles confused me for a while
[01:23:42] <j0sh> wbs: nice, you have an attribution in downey's Little Book of Semaphores
[01:24:05] <mru> what book is that?
[01:24:32] <j0sh> it's a ebook on synchronization
[01:24:54] <mru> I figured it wasn't railroad signals
[01:24:54] <j0sh> http://greenteapress.com/semaphores/downey08semaphores.pdf
[01:28:52] <kierank> j0sh: it's no knuth cheque ;)
[01:29:02] <j0sh> heh yeah
[01:29:30] <kierank> I knew someone with one of thoise
[01:30:06] <kierank> naturally he worked in such a messy office he didn't actually know where it was
[01:30:28] <mru> how do you know he was telling the truth?
[01:30:55] <BBB> Dark_Shikari: http://pastebin.com/3vT10uJh after and before, 4 cycles difference
[01:31:13] <Dark_Shikari> BBB: heh, not worth the mess
[01:31:29] <BBB> you saw 300 dezicycles difference btw?
[01:31:34] <Dark_Shikari> Might have been wrong.
[01:31:36] <kierank> mru: he'd shown it to people before
[01:31:36] <BBB> or really just 30?
[01:31:43] <BBB> must've been 30, or a shitty compiler :-p
[01:35:38] <BBB> oh, emu_edge is OK'ed
[01:35:40] <BBB> let me commit that
[01:35:46] <BBB> that's a massively big patch off my list :-p
[01:43:01] <Dark_Shikari> BBB: that seems weird.  just 400 cycles for an entire MB's MC?
[01:43:08] <Dark_Shikari> what test sample are you using?
[01:43:15] <BBB> elephant's dream
[01:43:23] <Dark_Shikari> oh, something covered in 0,0 mvs
[01:43:25] <BBB> there's a lot of skips also
[01:43:26] <Dark_Shikari> try something with a bit more action
[01:43:32] <BBB> sintel?
[01:43:42] <Dark_Shikari> Just a short clip like parkjoy
[01:45:47] <Dark_Shikari> something with motion all th etime
[01:46:19] <Dark_Shikari> http://x264.nl/developers/Dark_Shikari/website/compare/vp8.mkv
[01:46:50] <BBB> great, dl'ing
[01:47:11] * BBB runs make fate once more
[01:50:55] <BBB> why is it that people post complete iphone applications to libav-user, expecting us to find their bug and make them rich?
[01:51:21] <mru> iphone is the new php
[01:51:40] <BBB> every idiot thinks he can do it?
[01:51:58] <mru> every idiot comes asking how to use ffmpeg with it
[01:52:21] <mru> a few years ago, they were all asking how to convert $video to flv from php
[01:55:36] <Kovensky> mru: once in a while people appear if ffmpeg requires php because everything they find about it is how to use it from php
[01:57:48] <BBB> git push origin emu_edge:master pushes my branch back to ffmpeg.git, right?
[01:58:00] <BBB> I don't want to screw up more
[01:58:07] <mru> if you're unsure, don't do it
[01:58:22] <BBB> what do I do else?
[01:58:34] <mru> git rebase master emu_edge
[01:58:36] <mru> git checkout master
[01:58:42] <mru> git merge --ff-only emu_edge
[01:58:44] <mru> git push
[01:59:05] <mru> how much is on that branch?
[01:59:36] <BBB> just this one patch
[01:59:50] <BBB> I have one branch per "project", and generally a "project" is just a single patch
[02:01:11] <lu_zero> good morning
[02:01:15] * lu_zero just woke up
[02:02:07] <BBB> done
[02:02:08] <CIA-38> ffmpeg: Ronald S. Bultje <rsbultje at gmail.com> master * r81f2a3f4ff ffmpeg/libavcodec/x86/ (dsputil_mmx.c dsputil_yasm.asm):
[02:02:08] <CIA-38> ffmpeg: Implement a SIMD version of emulated_edge_mc() for x86.
[02:02:08] <CIA-38> ffmpeg: From ~550 cycles (C version) to 170 (SSE/x86-64), 206 (MMX/x86-32)
[02:02:08] <CIA-38> ffmpeg: and 196 (SSE2/x86-32) cycles.
[02:02:21] <Dark_Shikari> \o/
[02:02:24] <mru> looks like it worked
[02:02:39] <Dark_Shikari> BBB: bench on vp8.mkv?
[02:02:44] <BBB> yep
[02:02:45] * mru meanwhile tries to coerce qnx into running fate
[02:02:47] <BBB> coming
[02:04:48] <Kovensky> 22:58.42 mru: git merge --ff-only emu_edge <-- can't have merge commits either?
[02:09:24] <BBB> Dark_Shikari: http://ffmpeg.pastebin.com/K28fVzG8 28 cycles faster
[02:10:03] <BBB> Kovensky: I'm affraid to mess up
[02:10:05] <BBB> trying to learn slowly
[02:10:11] <Dark_Shikari> BBB: toldyaso
[02:10:16] <BBB> nice
[02:10:19] <Dark_Shikari> Now, I still don't know if it's worth it
[02:10:23] <Dark_Shikari> It's uuugly
[02:10:32] <BBB> do something about it
[02:11:17] <BBB> 28 cycles per run for something that runs a lot, regardless of which file
[02:11:49] <BBB> basically inter_predict() becomes 1.5-2.0% faster
[02:11:54] <BBB> as a whole
[02:11:57] <BBB> that's not bad
[02:12:50] <Dark_Shikari> It's not really ugly, moreso duplicated code.
[02:14:44] * BBB goes review fmtconvert code
[02:15:05] <BBB> Dark_Shikari: I'm fine with the patch basically, I don't care duplicated code all too much as long as it's right next to each other
[02:15:15] <BBB> not the best approach, but if it's faster...
[02:16:46] <Dark_Shikari> any chance you could get an overall bench while reviewing?
[02:16:52] <Dark_Shikari> (after removing timers ofc)
[02:16:58] <Dark_Shikari> Not sure if it affects overall enough to measure on your system or not
[02:17:01] <Dark_Shikari> as I don't know what your stddev is like
[02:17:35] <Kovensky> 23:10.04 BBB: Kovensky: I'm affraid to mess up <-- nah, it's a git thing
[02:17:35] <Kovensky> if you use --ff-only, then git doesn't make a commit saying "merge branch <branchname>" afterwards
[02:17:38] <Kovensky> OTOH, if you use --no-ff, then git will always make that commit, even the branch you're merging branched from the current HEAD
[02:19:56] <mru> if you say --ff-only git will refuse to make a merge commit
[02:20:06] <mru> the default is to make a merge commit if the merge is non-ff
[02:20:13] <BBB> Dark_Shikari: ok will try
[02:25:52] <Kovensky> mru: what I said, but more concise and with better jargon ._.
[02:28:39] <BBB> Dark_Shikari: http://ffmpeg.pastebin.com/PCXYdznc 0.55% faster
[02:28:43] <BBB> Dark_Shikari: that's pretty significant
[02:31:08] <Dark_Shikari> Not bad.
[02:31:23] * BBB slaps Dark_Shikari 
[02:31:46] <Dark_Shikari> ?
[02:32:15] <BBB> not bad is what dutch farmers say when they don't want to say something is pretty darn good, but they do want to say something
[02:32:17] <BBB> you're not a farmer
[02:32:42] <BBB> n/m, it's a bad joke
[02:33:56] <Dark_Shikari> I farm optimizations
[02:34:12] <BBB> go harvest
[02:34:57] <BBB> time for ffmpeg-mt again
[02:45:17] <Dark_Shikari> I'll send a patch in a bit
[03:03:22] <lu_zero> that would be a nice catchphrase on a t-shirt
[03:08:56] <Dark_Shikari> Message-ID to be used as In-Reply-To for the first email?
[03:09:00] <Dark_Shikari> wtf does that mean in git send-email?
[03:09:37] <mru> if you put a message ID there the patch will be sent as a reply to that one
[03:09:46] <Dark_Shikari> and if there is none, I just hit enter?
[03:09:51] <lu_zero> yup
[04:47:32] <CIA-38> ffmpeg: Jason Garrett-Glaser <jason at x264.com> master * r64233e702a ffmpeg/libavcodec/vp8.c:
[04:47:32] <CIA-38> ffmpeg: VP8: merge chroma MC calls
[04:47:32] <CIA-38> ffmpeg: Adds some duplicated code, but avoids duplicate edge checks and similar.
[04:47:32] <CIA-38> ffmpeg: ~0.5% faster overall on Parkjoy test sample.
[07:28:23] <KotH> salut
[07:28:29] <kshishkov> shalom
[07:30:06] <pJok> konbanwa
[07:30:12] <pJok> or
[07:30:22] <pJok> ohayou gozaimasu rather
[07:30:27] <wooster> prevet
[07:31:40] <pross-au> hmmm
[07:32:10] <kshishkov> nudge-nudge, Bink-Bink, mate!
[07:33:14] * kierank sees what kshishkov did there
[07:33:50] <pross-au> where did u learn to be so subtle
[07:34:26] * kshishkov is subtle as 'roo kick
[07:41:23] * elenril kicks kshishkov 
[07:41:44] <elenril> you've finished not working on wavpack multichannel, now you have no excuse!
[07:41:53] <_av500_> unless elenril is built like a roo, kshishkov shrugs
[07:41:59] <thresh> _av500_: awesome
[07:43:32] <kshishkov> elenril: Xan4
[07:44:37] * elenril never heard about it
[07:49:01] <kshishkov> your problem, but it's the codec Mike couldn't RE
[07:49:51] <elenril> resident evil?
[07:51:04] <kshishkov> Wing Commander IV
[07:55:04] <wbs> j0sh: yeah - had to "send a patch" ;P it's kinda annoying when there's bugs in a book like that, when you start pulling your hair off when you don't understand how a tricky problem is supposed to work, and then realize it's a bug in the text ;P
[07:59:33] <wbs> and re the discussion on people posting iphone apps - the android-ndk list is full of people asking how to compile ffmpeg
[08:00:35] <wbs> and attribute the problem to ffmpeg when they're actually screwing up in something else, keeping eternally long threads all with ffmpeg in the subject line
[08:01:37] <cartman> moin
[08:09:54] <j0sh> wbs: yeah, textbooks can have a lot of errata. i found a couple in my dragon book (compilers) but they were already reported by then :)
[08:10:25] <wbs> j0sh: ah.. too bad with normal books that you can't get the errata applied automatically before you read :-)
[08:10:42] <j0sh> would be nice to git-pull the latex :)
[08:10:47] <wbs> yeah :-)
[08:32:41] <Flameeyes> somebody (elenril?) has the pkg-config version of when the new metadata interface was introduced in libavformat, by chance?
[08:35:53] * elenril has nfi what pkg-config version is
[08:37:34] <cartman> elenril: version in the *.pc files
[08:37:36] <benoit-> moin
[08:38:27] <Flameeyes> elenril: usually I'd _expect_ the library version reported by the .pc files to be bumped when a new interface gets added so I can test for it :)
[08:38:30] <benoit-> does anyone know where I can get the right version of libcrystalhd? I wanted to give a shot to  Philip Langdale patch (compile it, at least).
[08:38:42] <cartman> benoit-: ask merbanan
[08:38:47] <elenril> isn't that just so version?
[08:39:00] <Flameeyes> elenril: depends what so version you're referring to :P
[08:39:04] <kshishkov> bonjour, benoit-
[08:39:19] <benoit-> kshishkov: dobroe utro (or something like that :))
[08:39:26] <Flameeyes> elenril: http://blog.flameeyes.eu/2009/10/27/a-shared-library-by-any-other-name :P
[08:39:30] <elenril> Flameeyes: this is all arcane black magic for me ;)
[08:40:12] <benoit-> cartman: I'll see with merbanan when he's here then... Or I'll email Philip to ask.
[08:40:26] <elenril> anyway, isn't the very first entry in doc/APIChanges what you're looking for?
[08:41:48] <Flameeyes> uhm let me check.. I looked last night and was mostly asleep...
[08:41:50] <kshishkov> Flameeyes: BTW, isn't that what we all like Gnome for - loads and loads of unneeded libraries
[08:42:04] <cartman> fact of life
[08:42:32] <Flameeyes> kshishkov: uhm I'd rather have that than kde's monolithic packaging that is able to get out of sync with itself
[08:42:36] <Flameeyes> [kdepim, anyone?]
[08:42:43] <cartman> kdepimp
[08:42:52] <Flameeyes> cartman: kdefuckup, let's be honest
[08:43:06] <cartman> yeah well they need better release management
[08:43:51] <kshishkov> Flameeyes: well, since KDE starts crapload of daemons/services/whatever even for single app, I'm not considering it sane
[08:43:52] <Flameeyes> cartman: they should have listened to us back in the kde3 days
[08:44:11] <cartman> Flameeyes: yeah same thing happening over and over but, what did you guys suggested back then?
[08:44:14] <Flameeyes> kshishkov: find me something sane that is actually living in the 21st century and not in the '70s...
[08:44:27] <Flameeyes> elenril++ yes that was what I was looking for.. but the first from the _bottom_ :P
[08:44:49] <elenril> well yeah, i meant the very first chronologically :)
[08:45:21] <Flameeyes> I was looking at the top, and that was other metadata APIs :P
[08:45:49] <kshishkov> Flameeyes: that may mean that 70s were sane unlike 2000s - just think when UNIX was created and when Haiku
[08:46:22] <Flameeyes> kshishkov: I have definitions of "sane" that goes above and beyond being minimal, tbh
[08:46:43] <Tjoppen> Flameeyes: don't use dark grey text on a light gray background
[08:47:26] <Tjoppen> (just inserting my pet peeve regarding blogs)
[08:48:01] <Flameeyes> Tjoppen: sorry — I'm not really a designer, that's a theme I found and that I liked the structure of :P I always tell myself to actually hire somebody to do a design for me, but never have the time or the money to do that
[08:50:15] <Tjoppen> it's just a minor eyestrain issue. a little more contrast would be better
[08:50:27] <j0sh> benoit-: possibly https://groups.google.com/group/crystalhd-development?pli=1
[08:50:33] <Dark_Shikari> http://www.exploringbinary.com/java-hangs-when-converting-2-2250738585072012e-308/
[08:50:36] <Dark_Shikari> ohgod not again
[08:52:24] <Flameeyes> Tjoppen: uhm actually it isn't that bad indeed... will probably make an update later since I wanted to fix another issue with the theme
[08:54:37] <Tjoppen> nice
[08:54:48] <Tjoppen> making the text darker should suffice
[08:55:36] <Tjoppen> also: interesting post on the ld stuff
[08:55:56] <Tjoppen> it's sort of the mental model I had inferred already
[08:56:23] <Flameeyes> thanks! — it's the kind of black magic that libtool hides "too well" :|
[09:24:29] <benoit-> j0sh: well, found it eventually. If anyone's interested, seems to be git://git.wilsonet.com/crystalhd.git/
[09:41:53] <lyakh> yeah... ok, spent a couple of days, put a large part of apply_window_mp3_c, including the loop, in a separate .S file - gained a whole extra 5%.......
[09:43:11] <spaam>  http://blog.whiletrue.com/2011/01/what-if-visual-studio-had-achievements/
[09:45:35] <cartman> lol
[09:46:00] <cartman> The Portal – Created a circular project dependency
[10:54:08] <lu_zero> wbs: ever used rtpplay and such?
[10:55:48] <wbs> lu_zero: yes, a few times
[11:09:49] <lu_zero> wbs: mind teaching me how to use it?
[11:10:05] <lu_zero> since apparently I'm missing a thing or two
[11:13:54] <merbzt> where can I find an avc intra sample file ?
[11:14:08] <Dark_Shikari> make one with x264?
[11:14:22] <av500> where can I find an avc intra command line for x264
[11:15:01] <Dark_Shikari> though I don't think x264 is quite compliant with every single absurd restriction
[11:15:21] <{V}> av500, man x264 ?
[11:15:26] <Dark_Shikari> commit b20059aa has an example commandline
[11:26:58] <gfto> I see more than 20 warnings about functions which parameters are declared const but are called without const var - http://ffmpeg.pastebin.com/7K42HgEq any idea what to do with them, I have some spare time and would like to clean the warnings
[11:27:24] <Dark_Shikari> patches welcome
[11:27:26] <Dark_Shikari> --> #ffmpeg-devel
[11:28:00] * av500 thought this was #ffmpeg-devel
[11:29:36] <gfto> Dark_Shikari: suer :) I was asking on what to do, remove const declaration in function prototypes or add casts (which sounds incorrect)
[11:30:42] <kshishkov> add qualifiers
[11:30:46] <Dark_Shikari> oh wait
[11:30:47] <cartman> gfto: casting sounds wrong
[11:30:49] <Dark_Shikari> this is #ffmpeg-devel.
[11:30:51] <Dark_Shikari> Damnit.
[11:31:15] <kshishkov> Dark_Shikari: no problems unless you were going to discuss your crazy games
[11:31:35] <Dark_Shikari> I thought it was #ffmpeg.
[11:31:37] <Dark_Shikari> 'cause I'm blind.
[11:36:40] <jannau> gfto: at least some of them can't be avoided
[11:36:46] <gfto> umm, casts definately don't work in this case. http://ffmpeg.pastebin.com/wdkN4LEJ
[11:37:11] <gfto> jannau: can we make gcc shut up about them, most of them are just rubish
[11:38:01] <jannau> I think not without silencing useful warnings
[11:39:06] <gfto> it seems that there is -Wcast-qual but not -Wno-cast-qual
[11:40:54] <jannau> merbzt: "Bitstreams for Professional Profiles" from http://www.itu.int/net/ITU-T/sigdb/spevideo/VideoForm-s.aspx?val=102002641
[11:42:03] <Dark_Shikari> AVC Intra != High 10 Intra
[11:42:08] <Dark_Shikari> AVC Intra is not an ITU spec
[11:46:28] * jannau should read more carefully
[11:46:51] <jannau> but it's just a plot to get Dark_Shikari to review the h264 profiles patch
[11:47:10] <jannau> justjust pinged
[11:55:01] <wbs> lu_zero: in my case, I've most often exported data from wireshark, by choosing "save as" in some of the RTP dialogs... I usually run e.g. rtpplay -f <file.rtpdump> 224.0.0.42/1234, and try to play it back with e.g. ffplay rtp://224.0.0.42:1234
[11:55:21] <wbs> lu_zero: some files need -T added to rtpplay to get it played back in a sensible speed
[12:05:47] <lu_zero> so it works only for multicast
[12:06:10] <lu_zero> I was trying to get it just send to localhost:port
[12:06:10] <wbs> no, you can send to 127.0.0.1/1234 as well
[12:06:18] <wbs> should work just as well
[12:06:23] <lu_zero> it complained a lot
[12:06:58] <wbs> ah, yeah, it complains if noone is listening on that port at the time
[12:07:15] <wbs> that's one of the advantages of sending over multicast
[12:08:19] <lu_zero> and obviously I'm messing up wrongly with the sdp I'm feeding ffmpeg with, possibly
[12:08:58] <wbs> probably
[12:09:42] <wbs> if you're testing mpeg2ts stuff, using the rtp:// url directly probably is easier
[12:10:55] <lu_zero> ok ^^;
[12:14:29] <mru> wtf @ const discussion
[12:14:43] <mru> passing non-const pointer to const-qualified function argument is perfectly fine
[12:14:52] <mru> it just means the function promises not to modify
[12:15:03] <mru> the other way around is wrong
[12:15:13] <Dark_Shikari> then why does gcc warn?
[12:15:17] <Dark_Shikari> is this a case of the C standard being really dumb?
[12:15:27] <mru> I've never seen such a warning
[12:15:43] <Dark_Shikari> I'd guess it's new to gcc 4.6
[12:15:44] <Dark_Shikari> or similar
[12:15:49] <mru> it's stupid
[12:15:54] <mru> it's nothing to warn about
[12:16:07] <mru> he _could_ be talking about multi-level pointers
[12:16:18] <mru> there the C spec is a bit stupid
[12:16:38] <wbs> the warnings he put on pastebin were multi-level pointers, yes
[12:17:06] <mru> some of those can be fixed by adding more const
[12:17:14] * superdump wonders what you're talking about
[12:19:27] <DonDiego> gfto: the correct way to fix such warnings is usually to *add* const in the right places
[12:19:47] <mru> removing const is never a correct fix
[12:20:38] <gfto> I have removed const from declarations in couple of places in imgutils and the resulting object code is exactly the same
[12:20:47] <Dark_Shikari> const is a tool for the programmer
[12:20:47] <mru> that's not the point
[12:20:49] <Dark_Shikari> not a tool for the compiler
[12:20:55] <mru> Dark_Shikari: both actually
[12:20:59] <Dark_Shikari> well yes, but moreso the former.
[12:21:10] <DonDiego> gfto: removing const means removing safeguards against mistakes...
[12:21:24] <mru> const-qualified data can be safely cached across function calls, for instance
[12:21:31] <gfto> I understand the maning, this is not changed in this function but the compiler seems to be too anal
[12:22:02] <Dark_Shikari> anal?  sounds like gcc
[12:22:22] <DonDiego> whatever, your fix is wrong, removing const qualifiers does not improve the code
[12:22:24] <mru> no, gcc is actually correct in this case
[12:22:31] <mru> the C spec is stupid
[12:22:56] <mru> the C spec doesn't allow implicitly adding const to one level of a multi-level pointer without adding it to all
[12:23:22] <gfto> that seems the problem with many of these places in the code
[12:23:28] <mru> in some cases the fix for the warning is as simple as changing "const int *foo" to "const int *const foo"
[12:23:40] <Dark_Shikari> if const doesn't solve the problem, you're not using enough
[12:24:28] <gfto> heh "const int *const foo", lets try that for uint8_t **blah :)
[12:24:29] <mru> btw, we now have qnx on fate too, should anyone care
[12:24:45] <mru> s/int/whatever/
[12:24:58] <wbs> \o/
[12:25:06] <superdump> const uint8_t *const *const blah?
[12:25:29] <mru> yes
[12:25:39] <mru> the last const isn't usually needed
[12:25:48] <mru> that's just for the pointer value itself
[12:26:00] * mru forgot a * in his example
[12:39:43] <lu_zero> wbs: complains the same way =|
[12:40:57] <wbs> lu_zero: hmm, that's weird
[12:41:16] <wbs> lu_zero: sure you listen on 127.0.0.1 and not localhost (which probably resolves to ::1)?
[12:47:52] <lu_zero> ffplay rtp://127.0.0.1:1234
[12:48:09] <lu_zero> rtpplay -v -f /tmp/dump.rtp 127.0.0.1/1234
[12:50:09] <wbs> ah, yes, rtp://127.0.0.1:1234?localport=1234
[12:50:47] <lu_zero> ^^;
[12:50:50] <lu_zero> thank you =)
[12:51:19] <lu_zero> uhm
[12:51:21] <lu_zero> ffplay rtp://127.0.0.1:1234?localport=1234
[12:51:31] <lu_zero> rtpplay -v -f /tmp/dump.rtp --help 224.0.0.42/1234
[12:51:34] <lu_zero> ...
[12:51:54] <lu_zero> wrong buffer
[12:51:56] <lu_zero> rtpplay -v -f /tmp/dump.rtp 127.0.0.1/1234
[12:52:11] <lu_zero> still complains the same way
[12:52:31] <CIA-38> ffmpeg: Mans Rullgard <mans at mansr.com> master * rf3619680a7 ffmpeg/Makefile:
[12:52:31] <CIA-38> ffmpeg: Makefile: remove unused variable ALLHTMLPAGES
[12:52:31] <CIA-38> ffmpeg: Signed-off-by: Mans Rullgard <mans at mansr.com>
[12:52:36] <CIA-38> ffmpeg: Mans Rullgard <mans at mansr.com> master * r7f939f55bb ffmpeg/Makefile:
[12:52:36] <CIA-38> ffmpeg: Makefile: build docs only for enabled tools; fix docs dependencies
[12:52:36] <CIA-38> ffmpeg: This makes "make documentation" build the man/html pages only for
[12:52:36] <CIA-38> ffmpeg: the tools enabled in the build. It also fixes the dependency
[12:52:37] <CIA-38> ffmpeg: tracking for the built man pages.
[12:52:37] <CIA-38> ffmpeg: Signed-off-by: Mans Rullgard <mans at mansr.com>
[12:52:38] <CIA-38> ffmpeg: Gianluigi Tiesi <mplayer at netfarm.it> master * re86e858111 ffmpeg/libavcodec/dca.c:
[12:52:38] <CIA-38> ffmpeg: dca: avoid C99 declaration in for() expression
[12:52:39] <CIA-38> ffmpeg: Signed-off-by: Mans Rullgard <mans at mansr.com>
[12:52:56] <wbs> lu_zero: ok, that's weird then, that works flawlessly for me
[12:56:11] <Kovensky> 09:52.38 CIA-38: ffmpeg: dca: avoid C99 declaration in for() expression <-- why is this? isn't ffmpeg C99 to begin with?
[12:56:35] <elenril> no
[12:56:45] <elenril> only some selected features
[12:57:06] <Dark_Shikari> it's stupid, IMO
[12:57:11] <Dark_Shikari> c99 for loop declarations avoid tons of bugs
[12:57:12] <Dark_Shikari> and are cleaner
[12:57:20] <Dark_Shikari> even if you don't like declaration after statement, they're still cleaner
[12:57:20] <mru> I agree with that
[12:57:28] <mru> but some silly compilers still don't support them
[12:57:35] <Dark_Shikari> Can't we stop caring about them?
[12:57:37] <Dark_Shikari> We don't support MSVC
[12:57:42] <Dark_Shikari> why support some other shitty C89 compiler?
[12:58:11] <mru> what if that's the only one that exists for a certain target?
[12:58:17] <Dark_Shikari> which one is this?
[12:58:27] <kshishkov> some shitty Atmel chip for example
[12:58:32] <mru> I've run into the same problem with TI DSP compilers
[12:59:16] <Dark_Shikari> You could write a preprocessing script to turn C99 int-- *shot*
[12:59:48] <lu_zero> wbs: willing to give a try?
[13:00:12] <wbs> lu_zero: on the mpegts stuff, or on getting rtpplay to work for you? :-)
[13:00:32] <lu_zero> wbs: that or give me an rtp-mpegts to try
[13:00:44] <lu_zero> I'm spending too much time on this =P
[13:01:07] <wbs> there's the http://albin.abo.fi/~mstorsjo/RTP_mpegts_sample.{cap,rtpdump} that I think I sent you last week
[13:01:20] <lu_zero> those are known to work?
[13:01:36] <wbs> they work quite ok - some dropped packets, but generally quite ok
[13:01:48] <av500> lu_zero: did you get the captures from us?
[13:01:55] <Kovensky> 09:50.12 Kaze: An IPv4 address space walks into a bar: "A strong CIDR please. I'm exhausted."
[13:02:30] <mru> ha ha ha
[13:02:40] <wbs> I had a look at the samples that av500 gave, and the issue there seemed to be that the mpegts demuxers sets the streams into probe mode, taking an eternity to sort out... if using a normal mpegts demuxer, the demuxer read_header function would sort it all out, but that one never is called in the rtp/mpegts setup
[13:04:43] <lu_zero> av500: those are making rtpplay upset ^^;
[13:05:08] <lu_zero> wbs: what I'm doing is to call the normal mpegts demuxer
[13:05:23] <lu_zero> just that I need to remap the streams doing so =|
[13:05:34] <lu_zero> (and double check it)
[13:09:45] <lu_zero> your sample does have the same problem =|
[13:10:17] <wbs> well, that's weird then. check with wireshark what ip address the packets are sent to, and check with netstat which ports ffplay listens to
[13:10:23] <wbs> did you test sending over multicast?
[13:13:31] <lu_zero> rtpplay -v -f /tmp/RTP_mpegts_sample.rtpdump 224.0.0.42/1234
[13:13:31] <lu_zero> fread body: Bad address
[13:13:31] <lu_zero> rtpplay: multimer.c:98: timer_check: Assertion `np->time.tv_usec < 1000000' failed.
[13:13:34] <lu_zero> Aborted
[13:17:27] <lu_zero> stranger and stranger
[13:17:30] <wbs> uhm, sounds like your rtpplay is miscompiled in some way.. I think I ran into some such issue early on, but don't really remember what I did to fix it
[13:18:25] <lu_zero> it does have -g -O2 as cflags so I'm not expecting such issues
[13:18:52] <wbs> in my case, it might have been some issue with osx
[13:23:26] <lu_zero> mpegts_read_header needs 5k
[13:23:34] <lu_zero> apparently
[13:31:31] <j-b> "unstable executables up to gcc 4.5" I call BS
[13:32:22] <mru> j-b: stable or not, c99 has nothing to do with it
[13:32:51] <j-b> the only stable way to have a computer is to turn it off
[13:33:16] <j-b> not to mention that gcc 4.2 compiles c99 fine
[13:33:35] <mru> of course it does
[13:37:15] * kshishkov want the best compiler eternal - GCC 96.96.96
[13:38:23] <lu_zero> isn't it the 6.6.6_p9999 ?
[13:39:49] <kshishkov> nope
[13:40:18] <kshishkov> just compare any GCC with 6 in any version and with 96 in any version
[13:40:37] <Dark_Shikari> 3.4 is still the best
[13:40:48] <Dark_Shikari> `-`
[13:50:20] <cartman> Dark_Shikari: share what you are smoking
[13:52:04] <Dark_Shikari> it's the only version of gcc that's never miscompiled any of my code
[13:52:08] <Dark_Shikari> of all those I've ever used
[13:52:09] <Dark_Shikari> (well, 3.4.5)
[13:52:22] <kshishkov> 3.4.5 patchlevel 6.7.8 ?
[13:52:53] <av500> runing in windows 1.2.3?
[13:53:29] <kierank> av500: is that what it would have been called if ibm bought microsoft?
[13:53:30] <kshishkov> av500: in windows -3.-2.-1
[13:53:53] <kshishkov> kierank: it would be windows 3/2^7
[13:55:48] <pJok> OS/2 Warp 9?
[13:56:07] <kshishkov> pJok: that's only for selected ships
[13:56:30] * pJok does not understand the people who are still running OS/2
[13:57:06] <kshishkov> pJok: they are also playing StarCraft in it
[13:57:17] <pJok> kshishkov, damn koreans...
[13:57:17] <kierank> pJok: they are not people, they are ATMs
[13:57:29] <pJok> kierank, if only... ;)
[13:57:47] <pJok> kierank, most of the ATMs around here run some terminal edition of windows now
[13:57:52] <pJok> and have been for quite some time
[13:59:23] <av500> terminal edition means its the last one?
[14:00:47] <kshishkov> could be
[14:01:00] <kshishkov> or could be just second word missing
[14:01:55] <pJok> hehe
[14:08:53] <lu_zero> pff
[14:08:55] <lu_zero> ok
[14:23:24] <cartman> thresh: http://www.androidcentral.com/archos-5-tablet-half-amazon-today-only
[14:23:29] <cartman> better than av500's discount :P
[14:23:52] <av500> yes, but old tech
[14:24:03] <av500> cartman: but please go buy one
[14:24:14] <cartman> av500: I have 4-5 tablets already
[14:24:16] <cartman> :P
[14:24:24] * cartman got a new one from Marvell
[14:24:48] <thresh> cartman: I'm off using held devices with hard drives :)
[14:24:55] <thresh> been there done that with an ipod
[14:24:57] <cartman> thresh: heheh :)
[14:25:07] <cartman> <3 ipod classic
[14:25:14] <thresh> i was using exactly that model
[14:25:28] <thresh> and guess what? it died three days after warranty void
[14:25:34] <cartman> I'm waiting for Motorola Xoom hotness
[14:25:41] <cartman> thresh: mine still works 6 years and going
[14:26:03] <kshishkov> thresh: that's success for manufacturer!
[14:26:06] <thresh> cartman: you obviously don't bike with it :)
[14:26:09] <thresh> kshishkov: indeed :)
[14:26:13] <cartman> thresh: lol
[14:26:30] <thresh> actually, I've fallen a numerous times on my n900 already, still alive
[14:26:55] <thresh> if only it wouldnt be such a disaster OS/software wise ...
[14:27:00] <cartman> http://searchengineland.com/google-bing-is-cheating-copying-our-search-results-62914
[14:27:04] <cartman> scroll down to examples
[14:27:08] <cartman> hahah MS is busted
[15:16:53] <siretart> michaelni: with the two commits regarding aspect handling in avfilter from yesterday evening, can the libavfilter API/ABI considered stable, or do you have more changes in the pipe?
[15:22:58] <ubitux> is for (int i ... ) still problematic with recent mingw64 versions?
[15:24:02] <saste> siretart: more changes due to audio filtering
[15:24:45] <siretart> saste: ah, I see. thanks
[16:06:32] <BBB> michaelni: will you review " [PATCH] Factorize code from video_thread() and put it in configure_video_filters()"?
[16:07:03] <BBB> mru: did you push "[PATCH] In get_video_frame(), use frame->pkt_pts rather than the deprecated reordered_opaque API, which is deprecated for this specific use" already?
[16:07:19] <BBB> I think you did, right?
[16:07:22] <BBB> I see it in git log
[16:07:45] <mru> if so, I did
[16:18:03] <michaelni> siretart, no ABI/API changes from my side planed but as saste said from his about audio
[16:18:16] <j-b> hello peopl
[16:19:47] <kshishkov> where do you see them?
[16:23:47] <michaelni> BBB, if it makes you happy, ill review it. But dont forget iam trying to do civil disobedience
[16:53:46] <BBB> mru: can you commit "[PATCH] Log debug information in filter_samples()"?
[16:54:23] <BBB> michaelni: if you don't want ot review, then don't, I'l review and apply myself
[17:02:36] <michaelni> BBB, well ive already reviewed it now
[17:03:13] <BBB> thank you
[17:06:17] <BBB> mru: do you want to backport "Document that av_write_header sets stream time_base to a value of it chosing" from videolan git?
[17:10:59] <ruggles> does x86 have a vector float log instruction?
[17:12:20] * av500 guesses its called vctrfltlg
[17:12:40] <thresh> av500: at office? :)
[17:12:44] <mru> that doesn't look like an sse instruction
[17:12:55] <av500> thresh: er, yes
[17:17:53] <pengvado> ruggles: no
[17:18:39] <mru> BBB: that patch wasn't approved afaics, but you had a comment that was never answered
[17:20:18] <pengvado> ruggles: how much precision do you need?
[17:21:54] <ruggles> 1/256 i think
[17:22:05] <lyakh> hm, are patches now preferred inline?
[17:22:47] <av500> not in .S files any more? :)
[17:23:09] <lyakh> av500: what? patches in .S files?;)
[17:23:22] <mru> lyakh: patches are preferred in any unmangled form
[17:23:23] <ruggles> pengvado: i need to calculate lrintf(128.0*(25.0-log2f(x)))
[17:23:31] <mru> pasting into gmail does _not_ work
[17:23:34] <lyakh> mru: good, thanks
[17:23:51] <lyakh> mru: it won't be the first patch I'm sending to a list, don't worry;)
[17:24:48] <av500> mru: fun fact: coworker wrote an IIR filter in asm, if you shouted loud enough into the MIC, the filter would go mute forever
[17:25:09] <lyakh> av500: lol
[17:25:09] <pengvado> ruggles: you need 8 bits exactly, or just some limit on average error?
[17:28:52] <ruggles> any estimate better than an integer will be useful.  the more accuracy the better, up to 8 bits.
[17:29:58] <pengvado> simd taylor series
[17:30:30] <lyakh> ...hope nearly 200 lines assembly (excluding empty lines) make an enjoyable reading, even with TABs...
[17:30:37] <pengvado> quadratic is enough to get average error below 1/256
[17:30:43] <mru> lyakh: tabs are forbidden
[17:31:05] <lyakh> mru: I know, I commented in the patch, if it is accepted, I'll convert
[17:31:15] <mru> and I have nearly 2000 lines of asm here about to go
[17:31:16] <ruggles> pengvado: great. i'll look into it.
[17:31:19] <kierank> why not use spaces in the first place?
[17:31:51] <lu_zero> lyakh: which editor do you use?
[17:32:02] <lyakh> kierank: different people have different preferences...
[17:32:05] <av500> notepad.exe?
[17:32:05] <lyakh> lu_zero: emacs
[17:32:15] <lu_zero> sed -i -e "s:\t:    :g" to remove tabs
[17:32:17] <lu_zero> uhmm
[17:32:31] <mru> M-x untabify
[17:32:32] <lu_zero> emacs... mru could you give him the mode you use?
[17:32:41] <lyakh> av500: no, mac:"Text Editor"
[17:33:00] * av500 prefers joe anyway
[17:33:11] * mru has seen people write code in msworks
[17:33:39] <lyakh> sure, I think we all have seen such code...
[17:33:47] <pengvado> ruggles: and for a C implementation, LUT works. x264 has one.
[17:34:15] <pengvado> I'm not actually sure whether simd float taylor series will be faster than scalar LUT
[17:34:43] * lyakh likes to look at ohloh.net when he wants to find out about developer experience of someone new in a certain community;)
[17:35:23] <kierank> [17:33] mru has seen people write code in msworks --> oh god
[17:35:49] * av500 has seen people "program" in excel
[17:36:05] <av500> it was a brake system even
[17:36:17] <kierank> hundreds of billions of dollars are managed in excel
[17:36:21] <ruggles> pengvado: that does sound faster. so is the LUT based on the mantissa only?
[17:36:43] <av500> kierank: ok for the $$, but pls not my car brakes :)
[17:37:11] <pengvado> both taylor and lut work by separating exponent from mantissa, adding exponent to the output directly, and the approximating log2 on the limited domain of the mantissa
[17:50:03] <BBB> mru: correct, I asked to use @note but nobody answered
[17:50:11] <BBB> Jumpyshoes: are you interested in vp7?
[17:50:25] <BBB> Jumpyshoes: and if you had to choose encoding/decoding, as a way to start learning, which would you prefer?
[17:52:55] <Jumpyshoes> BBB: no objections with vp7 and i guess i would like to start with encoding
[17:53:24] <mru> I would've thought decoding is easier to start with
[17:54:12] <Jumpyshoes> mru: probably, but i'm more interested in encoding
[17:54:33] <mru> how will you know the bitstream format without REing the decoder first?
[17:55:00] <Jumpyshoes> mru: has that not been done with vp7?
[17:55:10] <mru> not that I know
[17:55:26] <Jumpyshoes> oh
[17:55:37] <mru> nobody really cares about vp7 since it was never used in the wild
[17:55:49] <Jumpyshoes> who actually uses it then?
[17:55:58] <mru> on2 marketing
[17:56:07] <BBB> not many people, it was more an exercise to get you to learn everything about video :-p
[17:56:14] <BBB> best way to learn is to just do it yuorself
[17:56:22] <mru> it might be used in some closed system somewhere
[17:56:29] <BBB> are you interested in vp8 encoding? :-p (google is asking)
[17:56:49] <lu_zero> BBB: =)
[17:57:02] <Jumpyshoes> BBB: vp7 decoding or vp8 encoding are fine with me
[17:57:20] <BBB> which do you feel is more interesting?
[17:57:24] <Jumpyshoes> speaking of google i should submit my resume
[17:57:28] <j-b> vp7
[17:57:34] <BBB> j-b: hey there
[17:57:40] <j-b> hello BBB
[17:57:47] <BBB> Jumpyshoes: j-b will give you double gci points next year if you do vp7 decoding, I guess :-p
[17:57:57] <Jumpyshoes> can't do GCI next year
[17:58:01] <j-b> BBB: I don't want Jumpyshoes in GCI anymore
[17:58:06] <j-b> BBB: he is too good
[17:58:09] <BBB> oh
[17:58:12] <j-b> he destroys the concept
[17:58:22] <BBB> good point
[17:58:22] <j-b> he needs a GSoC
[17:58:25] <Jumpyshoes> to be fair i started with 0 knowledge in the things i did
[17:58:31] <j-b> and an exceptions
[17:58:36] <Jumpyshoes> i also can't do gsoc <_<
[17:58:43] <j-b> Jumpyshoes: take it in the best way you can
[17:58:43] <av500> skype used vp7
[17:58:54] <Jumpyshoes> j-b: haha okay
[17:58:56] <j-b> Jumpyshoes: well, age limitation ?
[17:59:04] <Jumpyshoes> j-b: yea, i'm too young (17)
[17:59:06] <j-b> Jumpyshoes: ok, so I need to do a SoV ?
[17:59:19] <Jumpyshoes> j-b: SoV?
[17:59:24] <j-b> Summer of VideoLAN
[17:59:30] <mru> summer of violence
[17:59:35] <Jumpyshoes> j-b: lol, possibly
[17:59:44] <j-b> Jumpyshoes: don't lol on that
[18:00:06] <j-b> I am stupid enough to do it
[18:00:16] <kierank> j-b: french government paying?
[18:00:23] <j-b> VideoLAN©®
[18:00:32] <av500> http://forum.skype.com/index.php?showtopic=67904
[18:00:38] <av500> wrt vp7
[18:00:38] <Jumpyshoes> BBB: hrm, can i think about that for a bit? vp7 is interesting because no one has done it so i'll get to work on RE + decodng, but vp8 encoding is also interesting <_<
[18:00:51] <BBB> Jumpyshoes: of course
[18:00:55] <kierank> Jumpyshoes: work on a codec people actually use ;)
[18:01:08] <mru> what kierank said
[18:01:20] <Jumpyshoes> kierank: lol
[18:01:26] <BBB> wvp2?
[18:01:29] <mru> nobody really uses vp8 either, to be honest
[18:01:43] <kierank> mru: yep, that's why i said that to him
[18:01:50] <lu_zero> mru: I'll use it for my evil plans soon
[18:01:55] <lu_zero> vp8
[18:01:59] <lu_zero> I mean ^^
[18:02:00] <kierank> Jumpyshoes: you can work on my broadcast encoder
[18:02:02] <Jumpyshoes> j-b: well, if it's possible, that would be interesting
[18:02:22] <jannau> mru: I guess google uses it to encode videos nobody watches
[18:02:26] <mru> if Jumpyshoes is masochistic, he can add interlaced support to our vc1 decoder :)
[18:02:40] <Jumpyshoes> kierank: i thought those were massive compliance stuff
[18:02:40] <BBB> rv40 bidirectional prediction
[18:02:41] <kierank> or write 422 h264 decoding
[18:03:05] <av500> if we re vp7, we can use vp6,7 and 8 to extrapolate vp9 with quadratic curve fitting!
[18:03:18] <lu_zero> av500: aaaaargh
[18:03:23] <j-b> vc1 interlaced and MVC would be cool
[18:03:33] <av500> Jumpyshoes: and I can host you on vp7.de!!!
[18:03:50] <mru> av500: no, we need vp4 as well for quadratic
[18:03:53] <Jumpyshoes> quadratic curve fitting?
[18:04:10] * mru reconsiders
[18:04:11] <jannau> av500: you have hopes that quadratic curve gives better results than a linear vp6,vp8 fit?
[18:04:15] <av500> mru: 2 points give linear, 3 gives x^2, no?
[18:04:27] <mru> av500: you're right
[18:04:30] * mru can't count to 5
[18:04:41] <Jumpyshoes> av500: vp7.de? >_>
[18:04:48] <av500> Jumpyshoes: yeah
[18:05:11] <av500> its also my initials and 7 was the 1st free one when I registered it
[18:05:26] <av500> also the only free one iirc
[18:05:55] <Jumpyshoes> av500: oh, i see
[18:16:40] <Kovensky> jannau: I got fate to work here btw, just not submitting
[18:16:45] <Kovensky> I need to figure out how to get it to work on cron (I wrote the crontab, but my ssh private key has a passphrase) so I give my pubkey to whoever is responsible ._.
[18:17:19] <mru> Kovensky: you'll need to create a key pair without password just for fate
[18:18:22] <jannau> or a properly configured ssh-agent
[18:18:31] <jannau> and enviroment
[18:18:38] <mru> I still recommend using a dedicated key
[18:18:40] <BBB> Kovensky: what os?
[18:18:54] <Kovensky> osx
[18:20:28] <BBB> yay
[18:20:29] <jannau> yes, I thought more of a dedicated key with a passphrase
[18:20:34] <BBB> mru: " [WIP] movie video source" should be committed?
[18:20:53] <mru> the WIP tag suggests otherwise, unless it has been completed
[18:20:57] <mru> I haven't reviewed it
[18:21:34] <BBB> I think it's completed
[18:21:53] <BBB> we can wait until it's applied to videolan repo
[18:23:18] <mru> that makes no sense
[18:23:29] <mru> if it's finished and reviewed, we should commit it
[18:26:09] <Kovensky> who do I send the pubkey to
[18:26:18] <av500> mru
[18:26:27] <av500> aka the fatekeeper
[18:26:27] <Kovensky> is IRC query okay
[18:35:27] <lu_zero> BBB: could you have a look at ff_rtsp_close_streams ?
[18:39:32] <lu_zero> http://ffmpeg.pastebin.com/bTyV9t0z
[18:43:33] <saste> mru: the movie source is complete, I'm just waiting for the reply from michaelni after the last review
[19:02:53] <kierank> With git, if I have modifications to ffmpeg vanilla and ffmpeg-mt is there any way of keeping them automatically in sync (with manual fixes if necessary)?
[19:03:52] <BBB> lu_zero: patch looks correct, nice catch
[19:05:48] <lu_zero> kierank: rebase the modification
[19:09:42] <lu_zero> sent to the ml
[19:24:28] <maxime1986> hello
[19:24:38] <maxime1986> ffmpeg -i dvd.vob -itsoffset 10 -i dvd.vob -map 0.0 -map 1.1 ...
[19:24:44] <maxime1986> doesn't work
[19:24:50] <maxime1986> ffmpeg -i dvd.vob -itsoffset -10 -i dvd.vob -map 1.0 -map 0.1 ...
[19:24:55] <maxime1986> work
[19:24:58] <kierank> maxime1986 --> #ffmpeg
[19:26:16] <maxime1986> kierank: I just want to know if it's a bug ...  so I think a user can't be aware of this...
[19:41:05] <CIA-38> ffmpeg: Anssi Hannula <anssi.hannula at iki.fi> master * r71e0bee9ea ffmpeg/libavcodec/h264.c:
[19:41:05] <CIA-38> ffmpeg: h264: add profile names for the existing defines
[19:41:05] <CIA-38> ffmpeg: Signed-off-by: Janne Grunau <janne-ffmpeg at jannau.net>
[19:41:16] <CIA-38> ffmpeg: Luca Barbato <lu_zero at gentoo.org> master * rea7f080749 ffmpeg/libavformat/rtsp.c:
[19:41:17] <CIA-38> ffmpeg: Free the RTSPStreams in ff_rtsp_close_streams
[19:41:17] <CIA-38> ffmpeg: This plugs a small memory leak
[19:41:17] <CIA-38> ffmpeg: Signed-off-by: Janne Grunau <janne-ffmpeg at jannau.net>
[19:41:26] <CIA-38> ffmpeg: Janne Grunau <janne-ffmpeg at jannau.net> master * rfe9a3fbe42 ffmpeg/libavcodec/ (avcodec.h h264.c h264.h h264_parser.c h264_ps.c): h264: Add Intra and Constrained Baseline profiles to avctx.profile
[19:42:22] <uau> Kovensky: btw did you see what i said about PKG_CONFIG_LIBDIR earlier? did you use (older) pkg-config without that or was there a reason why it didn't work for crosscompiling?
[19:43:05] * Kovensky didn't know about PKG_CONFIG_LIBDIR
[19:58:33] <BBB> this is retarded
[19:58:41] <BBB> I used to have ffmpeg-mt failing in two parts
[19:58:49] <BBB> I changed some random parts, didn't fix it
[19:58:51] <BBB> try it again
[19:58:55] <BBB> and now only one part fails
[19:58:56] <BBB> wtf?
[19:59:07] <BBB> I guess I shouldn't care, but this is pretty retarded
[20:00:27] <mru> I hate vanishing bugs
[20:00:36] <mru> I want to know _why_ they went away
[20:08:42] <lu_zero> BBB: bisect it
[20:30:23] <Kovensky> 17:00.36 mru: I want to know _why_ they went away <-- it's because you scared them away with your shotgun!
[20:34:15] <spaam> Kovensky++
[20:48:54] <jannau> are defines prefixed with FF_ considered internal
[21:02:14] <lu_zero> that was my understanding
[21:07:53] <Kovensky> http://www.yorktownhistory.org/homepages/1900_predictions.htm
[21:08:10] <saste> jannau: in that case I believe minor doesn't need to be updated
[21:08:27] <kierank> Kovensky: reminds me of that at&t advert where you can send a fax on the beach
[21:08:30] <saste> jannau: for being extra-safe though it's a good norm to update micro
[21:08:59] <saste> jannau: so that e.g. pkg-config can track the new dependency if the symbol is used in another library (although internally)
[21:11:02] <saste> jannau: also we have many FF_ symbols which are considered public at all effects
[21:11:48] <jannau> saste: I've already sent patches
[21:11:54] <lu_zero> yet another thing that should be addressed
[21:13:32] <jannau> it doesn't make much sense to have internal symbols to describe a field in avformatcontext
[21:24:26] <jannau> Dark_Shikari: I don't understand your mail
[21:25:48] <BBB> neither do i
[21:28:03] <kierank> _av500_: make them answer my mail on jvt-experts kthx
[21:35:35] <BBB> astrange: blegh, I fixed your h264 bug
[21:35:45] <BBB> astrange: ready to merge? make fate passes locally
[21:38:23] <jannau> BBB: woohoo!
[21:39:06] <kierank> BBB: merge mt?
[21:39:15] <BBB> kierank: flying pigs
[21:39:18] <BBB> see 'em? right up there
[21:39:28] <kierank> awww it was worth a try
[21:39:39] <kierank> also Dark_Shikari is saying High444 != High 444 Predictive
[21:39:57] <kierank> there's an old lossless mode and a new one
[21:41:25] <jannau> BBB: the encoding bug is the heisenbug? was it maybe a different ffmpeg base?
[21:41:35] <BBB> I rebased
[21:41:42] <BBB> and made local changes also
[21:41:45] <BBB> not sure what fixed it
[21:41:47] <elenril> lu_zero: did you do the api bump we talked about yesterday?
[21:41:48] <BBB> but I can't reproduce it anymore
[21:41:57] <lu_zero> elenril: waiting for you =P
[21:42:03] <BBB> jannau: I'll compare trees with alex to make sure we've got everything right
[21:42:15] <elenril> lu_zero: what? i thought you were going to do it =p
[21:42:24] <lu_zero> same ^^;
[21:42:27] <elenril> haha
[21:42:42] <elenril> you have commit powers unlike me =p
[21:43:07] <jannau> kierank: how do those two differ? only High 444 Predictive made it into the latest itu draft with profile_idc = 244
[21:43:36] <lu_zero> elenril: not that this changes
[21:43:51] <lu_zero> if you write I'll review and commit ^^
[21:44:02] <lu_zero> if I write you'll review and I'll commit =P
[21:44:15] <elenril> ok, i'll write it
[21:45:04] <lu_zero> thank you =)
[21:45:05] <kierank> jannau: can't actually remember the difference wrt profile_idc off the top of my head
[21:45:45] <jannau> lu_zero: I smell a conspiracy to game the system :D
[21:46:54] <elenril> wait, your change is lavu
[21:47:01] <elenril> mine is lavf
[21:47:38] <lu_zero> jannau: uh?
[21:47:43] <lu_zero> yup
[21:48:09] <lu_zero> that reminds me that we should discuss an item...
[21:49:54] * elenril wonders what to put use instead of svn revision in doc/APIChanges
[21:50:12] <mru> craft a git hash such that it matches the commit
[21:50:27] <elenril> my crypto magic isn't strong enough ;)
[21:50:27] <jannau> elenril: git short hash
[21:50:43] <elenril> jannau: of the commit i'm about to commit?
[21:50:47] <mru> there should exist a long hash with that property
[21:50:52] <mru> not necessarily a short one though
[21:52:17] <jannau> elenril: guess until you find one
[21:52:42] <elenril> i guess this will take a while
[21:53:07] <elenril> hmm, bump for lavf 52.94 isn't documented either
[21:54:09] <jannau> elenril: that's the reason why I suggested to start with short ones
[21:59:56] <elenril> any constructive ideas?
[22:00:43] <elenril> maybe we should write parent there
[22:00:46] <elenril> or tag api bumps
[22:01:15] <lu_zero> elenril: only major
[22:01:32] <elenril> you don't like having a gazillion tags?
[22:01:51] <_av500_> kierank: your jvt question is neither in latin nor does it mention h264, so booooring
[22:01:54] <jannau> elenril: $PARENT..
[22:02:15] <kierank> _av500_: yeah but it's a genuine question and they are ignoring it
[22:02:25] <kierank> they seem to think everyone understands the magic hrd(tm)
[22:02:42] <Jumpyshoes> hrd?
[22:02:53] * elenril wonders where are all the people who wanted to merge -mt a few minutes ago
[22:03:19] <kierank> Jumpyshoes: hypothetical reference decoder
[22:03:30] <kierank> magic thing in h.264
[22:03:41] <elenril> should i use first person pejorative in APIChanges?
[22:03:56] <_av500_> Jumpyshoes: jvt experts all wear pointy hats and fight balrogs
[22:06:24] <elenril> haha, git shortlog says i have 99 commits
[22:06:42] <Jumpyshoes> _av500_: oh ._.
[22:08:15] <lu_zero> _av500_: claim to have fought balrogs in their young times
[22:08:39] <Jumpyshoes> does anyone have a sandy bridge that they're willing to give me access to?
[22:08:56] <lu_zero> why a sandy bridge?
[22:09:08] <jannau> AVX
[22:09:09] <lu_zero> btw the broken bridge?
[22:09:23] <Jumpyshoes> lu_zero: working on avx for x264
[22:09:28] <mru> I didn't know trolls were so particular about the bridges they lived under
[22:10:49] <wbs> lu_zero: in what scenario did you find the leak in rtsp? I didn't stumble upon it in normal rtsp use... with rtp/mpegts however, I get lots of leaks
[22:11:06] <elenril> lu_zero: http://pastebin.com/awatEEuD
[22:12:00] <mru> http://www.ll.mit.edu/mission/communications/ist/publications/041031_Leek.pdf
[22:12:46] <mru> ^^ that paper finds that splint is no better than randomly tagging 43% of all lines as buggy
[22:13:04] <wbs> lol
[22:13:28] <wbs> sure, it forces you to manually reread and verify all of it ;P
[22:13:43] <mru> but what's the point in using lint then?
[22:13:48] <mru> if you're going to reread all of it
[22:13:59] <lu_zero> wbs: just ran valgrind on ffmpeg -i rtsp://source -vcodec copy -acodec  copy out.nut
[22:14:56] <lu_zero> elenril: looks ok
[22:15:37] <elenril> lu_zero: maybe i should mention that the commit has refers to parent
[22:15:46] <elenril> or maybe anybody has a better idea
[22:15:47] <BBB> mru: do you want to merge "Add sample_aspect_ratio to AVFilterLink" into git?
[22:16:18] <wbs> lu_zero: uhm, with that patch in place, I get a valgrind warning about a double free now, no such warning before (and no leak there)
[22:16:52] <BBB> wbs: where was it originally free'ed? maybe it needs a freep(&..)
[22:19:53] <ubitux> jannau: thanks for setting up patchwork for mplayer too
[22:21:03] <lu_zero> wbs: if it's freed it isn't in rtsp.c
[22:23:42] <wbs> lu_zero: it's freed in utils.c:2549, as st->priv_data
[22:25:41] <lu_zero> give me a backtrace
[22:26:19] <BBB> oh that's right, utils.c free()s priv_data already
[22:26:27] <wbs> http://pastebin.com/n6isx1pV
[22:27:16] <lu_zero> I wonder why it doesn't with mpegts-in-rtp...
[22:28:03] <lu_zero> ok so my free has to be a freep
[22:28:10] <wbs> because for mpegts-in-rtp, the AVStreams aren't created when parsing the SDP, they're created later when the chained mpegts demuxer adds new streams
[22:28:28] <wbs> that might be ok
[22:28:28] <lu_zero> they should be in the same context...
[22:28:47] <BBB> lu_zero: freep() would be ok
[22:28:58] <wbs> yes, but the AVStreams priv_data aren't set up if created that way
[22:30:51] <wbs> hmm, freep() isn't that easy in that case, you must make sure the AVStream->priv_data for the right stream is zeroed
[22:31:14] <lu_zero> uhm?
[22:31:24] <lu_zero> no
[22:31:28] <lu_zero> grrr...
[22:31:38] <lu_zero> freep isn't enough
[22:32:28] <lu_zero> we'd get that pointer dangling nonetheless
[22:32:30] <wbs> for mpegts in rtp, nb_rtsp_streams is 1, while many AVStreams are created (none which have priv_data set to the rtsp_st field), while they're mapped directly and linked via priv_data for "normal" rtp
[22:32:51] <wbs> can we do without setting that pointer to st->priv_data, by always cleaning it up within rtsp?
[22:33:22] <lu_zero> I guess we are keeping around a pointer too much
[22:34:01] <wbs> sdp_parse_line relies on being able to pick it out from st->priv_data though
[22:34:39] <lu_zero> the quickest path is to special case it
[22:34:59] <wbs> yeah, the mpegts stuff is special cased in a few other places, too
[22:35:39] * lu_zero originally wanted to make it uniform but it didn't work that well
[22:36:04] <wbs> it's kinda hard to force the both cases to uniformity yes, when they're almost orthogonally different
[22:36:06] <lu_zero> or I can just make that rtsp_st the st->priv_data
[22:36:34] <wbs> perhaps, but that would leak if no AVStream ever is created
[22:38:37] <Dark_Shikari> jannau: the execution of code differs based on profile_idc
[22:38:49] <Dark_Shikari> if the profile is HIGH 444 PREDICTIVE, we run special intra pred functions
[22:38:52] <Dark_Shikari> if the profile is HIGH 444, we don't
[22:38:57] <lu_zero>             st = s->streams[s->nb_streams - 1];
[22:38:57] <lu_zero>             rtsp_st = st->priv_data;
[22:38:57] <lu_zero>             rtsp_st->sdp_ip = sdp_ip;
[22:38:57] <lu_zero>             rtsp_st->sdp_ttl = ttl;
[22:38:57] <Dark_Shikari> therefore, we CANNOT have them use the same id
[22:39:52] <wbs> lu_zero: that one perhaps could use rt->rtsp_streams[rt->nb_rtsp_streams - 1] instead?
[22:40:54] <lu_zero> I guess I'll figure out tomorrow
[22:40:58] * lu_zero now is too tired
[22:41:06] <Dark_Shikari> mru: ugh, they have a sheevaplug sequel, and it still has a shitty old armv5 I think :>
[22:41:13] * Dark_Shikari prepares for more newbies asking to encode video on them
[22:42:31] <mru> this time it has a fan
[22:42:39] <mru> the sheevaplug had a habit of melting...
[22:42:44] <Sean_McG> ouch
[22:42:45] <Dark_Shikari> lol
[22:43:03] <mru> or more accurately, the caps in the psu blew up
[22:47:23] <_av500_> lu_zero: definitely progress
[22:47:39] <_av500_> does not work 100% but when it does it does
[22:47:50] <mru> is anything holding up ruggles' fmtconvert patch?
[22:48:23] <Sean_McG> also if there aren't any regressions with older compilers, can someone commit 704?
[22:48:36] <lu_zero> _av500_: yet another bug
[22:48:43] <lu_zero> possibly more ugly
[22:48:51] <lu_zero> anyway let me fix what I broke
[22:49:02] <kierank> elenril: found a metadata bug
[22:49:42] <_av500_> lu_zero: the mem leak?
[22:50:09] <wbs> _av500_: which was fixed into a double free for other codepaths..
[22:50:23] <_av500_> yeah, i saw
[22:50:42] <lu_zero> wbs: http://ffmpeg.pastebin.com/C8PHG7YM
[22:50:48] <lu_zero> try that as quick fix
[22:51:16] <_av500_> urg
[22:51:26] <lu_zero> ugly?
[22:51:31] <lu_zero> it is =P
[22:51:33] <_av500_> could have been from me :)
[22:51:51] <Dark_Shikari> http://www.youtube.com/watch?v=oJagxe-Gvpw
[22:52:08] <wbs> lu_zero: works yes
[22:52:09] <ruggles> mru: peloverde gave his ok, and you didn't change much, so i think it's ok to commit
[22:54:37] <lu_zero> patch sent
[22:57:34] <lu_zero> good night
[23:03:10] <jannau> Dark_Shikari: not in ffmpeg. FF_PROFILE_H264_HIGH_444 was not used
[23:04:21] <Dark_Shikari> jannau: The inverse was.
[23:04:23] <Dark_Shikari> != was used
[23:04:34] <Dark_Shikari> h->sps.profile_idc==244
[23:04:36] <Dark_Shikari> in h264.c
[23:04:48] <Dark_Shikari> Unless this is something different?
[23:06:08] <mru> ruggles: you forgot to remove the yasm code from the old place
[23:07:07] <ruggles> didn't you do that in your patch though?
[23:07:21] <mru> I only noticed arm
[23:08:37] <jannau> Dark_Shikari: that's kind of unrelated to the defines. we should replace the number with the symbol though
[23:08:54] <Dark_Shikari> jannau: the problem I mentioned was you were defining HIGH 444 == HIGH 444 Predictive
[23:08:58] <Dark_Shikari> iirc
[23:09:03] <Dark_Shikari> that == check is intended to tell the two apart
[23:09:32] <jannau> latest itu draft say profile_idc==244 HIGH 444 Predictive
[23:09:55] <jannau> and it was the previous value for HIGH 444
[23:10:00] <ruggles> mru: oh, it looks like i did miss the x86 yasm code removal
[23:10:09] <mru> ruggles: I've fixed it here
[23:10:36] <Dark_Shikari> jannau: no it wasn't, that was 144 iirc
[23:10:51] <Dark_Shikari> let me check
[23:11:06] <jannau> no: -#define FF_PROFILE_H264_HIGH_444    244
[23:11:16] <ruggles> mru: great, i don't have time tonight to update/resend.
[23:11:34] <Dark_Shikari> Yup, 144
[23:11:38] <Dark_Shikari> jannau: then that was wrong
[23:11:42] <Dark_Shikari> The spec says 144
[23:12:16] <jannau> ok, I'll change that and remove the VERSION_MAJOR check
[23:12:37] <jannau> and add a string to the profiles
[23:13:29] <jannau> that profile was removed? I haven't seen it in the latest draft
[23:13:36] <Dark_Shikari> Yes
[23:13:38] <Dark_Shikari> It was removed in 2007
[23:13:42] <jannau> ok
[23:13:48] <jannau> thanks
[23:14:02] <mru> ruggles: new patch sent
[23:41:44] <mru> lol, libjpeg v8 is 40% slower than v6
[23:41:54] <Dark_Shikari> lol libjpeg
[23:41:58] <Dark_Shikari> I heard you like the ijg
[23:43:01] <kierank> isn't the ijg just a crazy guy now?
[23:43:14] <mmu> what are they doing new from last year ? 128bit rendering ?
[23:43:33] <mru> v7 is just as slow
[23:45:21] <Dark_Shikari> who is it here who knows stuff about RTP?  Marvell apparently is looking for someone who does.
[23:45:26] <Dark_Shikari> and I'd like to give them a name or something
[23:45:39] <mru> hmm, it's spending that extra time in "jpeg_idct_16x16"
[23:45:59] <iive> Dark_Shikari: lu_zero
[23:46:12] <Dark_Shikari> lu_zero: ping
[23:50:41] <mru> ah, disabling that retarded scaling makes it faster
[23:51:01] <mru> how the fuck did he manage to slow down normal jpeg decoding by 40% when adding that?
[23:52:16] <Kovensky> hm, Marvell...
[23:52:28] * Kovensky remembers fighting with an old Marvell wireless card to get it to work under linux
[23:52:38] * Kovensky ended up having to use ndiswrapper and it would only work on 32bit kernels
[23:52:50] <superdump> mru: scaling stuff?
[23:52:50] <Kovensky> it also would refuse working on nt6+
[23:53:08] <mru> superdump: http://hardwarebug.org/2010/02/01/ijg-swings-again-and-misses/