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

[irc at mansr.com]

[00:39:56] <CIA-92> ffmpeg: mru * r22443 /trunk/configure:
[00:39:56] <CIA-92> ffmpeg: configure: add --disable-everything option
[00:39:56] <CIA-92> ffmpeg: This disables all codecs, formats, etc. It saves some typing when
[00:39:56] <CIA-92> ffmpeg: only a few components are desired.
[00:39:56] <CIA-92> ffmpeg: mru * r22444 /trunk/configure: configure: use map() function in a couple of places
[00:43:01] <CIA-92> ffmpeg: mru * r22445 /trunk/configure: configure: remove stray semicolon
[02:32:52] <CIA-92> ffmpeg: mru * r22446 /trunk/libavcodec/dsputil.c:
[02:32:52] <CIA-92> ffmpeg: Add some required casts
[02:32:52] <CIA-92> ffmpeg: These casts are correct and safe. The pointers are guaranteed to
[02:32:52] <CIA-92> ffmpeg: have proper alignment, and aliasing is not a problem with character
[02:32:52] <CIA-92> ffmpeg: types.
[02:32:53] <CIA-92> ffmpeg: mru * r22447 /trunk/ffplay.c: ffplay: use correct format specifiers in printf()
[02:32:54] <CIA-92> ffmpeg: mru * r22448 /trunk/libavcodec/snow.h:
[02:32:54] <CIA-92> ffmpeg: snow: remove unused stub functions
[02:32:55] <CIA-92> ffmpeg: w53_32_c() and w97_32_c() are defined as stubs when snow encoder is
[02:32:55] <CIA-92> ffmpeg: disabled. In this case, those functions are not referenced at all
[02:32:56] <CIA-92> ffmpeg: and do thus not need to be defined.
[02:32:56] <CIA-92> ffmpeg: mru * r22449 /trunk/libavutil/sha.c: sha: add missing include
[02:32:57] <CIA-92> ffmpeg: mru * r22450 /trunk/libavutil/random_seed.c: random_seed: try other alternatives if reading /dev/random fails
[02:32:57] <CIA-92> ffmpeg: mru * r22451 /trunk/libavutil/random_seed.c: indent
[02:35:53] <CIA-92> ffmpeg: michael * r22452 /trunk/ffplay.c:
[02:35:53] <CIA-92> ffmpeg: Implement framedrop.
[02:35:53] <CIA-92> ffmpeg: Replace SDL timer by a seperate thread, more accurate and less annoying.
[02:35:53] <CIA-92> ffmpeg: frame drop is enabled by default, bug reports welcome.
[02:35:53] <CIA-92> ffmpeg: Fixes issue1191
[03:47:49] <astrange> i was going to redo ffmpeg.c's a/v sync to use reordered_opaque but it requires changing more stuff than i'd hoped, hm
[06:26:52] <KotH> moin
[06:59:14] <elenril> anyone familiar with how put_bmp_header() works?
[06:59:30] <elenril> i wonder why it pads the extradata to even size, but doesn't account for it in size
[07:00:42] <kshishkov> because it's in the spec
[07:00:49] <elenril> in what spec?
[07:00:55] <kshishkov> otherwise it would be treated as part of extradata
[07:01:24] <elenril> got a link?
[07:01:39] <kshishkov> let's just say that all M$ spec include padding - in AVI chunks, in BMP spec as well
[07:01:51] <kshishkov> bbl
[07:02:02] <elenril> well wmp has problems with this
[07:18:01] <Yuvi> there, the ogg demuxer now seeks to keyframes at least as well as mplayer
[07:18:36] <CIA-92> ffmpeg: conrad * r22453 /trunk/ (3 files in 2 dirs): oggdec: Save offset of the page needed to reconstruct the current packet
[07:18:36] <CIA-92> ffmpeg: conrad * r22454 /trunk/ (libavformat/oggdec.c tests/ref/seek/lavf.ogg.ref):
[07:18:36] <CIA-92> ffmpeg: oggdec: Set data_offset to the right value
[07:18:36] <CIA-92> ffmpeg: Otherwise it gets set automatically to a page midstream and prevents seeking
[07:18:37] <CIA-92> ffmpeg: to the first page.
[07:18:37] <CIA-92> ffmpeg: conrad * r22455 /trunk/libavformat/ (oggdec.c oggdec.h):
[07:18:38] <CIA-92> ffmpeg: oggdec: Move ogg_find_stream and ogg_gptopts to oggdec.h
[07:18:38] <CIA-92> ffmpeg: (skeleton will need them)
[07:18:39] <CIA-92> ffmpeg: conrad * r22456 /trunk/libavformat/oggdec.h: oggdec: Check that we have a codec in gptopts (needed for skeleton)
[07:18:39] <CIA-92> ffmpeg: conrad * r22457 /trunk/libavformat/ (oggdec.c Makefile oggparseskeleton.c oggdec.h): oggdec: Parse skeleton to determine the start time of each stream
[07:18:40] <CIA-92> ffmpeg: conrad * r22458 /trunk/libavformat/oggdec.c: oggdec: Fix duration calculation for streams with non-zero start
[07:18:40] <CIA-92> ffmpeg: conrad * r22459 /trunk/libavformat/ (oggparsespeex.c oggparsevorbis.c): oggdec: Don't use ogg_stream's seq for vorbis or speex headers
[07:19:21] <CIA-92> ffmpeg: conrad * r22460 /trunk/libavformat/oggparsevorbis.c: oggdec: Fix memory leak in setting up vorbis headers
[07:19:21] <CIA-92> ffmpeg: conrad * r22461 /trunk/libavformat/oggdec.c: oggdec: Move PTS/DTS calculation to a function
[07:19:21] <CIA-92> ffmpeg: conrad * r22462 /trunk/ (libavformat/oggdec.c tests/ref/seek/lavf.ogg.ref):
[07:19:21] <CIA-92> ffmpeg: oggdec: Determine pts and filepos on a packet basis in read_timestamp
[07:19:21] <CIA-92> ffmpeg: This takes into account whether the granule defines the start or end times
[07:19:22] <CIA-92> ffmpeg: of packets, and sets the correct file offset of the associated page.
[07:19:22] <CIA-92> ffmpeg: conrad * r22463 /trunk/libavformat/ (oggdec.c oggdec.h): oggdec: Seek to keyframes
[07:19:51] <Yuvi> now to finish the *really* ugly stuff to fix issue 592 and make it able to seek to individual packets
[07:23:26] <astrange> i didn't notice until just now that the mkv encoder can't do skippable simpleblocks
[07:23:35] <astrange> i guess that needs pkt_flag_skippable or something :/
[07:23:59] <Yuvi> yeah, I don't think the api is there for that unfortunately :(
[07:43:15] <astrange> Dark_Shikari: can i have your fuzzer? i want to make sure there's no deadlocks in h264+mt
[07:46:27] <Dark_Shikari> astrange: ok
[07:47:03] <Dark_Shikari> piece 1: http://pastebin.org/109455
[07:47:22] <Dark_Shikari> piece 2:
[07:47:23] <Dark_Shikari> gcc -Wall -O3 -lavutil fuzzer.c -o fuzzer;rm log.$x.txt;rm failures.$x.txt;for a in $(seq 100000 120000);do echo $a >> failures.$x.txt;nice -n19 ./fuzzer input.ogv test.$x.ogv $a;export a;nice -n19 bash -c 'ffmpeg -y -i test.ogv -f null /dev/null > log.$x.txt 2>&1' 2>> failures.$x.txt;done
[07:47:35] <Dark_Shikari> where $x is some number (to allow many simultaneous scripts)
[07:47:45] <Dark_Shikari> piece 3: while true;do v=$(top -n 1 -b | grep ffmpeg | cut -c47-48);echo $v;if [ $v -gt 50 ]; then echo "killing";kill -9 `top -n 1 -b | grep ffmpeg | grep -v "grep" | cut -c1-5`;fi;sleep 1;done
[07:48:38] <Dark_Shikari> to autokill processes that use up all the memory (due to that bug/bad behavior in interleaved_write)
[07:48:56] <Dark_Shikari> note this is preferable to ulimits because it tells you in the log that it was KILLED, not segfaulted, so it distinguishes it from a crash.
[07:49:22] <Dark_Shikari> you can repurpose it for CPU time instead of memory usage trivially, which would allow you to catch deadlocks in an automated manner
[07:49:54] <Dark_Shikari> (I would prefer to run both simultaneously, to avoid oom)
[07:50:29] <Dark_Shikari> oom was a huge problem with fuzzing ogg
[08:25:10] <CIA-92> ffmpeg: mstorsjo * r22464 /trunk/libavformat/rtsp.c:
[08:25:10] <CIA-92> ffmpeg: RTSP muxer: Create the SDP with the numerical IP of the peer
[08:25:10] <CIA-92> ffmpeg: instead of using the original host name
[08:33:56] <CIA-92> ffmpeg: mstorsjo * r22465 /trunk/libavformat/rtsp.c: Cosmetics, break a long line, fix brace placement
[10:18:19] <bilboed-tp> siretart`, I can't see those arguments here :)
[10:18:51] <siretart`> bilboed-tp: sorry? you yelled your opinion on sticking with 0.5 very vocally in this channel
[10:19:05] <bilboed-tp> yah... TWELVE MONTHS AGO
[10:19:14] <siretart`> no, this week
[10:19:39] <siretart`> but anyway, I think we agree on the problem, but (maybe) disagree on the way to go
[10:20:53] <DonDiego> what's the beef now?
[10:21:44] <pJok> mornings :)
[10:42:05] <kshishkov> pJok: goda flera morgnar
[10:51:08] <kshishkov> mate!
[10:51:17] <pross-au> Gday
[10:52:01] <kshishkov> I've looked at all binkw32.dll I can finds (i.e. 0.5a and 0.8a) and indeed, looks like there's no BIK[ac-e]
[10:53:27] <CIA-92> ffmpeg: pross * r22466 /trunk/libavcodec/binkaudio.c: Make binkaudio work with ff_float_to_int16_interleave_c (martin at martin dot st)
[10:57:53] <pross-au> you're going to have to dig deeper kshishkov
[10:59:47] <kshishkov> no, simply put ESAMPLEWELCOME somewhere and forget about it
[11:00:12] * kshishkov wants to RE that old WMV3 format
[11:03:57] <DonDiego> kshishkov: yes, please RE that :)
[11:04:49] <kshishkov> that would require either working VM or an act of necromancy
[11:07:24] <pross-au> there's another WMV3 format?
[11:07:46] <kshishkov> yes, older one
[11:08:04] <pross-au> You're really scaping the bottom of the barrel kshishkov
[11:08:36] <kshishkov> at least I have many barrels to scrap
[11:08:43] <kshishkov> any suggestions on what to RE?
[11:09:09] <pross-au> Pace yourself!
[11:09:21] <kshishkov> hmm?
[11:09:39] <pross-au> VP7
[11:09:53] <pross-au> But its even more pointless then Bink Audio
[11:10:08] <kshishkov> what's not pointless then?
[11:10:21] <pross-au> MS-MPEG4
[11:10:29] <kshishkov> we have that
[11:10:30] <pross-au> (Past tense though)
[11:10:52] <DonDiego> kshishkov: vp4
[11:10:58] <DonDiego> on2 audio
[11:11:06] <DonDiego> oh, i have a good one: twinvq
[11:11:35] <kshishkov> DonDiego: ask Vitor to remove current twinvq support first ;)
[11:14:18] <kshishkov> I agree we should RE those VP codecs though
[11:16:46] <DonDiego> urm
[11:16:52] <DonDiego> that's not the one i mean..
[11:18:16] <pross-au> VP4 and VP7?
[11:18:19] <DonDiego> voxware
[11:18:27] <DonDiego> kshishkov: voxware, go for that one..
[11:18:41] <kshishkov> pross-au: both
[11:18:56] <DonDiego> kshishkov: there's also a vp3 variation we do not support
[11:18:57] <kshishkov> DonDiego: that's not fair, I was the one who asked for supporting it
[11:19:00] <DonDiego> vp31 or so
[11:19:10] <kshishkov> unlikely
[11:19:12] <DonDiego> kshishkov: hmm?
[11:19:19] <DonDiego> you asked for what?
[11:19:31] <kshishkov> for voxware support
[11:19:43] <DonDiego> from whom?
[11:19:54] <DonDiego> i'm not following
[11:20:09] <kshishkov> I expressed a wish for it to be supported
[11:20:22] <DonDiego> where?
[11:20:32] <kshishkov> here, on IRC
[11:20:50] <pross-au> kshishkov: SO! You've convinced DonDiego to share that Wish too
[11:21:13] <DonDiego> i've wanted voxware for a long time
[11:21:35] <kshishkov> here pirates used it instead of MP3 for rips
[11:21:46] <kshishkov> what's your reasoon?
[11:22:37] <DonDiego> i have a cool old movie that uses it
[11:22:39] <DonDiego> vamps
[11:23:00] * kshishkov has some cool old movies using it too
[11:23:45] <DonDiego> is it settled then? :)
[11:23:58] <kshishkov> yes, let's go convince voroshil ;)
[11:24:05] <DonDiego> http://www.imdb.com/title/tt0114826/
[11:25:32] <kshishkov> mine is better - http://www.imdb.com/title/tt0062759/
[11:26:40] <CIA-92> ffmpeg: michael * r22467 /trunk/ffplay.c:
[11:26:40] <CIA-92> ffmpeg: Make rdft speed user configureable.
[11:26:40] <CIA-92> ffmpeg: Change default speed back to a slower variant.
[12:26:58] <elenril> kshishkov: can you point me to the specs you were talking about?
[12:29:00] <kshishkov> elenril: you've not specified what format you're talking about either
[12:29:55] <CIA-92> ffmpeg: pross * r22468 /trunk/libavformat/bink.c: Prevent memory leak introduced in r22389 in Bink demuxer: pass partial packets to decoder.
[12:30:39] <elenril> i have problems with asf
[12:31:31] <elenril> i think avienc uses ff_put_bmp_header() too
[13:12:41] <elenril> http://i.iinfo.cz/urs-att/vim-112383453667211.gif
[13:13:24] <kshishkov> but it's more likely to appear in Emacs first!
[13:13:33] * twnqx hates ipod
[13:43:58] <Honoome> kshishkov: actually, vim had already that…
[13:45:31] <kshishkov> and what happens when you run "M-x clippy" in Emacs?
[13:49:55] <Honoome> nothing, but I got M-x butterfly
[13:50:24] <kshishkov> you are not on Ubuntu then
[13:50:44] <Honoome> definitely not, who do you think I am? :P
[13:50:58] <kshishkov> Diego Petten`o
[13:51:14] <kshishkov> (aka not that Diego)
[13:51:56] <Honoome> technically I'm Diego Elio now :P so that should stop the aliasing ;)
[13:52:28] <kshishkov> not unless you change first name
[13:54:00] <Honoome> kshishkov: I did
[13:54:07] <Honoome> legally, my first name is “Diego Elio”
[13:54:22] <kshishkov> that sounds like two names to me
[13:54:47] <Honoome> there's no concept of second name in Italy anymore
[13:55:17] <kshishkov> there's never been one here at all
[13:57:09] <kshishkov> (no nobility with a train of first and last names either)
[13:57:34] <Honoome> yeah that's different here
[13:57:37] <Honoome> isn't it not, lu_zero? :P
[13:58:01] <kshishkov> there's also Spain
[13:59:42] <kshishkov> Honoome: if lu_zero==Luca B then I think I know his four first names
[14:02:20] <Honoome> yeah it's him
[14:02:46] <twnqx> any idea how to export metadata to a text file so i can edit it, and re-import it to a file?
[14:03:05] <kshishkov> ffprobe infile > metadata.txt ?
[14:03:29] <kshishkov> converting it into command line for FFmpeg is trivial too
[14:04:38] <twnqx> 2> since ffprobe writes to stderr >_>
[14:04:47] <kshishkov> whatever
[14:04:53] <twnqx> but minor variations, indeed
[14:05:18] * kshishkov lives by mathematician's principle "if solution exists, go to sleep again"
[14:05:55] <twnqx> uh, is that major_brand, minor_version, compatible_brands metadata of the file?
[14:06:23] <twnqx> and: is there a list of usable metadata fileds somewhere?
[14:06:51] <twnqx> itunes has "is a part of a collection" and "album artist", which i'm looking for
[14:08:13] <twnqx> hm no, ffprobe doesn't show them on the file
[14:08:25] <kshishkov> ffmpeg -i infile
[14:08:58] <twnqx> no difference
[14:09:27] <kshishkov> then it's ignored in demuxer I think
[14:09:39] <twnqx> mh
[14:10:21] <twnqx> .mp4 is handled by the mov demuxer iirc?
[14:10:38] <kshishkov> yeth
[14:11:02] <av500> twnqx: major_brand, minor_version, compatible_brands metadata is some mp4/mov specific metadata
[14:11:08] <twnqx> ok
[14:14:11] <twnqx> the MOV_EXPORT_ALL_METADATA define is not reachable by a ./configure flag?
[14:14:21] <kshishkov> no
[14:15:13] * twnqx sees new metadata
[14:15:23] <elenril> ask bcoudrier about that
[14:15:42] * elenril would like to know why it exists too
[14:17:20] <twnqx> elenril: how would i go about making the remaining metadata usefull? i see 0xa9,grp aART cpil covr
[14:17:36] <twnqx> i suppose sovr will be... difficult
[14:17:55] * elenril has no idea how mov works
[14:18:01] <twnqx> it's mp4 :S
[14:18:09] <elenril> same thing (almost)
[14:18:12] <twnqx> well
[14:18:14] <twnqx> question is more
[14:18:21] <elenril> i tried to make sense of it a few times, but failed horribly
[14:18:22] <twnqx> how do i add metadata types
[14:18:35] <twnqx> the keys, e.g.
[14:18:40] <twnqx> is there a list of them?
[14:18:40] <elenril> add where?
[14:18:47] <elenril> yes, in libavformat/avformat.h
[14:19:37] <twnqx> so album_artist is defined. good.
[14:23:23] <twnqx> i think i asked that before. ffmpeg can't place cover art in files, right?
[14:23:40] <kshishkov> not yet
[14:23:47] <kshishkov> but it will - by streamcopy
[14:24:04] <kierank> god i hate windbg
[14:24:40] <kshishkov> try DEBUG.EXE then ;)
[14:24:49] <peloverde> What would be really sweet is to pull out the art, recode it and stick it back in
[14:25:03] <twnqx> recode?
[14:25:29] <elenril> i recall somebody saying he has a patch for extracting cover art as a stream
[14:25:34] <kshishkov> peloverde: most of modern media has nothing to do with art
[14:25:37] <elenril> Baptiste maybe
[14:25:38] <peloverde> either reencode the png smaller (like pngout) or the jpeg like the lossless recopress in jpeg-progs
[14:25:42] <elenril> kshishkov: s/modern//
[14:26:27] <peloverde> Oh music isn't art but the album cover is one of the last bastions of art ;)
[14:27:20] <kshishkov> elenril: yes, I've not heard good Czech composers either
[14:28:10] * elenril mostly listens to videogame soundtracks =p
[14:29:08] * kshishkov pulls out his colection of MIDI files ripped and converted out from Sierra games
[14:29:46] <pJok> does ffmpeg actually support midi files? ;)
[14:29:56] <kshishkov> not yet :(
[14:30:10] <kshishkov> someone should add at least OPL2/3 synth
[14:30:21] <twnqx> and .sid
[14:30:32] <andoma> +1 for SID
[14:30:43] <andoma> rockbox has a real tiny sidplayer in it
[14:30:53] <kshishkov> andoma: adplug.sf.net ;)
[14:30:58] <wbs> BBB: sorry for leaving in the middle of the flamewar yesterday - applied the luca-approved code with a big fat explanation
[14:31:07] <BBB> haha, ok :)
[14:31:13] <BBB> I didn't know that qualified as flamewar
[14:31:29] <wbs> well, not really, but "active discussion" at least :-)
[14:32:19] <wbs> the general problem is that in the rtsp muxer, we first announce an sdp, then after announcing we setup the individual streams - so either we create half-initialized rtp sessions and create the sdp from that, or then just create the sdp from the rtsp context instead
[14:32:40] <BBB> yeah, I noticed, I guess this is OK
[14:32:50] <wbs> yeah
[14:32:53] <BBB> I'm not terribly happy with copying random data all over the place, but it works
[14:33:09] <wbs> exactly; at least the big fat notice explains the two options and their implications
[14:35:24] <wbs> as far as I see it, I'd regard the rtsp muxer competent enough to create its own sdp - it still relies on too much details that aren't explicitly mentioned in the avf_sdp_create interface, so the more detailed interface would be good in that sense, but if luca doesn't want that, this solution at least solves my problem for now
[14:37:33] <BBB> Luca is right in a way, and don't forget he will always look at it from the PoV of the RTP muxing itself, without the RTSP
[14:37:53] <wbs> yeah, from that perspective it's understandable
[14:38:19] <wbs> but from the other perspective - there's nothing stopping me from crafting my own sdp and sending that in the announce, instead of the one provided by avf_sdp_create either
[14:38:37] <wbs> if I'm unable to make avf_sdp_create output the thing I need
[14:38:53] <BBB> of course
[14:38:55] <wbs> except for code duplication, that is
[14:38:58] <BBB> but we wouldn't want that in SVN ;)
[14:38:59] <BBB> right
[14:39:03] <wbs> exactly
[14:39:08] <BBB> the copy is OK, we'll leave it as-is for now
[14:39:14] <wbs> yeah
[14:39:16] <BBB> maybe later we can convince him of a more dynamic interface for internal use
[14:39:34] <wbs> yeah, someone runs into some other scenario requiring more customization
[14:39:45] <wbs> add an if to that sentence to make it make sense ;P
[14:41:49] <BBB> if any audio guru is online, how do you call this filter (top=before, bottom=after): http://people.gnome.org/~rbultje/filteraudio.png
[14:42:23] <kshishkov> lowpass
[14:43:55] <kshishkov> and inverting
[14:44:03] <BBB> maybe that's my bug :)
[14:44:14] <BBB> it doesn't invert
[14:44:16] <BBB> just sometimes
[14:44:26] <BBB> so this is lowpass?
[14:44:30] * BBB wishes he had a control
[14:44:32] <av500> kshishkov: lowpass, why?
[14:44:33] <KotH> looks like a differentiation to me
[14:44:56] <kshishkov> av500: less jiggly than before = lowpass :)
[14:45:12] <av500> I would not say that is is less jiggly
[14:45:35] <kshishkov> KotH: differentiation would make it even worse
[14:46:50] <KotH> BBB: a differentiation could be also approximated by a high pass
[14:47:02] <KotH> kshishkov: worse? depends on how you define good ;)
[14:47:25] <kshishkov> KotH: a straight line
[14:48:08] <peloverde> Its good to know that audacity is hideous on mac too and it's not just a linux thing
[14:48:49] <KotH> BBB: i think, easierst is if you can get teh samples out and compare their frequency spectrum
[14:49:36] <kshishkov> peloverde: at least it's less edgier on mac ;)
[14:49:47] <kshishkov> even in Audacity itself
[14:59:09] <BBB> the spetrum (in audacity) is almost the same
[14:59:18] <BBB> I don't see a difference
[14:59:35] <av500> the signals themselves do not look much different
[14:59:40] <av500> xcept for the invert
[14:59:41] <BBB> right
[14:59:46] <BBB> so what is it?
[14:59:50] <BBB> it's not lowpass
[14:59:53] <kshishkov> placebo filter
[14:59:59] <av500> fffilter?
[15:00:01] <BBB> is it a peak sharpener? :)
[15:00:06] <kshishkov> any real filter should affect spectrum
[15:00:07] <BBB> devnullfilter
[15:00:17] <BBB> kshishkov: did yuou load it in audacity?
[15:00:22] <BBB> I can show you before/after spectrum
[15:00:24] <BBB> they're the same
[15:00:35] <peloverde> Where is the filter code?
[15:01:27] <kshishkov> BBB: maybe try it with different window/length?
[15:01:52] <peloverde> Is it the final filter created by the WMA post?
[15:02:45] <BBB> http://people.gnome.org/~rbultje/spectrum.png
[15:02:53] <BBB> peloverde: yes
[15:03:06] <BBB> its effect is minimal
[15:03:11] <BBB> I can see a minor change in the spectrum
[15:03:14] <BBB> but not much
[15:03:46] <BBB> top=before, bottom=after
[15:04:35] <peloverde> take the fft coeffiecients of the filter (that's what you have right?) and export them
[15:05:02] <BBB> the last filter does not do FFT
[15:05:18] <peloverde> what does it do then?
[15:05:26] <BBB> it's a simple direct form 2 filter
[15:05:39] <peloverde> then give us the coefs
[15:06:00] <peloverde> it should be easy to see what ti does based on those
[15:07:04] <BBB> out[n] = in[n] * 0.93980580475 - in[n-1] * 1.8795833569 + in[n-2] * 0.93980580475 + out[n-1] * 1.9330735188 - out[n-2] * 0.93589198496
[15:07:20] <BBB> 1.8795... = 2*0.9398....
[15:07:31] <BBB> the out[n-1/2] coeffs make little sense to me
[15:07:53] <kshishkov> looks like a lowpass IIR filter which just cannot shave hi frequencies because there aren't any
[15:08:04] <BBB> hmm....
[15:08:10] <BBB> so I need a signal with more high freqs?
[15:08:17] <BBB> maybe that earlier weird filter is also lowpass
[15:08:22] * BBB disables
[15:18:30] <BBB> http://people.gnome.org/~rbultje/spectrum2.png
[15:18:40] <BBB> either I do something wrong, or it's a anti-lowpass filter
[15:20:03] <BBB> wbs: are you sure your buffers are padded with FF_INPUT_BUFFER_PADDING_SIZE?
[15:20:34] <wbs> BBB: that doesn't matter for that case
[15:20:45] <BBB> oh ok
[15:21:06] <wbs> if the last byte and the next one happen to be 0, we consume both and end up with size = -1
[15:21:20] <wbs> and then do a memcpy(, , -1) and get a spectacular crash
[15:22:12] <BBB> right
[15:22:17] <BBB> I guess patch = ok then
[15:22:57] <wbs> ok, I'll wait a moment to see if luca or michael has anything to say about it. they reviewed it initially a year ago
[15:24:10] <peloverde> kshishkov: did i do something wrong, this doesn't look lowpass to me: http://i.imgur.com/qSVVa.png
[15:25:47] <av500> If I had to globally adjust all pts/dts, where would I keep the adjust value? in AVFormatContext?
[15:27:51] <BBB> http://people.gnome.org/~rbultje/spectrum3.png
[15:28:01] <BBB> another one with more intense high-frequency sounds
[15:28:07] <BBB> again, no effect
[15:31:19] * BBB hates the bad focus management on mac with spaces enabled
[15:31:49] <KotH> BBB: have you checked the phase?
[15:32:02] <KotH> BBB: could be that it's mostly a phase changing filter
[15:32:54] * BBB looks at what phase is
[15:33:23] <KotH> you know star trek?
[15:33:32] <KotH> they have these nice and shiny weapons called phaser
[15:33:41] <KotH> what comes out of them is a "phase" ;-)
[15:34:09] <BBB> uhm
[15:34:09] <BBB> ok
[15:34:13] <BBB> but how do I analyze phase?
[15:34:33] <av500> BBB: you study EE for a few years
[15:37:00] <BBB> ;(
[15:38:16] <BBB> http://people.gnome.org/~rbultje/spectrum4.png
[15:38:26] <BBB> here it looks like an actual lowpass (check the 16kHz on the left)
[15:38:43] <BBB> but that's a very minor effect, wouldn't you expect it to be stronger?
[15:38:55] <BBB> kshishkov: is that what I'm looking for?
[15:39:20] <peloverde> spectrum 4 looks like my filter
[15:39:40] <BBB> ?
[15:39:57] <peloverde> http://i.imgur.com/qSVVa.png
[15:40:29] <av500> peloverde: ah, finally matlab :)
[15:40:33] <peloverde> BBB do you have access to MATLAB?
[15:40:41] <BBB> no
[15:40:53] <peloverde> The uni doesn't have a site license?
[15:41:03] <BBB> I study biology, dude :)
[15:41:24] <peloverde> I know a lot of systems biology people that live in MATLAB :)
[15:41:29] <BBB> hmm...
[15:41:31] <BBB> I don't think we have it
[15:41:34] <BBB> could check though
[15:41:40] <BBB> but so can I conclude it's a lowpass then?
[15:41:48] <BBB> I just wanted to convince myself and know what it means
[15:42:27] <av500> no, it is a highpass
[15:42:29] <peloverde> spectrum4 certainly doesn't look lowpass to me
[15:42:38] <av500> it filters out very low frequncies
[15:42:38] <peloverde> It looks like it's a DC removal filter
[15:42:42] <av500> yep
[15:42:47] <peloverde> highpass with a very low cutoff
[15:43:16] <BBB> no, on the left is 16kHz
[15:43:25] <BBB> according to the x-axis
[15:43:27] <av500> 16hz
[15:43:37] <BBB> oh!
[15:43:39] <BBB> hmm...
[15:43:41] <BBB> oi
[15:43:43] <BBB> oops
[15:43:48] <av500> you learn to read in biology?
[15:43:55] <BBB> no wonder I didn't see it elsewhere, the big graphs started at 500Hz or so
[15:43:58] <BBB> so it's a highpass?
[15:44:09] <av500> yes, a DC remover as peloverde said
[15:48:04] <janneg> av500: how is the Big Buck Bunny render machine doing? first 3 scenes are mostly done http://www.jannau.net/bbb_videowall/
[15:48:28] <av500> janneg: the BBB render machine turned out to by a crapacer with only 3 mem slots
[15:48:35] <av500> so its 4GB for this pos
[15:48:50] <av500> coz 2x4GB ram is ummm expensive
[15:49:07] <av500> err, only 2 mem slots
[15:49:09] <kshishkov> av500: buy 1x16GB ram then ;)
[15:49:17] <av500> kshishkov: sell it to me
[15:49:46] <kshishkov> av500: it'll get lost during sending
[15:50:06] <av500> so will my payment, thanks for doing business with you :)
[15:51:17] <janneg> av500: could be still useful. there are frames which render fine with less than 4G
[15:51:49] <kshishkov> av500: if you send it via post then yes, if via bank then they'll refuse transerring it. It's always a pleasure to do business with Ukraine!
[15:55:02] * kshishkov wonders why some av5.. guy cannot write a patch for Blender making it consume less RAM
[15:55:43] <peloverde> just be glad you aren't stuck in this position: http://blogs.msdn.com/expressionencoder/archive/2010/03/10/9976633.aspx
[15:57:14] <peloverde> BBB: if you don't have access to MATLAB, pylab and octave both have "ok" signal processing/analysis tools
[15:57:38] <peloverde> I've always found the spectrum tool in audacity to be lacking
[15:59:41] <BBB> av500: "DC remover", what is "DC" here?
[16:00:15] <kshishkov> BBB: roughly speaking, zeroth frequency
[16:00:21] <BBB> (I need to know abbreviations :) )
[16:00:24] <BBB> ah, ok
[16:00:29] <av500> direct current
[16:00:35] <kshishkov> constant component of the signal
[16:00:36] <av500> vs AC = alternating current
[16:00:49] <peloverde> "direct current" from when all this stuff was done with analog electronics
[16:00:55] <BBB> ok
[16:02:03] <kshishkov> BBB: look at me, I've never studied signal theory yet I somehow manage
[16:19:49] <KotH> BBB: dc remover == highpas with a very low filter frequency
[16:20:10] <mru> a capacitor
[16:20:44] <mru> everything is simpler in analogue
[16:21:02] <KotH> a capacitor is a phase shifter ;)$
[16:21:12] <mru> that too
[16:21:36] <KotH> and analog is a lot more difficult to get right than digital
[16:21:47] <KotH> but, i have to go now...
[16:21:51] * kshishkov remembers calculating LC-circuit properties with complex numbers
[16:21:56] <KotH> have fun decyphering strange signals
[16:22:13] <kshishkov> KotH: but we communicate with them
[16:22:18] <KotH> kshishkov: yeah.. i did that too.. in highschool... and got weird looks from all my classmates ;)
[16:22:22] <kshishkov> we == mere eartlings
[16:23:18] <kshishkov> I probably was the only one who was not freaked by complex numbers
[16:24:10] <KotH> .o0(that explains a lot about kshishkov)
[16:24:32] <mru> in uni our first exam in circuit theory was a bit of a fiasco
[16:24:39] <mru> 6 of 250 passed
[16:24:51] <mru> yes, I was one of them
[16:24:56] <kshishkov> we had intermediate test with similar results
[16:25:31] <kshishkov> and "6 of 250" was an outcome of the first test in math!
[16:27:04] <CIA-92> ffmpeg: mstorsjo * r22469 /trunk/libavformat/rtpenc_h263.c:
[16:27:04] <CIA-92> ffmpeg: Fix a crash in the H.263 RTP packetizer
[16:27:04] <CIA-92> ffmpeg: If size == 1 and buf[0] == 0 and buf[1] == 0 (the first byte after the
[16:27:04] <CIA-92> ffmpeg: buffer), it would set size = -1 and crash in the later memcpy.
[16:27:27] <kshishkov> it's pretty remarcable how our high schools manage to produce thousands of students knowing perfectly nothing
[16:27:48] <mru> sounds just like sweden
[16:28:04] <wbs> sounds mostly like finland, too ;P
[16:28:28] <mru> finland is a part of sweden, no?
[16:28:33] <kshishkov> s/Finland/Österland/
[16:28:59] <mru> just kidding
[16:29:07] <mru> everybody knows it's part of russia
[16:29:19] <mru> /o\
[16:29:22] <wbs> ;P
[16:29:26] <kshishkov> mru: guess what, I did not even get high marks for English at school
[16:29:49] <mru> I didn't attend english class in school
[16:30:55] <andoma> but you're half native
[16:31:26] <mru> many a brit would dispute that assertion
[16:31:41] <thresh> i got "A", but my english still sucks
[16:32:00] <mru> thresh: it's better than your french
[16:32:16] <mru> I thought _my_ french sucked...
[16:32:26] <kshishkov> mru: try mine ;)
[16:32:49] <thresh> mru: ha-ha, true
[16:32:53] <kshishkov> I'm not good at English but I don't know French at all
[16:33:03] <av500> ffrench!
[16:33:13] <thresh> well, actually mru teached me a bit of french
[16:33:21] <mru> that's a scary thought
[16:33:25] <kshishkov> av500: been there, moved to VVmpeg
[16:33:27] <thresh> like 'just drop last three or four letters and it'll be ok'
[16:33:27] <mru> because nobody ever taught me any
[16:33:44] <av500> of, so ffcon in paris it is!
[16:34:02] <kshishkov> thresh: and read a group of three vowels as one
[16:34:31] <mru> av500: and here I was thinking it would be nice to have it in Nice
[16:34:41] <thresh> kshishkov: so you do know french better than me!
[16:35:05] <kshishkov> thresh: haven't you studied "War and Peace" at school?
[16:35:10] <mru> any group of three or more vowels is pronouced like swedish å or ö
[16:35:28] <kshishkov> "river" or "island"?
[16:35:36] <kshishkov> SCNR
[16:35:49] <thresh> kshishkov: they didnt force us to read french phrases
[16:36:07] <kshishkov> thresh: well, what's left in that book then?
[16:36:21] <thresh> kshishkov: 'Austerlitz sky' is all i remember
[16:37:13] <kshishkov> thresh: then you remember much more than me. All I remember is that is was horiible long bunch of words next to impossible to read.
[16:37:34] <av500> mru: we can ask ti to sponsor it :)
[16:37:41] <av500> they have a nice place in nice
[16:38:16] <thresh> kshishkov: I enjoyed it. Probably because I read it on summer vacs being ~2k km away from my computer and that was the only source of entertainment there.
[16:39:14] <thresh> except for keeping the campfire and shooting the cans.
[16:39:15] <kshishkov> thresh: in such circumstances people even enjoyed Nietzsche
[16:40:27] <mru> nietzsche is good reading when near an abyss
[16:41:29] <kshishkov> does its bottom count as "near"?
[16:41:44] <mru> are there monsters there?
[16:41:57] * kshishkov looks around
[16:41:59] <kshishkov> not now
[16:43:27] <mru> I suspect his idea of a monster may have included trolls
[16:44:47] <kshishkov> told you once, I fit a definition of troll - "a creature supposed to live in Scandinavia but which doesn't"
[16:45:09] <kshishkov> also living under the bridge connecting Europe and Asia doesn't help either
[16:47:10] * pJok sends kshishkov off to stockholm
[16:47:43] <kshishkov> I don't think that prank will work second time
[16:47:58] <pJok> true
[16:49:57] <kshishkov> pJok: actually it was Ben who tried it in 2009
[17:08:44] <BBB> time now to understand that frequency domain filter I guess
[17:09:35] <kshishkov> that's just time-domain filter in different domain :P
[17:09:58] <mru> frequency-domain filtering is conceptually simple
[17:10:17] <mru> 1. take your time-domain signal
[17:10:24] <mru> 2. apply transform to frequency domain
[17:10:37] <mru> 3. modify components to your heart's desire
[17:10:42] <mru> 4. transform back to time domain
[17:11:03] <av500> 5. profit?
[17:11:23] <mru> for example, to implement a low-pass filter, you simply set all coefficients above the cutoff to zero
[17:12:37] <mru> in practice it won't be that perfect of course
[17:12:58] <kshishkov> depends on transform
[17:13:04] <mru> to get a perfect filter you'd need to do the transform on an infinitely long sequence
[17:13:11] <av500> overlap/add
[17:13:23] <mru> when you slice it up, you get a bit of leakage around the edges
[17:13:29] <kshishkov> windowing to hide artifacts, whatever
[17:23:31] * pJok hides kshishkov in the artifacts
[17:23:51] <kshishkov> pJok: I'm too big to be hidden
[17:25:13] <pJok> tells something about the artifacts then...
[17:25:35] <iive> kshishkov: you are too poor to be big. ;)
[17:26:14] <BBB> uhmm....
[17:26:24] <BBB> mru: I love you too, now can you translate all that to english for me?
[17:26:31] <BBB> I understand things like plus and minus
[17:26:42] <BBB> I don't even understand how FFT does what it does
[17:26:45] <kshishkov> iive: ask some people who've actually seen me like mru/merbzt/andoma/superdump
[17:26:58] <kshishkov> BBB: ask me
[17:27:04] <BBB> ask
[17:27:16] <iive> :O
[17:27:26] <mru> BBB: I recommend you get a book on signal theory and read it
[17:27:28] <kshishkov> FFT takes your ordinary signal and transforms it to sine waves
[17:27:52] <kshishkov> real part = sine wave amplitude, imaginary part - phase (i.e. shift)
[17:28:10] <kshishkov> it does it by magic ;)
[17:28:11] <astrange> i'm not getting any roundup emails except for when i add a new bug...
[17:28:16] <mru> the basic premise is that any signal can be represented as a sum of sines of various frequences and phases
[17:28:31] <kshishkov> astrange: not nosy enough then
[17:29:11] <mru> if the signal is symmetrical around t=0 you get all cosines
[17:29:16] <mru> i.e. same phase
[17:29:31] <mru> and nice, real-valued output
[17:30:02] <kshishkov> BBB: cycle FFplay output modes for audio file to understand that idea better ;)
[17:32:09] <BBB> so im = phase
[17:32:13] <BBB> re = ampl
[17:32:16] <BBB> hmm...
[17:32:18] <BBB> interesting
[17:32:19] <kshishkov> also isn't it said one has to understand Maxwell's equations before even touching electronics?
[17:32:37] <mru> BBB: polar can coordinates help here
[17:32:57] <kshishkov> and Euler's formula!
[17:33:27] <mru> and e^(pi*j) = -1
[17:33:30] <mru> never forget that
[17:33:57] <kshishkov> mru: I prefer e^(i*pi) + 1 = 0, it has _all_ important constants that way
[17:34:19] <mru> depends on which ones you consider important
[17:34:21] * kshishkov wonders why here people use "i" for imaginary one
[17:34:26] <mru> it doesn't have G or alpha
[17:34:31] <kshishkov> mru: one and zero of course
[17:34:51] <kshishkov> two transcendental numbers is a bonus too
[17:34:57] <mru> yep
[17:35:13] <mru> but zero is always implicitly present
[17:35:27] <mru> without zero, everything else is meaningless
[17:39:50] * kshishkov also remembers how to integrate and differentiate f(x)=e^x 
[17:40:15] <mru> impressive!
[17:43:48] <CIA-92> ffmpeg: rbultje * r22470 /trunk/libavcodec/ (acelp_vectors.c amrnbdec.c sipr.c acelp_vectors.h): Fix spelling.
[18:56:09] <Dark_Shikari> mru: just ask the lambda calculus
[18:56:30] <kshishkov> what's so special about that either?
[18:57:21] <Dark_Shikari> all numbers are defined as successors of zero ;)
[18:57:47] <kshishkov> natural ones only
[18:59:57] * elenril never understood what lambda calculus is
[19:00:15] <kshishkov> elenril: look at APL
[19:00:18] <kshishkov> or Lisp
[19:00:34] <kshishkov> or Perl without explicit variable names
[19:00:48] <elenril> :effort:
[19:01:31] <Dark_Shikari> elenril: go to school
[19:01:47] * elenril doesn't have time for that
[19:01:54] <Dark_Shikari> sure you do
[19:01:58] <Dark_Shikari> you haven't submitted patches to x264
[19:01:59] <elenril> i have to procrastinate
[19:02:00] <Dark_Shikari> which means you surely have time
[19:02:17] <elenril> (and write my bc paper)
[19:02:56] <kshishkov> on what?
[19:03:13] <elenril> black holes
[19:03:42] <mru> don't go too close
[19:03:50] <mru> stay this side of the horizon
[19:03:52] <elenril> visualisation of what infalling observer sees
[19:04:16] <kshishkov> hasn't that Schwarzschieldt guy written all about them?
[19:04:16] <mru> he'll be ripped to pieces before he has a chance
[19:04:17] <elenril> meh, it's no fun here
[19:04:22] <Dark_Shikari> mru: not with a big enough one
[19:04:41] <elenril> you could cross the horizon without even knowing it
[19:04:52] <Dark_Shikari> elenril: you may have been born inside the horizon
[19:04:56] <elenril> actually you always see the horizon ahead of you
[19:04:57] <Dark_Shikari> if the universe is closed, it is a black hole
[19:05:31] <kshishkov> or fridmon
[19:05:52] <mru> Dark_Shikari: in that case, prepare for the big crunch
[19:06:16] <Dark_Shikari> mmmm.  crunch.
[19:08:34] <kshishkov> elenril, wasn't the process of falling supposed to take infinite time anyway?
[19:09:21] <mru> kshishkov: in the reference frame of the faller, yes iirc
[19:09:26] <mru> bloody relativity
[19:09:47] <elenril> mru: no, the other way around
[19:09:59] <kshishkov> mru: and outside it's unobservable because of event horizon. Fun!
[19:10:01] <elenril> it's infinite time for the rest of the universe
[19:10:03] <Dark_Shikari> it takes infinite _external_ time in the reference frame of the faller
[19:10:14] <Dark_Shikari> thus, when you cross the event horizon, infinite time will have passed for an _observer_
[19:10:19] <Dark_Shikari> because time dilation is infinite at the event horizon
[19:10:23] <Dark_Shikari> which of course means you will never hit the singularity
[19:10:29] <elenril> actually one of the basic postulates in GR is that timespace is locally flat
[19:10:53] <mru> ~summon Xeno
[19:11:04] <Dark_Shikari> s/o/u
[19:11:21] <kshishkov> elenril: I think you should go to #x264-dev and embarass DS there by proposing better SIMD than he wrote for x264
[19:11:38] <kshishkov> Dark_Shikari: it's avoiding trademark
[19:11:52] <Dark_Shikari> kshishkov: patches welcome
[19:13:41] * elenril would have to learn asm first
[19:13:49] <Dark_Shikari> that takes a few hours
[19:14:22] <elenril> and it's not applicable to metadata anyway =p
[19:16:03] <kierank> write some metadata SEIs
[19:16:40] * iive suspects somebody is confusing event horizon with light speed travel
[19:18:04] * elenril suspects it's iive 
[19:18:51] * elenril reads what Dark_Shikari wrote again
[19:18:53] <elenril> wait, what?
[19:19:05] <elenril> no, you will hit singularity in a finite time
[19:19:20] <Dark_Shikari> elenril: in your reference frame
[19:19:25] <elenril> yes
[19:19:27] <Dark_Shikari> in an observer's frame, infinite time
[19:19:40] <Dark_Shikari> in the SINGULARITY'S FRAME, infinite time
[19:19:49] <Dark_Shikari> thus, the singularity won't exist when you hit it.
[19:20:11] <Dark_Shikari> hawking radiation etc
[19:21:22] <_av500_>  infinite time in pts or dts?
[19:21:30] <Dark_Shikari> hahahaha.
[19:24:19] <iive> Dark_Shikari: the time delay is caused by the gravitation. so the event horizon is not factor in it. also, light always travel at constant speed, so you will see the object until it "hides".
[19:25:00] <iive> now, i wonder if there is something interesting if you travel toward black hole with the speed of light....
[19:25:10] <Dark_Shikari> iive: gravitational time dilation
[19:25:19] <Dark_Shikari> separate issue
[19:26:20] <elenril> Dark_Shikari: singularity's frame?
[19:26:51] <Dark_Shikari> er, better said, the frame in which the age of the black hole is measured
[19:27:13] <elenril> that would be external observer's frame
[19:27:16] <Dark_Shikari> yeah, I guess
[19:27:19] <Dark_Shikari> or actually the horizon's frame
[19:27:24] <Dark_Shikari> because hawking radiation is produced there
[19:27:50] <elenril> you can't have a static frame on the horizon
[19:29:03] <elenril> i.e if you're on the horizon, you _have_ to be moving, either in or out
[19:38:02] <elenril> anyway, you have a point with hawking radiation, but it isn't very well understood so i wouldn't be so sure
[20:13:41] <elenril> does anybody know why does ff_put_bmp_header() pad it to even size?
[20:14:07] <elenril> but doesn't account for it when writing length
[20:14:37] <elenril> it breaks wmv3 playback in wmp
[20:14:55] <mru> elenril: it's the spec
[20:15:04] <elenril> link?
[20:15:11] <mru> microsoft.com ?
[20:15:27] <elenril> http://msdn.microsoft.com/en-us/library/aa930622.aspx << this?
[20:17:09] <mru> that defines the structure itself
[20:17:19] <Vitor1001> elenril: Just a curiosity, you said you were a physicist... Undergrad?
[20:17:40] <elenril> yes
[20:17:56] <Vitor1001> Fun :)
[20:18:13] <Vitor1001> Was there ~ 6 years ago...
[20:20:00] <Vitor1001> elenril: In the US?
[20:20:51] <elenril> no, cz
[20:23:55] <mru> elenril: you may have found a bug
[20:24:01] <mru> the padding is part of the RIFF spec
[20:24:10] <mru> I don't see any mention of it in asf spec
[20:25:49] <elenril> https://roundup.ffmpeg.org/issue1512
[21:03:13] <BBB> Koth: what's your email addy?
[21:04:36] <janneg> BBB: attila at kinali dot ch
[21:05:50] <KotH> BBB: just use firstname @ lastname dot country :)
[21:05:53] <KotH> BBB: or google for my name
[21:06:00] <KotH> BBB: or do as janneg said ;)
[21:06:03] <BBB> :) thanks
[21:08:43] <KotH> janneg: is it me or are there a lot of render errors in bbb?
[21:09:07] <KotH> BBB: btw: i'm on -legal :)
[21:09:17] <KotH> BBB: just not reading it very often ;)
[21:11:49] <BBB> oh
[21:11:52] <BBB> oops
[21:11:55] <BBB> ok
[21:11:58] <BBB> so opinion?
[21:12:06] <BBB> I just CC anyone whose attention I need
[21:12:41] <janneg> KotH: I blame blender foundation for publishing buggy sources
[21:14:09] * KotH blames blender foundation
[21:14:27] <KotH> BBB: cc'ing me is not a bad idea if i need to see something
[21:14:38] <KotH> BBB: either cc me or tell me on irc that i should have a look
[21:14:42] <BBB> ok, so now on to the content ;)
[21:16:46] * BBB patiently waits for koth to say CMS on mphq is OK
[21:19:45] * KotH is writing an email on that
[21:30:54] <KotH> BBB: biff
[21:33:18] <BBB> replied already
[21:33:25] <BBB> thanks :)
[21:49:56] <BBB> fun, a new flamewar
[21:50:59] <KotH> flamewar? i'm just stating my opinions :)
[21:53:54] <BBB> :)
[21:53:56] <BBB> it's a joke
[21:55:39] <BBB> anywya, joomla ok?
[21:57:24] <KotH> havent had a look at it :)
[21:57:45] <KotH> if it fullfills the three points, it's ok :)
[21:58:27] <BBB> I'd say popular means = ok
[21:58:32] <BBB> if drupal is ok also...
[21:59:36] <KotH> whatever floats your boat :)
[21:59:50] <KotH> it's you who will have to maintain the website
[21:59:58] <KotH> you have to be able to live with the cms
[22:00:04] <KotH> i only care about the admin side :)
[22:00:25] <KotH> anyways.. i'm off to bed
[22:00:27] <KotH> good night boys
[22:00:56] <janneg> good night KotH
[22:09:25] <BBB> lu_zero: so do I get the impression you want to help on the website? ;-)
[22:58:38] <MrNaz> BBB you here?
[22:58:46] <BBB> yes
[22:58:50] <BBB> what did I break this time?
[22:59:27] <MrNaz> nothing heh... there's still a problem with ffserver and im looking for someone to give a bounty to to fix it
[22:59:41] <BBB> so I did break something
[22:59:53] <BBB> but if you tell me what's broken, I can fix it
[23:00:12] <MrNaz> also, i still owe ffmpeg for the last thing you fixed... ben told me he'd get back to me with ffmpeg's bank details so i can send some money
[23:00:31] <BBB> oh, that'd be great
[23:00:44] <BBB> I can send you the foundation bank details, what's your email?
[23:01:02] <MrNaz> its audio... it broke quite a while ago, i can't pinpoint the build as it broke during the period ffserver was totally broken... video is working fine now though
[23:01:50] <MrNaz> the problem is that when streaming, audio output is totally broken, it just outputs a screaming sound instead of audio
[23:01:55] <BBB> ow. hmm...
[23:02:06] <BBB> so it worked before I broke the http streaming?
[23:02:07] <MrNaz> i'll get to the centre in a couple of hours and i can give you a demo
[23:02:19] <MrNaz> no it broke around jan i think
[23:02:25] <BBB> ok
[23:02:31] <BBB> I can look into that
[23:02:39] <BBB> can I reproduce in the same way as previously?
[23:02:56] <BBB> also, have you tested that it's not specific to a particular codec?
[23:03:09] <MrNaz> i've tried aac and mp3
[23:03:41] <MrNaz> however i have only tested with flv, not anything else
[23:04:15] <BBB> that's fine
[23:04:45] <BBB> I'll make a note and see if I can reproduce this tonight
[23:04:52] <BBB> I'll probably go home in a bit
[23:24:29] <kierank> hmmm where'd merzbt go...