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

[irc at mansr.com]

[01:44:36] <CIA-99> ffmpeg: banan * r24051 /trunk/libavcodec/dca.c: DCA: *_bits() -> *_bits_long() where needed, half fix for broken bitstream parsing
[04:02:41] <CIA-99> ffmpeg: ramiro * r24052 /trunk/libavformat/Makefile:
[04:02:41] <CIA-99> ffmpeg: Add id3v1.o dependency for oma demuxer
[04:02:41] <CIA-99> ffmpeg: Patch by Michael Karcher <ffmpeg at mkarcher dot dialup dot fu-berlin dot de>
[04:08:42] <CIA-99> ffmpeg: ramiro * r24053 /trunk/libavformat/Makefile:
[04:08:42] <CIA-99> ffmpeg: Remove superfluous id3v2.o dependency for dts, eac3, gsm, mlp, shorten, and
[04:08:42] <CIA-99> ffmpeg: truehd demuxers
[04:08:42] <CIA-99> ffmpeg: Patch by Michael Karcher <ffmpeg at mkarcher dot dialup dot fu-berlin dot de>
[06:00:33] <Dark_Shikari> hmm, with profile 1 (simple loopfilter, bilinear mc iirc) in vp8, we're tied with libvpx on core i7 x86_32
[06:00:47] <Dark_Shikari> 72 fps libvpx, 71fps ffmpeg
[06:00:55] <Dark_Shikari> that's with the chroma filter still in C
[06:05:45] <Yuvi> simple doesn't have chroma, or are you emulating the full lf with simple?
[06:06:43] <Dark_Shikari> oh you're right
[06:07:02] <Dark_Shikari> yeah, so it's a straight tie.  now we need magic to make ours faster.
[06:07:32] <Dark_Shikari> Of course, if we test with frame-based threading, we can get arbitrarily ridiculous fps numbers.
[06:12:15] <Yuvi> my opts to decode_block_coeffs should be good for another 3% or so for normal videos
[06:12:36] <Yuvi> http://pastie.org/1030819 if you want to try them
[06:14:23] <Yuvi> I'm probably going to collapse all the DCT_CAT* branches into read_tree with that subtree, they don't occur often enough to expand that
[06:14:35] <Dark_Shikari> I think we need two versions of the cabac decoder
[06:14:44] <Dark_Shikari> one is pure asm and branchless, the other is C and branchy
[06:15:12] <Yuvi> think the branchy would be better there since it's branching off the result anyway?
[06:15:20] <Dark_Shikari> if (!vp56_rac_get_prob(c, token_prob[6])) {
[06:15:22] <Dark_Shikari> branchy
[06:15:27] <Dark_Shikari> coeff += vp8_rac_get_coeff(c, vp8_dct_cat_prob[cat]);
[06:15:29] <Dark_Shikari> not branchy
[06:16:07] <Yuvi> yeah, though will gcc combine the if with the one inside vp56_rac_get_prob?
[06:16:39] <Yuvi> (libvpx didn't trust it to)
[06:17:00] <Dark_Shikari> Test it, that's important to check
[06:18:21] <Yuvi> http://pastie.org/1030825 some stats of how often each coeff/token is coded if you're curious
[06:19:03] <Yuvi> but that's probably the same as in h264
[06:19:07] <Dark_Shikari> wait, that seems weird
[06:19:09] <Dark_Shikari> why is EOB so rare?
[06:19:50] <Dark_Shikari> that can't be right
[06:19:52] <Dark_Shikari> there's one eob per block
[06:20:07] <Yuvi> oh
[06:20:10] <Yuvi> I messed that up
[06:20:26] * Yuvi smacks head
[06:20:47] <Yuvi> wonder why it wasn't zero...
[06:21:25] <Dark_Shikari> also, special-casing DC might be worth it
[06:21:54] <Yuvi> special case in what way?
[06:22:43] <Dark_Shikari> A separate set of code at the top?
[06:22:57] <Dark_Shikari> in order to simplify the qmul logic and the first-coeff logic (e.g. for blocks with and without DC)
[06:25:33] <Yuvi> something like http://pastie.org/1030830 ?
[06:26:47] <Yuvi> or what more?
[06:27:17] <Dark_Shikari> no
[06:27:22] <Dark_Shikari> I mean a full loop unroll by one iteration
[06:32:11] <Yuvi> hm, so something like http://pastie.org/1030838 ?
[06:32:42] <Dark_Shikari> something like that . try benching them?
[06:40:49] <Dark_Shikari> you'll want to load qmul into local vars
[06:40:50] <Dark_Shikari> aliasing
[06:42:28] <Yuvi> bah, messed something up
[06:57:50] <wbs> lu_zero: I think it's better to propagate the actual error from av_open_input_stream, as in the patch I just posted
[07:11:58] <cartman> hi all
[07:12:19] <kshishkov> hi eric
[07:12:32] <cartman> lo kshishkov
[07:12:47] <cartman> is it me or libvpx based encoding is dog slow? (meaning fps=1)
[07:13:03] <Dark_Shikari> No, not just you.  libvpx sucks.
[07:13:10] <cartman> glad about it
[07:13:20] <kshishkov> use Theora instead
[07:13:36] <elenril> lol
[07:13:43] <cartman> kshishkov: well thats an idea :-)
[07:14:01] * cartman will wait for a native encoder
[07:14:23] * kshishkov looks at pigs growing wings
[07:14:44] <cartman> bah ;)
[07:15:07] <elenril> kshishkov: why don't you write one
[07:15:45] <kshishkov> elenril: because I don't do encoding
[07:15:52] <elenril> sure you do
[07:15:59] <elenril> i saw an encoder from you
[07:16:10] <kshishkov> but if you convince Dark_Shikari that Touhou videos are best encoded with VPX ...
[07:16:11] <cartman> VC1 encoder?
[07:16:14] <elenril> it's pretty famous ;)
[07:16:26] <kshishkov> I wrote only ZMBV encoder
[07:16:33] <elenril> aac?
[07:16:58] * kshishkov does not consider his work on AAC to be encoder
[07:18:16] <elenril> actually it's not that bad
[07:18:29] <elenril> (unless you want stereo)
[07:18:42] * kshishkov knows a guy who wrote really good AAC encoder
[07:20:47] * cartman will stick to mp3 for a loooooooong time
[07:21:19] * kshishkov prefers FLAC
[07:21:50] <elenril> wav has better quality
[07:21:52] * elenril hides
[07:22:29] * kshishkov demonstrates some tricks from MPFC "How not to be seen" on elenril
[07:26:30] <elenril> any ideas how to make libc's resolver prefer ipv6?
[07:26:59] <wbs> elenril: you should use getaddrinfo, and set suitable flags when using it (so that it knows that it can return any address family)
[07:27:35] <wbs> and then you get a list of addresses, in any order - don't know if you can make it return the v6 address before the v4 one in that list
[07:27:59] <Dark_Shikari> Yuvi: any results?
[07:30:17] <Yuvi> Dark_Shikari: no, I can't see why it isn't working... I'm going to go to bed probably
[07:30:34] <Dark_Shikari> night.
[07:31:29] <elenril> wbs: i heard somewhere that it can be done with some magic in gai.conf
[07:32:16] * elenril blames Drepper
[07:32:27] <wbs> elenril: ok, never heard about that, but I guess it's probable
[07:32:42] <elenril> well it doesn't work :)
[07:45:03] <cartman> elenril: maybe http://people.redhat.com/drepper/linux-rfc3484.html
[07:45:46] <KotH> salut
[07:46:18] <cartman> lo KotH
[07:46:42] <KotH> hey cartman!
[07:46:46] <cartman> hoi!
[07:46:53] <KotH> where have you been, old man?
[07:47:02] <cartman> Trying to stay alive :)
[07:47:05] <KotH> ^^'
[07:47:08] <cartman> I am an old man indeed =)
[07:47:19] <KotH> were you dispatched to the east? ;)
[07:47:26] <kshishkov> have you said anything inappropriate about Turkey or anything appropriate about Armenia?
[07:47:30] <cartman> KotH: well no, not in the army yet :P
[07:47:39] <cartman> kshishkov: lol
[07:47:54] <cartman> the same old ffmpeg-devel
[07:47:55] <cartman> always fun
[07:49:26] <KotH> ofc
[07:49:33] <KotH> why should it change? :)
[07:49:49] <cartman> better this way ;)
[07:50:13] <kshishkov> we even kick people time from time
[07:51:08] <cartman> is Mr. Felker still around?
[07:52:03] <kshishkov> I heard he was on IRC in the first decade of June
[07:52:30] <cartman> oh
[07:52:37] <jai> cartman: saw him on #videolan once
[07:52:49] <jai> i assume you meant dalias
[07:53:11] <cartman> jai: yup
[07:53:14] <cartman> the flamemaster
[07:53:33] <kshishkov> we have mru for that
[07:53:47] <cartman> true that
[07:56:32] <KotH> cartman: rich is still on #mplayerdev
[07:56:42] <cartman> must.avoid.that.channel
[07:56:56] <KotH> why?that.project.is.not.evil
[07:57:04] <cartman> I could just join and say ogg rocks!!111!!!
[07:57:07] <cartman> and the fun begins ;)
[07:57:21] <KotH> you can say that here too, and face the same consequences ;)
[07:57:33] * cartman checks is mru is around 
[07:57:34] <cartman> :o
[07:57:35] <cartman> :P
[08:00:34] <kshishkov> cartman: this channel is publicly logged anyway
[08:00:57] <cartman> heheh
[08:17:33] <CIA-99> ffmpeg: banan * r24054 /trunk/libavcodec/dca.c:
[08:17:33] <CIA-99> ffmpeg: DCA: Occasionally a false XCH sync word can turn up after the core DTS data,
[08:17:33] <CIA-99> ffmpeg: to verify the sync word the extension fsize field should be compared to
[08:17:33] <CIA-99> ffmpeg: the core data length field.
[08:17:33] <CIA-99> ffmpeg: Patch by nick.nbrereton at net
[09:12:37] <CIA-99> ffmpeg: cehoyos * r24055 /trunk/libavformat/aviobuf.c:
[09:12:37] <CIA-99> ffmpeg: Silence a warning when compiling aviobuf.c
[09:12:37] <CIA-99> ffmpeg: Patch by Eli Friedman, eli d friedman a gmail
[13:11:40] <CIA-99> ffmpeg: michael * r24056 /trunk/libavcodec/ (h264_refs.c h264.h): Factorize ff_generate_sliding_window_mmcos() out.
[13:15:12] <mru> hmm, h264 work...
[13:50:34] <Tjoppen> finally. got a working build environment in mingw/msvc
[13:51:04] <mru> if you must use windows, at least do yourself a favour and install cygwin
[13:51:05] <Tjoppen> today's "fun" task: figure out why the aac encoder smashes the stack without being able to run a debugger..
[13:51:40] <kshishkov> could be too large stack variable
[13:51:40] <Tjoppen> unfortunately a native binary is desired
[13:51:42] <mru> stack-smashing, fun!
[13:51:57] <mru> Tjoppen: -mno-cygwin
[13:52:17] * Tjoppen tries
[13:52:29] <Tjoppen> at least libav* compiles fast with eight cores :)
[13:53:25] <Tjoppen> --extra-cflags, right?
[13:53:41] <mru> and --extra-ldflags
[13:54:24] <Tjoppen> yeah, I save my previous configure lines. -Wl etc. for ld
[13:55:03] <mru> --extra-cflags=-mno-cygwin --extra-ldflags=-mno-cygwin
[13:56:02] <J_Darnley> too bad it doesn't work with cygwin 1.7
[13:56:10] <mru> what? they broke it?
[13:56:14] <J_Darnley> yes
[13:56:20] <mru> oh dear
[13:56:30] <J_Darnley> config.log: gcc: The -mno-cygwin flag has been removed; use a mingw-targeted cross-compiler.
[13:57:10] <mru> annoying to have two copies of essentially the same gcc
[14:03:21] <Tjoppen> one fun thing about windows is that you can't do scanf() in one thread and printf() in another. the printf() will block until you enter something in the console
[14:04:07] <mru> global lock?
[14:04:35] <Tjoppen> probably. the solution: disable the console interace on windows
[14:05:11] <mru> scanf on stdin is usually a bad idea anyway though
[14:06:16] <Tjoppen> yeah. luckilly not required
[14:36:54] <CIA-99> ffmpeg: michael * r24057 /trunk/libavcodec/ (h264_refs.c h264.c):
[14:36:55] <CIA-99> ffmpeg: Perform sliding window operation during frame gap handling.
[14:36:55] <CIA-99> ffmpeg: This avoids some warnings about too many reference frames.
[14:43:55] <Vitor1001> BBB: ping
[14:47:30] <BBB> pong
[14:48:05] <BBB> Vitor1001: pong
[14:48:24] <Vitor1001> BBB: Would you mind reviewing my SSE dct code?
[14:48:35] <BBB> is later today ok?
[14:48:38] <Vitor1001> sure
[14:48:45] <BBB> I actually just started reviewing david's vc1 loopfilter code
[14:48:54] <BBB> but I'll try
[14:49:04] <Vitor1001> No hurry.
[14:49:15] <Vitor1001> The vc1 loopfilter is important too :)
[14:49:37] <Vitor1001> Floating point SSE is less black-magic than integer stuff
[14:50:24] <BBB> a lot of this is black magic, but that's ok :)
[14:50:39] <CIA-99> ffmpeg: michael * r24058 /trunk/ffmpeg.c:
[14:50:39] <CIA-99> ffmpeg: Move frame_available computation to where it belongs in ffmpeg.c.
[14:50:39] <CIA-99> ffmpeg: This fixes a infinite loop.
[14:59:59] <Vitor1001> BBB: well, it is also less fun :(
[15:01:13] <BBB> float is less fun?
[15:01:43] <BBB> I thought fixp was a headache already
[15:01:59] <Honoome> mru: a wizard did it! :P
[15:02:10] <Honoome> [re: how can an operand have two types]
[15:03:07] <mru> oh, _that_ is what quantum computing is all about
[15:03:13] <Vitor1001> BBB: SSE float has less funny tricks
[15:03:21] <Vitor1001> No packing/unpacking
[15:03:27] <Vitor1001> Just an eventual shuffling
[15:03:38] <Honoome> mru: yeah, leaving gcc to make sense of the code is a quantum event
[15:04:38] <Honoome> it can get it right or it can get it wrong, but you won't know until you observe it by either running the code or looking at the disassembly
[15:11:06] <BBB> Vitor1001: oh... that's a little sad
[15:11:13] <BBB> Vitor1001: how many float ops can you do at a time?
[15:11:28] <Vitor1001> BBB: 4
[15:11:43] <BBB> that's not too bad, kinda like mmx in words
[15:11:48] <Vitor1001> BBB: It is more the point you don't really need unpacking
[15:12:18] <Vitor1001> BBB: If you want to multiply float vectors, you just load them as float, multiply them as float and store them as float.
[15:14:13] <Vitor1001> BBB: It is easier, but less fun ;)
[15:14:46] <BBB> here's the main problem with mmx & co: you can only pack in very limited ways
[15:14:58] <BBB> what if I want to store the third value as a word (or byte) into a memory location?
[15:15:01] <BBB> I can't do that
[15:15:25] <BBB> and so things like horizontal filtering over ranges of just 1-2 pixels becomes very complicated
[15:15:29] <BBB> e.g. vp8 simple loopfilter
[15:15:48] <BBB> because in order to store, you have to load or remember the neigbour pixels which you didn't touch as well
[15:16:04] <BBB> I hope they did a better job at that for float handling
[15:16:04] <Vitor1001> Neither with sse. Even worse, if you want to load just the first value into a register, you can. But it will erase the other values :p
[15:16:21] <BBB> yes! exactly! it zeroes it on movd! which is stupid!
[15:16:26] <Vitor1001> The basis is the same. movaps, shufps, etc...
[15:17:09] <Vitor1001> I don't understand it either. It would make a lot of things easier.
[15:17:48] <Vitor1001> For floats, what is really missing is the very common operation of multiply by the inverse.
[15:18:18] <Vitor1001> Ie: a[0] *= c[3]; a[1] *= c[2]; a[2] *= c[1]; a[3] *= c[0];
[15:18:27] <Vitor1001> Happens again and again and again.
[15:19:02] <Vitor1001> Yes, it needs just an additional shuffle, but it makes a big percentage if you are only doing it.
[15:19:35] <BBB> the very point of simd should be so that we don't have to shuffle manually, the cpu does this for us :-p
[15:19:38] <BBB> saves instructions
[15:19:42] <BBB> which is the whole point
[15:20:08] <BBB> I'm sure someone will tell us now that ppc or <some obscure cpu> does all this much better
[15:24:58] <mru> cortex-a8 can at least do the vector reversal in parallel with arithmetic
[15:25:11] <mru> so it's mostly free if you schedule properly
[15:27:59] <Vitor1001> mru: Is it still mostly free if you don't already don't spend time waiting for instructions to finish?
[15:32:42] <tborg> got a little question, a little off-topic though.... is there a lossless video codec in FFmpeg using motion vectors so that motion vectors can be "debugged" using -vismv and/or -debug mv?
[15:33:29] <kshishkov> Snow
[15:35:28] <tborg> @kshishkov thanks!
[16:08:26] <tborg> sorry for bugging again about lossless video coding with snow... a) how to tell snow to encode lossless? b) if I use "-vcodec mpeg2video" instead of snow, -debug vis_mb_type works... does snow always use motion vectors or do I have to tell it?
[16:46:52] <CIA-99> ffmpeg: mstorsjo * r24059 /trunk/libavformat/ (rtpdec_asf.c rtpdec_asf.h):
[16:46:52] <CIA-99> ffmpeg: rtpdec_asf: Propagate errors from the chained av_open_input_stream
[16:46:52] <CIA-99> ffmpeg: This fixes the crash in issue 2070.
[17:08:15] <Tjoppen> seems my aac troubles are caused by the dsp stuff. trying --disable-altivec and --disable-mmx
[17:08:40] <mru> are you on ppc or x86?
[17:10:00] <Tjoppen> x86. ah, there's --disable-asm. was using --disable-yasm and wtf:ing about why it still didn't use C stuff
[17:10:23] <mru> so why did you mention altivec?
[17:10:51] <Tjoppen> rambling
[17:11:24] <mru> hmm, this on windows?
[17:11:28] <Tjoppen> yep
[17:11:37] <Tjoppen> woo, success. doesn't smash anymore
[17:15:08] <mru> does this patch help? http://article.gmane.org/gmane.comp.video.ffmpeg.devel/110408
[17:16:31] <Tjoppen> hm. I'll try it
[17:24:26] <Tjoppen> lots of "error: unknown register name '%xmm0' in 'asm'"
[17:25:40] <mru> hmm
[17:26:03] <Tjoppen> using gcc 4.5.0 btw
[17:28:34] <Tjoppen> also, another interesting fact: a lot of other encoders (mpeg2video, mpeg4, dvvideo, h263, mp2) work fine. I'm assuming they use at least part of the mmx stuff
[17:28:59] <mru> can you narrow it down to a single function?
[17:29:06] <mru> I'd start with the fft
[17:29:25] <mru> and mdct of course
[17:29:51] <Tjoppen> I narrowed it down to ff_fft_calc() earlier
[17:30:04] <Tjoppen> which calls some dsp function (not the c version)
[17:32:09] <CIA-99> ffmpeg: mru * r24060 /trunk/configure: configure: simplify some OS-specific flag setting
[17:41:06] <Tjoppen> woo. ffmpeg.exe crashed
[17:41:08] <Tjoppen> so it's not just my code
[17:57:50] <Tjoppen> looks like it doesn't like the syntax of the CLOBBER_*_MMX macros
[18:04:46] <Tjoppen> wait.. this happens only on 64-bit compiles? maybe I should try switching to 32-bit
[18:06:35] <wbs> Tjoppen: http://ffmpeg.arrozcru.org/autobuilds/, The win64 builds have been disabled because of a
[18:06:38] <wbs> known bug which causes some hard-to-track weirdness.
[18:06:46] <wbs> which then poins to https://roundup.ffmpeg.org/issue1889
[18:10:02] <Tjoppen> I'll try --arch=x86_32 then?
[18:10:22] <Tjoppen> that win64 thing I already knew about. I assumed configure was using a fallback
[18:20:24] <Tjoppen> yep, that did the trick. seems it's using c code though..
[18:20:32] <Tjoppen> at least for fft
[18:21:22] <mru> poke Dark_Shikari or pengvado, they should know this stuff
[18:27:44] <Tjoppen> this will do as a stop gap
[18:28:03] <Tjoppen> I wonder for which encoders this happens. it can't be only aac?
[18:29:23] <mru> anything using the fft I suppose
[18:35:47] <DonDiego> siretart: will you port michael's avidec commit to 0.6/0.5 or should i?
[18:41:13] <siretart> DonDiego: I have it ticked but cannot really promise when I get to it. if you have time, do it, if not, I'll do it later either today or later this week
[18:41:31] <siretart> I currently need to prepare a presentation for tomorrow
[18:41:57] <DonDiego> ok
[18:42:17] <DonDiego> i'm rather busy myself right now, i was hoping you might have minute
[18:57:35] <CIA-99> ffmpeg: diego * r24061 /trunk/Doxyfile:
[18:57:35] <CIA-99> ffmpeg: Revert update of Doxygen configuration file via 'doxygen -u'.
[18:57:35] <CIA-99> ffmpeg: It will be redone with some cosmetics split out in a moment.
[19:21:35] <CIA-99> ffmpeg: diego * r24062 /trunk/Doxyfile: cosmetics: Reorder config file entries to the format used by doxygen 1.5.6.
[19:35:52] <CIA-99> ffmpeg: diego * r24063 /trunk/Doxyfile: cosmetics: Reformat paragraphs and fix typos as done by 'doxygen -u'.
[19:43:40] <CIA-99> ffmpeg: diego * r24064 /trunk/Doxyfile:
[19:43:40] <CIA-99> ffmpeg: Update Doxyfile to the format preferred by Doxygen 1.5.6 (via 'doxygen -u').
[19:43:40] <CIA-99> ffmpeg: This is the version available in Debian stable, so it should be a reasonable
[19:43:40] <CIA-99> ffmpeg: baseline that can be expected to be present on all developer machines.
[19:50:30] <DonDiego> let's see if the doxygen config file split makes michael happy...
[19:59:52] * mru thinks doxygen seems badly designed
[20:00:04] <mru> most of that file should go in a site default config
[20:00:21] <mru> and each project should only need to set a few overrides
[20:06:05] <DonDiego> yeah..
[20:48:00] <mru> DonDiego: say, how about enabling libpostproc automatically if gpl is enabled?
[20:48:58] <BBB> Vitor1001: now I'm at your patch, hope to have it finished tonight or tomorrow
[20:50:40] <DonDiego> hmmm
[20:51:06] <DonDiego> is there a situation when it's preferable to not enable libpostproc?
[20:51:41] <mru> users can always disable it
[20:51:55] <mru> it just seems weird that one of the libs is off by default
[20:52:56] <DonDiego> well, it's the license..
[20:53:10] <mru> that's why I said enable it automatically with --enable-gpl
[20:53:10] <DonDiego> i'm not opposed, never really thought about it
[20:53:42] <DonDiego> say, has anybody compared the speed of the mp3 decoder with mpg123?
[20:58:48] <mru> you expect that myth to die so easily?
[20:59:26] <lu_zero> well ffmpeg12 has issues libmpeg2 doesn't have in one case
[20:59:43] <lu_zero> (shame on me for not noticing and fixing it)
[20:59:55] <mru> what is the issue?
[21:00:12] <mru> that's also one of those unkillable myths
[21:00:38] <mru> everybody is convinced something is missing/broken, but nobody has ever seen it in person
[21:02:16] <lu_zero> mru: vlc 1.1 shown that
[21:02:35] <lu_zero> with mpeg in rtp
[21:02:58] <mru> how does the decoder make a difference there?
[21:03:13] <lu_zero> mru: let me setup a feed so you can see it
[21:03:21] <lu_zero> ffplay somehow recovers
[21:03:24] <mru> ok ok, I believe you
[21:03:43] <mru> I just don't understand the relation bewtween the decoder and the transport
[21:05:55] <BBB> mru: ffmpeg12dec expects "parsed" MPEG frames
[21:06:11] <mru> so give it such frames
[21:06:13] <BBB> i.e. frames where the first byte is a mpeg start code 0x000001b?
[21:06:15] <lu_zero> BBB: you figured out to fix it?
[21:06:15] <BBB> right
[21:06:25] <BBB> I'm not sure if ffmpeg's rtp layer does that
[21:06:32] <BBB> if not, it should set needs_parsing=1 or so
[21:06:32] <mru> there's nothing unique about rtp here
[21:06:39] <BBB> in AVFormatContext
[21:06:48] <BBB> the difference is that libmpeg2 does the parsing internally
[21:06:48] <mru> it doesn't do that?
[21:06:54] <BBB> maybe, not sure
[21:07:00] <BBB> I've never used mpeg1/2 over rtp
[21:07:24] <lu_zero> BBB: we should add it
[21:07:35] <BBB> lu_zero: go for it :-p
[21:07:43] <BBB> that's the only diff between ffmpeg12dec and libmpeg2
[21:07:48] <lu_zero> BBB: ok
[21:07:53] <BBB> other than that they always give binary identical output, afaik
[21:08:22] <mru> depends on which idct is used
[21:08:39] <BBB> close-to-binary identical then
[21:10:35] <BBB> lu_zero: if you set up a feed, I'll help tomorrow
[21:10:39] <BBB> want to go home now :-p
[21:15:50] <spaam> boo.. slashdot is down :(
[21:16:21] <Anssi> works fine here
[21:16:26] <mru> did they get slashdotted?
[21:16:42] <spaam> Anssi: i get "Internal Server Error"
[21:16:43] <Anssi> or not.. maybe it was cache or it works intermittenly
[21:17:35] <Anssi> the latter
[21:18:08] <spaam> works now ;D
[21:18:19] <lu_zero>             st->need_parsing = AVSTREAM_PARSE_FULL;
[21:18:27] <lu_zero> it's already there -_-
[21:18:39] <lu_zero> BBB: nubes.esof2010.org will have them
[21:18:57] <lu_zero> usually backstage.esof2010.org/live/live_11.sd
[21:19:06] <lu_zero> backstage2.esof2010.org/live/live_12.sd
[21:19:12] <lu_zero> backstage3.esof2010.org/live/live_13.sd
[21:19:33] <BBB> ok, I'll check tomorrow
[21:20:04] <lu_zero> they will be on between 9am and 7pm CEST
[21:20:26] <BBB> cest?
[21:20:38] <lu_zero> gmt+1
[21:20:50] <BBB> est :)
[21:20:52] <BBB> that's me
[21:22:27] <spaam> CEST is gmt+2
[21:23:05] <spaam> maybe it was CET ;S
[21:23:10] <BBB> cet yes
[21:23:33] <spaam> oh i mean UTC
[21:23:35] <BBB> eastern and central-eastern
[21:23:47] <BBB> then there's PSt (pacific) and something in between
[21:23:57] <BBB> I don't know what the S stands for
[21:24:03] <kierank> standard?
[21:25:55] <BBB> perhaps
[21:25:58] * BBB goes home
[21:26:03] <BBB> zzz
[22:33:49] <CIA-99> ffmpeg: stefano * r24065 /trunk/tests/ref/lavfi/ (scale200 crop_scale crop_scale_vflip scale500): (log message trimmed)
[22:33:50] <CIA-99> ffmpeg: Update lavfitest reference after commit:
[22:33:50] <CIA-99> ffmpeg:  Author: bcoudurier
[22:33:50] <CIA-99> ffmpeg:  Date: Sat Jul 3 03:11:04 2010 +0000
[22:33:50] <CIA-99> ffmpeg:  Set graph swscale opts before parsing it, that way opts are available
[22:33:50] <CIA-99> ffmpeg:  when auto-adding scalers.
[22:33:51] <CIA-99> ffmpeg: It changed the swscale flags used by the auto-added scalers, and so
[22:33:51] <CIA-99> ffmpeg: stefano * r24066 /trunk/libavfilter/vf_pad.c:
[22:33:52] <CIA-99> ffmpeg: Factorize out some code and implement the fill_line_with_color()
[22:33:52] <CIA-99> ffmpeg: function. Allow to share code with the pending color source.
[22:33:53] <CIA-99> ffmpeg: stefano * r24067 /trunk/libavfilter/vf_pad.c:
[22:33:53] <CIA-99> ffmpeg: Move shareable draw_rectangle() and query_formats function to the top
[22:33:54] <CIA-99> ffmpeg: of the file, and put under #if CONFIG_PAD_FILTER the code specific to
[22:33:54] <CIA-99> ffmpeg: the pad filter.
[22:33:55] <CIA-99> ffmpeg: Simplify the inclusion of the color source.