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

[irc at mansr.com]

[00:59:35] <Yuvi> Dark_Shikari: fixed
[01:00:21] <Yuvi> there's still potential overreads before that, but I want to think a bit more about how best to fix them
[01:00:24] <CIA-92> ffmpeg: conrad * r22416 /trunk/libavcodec/vp3.c:
[01:00:24] <CIA-92> ffmpeg: vp3: avoid buffer overread in coeff decode
[01:00:24] <CIA-92> ffmpeg: I couldn't measure it to be slower for normal interframe videos.
[01:00:24] <CIA-92> ffmpeg: For the worst case, high-bitrate intra-only videos, it can be 0.7% slower.
[01:34:23] <Dark_Shikari> Yuvi: awwsome
[01:34:25] <Dark_Shikari> *awesome
[01:36:00] <Dark_Shikari> Yuvi: 2464
[01:44:27] <Dark_Shikari> doubling down on the fuzzer.  Two fuzzers running now.
[01:55:37] <mru> I ran the fuzzer on a png file and got this: http://imagebin.ca/view/poQWNB.html
[01:57:25] <Yuvi> Dark_Shikari: is that supposed to be oom or segfault?
[01:58:32] <Compn> mru : what am i suppoed to see in your fuzz.png ?
[01:58:39] * Compn guesses its fuzzy
[01:58:49] <mru> bad joke
[01:58:57] <Compn> you didnt make it fuzzy enough
[02:00:54] <mru> imagemagick refuses to make it fuzzier
[02:05:45] <astrange> try running multiple times
[02:51:50] <Dark_Shikari> Yuvi: segfault
[02:52:18] <Dark_Shikari> it may have been the same bug
[02:54:18] <Dark_Shikari> Yuvi: ok, I have new crashes for you, with updated ffmpeg
[02:54:25] <Dark_Shikari> 100055, 100176
[02:54:34] <Dark_Shikari> (second fuzzer is starting at 100k)
[02:57:43] <CIA-92> ffmpeg: mru * r22417 /trunk/Makefile:
[02:57:43] <CIA-92> ffmpeg: Change dir into doc/ when running texi2html
[02:57:43] <CIA-92> ffmpeg: This silly program always writes its output to the current directory.
[02:57:43] <CIA-92> ffmpeg: Changing directory is better than moving the file afterwards.
[02:57:44] <CIA-92> ffmpeg: mru * r22418 /trunk/ (Makefile common.mak): Prettify make output for documentation
[02:57:45] <CIA-92> ffmpeg: mru * r22419 /trunk/ (common.mak libavcodec/Makefile): Replace $(G) with more generic $(M) in silent make rules
[02:57:45] <CIA-92> ffmpeg: mru * r22420 /trunk/ (Makefile common.mak): (log message trimmed)
[02:57:46] <CIA-92> ffmpeg: Improve version.h generation
[02:57:46] <CIA-92> ffmpeg: Force version.sh to run whenever the version might have changed,
[02:57:47] <CIA-92> ffmpeg: regardless of what is being built. This is done by attaching the
[02:57:47] <CIA-92> ffmpeg: dependencies to a dummy file (.version) which is included from the
[02:57:48] <CIA-92> ffmpeg: makefile. As make will always attempt to rebuild any included files
[02:57:48] <CIA-92> ffmpeg: before considering other rules, this ensures that the real version.h
[02:57:49] <CIA-92> ffmpeg: mru * r22421 /trunk/Makefile: Make version.h depend on git changes
[02:57:49] <CIA-92> ffmpeg: mru * r22422 /trunk/common.mak:
[02:58:33] <CIA-92> ffmpeg: Remove .SECONDARY directive
[02:58:33] <CIA-92> ffmpeg: The presence of the .SECONDARY directive caused thing to not always
[02:58:33] <CIA-92> ffmpeg: be correctly rebuilt. Mentioning the object files explicitly as
[02:58:33] <CIA-92> ffmpeg: targets gives the desired result of make not deleting them without
[02:58:33] <CIA-92> ffmpeg: unpleasant side-effects.
[03:11:19] <CIA-92> ffmpeg: mru * r22423 /trunk/Makefile:
[03:11:19] <CIA-92> ffmpeg: 10l: fix version.h generation
[03:11:19] <CIA-92> ffmpeg: Note to self: always test in a clean directory
[03:15:20] <astrange> makemkv os x is shipping part of the mlp decoder but doesn't mention it anywhere :(
[03:38:16] <Dark_Shikari> Yuvi: another crash, 4189
[03:38:20] <Dark_Shikari> so 3 pending crashes.
[03:42:34] <astrange> rtp decoders break gcc lto somehow
[03:43:15] <Dark_Shikari> I think  it's safer to say that gcc lto breaks the rtp decoders
[03:44:07] <astrange> http://pastebin.com/THNkbinP funny warning
[04:00:27] <Dark_Shikari> anyone else want to run the fuzzer?  I have one server running it fulltime
[04:00:43] <Dark_Shikari> we can "allocate" sections of the seedspace, distributed computing style ;)
[04:06:13] <saintdev> would the command happen to be "./folding at home.exe -smp -local"?
[04:06:14] <saintdev> :p
[04:06:19] <Dark_Shikari> lol
[04:06:58] <saintdev> oh wait, i already have that running
[04:07:11] <astrange> i can run it fulltime on an old ppc but it would be rather slow
[04:07:18] <astrange> maybe fuzzing h263 or something
[04:08:03] <Dark_Shikari> yeah, probably useless
[04:08:05] <astrange> btw truncating mkv files seems to reliably crash libebml, has anyone tried that on lavf stuff?
[04:08:07] <Dark_Shikari> no point except on a real system
[04:08:16] <Dark_Shikari> astrange: we found an overread bug and fixed it
[04:10:44] <Dark_Shikari> probably more of those lying around
[04:10:51] <saintdev> in libebml?
[04:12:00] <saintdev> astrange: i could see how that could easily happen. what does avcodec do?
[04:12:28] <astrange> tries to be careful
[04:12:56] <astrange> i don't think you can do anything specific except remember to return errors and don't use mmap without checking lengths
[04:13:02] <saintdev> does it just spit out an error, and fail gracefully?
[04:13:02] <Dark_Shikari> er, in lavf
[04:48:26] <astrange> LTO ran the disk my vm is on out of free space
[05:02:37] <saintdev> LMAO at java MPEG4!
[05:03:42] <peloverde> It's been done before
[05:04:18] <saintdev> oh i know it's possible, but it would be terribly slow
[05:04:34] <peloverde> That assumes you are compiling it to the JVM
[05:05:04] <peloverde> When I did java codecs the JVM was only used for testing purposes
[05:25:59] <CIA-92> ffmpeg: ramiro * r22424 /trunk/libavdevice/vfwcap.c: vfwcap: Add support for UYVY pixel format.
[07:05:46] <elenril> nice somebody fixed audio in sh2 bink files
[07:06:24] <elenril> any plans on seeking?
[07:06:48] <kshishkov> no
[07:07:13] <elenril> :\
[07:07:13] <kshishkov> there's no seasy way to determine audio pts nor video keyframes in the middle
[07:09:15] <elenril> official player can't seek either iirc
[07:09:36] <kshishkov> the whole format was not designed for seeking at all
[07:09:49] <av500> kshishkov: that wont stop you, will it? :)
[07:10:09] <kshishkov> av500: no, it stopped Peter though
[07:12:49] * elenril tries to remux to nut
[07:13:32] <twnqx> what is a keyframe, actually? an i/I-frame in h264 terminology?
[07:13:34] <elenril> meh, doesn't work
[07:13:55] <twnqx> i doubt you can put bink into anything but bink :P
[07:14:48] <elenril> well i muxed flac into avi with ffmpeg
[07:14:51] <elenril> and it worked
[07:14:59] <elenril> ffmpeg is magic
[07:15:12] <twnqx> heh
[07:15:30] <twnqx> i'd guess there's a proper 4cc
[07:17:24] <kshishkov> twnqx: keyframe = I-frame in alll video codecs terms
[07:17:53] <kshishkov> and theoretically you can easily remux Bink into anything except ogg
[07:18:22] <twnqx> i guess you'd just have to define a marker to identify it (4cc or whatever)
[07:18:40] <elenril> well i can remux it
[07:18:46] <twnqx> but is it up to ffmpeg to set these standards?
[07:18:50] <elenril> but mplayer doesn't play it
[07:18:55] <elenril> with  [nut @ 0xb63fe2c0]Unknown codec?!
[07:19:06] <twnqx> so define the codec in your mplayer.conf?
[07:20:29] <superdump> there are IDR frames in h.264
[07:20:59] <kshishkov> and SI-frames, so what?
[07:43:09] <av500> elenril: to mux chapters into asf, where do I get muxable chapters from?
[07:43:29] <av500> is 1:1 copy of chapters metadata already commited?
[07:44:45] <CIA-92> ffmpeg: mstorsjo * r22425 /trunk/libavformat/rtpproto.c: Using struct timeval requires sys/time.h, fixes compilation on some OSes
[07:45:49] <CIA-92> ffmpeg: mstorsjo * r22426 /trunk/libavformat/rtsp.c:
[07:45:49] <CIA-92> ffmpeg: Include os_support.h which has a fallback declaration of socklen_t
[07:45:49] <CIA-92> ffmpeg: This fixes compilation on some OSes
[07:48:58] <elenril> av500: no
[07:49:15] <av500> so how would I get ffmpeg to mux chapters?
[07:49:27] <elenril> apply the patch ;)
[07:49:31] <av500> :)
[07:50:04] <av500> but without the patch, how do chapters get in? only by using lavf and setting them up by hand?
[07:50:10] <elenril> i don't have enough time/motivation to do it the correct way now
[07:50:18] <elenril> yes
[07:50:20] <av500> ok
[07:51:19] * elenril goes to school
[07:51:39] <av500> have fun
[07:53:42] <wbs> when doing svn propset svn:log, is there any way of getting the previous log message into an editor and just edit that, instead of having to copy/paste the old message from the log?
[07:54:00] <kshishkov> yes
[07:54:16] <kshishkov> IIRC with --revprop it does so by default
[07:54:31] <siretart`> doesn't propedit work as well?
[07:54:58] <wbs> aah, yes, I used propset, propedit probably does that
[08:39:16] <KotH> grüezi
[08:39:41] <kshishkov> shalom
[09:20:05] <CIA-92> ffmpeg: bcoudurier * r22427 /trunk/libavformat/mpegtsenc.c: reindent
[09:21:22] <CIA-92> ffmpeg: bcoudurier * r22428 /trunk/libavformat/mpegtsenc.c: In mpegts muxer, free adts context and temporary data
[09:40:26] <twnqx> :(
[09:40:37] <twnqx> seems like ffmpeg flac->m4a conversion killed all metadata
[09:40:57] <twnqx> alac/m4a
[09:41:14] <twnqx> at least ffprobe doesn't show any artist etc. for the file
[09:43:30] <astrange> file a bug if there isn't one
[09:43:39] <astrange> i can't tell if there is, roundup is very slow atm
[09:45:00] <elenril> twnqx: did you -map_meta_data?
[09:45:22] <twnqx> no
[09:45:30] <twnqx> metadata copying is no default?
[09:45:53] <elenril> no
[09:45:58] <av500> no
[09:46:00] * elenril should write a patch for that
[09:46:01] <twnqx> Oo
[09:46:21] <twnqx> does that go before the -i or after ?
[09:46:38] <av500> elenril: btw, asf->asf with codec copy yields a file that WMP plays with no sound :(
[09:47:28] <elenril> o_0
[09:47:30] <twnqx> wait
[09:47:34] <twnqx> so i first convert
[09:47:41] <twnqx> and then rerun to copy the meta data?
[09:47:42] <elenril> av500: did you test with older ffmpeg?
[09:47:48] <av500> no
[09:47:53] <av500> I will
[09:48:06] <av500> file looks ok from WM asf viewer side
[09:48:10] <elenril> twnqx: you run ffmpeg normally, just add -map_meta_data 0:0
[09:48:10] <av500> err, no
[09:48:28] <twnqx> uh, so outfile:infile is not a filename... understood, thanks
[09:48:50] <J_Darnley> It seems to work with some filenames
[09:49:11] <J_Darnley> But it is easier to use the "file ID numbers"
[09:49:23] <twnqx> funny how "acodec alac" turns to Output #0, ipod :P
[09:49:55] <twnqx> i personally would think that "ipod" is not a good name...
[09:50:26] <twnqx> errr
[09:51:30] <twnqx> why does my itunes crash on start in the vm D:
[09:53:48] <kshishkov> DRM?
[09:54:42] <twnqx> no idea
[09:54:57] <twnqx> but how the hell will i get the files on the ipod without
[09:55:52] <CIA-92> ffmpeg: michael * r22429 /trunk/libavcodec/h264_cavlc.c:
[09:55:52] <CIA-92> ffmpeg: Check level_prefix a bit (this just checks the max our bitreader can handle,
[09:55:52] <CIA-92> ffmpeg: as i did nt find a limit in the spec)
[09:55:52] <CIA-92> ffmpeg: This should stop cavlc_decode_residual() on a zero bitstream
[10:10:10] <av500> elenril: older ffmpeg version I have here produces a file that crashes WM asf viewer :)
[10:13:05] <elenril> lol
[10:13:11] <elenril> so it's an improvement
[10:13:42] <av500> yes, but even with current SVN, WM asf viewer  complains a lot
[10:13:57] <elenril> anything explicit?
[10:13:59] <av500> a lot of presentation times before send times
[10:14:03] <elenril> or just error 1084525
[10:14:13] <av500> no, very explicit
[10:15:06] <av500> and some packets flagged as multipayload with only 1 payload inside ...
[10:15:27] <elenril> anyway who'd want to use our asf muxer
[10:16:08] <elenril> s/our//
[10:22:31] <av500> elenril: well
[12:00:56] <twnqx> is embedding covers into the metadata already supported?
[12:30:32] <CIA-92> ffmpeg: mru * r22430 /trunk/configure:
[12:30:32] <CIA-92> ffmpeg: undef av_always_inline before redefining
[12:30:32] <CIA-92> ffmpeg: Fixes numerous warnings with --enable-small or --disable-optimizations.
[12:42:28] <kshishkov> mate!
[12:43:02] <pross-au> Hi
[12:43:36] <pross-au> A, C, D, E
[12:43:44] <kshishkov> where?
[12:44:08] <pross-au> I doubt they are in the wild
[12:44:41] <pross-au> But good job on the BIKb analysis
[12:44:56] <kshishkov> it was easy knowing BIKi
[12:47:13] <pross-au> The evolution of the EA codecs was quite telling. I suspect bink will be also (if you can source the samples).
[12:49:27] <kshishkov> it was mentioned in my blog that BIKd might exists in a wild
[12:51:45] <pross-au> Yeah, Vladimir (VAG) has a knack for finding things.
[12:52:53] <kshishkov> I'm still thankful he REd VMD
[13:14:38] <elenril> twnqx: metadata is supposed to be strings only
[13:15:11] <elenril> i think michael wants cover art to be exported as streams
[13:15:22] <twnqx> kinda makes sense, in the end
[13:16:15] <pross-au> elenril: because they typically have to be 'decoded'.
[13:16:56] <kshishkov> along with ASS rendered in oldschool way ;)
[13:17:50] <elenril> oldschool way?
[13:18:17] <twnqx> image subs.
[13:18:39] <CIA-92> ffmpeg: vitor * r22431 /trunk/libavformat/ffmdec.c: Fix memory leak in FFM demuxer
[13:18:46] <kshishkov> elenril: all text rendered with original font from CGA
[13:19:22] <av500> cover art as stream makes no sense
[13:19:28] <av500> it is metadata
[13:19:32] <pross-au> The AMIGA font was better
[13:20:11] <kshishkov> ok s/oldschool/newschool/ in text above
[13:33:45] <Vitor1001> pross-au: Have you seen my msg on -cvslogs?
[13:33:57] <kshishkov> too late
[13:34:05] <Vitor1001> :p
[14:17:36] <superdump> peloverde: i was just checking the desirable for 0.6 list and i saw latm on there
[14:17:48] <superdump> are you still looking at sbr stuff at the moment?
[14:17:57] <superdump> BBB: are you doing the ffmpeg soc application?
[14:18:55] <peloverde> superdump, I didn't put LATM there
[14:19:10] <superdump> me either
[14:19:14] * superdump looks at andoma
[14:19:17] <superdump> :)
[14:19:18] <kshishkov> and no intent to remove it from there either?
[14:19:40] <superdump> well it can stay so we're reminded
[14:19:46] <superdump> but maybe no one will look at it before 0.6
[14:20:00] <peloverde> I really don't intend on looking at LATM
[14:20:24] <superdump> i wasn't intending to right now either
[14:20:25] <kshishkov> the only way to remove something here is to implement it ;)
[14:20:28] <peloverde> I learned from adts->asc that people always forget to insert bitsatream filters
[14:20:38] <superdump> mmm
[14:20:51] <peloverde> inpart because no one knows what filters they need
[14:21:01] <kierank> do bitstream filters allow creation of multiple streams?
[14:21:08] <kierank> because that's possible in latm afaik
[14:21:23] <BBB> superdump: mike is
[14:22:38] <superdump> ok
[14:22:43] <kshishkov> BBB: no intent to add one of those? I'd mentor you for a change ;)
[14:23:05] <superdump> kierank: bitstream filters just re/deformat bitstreams into whatever format the decoder wants
[14:23:26] <BBB> kshishkov: ?
[14:23:48] <kshishkov> BBB: don't you want to participate in gsoc as a student?
[14:23:51] <BBB> kshishkov: I'm technically a student, but I already mentor someone :)
[14:23:52] <twnqx> talking about bitstream filters.
[14:24:03] <BBB> besides, my uni would never approve me participating
[14:24:05] <twnqx> i do have a question regarding them...
[14:24:07] <BBB> they're crazy
[14:24:22] <kierank> superdump: so let's say that one "latm stream" contains 4 separate tracks for example. How would you know in advance that there are 4 streams when using a bitstream filter?
[14:24:55] <superdump> the bitstream filter should parse the stream and identify that it has four tracks in it
[14:25:01] <superdump> and output them as separate tracks
[14:25:30] <twnqx> oh. i had to use the bsf in another software i don't have with me X:
[14:25:35] <superdump> parsing the track properties as approriate
[14:25:50] <kshishkov> BBB: who cares about them? In my uni it was only "participated? give us info to put to company website and to scientific activity report"
[14:26:18] <twnqx> but it went something like that... open file, figure out a h264 stream in the file. if my software recognises (successfully parses) a packet all is ok.
[14:26:20] <peloverde> I still think bitstream filters in ffmpeg are "broken"
[14:26:31] <twnqx> if not, insert that mpeg bsf, and retry
[14:26:32] <peloverde> The user shouldn't have to manually set up a filter chain
[14:26:36] <BBB> I might be mentoring someone though, so someone would have to take over mentor activity for me
[14:26:39] <BBB> at least on paper
[14:26:42] <BBB> I can still mentor him
[14:26:52] <peloverde> And in some cases we silently output broken files without them
[14:27:01] <superdump> mmm
[14:27:04] <kierank> peloverde: imo, just like smpte 337m encapsulation, chained demuxing is required
[14:27:09] <CIA-92> ffmpeg: benoit * r22432 /trunk/libavformat/ffmdec.c: Fix ffm_close return type.
[14:27:42] <peloverde> can't the outer demuxer just open the LATM demuxer like we do with DV?
[14:29:10] <kshishkov> it would require a special case
[14:31:51] <BBB> brb
[14:52:09] <peloverde> Can anyone reproduce https://roundup.ffmpeg.org/issue1805 ?
[14:56:46] <KotH> who is our local vlc representative here?
[14:57:14] <av500> j-b?
[14:57:18] * thresh points to j-b
[14:57:44] <j-b> KotH: maybe me
[14:57:50] <kshishkov> peloverde: seems to work fine here, probably he has not cleaned before building or something
[14:58:03] <mru> j-b: it's time to start thinking about linuxtag
[14:58:30] <j-b> when is it?
[14:58:45] <mru> 9-12 june
[14:59:33] <j-b> oh, yeah
[14:59:43] <j-b> what is needed?
[15:00:13] <peloverde> kshishkov, I wish we had AAC running on FATE, it would make my life so much easier
[15:00:38] <mru> j-b: bunnies and booze
[15:00:45] <mru> big buck bunnies, that is
[15:00:48] <kshishkov> peloverde: ask mike on fate ML ;)
[15:01:05] <kshishkov> and a lot of booze to endure aforementioned movie?
[15:04:01] <KotH> j-b: if vlc is present at lt, then it would be good if we could join up in one big booth
[15:04:53] <kshishkov> KotH: MPlayer - finally using both FFmpeg and VLC!
[15:05:07] <KotH> kshishkov: ?
[15:05:34] <av500> KotH: or we can hide the vlc guys behind the videowall again, no?
[15:05:43] <kshishkov> KotH: that's what you get if join everything in one big booth
[15:06:27] <KotH> kshishkov: well, we shared a booth with amarok once...
[15:06:39] <KotH> kshishkov: and they ended up giving us a working tittle for a book :)
[15:06:48] <kshishkov> audio players don't count ;)
[15:06:51] * av500 proposes to join booth with linuxHackerGirlz
[15:06:52] <j-b> http://www.linuxtag.org/2010/en.html wow, there is a photo of mru
[15:07:09] <kshishkov> KotH: now find somebody to donate _content_ for that book
[15:07:17] <mru> av500: will you send the invitation?
[15:07:38] <av500> provide address :)
[15:07:39] <KotH> kshishkov: i've written some intro.. but didnt had the time to clean it up and commit it
[15:08:00] <KotH> j-b: actually, that pic shows the ffmpeg/mplayer bunch at lt 2007
[15:08:12] <mru> btw, I thought of a new slogan for ffmpeg: There's a patch for that
[15:08:43] <mru> KotH: 2008 more likely
[15:08:52] <KotH> j-b: next question: how is the planning for VLCDD going?
[15:08:57] <KotH> mru: off by one ;)
[15:09:21] <kshishkov> mru: you forgot a word "welcome" at the end of slogan
[15:09:32] <KotH> j-b: 'cause if we want to do it together with ffcon, we need to start looking for a location
[15:09:58] <KotH> mru: "10y and still kicking" ?
[15:09:58] <j-b> KotH: I can't organise something in June, but in August/Sept, yes. Moreover June, might not make sense because of LinuxTag and OpenVideoConf
[15:10:07] <mru> kshishkov: that's the old slogan
[15:10:15] <KotH> j-b: aug/sep is fine too
[15:10:16] <kshishkov> KotH: 10y and still not 1.0
[15:10:30] <KotH> j-b: actually aug is better (students and vacation)
[15:10:39] <av500> ack for aug
[15:10:39] <j-b> end of aug is doable in Paris
[15:10:52] <KotH> kshishkov: you mean something like "we will beat hurd" ? :)
[15:10:57] <av500> ah, paris, I am there all the time, where is the fun in that?
[15:11:04] <j-b> hurd? still existing?
[15:11:15] <KotH> j-b: alternativeley, i got the adress of a nice location in northern germany from a friend
[15:11:31] <j-b> no pb for us.
[15:11:32] <KotH> j-b: yes, and switching the architecture again
[15:11:40] <av500> minix3 ftw!
[15:11:52] <KotH> av500: just because you got a signed cd!
[15:11:54] <KotH> ;)
[15:11:56] <j-b> We will just need a day in marge of the ffconf for VideoLAN matters
[15:12:09] <KotH> j-b: who's doing the planing at vlc?
[15:12:13] * j-b 
[15:12:22] <KotH> good!
[15:12:32] <kshishkov> mru: what about "no external decoders"?
[15:12:40] <j-b> if you meant "planning of VideoLAN Dev days"
[15:12:42] <kshishkov> should be a good goal too
[15:12:49] <KotH> j-b: that's what i meant
[15:14:41] <KotH> j-b: i'll do some more detailed planing and will come back with some date proposals tomorrow, if that is ok with you
[15:14:49] <j-b> sure
[15:15:04] <av500> kshishkov: what about: "able to re-mux it's own output .... eventually"
[15:15:39] <kshishkov> av500: there was a name for that test. Not to mention FFmpeg can do that
[15:15:58] <KotH> kshishkov: eat your own dog food?
[15:17:14] <kshishkov> KotH: no, that's using FFcc to compile FFmpeg ;)
[15:19:13] <av500> running on FFcpu....
[15:19:43] <kshishkov> of course
[15:20:07] * kshishkov tries not to mention "plays on FFogp"
[15:23:00] * KotH wonders how much alive ogp still is
[15:23:41] <kshishkov> if you don't know then who can know?
[15:24:16] <av500> FForacle?
[15:28:11] <peloverde> Speaking of long stalled projects, for some reason today I really feel like working on the AAC encoder
[15:28:23] <kshishkov> then go for it!
[15:28:43] * kshishkov always feel ashamed when he heard about ffaacenc
[15:36:59] <peloverde> It'll have a comback
[15:37:22] <peloverde> ffaac* projects have a tendency of coming back from the dead
[15:40:31] <CIA-92> ffmpeg: michael * r22433 /trunk/ffplay.c:
[15:40:31] <CIA-92> ffmpeg: Do not call SDL_SetVideoMode() with the same size as previously
[15:40:31] <CIA-92> ffmpeg: as this blanks the window.
[15:46:35] <CIA-92> ffmpeg: michael * r22434 /trunk/ffplay.c:
[15:46:35] <CIA-92> ffmpeg: Increase VIDEO_PICTURE_QUEUE_SIZE to 2.
[15:46:35] <CIA-92> ffmpeg: this allows more asynchronous decoding and display thus improving
[15:46:35] <CIA-92> ffmpeg: video smoothness.
[15:46:35] <CIA-92> ffmpeg: It also seems to improve absolute video decoding speed for some reason
[16:06:56] <kshishkov> peloverde: so you're saying we're dealing with undead codec?
[16:07:13] <peloverde> indeed
[16:09:23] <Honoome> what's the definition of undead codec? it sucks but people still use it?
[16:09:34] <Honoome> would a undead container be something like AVi?
[16:09:43] <twnqx> more like ogg
[16:09:47] <kshishkov> it digs out despite attempts to bury it
[16:10:08] <Kovensky> like nut?
[16:10:10] <Honoome> twnqx: why, do people _use_ ogg?
[16:10:19] <Honoome> I thought they just advocated it…
[16:10:23] <twnqx> yeah, i have youte some ogm...
[16:10:26] <twnqx> wuite*
[16:10:26] <bilboed-tp> because of vorbis mostly
[16:10:29] <twnqx> quite* damn
[16:10:53] <Kovensky> twnqx: AniMecha, a4e?
[16:11:06] <twnqx> zx
[16:11:13] <Honoome> bilboed-tp: I'd sincerely be curious for most xiph advocates to know their proportion between ogg and mp3 files… and ogg and avi of course
[16:11:19] <Kovensky> D:
[16:11:47] <Honoome> it's not that I think ill of the xiph advocates but… well I simply don't trust half of them :P
[16:11:54] <CIA-92> ffmpeg: michael * r22435 /trunk/ffplay.c:
[16:11:54] <CIA-92> ffmpeg: Only reschedule refresh if we successfully removed the scheduled one.
[16:11:54] <CIA-92> ffmpeg: Fixes some spurious error messages.
[16:12:06] <kshishkov> Honoome: huh, so you trust half of them?
[16:12:13] <bilboed-tp> Honoome, you mean "vorbis and mp3" and "theora and divx" I assume ? Else you're comparing pears and oranges
[16:12:43] <iive> ogg virbis are like Siamese twins. One of them is dead, but the other keeps it alive because of their internal connection.
[16:12:44] <Kovensky> <bilboed-tp> Honoome, you mean "vorbis and mp3" and "theora and divx" I assume ? Else you're comparing pears and oranges <-- what
[16:12:56] <Kovensky> codecs don't have overhead, they have a bitrate and that's it
[16:13:00] <kshishkov> bilboed-tp: well, "vorbis vs. mp3" ~= "divx vs. theora", you got the latter swapped
[16:13:15] <Honoome> bilboed-tp: no I literally meant ogg and mp3 (as a container rather than codec here) and ogg and avi (don't care whether it's divx/xvid/wmv/h264)
[16:13:30] <bilboed-tp> mp3 is not a container, it's a codec that can work outside of a container
[16:13:42] <bilboed-tp> and yes, ogg sucks
[16:13:43] <Honoome> *format rather than codec
[16:14:01] <Honoome> for what I care you could replace mp3 there with $anything-non-ogg-container
[16:14:11] <bilboed-tp> it sucks
[16:15:03] <bilboed-tp> and yes, I really want to slap the xiph guys for making vorbis and theora almost unusable outside of ogg
[16:15:32] <Kovensky> vorbis should work just fine in matroska
[16:15:48] <Honoome> I'm just quite sure at least half the people who say “ogg (vorbis|theora|flac) is fantastic” (and I don't care about vorbis or theora here, just talking about the frigging container…) will have most of their stuff downloaded from emule/bittorrent in non-ogg format…
[16:15:50] <bilboed-tp> that would be the almost unusable
[16:16:01] <kshishkov> bilboed-tp: be thankful their lossless codec hasn't stuck around
[16:16:09] <bilboed-tp> kshishkov, which one is that ?
[16:16:12] <elenril> they had a lossles codec?
[16:16:12] <Honoome> kshishkov: FLAC?
[16:16:22] <bilboed-tp> oh, some people use it alright
[16:16:35] <Kovensky> FLAC isn't their lossless codec
[16:16:35] <bilboed-tp> in fact quite a lot of illegal rips are in FLAC
[16:16:43] <Kovensky> FLAC was independent, they just brought it in later
[16:17:03] <Honoome> [the “I'm so cool I'll use the minimum amount of bits for the fields” FLAC that uses a 21-bit field in its headers?]
[16:17:22] <Honoome> bilboed-tp: magnatune releases (legal) lossless albums in FLAC as well :/
[16:17:36] <bilboed-tp> yup
[16:17:38] <kshishkov> no, there was some IIR-based lossless codec Ogg-Squish for which some container was designed, then came Vorbis
[16:17:39] * Honoome uses ffmpeg to convert them to M4A[ALAC] just for the sake of being able to play them around
[16:17:54] <Honoome> kshishkov: I'm happy I never had to deal with that I guess
[16:18:03] <kshishkov> Honoome: use FFmpeg-based players to eliminate converters
[16:18:20] <kshishkov> nobody has ever seen it
[16:18:20] <Honoome> kshishkov: iCant :P
[16:18:53] <mru> HALALAC, the codec for muslims
[16:19:53] <kshishkov> or red natives of America
[16:30:22] <KotH> mru: wouldnt that be JIHAC?
[16:31:11] <mru> JIHAAC
[16:33:37] * kshishkov thinks in most cases the best codec is "TurdAudio"
[16:44:26] <superdump> peloverde: ping?
[16:44:33] <peloverde> pong
[16:44:44] <superdump> how common is scalable aac in the wild?
[16:45:11] <kshishkov> probably it's limited to peloverde's samples only
[16:45:16] <peloverde> I haven't seen it
[16:46:08] <kshishkov> then it's nonexistent
[17:47:08] <BBB> peloverde: thanks for the supporting email
[17:47:33] <peloverde> That issue has been a thorn in my side for a long time
[17:48:10] <peloverde> Also my guess is with SBR it does more damage than help (though I haven't benchmarked it)
[17:49:11] <BBB> not just in cycles
[17:49:14] <BBB> also in lines-of-code
[17:49:18] <BBB> (of the caller)
[17:49:25] <BBB> look at wmadec.c
[17:49:27] <BBB> it's hideous
[17:50:25] <peloverde> I agree
[17:50:41] <peloverde> And I never wind up testing for it, because I don't do disable-asm builds often
[17:50:44] <BBB> hopefully michael agrees also
[17:50:55] <BBB> I'd love to use float_to_int16 in audioconvert.c
[17:51:01] <BBB> but that's just not possible right now
[17:51:24] <mru> even the asm ones want full 32k range
[17:51:39] <mru> and the recent pure-float decoders output -1..1
[17:51:59] <mru> there should at least be a way to request that scaling of the decoder
[17:52:23] <mru> I suspect it's almost always possible to fold it into some other multiplication
[17:52:47] <BBB> documentation on this would be great
[17:52:55] <mru> rtfs :-)
[17:54:24] <BBB> I'm asm-illiterate
[17:54:32] <BBB> or what if I am asm-illiterate?
[17:54:34] <BBB> or lazy
[17:54:51] <BBB> I shouldn't have to read 3 impls to get it
[17:54:52] <peloverde> can't scaling be done in float_to_int16_c by adding directly to the flaoting point exponent
[17:54:52] <mru> nice try, mr wmavoice
[17:55:09] <mru> I'm talking about the asm versions
[17:55:31] <mru> adding an extra multiplication there would slow them down substantially
[17:55:34] <mru> like 30%
[17:55:51] <mru> which is ridiculous when it can be had for free in the decoder
[17:56:04] <peloverde> It isn't handled for free though
[17:56:13] <peloverde> I take a substantial hit just having that case
[17:56:19] <mru> in many decoders it is free
[17:56:42] <mru> don't penalise them because of one special case
[17:56:43] <peloverde> and I don't know if the decoder is talking to SBR or not until after the frame is decoded
[17:57:23] <peloverde> but we are penalizing them because of one special case
[17:57:44] <mru> we have two types of decoders in ffmpeg now
[17:57:50] <mru> the old ones outputting int16
[17:57:53] <mru> they all scale internally
[17:58:05] <mru> and the new, slow ones outputting float -1..1
[17:58:17] <peloverde> that's because audioconvert sucks
[17:58:23] <BBB> they're slow because they can't use asm functions
[17:58:35] <BBB> because the asm functions are ununderstandable
[17:58:36] <mru> the decoder cores are mostly ok
[17:59:13] <mru> and the old ones _do_ scale on the fly somehow
[17:59:27] <BBB> btw there's issue tracker entries to convert them to float-output
[17:59:40] <BBB> https://roundup.ffmpeg.org/issue59
[17:59:42] <mru> and slow them down, fabulous
[17:59:45] <BBB> for wma, for example
[17:59:51] <BBB> it shouldn't
[17:59:55] <mru> sdgfhjkl ghui]
[17:59:56] <BBB> for wma, for example, all is float
[18:00:17] <BBB> the last call in its read function is the float->int convert
[18:00:22] <mru> don't you dare go and _remove_ the fast conversion for some silly reaons of purity
[18:00:30] <mru> wma is a bad example
[18:00:36] <BBB> I agree with you
[18:00:39] <BBB> I won't remove it
[18:00:40] <mru> look at ac3, vorbis, dca or whatever
[18:00:42] <BBB> I'd make it slower
[18:00:43] <BBB> it's bad
[18:00:45] <peloverde> Also if the target is anything bigger than int16 you lose prescion because of that damn hack
[18:00:45] <BBB> BUT
[18:00:51] <BBB> what if it could be faster?
[18:01:01] <mru> all except wma do it right
[18:01:02] <BBB> imagine the case where alsa wants float input
[18:01:07] <BBB> imagine the mac
[18:01:10] <mru> apart from the new ones that don't do it at all
[18:01:14] <BBB> where the whole audio pipeline is float
[18:01:19] <mru> yes, sure
[18:01:21] <mru> I agree
[18:01:34] <mru> but we shouldn't rush and remove something that someone thinks is ugly
[18:01:35] <peloverde> Imagine where the output is fed by the application into some third party post processing
[18:01:42] <mru> before we can replace it with something good
[18:01:43] <astrange> perian audio currently has to output 16-bit, i'm very interested in anything that lets it output float
[18:01:43] <BBB> mru: I agree, and I won't remove it
[18:01:48] <peloverde> audo post is usually float
[18:01:53] <mru> yes, yes, yes I agree
[18:01:55] <mru> now stop it
[18:01:59] <BBB> :)
[18:02:01] <astrange> i'd also like an fp mpegaudio decoder (if it's faster)
[18:02:17] * BBB too
[18:02:21] <mru> save that for another day
[18:02:27] <BBB> lol :)
[18:02:27] <astrange> yes
[18:02:37] <astrange> thought about adding it to the soc projects but i'm not qualified to mentor it
[18:02:43] <BBB> mru: I won't change anything, but it's good to think about
[18:03:14] <BBB> and audioconvert.c should be able to use dsp:float_to_int16 without hacks
[18:03:23] <mru> yes
[18:03:41] <peloverde> Suppose we make audioconvert call dsp.float_to_int16_interleave as long as it != ff_float_to_int16_interleave_c
[18:03:49] <mru> that won't work
[18:03:51] <mru> wrong range
[18:04:10] <mru> asm float_to_int16 doesn't scale
[18:04:13] <mru> nor should it
[18:04:40] <peloverde> How about we make each dsp.float_to_int16_interleave advertise what scaling it wants
[18:04:54] <peloverde> as opposed to making codec authors cargo cult it from other formats
[18:04:54] <BBB> ugly :)
[18:04:56] <mru> that's what I've been saying for the last 2 years
[18:04:58] <iive> peloverde: haven't i told you you can make _c work with any scalling?
[18:05:14] <peloverde> iive: you've told me you can, but i don't have the code
[18:05:17] <mru> iive: not without making it slower
[18:05:32] <iive> peloverde: i've send it to the maillist, around year ago.
[18:06:38] <peloverde> mru: And it's not about purity, it's about I can't test it without making special builds
[18:06:42] <peloverde> That's teh real issue
[18:08:53] <peloverde> And not being able to get 24-bit output sucks because then I can only verify to 15 bits and not 16
[18:08:56] <astrange> try exposing dsp_mask in the ffmpeg options
[18:09:18] <kshishkov> output floats ;)
[18:09:38] <peloverde> we don't make video decoders spit out RGB unless that is their native format
[18:09:58] <kshishkov> yes
[18:11:07] <kshishkov> are you implying yuv=float and rgb=int16 analogy?
[18:11:25] <mru> that's grossly inaccurate
[18:11:44] <mru> the display hardware takes yuv directly in most cases
[18:11:50] <mru> most sound cards take int16
[18:11:55] <mru> that's why it is the way it  is
[18:12:08] <peloverde> most not all, and the target output isn't always a sound card
[18:12:19] <mru> it was when the code was written
[18:12:21] <peloverde> ffplay doesn't even work with my sound card half the time
[18:12:28] <peloverde> It just deadlocks
[18:12:47] <kshishkov> blame SDL
[18:12:52] <mru> 10 years ago normal people would never have seen a sound card capable of anything but int16
[18:12:55] <mru> if that
[18:13:14] <kshishkov> mru: I thought float output was only to ease life for codec devs
[18:13:15] <peloverde> Newsflash: it isn't 2000 anymore
[18:13:21] <kshishkov> u8
[18:13:22] <mru> if you wanted float support you'd have to get very expensive pro kit
[18:13:32] <mru> peloverde: the code was written around 2000
[18:13:34] <astrange> the noise floor for 16-bit is already low enough for anyone
[18:13:39] <mru> much of it
[18:13:51] <astrange> but more is still useful for volume adjustment before playing it
[18:13:52] <peloverde> That doesn't mean it should be kept the way it is
[18:13:58] <mru> I'm not saying it should
[18:14:08] <mru> just providing an explanation for the current state of affairs
[18:14:23] <mru> but the worst thing you can do is to rush a change
[18:14:26] <mru> then you get russia
[18:15:20] <kshishkov> huh? changes can't be rushed in Russia. Never!
[18:15:22] <peloverde> I couldn't even change AAC to use MDCT scaling because people wanted to protect theoretical scalefactors that were bigger than MAX_FLOAT
[18:15:55] <mru> kshishkov: wrong, they did twice actually
[18:16:02] <mru> first time they got the ussr
[18:16:09] <mru> second time they got the mess after the ussr
[18:16:37] <kshishkov> mru: first revolution was in February of 1917 and USSR was created in 1922
[18:16:58] <kshishkov> and the mess after resembled USSR for many years as well
[18:16:59] <mru> well, that's pretty quick by russian standards
[18:17:13] <kshishkov> same monarchy
[18:17:27] <kshishkov> from Ivan IV till Vladimir I
[18:18:07] <kshishkov> (except that in soviet times the throne was passed from grandfather to another grandfather)
[18:19:15] <iive> peloverde: float range -32768.0 to 32767.0 the constant is 0x4B40FFFF
[18:19:17] <pJok> kshishkov, http://en.wikipedia.org/wiki/Maria_Feodorovna_%28Dagmar_of_Denmark%29
[18:19:52] <peloverde> iive: what constant?
[18:20:03] <iive> of the float_to _c function
[18:20:14] <kshishkov> pJok: jag vet det men mesta ryska kungar och drottingar var tyska
[18:20:57] <peloverde> I would tell that to the defenders of that awful function
[18:21:57] <kshishkov> peloverde: I think Michael hacked it with minimum effort, hence that weird range
[18:22:54] <iive> i would assume that 0-1.0 is normal range for float.
[18:23:17] <kshishkov> that too, yes
[18:23:38] <kshishkov> "normal" is the most correct definition too ;)
[18:24:20] <mru> the weird range for the C float to int is because with that scale and bias you can lift an int16 directly out of the float with only a shift
[18:24:43] <kshishkov> yes, it's expected
[18:25:05] <iive> no, with the above constant you can do that in another range.
[18:25:40] <iive> it can work in arbitrary range.
[18:25:58] <mru> what do you do with that constant?
[18:27:17] <iive> actually there are 2 constant, the bias that have to be added is 385*32768 .
[18:27:35] <mru> added where?
[18:28:21] <iive> you add the bias to the float, then the function uses the constant to get correct int from the mantisa
[18:28:42] <iive> it does check for the exponent (aka overflow) manually before that.
[18:29:01] <mru> but that's more work
[18:29:14] <iive> it's already done.
[18:29:20] <mru> fuck off
[18:30:01] <kshishkov> iive: patch+benchmark please
[18:30:05] <iive> my point is, you can remove all the scaling code from all codecs, without removing the _c function.
[18:30:23] <mru> the point is we shouldn't do that
[18:30:36] <mru> if you do that you end up with audioconvert.d
[18:30:38] <mru> .c
[18:30:44] <iive> kshishkov: it's on the maillist, there _c function is not getting any slower.
[18:32:58] <kshishkov> ok, I'll wait for outcome
[18:35:25] <iive> peloverde: what is the exact problem here?
[18:36:09] <peloverde> Mans thinks its wrong, he's usually pretty smart
[18:36:51] <peloverde> And I'm not usually very good at getting small patches accepted, big ones are worse
[18:37:08] <mru> there are of course a few different magic ranges where you can pull an int from a float like that
[18:37:48] <mru> but there's no point in supporting more than one
[18:40:26] <iive> it should work with any range that is power of 2.
[18:40:34] <mru> so?
[18:40:35] <drv> i guess this is the thread in question: http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/2008-July/050598.html
[18:41:42] <peloverde> There is a point when one requires a whole special codepath and the other uses the same range as everything else
[18:43:23] <iive> peloverde: if only the range is problem, then the _c function could be made to work with another range.
[18:43:55] <mru> iive: please shut up until you've figured out what we're talking about
[18:43:57] <iive> in most codecs the bias is added during mdct, so it is much cheaper.
[18:44:29] <iive> mru: i'm not talking with you.
[18:46:03] <ramiro> good old #ffmpeg-devel... getting more ridiculous every day...
[18:46:35] <iive> well, i'm just trying to help. and I get kicked as reward.
[18:46:37] <kshishkov> ramiro: yes, kicking reminds me of good old days which I mostly skipped
[18:46:43] <Honoome> hey I didn't even make a joke today! :P
[18:48:28] <kshishkov> try it then
[18:52:38] <kierank> http://linuxcentre.net/get_iplayer-dropped-in-response-to-bbcs-lack-of-support-for-open-source
[18:56:17] <bilboed-tp> such a shame :(
[18:56:17] <bilboed-tp> and that's a wrong channel, my bad
[18:58:59] * justlooking_ thinks its a shame kierank , is anyone making a simple Iplayer parser stript for ffmpeg now then!
[18:59:18] <kshishkov> unlikely
[18:59:35] <kierank> they are pandering to the "rights holders" again
[18:59:41] <Honoome> kshishkov: I meant for the ridiculous… ridicule is my third name!
[19:00:16] <kierank> back in 2003 when they went fta they just said screw it we're not paying murdoch £40m, we're going fta; get over it
[19:00:59] <kshishkov> Honoome: and your last name ends with ridiculous character as well
[19:01:53] <Compn> justlooking_ : i heard there was a patch for some iplayer + rtmpdump thing
[19:02:03] <Compn> patch or seperate project
[19:12:14] <justlooking_> parsing the iPlayer pages for flashhd,flashvhigh1 etc seems like the harder part then pass it to rtmpdump as that handles the new swf verification message better than the FLVStreamer apparently then into the ffmpeg input sounds simple enough for people here,i guess it just takes the will to do it!
[19:13:35] <kierank> or just continue to maintain get_iplayer
[19:13:37] <kierank> much easier that way
[19:20:46] <peloverde> If we want to be constructive... being able to to select float->int method, being able to request an output format, and float audio on fate would all lessen my hostility to ff_float_to_int16_c
[19:20:57] <justlooking_> i tryed reading and understanding the get_iplayer.cgi perl to see how and were he parses out and gets the real flashhd,flashvhigh1 URLs etc, but being a single massive script rather than seperate self contained script just doesnt help BINAP, its probably simple for you OC so i hope you or someone does continue and fork.
[19:26:00] <BBB> Vitor1001: do you still have that wmavoice postfilter code I sent you? did you notice how the wmavoice postfilter does ff_adaptive_gain_control() with a abssum instead of a dot_product of speech / postfilter?
[19:26:37] <BBB> Vitor1001: and now that I know that, should I use the binary code or should I use the code in ff_adaptive_gain_control() (nowing I will deviate from binary output by doing that)?
[19:27:51] <Vitor1001> BBB: Yes, I told you I found it weird.
[19:28:10] <Vitor1001> But, no, sum of squares and sum of abs() are different beasts...
[19:28:19] <Vitor1001> One cannot just replace one by the other
[19:28:46] <Vitor1001> BTW, I should find some time to see that funny FFT filtering
[19:28:57] <Vitor1001> I would be great to separate in a single function
[19:29:20] <Vitor1001> mirroring + RDFT + set Im to 0 + Re->Im + IRDFT
[19:29:35] <Vitor1001> BTW, in this function it is zeroing stuff that is already 0
[19:30:58] <BBB> really?
[19:31:13] <BBB> Vitor1001: so, can I change ff_adaptive_gain_control() then?
[19:31:16] <BBB> who uses it anyway?
[19:31:20] <Vitor1001> Yes, the FFT of a symetric function has zero imaginary part.
[19:31:22] <Vitor1001> Wait a mim
[19:31:56] <BBB> not surprisingly, amr && sipr
[19:32:10] <BBB> really?
[19:32:15] <BBB> in that case I can remove one of the two steps
[19:32:35] <Vitor1001> Yes, you can replace the loop that sets it to zero by just a
[19:33:10] <Vitor1001> farr1[0] = 0;
[19:33:13] <Vitor1001> farr1[2] = 0;
[19:33:15] * BBB keeps skipping over that code because it looks scary
[19:33:29] <Vitor1001> But don't forget to put a comment to say the others are zero
[19:33:37] <Vitor1001> It is something we forget easily
[19:33:39] <BBB> ok
[19:33:50] <Vitor1001> But I think these three steps makes a single thing
[19:34:14] <Vitor1001> It is just that I'm out of time to do the math and figure out why :(
[19:34:21] <BBB> but are they zero? because the symmetry is around 0x41, not 0x40
[19:34:30] <BBB> or does that not matter / is that in fact intended?
[19:34:39] * BBB is still no good at math
[19:34:44] <Vitor1001> It starts at 1.
[19:36:15] <BBB> too many things at once :)
[19:36:18] <Vitor1001> But since it is symetric in the "123454321" (without repeating the 5), the input vector is not a power of 2.
[19:36:41] <Vitor1001> What I meant that you do ff_rdft_calc(&s->rdft, &farr1[1])
[19:36:59] <Vitor1001> So symetric around 0x41 is symetric around the middle.
[19:37:11] <BBB> right
[19:37:21] <BBB> that hack is mine btw, the original code doesn't do that
[19:37:24] <BBB> anyway...
[19:37:27] <BBB> I should know this
[19:37:43] <Vitor1001> It is already pretty cool
[19:37:46] <BBB> ok, let's go back to adaptative_gain_control() - shall I change the function or shall I add a copy of it in wmavoice.c with identical names and a comment that it's different?
[19:38:12] <Vitor1001> Having to understand what kind of FFT it is using _and_ understanding the filtering at the same time is harder
[19:39:18] <Vitor1001> Does it does also the sqrt()?
[19:41:15] <BBB> no
[19:41:34] <BBB> maybe that's why it doesn't do the dot
[19:41:47] <Vitor1001> makes sense
[19:41:49] <BBB> is sqrt(dot(x,x,size)) the same as abssum(x, size)?
[19:41:52] <BBB> should be, right?
[19:41:57] <Vitor1001> No...
[19:42:18] <mru> of course not
[19:42:22] <BBB> oh wait, it's not
[19:42:27] <BBB> I told you I'm no good at math
[19:42:38] <Vitor1001> sqrt(2*2 + 2*2) = sqrt(8) != 2+2
[19:42:56] <BBB> so shall I modify ff_adaptative_gain_control() or copy the function into wmavoice.c?
[19:43:08] <Vitor1001> I'd say copy with a comment
[19:43:12] <BBB> ok
[19:43:13] <ohsix> did anyone try bunny during that fit of fuzzing?
[19:43:19] <mru> or more generally sqrt(a+b) != sqrt(a)+sqrt(b)
[19:43:49] <BBB> ok, will do, back to the FFT I suppose
[19:47:50] <peloverde> ohsix: bunny failed to compile ffmpeg for me
[19:47:58] <ohsix> ah
[19:48:47] <ohsix> i haven't had a reason to check it out yet :/
[19:52:43] <peloverde> I really wish someone would adopt flayer
[19:53:17] <peloverde> why did so many @google.com people start separate fuzzer projects a few years back and abandon them all
[19:54:34] <ohsix> probably seemed like a good idea at the time to solve a major problem they were having with something; then they probably finally decided to bin it, or write a safe language to do it :O
[20:39:58] <Yuvi> looks like chrome is doing the same stupid think ffmpeg2theora did (does?) for a/v sync on decoding errors
[20:41:08] <Yuvi> aka on decode_video returning an error, skip ahead to the next frame that doesn't and display that instead, ignoring pts
[20:53:30] <Compn> lol
[20:55:58] <CIA-92> ffmpeg: siretart * r22436 /branches/0.5/libswscale/swscale.c:
[20:55:58] <CIA-92> ffmpeg: Fix compilation on powerpc with --disable-altivec
[20:55:58] <CIA-92> ffmpeg: in case altivec is disabled, even compilation of code using altivec
[20:55:58] <CIA-92> ffmpeg: keywords or asm must be avoided.
[20:55:58] <CIA-92> ffmpeg: backport r30869 from mplayer repo by siretart
[21:00:32] <BBB> Vitor1001: do you have any thoughts about the top of the postfilter, what looks like an echo-type of filter? have you ever seen that before?
[21:08:22] * BBB thinks it's kalman smoothing
[21:08:43] <Dark_Shikari> Yuvi: any luck with my latest 3 crashes?
[21:09:44] <Yuvi> Dark_Shikari: haven't looked at them yep
[21:09:44] <Yuvi> xiph's been complaining about ffmpeg's ogg overhead quite loudly lately now that diego's gone an riled them up, so I'm fixing that
[21:10:26] <Dark_Shikari> ah.
[21:19:43] <twnqx> drop muxing support for it? :P
[21:19:55] <twnqx> gets the overhead to absolute 0!
[21:21:46] <Compn> lol
[21:22:04] <Compn> lots of trolling to go around
[21:40:49] <CIA-92> ffmpeg: mstorsjo * r22437 /trunk/libavcodec/arm/asm.S:
[21:40:49] <CIA-92> ffmpeg: Only use .size in ARM assembly when targeting ELF
[21:40:49] <CIA-92> ffmpeg: This fixes compilation on mingw32ce
[21:50:08] <peloverde> Has anyone looked into MinGW reacting poorly to -Werror=missing-prototypes?
[21:53:17] <wbs> peloverde: it was discussed somewhere recently (don't remember if it was on the ML or here..)
[21:58:09] <wbs> peloverde: http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/2010-March/084604.html
[22:02:00] <wbs> BBB: ok with the custom SDP url compromise that luca ok'd? http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20100309/43223d6f/attachment.patch
[22:02:27] <BBB> ah darn it he found me
[22:02:33] <wbs> muahah :-)
[22:03:12] <wbs> it's not pretty, but luca seemed quite reluctant to touching the sdp creation interface
[22:03:41] <BBB> link doesn't work
[22:04:02] <BBB> what's the patch name again?
[22:04:20] <wbs> custom-sdp-url.patch
[22:04:53] <peloverde> wbs: thanks
[22:08:31] <BBB> eeeeeeeeeeeeeeeeeeeeeeewwwwhhh
[22:08:34] <BBB> that is ugly
[22:09:04] <BBB> why doesn't he want to touch the sdp creation interface?
[22:09:10] <BBB> just add a avf_sdp_create2()
[22:09:14] <peloverde> Werror options doing nasty things on unanticipated compiler versions, what a surprise
[22:09:31] <ohsix> whats it doing?
[22:09:35] * Kovensky wonders how is the BBB rendering project going
[22:09:37] * Kovensky runs
[22:11:29] <wbs> yes, that's what I suggested, but he thinks that introduces the possibility to specify a completely unrelated url, and insisted on creating the SDP from rtp muxer contexts instead
[22:11:37] <wbs> until I reminded him of what a mess that becomes
[22:11:49] <BBB> we do that all the time
[22:11:49] <BBB> ?
[22:11:55] <BBB> oops
[22:11:57] <BBB> anyway
[22:12:09] <BBB> the "completely unrelated uri" could be done in this way also
[22:12:14] <wbs> exactly
[22:12:14] <BBB> I don't see how that changes anything
[22:12:21] <BBB> if that happens, it's an application bug
[22:12:24] <BBB> we don't care
[22:12:26] <BBB> fix the app
[22:12:36] <wbs> what about adding the more flexible sdp creation api as an internal ff_ function?
[22:12:38] * BBB needs an english tea
[22:12:45] <BBB> wbs: sounds fine with me also
[22:13:10] <wbs> since once we bump the public function, we should be pretty sure of how to design the api
[22:13:53] <wbs> but in this case it's simply a helper utility function needed by one part of lavf, and also exposed publicly (perhaps using a more restricted api)
[22:14:15] <wbs> ok, so I'll try to push for that solution once again
[22:16:34] <BBB> thanks
[22:16:41] <BBB> do you need me to reply in an email supporting that?
[22:17:07] <wbs> that would be helpful
[22:18:40] <BBB> done
[22:19:06] <wbs> thanks
[22:19:15] <wbs> ok with committing ff_ntp_time that luca approved of, btw?
[22:19:49] <BBB> yes
[22:19:54] <wbs> ok, great
[22:22:43] <CIA-92> ffmpeg: mstorsjo * r22438 /trunk/libavformat/ (rtpenc.c utils.c internal.h): Make the ntp_time function available to other parts of libavformat, as ff_ntp_time
[22:25:33] <CIA-92> ffmpeg: mru * r22439 /trunk/configure: configure: allow mips64el and powerpc64 as values for --arch
[22:25:36] <CIA-92> ffmpeg: mru * r22440 /trunk/libavcodec/sparc/ (dsputil_vis.h simple_idct_vis.c dsputil_vis.c): sparc: fix dsputil prototypes
[22:25:36] <CIA-92> ffmpeg: mru * r22441 /trunk/libavcodec/sparc/ (dsputil_vis.c vis.h): sparc: fix a few pages of cast warnings
[22:44:14] <CIA-92> ffmpeg: michael * r22442 /trunk/ffplay.c:
[22:44:14] <CIA-92> ffmpeg: Fix some apparent +- errors in the audio vissualization.
[22:44:14] <CIA-92> ffmpeg: The bugs become only vissible at higher time resolution than what is
[22:44:14] <CIA-92> ffmpeg: used currently.
[22:45:06] <DonDiego> michael and his double 's' in viSual...
[22:52:34] <iive> you can try to implement pre-commit filter that does spell check, it should ignore words with special symbols like var_name and function()
[22:54:56] <BBB> wbs: sorry if I'm not terribly up to date
[22:55:05] <BBB> wbs: so why didn't we want to change s->filename in the original context?
[22:55:08] <DonDiego> i've already put some thought to it and have a text file michaelni_typos lying around
[22:55:22] <drv> just need a michael_to_english() filter ;)
[22:55:32] <wbs> BBB: we'd have to change it back to the original value anyway
[22:55:39] <BBB> why?
[22:55:49] <BBB> we own the context, it's private, no?
[22:56:06] <wbs> well, actually we don't need to anymore, since we've got the original requested url in rt->control_uri
[22:56:13] <drv> actually those typos don't bother me so much - it's more things like "somewhen" that get under my skin
[22:56:32] <BBB> oh wait that's the rtsp avfctx
[22:56:35] <BBB> I thought it was the rtp
[22:56:42] <BBB> man, I really need to sleep
[22:56:45] <Compn> somewhen is acceptible
[22:56:53] <Compn> englishism
[22:57:13] <drv> it's more of a direct german-to-englishism from what i've seen
[22:57:17] <Compn> ah
[22:57:24] <drv> wenn -> when i think
[22:57:32] <Compn> sometime > somewhen
[22:57:47] <drv> right, it should be sometime, but i see somewhen a lot :)
[22:57:52] <Compn> heh
[22:58:22] <Compn> if only you guys spent this much time on the code instead of worrying about typos and punctuation
[22:58:46] <twnqx> or on compiler warnings
[22:58:48] * twnqx ducks
[22:59:11] <BBB> wbs: shouldn't you input the RTP AVFCtx into avf_sdp_create()?
[22:59:28] <DonDiego> drv: are you identified?
[22:59:43] <drv> hm, apparently not - need to fix my client
[22:59:45] <BBB> maybe I'm confused
[22:59:48] <drv> i think it broke when they changed ircd
[23:00:15] <drv> no wait, maybe i am logged in, or at least nickserv thinks so
[23:01:48] <BBB> wbs: if I'm completely wrong, then just ignore me and go ahead with the AVFCtx copy, but please add a big phat /* FIXME: do this without copying */ above it
[23:04:53] <DonDiego> drv: try leaving and rejoining the channel
[23:05:22] <drv> :)
[23:07:51] <DonDiego> drv: committers get op here..
[23:07:53] <DonDiego> welcome aboars
[23:07:56] <DonDiego> welcome aboard
[23:08:02] <drv> thanks
[23:09:22] <iive> well, not all committers
[23:14:08] <BBB> wbs: still there? :)