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

[irc at mansr.com]

[01:49:43] <Dark_Shikari> hmm, is there a decent channel for kernel-related stuff?
[01:49:48] <Dark_Shikari> though if anyone knows the answers to these it'd be nice
[01:50:03] <Dark_Shikari> 1) Does the linux kernel have a prefetch_this_file feature?  I don't think so, but it might have been added when I wasn't looking.
[01:50:08] <ohsix> theres ##kernel but none of the major committers are there
[01:50:21] <Dark_Shikari> 2) If I mmap a file and vmadvise every page in it, does that do 1) ?
[01:50:23] <ohsix> you use mmap and madvise to do that
[01:50:25] <Dark_Shikari> lol
[01:50:29] <Dark_Shikari> So it works?
[01:50:42] <ohsix> its a hint, but thats what it does if it can
[01:50:54] <Dark_Shikari> do we know how much it listens?
[01:51:18] <ohsix> the metaphorical we? i dont know, i personally dont know though, you can look in mm and see what it does
[01:51:30] <astrange> posix_fadvise()
[01:51:33] <ohsix> does this look weird to you btw http://paste.ubuntu.com/394242/
[01:51:47] <Dark_Shikari> astrange: does it actually work?
[01:52:02] <astrange> probably, i just did 'apropos advise'
[01:52:06] <astrange> there's readahead(2) as well
[01:52:13] <Dark_Shikari> basically the idea is, suppose we have grep
[01:52:23] <Dark_Shikari> grep is slow because the filesystem cannot reorder grep's requests
[01:52:36] <Dark_Shikari> if we can tell the filesystem what grep is going to do over the next, say, 5-10 seconds
[01:52:39] <Dark_Shikari> it can reorder them
[01:52:57] <ohsix> why would it reorder a linear search
[01:53:04] <Dark_Shikari> ohsix: because disks are disks
[01:53:17] <Dark_Shikari> filesystems _love_ reordering reads
[01:53:24] <ohsix> but its not the only io going on
[01:53:34] <Dark_Shikari> still doesn't matter
[01:53:46] <Dark_Shikari> grep will not request the next chunk until it's done with the current chunk
[01:53:50] <ohsix> it doesn't preclude reordering, it happens, but not from greps perspective
[01:54:00] <Dark_Shikari> How can the filesystem reorder only one read at a time?
[01:54:16] <ohsix> it will chew through everything it has faster than it'll get it off the disk, its not likely it will speed it up much
[01:54:30] <Dark_Shikari> Erm... but "how fast it can get it off the disk" is improved by reordering
[01:54:37] <Dark_Shikari> unless you actually think that grep goes as fast as dd
[01:54:55] <Dark_Shikari> this is a fact, this has already been done and tested
[01:55:05] <Dark_Shikari> there was a paper in which a guy modified open() to take a list of future-to-be-accessed files
[01:55:06] <ohsix> hurrrrrrrrr
[01:55:08] <Dark_Shikari> and changed grep to do this
[01:55:12] <Dark_Shikari> it vastly improved performance
[01:55:20] <Dark_Shikari> of course, it can probably nowadays be done without modifying syscalls.
[01:55:29] <Dark_Shikari> making it slightly more practical.
[01:55:41] <ohsix> files are one thing, metadata reads are slow, and so is opening files
[01:55:48] <Dark_Shikari> opening files is nearly free
[01:55:51] <Dark_Shikari> almost all inodes are cached
[01:56:02] <ohsix> :<
[01:56:06] <astrange> It's regarding license issue, I believe that XVID encoder is the only
[01:56:06] <astrange> MPEG4 encoder that doesn't required royalty when using it.
[01:56:08] <astrange> ????
[01:56:12] <Dark_Shikari> astrange: an idiot
[01:57:29] <ohsix> it lives in mm/madvise.c if you want to look; along with the rest of the vm stuff
[01:57:52] <Dark_Shikari> oh, cool.
[01:57:53] <Dark_Shikari> thx
[01:58:35] <ohsix> now you can look at my backtrace :)
[02:03:03] <Dark_Shikari> ?
[02:03:54] <ohsix> 17:51 < ohsix:#ffmpeg-devel> does this look weird to you btw http://paste.ubuntu.com/394242/
[02:04:25] <astrange> is that an out of pictures assertion?
[02:04:34] <ohsix> the one and only
[02:04:39] <astrange> if so does gst override release_buffer and then sometimes not release them?
[02:05:02] <ohsix> i can look in a minute, busy with something at the moment, looking at the nal stuff though, is that right for buf
[02:05:17] <astrange> http://trac.perian.org/browser/trunk/Patches/ffmpeg-larger-internal-buffer.diff
[02:05:35] <astrange> i didn't investigate hard enough to bring it up here
[02:27:05] <ohsix> it might very well be; i saw someone mention that when i last  brough tup this abort, i didn't get a stack dump then though; the _nal thing looks suspicious, i'd hoped someone could flatly state if its correct or not
[02:27:22] <ohsix> fwiw for the same content, it doesn't abort with ffplay
[02:28:10] <ohsix> the nal thing being #6  0x00007fffee8bd593 in decode_nal_units (h=0xb6f800, buf=0x8 <Address 0x8 out of bounds>, buf_size=518) at libavcodec/h264.c:2537
[02:28:45] <astrange> it's normal
[02:29:07] <astrange> debuginfo is inaccurate in most compilers with optimizations
[02:29:28] <astrange> (this is much improved in gcc 4.5)
[02:29:39] <ohsix> is it aptly named? it is dereferenced
[02:30:23] <ohsix> (thats as far as i looked)
[02:31:05] <ohsix> avpkt looks weird too #7  0x00007fffee8bdea6 in decode_frame (avctx=0x9487d0, data=<value optimized out>, data_size=0x7fffee66abec, avpkt=0xffffffffffffffff) at libavcodec/h264.c:2749
[02:31:19] <Dark_Shikari> it's gdb.
[02:32:04] <ohsix> well i have a build here without any optimization i can get a trace from, what places fault only with gdb?
[02:32:07] <astrange> the problem is with the debuginfo generation, not the debugger
[02:32:24] <Dark_Shikari> well yeah
[02:32:27] <astrange> but you don't need any of that anyway
[02:32:39] <astrange> just what the assert prints and a sample
[02:33:18] <ohsix> i have both, but the bug persists :P
[04:23:22] <ohsix> badnasty gdb has been dispatched, http://paste.ubuntu.com/394447/
[04:24:46] <ohsix> someone could have just said that buf is data from gst_ffmpegdec_frame ololol
[04:25:43] <ohsix> astrange: does it look like your buffer thing? it doesn't do it with ffplay
[04:37:30] <ohsix> astrange: dump with your patch applied (it does the same thing, but it takes a bit longer) http://paste.ubuntu.com/394452/
[04:38:05] <ohsix> i can point you to the sample and how to reproduce it
[05:07:54] <ohsix> http://paste.ubuntu.com/394462/ heres the last 1000 lines of the spew from ffmpeg before it explodes
[05:43:59] <ohsix> its weird, for all the years i've used ffdshow theres not been a single file of any sort i've had trouble with; yet its like every other file with totem/gstreamer + essentially the same bits behind the scenes
[05:56:52] <CIA-92> ffmpeg: conrad * r22493 /trunk/libavformat/oggparseogm.c: oggdec: Set packet duration for ogm streams
[05:56:53] <CIA-92> ffmpeg: conrad * r22494 /trunk/libavcodec/vp3.c: vp3: Simplify init_block_mapping
[05:56:54] <CIA-92> ffmpeg: conrad * r22495 /trunk/libavcodec/vp3.c: vp3: Init MVs to 0
[05:56:54] <CIA-92> ffmpeg: conrad * r22496 /trunk/libavcodec/vp3.c: vp3: Use memset to clear the fragment array
[05:56:54] <CIA-92> ffmpeg: conrad * r22497 /trunk/libavcodec/vp3.c: vp3: we only need a temp MV array of size 4
[05:56:55] <CIA-92> ffmpeg: conrad * r22498 /trunk/libavcodec/vp3.c: vp3: Make fragment_width _height by plane
[06:00:08] <CIA-92> ffmpeg: conrad * r22499 /trunk/libavcodec/vp3.c: vp3: remove unneeded error, this is internal and doesn't happen
[06:00:08] <CIA-92> ffmpeg: conrad * r22500 /trunk/libavcodec/vp3.c: theora: Add support for 4:2:2 and 4:4:4 subsampling
[09:05:28] <kshishkov> heh, http://c0389161.cdn.cloudfiles.rackspacecloud.com/dyn/str_strip/312503.full.gif
[09:44:17] <CIA-92> ffmpeg: stefano * r22501 /trunk/ (4 files in 2 dirs): (log message trimmed)
[09:44:17] <CIA-92> ffmpeg: Move error code definitions from libavcodec/avcodec.h to
[09:44:17] <CIA-92> ffmpeg: libavutil/error.h.
[09:44:17] <CIA-92> ffmpeg: Error code definitions and handling code belong to libavutil, where
[09:44:17] <CIA-92> ffmpeg: they can be shared by all the libav* libraries.
[09:44:18] <CIA-92> ffmpeg: See the thread:
[09:44:19] <CIA-92> ffmpeg: Subject: [FFmpeg-devel] [PATCH] Move error codes definitions from lavc to lavu
[09:53:36] <CIA-92> ffmpeg: stefano * r22502 /trunk/libavutil/error.h:
[09:53:36] <CIA-92> ffmpeg: Add missing parentheses around the AVERROR_PATCHWELCOME macro
[09:53:36] <CIA-92> ffmpeg: definition.
[10:00:25] <CIA-92> ffmpeg: stefano * r22503 /trunk/doc/APIchanges: Add APIchangelog entry for the libavutil/error.h addition.
[10:05:54] <DonDiego> moin
[10:06:04] <DonDiego> libavformat/matroskaenc.c:913: warning: suggest parentheses around && within ||
[10:06:12] <DonDiego> lame warning candidate of the day..
[10:08:58] <kshishkov> bah
[10:09:37] <kshishkov> the most idiotic I've seen is about array index bigger than array size in dca.c
[10:10:00] <kshishkov> and it can't be so because of condition before accessing array
[10:14:01] <DonDiego> you misunderstant
[10:14:03] <DonDiego> d
[10:14:37] <DonDiego> i consider the warning lame because nobody, especially not the dev who caused it can be bothered to fix it
[10:15:32] * kshishkov points to the warning at vc1dec.c
[10:18:53] <astrange> ohsix: it sounds like a buffer leak bug in gst ffmpeg's release_buffer callback
[10:19:04] <astrange> ohsix: of course if gst doesn't have one of those, it might not be
[10:21:17] <Yuvi> DonDiego: yo
[10:22:00] <Yuvi> DonDiego: so the only major theora work left in my tree is mc of entire mbs at once
[10:22:57] <Yuvi> which I'm going to hold of on merging until -mt since it'll probably make astrange rewrite it again
[10:23:15] <Yuvi> what problems were you having with seeking?
[10:23:23] <DonDiego> artifacts
[10:23:31] <Yuvi> with all files?
[10:23:57] <DonDiego> i think so
[10:24:03] <DonDiego> i'll give you details later
[10:24:12] <DonDiego> my trees are compiling right now
[10:24:23] <DonDiego> and i have a visitor for breakfast :)
[10:24:31] <Yuvi> ah
[10:24:53] <DonDiego> anyway, i'm superglad you've come this far
[10:24:59] <DonDiego> this is great news..
[10:25:08] <Yuvi> I know seeking doesn't work well if there aren't many pages or keyframes aren't flushed quite right
[10:25:09] * DonDiego hails Yuvi
[10:25:13] * DonDiego hails Yuvi some more
[10:25:26] * DonDiego hails Yuvi until his arms are tired and his throat is sore
[10:25:50] <astrange> i'm porting the reordered_opaque pts method from ffplay to ffmpeg
[10:26:19] <astrange> after that i think there are no issues merging mt theora
[10:26:35] <CIA-92> ffmpeg: conrad * r22504 /trunk/libavcodec/vp3.c:
[10:26:35] <CIA-92> ffmpeg: vp3: Split out motion vectors to their own array
[10:26:35] <CIA-92> ffmpeg: 1.5% faster overall decode on my penryn
[10:26:51] <astrange> and hopefully nobody will write error resilience or fill_edges support for it just yet
[10:27:40] <astrange> Yuvi: for "for sse2 it's nearly a wash between the added check vs. the time saved" do you mean loading dct coefficients into an xmm register and checking for all zeros in that?
[10:28:37] <Yuvi> astrange: no, I meant for doing doing the idct assuming they were zero (e.g. it's checked outside the call by last nnz)
[10:42:17] <CIA-92> ffmpeg: stefano * r22505 /trunk/libavfilter/vf_slicify.c: (log message trimmed)
[10:42:18] <CIA-92> ffmpeg: Extend the slice filter to make it issue slice height values randomly
[10:42:18] <CIA-92> ffmpeg: choosen between 8 and 32 when the supplied parameter is the string
[10:42:18] <CIA-92> ffmpeg: "random".
[10:42:18] <CIA-92> ffmpeg: This is useful for testing the slice support, but it is not supposed
[10:42:18] <CIA-92> ffmpeg: to be used by the user for other purposes and this interface may
[10:42:19] <CIA-92> ffmpeg: change in the future, and thus it is not documented.
[11:27:59] <CIA-92> ffmpeg: stefano * r22506 /trunk/libavfilter/ (avfilter.c avfilter.h defaults.c):
[11:27:59] <CIA-92> ffmpeg: Add AVFilterPic.pos field and make libavfilter propagate stream byte
[11:27:59] <CIA-92> ffmpeg: position information, as stored in the pkt.pos, through the
[11:27:59] <CIA-92> ffmpeg: filterchain.
[11:27:59] <CIA-92> ffmpeg: Note that the pos field is added *non* at the end of the
[11:27:59] <CIA-92> ffmpeg: AVFilterPicRef struct, thus breaking ABI compatibility, which is
[11:28:00] <CIA-92> ffmpeg: allowed as the API is still considered non-stable.
[11:28:00] <CIA-92> ffmpeg: stefano * r22507 /trunk/ffplay.c:
[11:28:01] <CIA-92> ffmpeg: Make ffplay pass the packet.pos information to the filterchain, get it
[11:28:01] <CIA-92> ffmpeg: again from the filterchain and pass it back to output_picture2().
[11:42:05] <CIA-92> ffmpeg: stefano * r22508 /trunk/ (libavfilter/avfilter.h doc/APIchanges):
[11:42:06] <CIA-92> ffmpeg: Bump libavfilter minor version and add APIchanges entry after the
[11:42:06] <CIA-92> ffmpeg: addition of the AVFilterPicRef.pos field.
[12:34:51] <CIA-92> ffmpeg: stefano * r22509 /trunk/libavfilter/vf_scale.c:
[12:34:51] <CIA-92> ffmpeg: Make the scale filter pass the pkt.pos information to the output
[12:34:51] <CIA-92> ffmpeg: picref.
[13:19:52] <Dark_Shikari> Yuvi: awesome, you did the DC only idct
[13:19:53] <Dark_Shikari> let me check that patch
[13:50:42] <Kovensky> Honoome: there?
[15:15:32] <DonDiego> mpeg12.c:2299: undefined reference to `ff_vdpau_mpeg_picture_complete'
[15:15:38] <DonDiego> anybody seeing the same error?
[15:15:54] <DonDiego> ./configure --enable-gpl --enable-postproc --disable-mmx2 --disable-sse && make
[15:32:33] <DonDiego> Yuvi: still around?
[15:44:12] <DonDiego> Yuvi: did you see all the theora/ogg bugs i assigned to you in roundup?
[15:44:24] <DonDiego> some may still be valid, dunno
[15:44:47] <DonDiego> also, what is the status of all those crashers that Dark_Shikari found by fuzzing?
[15:44:56] <DonDiego> Dark_Shikari: maybe you can tell me as well..
[15:47:10] <DonDiego> lu_zero: the roundup certificate expired...
[15:50:05] <DonDiego> Yuvi: [theora @ 0x74ebc4]7 bits left in packet 82
[15:50:11] <DonDiego> that looks like spam to me :)
[15:50:28] <Dark_Shikari> looks like ogg to me
[15:52:15] <mru> the difference?
[15:52:30] <Dark_Shikari> the file the spam is from?
[15:52:37] <Dark_Shikari> also, that same spam occurs for a whole lot of container formats iirc
[15:53:16] <DonDiego> well, my point is that i don't think the console should be spammed with debug messages like this
[15:53:30] <DonDiego> who cares how many bits were left in packet X?
[15:53:42] <Dark_Shikari> I agree, it should be left for verbose/debug mode
[15:53:52] <Dark_Shikari> then again, there _shouldn't_ be any bits left
[15:54:30] <DonDiego> Yuvi http://samples.ffmpeg.org/V-codecs/Theora/theora_testsuite/322x242_not-divisible-by-sixteen-framesize.ogg
[15:54:50] <DonDiego> mplayer places a black bar somewhere in the top of the image
[15:55:00] <DonDiego> with ffmpeg, but not with libtheora
[15:55:14] <DonDiego> can somebody verify with ffplay (my ffplay keeps crashing)
[15:56:35] <DonDiego> http://samples.ffmpeg.org/V-codecs/Theora/theora_testsuite/320x240.skeleton%2bcmml.ogv
[15:56:42] <DonDiego> this file seriously spams the console
[15:57:06] <DonDiego> [ogg @ 0x74cf04]Packet is missing granule
[15:57:11] <DonDiego> gets printed ad infinitum
[15:58:44] <DonDiego> http://samples.ffmpeg.org/V-codecs/Theora/theora_testsuite/multi2.ogg
[15:58:51] <DonDiego> that file fails to play at all with
[15:58:53] <DonDiego> LAVF_header: av_open_input_stream() failed
[15:59:15] <DonDiego> again with mplayer, but libtheora works fine
[15:59:29] <DonDiego> (confirmation with ffplay still appreciated..)
[16:00:23] <DonDiego> http://samples.ffmpeg.org/V-codecs/Theora/theora_testsuite/mobile_itu601_i_422.ogg
[16:00:37] <DonDiego> this one fails with mplayer unsuccessfully looking for a matching colorspace
[16:00:52] <DonDiego> could be an mplayer problem, but again libtheora is fine
[16:01:00] <siretart`> DonDiego: regarding the ia64 FTBFS, I cannot reproduce it on the debian porterbox
[16:01:30] <DonDiego> siretart`: weird..
[16:01:37] <DonDiego> any special cflags?
[16:01:42] <DonDiego> on either box?
[16:01:54] <siretart`> DonDiego: it might be fixed in gcc 4.4.3. fate tests with 4.4.2
[16:02:22] <siretart`> or maybe fate is using problematic cflags
[16:02:54] <siretart`> I'll reconfigure with fate's configure flags
[16:03:12] <DonDiego> ideally the fate boxes should not use any special flags..
[16:06:54] <mru> siretart`: the ia64 errors happen only with --enable-shared
[16:07:16] <mru> static build is fine
[16:07:24] <siretart`> still compiling here
[16:07:42] <siretart`> and I thought ia64 were fast.. ha
[16:08:16] <mru> it can be fast
[16:08:27] <mru> if you manage to write good code
[16:08:30] <Dark_Shikari> "ia64"  "fast"
[16:08:42] <Dark_Shikari> did those things even have simd?>
[16:08:46] <Dark_Shikari> other than x86_32 legacy simd
[16:08:46] <mru> writing good code for ia64 is still an unsolved problem
[16:08:53] <mru> don't know
[16:09:00] <mru> it's a vliw architecture
[16:09:09] <mru> and gcc *really* sucks with those
[16:09:10] <Dark_Shikari> it only does 3 operations per vliw though
[16:10:10] <Kovensky> more funny acronyms?
[16:10:31] <mru> very long instruction word
[16:10:44] <mru> it was all the rage in the 90s
[16:10:52] <Kovensky> heh
[16:11:01] <Kovensky> hmm, IIRC it had some funny instruction length
[16:11:06] <Kovensky> it was 41-bit IIRC
[16:11:12] <mru> no
[16:11:30] <mru> maybe each instruction within a bundle is some odd length
[16:11:43] <mru> but they'll always come in word-aligned groups
[16:11:50] <Kovensky> hmm
[16:11:52] <siretart`> mru: do you have a clue *why* ffmpeg fails to build on ia64?
[16:11:58] <mru> yes
[16:11:59] * Kovensky should find again the page where he saw that but :effort:
[16:12:03] <mru> the error message says it all
[16:12:35] <mru> it's trying to shove a >4MB offset into 22 bits
[16:12:35] <Kovensky> CC      /usr/home/kovensky/src/kovensky/build/build_libs/lib/libavcodec.a
[16:12:35] <Kovensky> CC      /usr/home/kovensky/src/kovensky/build/build_libs/lib/libavcodec.a
[16:12:37] <Kovensky> o_O
[16:12:47] <mru> uh?
[16:12:53] <Kovensky> huh indeed
[16:13:00] <Kovensky> it apparently is using a silent makefile
[16:13:03] <mru> how did you manage that?
[16:13:06] <Kovensky> no idea
[16:13:10] <Kovensky> I just git pulled and ran make
[16:13:11] <Kovensky> lol
[16:13:30] <Kovensky> more importantly, it's showing the wrong filename on the CC lines
[16:13:31] <mru> make config and try again
[16:13:54] <Kovensky> (forgot to mention it was reconfigured)
[16:14:01] <mru> configure line?
[16:14:33] <mru> 'cause it does the right thing here
[16:14:35] <siretart`> mru: is this something we can fix in ffmpeg? the fact that gcc 4.5 manages to compile it makes we wonder...
[16:14:40] <mru> no
[16:15:06] <siretart`> ok
[16:15:07] <mru> gcc seems to assume .bss will never be more than 4MB away from .text
[16:15:16] <mru> which is pretty insane
[16:15:22] <mru> our .bss is ~5MB
[16:15:38] <siretart`> oh, I see. thanks for explanation
[16:16:47] <peloverde> siretart`, DonDiego: Is there anything I can do to help with the release?
[16:17:13] <Dark_Shikari> run the fuzzer on mp4, mkv, h264, aac, ogg, theora, vorbis? ;)
[16:18:26] <DonDiego> peloverde: find out if there are any regressions or important bugs that are pending
[16:18:58] <DonDiego> peloverde: confirm the problems with theora i wrote about above in ffplay
[16:19:08] <DonDiego> check fate, there are a bunch of failures
[16:19:10] <siretart`> okay, I can reproduce the ia64 link problem with --enable-shared.
[16:19:18] <siretart`> but I think we can ignore that for 0.6
[16:20:29] <DonDiego> mru: is it normal that avr and blackfin fail so many tests?
[16:21:12] <mru> they always do
[16:21:33] <mru> gcc-avr32 is incredibly buggy
[16:21:34] <DonDiego> so no need to keep them on the radar for the release?
[16:22:35] <mru> I don't think anyone really cares
[16:22:43] <DonDiego> ok, fine then
[16:22:55] <DonDiego> ramiro: what about cygwin fate failures?
[16:23:55] <DonDiego> and then there is mac os x powerpc regtests
[16:24:34] <DonDiego> TEST VCODEC dnxhd_720p_rd
[16:24:39] <DonDiego> this one fails there..
[16:58:25] <DonDiego> peloverde: and thanks for the offer to help out with the release, it's much appreciated
[17:14:48] <siretart`> and also many thanks to all who offered to translate the release notes!
[17:15:15] <BBB> you forget that for native speakers in whatever language, this is no effort whatsoever :)
[17:16:16] <sancode> Hello.
[17:17:11] <kshishkov> BBB: try understanding English first
[17:17:55] <BBB> you're suggesting my english is poor :(
[17:18:12] <kshishkov> no, only the fact you forgot one condition
[17:26:20] * BBB conceeds
[17:27:02] <kshishkov> BBB: while you're at it, you can translate something into Dutch from Zulu or Quechua
[17:27:37] <siretart`> How about release notes in Quenya? ;-)
[17:27:52] <kshishkov> Sindarin
[17:28:17] * BBB has most of the zulu -> dutch is easy
[17:28:18] <kshishkov> and we need to agree on who edits final translation to Japanese
[17:28:26] <BBB> dutch -> zulu would take a zulu speaker
[17:28:32] <BBB> what's quenya?
[17:28:46] <BBB> wait, that first sentence was weird
[17:28:51] <BBB> why don't we cut the first half of it
[17:28:54] <BBB> then it makes sense
[17:29:04] <kshishkov> BBB: elfish language invented by JRRT after being exposed to Finno-Ugric languages
[17:29:36] <siretart`> BBB: high elfish, language of the elders
[17:29:56] <BBB> uh
[17:29:57] <BBB> no
[17:29:58] <BBB> :)
[17:30:22] <Dark_Shikari> translate it to orkish
[17:30:29] <kshishkov> nazghul
[17:30:50] <Dark_Shikari> no, I mean warhammer 40k ork
[17:30:51] <Dark_Shikari> ;)
[17:31:53] <kshishkov> or that language in Myst
[17:32:17] <kshishkov> and don't you dare to forget Klingon
[17:32:44] <Kovensky> lojban?
[17:33:04] <kshishkov> no
[17:33:19] <kshishkov> it does not compile anyway
[17:42:13] <BBB> what does a complex multiplication of x = {re1, im1}, y = {re2, im2}; x * y= ..? look like?
[17:42:51] <peloverde> real part: re1*re2 - im1*im2
[17:43:08] <peloverde> imaginary part re1*im2 + im1*re2
[17:43:48] <elenril> simply (re1 + i*im1)(re2 + i*im2)
[17:43:50] <BBB> do we have a function for that in FFmpeg?
[17:43:59] <kshishkov> look in fft.c ;)
[17:44:32] <kshishkov> BBB: at least you're unlikely to meet quaternions :)
[17:44:43] <peloverde> BBB, c99 complex.h supports it. we don't require c99 complex.h :(
[17:44:58] <BBB> oh, unlovely :(
[17:47:09] <kshishkov> BBB: you should try to write FFT implementation from scratch at least once in your life
[17:47:17] <BBB> I already did
[17:47:23] <BBB> without knowing it at that point
[17:47:32] <BBB> I RE'ed the FFT in wmavoice
[17:47:35] <BBB> that's FFT right there
[17:47:53] <kshishkov> I usually skip such parts
[17:48:05] <BBB> I would if I had to do it again
[18:08:54] <ohsix> astrange: thanks, you might be on to something; last time there was an event similar in the log there were a _bunch_ of release buffer messages
[18:14:18] <ohsix> BBB: what was your unknowing fft?
[18:18:15] <CIA-92> ffmpeg: aurel * r22510 /trunk/libavcodec/avcodec.h: bump minor avcodec version for libxvid codec id change (r22489)
[18:19:13] <BBB> ohsix: I have no idea what I'm doing
[18:19:22] <ohsix> :>
[18:19:22] <BBB> ohsix: that doesn't mean what I'm doing could not be fft
[18:19:34] <kshishkov> BBB: look at libavcodec/truespeech.c again
[18:19:34] <ohsix> i see
[18:19:46] <ohsix> has someone pointed you to that dspguru book yet?
[18:19:59] <BBB> kshishkov: well, :)
[18:20:23] <CIA-92> ffmpeg: aurel * r22511 /trunk/libavcodec/avcodec.h: CODEC_ID_XVID is not used anywhere, remove it at next major bump
[18:20:37] <kshishkov> BBB: that's a good example of someone not knowing what he does and noone to explain it to him either
[18:21:06] <BBB> lol :)
[18:21:13] <BBB> kshishkov: would you want me at some point to rewrite that?
[18:21:14] <kshishkov> but it's true
[18:21:30] <BBB> didn't mike re a codec at some point where he had no idea what he was doing?
[18:21:33] <kshishkov> BBB: you'd better write encoder for it, it was requested
[18:21:35] <BBB> and then someone redoing it 10 yrs later?
[18:22:00] <kshishkov> I don't have a slightest idea about what Xan codec you're speaking about
[18:22:25] <BBB> if I do a complex FFT (i.e. not RDFT), are only the first 0x82 filled out after fft()?
[18:22:29] <BBB> and the rest empty?
[18:22:32] <BBB> (7-bit-radius fft)
[18:22:52] <kshishkov> s/radius/radix/
[18:23:00] <BBB> :)
[18:23:10] <BBB> see, I have no friggin' clue what I'm talking about ;)
[18:23:18] <BBB> but is it true?
[18:23:39] <kshishkov> first of all, FFTs employed are usually have lengths = power of two
[18:23:55] <BBB> so I have FFTComplex[0x80] as input, and after fft(), only the first the first [0x41] are filled?
[18:24:23] <kshishkov> theoretically it should fill all 0x80 elements
[18:24:29] <ohsix> it doesn't fill the other half with something too?
[18:25:21] <kshishkov> every frequency affects all samples after all, something like that for time->frequency domain translation too
[18:26:44] <kshishkov> BBB: if it fills only first 64 complex numbers maybe it's 64-point FFT
[18:28:16] * BBB goes try his theory that one of his calcs is actually FFT instead of RDFT
[18:28:20] * BBB wonders how to test that
[18:29:16] <kshishkov> see whether it ignores imaginary part of output or not
[18:31:22] <BBB> the binary does
[18:31:30] <BBB> but here's the thing: the binary has many bugs already
[18:32:01] <BBB> and it actually calculates the output of fft(), and then does ifft(), ..., fft() and that's the end of it
[18:32:13] <BBB> but when calculating the initial values, im[0] and im[0x40] are not(!) zero
[18:32:40] <BBB> suggesting that it represents the fft of something where the input was not merely real
[18:32:42] <BBB> right?
[18:32:49] <kshishkov> yes
[18:32:58] <BBB> so I think the binary screws up
[18:33:15] <BBB> so I want to see if output improves if I do actual FFT instead of RDFT
[18:33:38] <BBB> of course I could easily totally screw up
[18:33:45] <BBB> but that's ok, since I don't know what I'm doing anyway
[18:33:59] <kshishkov> d'you wanna end with yer decoder producing better crap than original?
[18:37:16] <BBB> it already does!
[18:37:32] <BBB> much better, in fact, particularly in low-bitrate mode
[18:37:57] <BBB> I don't care much about the binary, I want to know the theory of music / speech encoding
[18:38:04] <BBB> merely reproducing the binary isn't very interesting
[18:38:12] <BBB> understanding it and improving it where possible, is much cooler
[18:38:32] <kshishkov> read a paper by Noll then
[18:39:02] * BBB will first just try random things
[18:39:17] <BBB> I currently just let the code modify data, print data before/after, print the results in a graph and see what it did
[18:39:24] <BBB> "aha, so that's what $process is/does"
[18:40:11] <kshishkov> BBB: read papers from here. http://www.eas.asu.edu/~spanias/papers.html
[18:43:34] <peloverde> IMHO you have to be very careful about "improving" the quality in comparison to the binary on such codecs, at some point they may recognize those bugs as part of the format and try to work around them in the encoder
[18:44:09] <kshishkov> M$? work around bugs?
[18:44:21] <kshishkov> they are famous for bug-for-bug compatibility!
[18:44:50] <peloverde> that's exactly what I'm saying
[18:44:59] <peloverde> so the decoder, stays invariant
[18:45:30] <peloverde> and instead tehy release an improved encoder that spits out better output for the mathematically unsound decoder
[18:45:50] <peloverde> all previous bitstreams are bug for bug compatible
[18:46:35] <kshishkov> are they known for actually _improving_ stuff either?
[18:46:36] <peloverde> One there is only one decoder, it isn't a bug in the decoder, it's a flaw in the format
[18:47:37] <BBB> peloverde: well, I'm not sure
[18:48:06] <BBB> peloverde: my impression, from looking over the postfilter, is that there's a lot of crap in here that shouldn't be there, made up to improve the bastardized output of the pure speech synthesis part itself
[18:48:11] <BBB> anyway
[18:48:15] <BBB> it sounds good, so I think it's fine
[18:48:20] <peloverde> ok
[18:48:30] <BBB> I agree I shouldn't go too far
[18:49:09] <kierank> hmm I wonder what "Dolby E Encoder Simulation" refers to
[18:49:43] <kshishkov> kierank: more context please
[18:49:56] <ohsix> is it actual speech synthesis? cuz there often is a bunch of garbage tacked on those things to make it sound better
[18:50:40] <BBB> postfilter
[18:50:41] <BBB> right
[18:50:46] <BBB> all I'm looking at now is postfilter
[18:51:35] <kierank> kshishkov: It's just a string that seems to be at the beginning of the Dolby decoding api
[18:52:13] <kshishkov> kierank: probably just encoder name, ignore it
[18:59:58] <BBB> interesting audio effect
[19:00:03] * BBB probably screwed up somewhere
[19:11:26] <BBB> is this a lowpassfilter? http://people.gnome.org/~rbultje/lowpassfilter.png
[19:12:03] <mru> not a very good one
[19:12:20] <peloverde> BBB, is that the same thing we were discussing thusday?
[19:12:24] <BBB> no
[19:12:35] <BBB> different piece of code
[19:12:36] <mru> BBB: can you plot output/input
[19:12:44] <mru> and also log(output/input)
[19:12:57] <mru> by frequency of course
[19:13:21] <peloverde> Do you have coefs for this filter?
[19:20:31] <CIA-92> ffmpeg: stefano * r22512 /trunk/ (libavcodec/iff.c libavutil/error.h):
[19:20:31] <CIA-92> ffmpeg: Make iff.c:decode_init return the value returned by
[19:20:31] <CIA-92> ffmpeg: avctx->get_buffer() in case of error, rather than AVERROR_UNKNOWN
[19:20:31] <CIA-92> ffmpeg: which is deprecated, and mark AVERROR_UNKNOWN for deletion at the next
[19:20:31] <CIA-92> ffmpeg: major bump.
[19:20:32] <CIA-92> ffmpeg: stefano * r22513 /trunk/ (7 files in 3 dirs):
[19:20:33] <CIA-92> ffmpeg: Replace all the occurrences of AVERROR_EIO with AVERROR(EIO), and mark
[19:20:33] <CIA-92> ffmpeg: AVERROR_EIO for deletion at the next major bump.
[19:20:34] <CIA-92> ffmpeg: stefano * r22514 /trunk/libavutil/error.h:
[19:20:34] <CIA-92> ffmpeg: Mark AVERROR_ENOMEM to be deleted at the next major bump.
[19:20:35] <CIA-92> ffmpeg: AVERROR(ENOMEM) must be used instead, and there are no occurrences of
[19:20:35] <CIA-92> ffmpeg: AVERROR_ENOMEM in the FFmpeg basecode so it can be safely dropped.
[19:27:15] <ramiro> DonDiego: things are failing randomly on my vboxes. it started failing last week or so. I guess the ram has gone bad.
[19:28:04] <ramiro> usually it's only one cygwin test or so, but I got an ICE compiling on mingw a couple of days ago that had never happened.
[19:28:46] <ramiro> the cygwin errors are always signal 15. it might be a bug in cygwin.
[19:42:52] <BBB> peloverde: no coefficients, this is an actual FFT-based filter
[19:43:16] <peloverde> BBB, so then what does the FFT of the filter look like?
[19:43:23] <BBB> mru: what you saw was input/output FFT (frequencies), so you want log-based instead?
[19:43:32] <BBB> peloverde: it's very large
[19:43:41] <BBB> it's multiple functions
[19:43:59] <BBB> shall I post the whole patch online?
[19:46:40] <peloverde> If it's that final computed FFT domain function, it may be harder to name than just lowpass, highpass, bandpass, etc
[19:47:14] <BBB> http://people.gnome.org/~rbultje/lowpassfilter2.png
[19:47:19] <BBB> log-based frequencies
[19:47:20] <kshishkov> depends on manipulation type
[19:47:29] <peloverde> siretart`, I found one issue with the SBR decoder, biasing for int_to_float_16_c causes us to lose precision when the signal is very small
[19:47:54] <BBB> peloverde: yes it's that one
[20:09:22] <peloverde> my guess is that it's some sort of matched emphasis filter
[20:11:27] <peloverde> siretart`, DonDiego, I have one AAC fix coming down the pipe
[20:14:50] <siretart`> peloverde: cool! you rock!
[21:04:43] <pasteeater> superdump: is your server/site dead?  i've been getting timeouts for a week.
[21:05:11] <pasteeater> or maybe a few days.  can't remember.
[21:05:45] <superdump> since the concepcion earthquake
[21:05:50] <superdump> it's offline
[21:06:02] <superdump> i don't know what's happening with it
[21:06:12] <superdump> i may just start a new blog somewhere else
[21:06:46] <pasteeater> was it located in Chile?
[21:06:49] <superdump> yes
[21:08:45] <pasteeater> i guess that was a dumb question.
[21:13:05] <CIA-92> ffmpeg: alexc * r22515 /trunk/libavcodec/ (aac.c aacsbr.c): aac: Don't bias output during the IMDCT if SBR will be used.
[21:13:05] <CIA-92> ffmpeg: alexc * r22516 /trunk/libavcodec/aacsbr.c: aacsbr: DSPUtilize analysis input scaling.
[21:14:11] <peloverde> siretart`, DonDiego: AAC fixes applied. AAC verfied on amd64 4.4.3-3ubuntu3, amd64 (noasm) 4.4.3-3ubuntu3, amd64 clang-svn.
[21:16:34] <pasteeater> siretart`: i'm the one who submitted LP 538555 by the way, but i'm going to be out of town for a week, in case i don't respond...
[22:47:28] <Yuvi> DonDiego: saw the bugs, I don't know much about vorbis but I'll look at them
[22:47:54] <Yuvi> DonDiego: mplayer fixed with non-4:2:0
[22:53:06] <DonDiego> Yuvi: a bunch of the bugs are not about vorbis, but about ogg and theora, most of them i think
[22:53:13] <Yuvi> yeah
[22:54:57] <DonDiego> can we quickly go over the theora status in trunk?
[22:55:08] <DonDiego> IIUC you merged all your speedup work, right?
[22:56:30] <Yuvi> not quite, DC-only is pending (will apply w/ michaels comments really soon), and I'm going to wait until -mt is merged to do MC of entire MBs at once (since it's likely to make astrange rewrite -mt again)
[22:56:39] <Yuvi> but other than that it should be merged
[22:56:55] <Yuvi> multi2.ogg works in ffplay, but not mplayer, hm
[22:57:31] <DonDiego> how much speedup does dc-only provide?
[22:57:38] <Yuvi> 2-4%
[22:57:43] <DonDiego> good stuff
[22:58:06] <DonDiego> what about the console spam? :)
[23:01:00] <J_Darnley> Yuvi: If you are working on ogg, do you plan on altering vorbis header writing?
[23:01:54] <Yuvi> DonDiego: let me see if that persists when I move the warning to the right place, I'd still like to complain about those invalid files
[23:02:13] <DonDiego> i cannot believe that *all* ogg files are invalid
[23:02:33] <Yuvi> dunno why mplayer is complaining so, ffplay doesn't
[23:02:38] <Yuvi> J_Darnley: not in the muxer
[23:02:46] <J_Darnley> ok
[23:02:59] <DonDiego> hmm, i need to test in ffplay, but it does not work on os x right now..
[23:03:21] <Yuvi> get a half-working sdl? (fully working sdl on os x is impossible I think)
[23:04:06] <Yuvi> or maybe they broke it on ppc
[23:07:45] <DonDiego> yeah, i suspect sdl is at fault
[23:08:10] <DonDiego> i'm recompiling on my x86 box, but it's slow..
[23:09:16] <DonDiego> http://samples.ffmpeg.org/V-codecs/Theora/theora_testsuite/322x242_not-divisible-by-sixteen-framesize.ogg
[23:09:25] <DonDiego> Yuvi: does this sample work properly for you?
[23:10:32] <Yuvi> the black bar seems to be something weird going on in mplayer's, it happens for snow too
[23:10:39] <Yuvi> except worse
[23:10:50] <DonDiego> k
[23:12:32] <DonDiego> Yuvi: so what else do you have on your plate?
[23:12:43] <DonDiego> what about all the bugs that the fuzzing uncovered?
[23:16:20] <Yuvi> main think I think is making seek work well, there's too many situations it doesn't (due to the whole granule is the end time not interacting with lavf's generic binary search)
[23:16:43] <DonDiego> k
[23:17:03] <DonDiego> btw, by spam i meant the "X bits left in packet 82" thing
[23:17:16] <DonDiego> that looks quite bogus and gets printed for every file
[23:17:16] <Yuvi> I should get that mostly done today, then I'll do fuzz bugs
[23:17:51] <DonDiego> cool
[23:18:22] <DonDiego> oh, the amount of beer that i owe you :)
[23:18:23] <Yuvi> that spam I'm not entirely sure about because I don't think I've ever looked at what's in the third header packet
[23:29:08] <DonDiego> http://samples.ffmpeg.org/V-codecs/Theora/theora_testsuite/mobile_itu601_i_422.ogg
[23:29:19] <DonDiego> Yuvi: that video gets stuck with ffplay for me
[23:29:36] <DonDiego> mplayer works fine with libogg/libtheora
[23:31:46] <DonDiego> http://samples.ffmpeg.org/V-codecs/Theora/ED-small-sample-file.ogg
[23:31:53] <DonDiego> that one gets stuck similarly
[23:32:08] <DonDiego> and crashes when quitting
[23:32:20] <DonDiego> glibc detected invalid pointer or whatnot
[23:33:30] <Yuvi> weird, they both work for me with ffplay
[23:37:16] <DonDiego> well, the crash might be related to some of the bugs the fuzzer uncovered
[23:37:19] <Yuvi> so 320x240.skeleton+cmml.ogv does indeed appear to be invalid despite being in the theora testsuite
[23:37:37] <DonDiego> oh, i'm not surprised
[23:37:54] <kierank> lol
[23:37:59] <DonDiego> i was the one to notice that all the files in the testsuite originally were invalid :)
[23:38:33] <DonDiego> see the theora_testsuite_invalid directory
[23:38:48] <DonDiego> i ran that ogg verification tool that they have against them
[23:38:54] <DonDiego> there was a muxing bug..
[23:39:26] <Yuvi> heh