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

[irc at mansr.com]

[04:56:40] <siretart> mru: pong
[05:58:39] <CIA-7> ffmpeg: mstorsjo * r23012 /trunk/libavcodec/amrnbdec.c:
[05:58:39] <CIA-7> ffmpeg: amrnbdec: Apply AMR_SAMPLE_SCALE when finishing the decoder output
[05:58:39] <CIA-7> ffmpeg: The output scaling was accidentally removed in rev 22937.
[06:40:11] <superdump> morning
[07:53:32] <KotH> salve
[07:53:49] <kshishkov> shalom
[07:56:03] <pJok> god morgon kshishkov :)
[08:00:32] <kshishkov> god morgon (:
[08:01:11] <KotH> juten morjen kshishkov
[08:01:40] <av500> KotH: eek
[09:10:27] <merbzt> tere homikust
[09:10:38] <wbs> tere tulemast
[09:11:54] <kshishkov> ar du i Ingermanland nu?
[09:12:12] <merbzt> vem jag ?
[09:13:05] <kshishkov> "tere hommikust" ar estlandska for "god morgon" eller hur?
[09:13:20] <merbzt> det stämmer
[09:13:58] <merbzt> men, nej jag är inte i Ingermanland
[09:14:28] <ohsix> ikke norsk
[09:23:39] <siretart> calimera!
[09:24:21] * kshishkov was right about German people being incomprehensible
[09:24:59] <siretart> Does anyone know open blockers for creating the 0.6 branch? FATE looks good to me so far
[09:25:10] <siretart> I'm considering creating the 0.6 branch this afternoon
[09:25:44] <DonDiego> i'm afraid i may know one
[09:25:55] <DonDiego> lgpl reimplementation of gpl parts in libswscale
[09:26:03] <DonDiego> let me send an email..
[09:26:41] <siretart> hrmpf
[09:26:42] <siretart> ...
[09:27:09] <DonDiego> not hard to backport in any case
[09:27:16] <DonDiego> i'll get back to you this afternoon
[09:27:21] <siretart> k
[09:32:04] * wbs is waiting for review of the movenc stuff that he'd be happy to have in the 0.6 branch
[09:32:19] <wbs> I've pinged baptiste a few times about it now without any success ;P
[09:32:54] <kshishkov> you can try catching him here late in the evening
[09:33:12] <wbs> yeah, i've tried pinging him on irc, too, but then he's mostly been idle
[09:33:34] <siretart> the plan is to first branch, then track and cherry-pick patches from trunk to branch and then release
[09:34:19] <siretart> picking that patch seems pretty straightforward
[09:49:30] <Kris_eva> Hi All, is there a way to browse patches submitted to ffmpeg?
[09:50:01] <kshishkov> yes, with your eyes, browser and site like news.gmane.org
[09:52:32] <Kovensky> git log?
[09:52:42] <Kris_eva> nice thanks
[09:53:06] <kshishkov> depends on definition of "submitted"
[09:53:36] <av500> Kris_eva: there is no formal patch submission, they are posted on the ML
[09:54:06] <Kovensky> you can also post them here, where you will be directed to post on the ML
[09:54:11] <Kris_eva> hmm I guess you are right
[09:54:40] <Kris_eva> just browsing through news.gmane.org
[09:56:05] <merbzt> Kris_eva: filter on [PATCH]
[09:56:52] <Kris_eva> yaa right...thanks
[10:03:54] <Kris_eva> Thanks fond what Iam looking for
[10:03:59] <Kovensky> or just [PATCH; people that send with git send-patch often end with [PATCH 1/n], [PATCH 2/n], etc
[10:04:19] <Kris_eva> found*
[10:42:41] <DonDiego> siretart: i have permission from michael to commit the lgpl code under #ifdef
[10:42:47] <DonDiego> i'll do that tonight
[10:42:56] <DonDiego> we're good to go then
[10:43:02] <DonDiego> siretart: what about 0.5.2?
[10:43:55] <siretart> DonDiego: I remember I had about 3 patches that I wanted to look at for 0.5.2, that's still open
[10:44:08] <siretart> then we need to consider if what we have is 'enough' for 0.5.2
[11:36:26] <DonDiego> commit those patches then
[11:36:36] <DonDiego> and ask on the ml if anything is pending
[11:56:17] <av500> http://blog.kaourantin.net/?p=89
[12:00:49] <DonDiego> flash is slow nonetheless :)
[12:01:23] <DonDiego> but somebody did indeed manage to light a fire under their behinds..
[12:02:16] <mru> actually, I wouldn't be sorry were flash burned at the stake
[12:02:28] <mru> mike can surely find another job
[12:03:31] <siretart> mru: you pinged my last night?
[12:03:41] <mru> yeah, random ubuntu question
[12:03:52] <mru> someone was complaining about ugly fonts
[12:04:02] <siretart> i see
[12:04:10] <mru> probably cheap, "free" fonts, no hinting, and overzealous AA
[12:04:20] <mru> any simple remedy?
[12:04:34] <mru> like a freetype package with hinting turned on?
[12:04:55] <mru> and a simple way to install, say, the usual windows fonts
[12:05:16] <mru> gentoo does all that of course
[12:05:19] * mru hides
[12:05:21] <astrange> freetype auto hinting isn't terrible especially with subpixel on (which should be default)
[12:05:29] <mru> auto-hinting is terrible
[12:05:36] <mru> compared to using the real hinting
[12:05:36] <astrange> the default font is really bland, though. and i think it's a grotesk too
[12:05:36] <ohsix> sec, i got the package name
[12:05:39] <siretart> you can configure AA in settings->appearance or something. windows fonts and other goodies are installed as sideeffect by installing the metapackage 'ubuntu-restricted-extras'
[12:06:13] <ohsix> apt-get instal msttcorefonts, most things install them already; and its a virtual that brings in the new package (dunno the new name)
[12:06:27] <ohsix> yea what he said
[12:07:21] <av500> mru: what is the exact name of yon tegra board?
[12:08:14] <mru> av500: 180-81162-1000-A02
[12:08:33] <av500> a tad less exact
[12:11:25] <mru> Tegra 250 Developer Kit
[12:11:51] <av500> yup, just found it.
[12:11:53] <av500> thx
[12:12:38] <av500> it boots now?
[12:12:55] <mru> it always booted with the kernel someone flashed for me
[12:13:04] <mru> I haven't been able run any other kernel
[12:14:11] <mru> I need to look into that again
[12:14:26] <av500> ic
[13:15:25] <j-b> astrange: what is the 'official' ffmpeg-mt repo now ?
[14:09:58] <scaphilo> anyone knows if its possible to use qscale (not dquant) for every single macro bock in mpeg4part2. The thing is: mpeg2 to mpeg4part2 openloop transcoder could work without a quantiser if this whould be possible.
[14:10:41] <scaphilo> mpeg2 can do changes in qscale from one mb to an other in every size mpeg4part2 has a maximum change possibility of +/- 2
[14:16:20] <astrange> why do you want to transcode to mpeg4part2? it's a bad idea to inflict any more of that on the world
[14:16:25] <astrange> try x264 ultrafast first
[14:17:19] <mru> he wants to do a bitstream conversion without full decode
[14:17:26] <mru> useless if you ask me
[14:17:43] <scaphilo> i dont really want to i have to :-)
[14:17:58] <scaphilo> and mru is right
[14:18:15] <mru> if you cannot choose what you have to do, you're doing it wrong
[14:18:40] <scaphilo> contract is a contract
[14:18:43] <astrange> and yes you can't convert the delta quant. but the quantizer is slightly different anyway
[14:18:57] <astrange> (no mismatch control)
[14:19:00] <mru> his client clearly doesn't give a toss about quality
[14:19:12] <scaphilo> :-)
[14:19:15] <scaphilo> right
[14:19:24] <scaphilo> you sould be able to watch
[14:20:08] <scaphilo> thx astrange
[14:20:39] <KotH> scaphilo: you know that the cost for inflicting pain (in any form) to a ffmpeg developer is a year ration of swiss chocolate?
[14:20:56] <KotH> scaphilo: so, be carefull what you ask ;)
[14:21:45] <scaphilo> KotH :-)
[14:22:31] <scaphilo> by the way is someone here who used ffmpeg on an ARM arch
[14:22:46] <scaphilo> i compiled for a niosII without an os
[14:23:18] <mru> ffmpeg is well-supported on arm
[14:23:41] <scaphilo> but with linux on it?
[14:23:53] <scaphilo> i mean uclinux or something
[14:24:00] <mru> libavcodec doesn't need an os
[14:24:41] <Kovensky> does it have an fflibc
[14:25:04] <merbzt> we are getting there
[14:25:15] <mru> lavc doesn't use much of libc
[14:26:18] <mru> most importantly, it doesn't do file i/o
[14:26:39] <mru> it needs some kind of malloc of course
[14:26:45] <scaphilo> is there an arm ffmepg project open source arround?
[14:26:45] <mru> which you can easily supply your own
[14:27:05] <mru> plain ffmpeg svn works fine on arm
[14:27:51] <scaphilo> am well didnt you build an main arround ffmpeg?
[14:28:01] <mru> uh?
[14:29:01] <scaphilo> difficult to describe sorry... how do you say ffmpeg to use this memory as input and an other memory as the output?
[14:29:19] <mru> see avcodec.h
[14:30:12] <scaphilo> k ill do that
[15:15:52] <CIA-7> ffmpeg: mru * r23013 /trunk/configure:
[15:15:52] <CIA-7> ffmpeg: configure: allow compiler-specific flags for --disable-optimizations
[15:15:52] <CIA-7> ffmpeg: ICC needs at least -O1 to link so add this when optimisations are
[15:15:52] <CIA-7> ffmpeg: otherwise disabled.
[16:34:37] <lu_zero> uhmm
[16:34:48] <lu_zero> our dv capture is completely outdated...
[16:43:14] <ramiro> twnqx: lu_zero: outdated how?
[16:43:25] <ramiro> oops, twnqx wasn't meant to be there...
[16:43:32] <twnqx> thought so :P
[16:44:55] <ramiro> twnqx: this is the message meant for you: I see from the logs that you had some problems with gentoo and "relocation R_X86_64_PC32 against". was that resolved? (and not the CFLAGS=-fPIC hack)
[16:46:14] <lu_zero> ramiro: dv1394 had been deprecated since ages
[16:46:22] <lu_zero> now you have to use raw access
[16:46:43] <twnqx> ramiro: guess i solved it, but can't remember how
[16:46:49] <twnqx> it's just... computers never win
[16:46:55] <twnqx> as a matter of principle
[16:46:58] <ramiro> lu_zero: IIRC last time I tried I had to use dvgrab...
[16:48:25] <Dark_Shikari> so, this guy is hilarious
[16:48:31] <Dark_Shikari> this guy I just talked to
[16:48:40] <Dark_Shikari> he wants to develop a new STB middleware for a big national telco
[16:48:43] <Dark_Shikari> because all the existing ones suck
[16:49:01] <Dark_Shikari> So he's going to.... go find a dozen grad students who will work for pennies on the dollar and hire them all
[16:49:08] <Dark_Shikari> somehow I don't see this going very well
[16:49:19] <lu_zero> right now I'm trying to not use dvgrab since it seems to introduce a quite annoying desync
[16:49:49] <ramiro> Dark_Shikari: is he brazilian?
[16:50:06] <ramiro> that sounds a hell of a lot like where I work.
[16:50:10] <Dark_Shikari> belgian, I think
[16:50:12] <kierank> the word "middleware" automatically signifies failure to me
[16:50:17] <_av500_> Dark_Shikari: the existing ones were written by mru
[16:50:33] * _av500_ hides
[16:50:38] <Dark_Shikari> ahaha
[16:51:00] <peloverde> I got a new firmware update pushed to my STB and it traded a usable interface for legible text
[16:51:18] <_av500_> you cannot have it all
[16:52:46] <peloverde> wasn't cablecard supposed to bring competition to the cable stb market
[16:53:02] <saintdev> yes, but the cablecos screwed it up
[16:53:26] <saintdev> so the fcc's solution: Let's come up with a new standard!
[16:53:54] <lu_zero> ...
[16:53:56] <lu_zero> bleah
[17:00:09] <Kovensky> ramiro: the usual workaround for that relocation thing is -Wl,-Bsymbolic
[17:00:28] <Kovensky> I don't remember the implications though, mru should know since he explained to me and I forgot :E
[17:01:38] <mru> it makes the linker resolve intra-lib references immediately while building the shared lib
[17:01:51] <mru> so at runtime they don't go through the got/plt
[17:03:12] <ramiro> Kovensky, mru: thanks
[18:15:13] <DonDiego> Yuvi: btw, what about nicking some optimizations from libtheora?
[18:15:54] <mru> do they have any
[18:15:56] <mru> ?
[18:16:01] <DonDiego> mmx IIRC
[18:16:09] <DonDiego> where we (only) have mmx2
[18:16:33] <_av500_> he said the t word
[18:17:31] <DonDiego> is there a contest going on to avoid the name of the codec that share letters with "the oral exam"?
[18:17:35] <DonDiego> :)
[18:24:12] <kierank> hmmm i wonder whether to report to bbc that this dolby app is quietly using libmxf without recognising lgpl
[18:24:28] <DonDiego> do it
[18:25:46] <kierank> does the use of lgpl code nullify the eula's "ban" on reverse engineering. (ignoring any local laws)?
[18:25:59] <DonDiego> no
[18:26:09] <DonDiego> it means that the license is violated
[18:26:22] <DonDiego> because it forbids such restrictions
[18:26:42] <DonDiego> the license == it == lgpl (just to clarify)
[18:27:15] <DonDiego> whether it's nullified or not is a different question i suppose
[18:27:49] <DonDiego> kierank: please report the violation to both the bbc and the libmxf devs
[18:28:03] <kierank> libmxf devs = bbc afaik
[18:28:20] <DonDiego> hmm
[18:28:23] <_av500_> they voilate themselves?
[18:28:34] <DonDiego> no, they cannot violate their own license
[18:28:35] <mru> dolby are the violators
[18:28:50] <kierank> yes neyrinck for dolby e is the app violating it
[18:29:04] <DonDiego> authors are always allowed to use their software in whatever ways they see fit
[18:29:12] <DonDiego> url?
[18:29:29] <kierank> http://neyrinck.com/Pages/scde.html
[18:29:39] <kierank> adds mxf support, which they don't mention is through libmxf
[18:30:18] <kierank> would have been more fun if it was lavf though ;)
[18:32:28] <DonDiego> indeed
[18:48:19] <peloverde> gah, everytime I touch implicit signaling I want to stab myself in the eye
[18:50:45] <iive> peloverde: you have only one eye left?
[18:52:04] <saintdev> he stabbed the other one out working on SBR =p
[18:53:31] <_av500_> no eye left for mp3pro then
[18:55:37] <BastyCDGS> namaste
[18:55:42] <BastyCDGS> how are u guys?
[18:57:01] <jai> :)
[19:00:10] <_av500_> slalom
[19:02:56] <BastyCDGS> shalom ;)
[19:03:42] <BastyCDGS> I am thinking of proper metadata handling
[19:04:05] <BastyCDGS> does ffmpeg charset conservations from any source?
[19:04:26] * mru fails to be enthused by metadata
[19:04:29] <BastyCDGS> thing is that IFF files can have a CSET chunk which tells which charset to use...
[19:05:15] <BastyCDGS> the other thing is that our method fails when a \0 appears in IFF chunk
[19:05:28] <BastyCDGS> because it used C-style strings which terminate at \0
[19:05:54] <BastyCDGS> if someone stores an UTF-16 or similar then we truncate after first char on little endian
[19:06:26] <BastyCDGS> oh not just le on any endianess
[19:06:37] <drv> metadata must be stored as utf-8 according to the api
[19:06:48] <drv> see avformat.h
[19:07:03] <BastyCDGS> that sounds really good, but are there converters for alien charsets to utf-8
[19:07:09] <BastyCDGS> i.e. not just native to utf-8
[19:07:10] <drv> that i do not know :)
[19:08:08] <BastyCDGS> there's always recode etc.
[19:08:15] <BastyCDGS> but that means dependency of external lib
[19:20:59] <elenril> BastyCDGS: there's GET_UTF16 macro
[19:21:34] <elenril> but that's all
[19:22:09] <BastyCDGS> so what I should do then about charset conversation?
[19:22:37] <CIA-7> ffmpeg: alexc * r23014 /trunk/libavcodec/ (aacsbr.c sbr.h): 10l: The SBR refactor requires the use of 2 independent output X buffers.
[19:23:14] * elenril would ignore them ;)
[19:23:55] <BastyCDGS> I can store the original charsets in UTF-8 though, but what to do with \0?
[19:24:29] <wbs> do you have a concrete case where you've got strings that contain null bytes that you absolutely must have represented here?
[19:25:34] <BastyCDGS> no, I just generally was thinking about this.
[19:28:54] <ramiro> huh? online movie rental through download? how are they supposed to keep you from pirating it?
[19:29:21] <mru> some kind of encryption I guess
[19:30:19] <mru> sony are doing it on ps3
[19:30:43] <ramiro> seems to me that if you have some data and some decryption key, you should always be able to decrypt it.
[19:30:56] <ramiro> there would be no restriction of when you can decrypt
[19:31:11] <mru> depends on the platform you're on
[19:31:13] <mru> on a pc, sure
[19:31:13] <BastyCDGS> mru, have you any ideas about dp24?
[19:31:17] <BastyCDGS> dp32
[19:31:21] <mru> the ps3 is different
[19:31:32] <mru> you can't run whatever software you want on it
[19:31:38] <ramiro> hm, makes sense. it's for pc in this case (some brazilian book store)
[19:33:30] <mru> then you can of course break it
[19:38:34] <ramiro> apparently it uses Microsoft's PlayForSure
[19:38:40] <mru> lol
[19:38:58] <ramiro> some microsoft drm something...
[19:39:13] <wbs> wasn't that their drm that they didn't support on their own zune? :-)
[19:40:01] <BastyCDGS> PlayForSureOnDevNull ;)
[19:40:16] <ramiro> wbs: wikipedia seems to confirm
[19:41:39] <ramiro> 1.5 mbps wmv and stereo audio.
[19:49:06] <BastyCDGS> mru, could you verify the be/le issue with rawvideo?
[20:05:46] <_av500_> ramiro: m4 drm is used for video rentals
[20:05:50] <_av500_> err, m$ drm
[20:05:57] <_av500_> wmdrm 10 aka janus
[20:05:58] <mru> m4 drm is used by autoconf
[20:06:03] <_av500_> yes
[20:06:03] <ramiro> lol
[20:06:27] <mru> got that tegra running properly btw
[20:06:43] <_av500_> k
[20:06:50] <_av500_> i will see one tomorrow it seems
[20:06:57] <_av500_> will try to grab it
[20:07:01] <_av500_> and run
[20:08:56] <mru> their ancient 2.6.29 kernel feels modern compared to the 2.6.22 I was battling yesterday
[20:09:00] <mru> stupid sigma
[20:11:05] <_av500_> vendor kernels ftw
[20:11:53] <mru> oh well, I accomplished what I wanted
[20:12:17] <_av500_> one would be surprised that .22 still runs todays binaries....
[20:12:23] <mru> it doesn't
[20:12:29] <_av500_> oh well
[20:12:43] <mru> had to force an old version of linux-headers
[20:13:00] <mru> since I'm building everything myself it's not a problem
[20:14:28] <mru> the omap3 runs ffmpeg much faster
[20:14:40] <mru> might have something to do with neon...
[20:14:53] <_av500_> what the sigma running?
[20:15:05] <mru> mips 74kf
[20:15:10] <mru> 660MHz
[20:15:23] <mru> beagle @ 600 is 1.5-4x faster
[20:15:43] <mru> but then again, we barely have any mips asm at all
[20:16:03] <_av500_> popcorn?
[20:16:12] <mru> ack
[20:17:08] <_av500_> dammit, i enter mips 74kf into google and it finds your blog post...
[20:17:25] <_av500_> they might be evil, but they are good
[20:17:26] <_av500_> :)
[20:31:21] <spaam> mru: fix some mips asm then :)
[20:41:23] <DonDiego> i have a question about the 'inline' keyword
[20:41:38] <DonDiego> is it wise to mark functions as inline nowadays?
[20:41:45] <Dark_Shikari> don't see why not
[20:42:55] <BastyCDGS> I still use inline keyword to strongly recommend the compiler to inline a function
[20:43:12] <DonDiego> i thought common wisdom was to let gcc take those decisions nowadays..
[20:43:46] <DonDiego> and that later in the 4.x series gcc actually got reasonably good at inlining decisions
[20:44:03] <Dark_Shikari> ALWAYS_INLINE is more useful
[20:44:37] <BastyCDGS> gcc does this, but using inline higher prioritizes it a bit...
[20:44:47] <DonDiego> i'm not talking about ffmpeg but in more general terms now
[20:44:56] <Dark_Shikari> same here
[20:45:00] <BastyCDGS> yep
[20:45:08] <DonDiego> ok
[20:45:46] <BastyCDGS> I use such keywords however, to indicate less quality optimizing compilers what they should do
[20:49:46] <mru> inlining of non-marked funcs depends on -O level iirc
[20:50:56] <peloverde> I got a huge speedup in aac main inlining a function that gcc should have been smart enough to inline on it's own
[20:51:46] <BastyCDGS> I also got different speed results when using inline while we tried  dp8 optimization
[20:52:30] <DonDiego> k
[20:58:41] * Kovensky usually puts inline on functions he expects to be inlined
[21:08:36] <DonDiego> offtopic: http://www.youtube.com/watch?v=cL2QyGD1oMI
[21:08:46] <DonDiego> the bane of my childhood memories
[21:09:13] <DonDiego> we would go visit my uncle and aunt in paris
[21:09:19] <BastyCDGS> good night guys, have to get some sleep now
[21:09:40] <DonDiego> and when the kids my cousin played with heard my name, they started singing the song from this commercial..
[21:10:34] <BastyCDGS> wow
[21:10:44] <BastyCDGS> nice video
[21:21:35] <spaam> DonDiego: you like that song ? :)
[21:22:28] <DonDiego> i hate it of course!
[21:22:45] <DonDiego> it was the bane of my visits to my cousin
[21:22:56] <DonDiego> well, actually nowadays it's funny..
[21:41:07] <BBB> holy shit, I'm installing xbmc and it really is like an identical twin of gstreamer, it wraps everything, I mean seriously EVERYTHING
[21:41:26] <BBB> it links against all kind of libraries that provide duplicate functionality with ffmpeg
[21:41:35] <BBB> it's a little weird that they don't know that
[21:41:40] <_av500_> its wrappers all the way down
[21:42:06] <BBB> doesn't that make you cry?
[21:42:14] <BBB> I mean imagine you're on a mac, which doesn't come with any of these deps
[21:42:20] <BBB> I've been sudo port install'ing for 2 days now
[21:42:27] <BBB> and I'm still not at a stage where configure finishes
[21:43:38] <_av500_> :)
[21:44:01] <_av500_> i know, one of the xbmc guys is doing gsoc for beagle
[21:44:16] <_av500_> and koen tried to cross build xbmc
[21:44:30] <_av500_> the list of deps was impressive
[21:44:53] <peloverde> I looked at xmbc and decided it looked like a disaster
[21:45:06] <peloverde> in particular the whole "PAPlayer" vs "DVDPlayer" thing
[21:45:12] <_av500_> yeah
[21:45:26] <_av500_> but u know, paplayer can wrap dvdplayer
[21:45:43] <_av500_> or was it the other way round
[21:47:59] <peloverde> The documentation says that it falls back to DVDPlayer if PAPlayer can't play the file
[21:50:13] <_av500_> dunno the details
[21:50:28] <_av500_> but they have faad, vorbis, mad AND lavc
[21:50:48] <BBB> what's paplayer?
[21:50:57] <peloverde> http://wiki.xbmc.org/index.php?title=PAPlayer
[21:51:01] <_av500_> the audio player of xbmc
[21:51:09] <BBB> and what's dvdplayer?
[21:51:28] <mru> _av500_: correction: the ffmpeg list of deps is impressive
[21:51:35] <peloverde> the video player part of xbmc
[21:51:43] <BBB> because it's minimal? :)
[21:51:47] <mru> any troll can write an app that uses at least one function from every lib he has heard of
[21:51:48] <BBB> ffmpeg is impressive. period.
[21:51:50] <mru> in fact, many do
[21:52:24] <BBB> yeah
[21:52:28] <BBB> xbmc uses liblzo
[21:52:35] <_av500_> gee, liba52, alac, libdca, libflac
[21:52:48] <twnqx> all only if wanted!
[21:53:01] <_av500_> dead or alive
[21:54:02] <peloverde> My question is if they use lavc why do they need all the one codec libs, do they all offer significant features that are missing in lavc
[21:54:20] <kierank> nothing can be as bad as k-lite
[21:54:53] <kierank> adds an extra ac-3 decoder because of "bugs" in ffmpeg. Same with mpeg-2. Guy who runs the codec pack doesn't want to reveal said bugs :/
[21:56:29] <peloverde> meh, xbmc has external mpeg-2 and ac-3 and a ton more
[21:57:18] <CIA-7> ffmpeg: stefano * r23015 /trunk/libavutil/ (error.c error.h):
[21:57:18] <CIA-7> ffmpeg: Make av_strerror() print an error message mentioning the error code
[21:57:18] <CIA-7> ffmpeg: number if strerror_r() did not succeed for whatever reason.
[21:57:18] <CIA-7> ffmpeg: This avoids the need for the application to fill the string in case
[21:57:18] <CIA-7> ffmpeg: strerror_r() fails, for example because the error code is not known.
[21:57:28] <kierank> the k-lite guy also adds ACM and VCM versions where available for some bizzare reason
[21:57:40] <Dark_Shikari> because more codecs is better!!
[21:58:01] <BBB> well
[21:58:01] <BBB> k
[21:58:02] <BBB> ie	
[21:58:04] <BBB> oops
[21:58:07] * BBB kicks irc client
[21:58:31] <BBB> kierank: it's true that I've seen in the past that if you incorrectly used the mpeg video parser with the ffmpeg decoder, it'd lead to very weird behaviour
[21:58:37] <BBB> I figured out a fix after a while
[21:58:42] <BBB> but that could well be what he's seeing
[21:58:46] <peloverde> even VLC requires MAD to be explicitly disabled
[21:58:47] <BBB> it's simply incorrect use of api
[21:59:03] <BBB> several people have said mad is qualitatively better than ffmpeg
[21:59:09] <BBB> that is a good reason
[21:59:27] <BBB> mp3 is still the biggest codec in the world
[21:59:30] <peloverde> based on what?
[21:59:37] <peloverde> do we not conform?
[21:59:47] <BBB> we're fixedpoint, mad is floatingpoint? I dunno
[22:00:09] <DonDiego> mad is fixedpoint
[22:00:10] <kierank> have listening tests been done?
[22:00:20] <DonDiego> slower than ffmpeg though
[22:00:51] <mru> mp3 is so shit the quality of the decoder is irrelevant
[22:00:54] <peloverde> strict metrics of conformance should be used, not vague sounds better
[22:01:29] <mru> mad decodes to 32-bit and downscales to 16-bit with some dithering
[22:01:32] <astrange> mad is fixedpoint and decodes more bits than ffmp3
[22:01:36] <mru> that's the only difference I know of
[22:01:42] <mru> fixed or float is irrelevant
[22:01:47] <mru> ffmp3 is fixed-point too
[22:02:31] <BBB> ffmp3 is 16bit?
[22:02:31] <mru> and much faster than libmad on many machines
[22:02:42] <mru> ffmp3 doesn't dither
[22:02:45] <mru> afaik
[22:02:51] <BBB> but is is 32 or 16bit?
[22:03:01] <mru> it uses more than 16 bits internally
[22:03:05] <mru> output is always 16
[22:03:11] <mru> mad can output 24 bits
[22:03:12] <BBB> hm...
[22:03:32] <mru> but we could just slap 8 random bits after those 16 and call it 24
[22:03:36] <mru> nobody would notice
[22:03:41] <mru> seriously
[22:03:59] <astrange> mad outputs 28 bits in 32 bits, i think
[22:04:06] <mru> 28, lol
[22:04:30] <mru> most people can't even hear 16 bits worth of precision
[22:04:37] <mru> and nobody can hear more than 20
[22:05:01] <kierank> [23:04] <@mru> but we could just slap 8 random bits after those 16 and call it 24 --> do that in audiphile_kiddy_mode
[22:05:09] <peloverde> when most mp3 is from cd source at best, more than 16-bits is completely irrelevant
[22:05:42] <peloverde> VLC also requires liba52
[22:06:22] <peloverde> is something broken about ffa52?
[22:07:16] <kierank> ask j-b
[22:07:22] <janneg> it's quieter
[22:08:07] <peloverde> quieter?
[22:09:32] <CIA-7> ffmpeg: rbultje * r23016 /trunk/libavcodec/iff.c: Revert r22974 int->unsigned parts that don't have any meaningful effect.
[22:09:33] <peloverde> Is it quieter than the a52 spec? or is liba52 lounder than the a53 spec?
[22:09:46] <peloverde> or does one of them ignore some sort of mixing/gain control metadata
[22:13:33] <janneg> 5.1 -> stereo downsampling. I think liba52 is louder, ffa52 downsampling is spec conformant afaik
[22:14:22] <j-b> peloverde: ping
[22:14:38] <j-b> peloverde: IIRC, we use liba52 for some weird reasons about SPDIF
[22:14:56] <j-b> and liba52 in vlc is not exactly used as a codec, but a "converter"
[22:15:02] <j-b> same goes with libdca
[22:15:56] <j-b> janneg: I don't see any difference now between liba52 and ffa52, but I can retry with VLC 1.1.0 and my 5.1 and 2.0 setup, if someone needs it.
[22:16:30] <j-b> and I haven't followed the discusion so far, so, pelase sorryr :)
[22:17:17] <mru> when sending ac3 directly to spdif, you don't need any decoder
[22:18:09] <janneg> j-b: that's in mythtv. and I haven't checked in a long time
[22:18:28] <janneg> you still need a parser
[22:18:33] <j-b> yes
[22:19:03] <j-b> I am clearly not saying it is the best solution now, I am just stating a fact.
[22:19:18] <j-b> and trying to explain it.
[22:19:48] <mru> liba52 doesn't provide a parser
[22:20:02] <mru> there's a function to parse a frame header, sure
[22:20:02] <_av500_> j-b: you got a beer drinking vlc meeting tomorrow night?
[22:20:10] <mru> but you have to do all the frame splitting yourself
[22:20:19] <j-b> _av500_: nope
[22:20:22] <_av500_> dmn
[22:20:32] <mru> _av500_: going to paris?
[22:20:39] <_av500_> i am
[22:20:40] <j-b> _av500_: but we can drink one
[22:20:55] <_av500_> im in paris now
[22:20:58] <_av500_> and tomorrow
[22:21:17] <_av500_> j-b: i will ping you, need to know if boss has special plans
[22:21:30] <j-b> cool, please do...
[22:21:36] <_av500_> j-b: where are you in paris?
[22:21:39] <j-b> vitor is in paris too, right?
[22:21:48] <j-b> _av500_: mostly east of Paris
[22:22:19] <_av500_> mru: get a cheap flight, there is still time, i know that irish pub...
[22:23:08] <mru> hehe
[22:26:04] <mru> £150 is the cheapest return...
[22:27:21] <_av500_> a steal
[22:27:30] <mru> expensive beer
[22:28:07] <BBB> holy shit xbmc is a wrapper of everything
[22:28:20] <mru> does it wrap itself?
[22:28:21] <_av500_> didnt you say that already
[22:28:22] <BBB> I should tell some phycisists about this, this could be what they've been looking for for ages
[22:28:28] <_av500_> lol
[22:28:29] <BBB> IT'S STILL CONFIGURING
[22:28:44] <_av500_> is it NP complete?
[22:28:55] <BBB> this is so complex, it might pass the turing test
[22:29:10] <BBB> I mean, for every file you throw at it, it has so many decoders it can decode it with
[22:29:16] <_av500_> speak slowly to it
[22:29:18] <BBB> that's almost intelligent
[22:31:52] <BBB> omg it compiles every submodule with -lmysqlclient
[22:32:06] <BBB> EVEN FFMPEG AND ALL ITS INTERNAL CODECS
[22:32:14] <BBB> (like dts/a52/etc.)
[22:33:44] <j-b> BBB: mplayer, ffmpeg, flash, some part of xine, some parts of vlc, now their own decoder engine, some dshow loader from gstreamer
[22:33:57] <j-b> and now, Boxeee is even worse
[22:34:10] <BBB> the dshow loader from gst that I took from xine?
[22:34:16] <BBB> (I wrote that :) )
[22:34:26] <BBB> that is hilarious
[22:34:42] <BBB> you know it plays only 3 codecs: wmapro, wmavoice and qdm2
[22:34:51] <BBB> all of which are now in ffmpeg :)
[22:35:06] <peloverde> BBB, ffqdm2 is a little fuzzy
[22:35:06] <BBB> oh, and some video codec
[22:35:14] <BBB> I think it does vc1 also
[22:35:17] <BBB> which ffmpeg also does
[22:35:40] <j-b> astrange: where is the official source of ffmpeg-mt? We have enabled it in VLC;..
[22:36:44] * BBB kicks xbmc
[22:36:49] * j-b lols
[22:36:51] <BBB> stupid system can't deal with spaces in filenames
[22:37:08] <BBB> my dir was called "source full", and it fails on "cp" somewhere because it got 3 arguments
[22:37:27] <BBB> maybe I should report bugs to them
[22:37:49] <astrange> http://gitorious.org/~astrange/ffmpeg/ffmpeg-mt
[22:37:59] <astrange> i haven't integrated that patch you gave me yet :/
[22:38:04] <j-b> astrange: no need :D
[22:38:23] <j-b> astrange: no more patching of ffmpeg-mt, just the normal one + vlc git master
[22:38:33] <j-b> astrange: cleaner patch :)
[22:38:58] <j-b> astrange: I have around 20% speed-ups here, no idea if it is normal or not
[22:39:32] <astrange> usually more if you're decoding as fast as possible
[22:39:51] <j-b> ok. Still testing it.
[22:42:32] <BBB> omg configure finished \o/
[22:42:39] <BBB> that took only 3 days
[22:42:46] <BBB> let's see how often make bails out
[22:42:47] <BBB> ...
[23:28:09] <peloverde> Is there a nice way in git to fastforward an inactive (not currently checkedout) branch to a commit?
[23:28:55] <Dark_Shikari> mru: ping
[23:29:03] <mru> peloverde: git branch -f
[23:29:04] <mru> Dark_Shikari: pong
[23:29:36] <Dark_Shikari> Should the ipad (1ghz ARM Cortex-alike) be able to decode h264 realtime at 1024x768?
[23:29:39] <Dark_Shikari> with ffmpeg
[23:30:21] <mru> might depend on encoding parameters and memory speed
[23:30:36] <mru> give me a test file and I can try on a 1GHz cortex-a8
[23:30:41] <peloverde> gratzi
[23:48:37] <DonDiego> gnite
[23:49:40] <peloverde> WTF C++ https://connect.microsoft.com/VisualStudio/feedback/details/520043/error-converting-from-null-to-a-pointer-type-in-std-pair?wa=wsignin1.0#tabs
[23:52:04] <Dark_Shikari> mru: I just upscaled some representative content from 800x600
[23:52:06] <Dark_Shikari> should be good enough
[23:52:15] <Dark_Shikari> the people testing this were reporting decoding times per frame around 60ms
[23:52:20] <Dark_Shikari> which seems a bit high
[23:52:55] <Dark_Shikari> I also wonder how coreavc performs by comparison
[23:53:01] <Dark_Shikari> especially given our extremely specific requirements
[23:53:25] <Dark_Shikari> mru: http://mirror05.x264.nl/Dark/test.h264
[23:53:37] <Dark_Shikari> contains a mix of zero-motion and high motion
[23:53:45] <Dark_Shikari> I would assume that if something lags, it's going to be the high motion.
[23:54:24] <Dark_Shikari> hmm, oops, forgot the multislicing.
[23:54:25] <Dark_Shikari> brb
[23:55:25] <Dark_Shikari> I heard you like frames with 81 slices
[23:55:38] <mru> huh?
[23:55:48] <Dark_Shikari> the first frame in the clip I'm uploading has 81 slices
[23:57:08] <Dark_Shikari> ok, http://mirror05.x264.nl/Dark/test.h264 is up
[23:57:31] <mru> Too many slices, increase MAX_SLICES and recompile
[23:58:47] <mru> why so many slices?
[23:59:52] <mru> ok, rebuilt with MAX_SLICES=128