[FFmpeg-devel-irc] IRC log for 2010-07-27

[irc at mansr.com]

[07:10:39] * Terminating due to: TERM
[07:10:52] * /join #ffmpeg-devel ...
[07:10:55] *** TOPIC: Welcome to the FFmpeg development channel. | Discussions about the development of FFmpeg itself are ontopic here. | Questions about using FFmpeg or developing with the libav* libraries should be asked in #ffmpeg. | FFmpeg 0.6 has been released! | This channel is now publicly logged.
[07:10:55] *** TOPICINFO: peloverde!~alex at cpe-173-88-148-20.neo.res.rr.com, 1276886498
[07:19:28] <CIA-92> ffmpeg: stefang * r24533 /trunk/ (9 files in 4 dirs): add Chinese AVS encoding via external library libxavs
[07:28:37] <kshishkov> hmm, somebody should convince DS to augment x264 with AVS, VP8 and RV3/4 and whatever H.264 ripoff we encounter in the future
[07:29:53] <av500> binkHD?
[07:30:01] <Dark_Shikari> I'd add VP8 support for, hmm
[07:30:05] <Dark_Shikari> $200k?
[07:30:22] <mru> that's cheap
[07:30:34] <mru> google paid $100M for a much worse encoder
[07:30:49] <kshishkov> av500: write to Jeff from RAD, he may also entertain that idea
[07:30:51] <Dark_Shikari> I'd take $1m too
[07:30:56] <saintdev> mru: lol
[07:31:10] <mru> saintdev: well, they did!
[07:31:26] <kshishkov> mru: they got some other codecs as a bonus
[07:31:33] <saintdev> that's why it's funny
[07:31:57] <saintdev> although they did get a few patents along with that.
[07:33:58] <kshishkov> mru: so it's $99999999.99 for a codec
[07:44:04] <merbzt1> anyone in patch apply mode ?
[07:45:18] <kshishkov> unlikely
[07:46:45] <CIA-92> ffmpeg: benoit * r24534 /trunk/tests: Add base64 to the svn:ignore list.
[07:47:23] <mru> benoit-: thanks
[07:48:05] <CIA-92> ffmpeg: benoit * r24535 /trunk/libavcore:
[07:48:05] <CIA-92> ffmpeg: Fill svn:ignore list for libavcore.
[07:48:05] <CIA-92> ffmpeg: Add *.d, *.ho and libavcore* to the ignore list.
[07:50:25] <merbzt1> I forgot to apply the dca patches yesterday
[08:04:00] <CIA-92> ffmpeg: mru * r24536 /trunk/libavformat/Makefile: libavformat needs libavcore
[08:06:24] <Yuvi> libavcore is really annoying me with it adding two keys to my tab-completion of libavcodec :(
[08:06:33] <mru> +1
[08:06:42] <mru> libavfilter did the same
[08:07:17] <av500> +2
[08:07:50] <av500> i find the libav prefix annoying anyway
[08:07:54] <av500> inside the source tree
[08:08:03] <mru> what I _really_ hate in names is when a name requires several completion steps
[08:08:15] <av500> typing cor+tab is ok
[08:08:22] <av500> or cod+tab
[08:08:26] <av500> or for+tab
[08:08:32] <mru> so set up some bash completion rules
[08:08:34] <mru> can't be that hard
[08:08:39] <mru> and emacs of course
[08:08:48] <av500> gee, how do I do that in notepad.exe?
[08:09:02] <funman> no plans on ffsh?
[08:09:02] <mru> notepad with tab completion?
[08:09:11] <mru> funman: nope, posix shell is just fine
[08:09:32] <av500> mru: it says: C:\, what do I do now?
[08:09:40] <elenril> posix shell has programmable completion?
[08:09:51] <mru> elenril: of course not
[08:10:04] <mru> posix shell is useless interactively
[08:11:48] <elenril> then ffsh is obviously needed
[08:16:55] <CIA-92> ffmpeg: mstorsjo * r24537 /trunk/libavformat/rtpdec_xiph.c:
[08:16:55] <CIA-92> ffmpeg: rtpdec_xiph: Drop RTP packets that come in without a prior fragment start marker.
[08:16:55] <CIA-92> ffmpeg: This can avoid segfaults in some cases.
[08:16:55] <CIA-92> ffmpeg: Patch by Josh Allmann, joshua dot allmann at gmail
[08:22:16] <CIA-92> ffmpeg: mru * r24538 /trunk/libavformat/raw.c:
[08:22:16] <CIA-92> ffmpeg: Remove duplicate initialiser for cavsvideo_muxer.extensions
[08:22:16] <CIA-92> ffmpeg: The extensions field was initialised first to "cavs", then to "avs".
[08:22:16] <CIA-92> ffmpeg: The name "cavs" is kept since this is used for the format elsewhere
[08:22:16] <CIA-92> ffmpeg: and "avs" is already used for avisynth files.
[09:05:34] <lu_zero> j0sh: the extradata depends on the file being packetized
[09:27:36] <saintdev> peloverde: oh wow, this seems to be a LOT more sensitive than itunes or nero
[09:42:23] <saintdev> huh, you would think with 2-pass nero would be able to improve the window decision :/
[09:42:46] <kshishkov> why should it?
[09:43:16] <saintdev> because it could store information about the attacks for use on the second pass
[09:43:42] <kshishkov> second pass is mostly for refining quantizers/codebooks in any codec
[09:44:16] <merbzt1> window decision just need a 2-4 frames lookahead
[09:45:33] <saintdev> less :P
[09:46:11] <merbzt1> depends on the frame size o)
[09:46:13] <kshishkov> my codec manages it with one frame of lookahead. Never mind its quality though
[09:46:36] <saintdev> kshishkov: LAME only uses one frame lookahead
[09:47:05] <saintdev> so it's in good company ;)
[09:47:42] <kshishkov> lookahead is only needed for using transitional windows on frame before the one with short windows
[10:07:00] <saintdev> hmm, it almost seems like nero isn't using any lookahead
[10:07:50] <saintdev> it reacts to most things 1 frame behind itunes/ffaac-lame
[10:09:23] <CIA-92> ffmpeg: cehoyos * r24539 /trunk/ (libavcodec/mpegaudiodec.c libavformat/mp3.c):
[10:09:23] <CIA-92> ffmpeg: Show correct bitrate for VBR MP3 files.
[10:09:23] <CIA-92> ffmpeg: Patch by Alexander Kojevnikov, alexander kojevnikov com
[10:11:56] <CIA-92> ffmpeg: cehoyos * r24540 /trunk/libavformat/mp3.c:
[10:11:56] <CIA-92> ffmpeg: Make frames unsigned.
[10:11:56] <CIA-92> ffmpeg: Patch by Alexander Kojevnikov, alexander kojevnikov com
[11:32:43] <merbzt1> hmm, how about we add a few sec holes in the ffmpeg code crome uses and then we fix them
[11:33:14] <merbzt1> for $3133.7 per bugfix
[11:33:40] <cartman> merbzt1: not a bad idea
[11:34:16] <mru> I'm sure we can find some already there
[11:36:32] <merbzt1> http://blog.chromium.org/2010/07/celebrating-six-months-of-chromium.html
[11:37:53] <merbzt1> not sure lavc stuff is included
[11:38:17] <merbzt1> but if it is, it might actually be worth it looking for some bugs
[11:38:31] <av500> btw, following the current trend, shouldnt we run ffmpeg in a sandbox as well?
[11:38:43] <merbzt1> up to the user
[11:38:53] <mru> I thought ffmpeg was just a big sandbox
[11:38:57] <mru> full of bickering kids
[11:39:18] <av500> true, but we can advertise said sandbox now as being more secure :)
[11:39:19] <merbzt1> but imo never feed ffmpeg unknown data
[11:40:09] <merbzt1> to many code paths that havn't been tested enough
[11:43:52] <mru> I bet there are code paths in ffmpeg that have never been executed
[11:44:31] <kshishkov> well, we are known for supporting obscure formats
[11:45:00] <mru> I'd like to think every major feature has been invoked at least once
[11:45:28] <mru> but rare error conditions might not ever have been triggered
[11:45:30] <merbzt1> we need fate tests for everything
[11:45:52] <mru> we should really test with a random-malloc-fail wrapper
[11:46:39] <mru> and record the prng seed for each run so it can be reproduced
[11:47:03] <kshishkov> for example, "range" field in DCA should not be read for XCh. lavc decoder does but so far nobody complained about bitstream decoding errors
[11:47:32] <av500> what? DCA is wrong? I want my money back!!!
[11:47:40] <merbzt1> kshishkov:  ?
[11:47:52] * kshishkov hands av500 a scan of 5rp coin
[11:47:54] <mru> av500: you didn't pay for XCh, you paid for a neon qmf filter
[11:48:34] <mru> speaking of testing, has everybody seen the new fate?
[11:48:40] <mru> http://fate.mansr.com/
[11:49:16] <kshishkov> merbzt1: in subframe header parsing function s->dynrange_coef should not be read when base_channel!=0 but no such situation occured so far
[11:50:08] <kshishkov> hmm, what about old x86 ? It's still in active undead state
[11:50:34] <mru> you want tests for x86_32?
[11:50:38] <mru> that can be arranged
[11:50:42] <Vitor1001> mru: I'm thinking about increasing FUZZ to 2 for ra288 and vorbis-18
[11:50:52] <mru> vorbis-18 was approved
[11:50:54] <av500> mru: it misses a longsoon entry
[11:51:06] <mru> Vitor1001: feel free to do it
[11:51:10] <kshishkov> mru: I'd like x86_<=32 dead
[11:51:26] <wbs> can that be arranged, too?
[11:51:34] <mru> with a shovel, I bet
[11:51:47] <Compn> the new fate without ... mingw :P
[11:51:49] * kshishkov can donate "Gdium" brand of shovel
[11:52:03] <mru> I'll add more machines
[11:52:11] <merbzt1> mru: can you add a warning count ?
[11:52:20] <mru> merbzt1: compiler warnings?
[11:52:28] <merbzt1> from the compile log
[11:52:30] <merbzt1> yes
[11:52:41] <mru> as from grep -ci warning?
[11:52:51] <merbzt1> guess that would work yes
[11:53:04] <mru> I can add almost anything
[11:53:19] <mru> I wanted to get something up and running quickly
[11:53:56] <merbzt1> it looks nice
[11:54:01] <Vitor1001> mru: Now you can also shout "patch welcome" for new features ;)
[11:54:04] <CIA-92> ffmpeg: vitor * r24541 /trunk/tests/fate2.mak:
[11:54:04] <CIA-92> ffmpeg: Increase error tolerance for RA288 and one vorbis test. Should fix some
[11:54:04] <CIA-92> ffmpeg: failures in PPC and ARM.
[11:54:30] <mru> Vitor1001: true, but I don't want too many patches just yet
[11:54:37] <mru> I have some ideas I'd like to implement first
[11:54:52] <Vitor1001> sure
[11:55:11] <Vitor1001> Anyway, I'm very happy already of being able to easily add new tests
[11:55:19] <mru> Vitor1001: it's curious that ra288/pps only fails with some gcc versions
[11:55:38] <mru> anybody want to try running some tests?
[11:55:53] <Vitor1001> mru: Yes, that should be something about the order operations are done.
[11:55:57] <mru> I should probably document how it's done
[11:56:09] <Vitor1001> What kind of tests?
[11:56:26] <mru> I meant fate2 runs
[11:56:36] <mru> all you need is in the ffmpeg repo
[11:57:38] <Vitor1001> Well, obviously everything passes here...
[11:58:01] <mru> do you have any interesting hw/os?
[11:58:08] <Vitor1001> AMD
[11:58:36] <Vitor1001> AMD Athlon(tm) 64 X2 Dual Core Processor 5600+
[11:58:39] <CIA-92> ffmpeg: mru * r24542 /trunk/tests/fate.sh: fate: clean up also after failed runs
[11:58:41] <Vitor1001> Besides my core2
[11:58:42] <av500> mru: I have that even crappier longsoon if you need it :)
[11:59:04] <mru> Vitor1001: I think my i7 covers intel/linux
[11:59:24] <kshishkov> av500: it's unlikely to be crappier but motherboard may
[11:59:38] <Vitor1001> Yes, there is no code specific to AMD boxes that supports SSE
[11:59:40] <mru> av500: the one with the incompatible chipset?
[12:00:05] <merbzt1> mru: can you do 32bit builds on the core i7 also ?
[12:00:09] <mru> merbzt1: sure
[12:00:42] <Vitor1001> mru: BTW, I also tried valgrind and it works fine, besides a leak in atrac3 I had to fix.
[12:01:02] <merbzt1> Vitor1001: tnx for that
[12:01:05] <mru> who runs the valgrind fate currently?
[12:01:16] <av500> mru: the old elonex one
[12:01:29] <Vitor1001> Michael Kostylev
[12:02:10] <av500> mru: http://www.theregister.co.uk/2008/05/23/china_cheap_eee_clone/
[12:02:11] <Vitor1001> merbzt1: No problem, it was pretty easy to fix :)
[12:03:19] <KotH> av500: rotfl.. 128mb ram... 1gb flash... my pc i bought 11y ago had more
[12:07:16] <Compn> 128mb ? that ought to be enough for anybody! ;p
[12:07:18] <Vitor1001> kshishkov: Can you have a look at issue2089? It blocks me from fate-testing musepack...
[12:07:33] <Compn> thats what adobe needs, a dedicated dsp for flash
[12:08:41] <twnqx> KotH: my first pc had 100MB hdd, 4MB ram and 1MB vga!
[12:08:54] <twnqx> and 40mhz, no fpu!
[12:09:19] <mru> fpu? flash processing unit?
[12:09:47] <mru> my first pc has 12MHz 286, 640k ram, 40M disk
[12:09:58] <mru> vga
[12:10:08] <Vitor1001> mru: fate2 pass in my AMD compiling with "--disable-sse" to force it to use 3dnow
[12:10:27] <mru> it could run wolfenstein 3d much to the annoyance of a classmate who had a 386 with ega graphics
[12:12:43] <kshishkov> Vitor1001: ok, I'll try
[12:12:59] <Vitor1001> kshishkov: thx
[12:14:30] <twnqx> lol mru :)
[12:14:34] <twnqx> my first was a 386/40
[12:14:50] <twnqx> and no 387!
[12:15:09] <twnqx> (also, no weitek 3167 or whatever it was)
[12:15:16] <kshishkov> my family could afford computer only when i586 appeared
[12:15:18] <mru> oh, and borland c 2.0
[12:15:36] <kshishkov> mru: I think it was called Turbo C 2.0 then
[12:15:46] <mru> maybe
[12:15:57] <mru> it said borland all over it too
[12:19:46] <KotH> boys, you're getting old
[12:20:44] <kshishkov> KotH: sometimes I feel extremely old
[12:21:24] <microchip_> kshishkov: use your anti-aging hypo spray :P
[12:24:59] <kshishkov> microchip_: never heard of it
[12:25:11] <kshishkov> leave it for Stallman anyway
[12:25:12] <microchip_> kshishkov: that's why you're old :P
[12:25:50] <KotH> microchip_: do you mean rohypnol?
[12:27:40] <microchip_> KotH: no, that's a date-rape drug, used by spaam ;)
[12:28:06] <spaam> no
[12:28:11] <spaam> microchip_: dont lie
[12:28:37] <microchip_> spaam: we know your secrets :p
[12:29:01] <spaam> no
[12:43:40] <kshishkov> Vitor1001: for now it looks like bitstream reading overrun, I'll try to figure it out at home if I have free time
[12:45:37] <Vitor1001> Ok. If you also find a sample for both codecs that don't overrun (ie, properly cropped) and small (less than 1mb of decoded raw pcm), it would also do the trick
[12:48:18] <kshishkov> MPC8 can be cut easily since it has internal structure - frames and such, MPC7 don't even align frames to byte boundary
[12:51:31] <Vitor1001> kshishkov: -acodec copy would work?
[12:52:40] <Vitor1001> kshishkov: nevermind, we don't have a mpc muxer.
[12:53:36] <kshishkov> actually my demuxer has to pad frames to make it work
[12:54:36] <kshishkov> whoever designed MPC SV1-7 was too concerned with saving bits
[12:55:04] * KotH would rather try to save kittens
[12:55:09] <Honoome> kshishkov: do you know the flac header, yeah?
[12:56:19] <Vitor1001> kshishkov: Wait, it doesn't overread just the last frame but every single one. Maybe the padding isn't big enough?
[12:57:54] <kshishkov> Honoome: MPC7 also has all frames as P-frames
[12:58:15] <Honoome> kshishkov: a 21-bit field on a flamin' lossless format!
[12:58:16] <kshishkov> Vitor1001: could be, I'll check
[13:11:54] <CIA-92> ffmpeg: stefano * r24543 /trunk/ (6 files in 2 dirs): Add the indevs.texi and outdevs.texi files.
[14:11:15] <peloverde> saintdev: 1 frame of look ahead should be sufficient
[14:14:20] <CIA-92> ffmpeg: alexc * r24544 /trunk/libavformat/avformat.h: Document existing rules for AVInputFormat.name.
[14:21:28] <peloverde> :)
[14:33:56] <lu_zero> hi jrmuizel
[14:33:56] <jrmuizel> lu_zero: hey
[14:34:43] <lu_zero> I was wondering if would be acceptable a patch for firefox to use libavcodec to cover webm
[14:34:55] <lu_zero> (and libavformat)
[14:35:36] <mru> lu_zero: acceptable to whom?
[14:35:48] <CIA-92> ffmpeg: stefano * r24545 /trunk/libavformat/allformats.c:
[14:35:49] <CIA-92> ffmpeg: Place the concat protocol entry at the begin of the registered
[14:35:49] <CIA-92> ffmpeg: protocol list, restore alphabetical order.
[14:36:26] <jrmuizel> lu_zero: unfortunately lgpl isn't compatible with our licensing terms
[14:37:03] <lu_zero> ah
[14:37:41] <lu_zero> how you managed to use gtk+ then?
[14:37:54] <lu_zero> exception clause from them?
[14:38:00] <jrmuizel> we don't distribute gtk
[14:39:56] <jrmuizel> there's been noises about changing our policies to allow shipping things that aren't compatible with the tri-license but nothing concrete thus far
[14:39:57] <lu_zero> so the problem is just with distribution
[14:40:08] <jrmuizel> yep
[14:40:27] <jrmuizel> afaik anyways, I'm not a lawyer
[14:40:33] <lu_zero> so as compile time option it would survive
[14:40:45] <lu_zero> but you won't enable it on the official builds
[14:41:05] <BBB> jrmuizel: mozilla?
[14:41:11] <jrmuizel> BBB: yes
[14:41:42] <lu_zero> mru: do we have benchmarks regarding png and jpeg on arm?
[14:42:17] <jrmuizel> lu_zero: well I don't think it could really be put into our source tree, but certainly it would be possible to link against a system libavcodec
[14:42:29] <av500> lu_zero: >10mpixel/s here
[14:42:45] <av500> but its on the dsp :)
[14:42:47] <mru> is that the new unit of decoder speed?
[14:42:59] <av500> its the one we use for jpef
[14:43:00] <av500> its the one we use for jpeg
[14:43:46] <BBB> jrmuizel: I'm not entirely sure that's true, let me confirm that with some people
[14:44:07] <jrmuizel> lu_zero: at the same time there would be resistance to the maintenance burden of supporting something that we didn't actually distritbute
[14:44:25] <jrmuizel> BBB: confirm what?
[14:44:27] <lu_zero> so it's an uphill route at best
[14:44:34] <jrmuizel> lu_zero: indeed
[14:45:17] <BBB> jrmuizel: that lgpl is incompatible with mpl if distributed together
[14:45:41] <BBB> I think that's only true if they're part of the same entity (not binary), e.g. in the same dll or in the same object file or source file
[14:45:51] <jrmuizel> it's sort of an unfortunate position that we're in and sort of ironic that Opera could more easily link against libavcodec then we could
[14:46:15] <BBB> as long as they are separated on some level, afaik it is ok, so I'm asking sflc for advice ;)
[14:46:39] <lu_zero> mru: if ffjpeg and ffpng are faster I'll consider replacing the stand-alone libraries with those
[14:46:59] <mru> jpeg is probably faster
[14:46:59] <jrmuizel> BBB: the issue isn't with license incompatibly it is with the policy that everything that we ship be tri-licensed
[14:47:01] <Honoome> lu_zero: will you make API-compatible interfaces for those? :P
[14:47:02] <mru> no idea about png
[14:47:17] <lu_zero> Honoome: only if somebody pays me for that separately
[14:47:34] <BBB> jrmuizel: that is a rather limiting policy that you might want to reconsider - especially if you want to make use of the true spirit of free software: sharing
[14:47:48] <lu_zero> then would be quite interesting having an use ffmpeg in jpeg and libpng in gentoo
[14:47:49] <BBB> nothing is tri-licensed, so essentially you're excluding everything from being shared (if it originated somewhere else)
[14:47:57] <mru> BBB: that idea was lost a long time ago
[14:48:19] <Honoome> lu_zero: we recently got a virtual/jpeg
[14:48:25] <jrmuizel> BBB: cairo is tri-licensed :)
[14:48:47] <mru> ffmpeg is too: lgpl2, gpl2, gpl3
[14:48:54] <jrmuizel> and we can share code with less restrictively licensed projects
[14:49:08] <BBB> nih syndrome :(
[14:49:17] <BBB> ohwell
[14:49:20] <BBB> nevermind then
[14:49:44] <BBB> I guess this kind of attitude is what keeps gnu/hurd alive :)
[14:49:46] <jrmuizel> BBB: I agree that it sucks, but there's not really an easy way out that satisfies everyone
[14:51:22] <lu_zero> anyway if we can get to avoid that restriction would be quite fun having a way to get a hopefully faster firefox ^^
[14:51:50] <jrmuizel> lu_zero: indeed
[14:52:17] <BBB> I suppose mozilla could always link against a system ffmpeg; some distributions would have that
[14:52:38] * lu_zero meanwhile tries to build firefox using gcc 4.5.0
[14:52:53] <jrmuizel> BBB: yeah, but I'm not sure that's worth the maintenance burden
[14:52:56] <spaam> dont firefox use libavcodec for theora and ogg vorbis ? those are lgpl ?
[14:53:11] <BBB> jrmuizel: I guess I have to agree there ;) ifdef spaghetti isn't quite worth it
[14:53:41] <BBB> wbs: nice patch, I'll do a deep review later today or tomorrow but I like the looks of it
[14:53:42] <jrmuizel> spaam: no we use the xiph implementations of theora and vorbis
[14:53:49] <BBB> wbs: especially if 'a' and 'v' work in ffplay
[14:53:50] <KotH> spaam: nope. ff devels wont toucn ffmpeg with a 10m pole
[14:54:06] <spaam> jrmuizel: ok
[14:54:53] <KotH> spaam: at fosdem one said, that they are not going to consider using any project that has been tainted by h.264
[14:55:03] <av500> lol
[14:55:07] <av500> so, no vp8...
[14:55:33] <jrmuizel> KotH: that doesn't make much sense
[14:55:38] <spaam> KotH: ok =
[14:55:42] <KotH> jrmuizel: no, it does not...
[14:55:46] <jrmuizel> what does "tainted by h.264" even mean?
[14:56:24] <KotH> jrmuizel: dunno.. dropped out after that comment... didn't want to join in a rl flamewar if it wasn with jörg schilling
[14:57:06] <av500> so, if we gat Dark_Shikari to commit an improvement to libvpx, it will be unusable?
[14:57:07] <BBB> KotH: that doesn't sound quite right, probably not a dev, esp. not given what I've heard about mozilla's desires for a h264-quality-like codec
[14:57:19] <jrmuizel> afaik the only reason for not using ffmpeg is because of the licensing problems discussed above
[14:57:48] <jrmuizel> KotH: do you know who it was that said that?
[14:58:49] <KotH> jrmuizel: no idea... i joined a discussion between mru, dondiego and someone from ff... and after i heard above comment, i didnt think it was good use of my time to stay there
[14:59:52] <KotH> jrmuizel: and i dont consider it the official position of ff... it would be too much RMS like
[15:00:15] <mru> or chris blizzard...
[15:00:19] <mru> he could say such a thing
[15:00:27] <KotH> jrmuizel: it's just an example of how weird and uninforment opinions are circulating in the area of video coding
[15:00:36] <mru> he drank the koolaid, then ate the bottle it seems
[15:01:06] <jrmuizel> KotH: indeed
[15:01:08] <lu_zero> mru: you mean the crate
[15:01:38] <KotH> .o0(damn, i need a typo fixer... or someone who proof reads my english in irc)
[15:02:41] <elenril> you need an encoding fixer =p
[15:03:28] <KotH> näi, bruchts nöd
[15:04:36] <elenril> ☃!
[15:20:54] <CIA-92> ffmpeg: michael * r24546 /trunk/libavformat/avformat.h: Make doxygen formatting more consistent.
[15:22:17] <CIA-92> ffmpeg: michael * r24547 /trunk/libavformat/avformat.h: Fix 2 doxy comments that referred to the wrong variable.
[15:26:44] <wbs> BBB: thanks :-) yeah, the 'a' and 'v' keys in ffplay do work
[15:28:59] <CIA-92> ffmpeg: mstorsjo * r24548 /trunk/doc/general.texi: Fix the lavf docs, we have a RTP muxer, not a demuxer
[15:55:19] <CIA-92> ffmpeg: michael * r24549 /trunk/ (6 files in 2 dirs): Fix doxy that refers to the wrong variable.
[17:00:34] <CIA-92> ffmpeg: mru * r24550 /trunk/configure:
[17:00:34] <CIA-92> ffmpeg: configure: fix sh_quote function
[17:00:34] <CIA-92> ffmpeg: Non-matching lists start with ! instead of the usual ^ in shell
[17:00:34] <CIA-92> ffmpeg: patterns.
[17:11:36] <stefang_> hi
[17:12:03] <CIA-92> ffmpeg: reimar * r24551 /trunk/libavcodec/gsmdec.c: Document how the ref_buf is used.
[17:12:12] <kshishkov> gruess dich
[17:35:12] <saintdev> peloverde: so if we are going to use lame's window decision instead of 3gpp. how should initialization be handled
[17:38:25] <peloverde> It seems to use a similar mechanic to 3gpp windowing, There was initialization for that one assert, which probably could be better avoided by using ">=", what else needs to be initialized?
[17:39:42] <saintdev> attack threshold, but that can probably be made static (iirc lame varies it depending on the requested quality)
[17:40:29] <peloverde> If it's not a complicated calculation it can be chosen each frame, 3GPP does it based on bitrate
[17:40:59] <saintdev> peloverde: it's selected from a table
[17:41:16] <peloverde> Then looking it up every frame should be fine
[17:41:29] <funman> 'window decision' is only about window length, right?
[17:42:31] <funman> i've seen there are some different windowing functions but Hann seems to be overwhelmingly used
[17:48:03] <saintdev> peloverde: double checked, it is selected depending on the requested quality, however for the default psymodel it is always 4.2 for L,R,M and 25 for S
[17:48:13] <saintdev> not sure about the ABR psymodel, let me look
[17:48:41] <peloverde> For now just worry about L,R,M
[17:48:58] <saintdev> ABR varies depending on requested bitrate
[17:52:21] <saintdev> huh, bitrate thresholds are much higher than quality thresholds
[18:03:59] <peloverde> ratios probably also depend on the weight and size of the moving average
[18:08:47] <peloverde> I know window decision is something LAME paid a lot of attention to
[18:08:58] <peloverde> I would trust their judgement
[18:09:43] <peloverde> At least for medium and high/bitrates qualities
[18:13:19] <_av500_> gee, mru is unstable today..
[18:13:48] <peloverde> saintdev: I'll be back in a few, time for more sc2
[18:14:10] <saintdev> they got you also!
[18:15:30] <funman> the zergs got everyone :o
[18:56:12] <CIA-92> ffmpeg: mru * r24552 /trunk/configure: Detect PathScale compiler
[19:12:17] * elenril wonders why he read that  as DeathScale
[19:34:11] <BBB> jrmuizel: I just asked my lawyer, and he tells me there is no problem linking lgpl to mpl, so the only problem that might exist is that you would ship non-mpl code, which is really only policy, not a licensing violation per se
[19:35:03] <_av500_> ffireffox fftw!
[19:36:43] <mru> mozilla and xiph love inventing stupid policies for the sole puprose of having something to stick to
[19:46:21] <kierank> vlc should make a browser
[19:50:16] <BBB> fedora would refuse to ship it
[19:50:17] <BBB> o
[19:50:21] <BBB> or worse, cripple it
[19:50:36] <mru> make it only display gifs
[19:50:47] <BBB> right, because jpegs use blocks, and so do mpegs
[19:50:49] <BBB> and they sound alike
[19:50:54] <BBB> only one letter difference
[19:50:59] <kierank> lol
[19:51:00] <BBB> must be patented!!! :-o
[19:51:40] <mru> but gifses are also patented
[19:51:42] <BBB> besides, did you know ffmpeg uses the same api for their mpeg and jpeg decoder? so even if they're not patented, then surely ffmpeg violates patents
[19:52:21] <mru> that's not far from the fsf "derived work" logic...
[19:52:34] <kierank> ffmpeg has the words h264 in it's vp8 decoder so it's patented!!!!111ONE
[19:54:08] <BBB> hehe, that's actually true
[19:54:37] <BBB> Dark_Shikari: seriously, intra_pred isn't very h264 specific, should we rename it to something more generic (similar to motion_est.c; intra_pred.c)?
[19:54:47] <BBB> Dark_Shikari: plus structures in it etc.
[19:55:05] <mru> it is h264
[19:55:21] <mru> it's the prediction scheme defined by h264
[19:55:27] <mru> others have borrowed it
[19:55:44] <saintdev> h264_omg_patents_intra.c
[19:55:57] <_av500_> look at bink, it reuses the h264 idea of frames....
[19:56:19] <_av500_> its tainted
[19:56:19] <mru> now you're talking like apple
[19:56:21] <saintdev> wait a second, vp8 uses frames also!!
[19:56:24] <_av500_> see
[19:56:31] <mru> in appleworld, if they do it, they invented it
[19:56:34] <saintdev> omg vp8 is tainted!
[19:56:40] <mru> painted?
[19:56:43] <mru> the shed?
[19:56:45] <mru> cannot be
[19:56:52] <_av500_> i think it is shikared darkly
[19:59:19] <j-b> software patents... what a joke...
[20:02:56] * elenril wonders when did so many trolls come here
[20:03:29] * spaam looks at mru 
[20:04:10] <_skal_paris_> all patainted
[20:05:18] <jrmuizel> BBB: indeed
[20:06:52] <jrmuizel> The idea is that someone should be able to take firefox and use it under the conditions of the MPL without having to follow the conditions of the LGPL
[20:08:23] <_skal_paris_> BBB: http://pastebin.org/423037
[20:08:45] <_skal_paris_> BBB: move some fields out of proba[2], that don't need to be copied
[20:09:01] <BBB> jrmuizel: I understand that, but seriously, this is easily prevented by haing an ext/ directory with "stuff that we didn't write"
[20:09:22] <BBB> or a separate dependencies repo that is only included in the binary builds, but not officially part of the source tarball
[20:09:37] <BBB> jrmuizel: anyway, that's all policy, I won't interfere, I'm just making the point that it's a little odd ;)
[20:10:09] <jrmuizel> BBB: right but what if I'm IBM and I want to link firefox into a proprietary product and don't want to abide by the conditions of the LGPL
[20:10:46] <jrmuizel> if firefox now depends on something that is LGPL I'm out of luck
[20:11:18] <BBB> jrmuizel: don't use the deps
[20:11:33] <BBB> jrmuizel: and make sure the product is functional (although crippled) without it
[20:11:49] <BBB> jrmuizel: just like gstreamer or vlc is functional (although crippled) without ffmpeg
[20:12:17] <jrmuizel> right but the goal is to have something for others to use that's not crippled
[20:12:35] <BBB> _skal_paris_: looks good to me, ask david (yuvi) also before you commit please
[20:13:02] <BBB> _skal_paris_: and the other ons is probably ok also, but also there, ask yuvi before applying (or wait three days and apply if he doesn't object)
[20:13:19] <Yuvi> the quant one is okay
[20:13:23] <Yuvi> what was the other one?
[20:13:44] <BBB> jrmuizel: it does that anyway - gtk is lgpl (and the system lib exception is part of gpl, not lgpl, so lgpl would still apply to gtk)
[20:13:55] <_skal_paris_> yuvi :  http://pastebin.org/423037
[20:16:13] <Yuvi> okay, don't mind too much where those are
[20:16:53] <_skal_paris_> yuvi: yeah, that's minor
[20:17:48] <jrmuizel> BBB: right, but we don't distribute gtk, and gtk certainly isn't the only the platform we support
[20:17:49] <BBB> if it saves a cycle..
[20:18:54] <jrmuizel> BBB: I'm not saying the policy is great, just trying to give some rationale
[20:19:52] <jrmuizel> policies are hard to change in community projects
[20:20:33] <jrmuizel> people love to bikeshed and complain
[20:20:37] <BBB> jrmuizel: linkage still makes you lgpl in this case, because you distribute a program that links to ... (see section 6b)
[20:20:46] <BBB> or well, not you
[20:20:56] <BBB> but it means the full program, although not lgpl itself, should not violate the lgpl
[20:21:18] <BBB> http://www.gnu.org/licenses/lgpl-2.1.txt section 6b
[20:21:21] <BBB> that's how I read it at least
[20:22:48] <jrmuizel> sure and I don't think the policy wouldn't prevent against linking against a system libavcodec either
[20:27:16] * Terminating due to: TERM
[20:27:35] * /join #ffmpeg-devel ...
[20:27:36] *** TOPIC: Welcome to the FFmpeg development channel. | Discussions about the development of FFmpeg itself are ontopic here. | Questions about using FFmpeg or developing with the libav* libraries should be asked in #ffmpeg. | FFmpeg 0.6 has been released! | This channel is now publicly logged.
[20:27:36] *** TOPICINFO: peloverde!~alex at cpe-173-88-148-20.neo.res.rr.com, 1276886498
[20:31:14] <BBB> jrmuizel: but I don't understand (tell me if I bikeshed too long and I'll stop); if you link against a system lgpl gtk, then regardless of what you ship in your mpl mozilla, _it may not violate the lgpl_, that's what section 6b says. so regardless of how you look at it, ibm cannot use mozilla only under the mpl, it must still abide by the lgpl for those parts that firefox links to, system or not... knowing that, what is the difference (other tha
[20:31:15] <BBB> did it") between linking to system libraries and linking to self-distributed lgpl binaries?
[20:31:18] <BBB> I probably bikeshed too long about this ;) let's get back to work
[20:31:54] <jrmuizel> BBB: that sounds correct to me
[20:33:02] <jrmuizel> but like I said there are widget backends other than gtk
[20:33:58] <jrmuizel> personally I'd rather the policy were different, but it's not easy for me to change it :)
[21:04:43] <_av500_> c++ is really the root of all evil: http://www.numerama.com/magazine/16319-pour-arreter-le-terrorisme-interdisons-la-programmation-c.html
[21:13:11] <CIA-92> ffmpeg: aurel * r24553 /trunk/libavcodec/dvdsubdec.c: remove useless cast
[21:13:38] <_skal_paris_> back
[21:13:54] <_skal_paris_> yuvi: ok, so good to go for both patches
[21:13:55] <_skal_paris_> ?
[21:14:22] <Yuvi> yeah
[21:15:04] <_skal_paris_> deal
[21:17:10] <peloverde> The prerendered cutscenes in sc2 do not reflect well on whatever codec they use
[21:20:25] <Dark_Shikari> keyframe flashing
[21:45:01] <CIA-92> ffmpeg: banan * r24554 /trunk/libavcodec/dca.c:
[21:45:01] <CIA-92> ffmpeg: Setup correct channel value when downmixing is required.
[21:45:01] <CIA-92> ffmpeg: Patch by Nick Brereton
[21:46:34] <CIA-92> ffmpeg: banan * r24555 /trunk/libavcodec/dca.c:
[21:46:35] <CIA-92> ffmpeg: DCA: fix multichannel -> 2 channel downmix.
[21:46:35] <CIA-92> ffmpeg: Patch by Nick Brereton
[21:50:13] <mru> peloverde: http://fate.mansr.com/report.cgi?slot=mips64el-linux-gcc-4.5&time=20100727213810
[21:50:24] <mru> anything special about those tests?
[21:52:20] <peloverde> They all seem to report maxdiff 1
[21:52:24] <peloverde> why are they failing
[21:52:30] <mru> they crash halfway
[21:52:35] <mru> look at the sizes
[21:53:10] <peloverde> Does the readout say it crashed, I'm not used to your new and improved fate yet
[21:53:33] <mru> it stopped outputting samples for some reason
[21:54:02] <peloverde> yes, mikes fate used to say SIGSEGV or SIGABRT
[21:54:10] <mru> the 'test' log says "error 255"
[21:54:26] <peloverde> ahh
[21:54:52] <mru> I need to try to capture more information about crashes and such
[21:55:04] <peloverde> The tools used by those particular files are listed in http://wiki.multimedia.cx/index.php?title=AAC_Conformance_Vectors
[21:55:12] <peloverde> lets see what they have in common
[21:56:23] <peloverde> hmm al07 and am00 have zero overlap on common optional tools
[21:57:27] <peloverde> Debug it further I'll probably need a backtrace or a valgrind report
[21:57:42] <mru> no valgrind on that machine
[21:59:28] <peloverde> gdb backtrace?
[22:00:16] <mru> I suppose I could get one
[22:00:20] <peloverde> The three mips64 configs are identical hardware?
[22:00:28] <mru> same hw
[22:00:53] <mru> the 4.3 one uses -march=mips3, the later ones -march=loongson2f
[22:01:04] <peloverde> ahh
[22:01:39] <CIA-92> ffmpeg: lu_zero * r24556 /trunk/MAINTAINERS: Add my gpg fingerprint
[22:03:44] <peloverde> I don't see any warnings in aacdec.o
[22:04:06] <mru> bugs don't always come with warnings
[22:04:25] <mru> armcc sometimes forgets to initialise something and then warns about it
[22:04:29] <mru> kinda funny
[22:04:37] <saintdev> peloverde: what does it mean when the reference decoder lists two window sequence changes for a block?
[22:04:58] <peloverde> That seems funny, can you pastebin the output?
[22:05:48] <saintdev> i'm guessing one for each channel when L and R use different block types
[22:06:09] <saintdev> peloverde: http://pastebin.org/423301
[22:06:20] <peloverde> When the program is crashing and I don't have valgrind and I don't have a backtrace, my next best option is compiler warnings
[22:06:35] <saintdev> block 21,22,23 are the first ones
[22:06:59] <peloverde> Is the file stereo?
[22:07:09] <saintdev> yes
[22:07:23] <peloverde> If so it was using a common window up until block 20
[22:07:30] <peloverde> look at the common_window flag
[22:07:38] <saintdev> ok, kind of what i guessed, just hadn't seen it before
[22:10:04] <saintdev> the weird one is the same file with 3gpp windowing
[22:10:18] <saintdev> http://pastebin.org/423315
[22:11:09] <peloverde> I've done zero work on stereo
[22:11:22] <saintdev> anyway...
[22:12:09] <saintdev> well itunes and nero use entirely common window for that sample
[22:12:50] <Vitor1001> Can anyone test a patch for me?
[22:12:54] <Vitor1001> http://ffmpeg.pastebin.com/t0amXsjT
[22:13:09] <Vitor1001> With the sample http://samples.mplayerhq.hu/fate-suite/gsm/ciao.wav
[22:13:26] * Vitor1001 is trying to debug issue2133
[22:16:16] <saintdev> pre-echo, how about post-echo, LOL
[22:16:22] <peloverde> mru: Another option would be adding more of the test vectors to see if we can further narrow what id failing
[22:18:14] <saintdev> peloverde: http://rapidshare.com/files/409476197/castanets.aac
[22:18:16] <saintdev> :/
[22:18:34] <peloverde> is mono ok?
[22:18:35] <spaam> Vitor1001: what rev was that patch made for ?
[22:18:58] <spaam> oh
[22:19:14] <Vitor1001> spaam: r24541
[22:19:18] <kierank> stop the presses; spaam is doing something useful ;)
[22:19:31] <spaam> kierank: hahaha :P
[22:19:40] <Vitor1001> spaam: I will make one against latest svn
[22:20:21] <Vitor1001> spaam: http://ffmpeg.pastebin.com/LW7pZFBW
[22:20:29] <saintdev> should too many bits per frame _really_ be an error
[22:21:13] <saintdev> yeah mono seems ok, no post-echo :P
[22:22:05] <saintdev> every other encoder has problems with pre-echo, not ff-aac!! It just has problems with post-echo.
[22:22:39] <CIA-92> ffmpeg: skal * r24557 /trunk/libavcodec/vp8.c: save some copies by moving some fields out of proba[2]
[22:24:40] <CIA-92> ffmpeg: skal * r24558 /trunk/libavcodec/vp8.c: perform the clipping on luma_dc_qmul[1] and chroma_qmul[0] earlier
[22:28:11] <saintdev> although surprisingly 3gpp windowing is more well bahaved than lame
[22:29:34] <spaam> Vitor1001: http://pastie.org/private/6tcmx7zbz2gdgrstyknmg  output from ffplay..
[22:30:14] <Vitor1001> spaam: ow, actually I need output from ffmpeg, something lilke "ffmpeg -i ciao.wav -f md5 -"
[22:31:10] <spaam> http://pastie.org/1062955
[22:31:11] <Vitor1001> spaam: Funny, for you the bug shows up also in ffplay. I could only reproduce it in ffmpeg.
[22:31:21] <Vitor1001> You are on 64 or 32 bits?
[22:31:27] <spaam> 64bity
[22:31:29] <spaam> -y
[22:32:00] <Vitor1001> Thanks... So the bug does exist.
[22:32:08] <spaam> np :)
[22:32:13] <Vitor1001> wait
[22:32:22] <Vitor1001> I just saw I sent you a bad patch :p
[22:32:48] <spaam> haha
[22:33:07] <Vitor1001> spaam: Ok, nevermind, my bad. Thanks anyway. :)
[22:33:20] <kierank> good job spaam
[22:33:42] <spaam> Vitor1001: i can test the real one if you like ;D
[22:33:46] <spaam> kierank: thank you :D
[22:34:04] <Vitor1001> spaam: No, ok, it looks like it was me that was confused :p
[22:34:42] <spaam> oK :)
[22:38:59] <mru> hmm, someone broke vp8
[22:39:48] * merbanan points at skal
[22:39:49] <Dark_Shikari> probably _skal_
[22:39:50] <Dark_Shikari> blame _skal_
[22:40:56] <kierank> the new brutalist fate should send henchmen to punish people for breaking things
[22:41:44] <_skal_paris_> yeah
[22:42:06] <_skal_paris_> ok, what did i break?
[22:43:03] <merbanan> http://fate.mansr.com/report.cgi?slot=x86_64-linux-gcc-4.3&time=20100727223231
[22:44:31] <_skal_paris_> fixing
[22:46:40] <_skal_paris_> merbanan: when fate says it's r 24558, it's exactly r24558? or anything before?
[22:46:52] <mru> that's the version it tested
[22:47:01] <_skal_paris_> k
[22:47:17] <mru> click the time to get a history of all tested revs
[22:49:02] <mru> it's showing a bunch of spurious errors right now because I accidentally filled up a disk
[22:49:34] <spaam> haha
[22:50:05] <_skal_paris_> can one get the exact command that was run?
[22:52:13] <BBB> _skal_paris_: it seems several testsuite files failed
[22:52:22] <BBB> google for vp8-test-vectors-r1
[22:52:37] <mru> or just grab the fate samples
[22:52:37] <BBB> ./ffmpeg -i $file -vcodec rawvideo -f md5 -an -
[22:52:44] <BBB> that would work too
[22:52:45] <Dark_Shikari> _skal_: please regression test before you do another commit
[22:52:49] <Dark_Shikari> revert it for now.
[22:52:49] <BBB> and compare before and after your patch
[22:53:01] <mru> and make fate-vp8-foo
[22:53:23] <merbanan> mru: but it would be nice to see the actual command in the log
[22:53:31] <mru> yes, it would
[22:54:14] <_skal_paris_> Dark: yep
[22:55:41] <mru> kierank: I changed the styling a bit
[22:58:51] <Vitor1001> mru: What do you think of a "make fate-vp8" target to run all vp8 tests?
[22:59:00] <mru> I already thought of that
[22:59:12] <Vitor1001> mru: ok, cool
[22:59:48] <_skal_paris_> where can i find the test-vector-* ?
[23:00:18] <Vitor1001> _skal_paris_: http://samples.mplayerhq.hu/fate-suite/vp8-test-vectors-r1/
[23:00:32] <_skal_paris_> thanks!
[23:00:35] <mru> and don't believe the mime type..
[23:01:10] <BBB> Vitor1001: what you had reminds me of an issue I had a week or two ago
[23:01:14] <BBB> make clean; make fixed it
[23:01:20] <BBB> Vitor1001: suggests a dependency problem somewhere...
[23:01:27] <BBB> (rather than an actual bug)
[23:01:30] <BBB> but I don't know where :(
[23:02:00] <BBB> mru: if compile fails, can we get gcc output?
[23:02:15] <mru> already there
[23:02:20] <Vitor1001> BBB: Hmm, might be possible. But I suppose mru box runs "make clean" between fate runs...
[23:02:37] <mru> it saves the console output
[23:02:54] <mru> click the link in the red box
[23:03:03] <_skal_paris_> can't get the same printout
[23:03:15] <_skal_paris_> ./ffmpeg -i vp80-00-comprehensive-007.ivf -vcodec rawvideo -f md5 -an -
[23:03:21] <_skal_paris_> gives onl one MD5
[23:03:30] <mru> -f framemd5
[23:03:39] <_skal_paris_> oh
[23:03:42] <_skal_paris_> k
[23:03:58] <BBB> oh it's there, got it
[23:04:01] <BBB> mru: thanks
[23:04:15] * BBB goes home
[23:04:18] <BBB> _skal_paris_: good luck :-p
[23:04:54] <_skal_paris_> BBB: i'm gonna revert & sleep
[23:05:08] <_skal_paris_> (there's a svn command for that, right? :)
[23:05:17] <_skal_paris_> but i would have like to understand the fate thing
[23:05:20] <_skal_paris_> and repro
[23:06:31] <Vitor1001> _skal_paris_: to run fate you have to download the samples
[23:06:46] <Vitor1001> rsync -aL rsync://rsync.mplayerhq.hu:/samples/fate-suite/ fate/fate-suite
[23:07:09] <_skal_paris_> vitor: that's why i grabbed the vp8 ones
[23:07:10] <Vitor1001> Then simply run "make fate SAMPLES=/the/path/to/the/dir/fate-suite"
[23:07:40] <_skal_paris_> ok, md5s are back to normal
[23:07:41] <Vitor1001> This command will run all the tests (and thus need all the samples)
[23:07:44] <mru> or configure --samples=/the/path
[23:07:47] <_skal_paris_> rolling back
[23:09:20] <_skal_paris_> done
[23:09:22] <_skal_paris_> sorry about that
[23:09:30] <mru> thanks for the speedy fix
[23:09:50] <mru> fate should verify within a few minutes
[23:09:55] <_skal_paris_> now i've got some md5 to look at and figure out my borkinationage
[23:10:07] <CIA-92> ffmpeg: skal * r24559 /trunk/libavcodec/vp8.c: b0rk3d FATE + black helicopters hissing -> rolling back to r24556 and sleeping
[23:10:37] <_skal_paris_> well, yeah, maybe tomorrow hey
[23:12:43] * _skal_paris_ waiting a bit for FATE to recall the black helipcopters though
[23:12:54] <mru> first green result in
[23:13:28] <mru> the x86 tests are taking about 3 minutes per compiler
[23:14:24] <spaam> buy a faster cpu mru ;)
[23:14:39] <mru> it's only using half of it
[23:20:44] <_skal_paris_> oh, fate-suite = 387megs
[23:20:46] <_skal_paris_> could be worse
[23:22:15] <kierank> too big for google
[23:28:01] <_skal_paris_> mru: if i leave only the vp8-* files in fate/fate-suite, will it still work?
[23:28:16] <mru> it will fail all other tests
[23:30:46] <_skal_paris_> ok, waiting then
[23:31:54] <Vitor1001> _skal_paris_: If you have only these files, better to run "make `seq -f "fate-vp8-test-vector-%03g" 1 17` SAMPLES=/files/fate-suite"
[23:31:57] <_skal_paris_> ah! that was r24558
[23:43:45] <_skal_paris_>  that was a silly patch
[23:46:04] <_skal_zZzz_> zZzz