Ffmpeg-devel-irc

Download

ffmpeg-devel-irc@ffmpeg.org

March 2010

1 participants
31 discussions

IRC log for 2010-03-10
by irc＠mansr.com 11 Mar '10

11 Mar '10

[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(a)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-supp… [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/43223… [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? :)

1 0

IRC log for 2010-03-09
by irc＠mansr.com 10 Mar '10

10 Mar '10

[00:19:43] <CIA-92> ffmpeg: bcoudurier * r22355 /trunk/libavformat/ (Makefile adts.h adtsenc.c mpegtsenc.c): In mpegts muxer, write adts header if aac bitstream does not contain it [00:29:37] <Yuvi> well, vp3 no longer leaks buffers on errors, but that didn't fix the crash [00:29:53] <Dark_Shikari> hopefully that will make it easier to find issues though [00:29:59] <CIA-92> ffmpeg: conrad * r22356 /trunk/libavcodec/vp3.c: vp3: be less spammy on broken files [00:30:00] <CIA-92> ffmpeg: conrad * r22357 /trunk/libavcodec/vp3.c: vp3: Simplify buffer management [00:30:00] <CIA-92> ffmpeg: conrad * r22358 /trunk/libavcodec/vp3.c: vp3: Don't leak buffers on errors [00:30:01] <CIA-92> ffmpeg: conrad * r22359 /trunk/libavcodec/vp3.c: vp3: use FF_BUFFER_TYPE_COPY [00:30:01] <CIA-92> ffmpeg: conrad * r22360 /trunk/libavcodec/vp3.c: vp3: Allocate a dummy reference frame if we have no keyframe [00:30:02] <CIA-92> ffmpeg: conrad * r22361 /trunk/libavcodec/vp3.c: vp3: Set pict_type [00:30:13] <Dark_Shikari> yay [00:31:20] <astrange> i wonder if you broke perian with that. its weird buffer management didn't work with vp3 and i had to hack it [00:38:04] <CIA-92> ffmpeg: bcoudurier * r22362 /trunk/libavcodec/dnxhddec.c: Fix interlaced vc-3 decoding, issue #1753 [00:44:16] <Yuvi> should be the same [00:47:19] <CIA-92> ffmpeg: bcoudurier * r22363 /trunk/libavformat/mov.c: Preallocate index entries in mov demuxer, huge speedup [00:48:20] <Dark_Shikari> nice [00:48:23] <Dark_Shikari> "huge speedup" [01:04:01] <CIA-92> ffmpeg: daniel * r22364 /trunk/ (7 files in 4 dirs): Kega Game Video (KGV1) decoder [01:04:01] <CIA-92> ffmpeg: bcoudurier * r22365 /trunk/libavformat/mov.c: In mov demuxer, convert mac encoded strings to utf-8 [01:06:03] <Yuvi> nope, broke it somehow [01:07:51] <astrange> try commenting out glob->shouldUseReturnedFrame = TRUE; [01:09:45] <Yuvi> nope, crashes without displaying anything now [01:14:17] <mfg> is there any way I can test my fix against FATE (or the same test cases) before resubmitting my patch? [01:14:47] <mru> you can always grab the sample and run the command manually [01:14:55] <mfg> i did, and it works [01:15:10] <mfg> but i figure, if I can just test the whole thing before its committed, it'd save the trouble [01:15:19] <mru> there's no easy way to do that [01:15:31] <mru> what was the problem? [01:15:42] <mfg> heheh, [01:15:58] <janneg> Yuvi: are there uncommitted matrosko demuxer patches? the lavf demuxer can't read the index of files created by the lavf muxer. http://pastebin.ca/1829344 [01:16:04] <mfg> well, the old probe probes from the start each time, so it never got -32 (AVERROR_EOF) [01:16:12] <mfg> The new way, however, does get eof. [01:16:34] <mfg> so I just need to lower the required score when we're at the end of file (like we do at PROBE_BUF_MAX) [01:16:48] <janneg> mplayer's demuxer is worse. it seems to be stuck in an infinite loop [01:18:52] <Yuvi> janneg: more info? (works for me) [01:19:02] <Yuvi> on how it was created + source [01:20:15] <janneg> Yuvi: ffmpeg -i file.avi -acodec copy -vcodec copy file.mkv [01:20:16] <mfg> I'll repost patch in a few minutes [01:20:21] <CIA-92> ffmpeg: mru * r22366 /trunk/libavutil/ (intmath.h common.h): [01:20:21] <CIA-92> ffmpeg: Fix build on configurations without fast av_log2() [01:20:21] <CIA-92> ffmpeg: This is a bit hackish. I will try to think of something nicer, but [01:20:21] <CIA-92> ffmpeg: this will do for now. [01:21:15] <CIA-92> ffmpeg: daniel * r22367 /trunk/libavcodec/avcodec.h: Bump avcodec minor version for kgv1 decoder [01:21:50] <CIA-92> ffmpeg: bcoudurier * r22368 /trunk/libavformat/movenc.c: Correctly mark mov metadata as utf-8, using iso language code [01:24:07] <elmojo> janneg: 02_rabbit-05_08 is ready for download [01:27:06] <janneg> Yuvi: http://93.220.65.20/ [01:28:20] <janneg> first 30 seconds. can't reproduce the [matroska @ 0x19cf5b0]Unknown entry 0xB7 with that but otherwise seems to have same problem [01:29:49] <mfg> mru: sent [01:30:57] <janneg> elmojo: thanks, again, if I should limit the bandwidth scream. which one do you render now? [01:33:32] <elmojo> janneg: 03_apple-05 [01:37:53] <janneg> elmojo: updated http://www.jannau.net/bbb_videowall/. bandwidth is ok? [01:38:37] <elmojo> sure, no worries [01:39:59] <elmojo> janneg: curious, do you have a target date to get this completed? [01:43:01] <janneg> linuxtag berlin, second week of june or so [01:44:19] <janneg> we probably get another 8G quad core soon [01:49:28] <elmojo> janneg: hopefully you can fix the eyes popping out of the Owl's head... although it kinda looks cool ;) [01:54:05] <CIA-92> ffmpeg: bcoudurier * r22369 /trunk/libavformat/movenc.c: Fix encoder metadata string langcode in mov muxer [02:01:08] <mru> janneg: your mkv seems to have quite a few weird things going [02:34:00] <Yuvi> yeah, it's invalid (I thought muxers didn't have to deal with AV_NOPTS_VALUE?) [02:34:27] <mru> wild pts was one thing I noticed odd, yes [02:37:10] <Yuvi> btw, anyone happen to know why mplayer decides to use over twice the CPU when playing theora through lavc than it does with libtheora? [02:44:19] <Yuvi> decides to scale it for some reason... [02:48:34] * mru curses mingw headers [02:48:47] <mru> http://fate.multimedia.cx/index.php?stderr=197014 [02:50:33] <Yuvi> or rather, it's scaling it either way, but for lavc it apparently scales multiple times because it assumes that codecs without B frames can't have multiple references [02:52:29] <mru> wtf has that got to do with scaling? [02:53:58] <Yuvi> its direct buffer allocation fails for fftheora ("DRI failure") due to that, so it seems like it makes several additional copies of the buffer or something [02:54:24] <Yuvi> hScale_MMX2 and yuv2packedX_MMX2 triple in the profile from libtheora -> fftheora [03:47:54] <mru> ramiro: ping [04:11:16] <astrange> Yuvi: vp3_draw_horiz_band seems to call draw_horiz_band with -976 height on the second call on 1080p bbb [04:22:30] <Yuvi> astrange: oops, guess not all images are multiples of 64 [04:23:51] <Yuvi> janneg: fixed, at least in the sense that it won't generate invalid files anymore [04:24:17] <CIA-92> ffmpeg: conrad * r22370 /trunk/libavformat/matroskaenc.c: mkvenc: write dts for VFW mode [04:24:18] <CIA-92> ffmpeg: conrad * r22371 /trunk/libavformat/matroskaenc.c: mkvenc: Don't try to write packets with unknown timestamps [04:24:18] <CIA-92> ffmpeg: conrad * r22372 /trunk/libavformat/matroskaenc.c: mkvenc: Handle negative timestamps correctly [04:24:31] <Yuvi> it won't work fully until someone writes a parser to unpack packed mpeg4 bitstreams and generates pts for them [04:25:03] <ramiro> mru: pong, I'll take a look [04:47:18] <ramiro> mru: diff from the -E output with 4.2.4 and 4.4.2: http://ffmpeg.pastebin.com/YWsgABMR [04:47:28] <ramiro> that code is from stdio.h [04:48:55] <ramiro> I'm curious, what effet would sysroot have there? (I got that my binutils weren't built to support sysroot, I'd have to recompile it) [04:53:54] <ramiro> getc is defined as in http://ffmpeg.pastebin.com/VD5Cr1bM [05:06:52] <ramiro> mru: same error with binutils built with --with-sysroot and provind --syroot to ffmpeg's configure [05:10:39] <peloverde_> wonderful, bunny can't build ffmpeg [05:22:36] <Dark_Shikari> btw, astrange, I think it was you who mentioned that os x ran quicktime jailed [05:22:46] <Dark_Shikari> Said hacker has already managed to find vulns on OS X despite that [05:22:54] <Dark_Shikari> he even managed to bring down the Finder [05:23:14] <astrange> i didn't say it was very well jailed [05:23:20] <astrange> x86-64 or 32? [05:23:58] <peloverde_> does anyone know why flayer was abandoned? [05:26:24] <Dark_Shikari> astrange: x86_64 [06:10:32] <CIA-92> ffmpeg: alexc * r22373 /trunk/configure: [06:10:32] <CIA-92> ffmpeg: Add missing build dependencies for the AAC decoder caused by adding of SBR. [06:10:32] <CIA-92> ffmpeg: Patch by Georgi Chorbadzhiyski gf at unixsol dor org [06:10:58] <kshishkov> typo in word "dot" [06:11:33] <peloverde_> well I guess it's obfuscation :) [06:12:35] <CIA-92> ffmpeg: alexc * r22374 /trunk/libavcodec/aacsbr.c: [06:12:35] <CIA-92> ffmpeg: Add a missing fft.h include to the aacsbr decoder. [06:12:35] <CIA-92> ffmpeg: Patch by Georgi Chorbadzhiyski gf at unixsol dot org [06:13:10] <astrange> merged mt, that took forever... [06:13:38] <kshishkov> push it to mainline, it should take even longer :( [06:14:05] <astrange> ...i was afraid i'd have no time to do homework, but the class is canceled [06:14:11] <astrange> that solves that [06:14:38] <CIA-92> ffmpeg: alexc * r22375 /trunk/libavcodec/aacsbr.c: aacsbr: Propagate errors from read_sbr_grid to prevent crashes in malformatted streams. [06:16:01] <peloverde_> Apparently changing everything from "uint8_t" to "unsigned" makes internal state thrashing more dangerous [06:19:45] <Dark_Shikari> in what [06:19:55] <peloverde_> The SBR decoder [06:20:27] <peloverde_> random reads sbr_basepointer+random_val%256 is usually legit [06:20:52] <peloverde_> they are still things that should be fixed [06:22:30] <CIA-92> ffmpeg: alexc * r22376 /trunk/libavcodec/aacsbr.c: 10l: Include missing return values in functions made non-void by the previous commit. [06:28:16] <astrange> kshishkov: i think merging would be easier than rewriting the vp3 mt support again. enough that i'm considering doing it and working on h264 later [06:30:02] <kshishkov> sounds like an eternal work [06:32:04] <astrange> it doesn't go too slowly once problems are identified [06:33:31] <thresh> moroning [06:36:35] <Yuvi> for mt, is there much overhead in await_reference_row ? [06:42:41] <astrange> hmm, 4.3% cpu on 1080p. so yes [06:43:03] <astrange> it could be inlined and some things factored out [06:43:07] <kshishkov> try mine CPU, it will be likely 430% [06:43:15] <astrange> and if chroma/luma mvs can't be different then it only has to run for luma [06:44:20] <Yuvi> one possibility (for theora only) is to take advantage of the fact that MVs can't be longer than 16 pixels [06:44:29] <Yuvi> so you could just call it once per slice [06:44:53] <kshishkov> then they change spec and you're screwed [06:44:56] <Dark_Shikari> lol [06:45:02] <Dark_Shikari> I think if they change spec we're already screwed =p [06:45:07] <Dark_Shikari> the mv vlc coding assumes no more than 16 pixels [06:45:35] <Yuvi> yeah, if they change that they'll probably take the opportunity to change everything [06:46:56] <astrange> about the error: you added, mpegvideo codecs do all the release_buffer stuff at the start of decoding [06:47:03] <astrange> so if they have to return early it doesn't matter [06:53:22] <CIA-92> ffmpeg: conrad * r22377 /trunk/libavcodec/vp3.c: vp3: correctly clip vp3_draw_horiz_band call [06:53:34] <Dark_Shikari> Yuvi: got one of the bugs? [06:54:42] <Yuvi> Dark_Shikari: the one astrange pointed out (don't think it crashed anywhere) [06:55:01] <Yuvi> astrange: so should I change vp3 to match? [06:57:08] <astrange> well, the important thing for it is keeping halfway-decoded frames if there was an error halfway through [06:57:21] <astrange> which can be done by running the shuffle-frame stuff in error: too [06:57:32] <astrange> but this way handles that naturally [06:57:43] <Yuvi> ah, that would be needed for mt [06:58:01] <astrange> yeah, i already did it but kept the control flow the same for the normal case [06:58:11] <astrange> which is a few more lines of changes than just moving it [06:58:47] <Yuvi> vp5/6 worked for perian without the hack right? [06:59:06] <astrange> yes [06:59:35] <Yuvi> I think I'll copy that model then [07:15:22] <CIA-92> ffmpeg: kostya * r22378 /trunk/libavcodec/rv34.c: [07:15:22] <CIA-92> ffmpeg: Check for reference frames so RV 3/4 won't segfault trying to copy data from [07:15:22] <CIA-92> ffmpeg: nonexisting reference. [07:22:49] <peloverde_> superdump, ping [07:22:56] <superdump> pong [07:23:01] <peloverde_> do you remember your though process when you wrote sbr_time_freq_grid()? [07:23:22] <superdump> something like - read spec, implement [07:23:29] <superdump> :) [07:23:38] <superdump> what looks weird? [07:23:46] <kshishkov> no use of LSD or other drugs? [07:23:49] <peloverde_> There were a few interesting deviations you have that imply you know what's going on [07:24:37] <peloverde_> for isntance you know to set t_q based on bs_num_noise not num_env [07:25:41] <peloverde_> in particular when the fame class is *VAR, you clip you clip middleBorder to num_env - 1 [07:25:48] <superdump> maybe i noticed that all the q stuff was noise or something [07:26:11] <superdump> hmm [07:26:13] <superdump> i don't know [07:26:56] <peloverde_> thrashed streams can come up with large values for bs_pointer and I'm kind of curious about setting limits on it [07:27:53] <peloverde_> I wish the CT people were still around and useful [07:27:55] <superdump> i do remember looking at the middleborder table and trying to figure out the neatest way to code it [07:28:04] <kshishkov> were they ever? [07:28:36] <andoma> CT = Coding Technologies? [07:28:41] <peloverde_> yes [07:28:42] <kshishkov> yes [07:28:42] <peloverde_> they used to be very responsive on mp4-tech [07:28:44] <superdump> peloverde_: does what i wrote match the CT code or something? [07:29:04] <peloverde_> I don't know, I haven't looked at their code [07:29:09] <superdump> ah [07:29:24] <andoma> peloverde_: those were swedish right? [07:29:37] <peloverde_> sweeden and germany [07:29:39] <superdump> well, unfortunately i can't remember that far back what i was thinking when i wrote it [07:29:40] <kshishkov> superdump, it's just strange to write working code for SBR purely on spec ;) [07:29:50] <andoma> superdump: you could hunt them down :) [07:30:00] <Yuvi> Dark_Shikari: btw, it looks like all your fuzzed ogg crashes are the same one [07:30:01] <Yuvi> where something goes wrong and a pts difference of ~1<<28 is calculated, which requires that many bits to encode in the mpeg4 header [07:30:05] <superdump> andoma: hunt down my thoughts? :) [07:30:11] <kshishkov> andoma: du kan gärna hjalpa till [07:30:14] <andoma> superdump: no, the guys from CT :) [07:30:20] <superdump> kshishkov: well, i try, it's how i roll ;) [07:30:41] <superdump> true [07:30:49] <superdump> though my swedish isn't good enough yet [07:31:00] <superdump> though if they're fairly young, their english should be good :) [07:31:18] <kshishkov> recruit some locals [07:31:35] <kshishkov> you should know at least two and a half of them [07:32:18] <superdump> peloverde_: maybe i tried to 'cut out the middle man' when assigning t_q [07:32:42] <peloverde_> ok well thanks anyway [07:32:48] <superdump> i do have a vague memory of studying the logic for that bit for a while [07:32:51] <superdump> maybe i screwed up [07:33:49] <elenril> so...when are we going to throw out faad? [07:33:52] <peloverde_> the whole bs_pointer thing, that it sues seems weird... valid bs_pointer values seem to be from 1 to num_env+1, but they read it with get_bits(ceil(log2(num_env+1))) vs get_bits(ceil(log2(num_env)))+1 [07:34:15] <andoma> elenril: i guess we wanna have PS first [07:34:38] <kshishkov> andoma: not having faad aound may speed up implementing it [07:35:32] <superdump> how common is PS usage really? [07:35:40] <andoma> no idea [07:35:40] <peloverde_> (and before anyone asks you can't have zero envelopes) [07:35:48] <peloverde_> It's very common in my test files ;) [07:35:57] <superdump> :) [07:36:26] <andoma> how much to you gain with PS in terms of bitrate? [07:36:32] <kshishkov> ok, let's bury libavcodec/libfaad.c first anyway [07:39:58] <Vitor1001> kshishkov: FATE is not happy with your commit... [07:40:18] <kshishkov> Vitor1001: but trasher is ;) [07:40:47] <Vitor1001> kshishkov: Nice! I saw it was a bad sample for thrashing :) [07:41:54] <peloverde_> Ah ha! it is discussed in the 3GPP encoding annex [07:43:21] <peloverde_> I hope 3GPP adopts usac because that is the only way i will be able to understand it [07:43:52] <Vitor1001> kshishkov: But new fate results don't look correct, just a single frame repeated... [07:45:49] <kshishkov> Vitor1001: http://fate.multimedia.cx/index.php?test_result=49102464 - seems the same except for the last 3 frames missing [07:46:33] <Vitor1001> The columns don't look the same to me [07:46:47] <Vitor1001> in the left always 0x5f7a0d4f [07:46:54] <Vitor1001> in the right different values [07:48:00] <kshishkov> hmm [07:50:10] <Vitor1001> kshishkov: and with ffplay I see some stuttering after the patch that wasn't there before... [07:50:42] <kshishkov> yes, probably that was a wrong place for placing checks, I'll try to resolve it [08:08:28] <kshishkov> oh wow, somehow slice_compare() which should catch those situations is never called [08:08:35] <siretart`> good morning [08:08:44] <kshishkov> Vitor1001, can you revert my commit since it's useless? [08:08:48] <kshishkov> god morgon [08:10:56] <Dark_Shikari> is ffmpeg supposed to support Ogg metadata writing? [08:11:09] <kshishkov> according to elenril - yes [08:11:20] <Dark_Shikari> 16:07 < Anarhist> well, i put -metadata title="title here", it gets printed during the encoding process, but then ogginfo doesn't show it, and neither does information dialogue in vlc [08:13:13] <Yuvi> guess they use case-sensitive comparison [08:14:15] <Yuvi> probably they're supposed to be uppercase [08:15:48] <kshishkov> bbl and resolve that stupid RV thing [08:21:01] <CIA-92> ffmpeg: vitor * r22379 /trunk/libavcodec/rv34.c: [08:21:01] <CIA-92> ffmpeg: Revert commit 22378. [08:21:01] <CIA-92> ffmpeg: It broke FATE and kostya asked me on IRC to revert it. [08:36:16] <elenril> Dark_Shikari: no [08:36:43] <elenril> there's a patch on the ml waiting for more comments [08:40:18] <wbs> regarding burying libfaad, what features are still missing in the ff aac decoder? [08:40:23] * elenril slaps kshishkov for spreading evil lies [08:43:08] <peloverde_> wbs, because I only started working on it again in november [08:43:39] <superdump> peloverde_: that didn't seem to answer the question :) [08:44:01] <superdump> i think peloverde_ is working on PS which will enable HE AAC v2 support [08:44:07] <wbs> ah [08:44:18] <peloverde_> oh, what [08:44:22] <peloverde_> I thought it said why [08:44:38] <superdump> after that, maybe BSAC and low delay are interesting but not much else? [08:44:45] <wbs> what about downmixing? [08:44:47] <peloverde_> even after that we are still missing some rarely used features [08:44:55] <peloverde_> I'll do LTP probably because it's easy [08:44:58] <superdump> downmixing should be done outside the codec [08:45:15] <wbs> true [08:45:21] <superdump> peloverde_: i don't expect to implement everything to be honest because so much crap is uninteresting and unused [08:45:38] <superdump> implement what is used and forget the rest until it is [08:45:40] <superdump> :) [08:45:44] <peloverde_> In theory ER AAC LD inherits from ER AAC LTP [08:46:00] <peloverde_> in practice i don't think anyone uses the predictor in ER AAC LD [08:46:12] <peloverde_> and LTP with predictor set to zero is LC [08:46:13] <andoma> both LTP and SSR was in the code originally [08:46:20] <andoma> when it resided in soc [08:46:21] <superdump> could do it without and see what happens [08:46:26] <andoma> but i ripped those out [08:46:28] <superdump> the code is still in soc iirc [08:46:47] <superdump> you ifdeffed them out :) [08:47:08] <peloverde_> every once in a while people ask me about SSR [08:47:17] <superdump> and they were dropped during review because i wasn't going to fix them [08:47:19] <peloverde_> I really should ask them where tehy are getting SSR bitstreams from [08:47:49] <wbs> any of you got any interest in looking at http://roundup.ffmpeg.org/issue1695, btw? [08:47:55] <peloverde_> I added main for the sole reason that flash does main [08:48:26] <Yuvi> I saw a file using main once [08:49:19] <peloverde_> I've thought about using main with the predictor off for more agressive TNS [08:50:09] <peloverde_> as far as the AMR thing goes, it's probably a sample rate issue [08:50:31] <peloverde_> I don't think I tested the encoder at anything other than 44100 and 48000 [09:08:14] <Yuvi> heh, visually ffmpeg handles trashed oggs better than anything else [09:09:28] <astrange> with dropping broken frames? [09:09:43] <Dark_Shikari> well, it's already so bad it's hard to notice, right? ;) [09:10:02] <Yuvi> the ones too broken to do anything meaningful with, yeah [09:10:24] * pJok found that ffmpeg trashes wmv3 as well [09:10:26] <Yuvi> most everything else drops anything that has even one flipped bit [09:11:14] <Yuvi> because container crc checks are that useful ;) [09:12:21] <pJok> crc? isn't that for people who just want bitexactness? ;) [09:12:45] <bilboed-tp> Yuvi, you're trying with a fuzzer ? [09:13:10] <Yuvi> bilboed-tp: Dark_Shikari is [09:14:01] <bilboed-tp> ah right [09:14:42] <Dark_Shikari> we're fuzzing ogg before the 0.6 release [09:14:49] <Dark_Shikari> mp4 + h264 + aac is already very very fuzz-immune [09:14:55] <Dark_Shikari> 500 runs with the fuzzer on a very large file generated no crashes [09:14:59] <Dark_Shikari> ogg... almost every run crashes [09:15:34] <Yuvi> only because of the mpeg4 encoder :P [09:16:19] <Dark_Shikari> but that's because vp3 trashed the buffer anyways [09:16:32] <Dark_Shikari> also, I wonder what the cause of the infinite loops is [09:16:39] <Yuvi> which ones were infinite? [09:16:45] <Dark_Shikari> Crash: 6 9 12 13 28 38 67 69 73 82 90 91 96 106 [09:16:46] <Dark_Shikari> Infinite loop: 30 48 60 [09:16:49] <Dark_Shikari> General note: practically everything hit with the fuzzer terminates early; the decoder does not manage to ignore all the errors to reach the end of the file. [09:16:53] <Dark_Shikari> (from my logfile) [09:17:12] <bilboed-tp> as long as they don't segfault but error out properly, that's fine [09:17:34] <Yuvi> btw, could you run ogg with -f null for a bit? most of the crashes should be in mpeg4 [09:18:46] <Dark_Shikari> bilboed-tp: of course [09:18:50] <Dark_Shikari> the fuzzer only detects crashes [09:20:11] <Dark_Shikari> Yuvi: did you fix the vp3 issues? [09:20:13] <Dark_Shikari> I'm svn upping [09:22:02] <bilboed-tp> oh btw, I did a gst-ffmpeg release on sunday (so that it could go into crackbuntu lucid) but I'll be doing another one as soon as 0.6 is out. [09:22:24] <Yuvi> Dark_Shikari: the first half of those crashes are the mpeg4 one [09:22:40] <Yuvi> haven't tried every one yet though [09:23:22] <Dark_Shikari> ok, I'm running the fuzzer again [09:23:22] <siretart`> bilboed-tp: does the gst-ffmpeg release include 0.5 or trunk? [09:23:28] <Dark_Shikari> have you tried any infinite loops? [09:23:31] <bilboed-tp> siretart`, trunk [09:24:03] <bilboed-tp> siretart`, using ffmpeg svn revision 21874 [09:24:04] <siretart`> bilboed-tp: did you discuss what version the package will use in lucid? the system one or the internal copy? [09:24:04] <Yuvi> 30 crashed for me instead of inifinite looping, checking where now [09:24:23] <Dark_Shikari> oh btw, Yuvi, it would be nice if it didn't _stop_ like it does [09:24:24] <bilboed-tp> siretart`, if you don't use the internal copy (or a ffmpeg checkout with the same revision) we won't offer any support [09:24:28] <Dark_Shikari> a lot of the time ffmpeg will simply _stop_ during decoding [09:24:36] <Dark_Shikari> it doesn't do this for corrupt files of most types [09:24:37] <Dark_Shikari> Only ogg [09:24:55] <Yuvi> ffplay doesn't for me? [09:24:56] <Dark_Shikari> it's not as bad as a crash, but IMO we should avoid it if possible [09:25:00] <Yuvi> maybe I have a local patch [09:25:07] <Dark_Shikari> well, I'm already through 17 seeds with the fuzzer [09:25:09] <Dark_Shikari> 19 [09:25:10] <siretart`> bilboed-tp: well, ffmpeg 0.6 is definitly not a candidate for lucid... [09:25:11] <Dark_Shikari> 20 [09:25:15] <Dark_Shikari> on a 260MB input file [09:25:22] <Dark_Shikari> obviously, it's not decoding them at the rate of 1 per 5 seconds [09:25:22] <bilboed-tp> siretart`, too bad for lucid [09:25:25] <siretart`> yeah [09:26:16] <bilboed-tp> siretart`, I ran the regression suite for 3 days over that checkout. It seemed to be a good one [09:26:30] <bilboed-tp> siretart`, except for the crack-plane-stride screwup [09:26:53] <Yuvi> extra does 600 fps for me [09:26:59] <Dark_Shikari> Yuvi: it takes more than 5 seconds [09:27:02] <Dark_Shikari> lol [09:27:12] <Dark_Shikari> it's a 10 minute long video [09:27:28] <siretart`> bilboed-tp: you mean the internal regression suite of gst-ffmpeg compiled against ffmpeg 0.5.1, or is that a lame attempt to persuade to reconsider ffmpeg 0.6 for lucid? [09:27:38] <Yuvi> hm, true [09:27:46] <Dark_Shikari> also, 30 still infinite loops here [09:28:02] <CIA-92> ffmpeg: alexc * r22380 /trunk/libavcodec/aacsbr.c: aacsbr: Check for illegal values of bs_pointer in sbr_read_grid(). [09:28:46] <bilboed-tp> siretart`, I mean the gstreamer regression suite we run before every releases. And that was against the revision I mentionned [09:28:47] <Dark_Shikari> how do I force coredumps? [09:28:57] <bilboed-tp> siretart`, there's no lame attempt at anything behind that [09:29:12] <wbs> Dark_Shikari: ulimit -c unlimited [09:29:15] <bilboed-tp> siretart`, people want the codecs that have appeared in ffmpeg over the past year [09:29:56] <twnqx> bilboed-tp: leave it to the users to whine [09:30:17] <bilboed-tp> twnqx, no, really [09:30:26] <twnqx> yes, really [09:30:34] <bilboed-tp> users include developers [09:30:37] <Dark_Shikari> wbs: thx [09:30:39] <twnqx> it's their fault for selecting a distro that's KNOWN to be ages behind [09:30:54] <Dark_Shikari> twnqx: hey they could always have picked redhat [09:30:56] <twnqx> leave it to them to convince the distro maintainers [09:30:56] <bilboed-tp> twnqx, yah.. well.. ubuntu... what am I gonne say :) [09:30:58] <Dark_Shikari> RHEL4! [09:31:10] <bilboed-tp> Dark_Shikari, not enterprise enough :) [09:31:18] <Dark_Shikari> but it has ENTERPRISE in its name [09:31:22] <Dark_Shikari> how could it possibly not be enterprise [09:31:26] <Dark_Shikari> _ENTERPRISE_ linux! [09:31:26] <twnqx> RHEL is pretty nice [09:31:29] <bilboed-tp> Dark_Shikari, too recent :) [09:31:33] <Dark_Shikari> RHEL4 is recent? [09:31:36] <twnqx> at least you get support on it for all the commercial apps [09:31:42] <Dark_Shikari> I'm pretty sure they used RHEL4 in ancient egypt [09:31:45] <bilboed-tp> Dark_Shikari, I might have missed the <sarcasm> tag :) [09:31:58] <Dark_Shikari> the pharaoh sent his order to chase down the jews via a "write" command in his RHEL4 terminal [09:32:04] <twnqx> lol [09:32:21] * twnqx installed some RHEL4U5 or so last year :P [09:32:43] <bilboed-tp> :) [09:33:22] <twnqx> i tried to compile some drivers for a comemrcial hardware/software thingy on gentoo with 2.6.33rc recently [09:33:25] <twnqx> utter fail :P [09:33:40] <Dark_Shikari> >gentoo [09:33:42] <Dark_Shikari> there's your problem [09:34:02] <twnqx> no [09:34:07] <Dark_Shikari> or equally [09:34:09] <Dark_Shikari> >commercial [09:34:10] <twnqx> * W i n D r i v e r [09:34:10] <twnqx> * ================= [09:34:10] <twnqx> * [09:34:10] <twnqx> * FOR DETAILS ON THE WinDriver FUNCTIONS, PLEASE SEE THE WinDriver MANUAL [09:34:10] <twnqx> * OR INCLUDED HELP FILES. [09:34:11] <Dark_Shikari> there's your problem [09:34:13] <twnqx> THAT'S the problem [09:34:20] <twnqx> they use a windriver wrapper >_> [09:34:51] <Dark_Shikari> Yuvi: oh, now this is interesting. my version compiled with disable-optimizatioons doesn't infinite loop [09:35:00] <siretart`> bilboed-tp: I've just checked, slomo builds the packages against the system ffmpeg package [09:35:22] <Dark_Shikari> ... wait a minute. I can't replicate it? wtf? [09:35:43] <twnqx> yey, your computer became non-deterministic! [09:35:49] <Dark_Shikari> lol, I have an ffmpeg running right now [09:35:50] <Dark_Shikari> locked up [09:35:50] <twnqx> next step: self-awareness [09:35:52] <bilboed-tp> siretart`, yah, that's why we don't offer any support for debian/ubuntu users and let distro maintainers handle that [09:35:55] <Dark_Shikari> and I ran the ffmpeg_g, with th SAME COMMAND [09:35:56] <Dark_Shikari> and it didn't lock up [09:36:20] <siretart`> bilboed-tp: ah fine, I'll then redirect all crashers to slomo. great. [09:36:40] <bilboed-tp> siretart`, who will then take great pleasure in closing them [09:37:26] <Yuvi> I got an infinite loop after hiding the crash, hmm [09:37:32] <bilboed-tp> siretart`, oh, and to add more fun... there's a decent chance it won't compile against 0.5.1 :) [09:38:17] <Yuvi> (http://pastebin.ca/1829683) [09:38:18] <Dark_Shikari> Yuvi: what do you mean? [09:38:24] <siretart`> bilboed-tp: fun. what internals is gst-ffmpeg abusing this time? [09:38:34] <Yuvi> with that patch to hackily fix the crash [09:38:50] <bilboed-tp> siretart`, we're just using API and codec ID that were added since then [09:38:53] <Yuvi> oh [09:38:56] <Yuvi> it's not locked up [09:39:07] <siretart`> bilboed-tp: https://buildd.debian.org/fetch.cgi?pkg=gstreamer0.10-ffmpeg;ver=0.10.10-1;… [09:39:10] <Yuvi> it's taking for ever in av_write_trailer [09:39:20] <Dark_Shikari> why? [09:39:22] <siretart`> bilboed-tp: that's the buildlog for the gst-ffmpeg package built against 0.5.1-1 [09:39:36] <Yuvi> because the whole issue is that timestamps are screwed up royally [09:39:50] <Yuvi> and interleave doesn't deal well with that [09:39:58] <Yuvi> av_whatever_interleave [09:40:29] <bilboed-tp> siretart`, then you disabled some stuff [09:40:37] <Dark_Shikari> Yuvi: explain? [09:40:51] <siretart`> bilboed-tp: but could you do me a favor and remove the lies from gst-ffmpeg configure script? [09:40:53] <siretart`> thanks in advance [09:40:58] <bilboed-tp> siretart`, no [09:41:32] <bilboed-tp> siretart`, I could change the "API and ABI in constant flux" to "behaviour in constant flux" [09:41:38] <bilboed-tp> siretart`, but the reasoning still stands [09:42:31] <siretart`> that would be a start. and the "there are no releases" argument remains just wrong [09:43:45] <bilboed-tp> file a bug [09:44:00] <Yuvi> Dark_Shikari: for some reason nearly all the encoded frames end up with pts/dts 0, except for a few that have a random negative pts [09:44:08] <bilboed-tp> siretart`, we can change the phrasing for the next gst-ffmpeg release which will be against 0.6 [09:44:24] <Yuvi> interleaved_write_frame buffers everything and does like a O(n^2) at the end to interleave everything (iirc) [09:44:28] <siretart`> bilboed-tp: thanks! [09:44:32] <Dark_Shikari> Yuvi: lol [09:45:42] <Dark_Shikari> is there any way tod o better than that? [09:46:08] <Yuvi> the negative pts ones get used as 32-bit unsigned somewhere, which causes the mpeg4 encoder to think it needs to use 25+ MB in the header to signal the pts difference [09:46:22] <Yuvi> which is larger than the allocated buffer [09:46:43] <Dark_Shikari> hah [09:50:42] <Dark_Shikari> Yuvi: I think you're right. the locked up ffmpeg is using up almost all the system's memory [09:54:58] <Dark_Shikari> how can I set it up so that a process that uses more than X megs of memory gets killed? [09:55:08] <kshishkov> again with ulimit [09:55:17] <Dark_Shikari> does it only apply to the current shell? [09:55:23] <kshishkov> of course [09:55:29] <kshishkov> (I think) [09:55:43] <Dark_Shikari> does it apply to sub-shells? [09:55:48] <kshishkov> it's shell builtin [09:55:54] <Dark_Shikari> do sub-shells inherit it? [09:56:03] <kshishkov> try it [09:56:18] <Dark_Shikari> where's the help? [09:56:26] <Dark_Shikari> --help, -h don't tell me what the options are [09:56:38] <kshishkov> ulimit -a [09:56:59] <Dark_Shikari> and if something hits max, it'll be killed? [09:56:59] <Dark_Shikari> or what [09:57:12] <twnqx> yes [09:57:22] <Dark_Shikari> oh, so it won't malloc-fail [09:57:23] <Dark_Shikari> it will _die_ [09:57:25] <Dark_Shikari> ok [09:57:25] <kshishkov> subshells seem to inherit it [09:57:26] <twnqx> hm [09:57:41] <twnqx> Dark_Shikari: dunno, depends :P [09:57:51] <twnqx> i _think_ brk() should fail [09:58:08] <twnqx> because malloc() is in userspace [09:58:09] <Dark_Shikari> well, I want to make it so the ffmpeg infinite loops automatically die [09:58:20] <Dark_Shikari> and thus I don't have to kill the fuzzer every few minutes [09:59:29] <twnqx> reading the brk() manpage i suspect malloc will fail. [10:00:07] <Dark_Shikari> so it won't kill the program [10:00:56] <Dark_Shikari> um. it's not working. [10:01:05] <Dark_Shikari> I set ulimit to -m 1000000 [10:01:08] <Dark_Shikari> 9865 root 20 0 5270m 5.1g 3252 R 100 87.1 0:13.95 ffmpeg [10:01:14] <Dark_Shikari> and it's malloced 5.1 gigs of memory [10:02:01] <kshishkov> try also with -v [10:02:23] <Dark_Shikari> ah. [10:03:29] <Dark_Shikari> trying that. [10:05:30] <Dark_Shikari> kshishkov: it works, but now it says "segmentation fault" [10:05:42] <Dark_Shikari> which means I have no way of knowing whether it was oomkilled or whether it actually crashed [10:05:59] <kshishkov> what's the difference in this case? [10:06:07] <Dark_Shikari> I want to distinguish infinite loops from crashes [10:06:13] <Dark_Shikari> or near-infinite loops [10:06:30] <Dark_Shikari> going to try ulimit -t now. [10:17:07] <Dark_Shikari> what would be the easiest way to write a script that automatically kill -9'd anything that went over 1g of memory according to top? [10:18:45] <kshishkov> for(;;){$v = `top -flags|grep ffmpeg|cut memory field`;if [$v -ge something] grep pid and kill it ;fi} [10:21:33] <Dark_Shikari> I wonder why the process doesn't get oomkilled by the kernel [10:25:05] <Dark_Shikari> kshishkov: -ge something? [10:25:47] <iive> Dark_Shikari: optimistic allocation? [10:26:02] <Dark_Shikari> got the rest of the commandline down pat [10:26:08] <Dark_Shikari> how do I do the greater than check? [10:26:20] <kshishkov> you know, shell builtin for comparing numbers [10:26:34] <Dark_Shikari> -ge ? [10:26:36] <CIA-92> ffmpeg: alexc * r22381 /trunk/libavcodec/aacsbr.c: aacsbr: Fail early on illegal envelope counts. [10:26:46] <Dark_Shikari> doesn't seem to be a command on bash [10:27:14] <kshishkov> it's an option to "[" command actually [10:27:18] <CIA-92> ffmpeg: alexc * r22382 /trunk/libavcodec/aacsbr.c: aacsbr: Merge sbr_time_freq_grid into read_sbr_grid (and into copy_sbr_grid). [10:27:18] <CIA-92> ffmpeg: alexc * r22383 /trunk/libavcodec/aacsbr.c: aacsbr: Move the e_a calculation from sbr_mapping() to read_sbr_grid(). [10:27:24] <KotH> Dark_Shikari: [ 1 -ge 2 ] [10:27:28] <Dark_Shikari> oh wow, that's cool [10:27:29] <KotH> Dark_Shikari: spaces are important [10:27:30] <Dark_Shikari> does it work on floats? [10:27:39] <KotH> Dark_Shikari: uhmm.. dunno, man test [10:27:55] <CIA-92> ffmpeg: alexc * r22384 /trunk/libavcodec/ (aacsbr.c sbr.h): [10:27:55] <CIA-92> ffmpeg: aacsbr: Cleanup the newly merged read_sbr_grid, eliminating several context [10:27:55] <CIA-92> ffmpeg: and some duplicate local variables. [10:28:06] <Dark_Shikari> while 1;do $v = `top -n 1 -b | grep ffmpeg | cut -c48-50`;if [ $v -ge 50.0 ] kill -9 `top -n 1 -b | grep init | cut -c1-5`;fi;sleep 1;done [10:28:11] <Dark_Shikari> it says "syntax error near unexpected token fi" [10:28:39] <kshishkov> if ... then ... fi IIRC [10:28:41] <Dark_Shikari> ah k [10:28:43] <KotH> if [..] ; then [10:28:48] <KotH> Dark_Shikari: man bash [10:28:50] <KotH> ;) [10:29:02] * kshishkov does not know shell script well among other things [10:29:18] * KotH had to learn basic shell for work [10:29:30] * KotH had to learn even php, but forgot most of it [10:29:48] <Dark_Shikari> time to test my oomkiller! [10:30:08] <kshishkov> KotH: lucky you, my work involved Java + HTML [10:30:26] <av500> kshishkov: so you are well skilled now! [10:30:28] <Dark_Shikari> you sure it isn't something like [[? [10:30:34] <Dark_Shikari> I get -bash: 0.0: command not found [10:30:37] <Dark_Shikari> when memory usage is 0.0 [10:30:49] <Dark_Shikari> i.e. if [ $v -ge 50.0 ] [10:30:50] <KotH> kshishkov: actually, i'd like to do some java again...so that i am up to date and can flame java "developers" even better ;) [10:30:55] <Dark_Shikari> where $v evaluates to 0.0 [10:31:10] <kshishkov> av500: so I'm selfunemployed now [10:31:35] <av500> KotH: write an android app :-P [10:32:10] <KotH> Dark_Shikari: [[ ]] is different from [ ] [10:32:24] <kshishkov> KotH: since Java 5 (aka 1.5) you can flame them as C++ devs too. [10:32:57] <Dark_Shikari> either way it's not working [10:33:26] <KotH> Dark_Shikari: i think test cannot deal with float values [10:33:27] <CIA-92> ffmpeg: alexc * r22385 /trunk/libavcodec/avcodec.h: Revert r22288 "Increase FF_INPUT_BUFFER_PADDING_SIZE to 64." [10:33:34] <KotH> Dark_Shikari: try bash arith functions [10:33:35] <Dark_Shikari> wow, that sucks [10:33:38] <Dark_Shikari> well I'll just round then [10:33:40] <peloverde_> It was fun while it lasted [10:34:06] <KotH> Dark_Shikari: ie something of the form $( $val < 0 ) [10:34:08] <KotH> or so [10:34:13] <KotH> no idea whether that works [10:34:21] * KotH has hardly ever done arithmetic in bash [10:34:23] <Dark_Shikari> no, it doesn't work with ints [10:34:39] <kshishkov> KotH: guess how "<" is interpreted in bash ;) [10:34:43] <Dark_Shikari> nhlmbuildserver ffmpeg # while true;do v= `top -n 1 -b | grep ffmpeg | cut -c47-48`;if [[ $v -ge 50 ]]; then kill -9 `top -n 1 -b | grep init | cut -c1-5`;fi;sleep 1;done [10:34:47] <twnqx> what's the opposite of operational? inoperational? unoperational? [10:34:49] <KotH> kshishkov: not within $() [10:34:50] <Dark_Shikari> when ffmpeg is using 41% of mem [10:34:52] <Dark_Shikari> this prints for example [10:34:53] <Dark_Shikari> -bash: 41: command not found [10:35:21] <kshishkov> strip percent sign then [10:35:23] <Dark_Shikari> er, same with [] [10:35:25] <KotH> er.. sorry, $(( )) [10:35:25] <Dark_Shikari> I did strip the % [10:35:40] <KotH> $() is command expansion [10:37:32] <KotH> Dark_Shikari: "Evaluation is done in fixed-width integers" [10:37:41] <KotH> Dark_Shikari: if you want float, use perl :) [10:40:25] <Dark_Shikari> KotH: but they are fixed width [10:40:31] <Dark_Shikari> and integers [10:40:33] <Dark_Shikari> and it is still not working [10:40:56] <KotH> i suggest to use perl [10:41:04] <KotH> bash is nice for small stuff [10:41:21] <KotH> for anything with complex string/number handling or controlflow use perl [10:41:45] <Dark_Shikari> well, I'm almost there [10:41:49] <KotH> ofc, unless you take this as an opportunity to learn bash ;) [10:41:49] <Dark_Shikari> I just need the comparator [10:41:50] <Dark_Shikari> that's it [10:41:55] <Dark_Shikari> I need if ( val > 50) [10:41:56] <Dark_Shikari> that's it [10:42:03] <Dark_Shikari> doesn't matter how [10:42:27] <KotH> if [ $val -gt 50 ] [10:42:41] <KotH> (with exactly that spacing) [10:44:15] <Dark_Shikari> if [ $v -gt 50 ]; then [10:44:17] <Dark_Shikari> like that? [10:44:29] <Dark_Shikari> doesn't work [10:44:34] <Dark_Shikari> -bash: 15: command not found [10:45:08] <KotH> o_0 [10:45:55] <KotH> attila@chise:~ # if [ 15 -gt 50 ] ;then echo gt; else echo lt; fi [10:45:55] <KotH> lt [10:45:55] <KotH> attila@chise:~ # if [ 75 -gt 50 ] ;then echo gt; else echo lt; fi [10:45:55] <KotH> gt [10:45:58] <KotH> works fine here [10:45:59] <Dark_Shikari> ;do v= `top -n 1 -b | grep ffmpeg | cut -c47-48`;if [ $v -gt 50 ]; then [10:46:16] <Dark_Shikari> try it with an _expression_ as $v [10:46:33] <KotH> attila@chise:~ # a=15; if [ $a -gt 50 ] ;then echo gt; else echo lt; fi [10:46:34] <KotH> lt [10:46:34] <KotH> attila@chise:~ # a=75; if [ $a -gt 50 ] ;then echo gt; else echo lt; fi [10:46:34] <KotH> gt [10:46:50] <Dark_Shikari> An expression [10:46:52] <Dark_Shikari> Not a number [10:47:46] <Dark_Shikari> oh. it's EVALUATING the expression [10:47:53] <Dark_Shikari> instead of using it as a number [10:47:59] <Dark_Shikari> i.e. the expression evaluates to say "15" [10:48:02] <Dark_Shikari> and then bash tries to RUN 15 [10:48:18] <KotH> i'd say you are missing a `|head -1` there [10:48:23] <KotH> a=`top -n 1 -b | grep Eterm | cut -c47-48 |head -1`;if [ $a -gt 50 ] ;then echo gt; else echo lt; fi [10:48:25] <Dark_Shikari> got it working [10:48:26] <KotH> lt [10:48:30] <Dark_Shikari> I just did [10:48:33] <Dark_Shikari> v=$(blah blah blah) [10:48:44] <Dark_Shikari> or er, wait, it's not killing it. [10:49:09] <pross-au> its shmpeg-devel [10:49:49] <Dark_Shikari> oh, my kill command faild [10:49:49] <KotH> Dark_Shikari: be aware that you will have two lines containing ffmpeg in the top output [10:49:56] <Dark_Shikari> wait, why? [10:49:59] <KotH> Dark_Shikari: one of them will be "grep ffmpeg" [10:50:04] <Dark_Shikari> LOL [10:50:25] <Dark_Shikari> how about grep ffmpeg | grep -v "grep" ? [10:50:31] <Dark_Shikari> that should work [10:50:37] <KotH> juup [10:50:46] <KotH> but why dont you use ps, but top? [10:50:51] <Dark_Shikari> no idea [10:51:09] <pross-au> psgrep [10:51:23] <KotH> or psgrep ^^' [10:51:45] <KotH> pross-au: better shmpeg-devel than animpeg-devel ;) [10:51:55] <Dark_Shikari> works now [10:52:05] <pross-au> what's ani mean? [10:52:16] <pross-au> ansimpeg-devel would be A'Okay [10:52:25] <KotH> pross-au: ever heard of these strange japanese cartoons, called anime? ;) [10:52:33] <Dark_Shikari> yay, I have a working oomkiller script [10:52:36] <Dark_Shikari> Yuvi: expect more goondess. [10:52:38] <Dark_Shikari> *goodness [10:52:46] <pross-au> Right. I was thinking of Windows animated cursors for some reason [10:55:10] <KotH> lol [11:14:36] <CIA-92> ffmpeg: alexc * r22386 /trunk/libavcodec/aacsbr.c: [11:14:36] <CIA-92> ffmpeg: aacsbr: Remove a slightly incorrect comment. [11:14:36] <CIA-92> ffmpeg: The two conditions are equivalent. [11:14:36] <CIA-92> ffmpeg: alexc * r22387 /trunk/libavcodec/aacsbr.c: aacsbr: Dead code removal. [11:38:15] <Dark_Shikari> Yuvi: 464 tests so far, no segfaults (all terminating early, so not full tests though. really more like a few dozen worth) [11:38:23] <Dark_Shikari> a dozen or so OOMkills [12:01:20] <CIA-92> libswscale: siretart * r30869 /trunk/libswscale/swscale.c: [12:01:20] <CIA-92> libswscale: Fix compilation on powerpc with --disable-altivec [12:01:20] <CIA-92> libswscale: in case altivec is disabled, even compilation of code using altivec [12:01:20] <CIA-92> libswscale: keywords or asm must be avoided. [12:02:06] <siretart`> is CIA-92 often that delayed? [12:02:12] <kshishkov> yes [12:02:30] <siretart`> :-( [12:10:43] <CIA-92> ffmpeg: pross * r22388 /trunk/configure: Enable tcp_protocol when enabling http [12:32:55] <CIA-92> ffmpeg: pross * r22389 /trunk/libavformat/bink.c: Ensure Bink demuxer returns AVERROR code when av_get_packet() fails [12:33:34] <KotH> siretart`: cia works by polling the repo [12:34:15] <kierank> you can reduce the time between polls [12:34:26] <Dark_Shikari> no, it can work on a pull basis instead of push [12:34:29] <Dark_Shikari> but only if it's set up appropriately [12:36:34] <siretart`> KotH: funny, the message was announced on #mplayerdev hours ago... [12:36:59] <Dark_Shikari> it's usually a 5 minute delay [12:37:03] <Dark_Shikari> it might be different for swscale [12:37:06] <Dark_Shikari> due to the submodule status [12:38:01] <CIA-92> ffmpeg: pross * r22390 /trunk/libavformat/mm.c: Remove static function name prefixes from American Laser Games MM demuxer [12:39:08] <KotH> siretart`: could be different polling times [12:39:26] <siretart`> or other hickups, I see [12:45:22] <KotH> siretart`: yes, alcohol might be involved too [13:51:42] <Honoome> mru: may I disturb you for a C standard question? :) given a calloc(sizeof(foo), N*M), am I allowed to address the resulting var as [x|x<N][y|y<M], or is it assuming something that might not be true? [13:53:42] <twnqx> [][] is a twodimensional array. the first would be an array of pointers [13:53:58] <mru> no it wouldn't [13:53:59] <twnqx> [] is in the end just a dereferencing operator [13:54:12] <mru> calloc returns a flat block of memory [13:54:23] <kshishkov> to address so compiler must know array dimensions [13:54:38] <mru> and sizeof() is typically passed as the second arg to calloc [13:54:45] <mru> not that it makes a difference [13:54:50] <kshishkov> so it's only [x+y*N] for you [13:54:53] <twnqx> and since calloc doesn't allocate it that way, you can't address your single allocated block as a multidimensional array [13:55:50] <andoma> I've always wondered why calloc() takes two arguments anyway.. [13:56:13] <kshishkov> andoma: same for fread() [13:56:40] <kshishkov> probably an artifact of some old record-based system [13:56:47] <Honoome> andoma: it's mostly to avoid integer overflows [13:57:21] <kshishkov> lol [13:57:23] <mru> if you int (*foo)[X] = calloc(), you can foo[x][y] [13:57:57] <Honoome> mru: okay (I did forget about the declaration of the variable, yeah one of the two dimensions is fixed) [14:30:50] <Dark_Shikari> Yuvi: ping [14:30:54] <Dark_Shikari> I got one fuzz test failure for you [14:30:55] <Dark_Shikari> 1704 [14:31:14] <Dark_Shikari> an actual segfault, not an OOM/infiniloop [14:40:27] <BBB> wbs: can you resend or retract the patches in "Use the actual RTSP peer IP [..]" so I know which one to review? I'm a little confused [14:44:01] <wbs> BBB: the one I thought should be ok is 0001 from the first series, that is, this one: http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20100308/ec1d0… [14:44:35] <wbs> BBB: the two other series are both "proposals", so you and luca can comment on which one seems less messy and acceptable to you [14:45:07] <wbs> that one at least solves the easier part of the problem; use the correct IP for the rtp sessions, which is everything that's needed for the demuxer case [14:45:58] <BBB> you can initialize peer_len when you declare it [14:46:02] <BBB> no reason to do it in a separate line [14:46:15] <wbs> ah, good point [14:47:25] <BBB> rest is ok, if it fixes the issue for localhost [14:47:44] <BBB> I need to read the rest of the thread to see what it's about [14:48:17] <wbs> ok, great, will apply that one in a second [14:51:26] <BBB> for the NTP thread, I think it should be ff_ntp_time() for now [14:51:31] <BBB> so agree with LucaA there [14:51:39] <wbs> ok, that's no problem with me [14:52:10] <BBB> let's see if Michael is ok with the metadata, can you ping the thread and ask for his opinion? I'll think about it for a little [14:52:18] <BBB> I don't directly have an opinion [14:52:22] <BBB> he might want avoptions for this also [14:52:34] <wbs> if I were to use the rtp muxers directly from a third party app, I'd need to reimplement it somewhere, but since I'm only going to use it through the RTSP muxer, it's fine with me [14:52:58] <wbs> yeah, he opted for using AVOptions for that kind of stuff (the controlname thing in SDP) on the other thread [14:53:31] <wbs> he hasn't said anything on that thread yet, but I guess he doesn't like (ab)using metadata in that way [14:58:59] <CIA-92> ffmpeg: mru * r22391 /trunk/common.mak: Remove duplicates from OBJS [14:59:00] <CIA-92> ffmpeg: mru * r22392 /trunk/subdir.mak: cosmetic: move some makefile variable definitions [14:59:01] <CIA-92> ffmpeg: mru * r22393 /trunk/subdir.mak: [14:59:01] <CIA-92> ffmpeg: Move some make rules outside of eval'd block [14:59:01] <CIA-92> ffmpeg: These rules use only global variables and thus do not need to be expanded. [14:59:04] <CIA-92> ffmpeg: mru * r22394 /trunk/ (common.mak subdir.mak): Simplify static/shared build rules [14:59:05] <CIA-92> ffmpeg: mru * r22395 /trunk/configure: configure: always write shared lib variables to config.mak [14:59:06] <CIA-92> ffmpeg: mru * r22396 /trunk/subdir.mak: Remove superflous ifdef CONFIG_{STATIC,SHARED} in makefiles [14:59:07] <CIA-92> ffmpeg: mru * r22397 /trunk/subdir.mak: [14:59:07] <CIA-92> ffmpeg: Reorder some make rules [14:59:07] <CIA-92> ffmpeg: I like it better this way. [14:59:58] <CIA-92> ffmpeg: mstorsjo * r22398 /trunk/libavformat/rtsp.c: [14:59:59] <CIA-92> ffmpeg: RTSP: Resolve and use the actual IP address of the peer we're connected to, [14:59:59] <CIA-92> ffmpeg: instead of using the original host name, since the RTP (and UDP) protocols [14:59:59] <CIA-92> ffmpeg: may choose another IP address if the host name resolves into several different [14:59:59] <CIA-92> ffmpeg: addresses. [15:07:34] * mru watches fate with caution [15:11:12] <CIA-92> ffmpeg: mru * r22399 /trunk/ (libavutil/internal.h libavutil/libm.h ffmpeg.c): (log message trimmed) [15:11:12] <CIA-92> ffmpeg: Move libm replacements to new header libm.h [15:11:12] <CIA-92> ffmpeg: ffmpeg.c uses lrintf(), which is missing on some systems. Previously [15:11:12] <CIA-92> ffmpeg: it picked up the replacement via libavutil/internal.h due to [15:11:12] <CIA-92> ffmpeg: HAVE_AV_CONFIG_H being erroneously defined. [15:11:13] <CIA-92> ffmpeg: Moving these replacements to a separate header enables ffmpeg.c to [15:11:13] <CIA-92> ffmpeg: use them without being exposed to internal interfaces. [15:11:59] <BBB> wbs: neither do I, really... which is why I held back a bit [15:14:46] <wbs> BBB: ok.. I'll have a look at AVOptions vs libavformat and see in which way it fits with this [15:17:08] <BBB> ok, thanks [15:17:19] <BBB> if you don't like it, let me know and I'll look more into it with/for you [15:17:27] <BBB> i'll just pretend I didn't see it for now ;) [15:17:30] <wbs> :-) [15:20:01] <wbs> but if passing a muxer-specific option to a muxer through AVOptions, we still would need to add a field to AVFormatContext for that option, right? [15:20:13] <CIA-92> ffmpeg: michael * r22400 /trunk/libavformat/utils.c: Add special case to avoid binary search when appending index entries. [15:20:23] <BBB> why? [15:21:54] <wbs> or how would we access the value set through AVOptions from the RTP muxer? (I'm talking about the ntp start time case here) [15:25:38] <jez9999> BBB: grr you changed rtsp.c all around :-) [15:25:47] <BBB> huh? [15:25:50] <jez9999> now i have to totally modify my patch.... if it even becomes relevant [15:26:19] <BBB> well first they complain the project isn't developing, and now we add all this new cool stuff and he still complains! [15:26:36] <wbs> jez9999: I guess most of the changes are done by me, not by BBB ;P [15:26:46] <BBB> true [15:26:54] <jez9999> ff_url_join [15:26:57] <wbs> that's me [15:26:58] <jez9999> overkill... [15:27:07] <jez9999> i was handily tacking stuff onto the string with snprintf() before [15:27:18] <wbs> yes, did you read the discussion on ffmpeg-devel? [15:27:26] <jez9999> nope [15:27:29] <BBB> jez9999: the chance of forgetting the [] is smaller with ff_url_join than with snprintf [15:28:16] <BBB> most importantly, it's not speed-critical, so "who cares", basiclly [15:28:32] <BBB> if it was a decoder in inner loops I would've agreed with you that it's overkill [15:28:34] <jez9999> i guess "?localport=%d&ttl=%d",... still functions like snprintf [15:29:04] <jez9999> i need to optionally tack on '&sourceaddr=xxx&sourceaddr=xxx' [15:29:06] <wbs> yes, that part is still a free-form format string [15:30:40] <jez9999> and god curse the person who dreampt up windows line endings [15:30:54] <jez9999> every single damn time i diff it feels like i have to go back and convert line endings [15:31:14] <wbs> well, at least that can't be blamed on me. ;P [15:53:14] <wbs> BBB: since I'm spamming you with quite a bit of things to review - ok to apply the patch for using rt->control_uri consequently instead of s->filename? [15:53:36] <BBB> for the RTP demuxer, you only changed it in teardown, right? [15:53:39] <BBB> or what was it again? [15:53:41] <wbs> yep [15:53:45] <BBB> that's ok [15:54:17] <BBB> the rtp muxer bits are ok if you feel they're ok; make sure you actually set rt->control_uri in the muxer or that it is set in the demuxer code somewhere called in the uxer, I didn't check that [15:57:07] <CIA-92> ffmpeg: mru * r22401 /trunk/ (common.mak libavcodec/Makefile): Prettify make output when generating headers [15:57:07] <CIA-92> ffmpeg: mru * r22402 /trunk/libavcodec/tableprint.c: [15:57:07] <CIA-92> ffmpeg: Replace some printf() with puts() in tableprint.c [15:57:07] <CIA-92> ffmpeg: This gets rid of a gcc warning about non-literal format strings. [16:04:44] <wbs> BBB: yes, it's initialized by the common code path [16:05:31] <CIA-92> ffmpeg: mstorsjo * r22403 /trunk/libavformat/ (rtsp.c rtspenc.c): Use rt->control_uri consequently instead of s->filename in all RTSP commands [16:06:57] <wbs> I guess trivial things like http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20100308/662f9… can be applied straight away without a review on the list, too [16:11:09] * mru curses [16:11:59] <av500> sure, but who [16:14:55] <Honoome> termcap! [16:18:49] <CIA-92> ffmpeg: mru * r22404 /trunk/libavcodec/arm/ (16 files): ARM: set size of asm functions in object files [16:18:49] <CIA-92> ffmpeg: mru * r22405 /trunk/libavutil/libm.h: libm.h needs attributes.h [16:21:22] <kshishkov> hmm, r22404 seems to be a good reason to curse indeed [16:21:35] <mru> no, that one was fun [16:21:46] <kshishkov> and its reason? [16:22:01] <BBB> wbs: apply it then :) [16:22:19] <mru> various tools like to know the size of things [16:33:01] <janneg> mru: the file was the product of packed b frames in avi and ffmpeg streamcopy [16:34:17] <mru> evil [16:34:34] <janneg> Yuvi: thanks, preventing the mkv muxer from invalid files was all I reported [16:45:01] <CIA-92> ffmpeg: mstorsjo * r22406 /trunk/doc/general.texi: Docs: Place the vorbis comment properly, currently it's shown above the table [16:50:29] <BBB> how do I check out the soc repo? [16:50:41] <kshishkov> as usual one [16:50:59] <BBB> svn co svn://me@svn.mplayerhq.hu/what/who/where? [16:51:13] <kshishkov> /soc/ [16:51:37] <bilboed-tp> /why/ [16:51:38] <kshishkov> or /soc/someproject if you know its name [16:54:41] <BBB> ok, thanks [17:40:11] <CIA-92> ffmpeg: mru * r22407 /trunk/ (28 files in 7 dirs): [17:40:11] <CIA-92> ffmpeg: Replace many includes of libavutil/common.h with what is actually needed [17:40:11] <CIA-92> ffmpeg: This reduces the number of false dependencies on header files and [17:40:11] <CIA-92> ffmpeg: speeds up compilation. [17:57:31] <MrNaz_yma> good, coz compiling takes BLOODY AGES [17:57:54] <twnqx> Thu Feb 18 19:42:59 2010 >>> media-video/ffmpeg-9999-r1 [17:57:55] <twnqx> merge time: 1 minute and 42 seconds. [17:57:58] <twnqx> bloody ages? pfff [18:16:10] <mru> 1:42? that's slow [18:17:10] <Dark_Shikari> that's faster than configure on my box ;) [18:17:25] <kshishkov> mru: 6-30 mins on my boxes [18:31:04] <siretart`> mru: I think your latest commit broke mplayer's mp3lib/dct64_sse.c [18:31:35] <siretart`> mru: I think it's missing an '#include "libavutil/mem.h"' [18:31:56] <mru> so fix it [18:32:05] <kshishkov> sounds like MPlayer's problem [18:32:14] <siretart`> ok [18:32:35] <kshishkov> also it should be #include "libavcodec/mpegaudiodec.c" [18:32:45] <mru> eeeww [18:33:59] <kshishkov> mp3lib is mostly duplicated functionality anyway [18:34:45] <mru> what's a dct doing with malloc anyway? [18:35:02] <siretart`> it uses the DECLARE_ALIGNED macro [18:35:13] <mru> oh, ok [18:46:50] <ShadowJK> duplicated functionality but different performance [18:47:11] <kshishkov> yes, guess which is faster (or at least should be) [18:47:47] <ShadowJK> depends on cpu :) [19:30:57] <ramiro> shouldn't lavu/lfg.h be installed too? [20:17:08] <CIA-92> ffmpeg: alexc * r22408 /trunk/libavcodec/aacsbr.c: [20:17:08] <CIA-92> ffmpeg: aacsbr: Initialize e_a[1] to -1. [20:17:08] <CIA-92> ffmpeg: This triggers lAPrev (e_a[0]) on the first SBR frame to be -1. The spec is [20:17:08] <CIA-92> ffmpeg: somewhat ambiguous to what this value should be but this increases the accuracy [20:17:08] <CIA-92> ffmpeg: of al_sbr_e_44_1 and similar streams from 14 bits to 15 bits. [20:47:23] <CIA-92> ffmpeg: alexc * r22409 /trunk/libavcodec/ (aacsbr.c sbr.h): aacsbr: Make the previous value of bs_num_env local to read_sbr_data(). [21:29:21] <Dark_Shikari> is there a way to tell gcc that external symbol arrays don't alias each other? [21:29:30] <Dark_Shikari> ((restrict)) is for pointers only iirc [21:32:45] <CIA-92> ffmpeg: alexc * r22410 /trunk/libavcodec/aacsbr.c: aacsbr: read bs_rel_bord directly into t_env. [21:34:10] <BBB> Dark_Shikari: when I tested, restrict didn't do anything either [21:34:16] <BBB> my impression is gcc ignores all of that [21:34:23] <Dark_Shikari> supposedly it doesn't [21:34:30] <BBB> it did for me :) [21:34:38] <Dark_Shikari> hence supposedly [21:36:44] <CIA-92> ffmpeg: alexc * r22411 /trunk/libavcodec/aacsbr.c: aacsbr: Factor out the common end border case from t_q setup. [21:38:02] <BBB> Dark_Shikari: :) [21:41:27] <astrange> restrict is not very effective in gcc <4.5 [21:41:33] <astrange> and 4.5 isn't out yet [21:42:17] <BBB> the lack of vc-1 interlaced is fixed in ffmpeg-0.7.0 [21:42:28] <BBB> gnome does not suck in gnome-5.2 [21:42:46] <astrange> 4.5-svn works pretty well [21:45:14] <Honoome> BBB: kde is dead after 4.15? [21:46:50] <kierank> the lack of vc-1 interlaced is fixed in ffmpeg-0.7.0 --> vc-1 interlaced is *that* big a deal [21:47:19] <iive> kierank: message from the future? [21:47:34] <kierank> yes i know [21:47:34] <CIA-92> ffmpeg: alexc * r22412 /trunk/libavcodec/aacsbr.c: aacsbr: Cleanup read_sbr_grid and copy_sbr_grid after the recent overhaul of those functions. [21:48:32] <iive> kierank: actually it is quite easy to get vc1 interlced. you just need around 10'000 euro. [21:48:52] <kierank> well blu-ray is the only use so who cares ;) [21:49:19] <kierank> and only the PAL or the blended blu-rays too [21:49:40] <kierank> ..actually i suppose there could be 30i/30p discs too [21:50:35] <iive> yes... nobody needs it. [21:50:58] <CIA-92> ffmpeg: alexc * r22413 /trunk/libavcodec/aacsbr.c: aacsbr: Check that bs_num_env is valid before writing arrays with it as an offset. [21:51:01] <kierank> thankfully in spite of being in the dvb spec nobody uses it [21:51:43] <kierank> I'm surprised microsoft didn't make one person use it just to be the "token vc-1 user" [21:53:02] <Honoome> kierank: they did, but they just photoshopped it away [21:53:24] <iive> i bet kostya could do it for less, in case it is condition for obtaining his dream work (place) [21:54:51] <kierank> Honoome: lol [21:58:28] <Dark_Shikari> actually, are external symbols guaranteed by C not to overlap? [21:58:34] <Dark_Shikari> i.e. external arrays of constant size [22:04:19] <Honoome> Dark_Shikari: I wouldn't bet on that [22:07:26] <Dark_Shikari> it makes sense as they're not pointers [22:07:29] <Dark_Shikari> and stack arrays can't overlap [22:11:57] <BBB> they're symbols [22:12:02] <BBB> there's no reason why they would not overlap [22:12:13] <Dark_Shikari> but they're typed symbols [22:12:19] <Dark_Shikari> i.e. x[10][2] and y[6][7] [22:12:24] <Dark_Shikari> and not pointers [22:12:33] <BBB> a symbol has no size [22:12:40] <BBB> a symbol is merely a location [22:12:51] <BBB> or in fact that's what it points to, but in effect it's just a string [22:12:54] <Dark_Shikari> but it's typed [22:13:03] <Dark_Shikari> obviously type matters, since the aliasing rules consider type [22:13:11] <BBB> correct [22:13:29] <BBB> but I think there's no difference between float[] and float*, for example [22:13:38] <BBB> if they're external symbols, both result in the same asm [22:13:40] <Dark_Shikari> what about float[][2]? [22:13:47] <Dark_Shikari> that requires a difference [22:13:50] <Dark_Shikari> due to the implicit stride [22:13:57] <BBB> yes [22:14:13] <BBB> it's a 1-D array (still a symbol/pointer) with stride=x*2+y [22:14:26] <Dark_Shikari> no, it's a pointer to an array of [2] [22:14:34] <BBB> right, so a pointer [22:14:48] <Dark_Shikari> but it's a pointer to an array of X[2] not X [22:15:02] <BBB> but symbols have no such provisions [22:15:38] <BBB> there's nothing that stops me from declaring a symbol float* that starts at [0][1] [22:15:45] <BBB> it's an aliasing violation [22:15:47] <Honoome> Dark_Shikari: in C symbols aren't typed [22:15:48] <BBB> but it works in practice [22:15:53] <Dark_Shikari> BBB: I know, I'm asking about legality [22:15:54] <Dark_Shikari> in C [22:16:02] <BBB> it's legal [22:16:33] * iive calls C police. [22:16:45] <Dark_Shikari> but you said it was an aliasing violation [22:16:57] <BBB> I think that's only C99 [22:17:02] <BBB> in earlier Cs it was valid [22:42:33] <astrange> my i386 linux vm won't let me use ebp in asm [22:42:41] <astrange> i thought elf was non-pic by default? [22:44:50] <Honoome> astrange: it is, on x86… but depends what you're building and where I guess [22:47:37] <astrange> ubuntu 9.10, anything gives me "error: bp cannot be used in asm here", even with -fno-pic or -fno-PIC [22:57:10] <astrange> oh, maybe because i forgot omit-frame-pointer [23:27:41] <mru> Dark_Shikari: I can make you an object file with overlapping symbols [23:31:04] <astrange> hmm i crashed gcc lto. i wonder how to make a testcase out of that [23:31:31] <mru> btw, gcc 4.3 miscompiles gcc 4.3 for avr32 [23:31:44] <mru> makes it output invalid asm [23:31:50] <Honoome> mru: wow [23:32:44] <mru> why does everything uoti says make me want to smash his skull with something heavy? [23:33:52] <iive> because he have an ego in the size of a planet? [23:34:11] <mru> I didn't know they made planets that big [23:35:02] <iive> gas giants are big enough. btw, that was supposed to be h2g2 reference. [23:35:29] <mru> yes, I'm familiar with marvin the paranoid android [23:36:26] <Honoome> mru: don't you have to fill a questionaire on h2g2 as part of the residency paperwork for UK? </idiocy> [23:36:45] <mru> sadly not [23:36:46] <CIA-92> ffmpeg: cehoyos * r22414 /trunk/libavcodec/wmadec.c: [23:36:46] <CIA-92> ffmpeg: SIMD optimization using float_to_int16_interleave. [23:36:46] <CIA-92> ffmpeg: Patch by Zhou Zongyi, zhouzy A os D pku D edu D cn [23:36:48] <mru> nor monty python [23:37:51] <Yuvi> Dark_Shikari: yep, that's an overread in decoding coefficients [23:38:42] <CIA-92> ffmpeg: cehoyos * r22415 /trunk/libavcodec/wmadec.c: Fix indentation after r22414.

1 0

IRC log for 2010-03-08
by irc＠mansr.com 09 Mar '10

09 Mar '10

[00:00:13] <saste> and you need of course to escape as '|' is special for the shell [00:00:47] <saste> whois janneg [00:00:53] <saste> ops.. [00:01:08] <mru> janneg: careful, he's stalking you [00:01:27] <saste> ehe :-) [00:01:40] <CIA-92> ffmpeg: alexc * r22301 /trunk/libavformat/ (utils.c avformat.h): [00:01:40] <CIA-92> ffmpeg: av_find_stream_info(): Add a workaround for backwards compatible HE-AAC signaling. [00:01:40] <CIA-92> ffmpeg: The sample rate, frame size, and channel count from the container are [00:01:40] <CIA-92> ffmpeg: not reliable when backwards compatible signaling is used. [00:06:00] <janneg> saste: of course I'm doing that. ffmpeg wouldn't see the | in the filename otherwise. the complete command is "ffmpeg -i 'concat:file.avi|file2.avi' -vcodec copy -acodec copy file.mkv [00:06:04] <janneg> " [00:06:54] <saste> i suppose you checked that "concat" is compiled in [00:07:00] <saste> with ffmpeg -protocols [00:09:31] <janneg> yes, it is. does it make sense to include the frame size and rate abbreviations under -protocols? [00:09:52] <relaxed> janneg: \| works [00:10:37] <saste> janneg: no it doesn't make sense to have them listed there [00:12:25] <janneg> relaxed: no, the same error [00:13:02] <saste> janneg: what you see is what i'd expect if concat: wouldn't be compiled into ffmpeg [00:13:18] <saste> for example is what i get with 'foo:xaa|xab|xac|xad|xae|xaf|xag|xah' which I'm using for testing [00:13:36] <saste> try with concat:file.avi [00:14:28] <saste> maybe you're not invoking the right ffmpeg [00:22:53] <CIA-92> ffmpeg: stefano * r22302 /trunk/libavformat/concat.c: [00:22:53] <CIA-92> ffmpeg: Fix concat seek result. [00:22:53] <CIA-92> ffmpeg: Patch by Wolfram Gloger wmglo AT-SIGN dent.med.uni-muenchen DOT de. [00:25:25] <janneg> saste: argh, it's working now. my real command line was concat:dir1/file.avi\|dir2/file.avi [00:27:31] <saste> janneg: good [00:27:44] <saste> as for the docs patches are welcome:-) [00:27:46] <CIA-92> ffmpeg: mru * r22303 /trunk/ffserver.c: ffserver: remove bogus comment [00:27:47] <CIA-92> ffmpeg: mru * r22304 /trunk/tests/ (md5.sh regression-funcs.sh ffserver-regression.sh): [00:27:47] <CIA-92> ffmpeg: regtest: move md5sum wrappers into separate file [00:27:47] <CIA-92> ffmpeg: ffserver-regression.sh doesn't need anything else from [00:27:47] <CIA-92> ffmpeg: regression-funcs.sh, and sourcing the entire file there [00:27:48] <CIA-92> ffmpeg: breaks things. [00:27:48] <CIA-92> ffmpeg: mru * r22305 /trunk/tests/ffserver-regression.sh: Make ffserver regression test run (still fails) [00:29:20] <janneg> saste: well, I think it should work with any pathnames [00:33:05] <mru> now, will someone fix the damn thing so actually works too? [00:36:47] <saste> mru: no that's for the 1.0 release [00:41:39] <CIA-92> ffmpeg: stefano * r22306 /trunk/libavformat/concat.c: [00:41:39] <CIA-92> ffmpeg: Fix concat seeking SEEK_END case. [00:41:39] <CIA-92> ffmpeg: Patch by Wolfram Gloger wmglo ^ dent.med.uni-muenchen.de. [00:42:43] <mru> pross-au: ping [00:46:11] * BBB isn't happy about that shout-path yet [00:46:20] <BBB> I still think it does the wrong thing [00:52:28] <pross-au> Hello [00:52:52] <mru> pross-au: I'm looking at iff.c (both of them) [00:53:06] <mru> can you explain why the demuxer needs ff_cmap_read_palette() [00:53:27] <pross-au> Yes [00:53:36] <mru> or alternatively, why the decoder needs it [00:53:59] <pross-au> iff can contain RAWVIDEO or IFF_BYTERUN1 or IFF_ILBM codecs [00:54:41] <pross-au> for RAWVIDEO, we 'tack' the palette at the end of the frame [00:55:21] <pross-au> for IFF_BYTERUN1 and IFF_ILBM, the palette is passed in the extradata [00:56:07] <pross-au> the palette needs to be decoded, hence the cmap_read_palette function [00:56:44] <pross-au> i could have createed an IFF_RAWVIDEO codec, but it seemed like a waste when we already have RAWVIDEO [00:57:04] <mru> ok, I see [00:57:21] <mru> you've been naughty with prototypes, you know [00:57:28] <pross-au> Oh!? [00:57:49] <mru> lavf/iff.c has a prototype for ff_cmap_read_palette [00:58:00] <mru> it should be in a header file [00:58:55] <pross-au> which one? [00:59:13] <mru> there isn't really a good one [00:59:16] <pross-au> creating an iff.h with ONE prototype seems overkill. [00:59:18] <mru> so I'm making a new one [00:59:42] <mru> files are cheap [01:00:11] <pross-au> you're gonna set a precedent now [01:04:03] <mru> with this change I can add -Werror=missing-prototypes [01:05:39] <pross-au> nice [01:07:13] <mru> just doing a quick build test on 12 arches, then I'll commit [01:07:49] <pross-au> only 12 [01:08:23] <mru> ah, caught an error [01:15:32] <pross-au> with the new 'beautified' makefile, warnings are much more visible... [01:30:54] <mfg> so, this might seem like a silly question, but what is ea-cdata and what is FATE? Apparantly, I broke it. [01:31:24] <mru> fate is the thing you cannot escape [01:31:29] <mfg> heh, tell me about it [01:31:33] <mru> http://fate.multimedia.cx/index-v3.php [01:31:48] <mfg> ty [01:31:55] <mru> green is good, yellow is bad, red is terrible [01:33:58] <mfg> links to revision are dead. [01:34:14] <mru> yes, but I know it was that change [01:34:17] <mru> I verified it [01:34:23] <mfg> oh, i'm not disputing [01:34:31] <mfg> i just cant see what is wrong [01:35:27] <mfg> is this the dos build? [01:35:37] <mru> all builds [01:35:47] <mru> http://fate.multimedia.cx/index.php?test_result=48722030 [01:36:30] <astrange> dos and sparc failures are different [01:42:55] <mfg> ok, how long can this stay broken before you send people to kill me? [01:43:15] <mfg> I cant really get away to look until tuesday :( [01:43:38] <mru> then I might revert in the meantime [01:43:43] <mfg> ok, thats fair [01:43:48] <mfg> sorry [01:43:51] <mru> failing tests are bad [01:43:53] <mfg> no doubt [01:44:07] <mru> we built fate to catch weird stuff like this [01:44:17] <mru> nobody expects you test a patch on all that stuff [01:44:22] <mfg> :) phew [01:44:25] <mfg> I feel better now [01:44:48] <mfg> but I've bookmarked the test case, so I'll fix it soon [01:46:36] <mfg> k, bbl with a fix (again, I apologize for breaking everything) [02:36:55] <CIA-92> ffmpeg: mru * r22307 /trunk/ (libavcodec/iff.c libavcodec/iff.h libavformat/iff.c): IFF: move ff_cmap_read_palette() prototype to a header file [02:36:56] <CIA-92> ffmpeg: mru * r22308 /trunk/libavcodec/alpha/ (4 files): Alpha: move dsputil prototypes to a header file [02:36:56] <CIA-92> ffmpeg: mru * r22309 /trunk/libavcodec/arm/ (4 files): ARM: move mpegvideo prototypes to a header file [02:36:58] <CIA-92> ffmpeg: mru * r22310 /trunk/libavcodec/ (4 files in 2 dirs): [02:36:58] <CIA-92> ffmpeg: bfin: fix function prototypes [02:36:58] <CIA-92> ffmpeg: Move prototypes to header files, add missing prototypes, [02:36:58] <CIA-92> ffmpeg: make some functions static. [02:36:59] <CIA-92> ffmpeg: mru * r22311 /trunk/libavcodec/sh4/ (dsputil_align.c qpel.c): sh4: fix about 1000 warnings [02:36:59] <CIA-92> ffmpeg: mru * r22312 /trunk/libavcodec/sh4/ (dsputil_sh4.h dsputil_align.c idct_sh4.c dsputil_sh4.c): sh4: move dsputil prototypes to header file [02:37:00] <CIA-92> ffmpeg: mru * r22313 /trunk/configure: [02:37:00] <CIA-92> ffmpeg: Error on missing function prototypes with gcc [02:37:01] <CIA-92> ffmpeg: This makes it an error to not have a prototype in scope for [02:37:01] <CIA-92> ffmpeg: a function with external linkage. The flag is only enabled [02:37:02] <CIA-92> ffmpeg: for gcc due to -Werror=type not working with all compilers. [03:05:26] <peloverde> Does somebody who agrees with mans's legal opinion about variable names want to second it in the HE-AAC try 5 thread? [03:06:38] <Dark_Shikari> done. [03:07:46] <Kovensky> you can patent variable names? o_O [03:07:58] <Dark_Shikari> in stupid-land, I guess [03:10:14] <peloverde> thanks [03:10:52] <peloverde> I think this means I'm ready to commit [03:26:07] <MrNaz_yma> wtf [03:26:12] <MrNaz_yma> patented variable names? [03:26:18] * MrNaz_yma patents $i [03:26:37] <ShadowJK> noooo, I'm using that one [03:26:51] <MrNaz_yma> that's fine... now pay up [03:31:01] <Dark_Shikari> I patent n. [03:32:39] <mru> http://to./32ha [03:32:46] <mru> best patent (application) ever [03:32:56] <mru> "Patent Acquisition and Assertion by a (Non-Inventor) First Party Against a Second Party " [03:32:59] <mru> aka trolling [03:34:00] <ohsix> that'd be a sneaky way to stop patent trolling [03:34:23] <Dark_Shikari> patent troll the patent trolls [03:34:26] <ShadowJK> that's a strange url [03:34:27] <Dark_Shikari> you can start an infinite recursion [03:34:34] <Dark_Shikari> ShadowJK: to. is the best url shortener ever [03:34:39] <ohsix> the people that do it disclaim that they are, someone had to have invented it! [03:42:07] <CIA-92> ffmpeg: mru * r22314 /trunk/libavfilter/defaults.c: [03:42:07] <CIA-92> ffmpeg: avfilter: make avfilter_default_free_video_buffer() static [03:42:07] <CIA-92> ffmpeg: This function is not referenced outside this file and has no [03:42:07] <CIA-92> ffmpeg: prototype. Feel free to flame if this is wrong. [03:43:09] <mru> there, that's the last of them [03:47:26] <CIA-92> ffmpeg: mru * r22315 /trunk/libavformat/ (utils.c internal.h): [03:47:26] <CIA-92> ffmpeg: Revert "Move the probe loop from av_open_input_file() into its own method" [03:47:26] <CIA-92> ffmpeg: This reverts r22296. This change made some files to fail to open. [03:47:26] <CIA-92> ffmpeg: The patch submitter has promised to investigate next week. [04:09:31] <mru> http://www.zeropaid.com/news/88284/how-will-you-get-your-internet-video-in-… [04:24:21] <peloverde> I threw up a little in my mouth when I saw the theora logo [04:34:00] <CIA-92> ffmpeg: alexc * r22316 /trunk/ (10 files in 2 dirs): [04:34:00] <CIA-92> ffmpeg: Add an HE-AAC v1 decoder. [04:34:00] <CIA-92> ffmpeg: A large portion of this code was orignally authored by Robert Swain. The rest [04:34:00] <CIA-92> ffmpeg: was written by me. Full history is available at: [04:34:00] <CIA-92> ffmpeg: svn://svn.ffmpeg.org/soc/aac-sbr [04:34:01] <CIA-92> ffmpeg: http://github.com/aconverse/ffmpeg-heaac/tree/sbr_pub [04:35:45] <elenril> \o/ [04:59:35] <pross-au> Originality, eh: http://upload.wikimedia.org/wikipedia/en/3/32/CDlogo.svg [05:05:19] <CIA-92> ffmpeg: alexc * r22317 /trunk/CREDITS: Add myself to CREDITS [05:59:54] <aaronl> woo, he-aac [06:03:59] <elenril> next step in world domination: -mt? [06:50:05] <CIA-92> ffmpeg: kostya * r22318 /trunk/libavcodec/ivi_common.c: [06:50:05] <CIA-92> ffmpeg: Scale tile dimensions in case both local decoding and scalability mode [06:50:05] <CIA-92> ffmpeg: are used in Indeo 5 stream. [06:50:05] <CIA-92> ffmpeg: Patch by Maxim ($indeo5dec_author) [06:50:10] <astrange> git blame --reverse is nice... [06:51:45] <astrange> well, maybe it is [06:51:45] <astrange> c72f2294 (michael 2010-02-23 23:41:11 +0000 242) int got_avcC; ///< flag used to parse avcC data only once [06:52:06] <astrange> c72f2294 doesn't touch h264.h [06:53:07] <astrange> ah, the one newer than that [06:53:21] <CIA-92> ffmpeg: kostya * r22319 /trunk/libavcodec/indeo5.c: [06:53:21] <CIA-92> ffmpeg: Make Indeo 5 decoder more robust on bitstream errors. [06:53:21] <CIA-92> ffmpeg: Patch by Maxim ($indeo5dec_author) [07:04:17] <astrange> enable-pthreads compile is broken :( [07:09:50] <Dark_Shikari> siretart or siretart` : ping [07:32:58] <superdump> peloverde: whoop! [07:33:07] <superdump> let's see how loudly michael complains.... [07:33:17] <peloverde> you did much of the work [07:33:27] <superdump> the monkey work maybe [07:33:38] <superdump> read spec a bit, write what i read, rinse and repeat [07:33:39] <peloverde> he agreed except for license conerns and "l" [07:33:42] <superdump> and get stuff wrong [07:33:46] <superdump> mmm [07:33:50] <peloverde> license concerns were debunked, and "l" was fixed [07:33:56] <superdump> license concerns? you mean about the names of variables? [07:33:59] <peloverde> yeah [07:34:03] <superdump> :) [07:34:18] <superdump> (i have been following every message in the thread, i just haven't commented) [07:34:34] <superdump> if i'd had something worth saying i'd have said it [07:34:47] <peloverde> if you know about the msb/usb stuff feel free to chime in [07:34:49] <Dark_Shikari> the variable names thing made me lol [07:35:18] <superdump> peloverde: i think i did before, i remember suggesting somewhere that it was upper subband and master subband or something [07:35:22] <superdump> and at that time you agreed [07:35:51] <superdump> but indeed there is no description in the spec, hence why i kept the names in case we figured out what they meant at some point [07:36:16] <superdump> i'm a little torn with the 'useful semantically obvious name' versus 'the variable name in the spec' [07:36:48] <peloverde> I added comments to about half the context variables but kept the names [07:36:49] <superdump> i found myself looking up in the 'glossary' wtf some things were [07:36:52] <Dark_Shikari> you can do both [07:36:53] <superdump> in the spec [07:36:54] <Dark_Shikari> i.e. [07:37:00] <Dark_Shikari> int useful_name; //stupid_spec_name [07:37:12] <superdump> or vice versa [07:37:27] <superdump> though useful_name is probably better to see in the code to be fair [07:37:34] <peloverde> also, the spec has certain naming conventions that once you learn allow things to make more sense [07:37:35] <superdump> well, i dunno [07:37:38] <superdump> it's difficult :) [07:37:48] <peloverde> like q_ means noise, e_ means enveleope [07:37:48] <superdump> on one hand there's ease of comprehension [07:38:07] <superdump> on the other there's quick referencing in the spec [07:38:51] <peloverde> for an encoder, I'd certainly want meaningful names [07:39:53] <astrange> is there an aac-experts? [07:40:25] <peloverde> there is mpam and there is mp4-tech [07:41:20] <peloverde> mpam is the official MPEG AHG on Audio Standards Maintenance reflector [07:41:38] <peloverde> mp4-tech is the mpeg4if techincal list [07:42:09] <peloverde> there used to be a bunch of super helpful CT people on mp4-tech, but they seem to have disappeared [07:42:31] <superdump> mmm [07:42:39] <superdump> maybe they consider AAC as being 'done' now [07:43:44] <peloverde> CT needed the HE-AAC licensing money much more than dolby does [07:54:06] <astrange> http://llvm.org/bugs/show_bug.cgi?id=6539 [07:59:32] <siretart`> Dark_Shikari: yes? [08:00:32] <Dark_Shikari> in the interests of making the gstreamer devs pick their arses off their chairs [08:00:36] <Dark_Shikari> I'm committing this http://pastebin.org/104787 [08:00:49] <Dark_Shikari> so, how much will this piss off the ubuntu maintainers? ;) [08:01:23] <ohsix> "patches welcome ;)" goes both ways [08:04:25] <siretart`> Dark_Shikari: have you tried talking to the gstreamer guys? at least bilboed was responsive to me. [08:05:01] <Dark_Shikari> the bug report has sat still for about a month now after I committed what they asked for (the preset api) [08:05:02] <siretart`> Dark_Shikari: in what ways are the gstreamer settings 'broken'. as in 'it doesn't work at all' or in 'the results are suboptimal'? [08:05:10] <Dark_Shikari> they haven't been updated in 5 years [08:05:14] <Dark_Shikari> we can't fix them because it would "break api" [08:05:19] <Dark_Shikari> they override x264's defaults with, by and large, nonsense [08:05:29] <Dark_Shikari> same status ffmpeg had [08:05:36] <siretart`> and you think this change would make them act? [08:05:45] <superdump> Dark_Shikari: blah blah [08:05:48] <Dark_Shikari> well, and it would prevent people from accidentally using crappy settings. [08:05:51] <Dark_Shikari> same as with ffmpeg. [08:06:04] <superdump> i spoke to some of the gst devs and they said changing the bools to ints should be ok [08:06:06] <Dark_Shikari> on an unrelated note, the latest email to ffmpeg-devel is hilarious. [08:06:12] <Dark_Shikari> superdump: I'm talking about changing the defaults [08:06:12] <siretart`> anyway, right now seems a good time to make such a change, as it won't get into lucid anywyas.. [08:06:22] <Dark_Shikari> bools->ints is minor [08:06:23] <superdump> changing defaults to improve quality has precedent [08:06:25] <superdump> i said that [08:06:34] <Dark_Shikari> even if it changes the default compatibility? [08:06:39] <Dark_Shikari> i.e. to high profile instead of baseline+cabac [08:06:51] <superdump> baseline + cabac -> main [08:06:59] <superdump> we can discuss that [08:07:14] <Dark_Shikari> then let's do it. [08:07:24] <superdump> we can at least make it output decent quality by default even if the defaults don't match x264 [08:07:34] <Dark_Shikari> Let's make them match x264's. [08:08:04] <superdump> we can try to do that, but maybe some will be objectionable [08:08:06] <superdump> we'll see [08:08:06] <Dark_Shikari> making 5% of users update their settings is justified by improving it for the other 95%. [08:08:18] <superdump> if you can make a patch, it would be appreciated [08:08:32] <Dark_Shikari> I don't even have a system to test gstreamer on [08:08:38] <Dark_Shikari> I don't have gui access to any linux box [08:08:57] <ohsix> vmware? [08:09:04] <siretart`> why do you argue then so strongly about gstreamer at all then? [08:09:07] <Dark_Shikari> linux ran bad enough on my laptop outside of a VM [08:09:17] <Dark_Shikari> siretart`: because we are in part responsible for the major programs that use x264 [08:09:21] <Dark_Shikari> if they make x264 suck, it damages us [08:09:52] <ohsix> heh is that supposed to be some sort of final statement on linux? vmware will run completely different in any regard to your laptop [08:10:02] <Dark_Shikari> ohsix: no, I'm saying I have an ATI graphics card [08:10:16] <siretart`> bitching very vocally against an downstream or upstream is not going to improve the relationship [08:10:17] <Dark_Shikari> I have ubuntu installed, it just doesn't work with my LAN, my wireless, or graphics [08:10:26] <Dark_Shikari> siretart`: it worked with ffmpeg. [08:10:32] <siretart`> ffmpeg is special [08:10:36] <Dark_Shikari> troll-driven development [08:10:43] <ohsix> vmware has a "VMWare II VGA" card; linux likes it [08:10:57] <Dark_Shikari> hmm, I actually should try vmware, it would be nice to have a linux gui handy. [08:11:05] <ohsix> its really nice [08:11:20] <ohsix> for keeping different versions of windows too; and snapshots to unfuck stuff [08:11:34] <superdump> Dark_Shikari: then code blindly, spam me the changes and i'll try it when i get time [08:11:54] <superdump> even if you do that i can see better what is _wrong_ with respect to x264 [08:11:55] <Dark_Shikari> superdump: ok, but let's pick a soultion first [08:12:00] <superdump> it's a starting point [08:12:07] <Dark_Shikari> the solutions I can see: [08:12:16] <Dark_Shikari> 1) least preferable: sync the gstreamer defaults up to x264 [08:12:29] <Dark_Shikari> 2) preferable option 1: have a DEFAULT option which doesn't set the parameter. [08:12:40] <Dark_Shikari> 3) preferable option 2: use strings and param_parse [08:13:06] <superdump> mmm [08:13:27] <ohsix> you have the most cred in your name with relation to x264, you could have just sent a patch to remove a bunch of stuff and it probably would have got applied; i dunno how gstreamers freezes work though, you might just be tilting at windmills until post release (and its been frozen for quite a while) [08:13:39] <Dark_Shikari> freeze ends very soon. [08:14:08] <ohsix> that was more in reference to the "ignored for weeks" relating to the bug [08:14:16] <Dark_Shikari> Ahh, ok [08:14:19] <superdump> not really ignored [08:14:31] <superdump> just neglected due to other shit being more important for the people involved i guess [08:14:35] <ohsix> yea [08:14:50] <superdump> i'm not actively not looking at it [08:14:52] <siretart`> I guess a bug with proper impact analysis and thorough explanation of the proposed change would help as well. - it's work to do that, though. [08:14:53] <superdump> i just have to work [08:15:10] <ohsix> it sucks, i want my bugs fixed too D: [08:15:14] <Dark_Shikari> meh. maybe once we get money we can offer bounties for these things. [08:15:25] <ohsix> the ones i've had are work i cant hope to do though [08:15:36] <KotH> moin boys and girls [08:15:41] <Dark_Shikari> you know, what I think we need is a trade system. [08:15:49] <Dark_Shikari> project A needs things fixed/added in Project B [08:15:55] <Dark_Shikari> project B needs things fixed/added in project A [08:16:09] <Dark_Shikari> trade fixes. a bug for a bug. a feature for a feature. [08:16:18] <superdump> that's just called collaboration [08:16:25] <Dark_Shikari> Yeah, but that's ignored so often :/ [08:16:26] <ohsix> theres no comparative value and rarely comparative time and effort for little things [08:16:54] <ohsix> you just need to do it and get some cred; and next time someone recognizes your name and can help with what you're asking about they'll do it [08:16:56] <superdump> if people put their egos in the drawer and try to work together constructively rather than be rigid and stubborn... [08:17:08] * ShadowJK wonders if libmp3lame and ffmpeg are still in stalemate [08:17:27] <superdump> anyway [08:17:30] * superdump works [08:17:51] <astrange> ffmpeg lame encoder hasn't been touched in my memory [08:18:09] <astrange> i wish it used the vbr presets, but i think those might be in the lame frontend [08:18:32] <ShadowJK> iirc you need to downgrade lame now? [08:19:01] <Dark_Shikari> buffer too small, etc, etc [08:19:35] <ShadowJK> yes [08:23:03] <peloverde> superdump: I explained exactly what needs to be done for AAC in constructive terms and gstreamer still calls our aac decoder broken [08:23:23] <superdump> :/ [08:23:55] <superdump> i don't remember the bugzilla ticket [08:24:16] <superdump> do you have it? [08:24:43] <Dark_Shikari> it's much easier to just call an upstream library "broken" as opposed to telling them what they need to do to fix it. [08:25:12] <Yuvi> I asked about lavf api and just got "lavf demuxers are poor quality" [08:25:20] <Yuvi> so eh [08:25:47] <Dark_Shikari> which is ironic because their demuxing/muxing libraries are quite often much worse... [08:26:10] <Dark_Shikari> but hey, it's easier to just call things broken instead of saying how to fix them. [08:26:34] <ohsix> is there an objective measure of this stuff somewhere [08:26:56] <Dark_Shikari> ohsix: cat /dev/urandom | head --bytes=1 [08:27:00] <Dark_Shikari> that's a measure of quality for a demuxer ;) [08:28:10] <Yuvi> Dark_Shikari: worse and 3x the LoC ;) [08:28:26] <Dark_Shikari> but more loc is better duh [08:28:58] <peloverde> superdump: https://bugzilla.gnome.org/show_bug.cgi?id=566250 [08:32:01] <ohsix> who's mike in there? [08:32:12] <astrange> well that is kinda pushing codec knowledge into the client [08:32:22] <astrange> maybe the parser should die if there's extradata? [08:32:28] <peloverde> "The ffmpeg AAC decoder isn't complete, and there's no way to figure out before decoding whether it will support the given stream or not. We therefore set it to NONE until it can handle the full specs." [08:33:29] <ohsix> kind of a tangent, but i've found that people generally cant reproduce things as they are on someone elses gentoo machine; so it makes things harder to test, and some people ignore it outright, not that this problem has anything to do with it [08:34:31] <peloverde> of course they conveniently don't mention in that comment that they choose to mangle the AAC frames by running the parser of them unnecessarily, and then wind up with bitstreams that signal features from profiles that no one uses [08:34:52] <Dark_Shikari> ohsix: well, that's what gentoo does [08:35:16] <ohsix> some stuff can be more insidious though; and having the software you're not testing "stable" for some definition of stable, while the bug is being looked at can help at least more quick checks and "this happens here" stuff that can help move it along [08:36:00] <ohsix> i know what gentoo does, you just cant give an up or down if you dont know if you've reproduced the environment in where the failure is exhibited with any confidence [08:36:56] <Dark_Shikari> I know, I've had the experience myself [08:37:13] <ohsix> debootstrap can give you debian/ubuntu stable/unstable on any lunix though; so its easy enough, at least for this junk; ui stuff canbe really confusing in a chroot [08:43:02] <superdump> peloverde: i pinged it at least [08:43:06] <peloverde> thanks [08:43:10] <peloverde> Has anyone looked into smart fuzzers at all? [08:43:11] <superdump> i'll nudge bilboed in a bit [08:43:16] <superdump> aha [08:43:20] <superdump> bilboed: hello :) [08:43:22] <Dark_Shikari> peloverde: I know a guy who wrote a very smart fuzzer [08:43:28] <Dark_Shikari> he's using it on quicktime to create exploits [08:43:41] <Dark_Shikari> it can automatically find bugs, and then modify the input file to create a minimal test case [08:43:48] <peloverde> I've looked at catchconv but it's brittle an unmaintained [08:44:01] <Dark_Shikari> he's already found multiple zerodays [08:44:05] <ohsix> hocevar has zzuf and that other guy (name forthcoming) has one too [08:44:08] <CIA-92> ffmpeg: benoit * r22320 /trunk/libavcodec/targaenc.c: [08:44:08] <CIA-92> ffmpeg: targeenc: fix rgb555 encoding on big endian systems. [08:44:08] <CIA-92> ffmpeg: Patch by Alexis Ballier gmail_address(name, surname) [08:44:11] <peloverde> now that the AAC decoder seems immune to zzuf, smart fuzzing seems to be the next step [08:44:24] <Dark_Shikari> I can harass him to try his smart fuzzer on ffmpeg at some point [08:44:38] <Dark_Shikari> he's apparently going to try to add a feature to automatically attempt creation of exploits [08:44:53] <KotH> peloverde: what's smart fuzzing? [08:45:43] <peloverde> KotH, a smart fuzzer observes a programs control flow and then specifically fuzzes a stream to fuck with it [08:46:27] <bilboed> Dark_Shikari, is that fuzzer available somewhere ? [08:46:34] <Dark_Shikari> bilboed: he hasn't open sourced it, but I could ask him for it [08:46:42] <Dark_Shikari> he probably won't give it away publicly but who knows [08:46:49] <Dark_Shikari> he found an utterly hysterical exploit in quicktime [08:46:49] <peloverde> So if the program takes branch A, the smart fuzzer would adjust the input to make it take B [08:46:53] <Dark_Shikari> that requires only 3 bytes of data [08:46:58] <ohsix> http://lcamtuf.coredump.cx/ tmin + bunny for fuzzing from this guy [08:48:21] <ohsix> heh, blurb for bunny: Uses compiler-level integration to seamlessly inject precise and reliable instrumentation hooks into the traced program. These hooks enable the fuzzer to receive real-time feedback on changes to the function call path, call parameters, and return values in response to variations in input data. [08:48:34] <astrange> quicktime runs jailed in most situations on 10.6 [08:48:48] <astrange> probably not protected (besides stack guards) on windows which has much more marketshare, of course [08:48:53] <Dark_Shikari> astrange: exactly [08:49:01] <Dark_Shikari> don't need to crack open OS X, just go for windows [08:49:11] <KotH> peloverde: hmm.. interesting [08:49:13] <KotH> peloverde: thanks [08:49:22] <Dark_Shikari> the primary target is really really old qt codecs [08:49:24] <Dark_Shikari> like QTVR [08:49:33] <Dark_Shikari> that haven't been updated in 20 years and are probably filled with holes [08:49:37] <astrange> i think those are actually turned off now [08:49:44] <astrange> the encoders are at least [08:49:48] <astrange> (on os x again) [08:49:49] <Dark_Shikari> encoders, sure [08:49:54] <Dark_Shikari> but decoders is all that matters [08:50:07] <superdump> peloverde: in the ticket, only mkv, mp4 and adts are discussed [08:50:27] <superdump> does the statement about adts frames stuffed into another container hold for other containers? [08:50:32] <superdump> e.g. ts and so on? [08:50:41] <superdump> if it's possible to put adts into ts [08:50:46] <peloverde> it should as long as the demuxer can chunk things into single frames [08:51:22] <superdump> so the demuxer has to strip adts headers or so? [08:51:29] <peloverde> no it doesn't need to [08:51:48] <peloverde> we always check for an ADTS header at the start of every frame [08:52:08] <superdump> what about multiple rdb per frame with all rdbs sent in one buffer? [08:52:30] <superdump> but with those buffers/chunks being contained in mkv or so [08:53:01] <peloverde> multiple RDBs depends on how the calling app works [08:53:09] <peloverde> we return the number of bytes read [08:53:24] <peloverde> so if CRC is off with multiple RDBs i think it should work [08:53:30] <peloverde> if not it's a trivial hack [08:53:47] <peloverde> I could code something up in 15 minutes [08:54:14] <peloverde> That said, I don't really multiple RDBs in the wild [08:54:22] <peloverde> I haven't gotten any complaints anyway [08:56:33] <pross-au> what is an RDB? [08:56:50] <peloverde> I saw some crazy header stuff in gstreamer that I think is for aac on openmax, I imagine if you can do that, ffmpeg's should be trivial [08:57:18] <peloverde> pross-au: Raw Data Block, it's basically one AAC frame, up to 4 RDBs can go in one ADTS frame [08:57:26] <peloverde> but most people stick with 1:1 [08:57:34] <pross-au> wilco [09:04:16] <CIA-92> ffmpeg: mstorsjo * r22321 /trunk/ (11 files in 2 dirs): [09:04:16] <CIA-92> ffmpeg: Rename url_split to ff_url_split [09:04:16] <CIA-92> ffmpeg: Since this function isn't in the public API, it should have an ff_ prefix. [09:05:51] <CIA-92> ffmpeg: mstorsjo * r22322 /trunk/libavformat/ (7 files): Reindent [09:08:29] <CIA-92> ffmpeg: mstorsjo * r22323 /trunk/libavformat/avformat.h: Add doxygen documentation for ff_url_split [11:38:01] <elenril> av500: that's your patch with asf chapters? [11:39:46] <av500> elenril: yup [11:40:42] <elenril> nice [11:40:55] * elenril should write chapters muxing for asfenc [11:41:29] <elenril> btw why don't you just use url_fskip? [11:41:44] <av500> because I am a novice ffmpeg hacker :) [11:42:02] <av500> so I just c6p code I find at other places ... [11:42:05] <av500> c&p [12:56:44] <CIA-92> ffmpeg: andoma * r22324 /trunk/libavcodec/pthread.c: Make avcodec_thread_execute2() static [12:59:01] <CIA-92> ffmpeg: andoma * r22325 /trunk/libavcodec/w32thread.c: w32thread: Make avcodec_thread_execute2() static here as well [13:14:07] <CIA-92> ffmpeg: benoit * r22326 /trunk/libavformat/ (asf.c asf.h asfdec.c): [13:14:07] <CIA-92> ffmpeg: Use ASF supports "markers" which are a name and a time stamp to create [13:14:07] <CIA-92> ffmpeg: lavf chapters. [13:14:07] <CIA-92> ffmpeg: Patch by Vladimir Pantelic pan (arobase) nt tu (dash) darmstadt de [13:50:47] <superdump> we probably need to clean up our soc stuff on the wiki [13:50:54] <superdump> i think applications opened today [13:51:04] <av500> benoit-: thx! [13:53:21] <av500> elenril: I can also take a shot at writing asf chapters... [13:54:46] <benoit-> av500: what for ? [13:59:07] <av500> [14:14] <CIA-92> ffmpeg: benoit * https://subversion/trac/avx/changeset/22326 /trunk/libavformat/ (asf.c asf.h asfdec.c): [14:04:37] <KotH> does ffmpeg support wma losless? [14:04:44] * KotH cannot find anyrefernece [14:06:55] <av500> dont think so [14:08:43] <elenril> av500: sure, go ahead [14:08:48] <elenril> should be easy [14:08:53] <av500> yes [14:22:42] <superdump> we don't have an ffmpeg page on the gsoc site for 2010 either [14:23:03] <superdump> oh [14:23:08] <superdump> maybe i was looking in the wrong place [14:45:49] <pJok> mornings [14:46:05] <KotH> afternoons [14:46:13] <kshishkov> god kvÃ€ll, tror jag [14:46:44] <wbs> kshishkov: det är väl nog bara eftermiddag ännu :-) [14:48:24] <kshishkov> wbs: ja, vi har samma tiden som FInland men det Ã€r inte sÃ¥ rolig [14:48:53] <pJok> ;) [14:49:46] * pJok grmbls about wmv3 in mov containers [14:50:04] <pJok> and swscalar complaining about it [14:50:12] <pJok> swscaler* [14:50:14] <kshishkov> jar, wmv3 i mov Ã€r hÃ¶gsta kvÃ€litat dynga [14:50:19] <mru> swscalar and swvector? [14:50:37] <mru> kshishkov: kvalitet [14:50:39] <kshishkov> swmatrix and swtensor too [14:50:46] <pJok> kshishkov, gotta love flip4mac ;) [14:51:00] <mru> matrixes and tensors are just generalised vectors [14:51:01] * pJok blames that piece of software for the wmv3 in a mov [14:51:18] <kshishkov> mru: thanks, I don't have occasions to practice my Swedish though :( [14:51:19] * mru doesn't use software with a 4 in the name [14:51:27] <pJok> just wondering why it complains about the input pixel format [14:51:39] <kshishkov> because of wrong format [14:51:54] <kshishkov> F4M actually writes WMV3-in-ASF-in-MOV [14:52:01] <kshishkov> we had a roundup issue for it [14:52:02] <mru> eew [14:52:03] <pJok> can i kick it in the shins with something? [14:52:39] <KotH> pJok: use an ICBM [14:52:45] <KotH> pJok: anything less isnt apropriate [14:53:05] <av500> kshishkov: http://www.youtube.com/view_play_list?p=1C0729201AA0A91A&search_query=collo… [14:53:17] <kshishkov> pJok: https://roundup.ffmpeg.org/issue875 [14:54:23] <kshishkov> av500: so you're finally try to learn Ukrainian? [14:54:40] <av500> :) [14:54:51] <pJok> kshishkov, i see noone bothered doing more about it, so i just need to shoot F4M then [14:54:59] <av500> no, I had to en[joy|dure] that for a week [14:55:23] <mru> enjure [14:55:27] <kshishkov> av500: and if you wonder, it's the way people speak English here (if they dare to speak it at all) [14:55:44] <av500> mru: luckily, nobody got enjured... [14:55:53] <kshishkov> pJok: either add demuxer chaining to FFmpeg or shoot F4M. Preferably both [14:56:04] <av500> kshishkov: so if I replace some words with codec speak, I can hear you? [14:56:11] <mru> injure: what sadists do [14:56:34] * pJok takes some of KotHs ICBMs and uses them on F4M [14:56:59] <kshishkov> av500: yes, just make sure it pronounces all three letters in word "the" separately ;) [14:57:17] <kshishkov> av500: or you can ask mru, I've speaked to him twice [14:57:29] <av500> he survived [14:57:47] <kshishkov> pJok: don't forget to make a collateral damage to Redmond [14:58:02] <av500> kshishkov: btw, are they popular in .ua? [14:58:45] <kshishkov> probably not, I try to avoid "popular" stuff here in order to not commit suicide [14:59:45] <pJok> kshishkov, i have special "packets" for them in store... [15:13:26] <CIA-92> ffmpeg: mstorsjo * r22327 /trunk/libavcodec/ppc/check_altivec.c: [15:13:26] <CIA-92> ffmpeg: Move the local includes below the system includes [15:13:26] <CIA-92> ffmpeg: This fixes a compilation issue on OS X 10.4, where some system headers were [15:13:26] <CIA-92> ffmpeg: included implicitly through dsputil_altivec.h (with _POSIX_C_SOURCE defined), [15:13:26] <CIA-92> ffmpeg: and other system headers included later, with _POSIX_C_SOURCE undefined at [15:13:27] <CIA-92> ffmpeg: that time. [15:13:36] <kshishkov> yay [15:13:46] <wbs> kshishkov: varsågod :-) [15:14:01] <wbs> and thanks to mru for pointing out the obvious fix ;P [15:14:03] <kshishkov> tack sÃ¥ mycket [15:14:31] * mru wonders who might look at his ffserver patch [15:15:34] <wbs> mru: I'll add my thoughts on it [15:16:04] <mru> it's practically untested btw [15:16:28] <mru> it builds and the (broken) regression test does something [15:16:31] <kshishkov> so is FFserver itself ;) [15:41:32] <superdump> mru: in response to your HE AAC thread message - maybe we should ask the Xiph guys to rewrite that hunk of code to avoid any legal problems? </blatant troll> [15:42:16] <kshishkov> or file a patent on using variables named "i" and "j" in loops [15:42:59] <BBB___> filing patent seems better [15:43:06] <superdump> :) [15:43:33] <mru> claims: [15:43:36] <mru> 1. a loop [15:43:55] <mru> 2. a loop as in (1) also comprising usage of a variable designated "i" [15:44:07] <mru> 3. a loop as in (2) containing an inner loop [15:44:14] <av500> 4. profit [15:44:16] <mru> 4. a loop as in (3) also comprising usage of a variable designated "j" [15:45:54] <kshishkov> then sue Ateme, subpoena their source code and improve x264 with it ;) [15:47:13] <kierank> subpoena dolby as well kshishkov kthx [15:48:29] * kshishkov is rather proud there's no direct translation of term "subpoena" into Ukrainian [15:50:32] <mru> kshishkov: I think the ukrainian translation involves use of a shovel [15:51:50] <kshishkov> mru: no, it expands to a longish phrase in local equivalent of Legalese [15:52:09] <av500> kshishkov: how boring [15:52:36] <kshishkov> av500: yes, this country copied German bureaucracy back in XIX century [15:54:29] <kshishkov> well, for example Ukrainian word for "central post office" is "poshtamt". Guess why even one-man queues here take at least 30 minutes to serve [15:57:27] <av500> kshishkov: here they got rid of most of the poshtamts :) [15:57:58] <kshishkov> what about the legendary job title "beamter"? [15:58:07] <av500> still to many of them .... [15:58:23] <kshishkov> effective as ever? [16:00:30] <av500> sure [16:01:13] <kshishkov> now imagine it and multiply on local ability to do everything via /dev/ass [16:03:52] * kshishkov forgot to add "happy nightmares" [16:34:11] <kierank> does latm go in anything else apart from transport streams? [16:34:49] <mru> what spec defines latm? [16:34:56] <jez9999> BBB: Hi. So, you think there's any chance of the patch for issue 1740 getting checked in? [16:36:27] <kierank> mru: 14496-3 apparently [16:36:50] <janneg> MPEG-4 Part 3 [16:37:09] <mru> then it's not tied to TS as such [16:37:36] <mru> being the obnoxious crap it is, I doubt it's used a lot though [16:37:46] <mru> aside from the few broadcasters who use it only to annoy [16:41:57] <BBB> jez9999: it fell off my radar, I replied [16:43:43] <j0sh> im having trouble with the theora depayloader [16:45:46] <j0sh> i get a lot of this http://pastie.org/859776 [16:47:06] <j0sh> theora is supposed to get most of its config info through the sdp/ftmp, but the decoder isn't making use of that, and its getting its info somewhere else (prob the rtp itself) [16:48:07] <j0sh> what i think is interesting is that even feng will print out this: [16:48:09] <j0sh> [theora @ 0x9685530]7 bits left in packet 82 [16:48:45] <j0sh> is it possible that there's a bug in the feng packetizer? [16:50:14] <j0sh> the video will play OK after a few seconds, but the first few are lost [16:52:25] <BBB> is it a live stream? [16:52:32] <BBB> it could just be you're getting incomplete packets in the beginning [16:53:09] <j0sh> not live, feng should be serving up a local file [16:53:26] <BBB> try another packetizer [16:53:28] <BBB> e.g. gstreamer [16:55:11] <j0sh> alright [16:59:05] <BBB> mru: is resolve_host() part of our public API? [16:59:11] <mru> no [16:59:12] <BBB> mru: I think not, but just checking [16:59:18] <BBB> mru: otherwise patch ok for me [16:59:22] <mru> it's under ifdef HAVE_AV_CONFIG_H [16:59:29] <BBB> (since there's no ffserver.c maintainer) [16:59:50] <BBB> and thanks for cleaning up that cruft [17:01:10] <CIA-92> ffmpeg: diego * r22328 /trunk/tools/trasher.c: [17:01:10] <CIA-92> ffmpeg: Add missing stdlib.h #include, fixes the warnings: [17:01:10] <CIA-92> ffmpeg: tools/trasher.c:44: warning: implicit declaration of function ?atoi? [17:01:10] <CIA-92> ffmpeg: tools/trasher.c:53: warning: implicit declaration of function ?abs? [17:32:59] <kierank> lol mpeg-la say they probably have patents on ogg [17:33:07] <mru> :-) [17:33:08] <kshishkov> container? [17:33:11] <mru> you asked them? [17:33:14] <kshishkov> good riddance! [17:33:16] <kierank> http://www.streamingmedia.com/article.asp?id=11746 [17:34:49] <mru> that seems to be about theora [17:35:42] <kierank> hmm yes he seems to be calling theora ogg [17:35:58] * mru nukes xiph from orbit [17:35:59] <kshishkov> what do you expect from lawyers? [17:36:05] <mru> it's xiph's fault [17:36:14] <mru> they use ogg and theora/vorbis interchangably [17:37:12] <kshishkov> and Vorbis is not that bad unlike the rest [17:37:53] <mru> vorbis could easily be made sane [17:38:11] <mru> just define a few arbitrary limits on certain elements [17:38:53] <kshishkov> BTW, how's Ghost? [17:39:03] <mru> what is ghost? [17:39:09] <kshishkov> Vorbis II [17:39:10] <mru> I've heard it mentioned a few times recently [17:39:25] <kshishkov> (quite a descriptive name, ain't it?) [17:39:36] <twnqx> no he didn't, at some point he even says "theora, the lossy video codec in the ogg..." [17:40:06] <mru> twnqx: whatever the exact wording, that article is about theora and only theora [17:40:25] <twnqx> which they consider part of the "ogg universe", which is fine with me [17:40:45] <twnqx> but yeah, i thought for a moment they really mean parts of the container could be patented [17:41:05] * twnqx wonders if indexes are patented and hence missing in ogg [17:42:42] <kshishkov> twnqx: maybe it's sanity that is patented? [18:34:19] <BBB> guys, we need a list of people willing to do consulting work on FFmpeg [18:35:50] <Compn> a list of ffmpeg mercenaries? [18:35:52] <Compn> hehe [18:35:58] <Compn> soldiers of fortune [18:37:00] <kshishkov> isn't mru enough? [18:37:13] <Compn> he only takes highest paying jobs [18:37:25] <BBB> kshishkov: do you want to do consulting? [18:37:47] <mru> BBB: it's not the first time that idea comes up [18:37:48] <kshishkov> nah, it's a hell to do any official work here [18:37:57] <BBB> mru: I know [18:38:01] <BBB> mru: hence my suggestion [18:38:21] <mru> and we shouldn't restrict it to ffmpeg development [18:39:10] <BBB> true [18:39:30] <BBB> do you want to post hourly rates? [18:39:43] * BBB is quite sure that there's huge differences [18:39:52] <mru> no, that's better to negotiate directly with clients [18:40:20] <BBB> shall I send out an email to the list so people can say "I want on this list"? [18:40:25] <mru> besides, if you need to ask about my rates, you can't afford them [18:43:40] <mru> time for another commit flood [18:43:44] <kshishkov> well, one can hire a lot of Chinese/Indian/Ukrainian workers instead ;) [18:44:05] <mru> no, that doesn't work [18:44:11] <kshishkov> and one will be extremely lucky to get desired result from them too [18:44:19] <CIA-92> ffmpeg: mru * r22329 /trunk/ (ffserver.c libavformat/os_support.c libavformat/avformat.h): [18:44:19] <CIA-92> ffmpeg: Move resolve_host() to ffserver.c [18:44:19] <CIA-92> ffmpeg: This deprecated function is only used by ffserver, yet does not have [18:44:19] <CIA-92> ffmpeg: a prototype visible there. [18:44:19] <CIA-92> ffmpeg: In the long term, ffserver should be made IPv6-aware. In the meantime, [18:44:19] <mru> parallel intelligence works like resistors [18:44:20] <CIA-92> ffmpeg: this change removes cruft from lavf and fixes some warnings in ffserver. [18:44:21] <CIA-92> ffmpeg: mru * r22330 /trunk/subdir.mak: Define HAVE_AV_CONFIG_H when building test apps [18:44:21] <CIA-92> ffmpeg: mru * r22331 /trunk/libavcodec/ (dct-test.c dctref.c dctref.h): Move dctref prototypes to a header file [18:44:22] <CIA-92> ffmpeg: mru * r22332 /trunk/subdir.mak: Define HAVE_AV_CONFIG_H for checkheaders in libs [18:44:23] <CIA-92> ffmpeg: mru * r22333 /trunk/ (Makefile common.mak): Skip cmdutils_common_opts.h fragment in checkheaders [18:44:23] <CIA-92> ffmpeg: mru * r22334 /trunk/libavcodec/dct-test.c: Remove unused fast_memcpy() function in dct-test [18:44:24] <CIA-92> ffmpeg: mru * r22335 /trunk/ (Makefile common.mak subdir.mak libavcodec/Makefile): Add TESTOBJS make variable for extra objects used by test apps [18:44:24] <CIA-92> ffmpeg: mru * r22336 /trunk/libavcodec/Makefile: Skip the tablegen fragments in checkheaders [18:44:25] <CIA-92> ffmpeg: mru * r22337 /trunk/ (8 files in 2 dirs): Add lots of missing includes [18:44:42] <kshishkov> you mean IQ of a crowd? [18:45:28] <mru> 1/IQ_group = 1/sum(IQ_individual) [18:45:39] <mru> and that's optimistic [18:45:50] <kshishkov> no, it's = 1 /min(IQ_individual) [18:45:53] <mru> often it's closer to IQ_group = IQ_min/group_size [18:46:16] <kshishkov> yes, that's true [18:46:30] <mru> adding people to a group cannot make the group as a whole smarter [18:46:53] <BBB> people, people [18:46:58] <kshishkov> but it can make it slower [18:47:14] <BBB> I wanted to suggest setting up a list of consultants for FFmpeg on the website [18:47:25] <mru> two equally smart people are certainly more productive than one [18:47:38] <mru> but they won't be able to solve problems too difficult for either of them alone [18:47:46] <mru> BBB: agree [18:48:21] <kshishkov> mru: a Russian equivalent of "great minds think alike" is "fools have the same thoughts" [18:48:46] <kshishkov> BBB: ok, now go finds consulting wannabees [18:49:12] <mru> german: zwei dumme, ein gedanke [18:50:04] <kshishkov> yes, quite the same [18:52:14] <Dark_Shikari> Yuvi: not to harass you or anything, but just curious if you've found any of those crashes or infiniteloops [18:55:30] <CIA-92> ffmpeg: mru * r22338 /trunk/libavcodec/Makefile: [18:55:30] <CIA-92> ffmpeg: Skip mpegaudio3.h in checkheaders [18:55:30] <CIA-92> ffmpeg: This unused header is a placeholder for work in progress(?). [18:55:30] <CIA-92> ffmpeg: This makes checkheaders pass again. [19:00:57] <CIA-92> ffmpeg: mru * r22339 /trunk/libavcodec/dct-test.c: ARM: fix dct-test [19:34:47] <wbs> BBB: found the rtsp control_uri case, it's 1697.. but the test urls there aren't available anymore [19:39:51] <BBB> let me see what I can find [19:55:02] <CIA-92> libswscale: reimar * r30863 /trunk/libswscale/utils.c: Fix memleak due to incorrect VirtualFree arguments: size must be 0 for MEM_RELEASE. [19:55:03] <CIA-92> libswscale: reimar * r30864 /trunk/libswscale/utils.c: Check for allocation failure for c->lumMmx2FilterCode and c->chrMmx2FilterCode. [20:00:48] <CIA-92> ffmpeg: mru * r22340 /trunk/ (3 files in 2 dirs): ARM: add some missing includes [20:18:38] <CIA-92> ffmpeg: mru * r22341 /trunk/ (Makefile common.mak libavutil/Makefile): [20:18:38] <CIA-92> ffmpeg: checkheaders: skip per-arch headers not meant for direct inclusion [20:18:38] <CIA-92> ffmpeg: Some of the per-arch headers are only meant to be used through [20:18:38] <CIA-92> ffmpeg: the parent header of the same name. Testing these standalone [20:18:38] <CIA-92> ffmpeg: does not make sense. [20:18:39] <CIA-92> ffmpeg: mru * r22342 /trunk/libavcodec/ (bfin/dsputil_bfin.h sh4/dsputil_sh4.h): Add missing includes in bfin and sh4 files [20:45:02] <BBB> peloverde: do you (want to) do contracting work? [20:45:17] <peloverde> BBB: yes [20:45:50] <BBB> ok, b/c I just recommended you and wanted to make sure I wasn't mistaken ;) [20:45:58] <BBB> add yourself to the list also [20:47:19] <peloverde> I will add myself, I was going to wait a few hours so I didn't stab others in the face with SVN merge conflicts [20:58:31] <CIA-92> ffmpeg: bcoudurier * r22343 /trunk/ (libavformat/mpegtsenc.c tests/ref/lavf/ts): 10l typo, fix ts total bit rate computation [20:59:49] <CIA-92> ffmpeg: bcoudurier * r22344 /trunk/ (libavformat/mpegtsenc.c tests/ref/lavf/ts): Start continuity counter at 0 for streams [21:01:38] <BBB> I haven't seen him on IRC for a while... [21:04:20] <Kovensky> we all miss his onjoin script don't we [21:20:44] <CIA-92> ffmpeg: mru * r22345 /trunk/ (9 files in 2 dirs): Move ff_sqrt() to libavutil/intmath.h [21:24:49] <Yuvi> Dark_Shikari: haven't fixed any yet (one appears to be a buffer overrun in mpeg4enc?) [21:27:51] <Dark_Shikari> o.0 [21:27:58] <Dark_Shikari> that's interesting, because it didn't crash in other tests [21:28:03] <Yuvi> seed 6 and 12 at least [21:28:06] <Yuvi> 9 and 12 [21:28:14] <Yuvi> 6 didn't crash for me [21:28:26] <Dark_Shikari> well I have so many seeds that are crashing that it doesn't matter if a few are missed =p [21:29:46] <CIA-92> ffmpeg: mru * r22346 /trunk/libavutil/ (attributes.h Makefile common.h): Move gcc attribute macros to new header libavutil/attributes.h [21:29:47] <CIA-92> ffmpeg: mru * r22347 /trunk/libavutil/common.h: Merge two adjacent ifdef blocks [21:29:47] <CIA-92> ffmpeg: mru * r22348 /trunk/libavutil/common.h: cosmetics: indent [21:30:41] <Yuvi> j0sh: you're writing the extradata the same way as rtpdec_vorbis ? [21:32:52] <Yuvi> Dark_Shikari: maybe it gets exposed because of how vp3.c leaks AVFrame on errors? [21:33:26] <Dark_Shikari> ahhh [21:33:29] <Dark_Shikari> yeah in fact that could be the problem [21:33:33] <Dark_Shikari> we need to fix that [21:33:38] <Dark_Shikari> it's flooding the logs with errors [21:33:45] <Dark_Shikari> and probably hiding real problems [22:08:24] <BBB> wbs: so to get the rtsp uri, you need to get a fresh session key first, did you run the command in his top post? [22:09:54] <BBB> oh wait I see it's dead [22:09:56] <BBB> let me get another uri [22:11:20] <BBB> wbs: try "rtsp://s53wm.castup.net/990310001-52.wmv?ct=US&rg=US&aid=31&st=0&ts=0&cu=B7…" [22:16:56] <CIA-92> ffmpeg: mru * r22349 /trunk/libavutil/avstring.h: More descriptive names for av_stristr() parameters [22:44:56] <CIA-92> ffmpeg: bcoudurier * r22350 /trunk/ (libavformat/mpegtsenc.c tests/ref/lavf/ts): Start continuity counter at 0 for pmt as well [23:12:12] <`md> lol bcoudurier knows about 10l? amazing [23:12:41] <mru> how so? [23:12:46] <mru> he's been around long enough [23:14:47] <`md> i guess so [23:34:40] <Dark_Shikari> ramiro: ping [23:38:29] <ramiro> Dark_Shikari: pong [23:38:55] <Dark_Shikari> ramiro: I have someone (a company) that wants help with building on windows [23:39:04] <Dark_Shikari> they want your email or some other way to contact you [23:40:13] <ramiro> hmm, if they failed to find my e-mail themselves that's bad (for me)... I should make it clearer on the website. [23:40:38] <Dark_Shikari> they might be being lazy. but you should do that anyways [23:40:44] <Dark_Shikari> also, they're a major partner of x264, so we care [23:40:57] <Dark_Shikari> (and a major user of ffmpeg, esp. on windows) [23:41:01] <Dark_Shikari> in client-side applications [23:42:49] <ramiro> I'm kind of paranoid about giving out my e-mail address so easily. it can be easily found, but I've had a personal e-mail account (msn messenger too) made unusable because I shipped the address along with ml20rc.msnfanatic.com [23:43:06] <ramiro> and that brought a horde of annoying people towards me... [23:43:15] <Dark_Shikari> makes sense [23:44:07] <ramiro> worse yet it was released prominently in a spanish language forum... [23:44:20] <Dark_Shikari> :/ [23:44:37] <ramiro> I don't even speak spanish =) [23:45:35] <mru> you speak portuguese, close enough [23:45:47] <mru> there's a simple mapping between the two [23:46:55] <CIA-92> ffmpeg: stefano * r22351 /trunk/libavformat/mpegts.c: [23:46:56] <CIA-92> ffmpeg: Replace last occurrence of the deprecated match_ext() with [23:46:56] <CIA-92> ffmpeg: av_match_ext(). [23:46:56] <CIA-92> ffmpeg: bcoudurier * r22352 /trunk/ (3 files in 3 dirs): [23:46:56] <CIA-92> ffmpeg: mpegts vbr muxing, activated when muxing rate is not supplied by the [23:46:56] <CIA-92> ffmpeg: user. [23:52:43] <CIA-92> ffmpeg: stefano * r22353 /trunk/libavformat/ (utils.c avformat.h): [23:52:43] <CIA-92> ffmpeg: Remove definition of match_ext(), which is declared under #ifdef [23:52:43] <CIA-92> ffmpeg: AV_HAVE_AVCONFIG and so not publicly declared, and currently unused. [23:59:57] <CIA-92> ffmpeg: bcoudurier * r22354 /trunk/libavformat/mpegtsenc.c: [23:59:57] <CIA-92> ffmpeg: In mpegts muxer, search for h264 aud nal, it might not be the first nal. [23:59:57] <CIA-92> ffmpeg: Improve ther error message when bitstream is malformated and tell user to use [23:59:57] <CIA-92> ffmpeg: the bitstream filter.

1 0

IRC log for 2010-03-07
by irc＠mansr.com 08 Mar '10

08 Mar '10

[02:05:53] <Yuvi> mru: OS X 10.6 hides the prototype for inet_aton with _POSIX_C_SOURCE [02:16:08] <Yuvi> it looks like only inet_ntoa is in posix? [02:21:10] <Dark_Shikari> Yuvi: found anything yet? [02:21:35] <Yuvi> for the crashes, no (since I needed ffmpeg to compile first :P) [02:22:07] <Dark_Shikari> lol [02:27:32] <CIA-92> ffmpeg: conrad * r22271 /trunk/libavformat/matroskadec.c: matroskadec: Fix a buffer overread [02:27:32] <CIA-92> ffmpeg: conrad * r22272 /trunk/libavformat/oggparsedirac.c: Fix warning about incompatible pointer types [02:35:12] <Compn> j-b : can you add t263 to h263 decoder in vlc fourcc.c ? samples > http://samples.mplayerhq.hu/V-codecs/T263/ [02:36:38] <CIA-92> ffmpeg: conrad * r22273 /trunk/libavformat/seek.c: [02:36:38] <CIA-92> ffmpeg: Add internal.h include for av_read_frame_flush prototype [02:36:38] <CIA-92> ffmpeg: Fixes build with clang [02:43:26] <Yuvi> clang being more strict with -Werror=implicit seems like it'll be prone to breakage... [03:02:27] <CIA-92> ffmpeg: conrad * r22274 /trunk/configure: [03:02:27] <CIA-92> ffmpeg: Fix clang sysroot flag [03:02:27] <CIA-92> ffmpeg: Older versions accepted both with and without an '=', but newer versions [03:02:27] <CIA-92> ffmpeg: require the '=' to be omitted [06:04:37] <CIA-92> ffmpeg: kostya * r22275 /trunk/libavcodec/ivi_common.c: [06:04:37] <CIA-92> ffmpeg: When tracking non-zero coefficients during Indeo 5 decoding, make sure [06:04:37] <CIA-92> ffmpeg: it does not ignore coefficient value = 256. [06:04:37] <CIA-92> ffmpeg: Patch by Maxim ((!min)_pole \at gmx dot/ de) [06:46:08] <superdump> i like the make output beautification [06:46:23] * kshishkov does not care much [06:54:06] <CIA-92> ffmpeg: mru * r22276 /trunk/configure: [06:54:06] <CIA-92> ffmpeg: Use -Werror=implicit only with gcc [06:54:06] <CIA-92> ffmpeg: Some other compilers turn too many warnings into errors with this flag. [06:54:58] * kshishkov wants to fix some warnings but that feeling quickly passes [08:32:42] <kshishkov> wow, FFMpeg does not compile on MacOSX/PPC [08:32:46] <kshishkov> *FFmpeg [08:33:01] <kshishkov> and FATE ignores it for two weeks too [08:35:11] <twnqx> heh [08:41:52] <kshishkov> and since I may be now the only core FFmpeg dev with such platform, tough luck for it to be fixed [08:42:09] <Yuvi> it compiles for me on 10.5 ppc? [08:42:42] <kshishkov> mine is 10.4 [08:43:35] <kshishkov> it complains about NSIG being undefined [08:53:45] <CIA-92> ffmpeg: kostya * r22277 /trunk/libavformat/rtmppkt.c: 1l trocadero: forgot reference operator on bytestream_get_be32() argument [09:14:09] <CIA-92> libswscale: stefano * r30855 /trunk/libswscale/ (yuv2rgb.c swscale_internal.h): [09:14:09] <CIA-92> libswscale: Add support to BGR444/RGB444 foreign endian output in libswscale. [09:14:09] <CIA-92> libswscale: Patch by Janusz Krzysztofik |jkrzyszt ^ tis icnet pl|. [09:14:11] <CIA-92> libswscale: stefano * r30856 /trunk/libswscale/ (utils.c swscale.c swscale_internal.h): Avoid duplication of usePal() macro. [09:26:47] <CIA-92> ffmpeg: reimar * r22278 /trunk/libavcodec/costablegen.c: [09:26:47] <CIA-92> ffmpeg: Fix --enable-hardcoded-tables compilation: the generate table files now [09:26:47] <CIA-92> ffmpeg: need to include fft.h, not dsputil.h. [11:22:12] <j-b> Compn: thanks [12:13:34] <CIA-92> ffmpeg: kostya * r22279 /trunk/libavcodec/indeo5.c: [12:13:34] <CIA-92> ffmpeg: Band quant tables should not be assigned inside band tile loop, [12:13:34] <CIA-92> ffmpeg: one time is enough. [12:13:34] <CIA-92> ffmpeg: Patch by Maxim (max_pole, gmx de) [15:41:33] <Houdini-tuxbox> Hello, make install is broken for CONFIG_SHARED with 52fb16d2c74bc608207c4f4947786757e8c8fb96 [15:41:54] <Houdini-tuxbox> install-headers doesn't exist anymore [15:41:57] <mru> what svn rev is that? [15:42:14] <Houdini-tuxbox> --- subdir.mak.orig 2010-03-07 16:34:27.000000000 +0100 [15:42:14] <Houdini-tuxbox> +++ subdir.mak 2010-03-07 16:34:44.000000000 +0100 [15:42:14] <Houdini-tuxbox> @@ -5,11 +5,12 @@ [15:42:14] <Houdini-tuxbox> LIBVERSION := $(lib$(NAME)_VERSION) [15:42:14] <Houdini-tuxbox> LIBMAJOR := $(lib$(NAME)_VERSION_MAJOR) [15:42:15] <Houdini-tuxbox> [15:42:15] <Houdini-tuxbox> +install-headers: install-lib$(NAME)-headers install-lib$(NAME)-pkgconfig [15:42:16] <Houdini-tuxbox> + [15:42:16] <Houdini-tuxbox> ifdef CONFIG_STATIC [15:42:17] <Houdini-tuxbox> all: $(SUBDIR)$(LIBNAME) [15:42:17] <Houdini-tuxbox> [15:42:18] <Houdini-tuxbox> install-libs: install-lib$(NAME)-static [15:42:18] <Houdini-tuxbox> -install-headers: install-lib$(NAME)-headers install-lib$(NAME)-pkgconfig [15:42:19] <Houdini-tuxbox> [15:42:48] <mru> what's that supposed to be? [15:42:54] <Houdini-tuxbox> hm, tag is "Split install-headers target and simplify rules" [15:43:07] <mru> which part of "svn revision" don't you understand? [15:43:33] <kshishkov> both, obviously [15:43:53] <Houdini-tuxbox> I fully understand "svn revision" [15:44:18] <mru> you just don't know how to apply that understanding to answer a simple question [15:44:45] <Houdini-tuxbox> but your web if only gives me a git view [15:45:15] <kshishkov> mru: mine is funnier - MacOSX 10.4/PPC, compiling fresh SVN libavcodec/ppc/check_altivec.c gives "/usr/include/signal.h:71: error: ‘NSIG’ undeclared here (not in a function)" [15:46:49] <Honoome> kshishkov: uh I have read that one before… [15:46:54] <Honoome> just I forgot where… [15:47:15] <CIA-92> ffmpeg: mru * r22280 /trunk/subdir.mak: 10l: fix make install with only shared libs [15:47:38] <Houdini-tuxbox> thanx [15:47:43] * mru needs to extend his buildtest script [15:48:28] <Houdini-tuxbox> it was 22243 :-) [15:49:27] <Houdini-tuxbox> have a nice sunday evening, bye [16:19:10] <twnqx> does ffmpeg's ac3 decoder support downmixing? [16:19:57] <mru> yes [16:22:28] <twnqx> cool, so if i'm requesting 2.0 from a 5.1 stream it will "do the right thing"? [16:22:32] <twnqx> nice :) [16:42:09] <roozhou> does ffmpeg's ac3 decoder support float output? [16:45:16] <kierank> you could probably make it output float if you wanted to [17:35:59] <roozhou> kierank: if i need post-processing on audio it is good to output float [17:36:40] <peloverde> roozhou, if your postprocessing code is float then it is [17:36:44] <roozhou> liba52 can output float [17:37:40] <peloverde> there is no technical reason why ffmpeg can't output float for ac3 or aac [17:38:04] <peloverde> except for nasty hacks optimizing for int16 on systems without simd float->int16 [17:39:57] <roozhou> does ffmpeg use simd float->int16? [17:40:21] <peloverde> on architectures where it is available [17:42:39] <roozhou> wmadec.c line 790: [17:42:40] <roozhou> n = s->frame_len; [17:42:40] <roozhou> incr = s->nb_channels; [17:42:40] <roozhou> for(ch = 0; ch < s->nb_channels; ch++) { [17:42:40] <roozhou> ptr = samples + ch; [17:42:41] <roozhou> iptr = s->frame_out[ch]; [17:42:41] <roozhou> for(i=0;i<n;i++) { [17:42:42] <roozhou> *ptr = av_clip_int16(lrintf(*iptr++)); [17:42:42] <roozhou> ptr += incr; [17:42:43] <roozhou> } [17:42:44] <roozhou> memmove(&s->frame_out[ch][0], &s->frame_out[ch][s->frame_len], [17:42:44] <roozhou> s->frame_len * sizeof(float)); [17:42:45] <roozhou> } [17:42:48] <roozhou> no simd at all [17:43:03] <peloverde> it's on a percodec basis [17:43:48] <peloverde> ac3dec.c:1320: s->dsp.float_to_int16_interleave(out_samples, output, 256, s->out_channels); [17:56:22] <CIA-92> ffmpeg: alexc * r22281 /trunk/libavcodec/mpeg4audio.c: [17:56:22] <CIA-92> ffmpeg: Add support for non-backwards compatible signaled parametric stereo. [17:56:22] <CIA-92> ffmpeg: This is done without breaking W6132 Annex YYYY draft MP3onMP4 which also uses AOT 29. [17:56:22] <CIA-92> ffmpeg: Samples: [17:56:22] <CIA-92> ffmpeg: http://samples.mplayerhq.hu/A-codecs/AAC/aacPlusDecoderCheckPackage_v2.1/bi… [17:56:23] <CIA-92> ffmpeg: http://samples.mplayerhq.hu/MPEG-4/mp3on4/id5_1.mp4 [18:07:12] <BBB> Vitor1001: ping [18:15:35] <BBB> Vitor1001: when you have time, could you look at http://people.gnome.org/~rbultje/graph.png and tell me what kind of math function you're thinking of when you see it? it's a 2d array in postfilter, seems like some sort of a z * (1 + log(1 + (x - ~59 / y))) for whatever values for z/y, but I couldn't really figure it out and my best tool is excel so then you know it's not gonna be much help :-p [18:16:36] <kshishkov> BBB: can you RE Indeo Audio (aka iac)? Along with Indeo4 it's the only thing missing from Intel codecs [18:16:48] <BBB> kshishkov: what type of audio is it? [18:16:51] <BBB> I'm certainly interested [18:17:00] <BBB> do you have a binary with debug symbols that runs? [18:17:05] <kshishkov> looks like MDCT from the look on it [18:17:32] <BBB> I was hoping to RE a video codec next, but I suppose a different type of audio codec is fine also :) [18:17:40] <kshishkov> no debug symbols, but iac_25.ax can be found even on MPHQ [18:18:53] <BBB> ok [18:19:37] * BBB chased vitor away :( [18:19:57] <BBB> I suppose you would have a ready-made wrapper handy for ffmpeg? [18:20:08] * BBB tries to prevent doing double work ;) [18:20:14] <kshishkov> yes, it's called MPlayer [18:20:23] <BBB> hmk, I'll write my own then [18:20:29] * BBB doesn't use mplayer [18:20:34] <kshishkov> it's standard ACM codec anyway [18:21:01] <BBB> I used objdump to convert dll to so for wmavoice [18:21:09] <BBB> then I figured out the api just by inspecting the binary [18:21:12] <BBB> made a wrapper [18:21:21] <BBB> and could link it in and run it as native code without needing any part of wine [18:21:23] <BBB> lovely [18:21:26] <BBB> gotta love objdump [18:21:42] <BBB> actually I think apple calls .so .dylib [18:21:51] * kshishkov rarely got to the point where he needed to run something because it was too problematic [18:21:58] <kshishkov> yes [18:22:07] <BBB> it's useful for ensuring bincompat [18:22:16] <BBB> or how do we call that again? [18:22:19] <BBB> bitexactness [18:22:20] <BBB> or whatever [18:23:12] <kshishkov> well, running binary decoder can be performed by different means, even gstreamer ;) [18:27:47] * BBB lets ida chew [18:28:00] <BBB> still have to finish postfilter, I think I understand about half of it now [18:28:58] <kshishkov> maybe you should just search for docs on speech codecs postfilters, I don't think they invented everything by themselves [18:31:51] <BBB> quite likely [18:32:05] <BBB> I've seen some functions copied from AMR [18:32:08] <BBB> I'll get there :) [18:34:28] * kshishkov wants to learn things about speech coding too [19:05:04] <nfl> Hi What does a negative timestamp in read_seek indicate? [19:05:53] <BBB> depends on the whence? [19:06:07] <BBB> it could e.g. mean "this much before the end of the file" [19:06:33] <kshishkov> first packets may have negative timestamps too [19:07:31] <siretart> DonDiego: hi. regarding the issue from yesterday, did you really configure with --disable-altivec? [19:08:26] <Vitor1001> BBB: can you send me the raw data? [19:08:40] <BBB> ok [19:09:46] <Vitor1001> BBB: I'll give a look [19:10:56] <peloverde> BBB, can variable names 1:1 copied in from an MPEG spec legally be used in an LGPL program? [19:11:31] <kshishkov> why not? [19:11:41] <kshishkov> it's not covered by copyrite [19:11:54] <peloverde> It wasn't my concern [19:12:22] <kshishkov> then what? [19:12:28] <peloverde> see: "[PATCH] HE-AAC v1 try 5" http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/2010-March/084391.html [19:12:34] <DonDiego> siretart: no, that was what i missed.. [19:13:09] <kierank> a lot of the x264 variable names come from the spec [19:13:11] <kshishkov> peloverde: Mans is right [19:13:14] <siretart> DonDiego: okay, anyway, it seems that my patch was posted twice because of gmane hickups.. [19:13:56] <mru> I did a ppc build yesterday with --disable-altivec [19:13:59] <mru> worked fine [19:14:00] <peloverde> kshishkov, would you mind sending something to the list to that effect? [19:14:59] <kshishkov> I don't see any need for that [19:15:10] <siretart> mru: also with swscale and runtime-cpudetect? [19:17:30] <Vitor1001> First line: [19:17:42] <mru> siretart: no [19:17:43] <Vitor1001> pow(((x+6.9)/64), 0.025) [19:18:03] <mru> siretart: runtime-cpudetect is kind of pointless if you disable all the accels though [19:18:04] <Vitor1001> BBB: second line pow(((x+6.9)/64), 0.05) [19:18:26] <kshishkov> and you can guess the rest :) [19:19:31] <Vitor1001> kshishkov: exactly [19:20:53] <siretart> mru: indeed [19:22:22] <siretart> mru: I don't think it should fail though. moreover, I'd like to avoid handling --enable-runtime-cpudetect on a per-arch basis [19:22:26] <mru> while I agree it shouldn't fail to build, it's a pointless configuration [19:22:44] <siretart> well, I don't disable all accels though [19:22:46] <siretart> just altivec [19:22:59] <mru> that's the only one on ppc [19:23:08] <BBB> Vitor1001: how did you do that? [19:23:13] <siretart> oh, if you mean that with accels, right [19:23:19] * BBB wishes excel had better functions for trendline guessing [19:23:32] <Vitor1001> openoffice + "paste special with transpose" = gnuplot input [19:23:50] <Vitor1001> all crosses in x=1, looks like f(x) = x^a [19:24:03] <Vitor1001> in gnuplot [19:24:09] <Vitor1001> f(x) = ((x-a)/b)**c [19:24:15] <Vitor1001> fit f(x) 't2.csv' using 0:1 via a,b,c [19:26:50] <CIA-92> ffmpeg: mru * r22282 /trunk/tests/ (9 files in 2 dirs): regtest: place image sequence outputs in separate directories [19:26:50] <CIA-92> ffmpeg: mru * r22283 /trunk/tests/seek-regression.sh: [19:26:50] <CIA-92> ffmpeg: regtest: run seektest on lavftest output files [19:26:50] <CIA-92> ffmpeg: Somehow this got lost in the recent overhaul. [19:28:48] <BBB> that was impressive [19:28:57] * BBB goes fit this in [19:29:06] <Vitor1001> Thanks, I was lucky :) [19:29:07] <Yuvi> DonDiego: for testing I'm using BBB 1080p, and ffmpeg -f null vs. dump_video -r modified to also not do a needless memcpy [19:39:34] <DonDiego> Yuvi: http://samples.ffmpeg.org/V-codecs/Theora/ [19:39:49] <DonDiego> http://samples.ffmpeg.org/V-codecs/Theora/WobblyWindowsIntro.ogg [19:39:52] <DonDiego> that one for example [19:40:04] <DonDiego> it ran faster with libtheora [19:40:53] <Yuvi> hm, my cpu's too fast for really meaningful benchmarks with that [19:41:03] <Yuvi> btw, is this on a cpu that doesn't support mmx? [19:41:06] <Yuvi> mmx2 [19:41:18] <mru> Yuvi: benchmark on a beagle :-) [19:41:24] <DonDiego> i used 'time mplayer -benchmark <file>' 'time mplayer -demuxer lavf -benchmark <file>' [19:41:26] <mru> seriously, you should do that [19:41:49] <DonDiego> Yuvi: yes, my K6-III does not have mmx2, just mmx and 3dnow/3dnowext [19:42:05] <Yuvi> mru: good idea [19:42:23] <DonDiego> does libtheora run on the beagle? [19:42:24] <Yuvi> DonDiego: then another problem is that we only have a mmx2 loop filter, wheras libtheora has an mmx one [19:42:34] <DonDiego> oh, ok :( [19:43:18] <DonDiego> Yuvi: sorry if i keep asking you what feels like every half hour, but what's the status of your theora and ogg work now? [19:43:19] <Yuvi> DonDiego: yeah, but it has no arm optimizations [19:43:39] <DonDiego> oh, let's publish benchmarks then ;) [19:43:47] <DonDiego> arm is an up and coming platform... [19:44:00] <Yuvi> I keep coming up with more special cases with seek that need handling [19:44:35] <Yuvi> since for just about everything, one or two codecs do things differently [19:44:42] <Kovensky> does anyone know of a tool that reads a file or stdin and puts the contents on the X clipboard? [19:45:12] <DonDiego> Yuvi: ogg seeking? [19:45:18] <peloverde> Kovensky, xclip? [19:45:19] <Yuvi> DonDiego: yep [19:45:26] <DonDiego> :( [19:45:31] <DonDiego> ogg is a bitch.. [19:46:03] <DonDiego> Yuvi: you should mention your experience as an answer to mans' blog post about ogg.. [19:46:19] <DonDiego> the xiph people honestly believe it's not so bad... [19:47:16] <DonDiego> Yuvi: and the theora optimizations? [19:48:30] <Yuvi> haven't gotten back to working on them, Dark_Shikari found some segfaults in the current code [19:49:49] <CIA-92> ffmpeg: conrad * r22284 /trunk/libavformat/ (rtsp.c os_support.c network.h): Localize the #define _SVID_SOURCE needed for inet_aton() to os_support.c [19:49:50] <CIA-92> ffmpeg: conrad * r22285 /trunk/libavformat/os_support.c: inet_aton needs _DARWIN_C_SOURCE on OS X [19:50:13] <Yuvi> 3dnow had an equivlant to pavgb right? [19:50:43] <Dark_Shikari> yes [19:50:44] <Dark_Shikari> pavgusb [19:50:47] <DonDiego> Yuvi: so you switched priorities to fixing those segfaults? [19:50:50] <Kovensky> <peloverde> Kovensky, xclip? <-- perfect :3 [19:50:56] <Kovensky> now, to learn el... [19:51:20] <Dark_Shikari> well IMO before 0.6 we should both fix the segfaults _and_ get optimizations in [19:51:24] <Yuvi> good, then for k6-III at least it won't be too hard to have a good loop filter [19:51:30] <Dark_Shikari> because "ready for html5" means "it doesn't crash" too [19:51:45] <CIA-92> ffmpeg: mru * r22286 /trunk/tests/ (17 files in 2 dirs): [19:51:45] <CIA-92> ffmpeg: regtest: run seektest on image sequences [19:51:45] <CIA-92> ffmpeg: Seeking on image sequences doesn't actually work, so this [19:51:45] <CIA-92> ffmpeg: test isn't very useful until that capability is added. [19:51:46] <Dark_Shikari> and we can explicitly brag that we did extra fuzz-testing to fix crash bugs =p [19:51:51] <Yuvi> DonDiego: yeah, putting segfaults against the web isn't a good idea ;) [19:52:18] <DonDiego> yes, i absolutely agree [19:52:32] <DonDiego> i'm just looking out for stuff i need to keep on the radar for 0.6 [19:52:34] <peloverde> Dark_Shikari, one thing I think about sometimes is illegal reads [19:52:38] <DonDiego> astrange: what about ffmpeg-mt? [19:52:39] <peloverde> should we be worried about them [19:52:43] <Dark_Shikari> peloverde: yes [19:52:45] <Dark_Shikari> DOS is bad [19:53:13] <mru> also what segfaults on one system might do something much nastier on another [19:53:17] <DonDiego> peloverde: that reminds me to ask you what i always ask as well (it would not be fair to just annoy yuvi): [19:53:22] <DonDiego> what about sbr? [19:53:23] <DonDiego> :) [19:53:25] <peloverde> Dark_Shikari, then we need more input buffer padding [19:53:31] <Dark_Shikari> you can sell Quicktime DOSs for $5k+ on _legitimate_ channels [19:53:49] <peloverde> DonDiego, we need a second legal opinion about variable names [19:53:50] <DonDiego> Dark_Shikari: ? [19:54:02] <Dark_Shikari> DonDiego: hence DOSs are important enough that people pay for said exploits... [19:54:08] <Dark_Shikari> any exploit someone would pay for is something we should fix [19:54:29] <peloverde> Dark_Shikari, if we want to stop illegal reads then we should look at the google patches or be willing to up input buffer padding size [19:54:44] <Dark_Shikari> peloverde: Or we could simply do what x264 does [19:54:47] <peloverde> Dark_Shikari, why not just sell the exploits ourselves [19:54:54] <Dark_Shikari> peloverde: because it's in our interest to fix them [19:54:54] <peloverde> :) [19:55:15] <peloverde> anyway what does x264 do? [19:55:45] <Dark_Shikari> at each macroblock, it checks to see that the amount of buffer left is greater than or equal to the estimated maximum size of an MB (worst-case) [19:55:49] <Dark_Shikari> this avoids massive buffer padding [19:55:54] <Dark_Shikari> This can be applied to any set of syntax elements [19:56:00] <peloverde> I did that for AAC [19:56:03] <Dark_Shikari> calculate the maximum size, round up a lot, check buffer against that _before_ decoding that set [19:56:06] <Dark_Shikari> thus you don't have to check on every read [19:56:07] <peloverde> but I still need more padding [19:56:18] <peloverde> I need 36 bytes per frame [19:56:24] <Dark_Shikari> that's "more"? [19:56:28] <peloverde> yes [19:56:29] <Dark_Shikari> I would have assumed we already had a megabyte or two [19:56:48] <peloverde> FF_INPUT_BUFFER_PADDING_SIZE 8 [19:56:55] <Dark_Shikari> LOL [19:57:03] <Dark_Shikari> this some kind of joke? [19:57:12] <peloverde> and some of that is for get_bits [19:57:22] <merbanan> how about we add a CONFIG_SMALL define ? [19:57:22] <peloverde> so I really need to increase it to 44 [19:57:43] <Dark_Shikari> 44? more like 44,000 [19:57:46] <mru> the existing padding is only to allow get_bits loading chunks of 8 bytes [19:57:54] <BBB> Vitor1001: ok, all math is done now, I'll work on code comments and then hopefully post & commit [19:57:57] <Dark_Shikari> yeah, it doesn't stop overreads [19:58:02] <BBB> (plus all variables need useful names) [19:58:03] <Dark_Shikari> mru: we could add a branch to get_bits ;) [19:58:07] <peloverde> It stops small overeads [19:58:23] <peloverde> I do one bit overeads for w6132 and that seems to work fine [19:58:42] <Dark_Shikari> that's not tolerable [19:58:46] <Dark_Shikari> anything that makes valgrind complain is bad [19:58:49] <Dark_Shikari> _anything_ [19:59:00] <mru> reading into the padding is of course ok [19:59:00] <peloverde> Dark_Shikari, valgrind doesn't complain about the 1 bit overeads [19:59:01] <merbanan> even bugs in valgrind ? [19:59:06] <Dark_Shikari> merbanan: ok, true [19:59:09] <Dark_Shikari> but those are not that common. [19:59:12] <Dark_Shikari> mru: obviously. [19:59:12] <mru> bugs in valgrind are bad too [19:59:29] <Dark_Shikari> the only valgrind bugs I know of that affect this sort of thing are the simd data tracking bugs [19:59:32] <Dark_Shikari> in pmaddwd, etc [19:59:34] <Dark_Shikari> er, pmaddusbw [19:59:41] <Dark_Shikari> but they're trivial to shut up [19:59:49] <Dark_Shikari> you just zero on malloc [19:59:51] <peloverde> anyway until someone is willing to increase FF_INPUT_BUFFER_PADDING_SIZE to something real, trying to stop overeads is insane [20:00:32] <Dark_Shikari> then we do it [20:02:33] <Yuvi> is it worth worrying about CPUs without mmx2 or 3dnow? [20:02:55] <DonDiego> without any or both of them? [20:02:56] <mru> I think we can increase the padding to, say, 64 without much debate [20:03:02] <Yuvi> both [20:03:04] <peloverde> Yuvi, I wouldn't bother but i'm sure there are people who care [20:03:41] <DonDiego> i fear i'm about the only person with such a vintage machine, but i do care :) [20:03:57] <Yuvi> well, it's easy enough to fix for you :) [20:04:36] <Dark_Shikari> Yuvi: I say no [20:04:46] <Dark_Shikari> then again I believe we shouldn't care about cpus without sse [20:05:51] <DonDiego> Yuvi: would it be worthwhile to port the libtheora loopfilter? [20:06:55] <Yuvi> maybe, I can post a patch and see what michael says [20:07:00] <Dark_Shikari> isn't our current version pretty good? [20:07:12] <Yuvi> yeah, but requires pavgb [20:07:56] <Yuvi> (the optimal mmx loop filter would unpack to 16-bits instead, so it's mostly different code) [20:08:06] <Dark_Shikari> are you sure it would? [20:08:37] <Yuvi> it should be faster than emulating pavgb in addition to the munging pavgb needs [20:08:46] <Dark_Shikari> nope, doesn't seem so [20:09:16] <Dark_Shikari> at least maybe not [20:09:39] <Yuvi> well, if it's questionable, it's easier to emulate pavgb unless someone with such a cpu cares enough to benchmark [20:09:39] <Dark_Shikari> pavgb in coreavc is pxor/por/pand pb_254/psrlq 1/psubb [20:09:41] <Yuvi> so I'll do that [20:09:51] <Dark_Shikari> I trust the original coreavc author on this [20:09:55] <Dark_Shikari> but he might be wrong. [20:13:52] <Dark_Shikari> Yuvi: http://pastebin.org/103997 [20:15:23] <peloverde> care to use a pastebin variant that doesn't have talking ads? [20:16:13] <Dark_Shikari> what ads? [20:16:35] <mru> pastebin.ca seems clean, at least with adblock [20:16:43] <Dark_Shikari> I prefer pastebin.org's interface [20:16:46] <Dark_Shikari> and it doesn't have ads either [20:16:58] <mru> w/o adblock has the most obnoxious ads ever [20:17:03] <mru> full-screen popups [20:17:17] <Dark_Shikari> wait, people still exist that browse without adblock? [20:17:32] <mru> as surprising as it sounds, yes [20:17:53] <Yuvi> mine didn't have the offending domain blocked initially [20:17:58] <Yuvi> *.adonion.com [20:22:10] <peloverde> I find most adblockers to aggressive, so I just avoid sites that use obnoxious ads [20:22:26] <Vitor1001> BBB: are you sure that the code that does RDFT -> set real part to zero -> IRDFT is correct? [20:22:47] <BBB> Vitor1001: it gives the same output as binary [20:22:57] <BBB> Vitor1001: but I admit it looks a little odd [20:23:06] <BBB> and I have no idea what it does [20:23:10] <Vitor1001> Weird... I'll try to understand it... [20:25:26] <BBB> I'm working on simpler parts of the code ATM, the tilt correction appears similar to AMR-NB [20:25:36] <BBB> I can probably merge the two into 1 shared function [20:25:54] <Vitor1001> Nice, shared code is great, but maybe it is speed critical to AMR... [20:26:38] <BBB> to be honest, doesn't look speed-critical [20:26:41] <BBB> but I'll measure [20:26:46] <BBB> is amrnbdec slow? [20:27:16] <Vitor1001> I don't know, never benchmarked it against opencore [20:27:43] <Vitor1001> But since it is float-based, it should be faster in desktops [20:34:16] <BBB> in ~3yrs, it'll be faster&better on smartphones also [20:34:24] <BBB> moore's law probably still applies there [20:34:55] <Vitor1001> I think for smartphones its already the case [20:35:14] <BBB> we'll see [21:08:13] <CIA-92> ffmpeg: alexc * r22287 /trunk/libavcodec/aac.c: AAC: Add a new line after the TNS error message. [21:10:07] <Kovensky> <Dark_Shikari> I prefer pastebin.org's interface <-- I don't see any major difference other than colors [21:10:19] <Kovensky> also, pastebin.ca doesn't corrupt your diffs and UTF-8s [21:10:28] <ohsix> gist ftw [21:10:37] <mru> I hate the @@ munging on .com/.org [21:10:53] <superdump> mmm [21:11:16] <Kovensky> the only thing I have against pastebin.ca is that the hilighters give comments less priority than keywords / string delimiters [21:11:30] <Dark_Shikari> Kovensky: um, have you seen pastebin.com? [21:11:32] <Dark_Shikari> it's a disaster [21:11:35] <Kovensky> so you get random hilighting inside comments [21:11:36] <Dark_Shikari> it was bought out [21:11:38] <Kovensky> Dark_Shikari: pastebin.com IS a disaster [21:11:46] <Dark_Shikari> pastebin.ca doesn't show line numbers correctly [21:11:48] <Kovensky> I'm talking in pastebin.ca's defense :P [21:11:51] <Dark_Shikari> they're covered up by the interface [21:11:56] <Kovensky> o_O [21:12:03] <mru> oh, .org is the old .com [21:12:06] <Dark_Shikari> mru: exactly. [21:12:13] <Kovensky> http://pastebin.ca/1827586 <-- they look correctly on this paste [21:12:19] <Kovensky> correct* [21:13:03] <mru> I have scripts to post on .ca [21:13:27] <mru> git diff | pastediff [21:13:51] <mru> even copies the url as X selection [21:14:22] <Dark_Shikari> Kovensky: http://i47.tinypic.com/dcrj1z.png [21:14:25] <Dark_Shikari> "correct" [21:14:32] <Dark_Shikari> fail css is fail [21:14:52] <Kovensky> Dark_Shikari: it's on your side then [21:14:56] <Kovensky> which browser [21:15:06] <Dark_Shikari> firefox [21:15:38] <Dark_Shikari> the problem is that the CSS is badly written and assumes a particular font size [21:16:01] <Dark_Shikari> but, in the interests of not losing my vision before I'm 30, I use a larger font [21:16:29] <Kovensky> oic [21:16:44] <Kovensky> Dark_Shikari: submit a bug report? :P [21:17:13] <Kovensky> oh great, the bug report link is 404 =p [21:17:37] <CIA-92> ffmpeg: alexc * r22288 /trunk/libavcodec/avcodec.h: [21:17:37] <CIA-92> ffmpeg: Increase FF_INPUT_BUFFER_PADDING_SIZE to 64. [21:17:37] <CIA-92> ffmpeg: The purpose of this is to give decoders a reasonable amount of buffer to work [21:17:37] <CIA-92> ffmpeg: with before needing to check for overreads. [21:17:46] <peloverde> ^Let's see if I get flamed [21:18:03] <superdump> :) [21:18:11] <Yuvi> (isn't that an API change?) [21:18:17] <Yuvi> ABI I guess [21:18:59] <peloverde> Couldn't you have said something about that when we were discussing it five minutes ago? :) [21:20:07] <peloverde> So does that mean I need to revert? [21:20:16] <mru> no, leave it [21:20:18] <mru> we need it [21:20:21] <Yuvi> yeah [21:20:22] <mru> no point pushing it off [21:20:25] <Kovensky> bump minor? [21:20:29] <Yuvi> going to happen sooner or later [21:20:33] <Dark_Shikari> I would go for more than 64 [21:20:39] <Dark_Shikari> we need enough to cover things like "one dct block of coeffs" [21:20:41] <Dark_Shikari> in h264 [21:20:52] <Dark_Shikari> to avoid checking per-read [21:21:03] <peloverde> I went with 64 because it fixes AAC and mru suggested 64 would be ok [21:21:27] <peloverde> I didn't submit a patch because I didn't want to waste weeks bikeshedding the size [21:21:39] <peloverde> If you have a legitamte reason to increase it, increase it [21:21:49] <Dark_Shikari> k [21:22:05] <mru> if we were talking about kilobytes there could be valid objections [21:22:10] <superdump> so the revolt begins...? :) [21:22:16] <Dark_Shikari> IMO we should try to go through the codecs and certify them as "not a problem" [21:22:19] <Dark_Shikari> wrt buffer overreads [21:22:24] <peloverde> yes [21:22:27] <Dark_Shikari> and possibly raise the size. [21:22:28] <mru> ultimately we may need to have per-codec padding [21:22:35] <Dark_Shikari> mru: I agree [21:22:37] <Dark_Shikari> it should be part of the API [21:22:41] <peloverde> Indeed [21:22:42] <superdump> that would make sense i guess [21:22:43] <Dark_Shikari> that each codec has an amount of padding it asks for [21:22:49] <Dark_Shikari> a codec property [21:23:01] <Dark_Shikari> for h264, if we wanted to check per-MB, it would be a few kilobytes [21:23:05] <Yuvi> that increases the dependence of lavf on lavc though [21:23:22] <mru> lavf is already hopelessly entangled in lavc [21:23:30] * superdump sighs [21:23:44] <mru> but this change wouldn't need to make it worse [21:24:06] <mru> add a field somewhere so the calling app can request whatever padding it wants from lavf [21:25:04] <peloverde> Issue 1295 closed [21:28:56] <peloverde> superdump, do you have any thoughts on this: http://github.com/aconverse/ffmpeg-heaac/commit/4f3345b375aa5c73918330e4783… [21:30:54] <superdump> let's see... [21:33:33] <superdump> well, the logical operator doesn't display correctly in my pdf [21:33:41] <superdump> it's just a square [21:33:45] <superdump> so i can't tell [21:34:49] <superdump> i'd say unless you find any files that have numpatches 6 or you can prove that it's a bug in the spec, stick with the spec and go with 5 i guess [21:34:54] <mru> peloverde: does this look right? http://pastebin.ca/1827665 [21:35:08] <peloverde> Oh shit, it is " <=" in the .doc [21:35:12] <superdump> aha [21:35:38] <peloverde> mru, yes [21:36:19] <superdump> peloverde: is it <= 5 in the doc and < 6 in the coding tech code and > 5 in our code? :) [21:38:37] <peloverde> now I'm even more confused [21:38:57] <superdump> why? [21:39:34] <peloverde> nevermind [21:39:55] <peloverde> for a minute I thought that 6 was allowed by the spec [21:40:57] <superdump> :) [21:41:38] <peloverde> anyway the files imply CT had an encoder outputting 6 patches, which means we need to support it [21:41:40] <DonDiego> astrange: what's the status of ffmpeg-mt? [21:42:18] <peloverde> I wonder If I should forward this to dolby [21:42:31] <superdump> peloverde: hmm, might be an idea i guess [21:42:50] <peloverde> they took down the check package though [21:43:02] <peloverde> CT's website had a ton of useful stuff that dolby just killed [21:44:17] <peloverde> also can a fate test just look at sample rate and a number of channels? because I want to add tests for HE-AAC signaling [21:45:44] <mru> ffprobe tests [21:48:01] <peloverde> presumably, but that would also cover metadata [21:48:33] <CIA-92> ffmpeg: mru * r22289 /trunk/libavcodec/fft-test.c: Update include directives in fft-test.c [21:48:33] <CIA-92> ffmpeg: mru * r22290 /trunk/ (6 files in 2 dirs): Give RDFT types more meaningful names [21:48:43] <mru> we could teach ffprobe to not print metadata [21:49:09] <peloverde> maybe a flag to suppress metadata? [21:49:32] <mru> exactly [21:50:00] <mru> what harm does the metadata printout do anyway? [21:50:49] <peloverde> if someone adds 3gpp asset information it will break the test [21:57:34] <CIA-92> ffmpeg: mru * r22291 /trunk/ (6 files in 2 dirs): Create a public API for FFT family of functions [21:57:34] <CIA-92> ffmpeg: mru * r22292 /trunk/ffplay.c: ffplay: use public fft interface [22:19:22] <CIA-92> ffmpeg: mru * r22293 /trunk/ffserver.c: [22:19:22] <CIA-92> ffmpeg: ffserver: do not use intreadwrite.h [22:19:22] <CIA-92> ffmpeg: intreadwrite.h is not part of the public API and should thus [22:19:22] <CIA-92> ffmpeg: not be used by the ff* applications. [22:19:22] <CIA-92> ffmpeg: mru * r22294 /trunk/ (common.mak subdir.mak): Define HAVE_AV_CONFIG_H only when building libraries [22:19:23] <CIA-92> ffmpeg: mru * r22295 /trunk/ (ffplay.c ffserver.c ffprobe.c cmdutils.c ffmpeg.c): Remove hacks not required since HAVE_AV_CONFIG_H was unset for the apps [22:35:45] <saste> hurrah for mans! \o/ [22:35:55] <saste> FFmpeg code never has been so sweet.. [22:36:23] <saste> but now there are some suspicious warnings in ffserver.c [22:36:34] <saste> ffserver.c: In function ‘http_parse_request’: ffserver.c:1341: warning: implicit declaration of function ‘av_match_ext’ [22:36:35] <mru> I'm looking at those right now [22:37:03] <Yuvi> oh, that's a cool trick, pavgb(a,~b) is (a-b)>>1 [22:37:09] <Yuvi> didn't think of that before [22:38:00] * mru looks at VHSUB [22:38:18] <Yuvi> of course neon has the more useful instructions :P [22:43:01] <CIA-92> ffmpeg: stefano * r22296 /trunk/libavformat/ (utils.c internal.h): (log message trimmed) [22:43:02] <CIA-92> ffmpeg: Move the probe loop from av_open_input_file() into its own method [22:43:02] <CIA-92> ffmpeg: av_probe_input_buffer() so that it can be reused. Here are a few [22:43:02] <CIA-92> ffmpeg: differences to the original way things were probed: [22:43:02] <CIA-92> ffmpeg: - maximum probe buffer size can be specified as a parameter. [22:43:02] <CIA-92> ffmpeg: - offset within the stream to probe from can be specified as a parameter. [22:43:03] <CIA-92> ffmpeg: - instead of seeking back to the start each time a probe fails, stream [23:11:14] <CIA-92> ffmpeg: cehoyos * r22297 /trunk/libavformat/utils.c: [23:11:14] <CIA-92> ffmpeg: Fix pts->dts conversion init for non-zero initial value for pts. [23:11:14] <CIA-92> ffmpeg: Patch by Daniel Kristjansson, danielk cuymedia net [23:11:24] <superdump> when did concat get merged? [23:11:46] <superdump> and what's the syntax? (i don't see anything in the help output) [23:13:58] <janneg> superdump: 21666 [23:14:06] <superdump> thanks [23:14:21] <janneg> git sha1 a4b47b0b864e3 [23:17:06] <superdump> looks like -i concat:/path/to/file1|/path/to/file2... [23:18:47] <janneg> doesn't work for me [23:47:31] <CIA-92> ffmpeg: alexc * r22298 /trunk/libavcodec/aac.c: AAC: Set codec parameters in the first frame rather than in .init() [23:53:20] <CIA-92> ffmpeg: alexc * r22299 /trunk/libavcodec/aac.c: 10l: AAC: Set multiplier to 0. [23:54:35] <CIA-92> ffmpeg: stefano * r22300 /trunk/libavfilter/defaults.c: [23:54:35] <CIA-92> ffmpeg: Make avfilter_default_start_frame() correctly pass the aspect ratio [23:54:35] <CIA-92> ffmpeg: information to the next filter. [23:55:25] <saste> janneg: how is not working? [23:56:31] <janneg> saste: concat:file1.avi|file2.avi: no such file or directory [23:58:56] <saste> which is the complete command?

1 0

IRC log for 2010-03-06
by irc＠mansr.com 07 Mar '10

07 Mar '10

[00:01:36] <peloverde> O.o my response to michael's review plus the new patch crossed the 200k limit [00:02:21] <peloverde> Does a mod want to push it through or should I resend and omit the (unchanged) tables? [00:03:01] <mru> done [00:04:42] <peloverde> thanks [00:08:51] <Dark_Shikari> my fuzzer has detected about half a dozen crases in ffmpeg already [00:08:55] <Dark_Shikari> testing on h264+aac in mkv [00:09:14] <mru> fix it! [00:09:20] <Dark_Shikari> have to get samples first [00:09:22] <peloverde> Dark_Shikari, I can't get it to crash fuzzing AAC-LC, mdat only in mp4 [00:09:36] <Dark_Shikari> random seeds that caused crashes: 140, 175, 182, 197, 229 [00:09:38] <peloverde> A few illegal reads, no crashes [00:09:41] * mru needs to extend his bot to be as good as j-b's [00:09:51] <Dark_Shikari> lemme post the fuzzer so anyone can replicate it [00:10:33] <Dark_Shikari> http://pastebin.org/102018 [00:10:35] <Dark_Shikari> trivial fuzzer [00:10:39] <Dark_Shikari> ./fuzzer inputfile outputfile seed [00:10:59] <Dark_Shikari> http://mirror05.x264.nl/Dark/x264clips/IronMan.mkv test file [00:11:11] <Dark_Shikari> encoding command: ffmpeg -i input output.avi [00:11:22] <Dark_Shikari> thus, ./fuzzer IronMan.mkv test.mkv 140 will produce a crash in ffeg. [00:11:24] <Dark_Shikari> *ffmpeg [00:12:15] <peloverde> playing AAC with NBC PS crashes the mp3 decoder :) [00:12:31] <peloverde> (actually it crashes SDL) [00:12:35] <Dark_Shikari> lol [00:12:41] <Dark_Shikari> well, time to debug these. [00:14:15] <Dark_Shikari> woohooo! crash in memcpy [00:14:20] <Dark_Shikari> Matroska bug! [00:14:27] <Dark_Shikari> oh shit this might be exploitable [00:15:10] <mru> those are usually easy to fix [00:15:46] <Dark_Shikari> then do it if it's so easy ;) [00:15:53] * Dark_Shikari makes disabled-optimizations build to track this down better [00:16:37] <mru> a runaway memcpy that actually crashes is much easier to track than one that corrupts some data causing a crash gigabytes later [00:17:07] <Dark_Shikari> of course [00:17:21] <Dark_Shikari> I'm not valgrinding =p [00:17:23] <Dark_Shikari> too slow for fuzzing [00:17:33] <peloverde> I always valgrind the crashes from fuzzers [00:17:34] <mru> don't you have an i7? [00:17:41] <peloverde> look for the first illegal write [00:17:43] <Dark_Shikari> mru: I'm running this on a dual i7 linux box [00:17:46] <Dark_Shikari> only 1.8ghz 2-core [00:17:52] <Dark_Shikari> and valgrind is still slow [00:18:01] <peloverde> hell for audio i run the fuzzer with valgrind [00:18:16] <Dark_Shikari> want to investigate this one then? [00:18:22] <Dark_Shikari> takes about a minute to crash with a memcpy in matroskadec [00:18:29] <Dark_Shikari> who the hell maintains matroskadec anyways [00:18:35] <peloverde> I don't know the matroskadec codebase at all [00:18:47] <mru> it ain't me [00:19:07] <Dark_Shikari> what would be the best way to start a fuzzer thread? [00:19:18] <Dark_Shikari> I was thinking we could work on the bugtracker and offer the same bugfix rewards as usual, but keep it all in one bug report [00:19:24] <Dark_Shikari> and all I would do is report sample name + random seed [00:19:37] <Dark_Shikari> then I wouldn't have to upload every single one [00:20:12] <Dark_Shikari> yup, it crashes where I thought [00:20:13] <Dark_Shikari> memcpy (pkt->data+offset, pkt_data, pkt_size); [00:22:42] <Yuvi> aurel does, but I'm familiar with it too [00:23:10] <Dark_Shikari> Yuvi: want to look into it? [00:23:26] <Dark_Shikari> don't have to, it's not critical, just wondering. [00:23:46] <Yuvi> sure [00:24:16] <Dark_Shikari> ok, since I have slow upload, it will be fastest for you to replicate it by using the fuzzer [00:24:19] <Yuvi> btw, pastebin.org's popups are annoying [00:24:23] <Dark_Shikari> popups? [00:24:26] <Dark_Shikari> it doesn't have popups [00:24:33] <Dark_Shikari> or are you on some weird browser without adblocking [00:24:35] <mru> Yuvi: not enough adblock? [00:24:42] <Dark_Shikari> anyways, download the fuzzer, run it on the file with a seed of 140 [00:24:48] <Dark_Shikari> I gave the link above, should be enough info to replicate it [00:24:56] <Yuvi> safari's popup blocking doesn't cover javascript onclick [00:25:55] <Yuvi> (and view source is disabled for that site somehow?...) [00:26:20] <mru> not for me [00:26:31] <mru> you're browser's broken, dude [00:27:10] <Yuvi> eh, it's the least broken of OS X browsers [00:27:21] <mru> s/browser/OS/ [00:31:03] <Dark_Shikari> thread started on ffmpeg-devel [00:32:43] <Yuvi> blocking *.adonion.com fixed it [00:39:21] <mru> wow, that's an annoying popup [00:39:44] <Yuvi> seed 140 doesn't crash for me, isn't it dependent on your RNG? [00:40:38] <Dark_Shikari> Yuvi: shit. it varies per OS? [00:41:01] <mru> compare md5 of files [00:41:03] <Dark_Shikari> blah, I guess that's true [00:41:08] <Dark_Shikari> I'm running on gentoo here [00:41:12] <Yuvi> af5356bc1ee63c6f0180f15705d04a33 [00:41:41] <Dark_Shikari> fbf75339bebb9ed4c13c2cc624d8c961 IronMan.mkv [00:41:43] <Dark_Shikari> 5c59aa9d2bbfb08f1d29db54c4227b9e test.mkv [00:41:52] <Dark_Shikari> I could borrow ffmpeg's LCG or something [00:42:18] <mru> yeah, you can't use rand() [00:42:24] <Dark_Shikari> rand() differs even on linux systems? [00:42:27] <mru> it's, err... random [00:42:50] <mru> it's unspecified by the standard what it should do [00:42:59] <Dark_Shikari> I guess it depends on libc version? [00:43:05] <mru> I'm pretty sure glibc has changed it some time or other [00:43:23] <mru> the old one wasn't bloated enough [00:44:21] <Dark_Shikari> ok, I'll upload the file separately and modify my code to use a deterministic rng [00:44:22] <janneg> return 4;? [00:45:07] <Dark_Shikari> should I just have it link to libavutil? [00:45:12] <Dark_Shikari> and use the LFG? [00:45:26] <mru> maybe we need to write ffuzz [00:48:47] <mru> janneg: xsi requires a period of at least 1<<32 [00:51:04] <Dark_Shikari> wait wtf [00:51:07] <Dark_Shikari> I included avutil.h [00:51:08] <Dark_Shikari> fuzzer.c:10: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'state' [00:51:11] <Dark_Shikari> line: [00:51:12] <Dark_Shikari> AVLFG state; [00:51:18] <Dark_Shikari> is that not sufficient to have AVLFG defined? [00:51:51] <Dark_Shikari> lfg.h isn't in my /usr/include/libavutil, is it not a public header? [00:51:51] <mru> for lfg you need lfg.h [00:52:10] <mru> seems not [00:52:15] <mru> don't look at me [00:53:52] <Dark_Shikari> updated the fuzzer [00:53:56] <Dark_Shikari> obviously the old number (140) won't work [00:54:34] <peloverde> Does anyone have an old mp3on4 draft from when it used to use AOT 29? I'm trying to add PS without breaking draft mp3on4 [00:56:43] <janneg> mru: I know, it was just a reference to http://xkcd.com/221/ [01:01:26] <janneg> MS shuffle implementation using "return (0.5 - Math.random());return (0.5 - Math.random());" [01:01:29] <janneg> return (0.5 - Math.random()); [01:01:36] <mru> also http://dilbert.com/fast/2001-10-25/ [01:02:07] <janneg> return (0.5 - Math.random()); [01:02:10] <janneg> return (0.5 - Math.random()); [01:02:57] <Dark_Shikari> 9 9 9 9 9 9 9 9 9 9 [01:03:01] * Dark_Shikari clicks [01:03:03] <Dark_Shikari> yes, it's that comic [01:03:34] <mru> Dark_Shikari: I can fuzz the file for you directly on mphq [01:03:45] <Dark_Shikari> Yuvi: http://www.mediafire.com/?mzmjijtmjhy [01:03:46] <Dark_Shikari> here's your file [01:03:51] <Dark_Shikari> mru: what do you mean? [01:03:55] <Dark_Shikari> in an automated fashion? [01:04:07] <mru> grab the original and run the fuzzer with your seed [01:04:20] <mru> if your upload is slow [01:04:30] <Dark_Shikari> that method is high latency and wastes space [01:04:48] <mru> I know, cgi [01:07:11] <janneg> argh, sorry. connection problems [01:08:22] <janneg> using return (0.5 - Math.random()); as comparison function for a sort algorithm [01:09:00] <janneg> if you're lucky it'll trigger an infinite loop [01:09:19] <mru> rock, paper, scissors [01:09:23] <mru> sort [01:18:30] <Dark_Shikari> Yuvi: got it? [01:21:53] <Yuvi> Dark_Shikari: yeah, matches your md5, but doesn't crash for me [01:22:02] <Dark_Shikari> wtf? [01:22:06] <Dark_Shikari> with commandline [01:22:09] <Dark_Shikari> ffmpeg -i input output.avi [01:22:10] <Dark_Shikari> ? [01:22:20] <Yuvi> yep [01:22:22] <Dark_Shikari> well, valgrind it and you'll probably get errors [01:22:30] <Dark_Shikari> maybe whether or not it actually dies is system-dependent [01:22:45] <Yuvi> my guess (from looking at the code) is an overread [01:22:52] <Dark_Shikari> probably [01:24:06] <Yuvi> wonder if released valgrind supports 64-bit OS X or 32-bit binaries only [01:24:56] <Yuvi> actually guess I'll have to get a snapshot for 10.6 anyway [01:27:44] <ohsix> are you guys both on x86_64 or whatever? [01:28:01] <ohsix> nevermind [01:32:19] <CIA-92> ffmpeg: michael * r22228 /trunk/tools/trasher.c: Make trasher use a well defined random number generator and allow the seed to be specified on teh cmd line. [01:33:43] <CIA-92> ffmpeg: michael * r22229 /trunk/tools/trasher.c: Remove apparently unneeded define and includes. [01:34:05] <J_Darnley> uh "on teh cmd line"? [01:55:16] <Dark_Shikari> hahaha, michael added my features to trasher ;) [01:56:00] <Dark_Shikari> Yuvi: try seed 35 with my new fuzzer [02:12:50] <Compn> i think we need to promote some of ffmpeg's lesser known code [02:32:11] <Yuvi> Dark_Shikari: got 35 to crash in linux, in os x it has a runaway malloc [03:55:21] <Yuvi> Dark_Shikari: patch sent, should fix both of them [04:37:22] <MrNaz_yma> Checking -head but i there's a bug in ffmpeg as of feb 10th: when using -ss and -t in conjunction, ffmpeg does not encode -t duration from the specified time in -ss but from the start... e.g., -ss 00:01:00 -t 00:01:30 will result in a 30 second clip instead of a 1 minute and 30 second clip [04:37:31] <MrNaz_yma> i believe this is a break from past behavior [06:06:30] <Dark_Shikari> Yuvi: great [06:10:11] <Dark_Shikari> Yuvi: still here? [06:10:18] <Yuvi> Dark_Shikari: yep [06:10:20] <Dark_Shikari> 73, 163, 278, [06:10:24] <Dark_Shikari> make sure all those are the same crash [06:12:11] <Dark_Shikari> can you pastebin your patch as well so I can apply it locally? copy-pasting from email sorta sucks [06:13:06] <Yuvi> http://pastebin.org/102112 [06:14:22] <Dark_Shikari> thx [06:17:41] <Dark_Shikari> Yuvi: if all three of those are the same issue, next target will be the mp4 demuxer [06:38:18] <Yuvi> Dark_Shikari: yep, they are [06:40:14] <Dark_Shikari> ok, fuzzing mp4 now. [06:40:34] <Dark_Shikari> thanks for fixing that. [07:23:41] <superdump> Dark_Shikari: reynaldo got back to me [07:23:55] <superdump> he said that he hasn't been able to contact the guy who runs the server [07:24:53] <Dark_Shikari> ooof :/ [07:27:06] <MrNaz_yma> Dark_Shikari can you clarify the correct behaviour for -t ? [07:27:22] <Dark_Shikari> it should take as input X seconds of the video [07:27:29] <MrNaz_yma> in that case it's wrong [07:28:12] <MrNaz_yma> e.g., -ss 00:01:00 -t 00:02:00 should yield a 2 minute video... but it yields a 1 minute video, as it seems to take -t as a timestamp to end at rather than a length of time to encode for [07:29:25] <Dark_Shikari> More likely, the fps is off by a factor of 2 [07:29:53] <superdump> Dark_Shikari: the main problem is that the article is linked to from all over the place [07:29:54] <MrNaz_yma> no [07:29:58] <superdump> but we could rewrite it [07:30:04] <MrNaz_yma> Dark_Shikari no i've tried it with different times [07:30:11] <superdump> or put up a mirror or something [07:30:52] <MrNaz_yma> Dark_Shikari i've just confirmed that -ss 00:04:00 -t 00:05:00 also yields a 1 minute video [07:31:21] <MrNaz_yma> and that's with -r22168 [07:31:51] <Dark_Shikari> superdump: use google cache [07:33:31] <superdump> maybe i'll copy and paste it back into a blogger blog i had ages ago so i never have to manage anything myself [07:34:12] <Dark_Shikari> get hosting from mike [07:35:09] <kshishkov> yes, it's a sign you work for FFmpeg too ;) [07:41:12] <MrNaz_yma> Dark_Shikari also, when ffmpeg is invoked with infile === outfile all that happens is that it blows the file away... is there a reason for this or can i suggest a feature where it emits an error in this case ? [07:41:58] <kshishkov> it's common way [07:42:18] <kshishkov> i.e. it works this way in any other programe [07:42:21] <kshishkov> *program [07:43:06] <kshishkov> and your suggestion will fail something like ffmpeg -i pipe://1.avi pipe://1.avi [07:43:48] <kshishkov> just accept this [07:51:48] <MrNaz_yma> ok [07:51:52] <MrNaz_yma> just wondering [07:51:59] <MrNaz_yma> anyway... not sure if i've done this right: https://roundup.ffmpeg.org/issue1797 [07:52:04] <MrNaz_yma> that's my first roundup submission [09:26:55] <KotH> a wonderfull, snowy, swiss, good morning boys [09:27:29] <elenril> snow is evil! [09:27:52] * elenril doesn't want more snow here [09:28:49] * kshishkov strikes out wrong words and is left with "morning, boys" [09:29:34] <KotH> lol [09:29:40] <KotH> hey, we got about 10cm of snow overnight [09:29:47] <KotH> and it's still snowing :) [09:30:08] <KotH> and, snow is fun :-) [09:30:45] <elenril> snowing here too [09:30:58] <elenril> nothing fun about it [09:31:04] <kshishkov> slowly melting here [09:36:25] <kshishkov> lol, Indeo Audio unpacks single bits into int array so getbits() is really a loop reading separate bits back from that array [10:03:02] <Yuvi> hm, why does oggparsevorbis use the matroska packing for headers [10:04:35] <Yuvi> wonder if nut specifies which packing of xiph headers to use [10:13:09] * elenril wonders how long does it take to compile wine [10:14:30] <kierank> not that long last time i did [10:14:47] <kierank> i used make -j5 though [10:15:14] <elenril> heh [10:15:39] * elenril can't use big -j because of his shitty i/o controller [10:15:49] <elenril> (i think) [11:57:03] <Compn> Dark_Shikari : i assume you've seen this article : http://www.guardian.co.uk/technology/2010/feb/26/berners-lee-html5-adobe-ar… [12:20:25] <mru> hey guys, please endorse my separation of fft from dsputil.h [12:22:13] <_av500_> i endorse it [12:22:30] <_av500_> anything that makes dsputils smaller [12:22:55] <peloverde> mru: I like the idea, I just want to review the details one more time [12:23:23] <mru> the first patch just moves a block of lines from one file to another [12:23:34] <mru> I'm not entirely happy with those tables [12:23:41] <_av500_> peloverde: any move on the he issue? i was in no mails land for a week.. [12:23:48] <mru> they're spread out in weird places [12:24:47] <peloverde> _av500_: Michael delivered a large review yesterday, I fixed most of the issues and asked for approval to commit the result as it stands [12:25:17] <_av500_> cool [12:25:28] <_av500_> and the ffplay fix? [12:27:30] <peloverde> I never liked the name IRIDFT, it doesn't really make sense, i question if it should be made public [12:28:05] <peloverde> _av500_, michael is ok with a hack in libavformat/utils.c [12:28:13] <mru> please suggest improvements [12:28:29] <mru> I have no idea what those values mean [12:30:02] <_av500_> peloverde: ok [12:30:43] <kshishkov> peloverde: that could be expressed as INTEGER_DFT|INVERSE_DFT instead of enum [12:33:24] <peloverde> mail sent [12:41:31] <CIA-92> ffmpeg: mru * r22230 /trunk/ (libavutil/mem.h libavcodec/dsputil.h): [12:41:31] <CIA-92> ffmpeg: Move DECLARE_ALIGNED_{8,16} macros to mem.h [12:41:31] <CIA-92> ffmpeg: These macros naturally belong next to the generic DECLARE_ALIGNED [12:41:31] <CIA-92> ffmpeg: macro. [13:07:34] <CIA-92> ffmpeg: stefano * r22231 /trunk/ffprobe.c: [13:07:34] <CIA-92> ffmpeg: Add support to input devices in ffprobe. [13:07:34] <CIA-92> ffmpeg: See the thread: [13:07:34] <CIA-92> ffmpeg: Subject: [FFmpeg-devel] [PATCH] Add support to input device to ffprobe [13:07:34] <CIA-92> ffmpeg: Date: Sun, 21 Feb 2010 14:57:44 +0100 [14:12:46] <CIA-92> ffmpeg: stefano * r22232 /trunk/cmdutils.c: [14:12:46] <CIA-92> ffmpeg: Make opt_default() look for options in sws_opts only if sws_opts is [14:12:46] <CIA-92> ffmpeg: defined, fix crash. [14:26:08] <CIA-92> ffmpeg: mru * r22233 /trunk/ (58 files in 5 dirs): [14:26:08] <CIA-92> ffmpeg: Remove DECLARE_ALIGNED_{8,16} macros [14:26:08] <CIA-92> ffmpeg: These macros are redundant. All uses are replaced with the generic [14:26:08] <CIA-92> ffmpeg: DECLARE_ALIGNED macro instead. [14:26:08] <CIA-92> ffmpeg: mru * r22234 /trunk/ (Makefile subdir.mak): Use $(RM) to delete files [14:35:37] <CIA-92> ffmpeg: mru * r22235 /trunk/ (27 files in 5 dirs): Move FFT parts from dsputil.h to fft.h [14:37:35] <elmojo> janneg: finished 02_rabbit-04.job and starting 02_rabbit-05_08.job now [14:42:09] <_av500_> ah, i see more BBB renderers... [15:10:06] <CIA-92> ffmpeg: kostya * r22236 /trunk/libavcodec/bink.c: Bink version 'h' also has chroma planes swapped [15:24:36] <janneg> elmojo: nice, where can I download the files? [15:24:46] <janneg> ah, I see [16:41:05] <siretart> gmane-- :-/ [16:42:15] <saste> yes she's gone... too bad [16:42:28] <astrange> pelhttp://github.com/aconverse/ffmpeg-heaac/commit/12cf52f1104e41048b984d3e… does anything interesting happen if you do "for (i = 0; i < 3; i++) autocorrelate(X_low[k], phi, i);"? [16:44:47] <mru> astrange: your tab complete didn't take [16:45:30] <astrange> oh, he quit [16:46:29] <kshishkov> good IRC client shuld remember all nicks ever present in channel and autocomplete them [16:46:58] <kshishkov> automatically kicking everybody who's ever offended you and you have op rights there is a bonus [16:47:37] <astrange> irssi is a reasonable irc client but still has annoyances [16:47:38] <kshishkov> evil is a cure for incompetence after all ;) [16:48:16] <astrange> mostly that when you paste something, half the time it just tries to privmsg it to the first word you pasted [16:51:29] <mru> I never had that problem [16:51:40] <mru> paste stuff starting with /msg much? [16:54:07] <astrange> maybe it was pasting things starting with a tab [16:58:37] <CIA-92> ffmpeg: siretart * r22237 /branches/ (0.5 0.5/configure): [16:58:37] <CIA-92> ffmpeg: Add Hurd to OS list and disable dv1394 in the Hurd case. [16:58:37] <CIA-92> ffmpeg: patch by Andres Mejia, mcitadel gmail com [16:58:37] <CIA-92> ffmpeg: backport r18938 by diego [16:59:10] <kshishkov> wow, somebody cared about Hurd! [16:59:27] <mru> lol [17:01:11] <kshishkov> BTW, how's VMS support status? [17:14:22] <CIA-92> ffmpeg: thilo.borgmann * r22238 /trunk/libavcodec/alsdec.c: Fix last frame block size correction. [17:15:02] <CIA-92> ffmpeg: mru * r22239 /trunk/ (subdir.mak configure): Add YASMDEP variable; use for deps on yasm files [17:15:02] <CIA-92> ffmpeg: mru * r22240 /trunk/ (Makefile configure): Add CP make variable [17:15:03] <CIA-92> ffmpeg: mru * r22241 /trunk/ (Makefile subdir.mak): Use mkdir -p to create directories [17:15:03] <CIA-92> ffmpeg: mru * r22242 /trunk/ (Makefile subdir.mak configure): Add INSTALL makefile variable [17:15:05] <CIA-92> ffmpeg: mru * r22243 /trunk/subdir.mak: Split install-headers target and simplify rules [17:15:06] <CIA-92> ffmpeg: mru * r22244 /trunk/ (Makefile common.mak subdir.mak): [17:15:06] <CIA-92> ffmpeg: Prettify make output [17:15:06] <CIA-92> ffmpeg: This gives brief messages from make by default. For full command [17:15:06] <CIA-92> ffmpeg: echoing, add V=1 to make command line. [17:43:10] <J_Darnley> >Prettify make output [17:43:13] <J_Darnley> eeeewwww [17:43:54] <kshishkov> well, you can't make it uglier so somebody tried it other way [17:44:01] <J_Darnley> Makes make -s pointless [17:45:08] <CIA-92> ffmpeg: mru * r22245 /trunk/ (subdir.mak configure): Fix make install [17:45:11] <J_Darnley> granted, it isn't very silent with ahh the warning [17:45:17] <J_Darnley> *all [17:46:22] <mru> J_Darnley: you liked it better before? [17:46:29] <CIA-92> ffmpeg: mru * r22246 /trunk/subdir.mak: Fix install with shared libs on weird systems [17:46:36] <J_Darnley> I was a bit more quiet [17:46:41] <J_Darnley> *It [17:46:49] <mru> eh? [17:47:02] <J_Darnley> make -s doesn't echo the commands [17:47:10] <mru> make V=1 gives you exactly what you had before [17:47:19] <J_Darnley> now it echoes CC foo/bar [17:51:59] * DonDiego is not fond of terse make output [17:52:10] <mru> so export V=1 [17:54:29] <mru> if you hate it so badly, why didn't you say anything on the ml? [18:03:02] <mru> http://fate.multimedia.cx/index.php?stderr=195059 [18:03:07] <mru> any clues wtf that is? [18:24:00] <Dark_Shikari> impressive [18:24:05] <Dark_Shikari> 500 runs on the fuzzer, mp4+aac hasn't crashed [18:24:10] <Dark_Shikari> er, h264+aac in mp4 [18:24:15] <kshishkov> good [18:24:46] <kshishkov> try that also on Theora+Vorbis ;) [18:26:52] <janneg> in ogg [18:27:16] <kshishkov> of course, ISO was wise not to allow muxing it into mp4 [18:27:52] <DonDiego> mru: i no longer read the mls and to be honest, i don't yet know if i will make a comeback [18:29:48] <DonDiego> Dark_Shikari: that was ffmpeg? [18:30:10] <DonDiego> and sure, putting our theora and vorbis stuff through the same punishment would be interesting.. [18:30:43] <peloverde> Dark_Shikari, google and I spent meany hours cleaning up AAC [18:31:49] <kshishkov> and somebody worked on H.264 decoder too, obviously [18:32:15] <DonDiego> ffserver.c:2445: warning: implicit declaration of function ‘strcasestr’ [18:32:42] <DonDiego> is this only on os x or are people now competing to introduce more and lamer warnings? [18:32:49] * DonDiego shakes his head [18:33:21] <kshishkov> maybe it's GCC [18:33:27] <DonDiego> at the current rate the day when mplayer code is cleaner than ffmpeg cannot be far away ;-p [18:34:24] <kshishkov> unlikely [18:34:33] <Dark_Shikari> DonDiego: you got a test sample for me to try on? [18:34:36] <Dark_Shikari> I would be happy to fuzz ogg [18:34:55] <Dark_Shikari> could just use ffmpeg2theora to make one [18:34:56] <DonDiego> big buck bunny is the standard one [18:35:07] <DonDiego> or our samples collection [18:35:23] <Dark_Shikari> well, 500 runs on mp4 is probably good enough for now. [18:35:31] <DonDiego> http://samples.ffmpeg.org/V-codecs/Theora/ [18:35:36] <Dark_Shikari> given it's a 250MB MP4, that's about 75 gigs of fuzzing [18:35:59] <DonDiego> the samples dir has smaller files [18:36:13] <Dark_Shikari> bigger means more chances for failure though [18:36:22] <Dark_Shikari> well, I guess it works both ways [18:36:27] <Dark_Shikari> smaller is more likely to find header parsing issues [18:36:54] <peloverde> I generally do two rounds of fuzzing for mp4 files, one on the whole file and one on mdat only [18:36:58] <DonDiego> Yuvi: this reminds me - what samples do you use for performance comparisons? [18:37:03] <DonDiego> Yuvi: and how do you test? [18:37:19] <DonDiego> i ran some tests with mplayer and two samples from the samples dir yesterday [18:37:27] <DonDiego> and libtheora 1.0 came up slightly faster [18:43:27] <Dark_Shikari> on an unrelated note [18:43:30] <Dark_Shikari> http://img682.imageshack.us/img682/3374/theora.png [18:43:31] <Dark_Shikari> http://img682.imageshack.us/img682/7056/schroedinger.png [18:43:42] <Dark_Shikari> the new schroedinger beats theora again [18:44:02] <Dark_Shikari> http://forum.doom9.org/showthread.php?p=1380594#post1380594 [18:45:08] <kshishkov> so? [18:49:34] <DonDiego> is that in any way surprising? [18:49:44] <Dark_Shikari> Actually it is, theora used to beat schro on many tests [18:49:59] <Dark_Shikari> I'm not sure if that was a testament to theora improving, or schro sucking terribly [18:50:14] <kshishkov> someone should try Haar+fullpel MC+fspp postproc for video codec [18:50:20] <kshishkov> it should also beat THeora [18:50:29] <Dark_Shikari> kshishkov: postproc? I have my own very nice postproc chain [18:50:53] <Dark_Shikari> SPP + dehalo_alpha + limited_sharpen_faster + very strong gradfun [18:50:58] <kshishkov> Dark_Shikari: well, postproc is the only thing why Theora does not suck even more [18:50:59] <Dark_Shikari> it does wonders for blocky-mess videos [18:51:15] <Dark_Shikari> I watched this awful awful FLV video yesterday and that made it basically fine [18:51:27] <Dark_Shikari> SPP to kill blocks, dehalo to kill ringing, LSF to make it not blurry, and gradfun to remove smudging [18:51:35] <Dark_Shikari> And it went barely in realtime on sub-SD on a core i7 ;) [18:53:54] <kshishkov> still, throwing out all details should give us excellent bitrate, low-complexity gives more CPU to postfilter which drops a bag of fairy dust on the whole codec [18:54:23] <Dark_Shikari> of course, it's not good if you want to actually _keep_ details [18:54:23] <Dark_Shikari> =p [18:54:35] <Dark_Shikari> kshishkov: that's the On2 method [18:54:42] <Dark_Shikari> 1) low complexity crap codec [18:54:45] <Dark_Shikari> 2) claim "high performance" [18:54:48] <kshishkov> yes, so the only way to compete with Theora [18:54:54] <Dark_Shikari> 3) dump "optional" postprocs on it, without which it looks like shit [18:55:03] <Dark_Shikari> the theora postproc is not very good [18:55:08] <Dark_Shikari> ok, it's basically nonexistent [18:55:18] <Dark_Shikari> Go look at VP6 or VP7 for stupidly complex postproc [18:55:28] <Dark_Shikari> VP8 will probably be even worse [18:55:40] * kshishkov hopes it won't be at all [19:08:38] <Dark_Shikari> Got a segfault on theora+vorbis in ogg [19:08:47] <Dark_Shikari> Yuvi: interested? [19:09:12] <kshishkov> try with official player ;) [19:09:20] <Dark_Shikari> I'm just fuzzing ffmpeg. [19:15:22] <mru> strcasestr is an evil gnu function [19:15:31] <mru> the prototype isn't visible in c99 mode [19:17:15] <Dark_Shikari> http://hothardware.com/News/Sonys-Great-Idea-Demos-That-Become-Less-Fun-Whe… [19:17:18] <Dark_Shikari> lol [19:18:13] <Dark_Shikari> wow, I'm getting a LOT of ogg segfaults [19:20:02] <CIA-92> ffmpeg: stefano * r22247 /trunk/ffplay.c: [19:20:02] <CIA-92> ffmpeg: Use av_get_pict_type_char() in debug code within output_picture2(), [19:20:02] <CIA-92> ffmpeg: simplify. [19:20:02] <CIA-92> ffmpeg: stefano * r22248 /trunk/ffplay.c: Reindent after the last commit. [19:21:14] <Dark_Shikari> Yuvi and anyone else who wants to find/fix ogg, vorbis, or theora bugs [19:21:16] <Dark_Shikari> http://mirror05.x264.nl/Dark/Extra.ogv [19:21:31] <Dark_Shikari> fuzzer seeds: 6 9 12 13 28 [19:21:54] <Dark_Shikari> I think I actually got an infinite loop too [19:22:14] <Dark_Shikari> Yup. Seed 30 is an infinite loop it seems. [19:22:28] <DonDiego> mru: see, i'm sayin this is a competition to introduce lame warnings [19:22:39] <DonDiego> see a warning - ignore it - the ffmpeg way.. [19:22:41] <mru> I have a fix queued up [19:22:53] <mru> spare the sarcasm [19:23:05] <DonDiego> it's true [19:23:35] <DonDiego> it took massive flaming and a *vote* to have michael agree to a "let's at least try to fix warnings" policy [19:24:36] <mru> that was michael [19:25:10] <DonDiego> strcasesep? [19:25:16] <twnqx> Oo [19:25:18] <DonDiego> strcasestr i mean [19:25:31] <DonDiego> well, no wonder, he is known to actively ignore warnings.. [19:25:42] <twnqx> i did that [19:25:50] <mru> that wasn't michael [19:25:55] <mru> and I said I have a fix waiting [19:25:58] <mru> calm down [19:26:11] <twnqx> until i wasted a day up to the point where -Wall showed a warning... and it was the cause of the problem [19:28:29] <kshishkov> so GCC showsonly useless warnings by default? [19:29:39] <twnqx> nah, but mostly. [19:30:19] <CIA-92> ffmpeg: mru * r22249 /trunk/common.mak: Fix build with compilers using a separate dependency command [19:30:25] <DonDiego> nonsense [19:31:44] <DonDiego> btw, that warnings vote was actually a good opportunity for voting: there was already consensus, it just had not become clear [19:32:52] <DonDiego> siretart: i have no trouble building either 0.5 or trunk with the configuration you mentioned [19:33:07] <DonDiego> i.e. --enable-cpudetect --enable-swscale --enable-gpl [19:41:29] <CIA-92> ffmpeg: diego * r22250 /branches/0.5/configure: libswscale is no longer GPL; update help comment accordingly. [19:41:49] <kshishkov> no longer GPL-only [19:41:59] <kshishkov> it still can be GPL [19:42:03] <DonDiego> sur [19:42:04] <DonDiego> e [19:42:12] <CIA-92> ffmpeg: mru * r22251 /trunk/libavutil/ (avstring.h avstring.c): [19:42:12] <CIA-92> ffmpeg: Add av_stristr() function [19:42:12] <CIA-92> ffmpeg: This is a case-insensitive version of strstr(). [19:42:12] <CIA-92> ffmpeg: mru * r22252 /trunk/ffserver.c: ffserver: use av_stristr() [19:42:16] <mru> there, strcasestr gone [19:43:09] <kshishkov> why that reminds me of Borland vs. something else case-insensitive string function naming? [19:44:43] <mru> there was already an 'i' function in avstring so I stuck with the pattern [19:44:54] <mru> I don't really prefer one over the other [19:45:34] <kshishkov> I don't think there's a real reason to prefer one over oanother anyway [19:51:45] <CIA-92> ffmpeg: diego * r22253 /branches/0.5/Changelog: Mention LGPL libswscale in the Changelog. [19:54:05] <saste> mru: r22251 => missing minor bump and APIChanges entry [19:54:24] <mru> feel free to fix while I fix some actual bugs [19:54:47] <saste> i'll do [19:55:02] <saste> not that i consider this *not* an actual bug... [19:58:24] <kshishkov> you know, inventor of first computer said that it'd be better and cheaper if higher-skilled workers would do tasks requiring high skills and leave mundane tasks to low-skilled workers [19:59:28] <Dark_Shikari> my god I have a lot of fuzzer failures on ogg [19:59:30] <Dark_Shikari> so far: [19:59:31] <Dark_Shikari> Crash: 6 9 12 13 28 38 67 69 73 82 90 91 96 [19:59:31] <Dark_Shikari> Infinite loop: 30 48 60 [20:00:01] <mru> did I mention ogg being difficult to implement? [20:00:08] <Dark_Shikari> this might be in theora or vorbis too [20:00:13] <Dark_Shikari> haven't gdb'd anything [20:01:00] <astrange> turn on coredumps [20:01:18] <Dark_Shikari> effort, I won't be able to figure out which coredumps associate with which fuzzer seeds [20:01:48] <mru> fix your script to take care of that [20:02:14] <Dark_Shikari> meh [20:08:42] <CIA-92> ffmpeg: stefano * r22254 /trunk/ (libavutil/avutil.h doc/APIchanges): [20:08:42] <CIA-92> ffmpeg: Bump minor number and add APIchanges entry after the inclusion of [20:08:42] <CIA-92> ffmpeg: av_stristr(). [20:10:12] <astrange> it's still useful to know where a crash can possibly be [20:10:27] <astrange> but matching files is better, yes [20:16:35] <ramiro> is it possible to automate gdb to break at an address and print the value of edi and continue execution? [20:16:42] <mru> yes [20:21:27] <ramiro> any specific pointers on how that would be done are welcome... [20:24:28] <janneg> ramiro: commands [20:38:44] <ramiro> mru, janneg: thanks, I finally got it... [21:29:00] <CIA-92> ffmpeg: stefano * r22255 /trunk/libavfilter/avfilter.c: Show aspect ratio information in dprintf_picref() traces. [21:29:56] <Yuvi> Dark_Shikari: I'll start looking at ogg crashes in a bit [21:30:20] <Dark_Shikari> k [21:36:07] <Dark_Shikari> I stopped the fuzzer because it was getting too much stuff [21:36:11] <Dark_Shikari> I suspect it's probably only a few bugs. [21:51:47] <verb3k> I get some artifacts with an h.264 video on ffplay and mplayer svn (didn't have that on older revisions) [21:52:03] <verb3k> is this the right place to talk about this? [22:00:18] <mru> http://www.nf.mpg.de/orgmode/guest-talk-dominik.html [22:00:28] <mru> note the video downloads: [22:00:30] <mru> Best quality (QuickTime, 301 MB) [22:00:34] <mru> Good quality (Ogg/Vorbis, 364 MB) [22:00:41] <Dark_Shikari> >quicktime [22:00:44] <Dark_Shikari> stab him in the face please [22:00:44] <ShadowJK> lol [22:00:53] <mru> I assume it's h264 inside [22:00:58] <Dark_Shikari> probably quicktime h264 [22:01:02] <Dark_Shikari> aka worse than theora [22:01:12] <kierank> and zipped for good measure [22:01:15] <mru> yeah [22:21:23] <CIA-92> ffmpeg: reimar * r22256 /trunk/libavformat/gxf.c: [22:21:23] <CIA-92> ffmpeg: GXF time base is always based on "fields" per second even for [22:21:23] <CIA-92> ffmpeg: non-interlaced video. [22:21:23] <CIA-92> ffmpeg: Should fix issue 1766. [22:26:45] <CIA-92> ffmpeg: reimar * r22257 /trunk/libavformat/gxf.c: Set GXF fallback time-base to match the one specified for audio-only. [22:37:27] <CIA-92> ffmpeg: mru * r22258 /trunk/ (7 files in 4 dirs): Add some missing #includes [22:37:27] <CIA-92> ffmpeg: mru * r22259 /trunk/libavcodec/ (mpegaudiodec.c atrac1.c rdft.c): [22:37:27] <CIA-92> ffmpeg: Make some functions static [22:37:27] <CIA-92> ffmpeg: These functions are not used outside their respective files, and they [22:37:27] <CIA-92> ffmpeg: lack a prototype in a header. [22:37:28] <CIA-92> ffmpeg: mru * r22260 /trunk/libavcodec/ (lpc.h dsputil.c ac3dec.h png.h vorbis.h): Move some prototypes from dsputil.c to reasonable header files [22:37:29] <CIA-92> ffmpeg: mru * r22261 /trunk/libavcodec/ (dsputil.c dsputil.h mlpdsp.c): Move prototypes for various dsputil init functions to dsputil.h [22:37:34] <CIA-92> ffmpeg: mru * r22262 /trunk/libavcodec/ (mpegvideo.h h263.h): Move ff_set_qscale() prototype to mpegvideo.h; it is defined in mpegvideo.c [22:37:34] <CIA-92> ffmpeg: mru * r22263 /trunk/libavcodec/ (dsputil.c dsputil.h vc1dsp.c): [22:37:34] <CIA-92> ffmpeg: Move some VC1 dsp prototypes to dsputil.h; they are defined in dsputil.c [22:37:34] <CIA-92> ffmpeg: Also fix function definitions to match prototypes (missing const). [22:37:35] <CIA-92> ffmpeg: mru * r22264 /trunk/libavcodec/ (cavsdsp.c dsputil.c dsputil.h): Move some dsp func prototypes to dsputil.h; they are defined in dsputil.c [22:37:35] <CIA-92> ffmpeg: mru * r22265 /trunk/libavcodec/ (dsputil.c snow.h): Move ff_spatial_dwt() prototype to snow.h [22:37:36] <CIA-92> ffmpeg: mru * r22266 /trunk/libavcodec/x86/ (6 files): x86: move function prototypes to header files [22:38:08] <CIA-92> ffmpeg: mru * r22267 /trunk/libavcodec/ppc/ (13 files): PPC: move prototypes to headers and make some functions static [23:08:25] <saste> how can I generate a random number in pure sh? [23:08:42] <saste> I just discovered $RANDOM is a bashsism [23:08:45] <mru> pseudo-random good enough? [23:09:03] <saste> yes that would work [23:09:10] <mru> you can cook an LCG PRNG easily enough in sh [23:09:47] <saste> * uhm ... googling for LCG [23:10:03] <iive> /dev/random? [23:10:06] <mru> next=cur*CONST1+CONST2 [23:10:33] <saste> /dev/random I'm not sure how portable it is [23:10:40] <mru> not at all [23:10:40] <saste> LCG should be fine though [23:10:50] <mru> do an lcg and seed with pid [23:10:54] <mru> that's portable [23:11:01] <saste> mru: ok thanks [23:11:44] <mru> or use date with some format producing numbers [23:11:52] <saste> (echo $$ ; w ; date) | cksum | cut -d" " -f1 [23:11:57] <saste> this was my first idea [23:13:18] <mru> what do you need a random number for? [23:13:39] <saste> slicify_h=$(expr 8 + $ $RANDOM % 24 $) [23:13:50] <saste> that's for the lavfi test script [23:14:07] <Vitor1001> Dark_Shikari: If you are looking for something nice for your fuzzer, try http://samples.mplayerhq.hu/fate-suite/real/spygames-2MB.rmvb [23:14:19] <Dark_Shikari> Vitor1001: ahahahahah, you want me to torture kostya? [23:14:43] <Vitor1001> Not his fault, just hacked a 5 min script to run it across all fate samples. [23:14:51] <Vitor1001> And this one fails for _every_ random seed [23:14:59] <Dark_Shikari> it crashes on every one? LOL [23:15:42] <Vitor1001> Ok, it was an overstatement. For some of them it is just an infinite loop and my script timeout [23:16:10] <mru> that's what the -timelimit option is good for [23:16:47] <Dark_Shikari> Vitor1001: lol [23:16:49] <Vitor1001> mru: does it works when the decoder enter an infinite loop? [23:16:55] <Dark_Shikari> well, we need a place to stick all these results [23:16:57] <Dark_Shikari> ;) [23:16:59] <mru> Vitor1001: yes [23:17:04] <mru> the OS kills the process [23:17:09] <Vitor1001> mru: nice [23:17:18] <Vitor1001> Dark_Shikari: What do you think about the wiki solution? [23:17:32] <mru> someone found a solution to the wiki problem? [23:17:38] <Vitor1001> mru: lol [23:17:59] <Vitor1001> talking about adding a table of fuzzled files that segfaults [23:18:10] <mru> I figured [23:18:29] <Vitor1001> Looks readable and script-friendly [23:18:46] <Vitor1001> at least script-friendly for adding entries [23:19:07] <Dark_Shikari> a wiki solution sounds fine to me [23:19:17] <Dark_Shikari> better than spamming fate with useless numbers [23:19:23] <mru> are wikis soluble in water? [23:19:27] <mru> or do you need ether? [23:19:44] <Vitor1001> alcoohol [23:19:55] <CIA-92> ffmpeg: mru * r22268 /trunk/libavformat/ (seek.c internal.h): Move av_read_frame_flush() prototype to lavf/internal.h [23:19:57] <CIA-92> ffmpeg: mru * r22269 /trunk/configure: [23:19:57] <CIA-92> ffmpeg: Error on implicit function declarations [23:19:57] <CIA-92> ffmpeg: Turning on -Werror=implicit makes implicit function declarations [23:19:57] <CIA-92> ffmpeg: an error with supported compilers. [23:20:06] <mru> there, no more of those mistakes [23:21:06] <twnqx> can't a SINGLE flight this year be on time :( [23:21:23] <twnqx> *whine* [23:21:35] <mru> flights on time? unheard of [23:21:56] <mru> anyway, it's party time over here [23:22:00] <twnqx> enjoy :) [23:27:32] <Vitor1001> Dark_Shikari: 5 minutes ugliness: http://wiki.multimedia.cx/index.php?title=Fuzzer_work [23:28:03] <Dark_Shikari> ah, using the trasher thingy [23:28:40] <Vitor1001> Dark_Shikari: Does it work worse than yours? [23:28:56] <Vitor1001> It is pretty pratical to use something already in the tree... [23:29:26] <Dark_Shikari> I agree [23:34:24] <Dark_Shikari> Vitor1001: could you get it to automatically update the page? [23:34:26] <Dark_Shikari> to add new info etc [23:34:41] <Vitor1001> You mean the script? [23:34:42] <Dark_Shikari> the ultimate of course would be a button to re-check something, to tell the fuzzer to go try it again, but that would be hard [23:34:45] <Dark_Shikari> yeah [23:35:49] <Vitor1001> Looks non-trivial [23:36:05] <Vitor1001> but outputting cut-and-pastable output should be easy [23:37:24] <CIA-92> ffmpeg: michael * r22270 /trunk/libavcodec/mpegaudio3.h: [23:37:25] <CIA-92> ffmpeg: header for common code between mp3 decoder and encoder. [23:37:25] <CIA-92> ffmpeg: unfinished, iam just commiting this so the functions that should be [23:37:25] <CIA-92> ffmpeg: non static have prototypes. [23:38:50] <Vitor1001> Dark_Shikari: Did you already try trasher? I wonder what range of parameters you found useful.. [23:40:35] <Dark_Shikari> didn't try it yet

1 0

IRC log for 2010-03-05
by irc＠mansr.com 06 Mar '10

06 Mar '10

[00:23:36] <CIA-92> ffmpeg: conrad * r22213 /trunk/ffplay.c: Just ignore streams with unknown codec_type instead of exiting [00:23:38] <CIA-92> ffmpeg: conrad * r22214 /trunk/libavformat/oggparsetheora.c: [00:23:38] <CIA-92> ffmpeg: oggdec: Parse theora headers since ogg might not mark keyframes [00:23:38] <CIA-92> ffmpeg: Fixes issue746 [00:26:03] <Yuvi> siretart`: recordmydesktop oggs should be fixed [00:26:33] <BBB> before you release, can you wait until my float<->int16 patch is applied? [00:26:57] <DonDiego> that depends on you applying the patch in time :) [00:26:58] <Yuvi> 0.6 or 0.5.1? [00:30:25] <DonDiego> Yuvi: did you just fix the loooooooooooooooooooooooongstanding seeking in theora videos produces artifacts issue? [00:30:47] <Yuvi> shouldn't have [00:31:13] <DonDiego> pity [00:31:20] <Yuvi> (yet at least) [00:31:33] <mru> DonDiego: that issue is old as ogg itself [00:31:48] <Yuvi> this was just that ffmpeg needs to see a keyframe for -vcodec copy, and those oggs had none marked [00:51:09] <CIA-92> ffmpeg: stefano * r22215 /trunk/libavcodec/imgconvert.c: [00:51:09] <CIA-92> ffmpeg: Fix BGR cases missing from depth test in avcodec_get_pix_fmt_loss(). [00:51:09] <CIA-92> ffmpeg: Patch by Janusz Krzysztofik: [00:51:09] <CIA-92> ffmpeg: <${name initial}${surname less the final "ofik"}(a)tis.icnet.pl>. [00:51:45] <DonDiego> i hate these silly cases of email mangling [00:51:53] <DonDiego> the idea is giving people credit [00:52:12] <mru> it was funny the first time [01:00:24] <saste> yes I do it mostly for fun I'm getting tired of the usual mangling methods [01:00:37] <saste> then bots can fetch the mail from the ML [01:00:54] <saste> and humans usually have no problem at deciphering the mangled email [01:28:59] <DonDiego> mru: still around? [01:30:05] <mru> yes [01:30:47] <DonDiego> you saw my commit to bktr.c [01:30:55] <mru> yes [01:30:58] <DonDiego> it's not enough to fix netbsd compilation [01:31:07] <DonDiego> i was talking to michael kostylev in private [01:31:10] <mru> oh dear [01:31:28] <mru> what else did the idiots fuck up? [01:31:37] <DonDiego> the fate box adds -D_NETBSD_SOURCE to the global CFLAGS [01:32:11] <mru> I know [01:32:17] <mru> god knows what that's masking [01:32:28] <DonDiego> sockaddr_storage [01:32:37] <DonDiego> >> /usr/include/sys/socket.h: [01:32:41] <DonDiego> >> #if (_XOPEN_SOURCE - 0) >= 500 || defined(_NETBSD_SOURCE) [01:32:44] <DonDiego> >> struct sockaddr_storage { [01:32:53] <DonDiego> from michael k's mail [01:33:15] <DonDiego> (geez, why is there whitespace in the paste? [01:33:23] <DonDiego> - trailing whitespace) [01:33:51] <mru> already in the email? [01:34:01] <mru> added by mail reader? [01:34:17] <DonDiego> no, not in the email [01:34:41] <DonDiego> normal X copy and paste by middleclick, pasted from an xterm [01:35:20] <mru> spec for sys/socket.h says nothing about that struct being xsi only [01:35:29] <mru> which means it's part of the base standard [01:35:36] <mru> and no _XOPEN_SOURCE is needed [01:35:43] <mru> die, bsd, just die [01:35:49] <DonDiego> the problem here is that _XOPEN_SOURCE is not defined during the configure test [01:36:00] <mru> not relevant [01:36:06] <DonDiego> but defined in rtpdec.c [01:36:07] <mru> it shouldn't be needed to get that struct [01:37:09] <DonDiego> one way to fix this would be defining _XOPEN_SOURCE globally [01:37:33] <DonDiego> the other would be _NETBSD_SOURCE globally [01:37:44] <DonDiego> we turn on __EXTENSIONS__ for solaris [01:37:49] <mru> the first is almost as bad as the second [01:38:18] <DonDiego> what's so bad about the first? [01:38:23] <mru> turning something like on just for netbsd would be acceptable [01:38:48] <mru> we don't want to accidentally start depending on extensions [01:38:56] <DonDiego> _XOPEN_SOURCE for netbsd? [01:39:07] <DonDiego> or _NETBSD_SOURCE for netbsd? [01:39:17] <mru> I'd prefer xopen [01:39:25] <mru> it's more specific [01:39:49] <mru> and should only pull in standard stuff [01:40:05] <mru> there's no telling what _NETBSD_SOURCE might enable [01:40:24] <mru> there are some historic bsd functions that conflict with standard ones [01:40:58] <mru> ask michael k if _XOPEN_SOURCE globally works [01:41:05] <DonDiego> on it... [01:41:25] <DonDiego> apparently using standard posix int types in bktr.c works as well [01:41:45] <mru> ? [01:41:59] <DonDiego> u_int64_t --> uint64_t [01:42:02] <mru> I thought the system bktr.h used nonstandard crap [01:43:11] <DonDiego> ok, let's see what he says [02:21:04] <CIA-92> ffmpeg: michael * r22216 /trunk/ffplay.c: [02:21:04] <CIA-92> ffmpeg: Libavfilter for ffplay support. [02:21:04] <CIA-92> ffmpeg: This still needs some minor work here and there but should be already functional. [02:21:04] <CIA-92> ffmpeg: Note that the code pathes that are under "not avfilter" ifdefs as well as the [02:21:04] <CIA-92> ffmpeg: ifdefs will be droped as soon as all major issues have been det with, aka could [02:21:05] <CIA-92> ffmpeg: be real soon or not. [02:22:05] <Compn> michael : what about libavfilter support for mplayer? :) [02:43:12] <Compn> [aac @ 0p2598230]SBR not implemented. Update your FFmpeg version to the newest one from SVN. If the [02:43:12] <Compn> problem still occurs, it means that your file has a feature which has not been implemented. [02:43:19] <Compn> need to make this error only appear once ^^ [02:43:29] <mru> s/once/never/ [02:43:36] <mru> peloverde: we're waiting... [02:44:00] <ShadowJK> wtf @ yield [02:44:09] <pasteeater> i think 22216 breaks compilation [02:44:11] <pasteeater> http://pastebin.com/qjMzrkUi [02:44:18] <mru> yield is almost always the wrong answer [02:44:25] <ShadowJK> yes [02:44:53] <pasteeater> ...on arch linux x86_64 [02:46:01] <mru> yep [02:46:04] <mru> looking into it [03:03:11] <relaxed> hmm, no problems building SVN-r22216 on debian unstable x86_64 [03:03:36] <mru> it only breaks without --enable-avfilter [03:29:48] <Yuvi> well, I finally figured out the single use of skeleton: getting the first pts right [03:30:20] <mru> lol [03:31:48] <Yuvi> the index uses it too (and actually adds a field for duration), but that's not final so eh [03:37:47] <CIA-92> ffmpeg: michael * r22217 /trunk/ffplay.c: Fix 100l pkt->pos typo. [03:55:34] <CIA-92> ffmpeg: michael * r22218 /trunk/ffplay.c: 10l fix timestamps (lavfi update broke them) [06:01:14] <thresh> moroning [06:54:29] <Dark_Shikari> superdump: fix your blog [06:54:34] <Dark_Shikari> http://rob.opendot.cl/index.php/useful-stuff/ffmpeg-x264-encoding-guide/ is still down [07:20:55] <superdump> Dark_Shikari: well, i need a new host [07:21:07] <superdump> what do you want me to do? unearthquake chile? [07:21:09] <Dark_Shikari> ask mike [07:21:33] <superdump> i'd still need to get all the data from reynaldo [07:21:47] <superdump> i can send him an e-mail though to see what we can do [07:21:47] <kshishkov> superdump: good idea to unearthquake anyway [07:21:48] <Dark_Shikari> true. [07:22:16] <superdump> but i expect he's busy taking care of his wife and kids [07:23:02] <Dark_Shikari> true [07:23:07] <Dark_Shikari> where was the server in chile? [07:23:40] <kshishkov> opendot.cl [07:27:07] <superdump> concepcion i'm guessing [07:27:12] <superdump> i think it was at reynaldo's house [07:27:36] <superdump> his house is fine, but net connections are not stable from what i gather [07:29:01] <Dark_Shikari> ah. [07:29:05] <Dark_Shikari> well, good that his house is fine [07:29:08] <Dark_Shikari> net connections are easier to fix [07:29:29] <superdump> i've kind of wanted to start the site from scratch anyway [07:29:36] <superdump> well [07:29:40] <superdump> keeping some of the content [07:29:47] <superdump> and adding redirects as appropriate [07:29:53] <kshishkov> ask web.archive.org [07:34:07] <superdump> seems to be taking a very long time [07:35:05] <superdump> it hasn't picked up any of the more recent changes [07:35:12] <superdump> the last change it noticed was in 2008 [07:35:54] <kshishkov> it's easier for me - no very useful information on my blog [07:37:34] <astrange> archive.org has a 6 month delay on everything and usually more [07:39:55] <superdump> is archive.org always so sloooow? [07:40:20] <kshishkov> no, it depends on popularity of site [07:40:46] <kshishkov> could be slower [07:42:25] <superdump> you mean low ranked sites only allow one person to view them per day [07:42:27] <superdump> ? [07:42:32] <superdump> omg! [07:42:36] <superdump> it loaded something! [07:42:53] <andoma> good morning [07:43:00] <kshishkov> I've read that archive.org gets its data mostly from alexa.com [07:43:04] <kshishkov> god morgon [07:43:18] <superdump> oh dear, it's not even a version that has preset support [07:43:21] <superdump> not surprising though [07:43:26] <superdump> oh well [07:43:48] * superdump goes back to reviewing michael's review of he aac [07:43:54] <kshishkov> there's also google cache ;) [07:45:02] <astrange> one or two things he asked were the same things i asked, i should have phrased that as "please name usb something else" [07:46:56] <kshishkov> wrong channel? [07:47:40] <astrange> usb is the name of a variable in aacsbr [07:48:07] <kshishkov> ah [07:48:54] <kshishkov> yes, a bit misleading name unless there are also variables like "iLink", "com", "lpt" [08:03:50] <superdump> Dark_Shikari: http://74.125.77.132/search?q=cache:TK96XlO5grYJ:rob.opendot.cl/index.php/u… [08:04:06] <Dark_Shikari> I know about the cache [08:09:03] <KotH> moin [08:09:23] <kshishkov> gruss dich [08:16:10] <CIA-92> ffmpeg: mstorsjo * r22219 /trunk/libavformat/rtpproto.c: Return from rtp_read when select returns an error [08:27:14] <CIA-92> ffmpeg: benoit * r22220 /trunk/ (3 files in 2 dirs): [08:27:14] <CIA-92> ffmpeg: Add initial support for 12-bit color mode. [08:27:14] <CIA-92> ffmpeg: Patch by Janusz Krzysztofik jkrzyszt tis icnet pl [08:27:14] <CIA-92> ffmpeg: Original thread: [08:27:14] <CIA-92> ffmpeg: Subject: [FFmpeg-devel] [PATCH v2] Add initial support for 12-bit color mode. [08:27:15] <CIA-92> ffmpeg: Date: Mon, 1 Mar 2010 02:05:07 +0100 [08:35:21] <CIA-92> ffmpeg: benoit * r22221 /trunk/doc/swscale.txt: [08:35:21] <CIA-92> ffmpeg: Update SW scaler doc after libswscale commit 30841. [08:35:21] <CIA-92> ffmpeg: Patch by Janusz Krzysztofik jkrzyszt, tis icnet pl. [09:11:18] <siretart`> Yuvi: verified, that ogv works now. do you think it is really just that onliner? in that case, I'd nominate it for the 0.5 branch [09:11:58] <kshishkov> too late, 0.5.1 is out and we're moving towards 0.6 [09:12:49] <siretart`> kshishkov: indeed, but still interesting for distro packages. [09:14:00] <siretart`> no, it is not just r22214 :-( [10:41:20] <Yuvi> siretart`: dunno what else might be needed, don't see anything else that could fix it since 0.5 unless it crashed [10:58:02] <siretart`> Yuvi: no, it doesn't crash. the video just looks very disorted [10:58:12] <Yuvi> oh [10:58:24] <Yuvi> that's theora's 3 quant [10:58:32] <Yuvi> which probably I added after 0.5 [10:59:16] <siretart`> oh, that means that's rather a new feature than a regression. I see [11:01:49] <twnqx> is there a spline36 resizer in swscale? [11:12:55] <CIA-92> libswscale: cehoyos * r30840 /trunk/libswscale/ (yuv2rgb.c swscale.c swscale_internal.h): [11:12:55] <CIA-92> libswscale: Support BGR555, BGR565, RGB555 and RGB565 foreign endian output in [11:12:56] <CIA-92> libswscale: libswscale. [11:12:56] <CIA-92> libswscale: Patch by Alexis Ballier, alexis D ballier A gmail [11:12:57] <CIA-92> libswscale: benoit * r30841 /trunk/libswscale/ (yuv2rgb.c swscale.c swscale_internal.h): [11:12:58] <CIA-92> libswscale: libswscale: Extend the unaccelerated path of the unscaled yuv2rgb special [11:12:58] <CIA-92> libswscale: converter with support for rgb444 output format. [11:12:59] <CIA-92> libswscale: Patch by Janusz Krzysztofik jkrzyszt chez tis icnet pl [11:12:59] <CIA-92> libswscale: benoit * r30842 /trunk/libswscale/yuv2rgb.c: Cosmetics: fix vertical alignment. [11:14:54] <peloverde> I just found my copy of the old Coding Technologies aacPlusDecoderCheckPackage, I'm a little scared to run it [11:15:26] * twnqx svn ups [11:15:55] <thresh> this checkout is going to be legen....wait for it...dary?! [11:16:27] <twnqx> no, i do it daily to hope that i finally can convert flac to alac and keep my tags [11:16:50] <twnqx> s/to/and [11:16:51] <DonDiego> peloverde: go for it :) [11:17:59] <peloverde> I will shortly, I'm fixing some issues michael found [11:18:53] <jai> twnqx: ? [11:19:02] <jai> raw flac? [11:19:03] <twnqx> the author/artist thingy [11:19:30] <jai> hmm [11:20:41] <twnqx> libavcodec/vc1dec.c:2319: warning: suggest parentheses around operand of ‘!’ or change ‘&’ to ‘&&’ or ‘!’ to ‘~’ <- should i be worried? [11:21:14] <twnqx> /usr/lib/gcc/x86_64-pc-linux-gnu/4.4.2/../../../../x86_64-pc-linux-gnu/bin/ld: libavutil/lls.o: relocation R_X86_64_PC32 against undefined symbol `memset@@GLIBC_2.2.5' can not be used when making a shared object; recompile with -fPIC [11:21:15] <twnqx> /usr/lib/gcc/x86_64-pc-linux-gnu/4.4.2/../../../../x86_64-pc-linux-gnu/bin/ld: final link failed: Bad value [11:21:18] <twnqx> argh, that's new [11:22:21] <DonDiego> twnqx: yes, worry that everybody ignores warnings instead of fixing them.. :-( [11:22:27] <DonDiego> kshishkov: your code.. [11:22:30] <jai> twnqx: gentoo? [11:22:33] <twnqx> yeah [11:22:36] <jai> heh [11:22:43] <twnqx> but manual compile [11:23:15] <Dark_Shikari> lets say I run for s in 1 2 3;do bash -c 'mycommand $s';done [11:23:21] <Dark_Shikari> how do I get $s to propagate into the subshell? [11:24:00] <twnqx> do export s; bash -c ... ? [11:24:01] <jai> twnqx: -fpic missing, thats strange [11:24:17] <Dark_Shikari> twnqx: great, thx [11:24:30] <Dark_Shikari> I now have an ffmpeg fuzzer set up [11:25:15] <Dark_Shikari> Any particular people want fuzzed? [11:25:21] <Dark_Shikari> I'm fuzzing h264 + aac in mkv right now. [11:25:44] <jai> Dark_Shikari: the mov/mp4 demuxer [11:26:17] <Dark_Shikari> http://pastebin.org/101646 <--lazy 5 minute fuzzer [11:26:18] <Dark_Shikari> usage: [11:26:22] <Dark_Shikari> ./fuzzer inputfile outputfile [11:26:53] <Dark_Shikari> example usage: [11:26:54] <Dark_Shikari> for a in $(seq 20);do echo $a;./fuzzer IronMan.mkv IronMan.$a.mkv;export a;bash -c 'ffmpeg -y -i IronMan.$a.mkv output.avi > test2.txt 2>&1' 2> failures.txt;done [11:27:06] <Dark_Shikari> failures.txt will hold "segmentation fault" if something failed [11:27:16] <Dark_Shikari> hmm, I should make it so that failures.txt holds _which_ number it was [11:27:24] <Dark_Shikari> test2.txt holds the log [11:27:41] <Dark_Shikari> oh, guess I need to do 2>> failures.txt too [11:29:13] <twnqx> jai: CFLAGS=-fPIC ./configure .. did the trick [11:29:58] <jai> twnqx: ofcourse, my point was it should be set correctly by configure :) [11:30:32] <twnqx> (in #mplayer) <zak_> is it possible to extract audio from a powerpoint file? [11:30:39] <twnqx> we need a ppt demuxer! [11:31:06] <twnqx> oh he asked i ffmpeg, too [11:31:15] <jai> people must be doing moroccan black again [11:37:26] <kshishkov> DonDiego: the same offer as for Reimar - place parentheses if you feel that's right [11:38:44] <kshishkov> twnqx: that would be common OLE dungheap demuxer for old M$ Office documents [11:39:20] <twnqx> kshishkov: i'd go for && instead of & [11:39:39] <twnqx> if(!coded_inter) coded_inter = !is_intra[i] & is_coded[i]; <- or is there a reason to use binary? [11:40:23] * janneg failed with that [11:41:00] <twnqx> since i don't know if it's supposed to really mask a single bit i can't guarantee [11:41:01] <janneg> twnqx: there are fears that && creates slower code [11:41:27] <jai> you could always inspect gcc's output [11:41:48] <kshishkov> and everybody (starting with me) is too lazy to benchmark and apply either solution [11:41:59] <janneg> the code differs [11:42:34] <twnqx> does it differ with (), too? [11:43:01] <DonDiego> kshishkov: why didn't you add them in the first place? :-( [11:43:09] <DonDiego> kshishkov: please don't just ignore warnings.. [11:43:13] <janneg> it shouldn't but I haven't tried [11:44:24] <jai> or just disable that warning, since most people seem to be allergic to it [11:45:30] <jai> -Wno-parentheses iirc [11:48:19] <kshishkov> DonDiego: honestly, I don't remember. And I don't think it was printed by older GCCs. [11:49:43] <DonDiego> yes, it's new, but that should not stop you from fixing it :) [11:50:41] <kshishkov> yes, but the feeling that GCCs silently redefine operator precedence and come with warnings to cover that does [11:51:28] <twnqx> if it's legal to redefine them you should have been worried from the beginning [11:51:54] <twnqx> is there a certain degree of randomness in gcc's code generation? [11:52:49] <twnqx> if not, using && instead of & canges the evaluation order of the term, and consequently register allocation etc [11:52:56] <kshishkov> no, it's uncertainly large [11:53:30] <twnqx> what i meant is: if i'm running the same .c file through it twice, should i getthe same .s file? [11:53:46] <kshishkov> you should [11:54:15] <twnqx> because i did the & vs. && change, and i see labels and register/temporary variable address allocation changed [11:55:08] <kshishkov> first is simple AND, the second is "if !a set 0 else set !!b" [11:56:07] <twnqx> excuse my while i read 6690 lines of diff -u to find more than label/offset/register changes [11:56:37] <kshishkov> and for me that GCC warning sounds like "hello, in future your expression will be evaluated as 'coded_inter = !(is_intra[i] & is_coded[i]);', dont forget parentheses now or we'll silently screw it later" [11:56:57] <twnqx> is precedence of ! vs. & defined? [11:57:10] <kshishkov> look into K&R [11:57:44] <twnqx> i don't have the book, and i personally just silence the warnings [11:58:01] <kshishkov> first is unary operator and they should have the highest priority [11:58:06] <twnqx> just in case i might be scrwed in a later release [11:58:34] <DonDiego> #if (!defined(__ICC) || __ICC > 1110) && AV_GCC_VERSION_AT_LEAST(4,2) [11:58:40] <DonDiego> this is confusing [11:58:43] <DonDiego> why not [11:59:06] <twnqx> ICC generates a GCC version? [11:59:07] <DonDiego> #if (__ICC > 1110) || AV_GCC_VERSION_AT_LEAST(4,2) [11:59:14] <DonDiego> or even better [11:59:32] <DonDiego> #if AV_ICC_VERSION_AT_LEAST(1110) || AV_GCC_VERSION_AT_LEAST(4,2) [11:59:46] <kshishkov> it won't work when it's GCC :) [12:00:13] <DonDiego> why should it not? [12:00:31] <twnqx> the first one, coause __ICC will not be defined. the second one should [12:00:55] <kshishkov> ah, it may fail in case when __ICC > 1100 and it cannot pretend to be GCC 4.2 [12:00:58] <DonDiego> twnqx: summary: it should work [12:01:03] <kshishkov> the question if that's possible [12:01:18] <twnqx> yes [12:01:35] <DonDiego> does anybody here have icc? [12:01:46] <kshishkov> Carl should [12:09:09] <twnqx> yuck, compiler inlines the full vc1_decode_p_mb function [12:09:48] <Dark_Shikari> if it's only called once wouldn't it surely be inlined? [12:10:11] <kshishkov> once per macroblock [12:10:13] <twnqx> yeah, but makes finding the code close to impossible since there are no line numbers in the .s [12:10:20] <Dark_Shikari> add noinline [12:10:30] <twnqx> that might change the code [12:11:10] <twnqx> also... i HATE AT&T syntax with a passion [12:11:40] <kshishkov> well, not being on x86 helps [12:11:46] <twnqx> heh [12:11:54] <Compn> kshishkov : help me find 'eidos escape video studio' program so i can make some samples :) [12:12:00] <peloverde> twnqx, well they invented UNIX, C, and information theory so sometimes we just need to live with their mistakes [12:12:30] <kshishkov> Compn: ok, I'll try [12:12:47] <kshishkov> peloverde: sometimes those were different people [12:12:50] <twnqx> cmovge <- i'm so far out of asm i don't even know what this opcode does [12:13:02] <kshishkov> conditional move [12:13:16] <twnqx> oh [12:13:24] <kshishkov> if previous compare result was "greater or equal" [12:13:27] <twnqx> that would have been useful back in the 386 days [12:14:06] <kshishkov> it was - on ARM [12:18:49] <twnqx> kshishkov: i conclude: && will be slower than & [12:19:12] <kshishkov> Compn: probably you'd have to ask some videogame dev to leak it to you, it's unlikely to be used outside inhouse dev process :( [12:19:17] <twnqx> it really generates extra code [12:19:38] <kshishkov> twnqx: indeed. And I'd rather see GCC fixed not to display idiotic warnings [12:20:40] <twnqx> the () do not generate any difference [12:20:49] <kshishkov> it should not [12:21:43] <twnqx> i assume both variables are either 0 or 1 all the time? [12:21:51] <kshishkov> yes [12:32:29] <elenril> wtf [12:32:46] <elenril> apparrently my system downloads stuff faster if it's doing some i/o [12:36:03] <Compn> kshishkov : no, it was an actual codec for quicktime... also there was a demo but eidos' site is gone and the links are all 404 [12:36:07] <KotH> elenril: what kernel version? [12:36:35] <Compn> kshishkov : old 404 links to demo >> http://www.siggraph.org/education/materials/HyperGraph/video/codecs/Escape.… [12:37:21] <DonDiego> http://samples.ffmpeg.org/V-codecs/3ivx/ [12:37:24] <DonDiego> are these samples supposed to work with ffmpeg? [12:37:27] <elenril> KotH: 2.6.33 [12:37:36] <DonDiego> it does not work here even after changing the preprocessor check in mpeg4video.h [12:37:37] <KotH> elenril: have a look at dmesg [12:37:43] <KotH> elenril: do you have any oopses? [12:37:56] <KotH> elenril: page alloc failures, that is [12:38:40] <elenril> no [12:39:17] <Compn> DonDiego : file roundup issue for it :P [12:39:39] <elenril> there's one i/o error. but these happen quite often, i blame dm-crypt [12:49:22] <Compn> DonDiego : file roundup issue for 3ivx [12:51:50] <DonDiego> hmm, well, ok... [13:06:19] <DonDiego> mru: your blog appears to be down [13:09:07] <DonDiego> mru: adding -D_XOPEN_SOURCE=600 fixed compilation on netbsd [13:09:19] <DonDiego> are you ok with adding that to cppflags in configure then? [13:11:39] <ShadowJK> I wonder if he got slashdotted (or whatever the modern equivalent is), I saw the link posted outside freenode in non-multimedia channels.. [13:12:09] <KotH> again? [13:12:15] <DonDiego> reddit? ycombinator? [13:12:30] <peloverde> he was on /. [13:12:52] <kierank> there's also a post on the bbc backstage mailing list about how bad ogg is as well [13:24:19] * mru curses web servers [13:24:28] <mru> my lighttpd sometimes just stops serving anything [13:24:38] <thresh> me likey nginx. [14:10:51] <mru> lol@dilbert "evil is the cure for incompetence" [14:11:12] <kshishkov> you should know that for ages [14:12:10] <kshishkov> when I was promoted to project manager I'd been asked to study something other than Dilbert for project management for some reason [14:12:43] <KotH> lol [14:12:48] <mru> dilbert is how real companies actually work [14:13:52] <kshishkov> I suspected that [14:15:43] <kshishkov> still, there may be some differences. Like competent management is not always pointy-haired [14:16:26] <mru> the difference is that _incompetent_ management is not always pointy-haired [14:16:34] <mru> which makes them harder to spot at a distance [14:17:12] <mru> to assess the competence of a manager, check how often he's changed groups/projects [14:17:32] <mru> frequent changes w/o a promotion mean he's a problem being shuttled around [14:17:38] <mru> but not bad enough to be fired on the spot [14:18:01] <mru> frequent promotions mean he's an arse-licking bastard [14:18:24] <kshishkov> or somebody's relative [14:18:34] <KotH> if in japan, check whether his office has only a single desk facing the window ;) [14:18:44] <mru> it means promotion was the simplest way to get him off your back [14:18:52] <mru> KotH: :-) [14:19:02] <mru> also check for red staplers... [14:19:10] <KotH> red staplers? [14:19:21] <kshishkov> KotH: "an ilk of looking into the window" or something, forgot that expression [14:19:22] <mru> not seen Office Space? [14:20:21] <kshishkov> a big mistake, I must say [14:20:43] <kshishkov> (not to see it) [14:21:13] * kshishkov wonders why http://en.wikipedia.org/wiki/C._Northcote_Parkinson is not listed as the greatest economist [14:22:01] <KotH> mru: nope [14:22:12] <KotH> mru: torrent? rsync server? [14:23:21] <kshishkov> KotH: should be available everywhere, it's a cult movie [14:23:47] <KotH> ofc, but i'm lazy :) [14:24:29] <BBB> DonDiego: can you still help get the vso 20k? [14:24:43] <BBB> dondiego: or should I do it through foundation? (that'll involve considerable paperwork here) [14:44:21] <peloverde> Is there a way to shut up gcc about multilevel const issues short of tossing casts everywhere? [14:44:43] <kshishkov> -Wsomething [14:47:53] <BBB> -Wnone? [14:48:14] <bilboed-pi> -Wburied-somewhere-deep-in-the-gcc-manpage [14:48:17] <kshishkov> yes, GCC devs seem to stealthly advertise it more and more [14:48:35] <peloverde> All I can find is -Wcast-qual which has other side effects [14:48:44] <DonDiego> BBB: what sort of paperwork? [14:49:21] <BBB> me or you? [15:09:59] <BBB> peloverde: are you busy today? [15:10:27] <peloverde> BBB: Just working on implementing michael's feedback on the SBR patch [15:10:32] <peloverde> do you need something? [15:11:12] <BBB> let's say I have this code for a postfilter and I rewrote it in float to use all FFmpeg RDFT code... I still don't actually know what it does [15:11:48] <BBB> I'm hoping to show it to you so you can tell me what every step does (so I can add comments, make up useful function names, learn something useful) [15:12:06] <BBB> it's 700LOC [15:12:09] <BBB> approximately [15:12:15] <peloverde> I can take a look and try to explain [15:12:42] <BBB> including tables [15:14:32] <peloverde> e-mail it or pastebin it or something like that [15:15:23] <BBB> http://ffmpeg.pastebin.com/9VdR7pMA [15:17:26] <peloverde> ok, it will take me a little while to digest that [15:17:34] <BBB> basically the apf() function, and all stuff it calls [15:18:32] <BBB> and sorry if some variable names are bad, it's still in a pretty rough state while I try to understand the code [15:19:04] <BBB> if variables have a name other than "tmpXX", "varXX" or "arrXX", it should somehow make sense [15:22:09] <kshishkov> BBB: lines 567-580 remind me of lowpass IIR filter [15:22:55] <BBB> iir=synthesis [15:23:01] <BBB> so lowpass speech synthesis? [15:23:05] <BBB> hmm... [15:23:36] * kshishkov has employed lowpass IIR filetr in AAC encoder for cutting off high frequencies [15:23:38] <BBB> oh yeah sorry for those macro names, I think I was getting annoyed at that point for not getting something [15:24:01] <kshishkov> so you wanted to get revenge at expence of reviewer? ok [15:24:50] <BBB> I thought it was funny [15:25:22] <kshishkov> lines 555-563 look like a windowing [15:26:36] <kshishkov> farr13 is obviously a thing you could've renamed by yourself [15:26:51] <BBB> some of those I'll get rid of [15:26:55] <BBB> there's a lot of useless memcpy()s [15:27:02] <BBB> I already cut half [15:27:07] <peloverde> 555-563 look like some sort of filter to me, not windowing [15:27:09] <BBB> I can probably get rid of another 50% of the remainder [15:27:50] <BBB> so arrays are not yet named because they shouldn't be there, period [15:28:08] <kshishkov> peloverde: yes, but that f(n) = (0.99 + c)^n is a bit suspicious [15:30:56] <peloverde> kshishkov, but it isn't quite (0.99 + c)^n [15:31:10] <peloverde> f(n) = 0.99*f(n-1) + c [15:31:36] <peloverde> you'll never wind up with c^n type terms [15:35:00] <BBB> isn't it gain transition smoothing? [15:35:33] <BBB> (if that's a term) [15:35:38] <BBB> that's about all I got from it [15:35:56] <BBB> and I'm interested especially in your take on 503-526 [15:36:07] <BBB> that's the frequency domain filter [15:36:16] <BBB> but whatever it's doing inside there is like black magic to me [15:37:31] <BBB> (and I assume the stuff before, line 466-488, is an echo filter?) [15:40:16] <peloverde> BBB FYI a dsputil version of ff_dot_productf exists [15:40:44] <kshishkov> maybe that stuff is used to smoothe frequencies around peaks (and peaks ~= impulses in LPC) [15:42:20] <BBB> peloverde: I'll optimize/dsputilize after it's in SVN [15:42:28] <BBB> first I want a version in SVN that works and is clear [15:42:48] <BBB> that's one good thing I learned in Glib/GNOME - first make it work, then optimize it [15:43:07] <BBB> unfortunately most people never make it to level 2 [15:43:52] <peloverde> I think one thing that would be helpful is going through and marking what is real and what is complex [15:45:51] <peloverde> The RDFT calls do make it a little tricky because they transform the two [15:51:13] <BBB> right [15:51:33] <BBB> esp. because it's all in the same buffers [15:54:53] <BBB> wbs: can you implement the URLProtocol caps field as suggested by Michael & me in that thread? [15:54:59] <BBB> if not, I'll try this weekend [15:55:04] * BBB seriously low on time now [15:57:41] <kshishkov> BBB: any FT can be done in the same buffer - first you need to reorder coeffs by swapping and then perform a lot of butterflies with phase coeffs ;) [15:58:21] <BBB> well the problem is that I have no idea what the data in the buffer means before and after the FT [15:58:25] <BBB> I start with lpcs [15:58:32] <BBB> then I FFT the lpcs (RDFT) [15:58:37] <BBB> I have no idea what I have now [15:58:51] <BBB> and so on [16:00:42] <kshishkov> well, lines 94-96 are complex multiplication [16:01:32] <wbs> BBB: I'll see if I have the time to try it out or if you beat me to it [16:01:32] <peloverde> Yes, that's multiplying the FFT of the filter by the FFT of the signal [16:02:21] <kshishkov> so it's really complex numbers in <Re Im> <Re Im> ... order [16:02:40] <wbs> BBB: but generally, I don't think that netinit is all that expensive to perform a few times extra for non-network protocols [16:02:43] <BBB> yes, that's both complex [16:02:56] <wbs> and that would be within #if CONFIG_NETWORK anyway, I guess [16:03:19] <BBB> wbs: I was thinking that we shouldn't do it for e.g. file, hnce my suggestion of the extra CAP field [16:03:46] <wbs> BBB: yeah, that's a good idea generally, but given that it'd break abi, I don't feel that it's all that important [16:04:00] <BBB> hence my suggestion of the version #ifdef [16:04:07] <BBB> but like I said, might be too much effort for no gain [16:04:10] <BBB> I don't know [16:04:14] <BBB> I'll leave it up to you [16:04:18] <BBB> Michael seems OK with both [16:04:24] <BBB> so do whichever seems better to you [16:04:39] <BBB> I could always change it later, I guess [16:04:57] <wbs> ok.. I guess I could try to benchmark ff_network_init() and see how slow it really is [16:05:26] <BBB> it does nothing (on Linux) [16:05:33] <BBB> or mac [16:05:37] <wbs> yeah, I know, I meant on windows :-) [16:05:41] <BBB> ah, ok [16:05:49] <wbs> so for most normal platforms it doesn't really matter anyway [16:07:18] <BBB> maybe that's why Michael doesn't care [16:07:19] <BBB> :) [16:07:43] <wbs> exactly, and I doubt all that many do multithreaded/intensive server-stuff with libavformat on windows anyway [16:08:09] <BBB> fair enough, can you do it in url_open/close() then? [16:08:16] <BBB> assuming your benchmarking is ok [16:08:46] <wbs> yeah, I'll benchmark it on windows and try that one out; I'm not sure if I have the time to test it out tonight or tomorrow, but soonish anyway [16:09:25] <wbs> I guess it will be #if CONFIG_NETWORK ff_network_init() #endif in url_open and url_close then, right? [16:12:13] <BBB> yes [16:14:13] <wbs> ok, so not all that elegant either, but at least confined to a few small places [16:15:00] <peloverde> BBB: unfortunately I don't know much about LPCs which puts me a a disadvantage when trying to decipher the early parts of the code [16:15:21] <BBB> hm, ok... maybe I should bug vitor also then [16:15:32] <BBB> I don't really know lpcs either btw [16:16:31] <kshishkov> BBB: look at libavcodec/truespeech.c - that's all _I_ know about speech codecs [16:16:44] <BBB> still more than me [16:16:54] <BBB> not for long, hopefully <evil smile> [16:16:55] <peloverde> The fact that the 3rd input to _DoFilterProjection is treated as angles seems interesting [16:17:10] <kshishkov> BBB: no, look there for real [16:17:36] <peloverde> _DoFilterProjection is just farr1 = farr2 .* exp(j*in) [16:18:58] * BBB poses that kshishkov has interesting ways of "RE'ing" a codec [16:19:03] <peloverde> someone with better LPC knowledge, vitor or maybe ruggles might have better luck with the earlier sections of the code [16:19:27] <BBB> kshishkov: that codec is in a rough state, I wouldn't have been comfortable committing it like that :> [16:20:14] <kshishkov> BBB: look at copyright date, rules were easier those days [16:20:21] <BBB> aha [16:20:28] * kshishkov does not have much luck with audio codecs though [16:21:58] <BBB> peloverde: but yes, many of these functions do very simple math [16:22:12] <BBB> peloverde: I'm interested in what the math *means*, rather than what it *does* [16:22:28] <BBB> I know what it does, I simplified it to 1-10 LOC :) - I have no idea what it means, though :-( [16:22:46] <DonDiego> BBB: what paperwork do you need to do? [16:22:59] <peloverde> The fact that it does do simple math, may give you clues what it means though [16:23:16] <peloverde> Like the fact that in is angles is important [16:23:22] <BBB> dondiego: "hire" michael as an employee, which might not be easy, or do extra taxpaperwork to take him as a consultant [16:23:32] <BBB> right now I've set up the foundation to not be able to hire people [16:23:35] <BBB> tax sucks anyway [16:24:02] <BBB> peloverde: what's your take on 431-434? [16:24:25] <BBB> peloverde: it does FFT, then shifts all RE into IM and zeroes the RE and then does iFFT [16:24:28] <BBB> what does that mean? [16:24:36] <DonDiego> how can the foundation spend money then? [16:24:44] <kshishkov> BBB: mirroring [16:24:46] <BBB> dondiego: grands, expenses [16:24:59] <BBB> dondiego: "hiring" people is a little more complicated [16:25:15] <BBB> I can hire him as a consultant right now, but then me and he will be taxed for that [16:25:23] <BBB> I don't care so much, but he might [16:25:40] * BBB needs an accountant [16:26:06] <BBB> kshishkov: ? [16:26:24] <BBB> kshishkov: sorry, that's probably a famous term, but I'm not sure I know what it means [16:26:36] <BBB> don't forget this still is my first codec [16:26:40] <kshishkov> BBB: lines 431-434 look like they mirror lower half coeffs [16:27:22] <BBB> I meant 443 [16:27:28] <BBB> the code under that, after the loop [16:27:29] <BBB> sorry :) [16:27:45] <kshishkov> ah [16:27:55] <BBB> note how I do rdft_calc(farr+1), and then Irdft_calc(farr) [16:28:29] <BBB> the original code actually does for (n=0;n<0x41;n++) im=re; re=0; [16:30:53] <BBB> 0x40, not 0x41, but anyway [16:31:01] <kshishkov> you could use analytics here [16:31:03] <peloverde> hilbert transformer@ [16:32:04] <BBB> that wikipedia page is scary [16:32:12] * BBB wishes he had continued math in college now [16:32:42] * kshishkov had math only for 1.5 years at his university [16:33:37] <peloverde> When you go from real to imaginary there is an implied part of the spectrum that is conjugate symmetric [16:33:46] <peloverde> so it goes from real to imaginary with the opposite sign [16:37:52] <BBB> I think I'm gonna get a math textbook to understand that wikipedia page [16:38:06] <BBB> do you guys have mathbook suggestions? [16:38:12] <BBB> I can probably get them cheaply in the uni bookshop [16:38:51] <kshishkov> anything by German authors ;) [16:39:17] * BBB will be right back [16:39:36] <peloverde> If you mean a generic calculs type text then no, if you mean signal processing math then I'm biased toward Haykin VanVeen and Lathi [16:39:39] <janneg> if the author is dead for at least 50 years [16:44:45] <DonDiego> peloverde: link? [16:45:08] <DonDiego> BBB: then how about a grant? [16:46:57] * mru has signals&systems by oppenheim&willsky [16:47:04] <mru> made sense back when I read it [16:47:37] <kshishkov> not anymore? [16:47:44] <mru> don't know [16:47:55] <mru> haven't opened it in a long time [16:47:59] * kshishkov is not sure he's read something serious about signal processing at all [16:49:23] <mru> that was the recommended textbook in uni [16:50:14] <kshishkov> you must be liberal, here they just told you what to read (and that's all you could get at the library too) [16:50:55] <mru> we were allowed to read anything of course [16:51:03] <mru> so long as we passed the exams nobody cared [16:51:19] <mru> lectures usually followed some book though [16:51:27] <mru> so it was a good idea to get the recommended one [16:51:54] <mru> on a couple of courses I used similar books my brother already had [16:53:09] <kshishkov> well, mine KTH was definitely worse than yours [16:53:27] <kshishkov> (but it produces crap in rather large quantities) [17:18:23] <mru> kshishkov: http://www.theregister.co.uk/2010/02/24/iplayer_xbmc_adobe_swf_verification/ [17:19:48] <kshishkov> nice [17:19:57] <mru> well, can you fix it? [17:20:07] <mru> we're not afraid of the dmca are we? [17:20:12] <kshishkov> no, BBC is not fixable [17:20:46] <kshishkov> and in my position the less people use that crap the better [17:20:52] <kierank> presumably because ffmpeg has no knowledge of the swf file? [17:21:06] <mru> kierank: it's an rtmp thing [17:21:30] <kierank> yes, but swf verification afaik is a hash of the swf file that is needed to authenticate [17:21:52] <kshishkov> theoretically it's easy to record official iPlayer session and if they haven't complicated it, fixed reply should be enough [17:21:56] <mru> if iplayer can do it, so can we [17:22:06] <kierank> get_iplayer still works [17:22:38] <mru> DRM rule #1: there is no protection [17:23:07] <Dark_Shikari> kshishkov: so I hear you want to get out of ukraine [17:23:12] <kshishkov> see one of Michael's sigs [17:23:17] <mru> summary of drm: here's a lock and a key, please don't use the key in the lock [17:23:20] <kshishkov> Dark_Shikari: doesn't everybody? [17:23:37] <mru> kshishkov: only those who are in to begin with [17:23:40] <Dark_Shikari> seriously though, what's the issue? =p [17:23:47] <mru> Dark_Shikari: it's a back-water [17:23:49] <kshishkov> mru: local corrolary: there's always a hole in the wall anyway [17:24:39] <Dark_Shikari> well that's a given [17:24:45] <kshishkov> Dark_Shikari: it's mostly a matter of somebody pulling me to other land [17:24:46] <Dark_Shikari> I guess the crappy internet is a good enough reason to move [17:25:06] <Dark_Shikari> I was just wondering if it was some particular event/crappy thing going on [17:25:07] <kshishkov> crappy everything [17:25:12] <Dark_Shikari> or just ukraine in general sucking [17:25:16] <mru> Dark_Shikari: the only difference compared to the ussr is that now they can choose their bureaucrats [17:25:29] <Dark_Shikari> e.g. right now, the UK and Australia both have great reasons to gtfo [17:25:45] <kshishkov> Dark_Shikari: it's almost perfect in sucking [17:25:53] <KotH> mru: hint: if the copyprotection system goes even a tad bit over a very narrow description of what a copy protection system does, then it isn't protected by law. ie it is legal to break it and distribute the tools to do so [17:25:59] <KotH> mru: at least in .ch :) [17:26:02] <kierank> Dark_Shikari: it's getting torn to pieces in the house of lords anyway [17:26:18] <Dark_Shikari> kierank: "it" can mean various different things [17:26:29] <mru> kierank: what? mandy's stupid law? [17:26:29] <Dark_Shikari> I'm pretty sure they're not tearing your cameras to pieces :) [17:26:38] <kierank> mru: yes [17:27:19] <Dark_Shikari> hopefully this continues and it doesn't pass. [17:27:23] <CIA-92> ffmpeg: vitor * r22222 /trunk/libavformat/utils.c: Fix memory leak in NUT muxer [17:27:25] <Dark_Shikari> then again, australia is still royally fucked [17:28:13] <kierank> won't pass before the election anyway [17:28:14] <kshishkov> Dark_Shikari: strong selling points - no useful infrastructure, food gets crappier each year, no real perspectives [17:29:06] <elenril> mafia in the goverment? [17:29:40] <Dark_Shikari> sounds just like everywhere else then [17:29:50] <mru> does anyone know a decent, free country? [17:30:05] <Dark_Shikari> saveden [17:30:09] <Dark_Shikari> iculando [17:30:11] <kshishkov> elenril: the term "Dniepropetrovsk mafia" describing local government was coined in Brezhnev times [17:30:15] <Dark_Shikari> finulando [17:30:37] <mru> I have doubts about sweden [17:30:38] <kshishkov> mru: jag vet om gamla och fria land [17:30:42] <mru> don't know about .fi [17:30:42] * elenril heard chocolateland is nice [17:30:47] <mru> language is a bitch there [17:30:47] <Dark_Shikari> sweden seems to be doing pretty well [17:30:58] <Dark_Shikari> oh yeah, Netherlands [17:31:00] <mru> .se has fast internet, that's about it [17:31:12] <kshishkov> mru: one of those languages, the second language is fine [17:31:17] <mru> .nl has a learnable language at least [17:31:28] <mru> kshishkov: swedish only works in parts of finland [17:31:31] <Dark_Shikari> mru: don't even need to [17:31:36] <Dark_Shikari> I know a guy who worked out of nl for like 7 years [17:31:39] <Dark_Shikari> he never learned the language [17:31:39] <mru> you'd have to learn finnish eventually [17:31:46] <Dark_Shikari> he said it worked fine [17:31:52] <mru> sure it would work [17:31:56] <Dark_Shikari> apparently the .nl guys are really picky about their language too [17:31:58] <mru> but if I lived there I'd learn it [17:32:05] <kshishkov> mru: at least it's interesting from linguistics PoV [17:32:08] <mru> I can pretty much read it [17:32:09] <Dark_Shikari> i.e. if you get it even very slightly wrong, they get mad and ask you to use english [17:32:12] <Dark_Shikari> =p [17:32:41] <kierank> could live with all the british expats in the south of spain [17:32:57] <Dark_Shikari> meh, spain [17:33:01] <Dark_Shikari> the rain in spain falls mainly on the plain [17:33:12] <mru> I know some nice spanish girls [17:33:47] <kshishkov> mru: asked Diego? [17:33:51] <Dark_Shikari> japan works mostly fine if you're willing to put up with absurdly high rent and being a gaijin for the rest of your life [17:33:56] <mru> germany has issues [17:34:07] <Dark_Shikari> south korea works well if you're willing to learn a mostly useless languaZERG RUSH KEKEKEKEKEKEKEK [17:34:16] <mru> I don't think I could put up with japan in the long term [17:34:30] <mru> korean language is hard [17:34:37] <Dark_Shikari> it's easier than japanese iirc [17:34:39] <mru> nice people though [17:34:40] <Dark_Shikari> taiwan works well if you're willing to put up with a hilariously insane political system [17:34:42] <mru> harder than japanese [17:34:48] <mru> easier script [17:34:55] <kshishkov> Dark_Shikari: here it's both absurdly high rent and mostly useless language let alone political system [17:35:19] <kshishkov> mru: maybe you don't play Starcraft enough [17:35:28] <Dark_Shikari> Just watch pro starcraft for a year or two [17:35:34] <Dark_Shikari> and you will get used to the soothing voices of korean commentators [17:35:49] <mru> I know what korean sounds like [17:35:55] <kshishkov> mru: also it's fiendishly easy script - no spaces or other means of divinding words [17:35:59] <Dark_Shikari> puroxy roboticuso bay! [17:36:06] <peloverde> If you like the sound of Korean, work on the BSAC decoder! [17:36:07] <mru> kshishkov: they do have spaces [17:36:27] <kshishkov> mru: but they don't seem to use them often enough [17:36:33] <mru> it's the grammar that's hard [17:36:49] <kshishkov> try Russian [17:36:52] <mru> I did [17:36:56] <kshishkov> I know [17:37:23] <Dark_Shikari> Oh yeah, there's israel, which is great if you're jewish and you're fine with a missile attack every once in a while [17:37:35] <mru> and learning f*cking hebrew [17:37:41] <peloverde> DonDiego, http://www.amazon.com/Signals-Systems-2nd-Simon-Haykin/dp/0471164747 http://www.amazon.com/Signal-Processing-Linear-Systems-Lathi/dp/0195219171/ [17:37:55] <Dark_Shikari> hebrew isn't that bad [17:37:59] <Dark_Shikari> probably easier than japanese. [17:38:03] <mru> lol, spammers selling "steel buildings" again [17:38:22] <mru> I couldn't live in israel [17:38:29] <kshishkov> Dark_Shikari: I can comprehend Japanese even when I don't know how to read certain kanji [17:38:30] <mru> not for the missiles [17:38:37] <mru> they're not so big a deal [17:38:39] <kshishkov> not for the people [17:38:46] <mru> the people are totally weird [17:38:52] <mru> I've met enough of them [17:38:59] <mru> some of them are really nice [17:39:00] <kshishkov> yes, and a good deal of them came from here [17:39:03] <mru> but they're too few [17:39:12] <mru> I've met loads in the old company [17:39:22] <kshishkov> mru: I know only one good "crazy Jewish guy" [17:39:44] <DonDiego> oded? [17:39:49] <kshishkov> nej [17:39:51] <mru> merbzt [17:40:37] <Dark_Shikari> crazy jewish guy--> is any other type that exists? [17:40:47] <DonDiego> peloverde: thx [17:41:54] <kshishkov> Dark_Shikari: yes, I have sheerly mad drunkard guy or certain origin in neighbourhood [17:42:39] <KotH> peloverde: oh.. thanks... forgot to ask about those books :) [17:43:14] <kshishkov> Dark_Shikari: and those teachers I met of Jewish origin were probably the best ones I've ever met for both professional and human qualities [17:43:43] <mru> I didn't say jews, I said israelis [17:43:54] <mru> the jews in other countries aren't usually as crazy [17:44:12] <kshishkov> half of them have relatives emigrated to Israel [17:44:20] <DonDiego> bye [17:45:18] <KotH> hmm.. [17:45:40] <KotH> does anyone have an idea why irssi would stop loggin a specific channel? [17:45:50] <mru> you told it to? [17:46:00] <KotH> correction, everything on freenode [17:46:17] <KotH> it didnt write a singe line of log for freenode since i reconnected [17:46:38] <kshishkov> out of free space? [17:46:43] <KotH> nope [17:46:46] <mru> maybe you forgot to save some setting [17:46:47] <KotH> all other servers log fine [17:46:59] <KotH> mru: i havent touched any setting for years [17:47:22] <mru> maybe you should have... [17:47:22] <KotH> wtf... [17:47:22] <kshishkov> what about writing permissions? [17:47:24] <KotH> it logs [17:47:35] <KotH> but to ~/irclogs/freenode/*.log ^^' [17:47:47] * KotH wonders how that happend [17:48:00] * KotH tries a restart [17:49:36] <kshishkov> log this! [17:50:25] <KotH> wtf.. [17:50:29] <KotH> something is fucked up [17:50:51] <kshishkov> have you updated irssi? [17:51:26] <KotH> nope [17:52:28] <kshishkov> and it's not part of Gnome, i.e. does not have a tendency to randomly screw configs, doesn't it? [17:53:19] <elenril> blame Kovensky! [17:54:09] <kshishkov> no, he uses mru for blaming on everything [17:55:37] <kierank> blame xiph [17:57:09] <KotH> hmm.. [17:57:12] <KotH> let me try something [18:02:44] <KotH> at least, i'm not alone with that prob ^^' [18:03:23] <kshishkov> KotH: try my way - don't treat it as a problem ;) [18:03:35] <KotH> kshishkov: er.. i think it is a prob [18:03:54] <kshishkov> KotH: yes, that's exactly what is wrong with you [18:04:48] * KotH thinks kshishkov is the problem [18:05:00] <kshishkov> you've not seen me yet [18:09:37] <kshishkov> here's a nice string for you to log [18:12:13] <KotH> kshishkov: it was a bug in irssi ^^' [18:12:24] <elenril> did you send a patch? [18:12:47] <KotH> it has been fixed ages ago... but i'm using debian/stale :/ [18:13:11] <elenril> o_0 [18:13:16] <elenril> why would you want to do that [18:13:22] <KotH> lazyness [18:13:30] <KotH> you know, *effort* and such ;) [18:13:36] * elenril knows [18:15:37] <elenril> laziness is the foundation of all physics [18:21:47] <kshishkov> engineering too [18:22:53] <kshishkov> for example, C.F. Gauss performed Fourier transforms by hand [18:24:26] * elenril meant that universe itself is lazy [18:24:29] <elenril> http://en.wikipedia.org/wiki/Principle_of_least_action [18:24:39] <peloverde> gauss invented the fft [18:25:02] <kshishkov> what has that French guy done then? [18:25:31] <peloverde> Fourier invented the slow fourier transform [18:25:53] <elenril> iirc without any mathematical foundation for it [18:26:14] <kshishkov> it can be Tailored ;) [18:27:57] <elenril> and i think he only invented fourier series [19:28:20] <peloverde> KotH, I put the old CT aacPlusDecoderCheckPackage_v2.1 on samples but am having trouble making it readable [19:33:26] <peloverde> nevermind i got it [19:36:25] <BBB> shit he left [19:36:34] <BBB> hmm... [19:36:40] <BBB> peloverde: thanks for the book ref, I'll check it out [19:36:45] <BBB> I indeed meant signal processing math [19:36:47] <BBB> I know general math [19:36:54] <BBB> although I might have to refresh it here and there [19:37:30] <ohsix> dspguide is free if you haven't seen that yet :P [19:38:11] <BBB> btw elenril if you think physics is lazy, you should check out biology [19:38:48] <kshishkov> you mean watching evolution process? [19:40:34] <peloverde> I'm getting angry warnings on my aacPlus Decoder Check, this can't be good [19:40:47] <peloverde> It also says that we are missing 3gpp asset metadata support [19:40:55] <BBB> kshishkov: look at mice grow [19:40:58] <BBB> if not something else [19:41:03] <ohsix> why are there so many people with 9 char nicks that start with p :O [19:41:25] <kshishkov> look at nicks starting with 'k' [19:41:46] <ohsix> i'm lucky i dont also have 4 of those in one window [19:53:15] <elenril> http://entertainment.slashdot.org/story/10/03/05/1723215/Microsoft-Sends-Fl… [19:54:27] <kshishkov> they'd rather send other IEs to bury along with it [20:00:13] <peloverde> The files in the aacPlus decoder check appear to be illegal... lovely [20:02:01] <KotH> peloverde: files in the samples directory will have their permissions fixed every hour (xx:17), so just put there what you want and let it ferment ;) [20:05:15] <CIA-92> ffmpeg: vitor * r22223 /trunk/libavcodec/imgconvert.c: [20:05:15] <CIA-92> ffmpeg: Round correctly chroma picture height. [20:05:15] <CIA-92> ffmpeg: Fix issue 956. [20:26:47] <mru> skype is hiring codec devs [20:27:11] <elenril> they should hire kshishkov [20:27:24] <mru> they have office in stockholm [20:27:49] <BBB> indeed, they should hire that boy that JUST RAN OUT OF THIS CHANNEL [20:31:04] <mru> hmm, they're using an ancient email address of mine [20:31:07] <mru> wonder where they got it [20:31:28] <mru> good thing every email address I've used in the last 10 years still works [20:37:03] <Dark_Shikari> mru: did you just get a call? [20:37:12] <mru> email [20:37:16] <Dark_Shikari> They just called me up asking me to work for them [20:37:28] <Dark_Shikari> and asking for where to find more codec devs [20:37:49] <mru> what did you tell them? [20:38:51] <Dark_Shikari> that I'm probably booked this summer unless they can offer a lot of money [20:38:52] <peloverde> I'm sure he told them the truth... to forge a new codec dev, you must first slay an old god [20:39:00] <Dark_Shikari> But I'm willing to consult and contract as always [20:39:07] <Dark_Shikari> and that their codec devs should feel free to contact me at any time, via any channel [20:39:15] <Dark_Shikari> And that they should look at Doom9 for more codec people [20:39:39] <Dark_Shikari> and ffmpeg [20:49:05] <Compn> skype going to make a new codec? [20:49:11] <Compn> instead of paying for h264 / aac ? :P [20:49:19] * Compn forgets what skype uses now [20:49:28] <wbs> they have some codecs of their own, iirc [20:49:39] <wbs> http://en.wikipedia.org/wiki/SILK [20:50:03] <mru> they're looking for people with knowledge of h264 [20:50:13] <kierank> Compn: they use vp7 [20:50:34] <Dark_Shikari> they used VP7 [20:50:34] <Dark_Shikari> yeah [20:51:15] <Dark_Shikari> This is one reason I want to get that proprietary license done [20:51:17] <Dark_Shikari> sell them x264 [20:51:20] <Dark_Shikari> get them away from vp7 [21:11:54] <BBB> hm... [21:12:03] <BBB> so now we can see how people outside rank us [21:12:13] <BBB> apparently mru and dark)shikari are codec gods [21:12:28] <BBB> now we'll see who are merely mortal, and who ar nothing at all, just by sequence of calls and whether we get a call at all [21:12:38] <Dark_Shikari> but mru has never even done work on a lossy codec =p [21:12:51] <mru> what makes you say that? [21:13:28] <BBB> Dark_Shikari: well be that true or not, he did get the first call [21:13:33] <Dark_Shikari> he got an email [21:13:34] <Dark_Shikari> I got a call [21:13:35] <BBB> so for all practical purposes, he is THE codec god [21:13:42] <mru> do they have my number? [21:13:43] <BBB> maybe they don't have his phone# [21:13:53] <BBB> method of connection is irrelevant [21:13:59] <BBB> it's about ORDER, SEQUENCE :-p [21:14:01] <mru> anyone with basic net skills can find it [21:14:06] <pasteeater> did they call you with skype? [21:14:18] <pasteeater> DW BUS CORP. "randome number" [21:14:19] <Dark_Shikari> pasteeater: lol, my cell phone [21:14:23] <Dark_Shikari> from my CV [21:14:41] <mru> the email said someone had recommended me [21:14:48] <mru> but all such emails say that [21:14:50] <pasteeater> i meant from skype. sometimes the caller id is "spammy". Anzazi Sportswear. [21:15:23] <pasteeater> mru: Hello, I am Nigerian Royalty named Mr. Elvis Guru. Someone recommended you. [21:15:46] <mru> this one seemed genuine [21:15:48] <Dark_Shikari> they said they saw my resume on my blawg [21:28:16] <BBB> oops, wrong button [21:34:54] <Rathann> who's in charge of ffmpeg.org DNS, KotH? [21:37:06] <mru> root is in charge [21:37:11] <mru> is there a problem? [21:41:05] <mru> macros defining macros, OH YEAH [21:41:17] <mru> and self-undefining macros [21:42:44] <Honoome> autoconf again? [21:45:03] <mru> oh no [21:45:06] <mru> gnu as [21:46:42] <Honoome> oh even better then [22:00:57] <wbs> BBB: I tried benchmarking ff_network_init on windows... when using two different timers with millisecond precision, I just get 0 ms runtime for the call. when using a slightly modded START_TIMER/STOP_TIMER (modded to print the runtime for each invocation), I get something like this: [22:01:09] <wbs> 129155310 dezicycles in ff_network_init, 1 runs, 0 skips (for the first invocation, which actually loads stuff I think) [22:01:21] <wbs> 940310 dezicycles in ff_network_init, 1 runs, 0 skips (for later invocations) [22:02:40] <wbs> so later invocations are much faster (I think it just does some reference counting somewhere and doesn't load the networking system twice), and the first invocation is also less than 0 ms on this machine, so calling it once too much on startup isn't all that bad IMO [22:04:35] <KotH> Rathann: anyone of mru, diego or me [22:04:58] <Rathann> KotH: ack, thanks [22:19:01] <BBB> wbs: fair enough, feel free to commit it in url_open/close_protocol() then [22:20:18] <wbs> BBB: I had to keep ff_network_init/close in rtsp btw, since that's a (de)muxer and not a protocol.. but for gopher/http/rtp/rtmp I could get rid of the protocol-specific initialization [22:20:35] <BBB> rtsp is fine [22:20:39] <BBB> I'm surprised it didn't do that already [22:20:58] <BBB> don't forget rtsp opens tcp control connection [22:21:05] <BBB> and don't forget sdp either [22:21:12] <wbs> they're taken care of. :-) [22:21:31] <BBB> right, but if tcp open happens before sth. else, than rtsp doesn't need it anyway [22:21:39] <BBB> but well yeah who cares, go ahead and commit it :) [22:21:57] <wbs> the whole mess, or just the network_init/close stuff? [22:22:20] <wbs> whole mess as in ff_url_join and network_init/close [22:23:47] <BBB> just the network_init [22:23:58] <wbs> ok [22:24:00] <BBB> I think I already said the ff_url_join stuff was fine, didn't I? [22:24:05] <BBB> so you can then commit that afterwards also [22:24:09] <wbs> ok [22:24:11] <BBB> don't forget to say "applied" on the mailinglist [22:24:18] <wbs> yeah, I will. :-) [22:24:21] <BBB> the rest (EGAIN stuff) was not OK yet :) [22:24:31] <wbs> no, that's a completely different series :-) [22:30:40] <wbs> ok, here goes nothing... [22:31:13] <CIA-92> ffmpeg: mstorsjo * r22224 /trunk/libavformat/avio.c: [22:31:13] <CIA-92> ffmpeg: Always call ff_network_init/ff_network_close when opening protocols [22:31:13] <CIA-92> ffmpeg: ff_network_init is a no-op on all platforms except windows, and on [22:31:13] <CIA-92> ffmpeg: windows the performance penalty is minimal (less than 1 ms in my tests). [22:32:33] <CIA-92> ffmpeg: mstorsjo * r22225 /trunk/libavformat/ (utils.c avformat.h): Add a function ff_url_join for assembling URLs [22:36:10] <wbs> BBB: ok to remove the ff_network_init/close from tcp.c/udp.c, too, now that they're inited in avio.c? [22:36:11] <CIA-92> ffmpeg: mstorsjo * r22226 /trunk/libavformat/ (rtmpproto.c rtsp.c rtpproto.c rtspenc.c http.c gopher.c): [22:36:11] <CIA-92> ffmpeg: Use ff_url_join for assembling URLs, instead of snprintf [22:36:11] <CIA-92> ffmpeg: This ensures proper escaping of numerical IPv6 addresses. [22:36:11] <CIA-92> ffmpeg: The RTSP (de)muxer needs its own network initialization, since it isn't [22:36:11] <CIA-92> ffmpeg: a protocol and url_open hasn't been called yet. [22:37:42] <BBB> wbs: yes [22:39:39] <CIA-92> ffmpeg: mstorsjo * r22227 /trunk/libavformat/ (tcp.c udp.c): [22:39:39] <CIA-92> ffmpeg: Don't explicitly initialize networking in the tcp and udp protocols [22:39:39] <CIA-92> ffmpeg: Networking is always initialized when opening protocols. [22:41:10] <elmojo> janneg: one other type of message I see is "cannot read: /home/user/.blender/04.blend_comp7.exr" - let me know if that is a problem. [22:41:20] <BBB> \o/ [22:45:19] <wbs> ah, always feels great to be able to remove all the temp branches for different versions of submitted patches :-) [22:45:24] <j0sh> wokring on the theora rtp depayloader. should theora data fragments be buffered to a whole unit before they're sent to a decoder? [22:46:18] <wbs> j0sh: for H263 at least, the data from each RTP packet is returned immediately, but then passed into a parser that joins the packets as appropriate [22:46:33] <Yuvi> j0sh: yesh, the decoder only works on an entire frame [22:46:57] <wbs> but if there isn't any suitable parser that can do that, it's probably better to buffer it up properly in the depacketizer instead [22:47:24] <Yuvi> with theora it's impossible for a parser to combine them [22:47:36] <Yuvi> has to be done at the demuxer level [22:48:02] <wbs> ok, well then the decision is even easier :-) [22:48:26] <j0sh> gotcha... i noticed in the vp3 (theora) source, there are some provisions for handling "fragments," is this unrelated? [22:48:45] <Yuvi> yes, it's what vp3 called blocks [22:49:07] <Yuvi> though theora made some weird distinction between "block" and "fragment" depending on whether you're iterating in hlbert or raster order [22:49:46] <j0sh> alright, i will buffer the data in the depayloader then. thanks! [22:52:53] * BBB excited to see sudden interest in ff-rtsp stack [22:52:57] <BBB> so what drives all this? [22:53:30] <janneg> elmojo: I think that are blender temp files [22:55:02] <j0sh> i tried working on h264 but it was too complicated... so i'm turning to rtsp, heh [22:58:55] <BBB> last year one student tried the theora dpayloader, didn't work unfortunately :( [22:59:04] <BBB> the vorbis one got done though, so use that as your template [22:59:05] <BBB> a [22:59:14] <j0sh> yup thats what im doing [22:59:14] <BBB> afaik they're almost identical [22:59:58] <j0sh> the feng rtsp server sends all the theora data as fragmented packets which vorbis rtp doesnt handle, so im adding that [23:01:36] <j0sh> if the end of a fragmented packet is only a few bytes and there's room to start a new frame, is that done? [23:01:57] <BBB> probably [23:02:03] <BBB> every byte is a byte [23:02:53] * mru thought every byte was 8 bits [23:05:11] * Kovensky bytes mru [23:05:22] <mru> ouch, Kovensky bit me [23:06:12] <ohsix> 8 times [23:10:27] <CIA-92> libswscale: michael * r30847 /trunk/libswscale/swscale_template.c: try to avoid returning odd slices. [23:14:44] <wbs> j0sh: don't know how the rtp/theora stuff works, but what I've seen of other rtp schemes, you either split one frame into multiple packets (but only keep data from one frame in each packet, so the last packet is a smallish one) or join multiple frames into one packet (for audio) [23:20:59] <wbs> BBB: I think one reason for the amount of rtsp-demuxing/decoding related fixes from me, at least, is that I've only found the lacking areas one at a time, so instead of going "omg, this is severly lacking", I've noticed that "this should be quite usable, except for this little detail that's bugging me" [23:21:52] <wbs> as long as bugs are found in that way, it's much easier to keep up the motivation to fix issues that aren't critical but only annoying :-) [23:24:15] <j0sh> wbs, yeah thats pretty much what the theora/vorbis rfcs say -- last packet in the fragment is smallish, but i wasn't sure. i ran some tests and that seems to be the case [23:25:06] <BBB> wbs: I think the stack isn't in too bad a shape, it's got a lot of features [23:25:11] <BBB> but I know some major stuff is lacking [23:25:32] <BBB> I always found that firewall hole-poking thing which you wrote an annoying miss [23:26:01] <BBB> there's probably some other things on my todo list, but it's in quite a good state [23:26:18] <wbs> j0sh: ok, then I guess you won't have to worry about that case, unless you find an example of such a weird source producing that kind of packets [23:26:27] <j0sh> yeah, ive been lurking on the ML awhile -- that firewall/nat thing was pretty cool, i gotta say [23:27:19] <wbs> j0sh: for the hypothetical case with concatenaed split theora frames, you wouldn't get the timestamp for the second frame (unless that's within the payload itself in some way), so I don't think you'll encounter that :-) [23:27:52] <BBB> video frames are much bigger than that, typically [23:28:15] <BBB> I have yet to find a video codec that can pack a full 320x240 frame in <1500bytes [23:28:37] <BBB> PNGalpha with continuous series of black frames does not count [23:29:49] <wbs> BBB: well, the mess with hardcoded stuff for different codecs vs dynamic payload depacketizers in rtpdec.c feels a bit awkward, but I guess I should step up and convert the AAC stuff to a proper dynamic payload handler [23:30:13] <mru> BBB: that's 0.15 bits per pixel [23:30:19] <mru> h264 can manage that on average [23:30:25] <BBB> hm... [23:30:29] <mru> I-frames will be bigger [23:30:35] <BBB> that'd be interesting [23:30:53] <BBB> wbs: rtpdec.c splitting would be nice [23:30:58] <BBB> but it used to be worse [23:31:01] <BBB> so I won't complain too much [23:31:04] <wbs> I can imagine :-) [23:31:18] <wbs> reading svn logs is quite a horror trip sometimes :-) [23:31:48] <mru> hopefully it has a happy ending [23:32:16] <BBB> mru: the rtsp stack is ok right now [23:32:19] <mru> but usually there are plenty of openings for sequels [23:32:21] <BBB> like I said, it's been a lot worse [23:32:34] <BBB> and most obvious stuff, like radio streams, works now [23:32:44] <BBB> I had a patch to make quicktime sessions work also, but that's not in yet [23:32:51] <BBB> (for steve jobs keynotes) [23:33:13] <mru> I don't think I've ever played an rtsp stream [23:33:26] <mru> outside of work [23:36:50] <j0sh> would be nice if html5 <video> and <audio> could work with rtsp, i think [23:38:12] <j0sh> correct me if i'm wrong but as far as i can reckon, arent the tags limited to progressive playback under most circumstances right now? [23:39:11] <wbs> j0sh: firefox actually manages to play progressively streamed ogg over http, too, but it doesn't really work well enough to be really usable [23:40:05] <BBB> j0sh: progressive as in no-seeking? I think it's supposed to be a complete video playback engine [23:40:11] <BBB> including all the bells and whistles [23:40:27] <BBB> rtsp should work too then [23:40:49] <j0sh> i guess, i took progressive to mean download completely (or buffer to a certain length), then play [23:41:14] <j0sh> no seeking, yeah [23:42:09] <BBB> I'd be surprised [23:42:16] <BBB> I'd expect it to work for streaming/live also [23:42:20] <BBB> but well, who knows :) [23:44:36] <j0sh> ok well i gotta go eat dinner and run errands. thanks for the help and i'll keep working on the depayloader over the weekend [23:44:52] <wbs> BBB: well, since the html5 standards don't mandate any formats/protocols/codecs at all, I guess it's all up to the browsers which streaming protocols they want to support [23:45:19] <BBB> right [23:45:24] <BBB> j0sh: ok, keep us updated [23:45:33] * BBB will run for dinner also [23:46:25] <wbs> and I'll go sleep soon, too [23:48:03] <BBB> later then!

1 0

IRC log for 2010-03-04
by irc＠mansr.com 05 Mar '10

05 Mar '10

[00:28:45] <CIA-92> ffmpeg: stefano * r22191 /trunk/libavutil/pixdesc.c: (log message trimmed) [00:28:46] <CIA-92> ffmpeg: Declare the PIX_FMT_GRAY8 pixel format as a paletted format. This is [00:28:46] <CIA-92> ffmpeg: consistent with the allocation currently done for PIX_FMT_GRAY8 [00:28:46] <CIA-92> ffmpeg: pictures. [00:28:46] <CIA-92> ffmpeg: No significant slow-downs have been measured. [00:28:46] <CIA-92> ffmpeg: See the thread: [00:28:47] <CIA-92> ffmpeg: Subject: [FFmpeg-devel] [PATCH] Is gray8 a paletted format? [00:34:15] <mru> monty joins the fray: http://news.slashdot.org/comments.pl?sid=1570150&cid=31351360 [00:38:57] <j-b> you didn't see that one? [00:39:15] <mru> didn't have time to read it until now [00:39:17] <j-b> "Mans is a bad guy that doesn't like me" [00:39:33] <j-b> that why he says that [00:39:33] * mru has been busy enough keeping server alive [00:40:03] <mru> and eating, and reading email, and updating that blasphemous article, etc [00:40:14] <j-b> "Ogg was designed to stream, mkv was not." [00:40:30] <mru> mkv was designed in a way that allows it [00:40:34] <mru> ain't that enough? [00:41:39] <j-b> "your arguments are not valid, you just don't like me" [00:41:41] <j-b> pfff [00:42:06] <mru> I expected nothing less from him [00:42:17] <mru> but hopefully someone read it and learned something [00:42:56] * Yuvi learned that 2004 was recently [00:43:38] <Yuvi> and that ogg was widespread in 1996 [00:43:38] <mru> ? [00:43:47] <j-b> lol :D [00:43:56] <j-b> and that H264 is less good than Theora [00:43:59] <mru> the first I heard of ogg was around 2000 [00:44:13] <Yuvi> "mkv's not been able to interleave until just recently" but maybe he's talking about something else [00:44:26] <mru> I don't get that bit [00:44:31] <mru> what is a mux if not interleaved? [00:45:08] <Yuvi> avi, mov, mxf can be non interleaved [00:45:55] <Yuvi> if you put all the audio packets before the video packets or something [00:46:02] <Yuvi> I think one mxf-based spec even requires [00:46:07] <Yuvi> it [00:46:17] <j-b> is mxf royalty-free ? [00:46:24] <mru> if you put the audio and video separately mp4 can get a *really* low overhead [00:48:11] <Yuvi> timeline wise, vorbis started sometime around 1993, but wasn't standardized until 1998-2000 (when ogg was split off with basically no modifications) [00:48:31] <Yuvi> mkv started sometime around 2002 and was basically done in 2003-4 [00:48:31] <mru> vorbis wasn't available to the masses until ~2001 [00:48:40] <mru> ogg was irrelevant before that [00:48:47] <Yuvi> nut started 2003 and was finalized 2006 [00:48:53] <Yuvi> so they're all pretty close [00:51:41] <mru> I added a mention of ASF [00:51:46] <mru> that'll tickle 'em... [00:51:57] <j-b> ASF isn't bad :) [00:52:37] <mru> no, I just had a look at the spec and it's quite reasonable [00:52:56] <j-b> it works pretty fine for streaming (ogg doesn't... chained-ogg) [00:53:03] <mru> it's a bit microsofty of course... [00:53:04] <j-b> it works pretty fine for file playback [00:53:14] <j-b> and it can even have h264 in it :) [00:53:19] <j-b> "I'd love to see your analysis of the Matroska container format." [00:53:32] <mru> I should start charging money for these [01:01:54] <iive> mru: actually there are very nice replies to that comment, unfortunately they are (still) low score. I wonder is john is hanging around here. [01:02:12] <mru> yeah, I saw some positive replies too [01:03:45] <mru> btw, 23% of the traffic to my blog is from google chrome [01:03:51] <peloverde> mru: did the site just go down? [01:04:04] <CIA-92> ffmpeg: michael * r22192 /trunk/libavcodec/h264.h: Optimize *_type init, 1.5 cpu cycles faster. [01:04:05] <mru> it glitched [01:09:11] <peloverde> the retards are out on full force spamming that entry about H.264 licensing [01:09:32] <peloverde> sometimes I wonder if they are disingenuous or stupid or both [01:12:00] <mru> who is TFA? [01:15:07] <peloverde> any idea why the mpeg-4 systems patent pool shut down? [01:15:21] <mru> part 1? [01:15:59] <mru> everybody realised it was the worst spec ever written and used something else [01:16:27] <peloverde> part 1 is still based on part 12 [01:16:35] <mru> part 1 can't be based on part 12 [01:16:39] <mru> part 12 is newer [01:16:52] <mru> part 12 is the tiny sane subset of part 1 [01:17:03] <mru> rewritten in a way that can actually be understood [01:17:06] <peloverde> part1 is the so-called mp4v1 [01:17:22] <mru> maybe they "backported" it [01:19:02] <peloverde> Part 1 describes itself among other things as "a file format to contain the media information of an ISO/IEC 14496 presentation in a flexible, extensible format to facilitate interchange, management, editing, and presentation of the media specified in part 12 (ISO File Format), part 14 (MP4 File Format) and part 15 (AVC File Format) of ISO/IEC 14496" [01:19:22] <mru> that must be from a revised version [01:19:30] <peloverde> yes [01:19:32] <mru> the original from ~2002 can't have said that [01:19:40] <mru> the parts stopped at 6 or so then [01:19:50] <peloverde> -14 still makes reference to -1 boxes [01:20:15] <peloverde> -1 is still a mess [01:21:02] <peloverde> also I think the parts stopped at 7 then [01:21:21] <peloverde> because -7 is the weird mpeg-4 visual reference hardware [01:21:54] <mru> I've never looked at 4-9 [01:22:19] <peloverde> -4 and -5 are critically important, reference software and conformance [01:22:19] <mru> except whichever one is conformance testing [01:22:50] <peloverde> they recently split audio conformance out into -26 [01:23:57] <peloverde> I have mixed feelings about that, when others were buying specs for me, getting things bundled was nice but split makes it easier to find things [01:24:32] <peloverde> now they just need to split -3 [01:25:57] <peloverde> most of the patents on -1 are post 2000 which makes me think they are probably on weird mpeg-4 boxes that no one uses [02:01:02] <CIA-92> ffmpeg: michael * r22193 /trunk/libavcodec/h264.h: [02:01:02] <CIA-92> ffmpeg: Port Optimizations about *_type init from decode to filter code. [02:01:02] <CIA-92> ffmpeg: 1 cpu cycle faster [02:26:31] <mru> http://linuxhaters.blogspot.com/2010/03/tale-of-ogg.html [02:31:40] <CIA-92> ffmpeg: alexc * r22194 /trunk/libavcodec/aac_ac3_parser.c: [02:31:40] <CIA-92> ffmpeg: AAC parser: Don't write channels, sample rate, and frame size each frame. [02:31:40] <CIA-92> ffmpeg: Thanks to backwards compatible HE-AAC signalling these values are unreliable. [02:33:37] <CIA-92> ffmpeg: alexc * r22195 /trunk/libavcodec/aac_ac3_parser.c: Cosmetics: Re-indent after last commit. [02:34:29] <peloverde> ^one step closer to SBR o.O [03:07:25] <peloverde> HE-AAC try 5 sent :) [03:18:38] <mru> http://embed.cs.utah.edu/embarrassing/jan_10/harvest/ [03:21:09] <ohsix> heh why did they bother with percentages [03:21:19] <peloverde> This is the real reason to use clang: http://zi.fi/shots/clang.png [03:26:11] <peloverde> Sadly for people stuck on x86-32 llvm 2.7 will probably still have shitty x87 support [03:29:56] <mru> I'd rather not have the compiler second-guess what I might have meant [03:30:48] <ohsix> what about the other 95% [03:30:54] <peloverde> It's an error, not a warning, it still needs to be fixed for compilation to be successful [03:31:22] <ohsix> oh nm, clang screenshot [03:31:26] <mru> I've seen enough people who'd just do what the compiler suggests, right or wrong [03:31:50] <mru> better not suggest anything, let the programmer figure out what's wrong [03:32:04] <ohsix> same, its an old horror story from the vms + pl/i era too [03:32:31] <ohsix> pl/i tried to tell you a _lot_ about errors that was applied verbatim heh [03:32:43] <peloverde> I have trouble finding typos, I think I'm slightly dyslexic, seeing to two words above and below each other is a huge help [03:33:02] <ohsix> and one of the versions on vms would automatically do it for you & mask that there ever was one [03:33:08] <mru> if the compiler says an identifier is undeclared I'll double-check it [03:38:15] <pengvado> "people stuck on x86-32" <-- does that mean stuck on x86-32 that are old enough to not have sse? [03:38:55] <mru> or x86-32 systems using x87 parameter passing [03:39:07] <ohsix> does clang use levenshtein distance or what to propose that correction [03:42:52] <mru> it doesn't do it at all here [03:48:00] <ohsix> heh http://embed.cs.utah.edu/embarrassing/jan_10/harvest/compare_suncc-5.10_gcc… [04:02:41] <astrange> http://embed.cs.utah.edu/embarrassing/jan_10/harvest/compare_suncc-5.10_gcc… ?? [04:06:50] <mru> mov %eax,0x0 ?? [04:07:09] <mru> omg, the value of zero changed! [04:07:53] <ohsix> its radiation protection!!11 [04:08:10] <mru> seriously, wtf is that? [04:08:47] <ohsix> probably droppings from one of the compiler passes after the one that removes null side effects [04:09:01] <astrange> probably (0x0) [04:09:04] <astrange> and that might be a relocation [04:09:22] <ohsix> oh, good point [04:09:37] <mru> absolute memory addressing? [04:09:49] <ohsix> arg in fact i have some junk to look at again in light of that; didn't think about fixups [04:11:20] * mru guesses there's a volatile global involved [04:11:25] <mru> *never* use volatile [04:11:28] <mru> it's always wrong [04:11:56] <ohsix> the code for the case is there with the assembly [04:12:15] <Dark_Shikari> mru: no, there are plenty of correct cases for volatile with multithreading [04:12:28] <mru> Dark_Shikari: no [04:12:46] <mru> volatile is nuking ants [04:12:49] <Dark_Shikari> while( !flag ) {sleep();} [04:12:53] <Dark_Shikari> you must say flag is volatile [04:13:11] <mru> you shouldn't be doing that [04:13:19] <Dark_Shikari> yes you shouldn't be doing spinlocks [04:13:21] <mru> you should make sleep() and optimisation barrier instead [04:13:31] <Dark_Shikari> so I have to modify the compiler? [04:13:43] <mru> no [04:13:48] <mru> just define some macros [04:13:51] <Dark_Shikari> there are no cross-platform optimization barriers [04:13:52] <Dark_Shikari> they do not exist [04:13:58] <Dark_Shikari> there are no cross-platform memory fences [04:14:07] <Dark_Shikari> welcome to our shitty world. [04:14:08] <mru> an optimisation barrier in gcc is trivial: __asm__ volatile ("") [04:14:24] <Dark_Shikari> wrong [04:14:28] <Dark_Shikari> volatile does not mean it won't reorder [04:14:33] <Dark_Shikari> it means it won't remove it if the output isn't used [04:14:42] <Dark_Shikari> GCC can and does reorder volatile asm blocks [04:14:50] <mru> never seen it do that [04:14:53] <Dark_Shikari> I have [04:15:06] <astrange> it will reorder scalar operations around them [04:15:14] <ohsix> i remember an old thread on their ml about it doing that [04:15:15] <mru> on the contrary, I've seen the presense of an asm block turn off lots of optimisation in that area [04:15:24] <astrange> it won't reorder memory accesses around asm volatile ("" ::: "memory") [04:15:29] <astrange> (i think) [04:15:34] <mru> it ought not [04:15:51] <mru> either way, you'll need proper hw memory barriers too [04:16:10] <ohsix> the "all of memory is tainted" flag is newish isn't it? or was that for the stack [04:16:28] <mru> memory clobbers don't usually apply to the stack [04:16:33] <mru> which makes some kind of sense [04:17:14] <ohsix> i just remember that recently a pseudoclobber was added recently for asm(), might be related; don't remember exactly what it pertained too [04:19:58] <ohsix> theres some junk about reordering in the docs; Similarly, you can't expect a sequence of volatile asm instructions to remain perfectly consecutive. If you want consecutive output, use a single asm. Also, GCC will perform some optimizations across a volatile asm instruction; GCC does not “forget everything” when it encounters a volatile asm instruction the way some other compilers do. [04:21:08] <mru> declaring variables volatile is still overkill in almost all situations [04:22:33] <ohsix> oh nevermind; it was "cc", and not on x86 [04:23:21] <ohsix> re: memory clobber; If your assembler instructions access memory in an unpredictable fashion, add `memory' to the list of clobbered registers. This will cause GCC to not keep memory values cached in registers across the assembler instruction and not optimize stores or loads to that memory. You will also want to add the volatile keyword if the memory affected is not listed in the inputs or outputs of the asm, as the `memory' clobber does not count as a side [04:56:40] <peloverde> Does configure work around clang having issues with out inline ASM or does clang actually build it now? [04:59:38] <CIA-92> ffmpeg: alexc * r22196 /trunk/libavcodec/aac.c: [04:59:39] <CIA-92> ffmpeg: AAC: Mark predictor functions av_always_inline. [04:59:39] <CIA-92> ffmpeg: This results in a 50% speedup on main profile with no increase in binary size. [05:00:07] <drv> wow [05:01:23] <ohsix> req: cache footprint info as result of change [05:03:09] <peloverde> ohsix: How can I get that? [05:04:12] <ohsix> valgrind has a module to do it, but there are also perf counters on any recent cpu that'll let you count flushes or "bad" events and count them [05:04:53] <ohsix> valgrind can emulate different cache sizes and junk though [05:06:59] <ohsix> http://valgrind.org/docs/manual/cg-manual.html [05:07:57] <ohsix> thats for hypothetical configs and annotation; you'd still probably want to use oprofile as well [05:09:33] <ohsix> sudo opcontrol --init ; opcontrol -l will show all the events you can count on your cpu [05:09:34] <peloverde> Does inline a function only called one place really have a signficant cache impact? [05:10:16] <peloverde> And does inlining a function that is six fp-ops really have a significant cache impact? [05:10:46] <ohsix> not unless its already close to overunning the cache already, but cache sizes vary, and it could impact the devices with small caches; you can find a lower bound though [05:12:07] <ohsix> but still, unless you measure you never know where it is :P [05:14:10] <ohsix> mru: apparently gcc will insert dup loads and movs to align things too [05:15:05] <ohsix> at least; the docs for cachegrind seem to suggest as much [05:32:26] <peloverde> ohsix: according to cachegrind my I1 miss rate increased from 0.10% to 0.12% and my D1 misrate increased from 2.0% to 2.2% [05:34:07] <ohsix> nice, with the sizes it inferred from your cpu? [05:34:55] <ohsix> it uses cpuid to read em' and use them as defaults [05:39:20] <ohsix> btw thanks for looking, i'm not set up to check those things myself atm [05:46:20] <peloverde> which whatever the defaults from my cpu were [05:46:45] <ohsix> can you try with half & quarter what your cpu is? [06:01:13] <bcoudurier> hi guys [06:03:46] <peloverde> ohsix: results were comparable for quarter cache [06:03:58] <ohsix> hm, nice [06:04:28] <ohsix> what was quarter anyways? in l1/d1 [06:04:39] <superdump> hey bcoudurier [06:05:30] <ohsix> and did cachegrind say it was actually using the cache sim :> [06:06:45] <peloverde> I fed it the --I1, --D1, --L2 arguments and the numbers were different this time so it did something different [06:07:00] <ohsix> oic [06:07:23] <peloverde> 0.38%->0.39% and 2.9%->3.1% [06:07:35] <peloverde> that's why I said comparable and not the same [06:08:18] <ohsix> how big were they for the quarter? [06:09:43] <peloverde> my quarter cache sizes are I1 8192 D1 8192 L2 1048576 [06:12:30] <ohsix> the l2 on the p3 was only 512k, so testing that is probably not much different [06:13:04] <ohsix> at least the ones that ran at half clock speed :P later was only 256kb [06:15:40] <ohsix> k6-2 only had 32k/32k for i/d, 128k of l2 [06:19:25] <ohsix> thanks for looking [06:20:11] <ShadowJK> P3 came with 2 different sizes of L2 cache iirc [06:20:11] <ShadowJK> the later probably had 256k? [06:20:53] <ohsix> latter, right; but it ran at full speed [06:52:32] <aaronl> what's depressing about that compiler comparison from earlier is that gcc-head is worse than gcc 3.4 [06:53:54] <ohsix> you don't want to get stuck in local minima ;] [06:56:40] <elenril> Nut came ten years after Ogg was already widespread. And looks almost exactly like Ogg << lol [06:57:23] <elenril> obvious troll is obvious [06:57:53] <ohsix> was someone advocating nut or did he pick that up himself [06:58:43] <elenril> i don't see anybody mentioning it before him [06:58:51] <elenril> probably because nobody knows about it ;) [07:00:30] <ohsix> huhu, he must be picking up the vernacular [07:58:58] <relaxed> I think the nut comment was a poke at ffmpeg/mplayer devs. [08:42:30] <KotH> ohayou [08:43:45] <kshishkov> god morgon [08:53:54] <CIA-92> ffmpeg: conrad * r22197 /trunk/libavformat/matroskaenc.c: [08:53:54] <CIA-92> ffmpeg: Attempt seeking to write EBML master sizes even if streamed [08:53:54] <CIA-92> ffmpeg: Most EBML masters are much smaller than IO_BUFFER_SIZE and thus the size [08:53:54] <CIA-92> ffmpeg: can be updated. This makes parsing the resulting files easier. [08:53:55] <CIA-92> ffmpeg: conrad * r22198 /trunk/libavformat/matroskaenc.c: [08:53:55] <CIA-92> ffmpeg: Write the first seekhead if writing to a stream, we won't be able to seek [08:53:56] <CIA-92> ffmpeg: back and write it at the end [08:53:56] <CIA-92> ffmpeg: conrad * r22199 /trunk/ (libavformat/matroskaenc.c tests/ref/acodec/pcm): Simplify starting and ending clusters [08:53:57] <CIA-92> ffmpeg: conrad * r22200 /trunk/libavformat/matroskaenc.c: Fix indentation [08:53:57] <CIA-92> ffmpeg: conrad * r22201 /trunk/libavformat/matroskaenc.c: [08:53:58] <CIA-92> ffmpeg: Ensure that we write clusters and blocks with known size when streaming [08:53:58] <CIA-92> ffmpeg: Too many demuxers can't cope with clusters of unknown size. [09:15:08] <CIA-92> ffmpeg: gb * r22202 /trunk/libavcodec/vaapi_h264.c: [09:15:08] <CIA-92> ffmpeg: Cope with rev 22183: [09:15:08] <CIA-92> ffmpeg: Reorder indexes in weight tables. [09:16:16] <j-b> good morning [09:16:22] <kshishkov> bonjour [09:19:09] <KotH> salut [09:21:23] <Yuvi> hm, I broke gcc 2.95 [09:21:46] <kshishkov> what, it's you who released 2.96? [09:22:58] <Yuvi> guess it didn't have good support for compound literal arrays [09:23:13] <peloverde> Yuvi, nice work on that theora stuff (aside from breaking 2.95 ;) ) [09:23:49] <Yuvi> peloverde: we're now ~3% faster than libtheora on my penryn, with at least another 15% possible :) [09:24:15] <Dark_Shikari> now get it in before 0.6 ;) [09:24:17] <Yuvi> anyone happen to know if changing it to int[3] would work? [09:24:26] <Dark_Shikari> and then make an announcement ;) [09:25:21] <kshishkov> "FFmpeg är snäbbare av libtheora"? [09:25:25] <Yuvi> eh, let's see, I like the weird C there [09:26:04] <peloverde> That is weird C, I like it [09:26:34] <CIA-92> ffmpeg: conrad * r22203 /trunk/libavcodec/vp3.c: Maybe fix gcc 2.95 [09:31:18] <merbzt> snabbare [09:31:59] <kshishkov> ok, it's not me who agreed to translate news from Swedish anyway [09:49:39] <DonDiego> Yuvi: did you merge all your theora work now? [09:50:03] <Yuvi> DonDiego: not yet, I'm going to fix ogg seeking and implement 4:2:2 and 4:4:4 before finishing [09:50:09] <Yuvi> now that we're slightly faster than libtheora [09:52:25] <DonDiego> but you merged all the speedups? [09:53:14] <Yuvi> not yet, sorry [09:54:34] <peloverde> Yuvi, 22203 didn't help [09:54:40] <peloverde> http://fate.multimedia.cx/index.php?history=build&config_id=69 [09:55:40] <DonDiego> Yuvi: np, you are making great progress [09:56:01] <Yuvi> darn, I was hoping 2.95 would accept that compound literal [09:56:38] <DonDiego> keep me posted on your progress please [09:57:01] <DonDiego> i'm interested and we would like to have your theora work in 0.6 [09:57:09] <DonDiego> "works with html 5" [09:57:18] <DonDiego> the codename should be the motto as well :) [09:57:26] <Yuvi> sure [09:57:46] <Yuvi> hopefully I should have ogg seeking fixed for tomorrow, I've been pounding at it and cursing ogg for a bit now [09:58:59] <Yuvi> and also, I just made our mkv muxer work well for live streaming so to erode that advantage of ogg :) [10:00:23] <DonDiego> cool :) [10:01:57] <CIA-92> ffmpeg: conrad * r22204 /trunk/libavcodec/vp3.c: Really fix 2.95 [10:07:42] <wbs> anyone running gentoo that could do a quick compile test to verify a detail for a (gentoo) bug report? [10:08:51] <thresh> if gentoo/ia64 is acceptable, yes [10:09:22] <wbs> I guess so, download http://albin.abo.fi/~mstorsjo/stailq.c and try to compile it (just gcc stailq.c -o stailq) [10:11:28] <KotH> btw: did anyone ever do a patent search on vorbis or theora? [10:11:40] <KotH> a non-xiph-sponsored search that is [10:12:53] <thresh> wbs: stailq.c:21: error: expected expression before 'struct' [10:13:00] <wbs> thresh: great, thanks. :-) [10:13:02] <thresh> wbs: gcc version 4.4.3 (Gentoo 4.4.3 p1.0) [10:13:04] <DonDiego> KotH: mozilla claim they did [10:13:22] <wbs> thresh: gentoo ships broken libc headers, and that's a example to pinpoint it to them :-) [10:14:02] <wbs> wonderful story; they noticed that sys/queue.h is upstream glibc is ancient, so they've copypasted stuff from newer freebsd versions into their own version. without actually checking that the copypasted stuff works ;P [10:15:29] <andoma> what a shame [10:15:35] <andoma> i'm a big fan of queue.h though [10:16:07] <andoma> on OS/X they changed the order of arguments for some TAILQ-macros between 10.4 and 10.5 [10:16:09] * kshishkov is no fan of queues since they tend to be rather long here [10:16:50] <wbs> I haven't actually used it myself, but I package some code that uses it [10:18:21] <KotH> DonDiego: have they published any results? [10:18:43] <Kovensky> http://blogs.perl.org/users/ovid/2010/03/linked-lists-have-now-been-patente… [10:27:02] <DonDiego> KotH: no, they haven't [10:28:28] * KotH wonders why neither xiph nor mozilla publish their results [10:28:51] <KotH> it smells like they found something that they shouldnt have [10:29:28] <kshishkov> or on the contrary - they don't want to search for it in case they _can_ find that [10:29:40] <kshishkov> quite a common practice [10:30:27] * KotH wonders whether ffmtech has enough money already to conduct a patent search [10:31:19] <kshishkov> no [10:32:07] <kshishkov> from what I know it mostly depends on what amount of information you already know and can range from $10000 to +\infty [10:33:05] <pross-au> $infinity? [10:33:17] <elenril> ∞ [10:33:44] <kshishkov> pross-au: yes, like penalty for breeding rabbits in Australia [10:34:19] <peloverde> IMHO it would be a waste of FFMtech's money [10:34:37] <merbzt> I would not support that kind of task [10:35:02] <kshishkov> it's both irrelevant to us and not very moral [10:35:25] <KotH> why isnt it moral? [10:35:44] <KotH> or do you mean it's moral to claim something w/o proving it [10:36:01] <kshishkov> KotH, it looks like we are jealous and want to undermine it [10:36:03] <merbzt> there is no reason for us to rain on their parade [10:36:34] <pross-au> which task guys? [10:36:43] <kshishkov> convincing them to that thing for themselves is right IMO [10:36:56] <kshishkov> pross-au: patent search on Theora/Vorbis [10:37:15] <pross-au> kshishkov: you want to prove Xiph wrong? [10:37:34] <kshishkov> pross-au: not me, I don't care much about them [10:37:34] <bilboed-pi> that smells like one massive waste of time/money [10:37:42] <kshishkov> pross-au: have you seen that? http://wiki.multimedia.cx/index.php?title=Bink_Video_version_b [10:38:15] <pross-au> kshishkov: yep and i was gonna ask, are you implementing a decoder, or just documenting it? [10:38:35] <kshishkov> pross-au: not yet (on both) ;) [10:38:58] <kshishkov> first one has to understand what and how it does [10:39:41] <pross-au> Are you doing that? [10:39:50] <kshishkov> yes, in free time [10:39:58] <kshishkov> as you can see, nothing is known about it [10:40:18] <pross-au> s/nothing/not much/ [10:40:32] <pross-au> um did that idb file help you? [10:40:55] <kshishkov> of course [10:41:39] <pross-au> Good to hear [10:53:29] <wbs> pross-au: btw, are you aware that the bink audio decoder outputs a lot of noise if compiled without optimizations? [10:54:12] <wbs> I build with --disable-optimizations --disable-stripping --enable-debug --disable-mmx --disable-asm, and do get the actual sound, but with a lot of noise on top [10:55:06] <DonDiego> KotH: they claim that publishing results could undermine a defense in court, i.e. help attackers [10:55:25] <pross-au> wbs: news to me. will check it out [10:55:35] <kshishkov> wbs: it's not because of asm, I think, sice it plays fine on PowerPC [10:55:38] <kshishkov> *since [10:55:58] <kierank> [10:55] <@DonDiego> KotH: they claim that publishing results could undermine a defense in court, i.e. help attackers --> isn't that a bit of a circular argument [10:56:39] <wbs> kshishkov: ok.. I just generally use that configure option to get quick rebuilds and sensible valgrind output when testing non-performance-critical stuff :-) [10:57:09] <DonDiego> kierank: well, it gives the other side knowledge about your defense strategies [10:57:36] <merbzt> pross-au: most likely the float2inst16 special scaling stuff [10:58:18] <peloverde> float2int16c has bitten me in the ass numerous times [10:58:29] <KotH> DonDiego: lol [10:58:40] <KotH> DonDiego: if they found nothing -> no problem in court [10:58:53] <merbzt> peloverde: I tried to get rid of it :/ [10:58:58] <KotH> DonDiego: if they found something -> there is even more a problem if they have to publish their results in court [10:59:21] <peloverde> Isn't BBB working on making audioconvert not suck? [10:59:51] <merbzt> peloverde: well moving the codec to output float would obsolete it [11:00:34] <pross-au> merbzt: i was thinking of doing that... [11:00:51] <merbzt> *moving all codecs [11:01:40] <peloverde> the issue is the weird hacks float2int16c uses, it requires biased floats but is faster than generic C code [11:02:20] <peloverde> And it doesn't help that lossy floatingpoint audio isn't well supported in FATE [11:02:59] <merbzt> well all common archs have faster simd convert [11:03:13] <peloverde> that is true [11:03:15] <merbzt> only p2 might be faster in c [11:03:37] <merbzt> "but think about the children!" [11:04:21] <merbzt> anyway codecs should output in planar float mode or planar int16 [11:04:37] <peloverde> agreed [11:04:50] <DonDiego> KotH: they argue along the lines of [11:05:38] <DonDiego> the attackers will already know that they think patent x does not apply at all or that they don't practice the claims or somehow worked around them [11:05:52] <DonDiego> it's a bit similar to not talking to the police [11:08:04] <KotH> very twisted logic... [11:08:25] <kierank> it seems so [11:11:26] <DonDiego> the argument is that it gives attackers time and preparation [11:11:58] <KotH> lol [11:12:06] <KotH> that would be an issue, if there would be a time limit [11:19:21] <DonDiego> there is [11:19:44] <KotH> huh? [11:19:45] <DonDiego> patent holders can prepare an attack with due time and then sue [11:19:56] <DonDiego> that creates time pressure [11:20:01] <KotH> and where is the time limit? [11:20:30] <DonDiego> the deadlines during the trial [11:20:45] <KotH> _during_ the trial, not upfront [11:21:01] <DonDiego> what do you mean by "not upfront"? [11:21:16] <KotH> if i would be holding, lets say 20 patents, i'd check whether vorbis or theora would infringe them [11:21:36] <KotH> i'd really take my time to prepare for an upcoming trial, w/o telling anyone [11:21:42] <KotH> and as soon as i smell money, i'd sue [11:22:32] <KotH> i dont have to do all research during the trial. nobody says i have to come unprepared [11:23:07] <peloverde> Is roundup down? [11:23:17] <KotH> ofc, as soon as i'm in court, there are deadlines to deal with [11:23:25] <peloverde> nevermind, it's working now [11:23:36] <KotH> but they dont start until i actually sue someone [11:27:36] <DonDiego> i understand their arguments, i'm not *terribly* convinced but i can see the merit [11:27:41] <DonDiego> there is a tradeoff [11:28:03] <DonDiego> from the outside you cannot tell if they found something or they found nothing [11:28:25] <iive> peloverde: actually i think i've done tweak of float2int16c that eleminates the need of special scalling, aka it can work with different range, by changing the magic constant. [11:28:27] <CIA-92> ffmpeg: alexc * r22205 /trunk/ffmpeg.c: ffmpeg.c: Don't use NULL for integer metadata flags. [11:28:44] <peloverde> iive, good to hear [11:29:23] <DonDiego> the tradeoff is between their defense and their credibility [11:30:07] <DonDiego> i personally don't think the tradeoff is worth it [11:31:45] <iive> peloverde: and i think i've posted that tweak on the maillist, so if you are up to the task. [11:33:21] <kierank> [11:28] <@DonDiego> from the outside you cannot tell if they found something or they found nothing --> yet with "patented" standards you know where you stand since countless others will fall with you [11:44:49] <superdump> kierank: mmm, and so there would be serious repercussions for anyone suing people for patent infringements [11:45:48] <peloverde> still alcatel-lucent managed to attack mp3 from the outside [11:46:06] <superdump> mmm [11:50:16] <peloverde> DonDiego, I'm watching FOSDEM talks I missed and i can see you o.O [11:50:46] <DonDiego> where? [11:51:06] <DonDiego> distros vs. upstream? [11:51:16] <peloverde> yep [12:07:19] <mru> omg, "It is illegal for you to write a player even if you know how to write one except for the codecs and container formats developed by Xiph." [12:08:29] <DonDiego> huh? [12:09:08] <kshishkov> is that official Mozilla position? [12:09:30] <bilboed-pi> mru, where on earth is that from ? [12:09:49] <kierank> wow even gabest chimed in [12:09:55] <mru> someone commenting on my blog [12:11:37] <mru> notice how everybody who claims to have ever touched the ogg format hates it [12:11:41] <mru> except monty [12:11:52] <kshishkov> monty has not touched it [12:12:01] <mru> I was getting to that [12:12:33] <peloverde> I love the <I love vorbis but hate ogg> posts from various implementers [12:12:59] <kshishkov> well, Xiph is trying to discourage them on Vorbis as well [12:14:50] <pross-au> meh, i use chromium-browser [12:15:12] <mru> I would, did it not require dbus [12:16:18] <peloverde> I use chromium-browser but wish the ubuntu maintainer would rename chromium-codecs-ffmpeg-nonfree to something saner [12:16:23] <siretart`> the ubuntu chromium package doesn't require dbus [12:16:49] <mru> siretart`: how'd you get rid of it? [12:17:17] <siretart`> mru: the package doesn't declare a dependency [12:17:38] <siretart`> what does chromium use dbus for after all? [12:17:44] <mru> no idea [12:17:53] <mru> gentoo lists it as a dependency [12:18:05] <siretart`> it doesn't seem very well integrated into gnome nor kde anyway [12:18:06] <mru> I could force-install it without and see what happens [12:18:52] <siretart`> DonDiego: do you remember the av_lock_mgr() patch for 0.5.1? it seems that the kde folks scream for that as well... [12:20:20] <KotH> stupid question: what in the world could be patented in a file format? [12:20:31] <mru> storing bits in a sequence [12:20:32] <KotH> (disregarding all prior art and trivial patents) [12:20:39] <pross-au> If video is important as the HTML5 supporters say, then the mozilla dev will either change their mind or find themselves with a diminishing user-base as people move to chrome [12:20:58] <peloverde> The MPEG-4 scenegraph? (that no one uses in practice) [12:21:06] <pross-au> KotH: novel chunking :D [12:22:18] <peloverde> MPEG-4 Systems (-1) originally included a lot of flash like interactivity [12:22:51] <peloverde> pross-au, there are a lot of rabid irrational firefox fans [12:23:02] <kierank> and 3d and vr and all sorts of other crap [12:24:28] <pross-au> peloverde: yeah, but who is listening to them? [12:24:55] <pross-au> i dont see it translating into theora optimised graphics boards [12:24:58] <peloverde> My guess (and only a guess) is if you stuck to a minimal mp4 (container not codec stack) it would be hard to step on a patent [12:25:18] <pross-au> mru: nice article btw [12:25:27] <peloverde> pross-au, what I'm implying is that these people will give firefox a long leash before jumping ship [12:29:32] <mru> eeeww, chromium wants gconf too [12:30:11] * siretart` doesn't find any key containing 'gconf' in his database [12:30:40] <siretart`> err [12:30:50] * siretart` doesn't find any key containing 'chrome' nor 'chromium' in his gconf database [12:31:14] <peloverde> siretart`, my guess is it uses it to pull in gnome proxy settings or the like [12:31:33] <peloverde> it really should exec gconftool-2 [12:32:20] <siretart`> oh right, the proxy settings dialog fires up the gnome settings dialog [12:33:41] <mru> I'm forcing it, let's see what breaks [12:34:40] <DonDiego> siretart`: what do you mean by "scream for that"? [12:35:04] <CIA-92> ffmpeg: alexc * r22206 /trunk/libavcodec/aac.c: [12:35:04] <CIA-92> ffmpeg: AAC: Return the number of bytes consumed in decoding a frame. [12:35:04] <CIA-92> ffmpeg: The libfaad wrapper does this. [12:35:31] <siretart`> DonDiego: the kdesupport package doesn't compile anymore :-) [12:35:46] <siretart`> as, 0.5.1 seems to help them with that [12:41:12] <DonDiego> oh, good :) [12:42:03] <merbzt> some nice tree structure [12:42:26] <DonDiego> siretart`: Yuvi keeps committing theora stuff, this is looking good for 0.6... [12:43:01] <DonDiego> mru: did you make any more changes to your text? [12:43:09] <peloverde> DonDiego, no comments so far on the latest SBR patch, I'm going to interpret that as a good thing [12:43:58] <mru> DonDiego: yes, I made some changes [12:44:19] <mru> Exception: Call to 'pkg-config --cflags gconf-2.0' returned exit status 1. while loading dependencies of base/base.gyp while loading dependencies of net/net.gyp while loading dependencies of app/app.gyp while loading dependencies of build/all.gyp while trying to load build/all.gyp [12:44:22] <DonDiego> peloverde: excellent :) [12:47:02] <siretart`> Yuvi++! :-) [12:48:14] <siretart`> DonDiego: 0.5.1 uploaded to ubuntu [12:51:31] <peloverde> Is thilo looking into the ALS icc-11.1 issue? it would clear up another yellow spot on fate for 0.6 [12:53:29] <DonDiego> siretart`: could you get the ubuntu chromium maintainers to call their ffmpeg packages something else than "nonfree"? [12:53:58] <siretart`> DonDiego: there is no such package in ubuntu [12:54:20] <peloverde> There is a chromium-team lp account with a chromium ppa [12:54:21] <siretart`> however, there is a well known PPA carrying such packages [12:54:44] <siretart`> I don't know the guy who is working on the packages [12:54:56] <peloverde> It seems odd that there are two packages at all [12:55:13] <siretart`> peloverde: yes, it seems that asac is working on 'official' packages [12:55:37] <peloverde> all the formats supported by chromium-codecs-ffmpeg-nonfree are in the ffmpeg package in main [12:55:45] <peloverde> so why does chromium do the weird split? [12:56:01] <siretart`> because chromium doesn't work with ffmpeg 0.5? just a guess [12:56:24] <CIA-92> libswscale: stefano * r30825 /trunk/libswscale/ (swscale-test-all.sh swscale-test.c): (log message trimmed) [12:56:24] <CIA-92> libswscale: Make swscale-test take in input the name of the input and the output [12:56:24] <CIA-92> libswscale: format. [12:56:24] <CIA-92> libswscale: Make swscale-test only perform the test from the input to the output [12:56:24] <CIA-92> libswscale: format rather than perform all. [12:56:25] <CIA-92> libswscale: Also implement swscale-test-all.sh, for performing all the tests. [12:56:26] <CIA-92> libswscale: Improve flexibility of the swscale-test tool, this way is simpler to [12:56:26] <CIA-92> libswscale: stefano * r30826 /trunk/libswscale/swscale.c: [12:56:27] <CIA-92> libswscale: Fill the r, g, b values used for computing the c->pal_yuv table in the [12:56:27] <CIA-92> libswscale: case where the source format is PIX_FMT_GRAY8. [12:56:28] <CIA-92> libswscale: This is required as PIX_FMT_GRAY8 has been declared as a paletted [12:56:28] <CIA-92> libswscale: format in FFmpeg r22191, fix GRAY8 -> RGB conversion. [12:56:29] <CIA-92> libswscale: stefano * r30827 /trunk/libswscale/ (swscale-test-all.sh swscale-test.c): [12:56:29] <CIA-92> libswscale: Revert r30825, it was not supposed to be committed. [12:56:30] <CIA-92> libswscale: 127.32L to me, beware when using git svn dcommit for committing stuff [12:56:36] <peloverde> no i don't mean chromium-codecs-ffmpeg-nonfree vs ffmpeg, i mean chromium-codecs-ffmpeg-nonfree vs chromium-codecs-ffmpeg [12:56:50] <peloverde> I understand that chromium-codecs-ffmpeg* needs the google patches [12:56:54] <CIA-92> libswscale: to svn... [12:57:05] <siretart`> then you understand more than me about it :-) [12:58:20] <DonDiego> peloverde: what google patches? [12:58:28] <DonDiego> and where are those packages you speak of? [12:58:29] <peloverde> I opened up an inquiry on the name and this was the response: https://answers.launchpad.net/chromium-browser/+question/81283 [12:59:07] <peloverde> DonDiego, These patches: http://src.chromium.org/viewvc/chrome/trunk/deps/third_party/ffmpeg/patches… [13:01:09] <DonDiego> are these the patches that already got merged or new ones? [13:02:23] <peloverde> new ones/what was left of the last round [13:02:31] <peloverde> there used to be somewhere around 50 [13:02:36] <superdump> peloverde: why not add Google Chrome to the projects using ffmpeg page too? [13:02:56] <DonDiego> go right ahead [13:03:09] <DonDiego> so, let's review and commit those patches :) [13:03:17] <DonDiego> i see aac stuff, superdump, peloverde ? [13:03:27] <peloverde> superdump, they are more or less the same thing?, I wasn't sure to list them separately or what [13:03:36] <peloverde> DonDiego, 03 was fixed recently in a different manner [13:03:57] <peloverde> DonDiego, and the bug only manifested with replacement bitsream reader they were using [13:04:11] <superdump> peloverde: well, i'd be inclined to list Google Chrome over Chromium just because it's higher profile [13:04:16] <superdump> but listing both should be fine [13:04:26] <peloverde> 2 lines or 1? [13:04:35] <superdump> or put them together as one line with two links [13:04:36] <superdump> :) [13:04:47] <peloverde> that's what I meant by one [13:04:57] <peloverde> and in that case would it be under G or C [13:05:20] <DonDiego> Chromium / Google Chrome [13:05:26] <DonDiego> kshishkov: http://src.chromium.org/viewvc/chrome/trunk/deps/third_party/ffmpeg/patches… [13:05:29] <DonDiego> this one is for you [13:05:38] <peloverde> yes they have new BSFs [13:06:18] <peloverde> DonDiego, 02_mov_dref_looping.patch was discussed once and rejected but i don't remember why [13:07:05] <peloverde> 06+07 are about ogg needing big chunks of the decoder, blol [13:07:33] <kshishkov> DonDiego: well, the question is why. [13:07:54] <peloverde> kshishkov, presumably to pipe it off to some hardware decoder? [13:08:10] <kshishkov> EDONTCARE then [13:08:27] <DonDiego> bah [13:08:34] <DonDiego> if it's useful to some people.. [13:08:51] <DonDiego> didn't we have some googlers on the channel at some point? [13:09:26] <peloverde> schekus and fbachard sometimes lurk here [13:09:42] <peloverde> they aren't on in their channel either right now [13:09:51] <peloverde> probably because it is 5AM in california [13:10:36] <DonDiego> mru: http://src.chromium.org/viewvc/chrome/trunk/deps/third_party/ffmpeg/patches… [13:10:45] <DonDiego> the second configure hunk of this patch looks ok [13:11:15] <mru> I don't know [13:11:22] <mru> iirc there was more to it than that [13:11:33] <DonDiego> peloverde: what about 03? [13:11:52] <peloverde> The vehemently claim that for their benchmarks -O2 is faster than -O3 [13:12:13] <DonDiego> no, i mean patch 03-whatever [13:12:17] <DonDiego> aac one [13:12:29] <peloverde> <peloverde> DonDiego, 03 was fixed recently in a different manner [13:12:34] <peloverde> <peloverde> DonDiego, and the bug only manifested with replacement bitsream reader they were using [13:12:56] <DonDiego> oh, sorry, missed the scrollup [13:13:35] <peloverde> It's a nastly flaw in the aac bitstream format that makes it zero padding unfriendly [13:13:48] <siretart`> peloverde: excellent link. I've just subscribed there and comment on that as well [13:14:27] <DonDiego> mru: there are two build system patches as well: [13:14:29] <DonDiego> http://src.chromium.org/viewvc/chrome/trunk/deps/third_party/ffmpeg/patches… [13:14:36] <DonDiego> http://src.chromium.org/viewvc/chrome/trunk/deps/third_party/ffmpeg/patches… [13:15:24] <peloverde> DonDiego, those increase coupling between lavf and lavc [13:15:56] <mru> and they're wrong [13:16:00] <peloverde> though arguably so do the proposed ways for dealing with HE-AAC [13:16:06] <DonDiego> lavf depends on lavc anyway [13:16:07] <mru> demuxing flac in ogg shouldn't require the flac decoder [13:17:14] <mru> if it needs some header parsing function, that should be broken out and enabled separately [13:17:58] <DonDiego> we should tell the google people that [13:18:06] <DonDiego> does anybody have a contact? [13:18:45] <peloverde> fbachard and scherkus or crbug.com [13:19:07] <DonDiego> mru: what about the dirac one, that looks less harmful [13:19:20] <mru> also wrong [13:19:54] <mru> whatever it needs from the raw dirac "demuxer" should be factored out [13:20:49] <mru> as a general rule, no *_encoder/decoder/muxer/demuxer should depend on another [13:21:04] <mru> if there's common code they both need, that should be separated [13:26:53] <CIA-92> ffmpeg: pross * r22207 /trunk/libavformat/bink.c: Guard against invalid memory read [13:28:47] <CIA-92> ffmpeg: pross * r22208 /trunk/libavformat/bink.c: handle errors reported by av_get_packet() in Bink demuxer [14:47:26] <DonDiego> mru: do comments not appear immediately on your blog? [14:48:21] <mru> first-time commenters are moderated [14:48:48] <mru> and I don't continuously monitor my email [14:51:04] <kshishkov> trolling on Xiph formats - just cast a doubt they are not as good as advertised! [14:51:05] <DonDiego> :) [14:51:21] <DonDiego> mru: kevin granade wrote some good points that you could address [14:51:46] <mru> I'll wait for the dust to settle, then write a response [14:54:09] <DonDiego> he mentions more or less what i said [14:54:22] <mru> he also misunderstood half the article [14:54:31] <DonDiego> if you make the tone a bit more neutral it's more difficult for dissenters to dismiss what you wrote [14:54:41] <DonDiego> also, comparisons with other containers are instructive [14:54:57] <DonDiego> well, just make the article harder to misunderstand :) [14:55:23] <DonDiego> it is a good article already, i'm very happy you wrote it, i'm just trying to help you make it even better [14:55:44] <DonDiego> at some point you could merge it with the timestamp article into one coherent complete criticism [14:55:55] <mru> some of the comments are way beyond the level of stupidity I expected [14:56:03] <DonDiego> nah, it's ok [14:56:28] <DonDiego> just present the trolls with facts [14:56:41] <DonDiego> and ignore them if they continue beating their drums [14:56:58] <mru> I have to stop somewhere [14:57:07] <mru> I don't have time to explain every last detail [14:57:20] <DonDiego> of course [14:57:41] <DonDiego> but you know this has been a recurring topic over the years [14:57:59] <DonDiego> if you extend it a bit you will not have to repeat yourself forever :) [14:58:21] <mru> I'll try to extend it a bit later [14:58:25] <mru> I have to do some real work now [14:58:56] <jez9999> BBB: hey... see the patch to issue 1790 [14:59:17] <DonDiego> good [14:59:31] <DonDiego> mru: and thanks again for the writeup, it's an enlightening read [15:00:50] <mru> it feels a bit futile though [15:01:18] <mru> those who understand it already agree, and those don't will never be swayed [15:01:38] <DonDiego> i understand the feeling [15:01:48] <DonDiego> but there are a lot in between that watch the discussion [15:01:55] <DonDiego> without a stake in either position [15:02:10] <DonDiego> they can use such texts to form an informed opinion [15:02:30] <DonDiego> the more facts we give them, neutral facts, the more informed these opinions will be [15:02:55] <DonDiego> IME neutral bystanders are best swayed by neutral factual information [15:05:30] <BBB> jez9999: done [15:06:02] <jez9999> BBB: don't you administer that file? [15:06:18] <BBB> jez9999: yes, but martin wrote the patch so he may check it in for me [15:06:24] <BBB> jez9999: don't worry, he'll apply in a second [15:06:26] <BBB> he's quite fast [15:06:44] <jez9999> ok [15:06:56] <jez9999> the funny thing is, i experimented, and the exiting code seems to be interruptable anyway [15:07:12] <jez9999> when i call thread.interrupt() in java and it's presumably sitting on select(), it does return [15:08:09] <BBB> well yes [15:08:12] <BBB> but we don't all use java [15:08:21] <BBB> so this is better :) [15:08:24] <jez9999> how does it work even in java though? [15:08:39] <BBB> probably a kernel thing [15:08:44] <BBB> ctrl-C also interrupts select() waits [15:08:48] <BBB> probably same mechanism [15:08:53] <jez9999> ah [15:08:56] <BBB> but I have no idea of how that works [15:09:04] <BBB> :) [15:09:48] <wbs> jez9999/BBB: applied the select/url_interrupt_cb patch [15:09:51] <CIA-92> ffmpeg: mstorsjo * r22209 /trunk/libavformat/rtpproto.c: Check url_interrupt_cb in rtp_read, wait in select for max 100 ms before rechecking url_interrupt_cb [15:09:56] <BBB> jez9999: see? [15:10:09] <jez9999> yup [15:10:31] <jez9999> i'm still relying on my own build for IP filtering though. o well. [15:10:52] <BBB> we'll get there, I'm a bit slow at getting moving there [15:22:37] <siretart`> does someone know the screencast software recordmydesktop? the created ogv fail to decode with ffmpeg :-( [15:23:06] <kshishkov> sample please ;) [15:23:40] <KotH> and upload them ;) [15:23:56] <DonDiego> siretart`: do they work with something else? [15:24:30] <siretart`> DonDiego: they work fine in totem [15:24:47] <mru> wtf? [15:25:16] <mru> you found a file that plays in totem? [15:25:26] <siretart`> scary, no? [15:26:27] <BBB> well look [15:26:32] <BBB> gstreamer is designed around ogg [15:26:50] <BBB> maybe recordmydesktop is gst as well? [15:27:29] <KotH> o_0 [15:27:32] <KotH> around ogg? [15:27:49] <KotH> i thought the mkv guys got gstreamer flying? [15:27:56] <mru> I thought it was designed around hype [15:28:14] <mru> no, mkv and gst are quite separate [15:28:39] * KotH atleast remembers how the mcf guys went to build gstreamer after the mplayer-mcf cooperation broke up [15:28:50] <mru> mkv was made by robux4 et al [15:29:12] <BBB> I implemented mkv support in gst [15:29:22] <BBB> long before the ffmpeg patch and non-c++ mplayer support [15:29:33] <BBB> but it was not designed around it [15:29:44] <BBB> they (mkv guys) wanted to, but there was no interest [15:31:29] <siretart`> filed as https://roundup.ffmpeg.org/issue1793 [15:32:27] <siretart`> might be a dupe of #746, not sure though [15:35:57] * mru writes recursive gas macros [15:36:25] <kshishkov> do gas creators know of that possibility? [15:36:40] <mru> probably [15:36:48] <mru> you can also have macros defining macros [15:36:49] * kshishkov suspects that is uses cpp as well [15:36:53] <mru> recursively... [15:36:56] <kshishkov> oh, lispy! [15:39:08] <mru> throw in some .include directives for extra fun [15:55:39] <twnqx> <yoann_> nooooo :( error [15:55:39] <twnqx> <yoann_> /usr/local/arm/3.4.3/bin/arm-linux-as: option non reconnue '-HAVE_AV_CONFIG_H' [15:55:39] <twnqx> <yoann_> make: *** [libavcodec/arm/dsputil_arm.o] Erreur 1 [15:55:52] <twnqx> hm... is there something passed on from C to as? [15:56:19] <superdump> looks like it should maybe be -DHAVE_AV_CONFIG_H [15:56:25] <mru> broken gcc [15:56:57] <mru> we really only support gcc4 and armcc for arm [15:58:21] <mru> older gcc versions are too crap to bother with [16:02:00] <twnqx> http://www.engadget.com/2010/03/04/mios-tegra-powered-moov-v780-puts-maps-7… cute [16:07:55] <kierank> twnqx: pricey [16:08:21] <twnqx> yeah :X [16:08:25] <twnqx> still cute [16:11:03] <kshishkov> still, 720p on 800x480 screen is a bit overcalled [16:12:07] <twnqx> also, from a tegra i'd expect 1080p [16:12:17] <twnqx> (on the hdmi at least) [16:15:55] <twnqx> what i really want... is that nokia netbook with a tegra2 mainboard [17:36:28] <BBB> I hate it when I can't extract exe files to see their content [17:36:34] <BBB> what do you people use? [17:36:40] <kshishkov> with what? [17:37:21] <kshishkov> there are many tools for many types for extraction [17:37:25] <jai> extract exe files? [17:37:34] <jai> do you mean unpacking? [17:38:02] <mru> I guess he means a self-extracting compressed archive [17:38:16] <jai> 7zip perhaps [17:38:28] <kshishkov> unzip/unrar/cabextract usually enough [17:42:19] * kshishkov wonders why his custom asm function works in all cases but when callee is compiled with gcc -O1 [17:43:24] <mru> cpu? [17:43:30] <kshishkov> x86 [17:43:50] <mru> inline asm? [17:44:03] <kshishkov> no, standalone [17:44:16] <mru> did you mean _caller_ compiled with -O1? [17:44:35] <kshishkov> ah, right [17:44:53] <mru> you're probably clobbering a callee-saved register [17:45:04] <mru> and gcc was only using it with -O1 [17:45:14] <kshishkov> those are? [17:45:19] <mru> not a clue [17:45:28] <mru> try saving all regs you use and see if that helps [17:46:50] <Compn> bwaahahaha [17:46:52] <Compn> http://web.archive.org/web/20000824073138/209.237.24.132/OnlineVideos/GiguQ… [17:46:58] * Compn is happy to find new samples [17:48:23] <Compn> oh qdmc , nevermind [17:49:42] <mru> btw, what's the matter with the cygwin/gcc4.4 fate build? [18:19:57] <BBB> drv: do you still have that link from yesterday? [18:25:11] <mru> lol http://stevehoffman.tv/forums/showpost.php?p=5094768&postcount=38 [18:26:31] <thresh> niiice [18:26:31] <kshishkov> mru: that's why it's called "psychoacoustics" - it's all in a head of listener [18:27:16] <mru> on a *really* cheap gadget I might believe there could be a difference [18:27:34] <mru> decoding the compressed file will cause more power draw from the cpu [18:27:46] <mru> if the power distribution is weak, this could affect the dacs [18:29:02] <kshishkov> then 256k AAC must sound really awful there [19:11:35] <CIA-92> ffmpeg: fenrir * r22210 /trunk/libavcodec/flashsv.c: Fixed buffer overread in flashsv decoder. [19:12:37] <thresh> woah, laurent has an svn account? [19:13:04] <kshishkov> since ages I think [19:13:10] <CIA-92> ffmpeg: fenrir * r22211 /trunk/libavcodec/dxva2_h264.c: Fixed DXVA2 H264 hwaccel after luma/chroma_weight changes. [19:13:17] <kshishkov> used mostly for Flash-related stuff patching though [19:19:49] <mru> fenrir has not committed before jan 2010 [19:19:57] <mru> I don't think he has another account [19:21:38] <kshishkov> indeed, but he send some patches though [20:17:40] <Yuvi> gah, these recordmydesktop oggs are like not interleaved at all, but they're not chained either [20:22:12] <mru> that's invalid according to some parts of the spec [20:22:29] <mru> other parts could be interpreted as allowing it [20:23:42] <mru> btw, what was the verdict on the continuation bug? [20:23:47] <mru> is it still in libogg? [20:24:52] <Yuvi> I would say yes, but I haven't reproduced it myself [20:25:02] <mru> do you know what triggers it? [20:25:30] <mru> easy enough to feed it dummy packets of the right sizes to make it happen if they are known [20:25:30] <Yuvi> last time it came up some xiph people agreed but couldn't figure out where in libogg it happened [20:25:40] <mru> great [20:26:03] <Dark_Shikari> mru: another reason to hate C++ [20:26:09] <Dark_Shikari> doing a homework assignment, and apparently this is actually legal: http://pastebin.org/101298 [20:26:17] <Yuvi> probably if you feed random packets of mod 255 it'll trigger eventually [20:27:19] <mru> Dark_Shikari: it's easy enough to follow the pointers, but it sucks that you can do such things [20:27:24] <mru> just imagine the runtime overhead of that [20:27:34] <Dark_Shikari> but what actually happens? [20:27:45] <mru> compile and see [20:27:46] <Dark_Shikari> it's completely non-obvious [20:27:48] <Dark_Shikari> lol [20:28:37] <mru> *ap = generic; copies 'generic' to wherever ap is pointing [20:28:48] <mru> at that time it is point at the same thing cp is [20:28:54] <Dark_Shikari> yes, but what happens if you copy a non-cow over a cow [20:29:02] <Dark_Shikari> and then tell the cow to do something cow-speicifc? [20:29:05] <ohsix> whats worse is the compiler cnt always figure out which method to call from the context [20:29:12] <mru> either you get runtime conversion or an exception [20:29:22] <mru> not sure which [20:29:25] <Dark_Shikari> but you can't convert from Animal to Cow [20:29:30] <Dark_Shikari> only from Cow to Animal [20:29:34] <Dark_Shikari> subtyping isn't reversible [20:29:36] <mru> but you can degrade the cow into an animal [20:29:39] <mru> or a burger [20:29:41] <Dark_Shikari> but animals can't moo [20:29:55] <Dark_Shikari> also, the assignment says it won't runtime exception [20:29:59] <Dark_Shikari> o.0 [20:30:06] <mru> it could be overloaded for Animal [20:30:36] <Dark_Shikari> it could keep the moo function while overwriting the data that's shared [20:30:42] <Dark_Shikari> i.e. cp->moo() will print "Bob" [20:30:44] <mru> you don't know whether moo is virtual or not either [20:30:52] <Dark_Shikari> it's virtual [20:31:00] <Dark_Shikari> and only cows have it. [20:31:03] <mru> you have the class definitions? [20:31:13] <Dark_Shikari> no, it just says that it's virtual. [20:31:28] <Dark_Shikari> I'm pretty sure it's going to print "Bob". [20:31:35] <mru> why? [20:31:36] <drv> BBB: http://www.mindspring.com/~alanh/fracs.html [20:31:46] <BBB> drv: thanks, I found it in my logs [20:31:48] <BBB> long live logs [20:31:52] <drv> :) [20:31:55] <mru> if Animal doesn't have a moo() function it won't work [20:31:57] <Dark_Shikari> because the string is a common member of all Animals [20:32:04] <Dark_Shikari> moo is cow-only [20:32:08] <Dark_Shikari> thus, the assignment will overwrite the string [20:32:10] <Dark_Shikari> but not the moo [20:32:16] <mru> not so hasty [20:32:22] <Dark_Shikari> well, the assignment says it will not error [20:32:23] <Dark_Shikari> and it will compile [20:32:27] <Dark_Shikari> and it will run without errors [20:32:41] <Dark_Shikari> oh wait, it says it "won't lead to type errors at runtime" [20:32:45] <Dark_Shikari> it could lead to some other type of error. [20:32:47] <mru> the question can't be answered without seeing the full source you're compiling [20:33:12] <mru> you could get some weird virtual function exception [20:36:37] * Dark_Shikari just writes it up [20:37:50] <mru> daft course if you ask me [20:38:35] <Yuvi> every time I think about implementing reading ogg skeleton to fix some problem with ogg, it turns out that skeleton doesn't actually handle that problem [20:38:37] <ohsix> you can use the name of the class to find the right activation site if its ambiguous, but its still lame [20:38:53] <Yuvi> I still haven't figured out why it exists [20:39:25] <mru> I could say that about xiph itself [20:43:30] <Dark_Shikari> mru: it prints bob. tested it [20:43:44] <mru> code? [20:43:54] <Dark_Shikari> http://pastebin.org/101332 [20:43:56] <Dark_Shikari> I'm shit at C++ [20:44:31] <ohsix> best part of resolving those things is it'll try and find a type conversion path and stop at the first one that fits [20:45:13] <mru> Dark_Shikari: what happens if you have moo() print something that only exists in Cow? [20:45:22] <Dark_Shikari> that would be different and potentially fail horribly [20:45:28] <Dark_Shikari> or probably it'll keep the name [20:45:29] <Dark_Shikari> let me try [20:45:30] <ohsix> like if a copy constructor can promote one type to another, it'll do it to resolve the signature [20:45:56] <Dark_Shikari> Yes [20:45:59] <Dark_Shikari> it works as I thought [20:46:04] <mru> what does it do? [20:46:07] <Dark_Shikari> if the value is only in cow, it'll print "Flossie" [20:46:11] <Dark_Shikari> if the value is in both, it'll print "Bob" [20:46:51] <mru> how is ->moo actually resolved? [20:46:55] <mru> in asm [20:47:41] <Dark_Shikari> I have no idea. [20:47:44] <Dark_Shikari> let me look [20:47:58] <Dark_Shikari> oh holy fuck name mangling [20:48:12] <Dark_Shikari> wow that's a lot of asm [20:48:16] <Dark_Shikari> er, if you want to look, feel free [20:49:07] <Dark_Shikari> oh, it inlines everything [20:49:09] <Dark_Shikari> it figures it out at compile time [20:49:21] <Dark_Shikari> and all it does is print flossie and bob [20:49:38] <mru> well, let's mess with it some more [20:51:05] <Dark_Shikari> feel free, I'm done with that question =p [20:51:06] <Dark_Shikari> fuck c++ [20:52:33] <DonDiego> Yuvi: they continue revving ogg, but going back and using something else is out of the question - who understands those guys... [20:53:13] <mru> "it would break a million devices" apparently [20:53:14] <mru> lol [20:53:15] <Dark_Shikari> DonDiego: if you want to kill ogg, write competing applications that use something else [20:53:22] <Dark_Shikari> i.e. icecast replacement, etc [20:53:44] <Dark_Shikari> don't bitch, do. [20:55:31] <mru> we should start an official "kill ogg" campaign [20:55:44] <mru> facebook group, anyone? [20:56:50] <Yuvi> DonDiego: well, I don't fully disagree that it became too late to update ogg after they stuffed theora in it [20:56:56] <Yuvi> but fixing it then would've been nice [20:57:14] <Yuvi> update it in incompatible ways that it [20:57:29] <DonDiego> the installed base they talk about is bogus [20:57:40] <mru> of course it is [20:57:43] <DonDiego> there are more devices out there supporting mkv than ogg [20:57:55] <Dark_Shikari> and devices that only do vorbis hardly count [20:58:04] <DonDiego> if they start supporting mkv themselves [20:58:10] <DonDiego> they suddenly will work on these devices [20:58:18] <Dark_Shikari> if they support mkv, they will have to admit they made a mistake. [20:58:25] <Dark_Shikari> But until pirates start using ogg, you probably don't have to worry. [20:58:35] <Yuvi> are there hardware devices supporting mkv that support theora? [20:58:40] <Dark_Shikari> doubtful [20:58:59] <ohsix> audio devices don't count? heh; what about games that use ogg/vorbis too [20:59:14] <Dark_Shikari> ohsix: what I mean is that they're talking about ogg in the context of things other than vorbis [20:59:18] <mru> games don't count [20:59:21] <mru> they're already made [20:59:22] <Dark_Shikari> and yes, games don't count [20:59:24] <Dark_Shikari> they're already made [20:59:27] <Dark_Shikari> hence Bink's idea [20:59:31] <mru> they'll still exist even if a new format is created [20:59:31] <Dark_Shikari> no backwards compatibility whatsoever [20:59:52] <ohsix> oic, i must have missed some context [20:59:55] <Dark_Shikari> I'll make a prediction, by the way [21:00:20] <Dark_Shikari> There will be no ASIC created in the next 3 years that does 1080p Theora decoding. [21:00:46] <Dark_Shikari> (not one actually put to silicon and sold in a product, at least) [21:00:47] <DonDiego> Yuvi: not that i know, but all you need to add in is another decoder, not a demuxer also [21:01:04] <mru> well, asic decoding is on the way out [21:01:12] <ohsix> ^ [21:01:12] <DonDiego> and if vorbis worked better in generic containers it would be considered an alternative [21:01:14] <Dark_Shikari> mru: says the iphone [21:01:21] <Dark_Shikari> says your set top box [21:01:22] <mru> it's all semi-programmable accelerators now [21:01:25] <Dark_Shikari> yes, which are all asics [21:01:40] <ohsix> but the "s" part isn't theora, its "video" [21:01:42] <mru> even existing ones could to some extent support theora [21:01:42] <Dark_Shikari> the CABAC decoder does just CABAC [21:01:54] <Dark_Shikari> mru: I doubt any idct hardware could [21:01:57] <mru> what is theora MC like? [21:02:03] <Dark_Shikari> it's basically a carbon copy of mpeg-2 [21:02:07] <Dark_Shikari> with a different C position [21:02:12] <Dark_Shikari> (simpler C position, h264-style) [21:02:24] <mru> so chances are existing MC accels could do it [21:02:28] <Dark_Shikari> MC is fast though [21:02:31] <mru> idct, probably not [21:02:35] <Dark_Shikari> it's bilinear, that's like 5% of the total decoding time [21:02:48] <Dark_Shikari> idct is more costly probably [21:02:56] <Dark_Shikari> requires 32-bit math and can't be done by existing hardware [21:02:57] <mru> MC is more than that on tiny systems [21:03:10] <Dark_Shikari> I'd be more worried about entropy decoding [21:03:21] <Dark_Shikari> my calculations show that for 1080p30, assuming every single dct coefficient slot is used [21:03:26] <Dark_Shikari> and a 64-byte cacheline size [21:03:31] <Dark_Shikari> the maximum memory bandwidth required is 6GBps [21:03:44] <Dark_Shikari> for dct coeffs only [21:03:55] <mru> new set top boxes have ddr3 memory [21:04:05] <Dark_Shikari> yeah, ddr3 finally solves that [21:04:07] <Dark_Shikari> it's 6.4GBps [21:04:34] <mru> TI's coming chips support triple 1080p60 h264 [21:04:43] <mru> that's a lot of memory bandwidth [21:04:54] <Dark_Shikari> h264 is much less than theora [21:04:59] <Dark_Shikari> about two orders of magnitude less [21:05:04] <DonDiego> Dark_Shikari: do you want to bet about that prediction? [21:05:05] <mru> because it was designed to be efficient [21:05:20] <mru> DonDiego: he'll be old enough to drink then... [21:05:24] <Dark_Shikari> lol [21:05:36] <Dark_Shikari> hmm, good question [21:05:39] <Dark_Shikari> the annoying thing is that the lines between ASICs and DSPs are blurring as mru said [21:06:00] <Dark_Shikari> so it might be hard to actually phrase the bet in a way that's relevant in 3 years [21:06:16] <DonDiego> no, let's bet money, i'm poor :) [21:06:23] <Dark_Shikari> lol, you think you'll win? [21:06:30] <DonDiego> yes [21:06:59] <DonDiego> ok, let's cut out the suspense [21:07:01] <Dark_Shikari> that requires a lot of things to happen: [21:07:02] <DonDiego> i know [21:07:08] <DonDiego> http://www.elphel.com/ [21:07:11] <Dark_Shikari> 1) that theora actually succeed (and not, say vp8) [21:07:26] <DonDiego> their cameras use theora [21:07:29] <DonDiego> in hardware [21:07:43] <Dark_Shikari> encoding? [21:08:19] <DonDiego> it's a camera.. [21:08:31] <DonDiego> of course it encodes, what else would it do? [21:08:41] <KotH> transmutate [21:08:45] <Dark_Shikari> http://www3.elphel.com/sites/default/files/Elphel_Brochure.pdf [21:08:47] <KotH> ;) [21:08:48] <Dark_Shikari> I don't see anything about that here [21:08:53] <DonDiego> http://www.google.com/search?q=theora%20site%3Aelphel.com&btnG=Google+Search [21:08:53] <Dark_Shikari> nor do I see anything about an ASIC [21:09:02] <DonDiego> http://www3.elphel.com/linuxdevices/articles/AT3888835064.html [21:09:09] <Dark_Shikari> it says it captures to JP4 raw [21:09:10] <DonDiego> http://www3.elphel.com/xilinx/publications/xcellonline/xcell_53/xc_video53.… [21:09:20] <Dark_Shikari> um, that's an FPGA, not an ASIC [21:09:26] <DonDiego> bah [21:09:38] <Dark_Shikari> the difference between an FPGA and an ASIC is 50 million dollars of tapeout costs [21:09:42] <DonDiego> just admit defeat ;-p [21:09:44] <Dark_Shikari> _that_ is what I am betting on [21:10:00] <KotH> Dark_Shikari: it's 50k to 5mio [21:10:01] <ohsix> goalposts being moved [21:10:07] <Dark_Shikari> also, it says it only does 30fps in raw mode [21:10:08] <KotH> Dark_Shikari: not 50M :=) [21:10:15] <Dark_Shikari> so, again, no [21:10:18] <Dark_Shikari> I said 1080p30 [21:10:21] <Dark_Shikari> it doesn't do 30fps outside of raw mode [21:10:26] <DonDiego> haha [21:10:38] <Dark_Shikari> because the encoder is too slow [21:10:38] <DonDiego> admit you were surprised it even existed :) [21:10:58] <Dark_Shikari> I'm actually surprised they managed to do it in a Spartan 3E [21:11:03] <Dark_Shikari> that's what surprises me the most [21:11:08] <Dark_Shikari> That's a fucking awful FPGA [21:11:47] <Dark_Shikari> It's probably a very very bad encoder of course, but that's a given, cameras always are. [21:12:07] <Dark_Shikari> good HD video encoders usually use something like a Virtex 4 [21:12:11] <Dark_Shikari> well, then again, it's not good. [21:12:50] <ohsix> does anything beside the number of LUs have any bearing on it? the names go over speed classes and LUs [21:13:05] <Dark_Shikari> I don't really know enough about FPGAs to say [21:13:08] * twnqx has a virtex 5 devel board [21:13:22] <Dark_Shikari> twngx: doesn't that thing have like 300k logic units? [21:13:26] <twnqx> ya [21:13:42] <Dark_Shikari> that is a freaking huge fpga [21:13:42] <Dark_Shikari> spartan was like a few thousand I recall [21:13:46] <twnqx> well, depending on the model, those are families [21:13:53] <ohsix> what makes the good ones usually use virtex4 then, besides the numbers are bigger and you know 2 of their model names ;] [21:13:54] <twnqx> spartan 3e is pretty big [21:14:00] <Dark_Shikari> ohsix: more processing power [21:14:09] <Dark_Shikari> Ateme uses TWO virtex 4s in their hardware encoders [21:14:18] <twnqx> virtex4 is pretty old :P [21:14:26] <Dark_Shikari> 60 RD calls per macroblock [21:14:34] <Dark_Shikari> about 2-3 times more than x264 on max settings [21:14:40] <Dark_Shikari> in realtime on 1080i30 [21:14:54] <Dark_Shikari> All at once, of course (yay for copy-pasting logic units) [21:15:09] <ohsix> nice; that doesn't mean they "use" 2, people use fpga to keep the hardware malleable; time can make it better, what they probably do have is plenty of capacity to do even expensive things without a hw changeout [21:15:36] <twnqx> spartan 3e ranges from 100k to 1.6m gate equivalents [21:16:15] * twnqx uses spartan 3e on some hobby project [21:16:28] <twnqx> but next project i'll try spartan 6 :] [21:17:04] <twnqx> just need to figure where to buy them, none of my usual suppliers have them :( [21:17:17] <ohsix> they can put cpu/dsp ip in next to their custom blocks too; those take up space but makes stuff way more maintainable [21:17:26] <Dark_Shikari> ohsix: they do use 2 [21:17:28] <Dark_Shikari> they duplicate the encoder [21:17:35] <Dark_Shikari> one works a few seconds ahead of the other for lookahead purposes. [21:17:40] <mru> Dark_Shikari: I've seen the output of the elphel cams [21:17:43] <mru> not impressive [21:17:46] <Dark_Shikari> mru: not surprised [21:17:48] <twnqx> virtex4s can already have a power pc core embedded, no need to waste fpga space on that [21:17:49] <mru> hardly any mc [21:17:53] <Dark_Shikari> also, I suspect that encoding is actually easier than decoding for theora [21:18:02] <Dark_Shikari> because you can parallelize DCT coefficient creation, but not decoding. [21:18:15] <Dark_Shikari> This would be solved if theora stored a pointer to the start of each set of DCT coeffs [21:18:23] <Dark_Shikari> well, actually no, not even that, because of zero-runs [21:18:26] <mru> I think some old linuxtag videos were made with those cameras [21:18:30] <mru> 2007 or 2008 [21:18:35] <ohsix> twnqx: i'm thinking on situations in particular where the software is the only differentiation [21:19:06] <twnqx> i wouldn't run the entropy encoding in hardware e.g. [21:19:08] <ohsix> ie big magic box with a bunch of cards and memory; and the software that actually does something [21:19:49] <twnqx> virtex 5/6 have dsp features, e.g. fast multipliers, as well [21:19:55] <Dark_Shikari> twnqx; yes, I know ateme uses a bit cost approximation to avoid full cabac on every RD call [21:20:03] <Dark_Shikari> i.e. not even what x264 does, a much more parallelizable option [21:20:12] <Dark_Shikari> since huge amounts of linear stuff in fpgas sucks [21:20:35] <twnqx> yeah :P [21:25:25] <Dark_Shikari> mru: I'm guessing on that kind of fpga you can't get much of a fancy motion search. [21:26:30] <twnqx> never looked into motion searching algorithms [21:27:13] <twnqx> heh, Dark_Shikari... want a small spartan 3e to try out? [21:27:34] <Dark_Shikari> I had one a while back, never used it [21:27:37] <Dark_Shikari> I don't know verilog [21:28:24] <twnqx> that's a problem then, unless you know VHDL :P [21:29:03] <Dark_Shikari> nope =p [21:29:14] <Dark_Shikari> could learn it at some point [21:29:52] <twnqx> is there any description besides the code how motion search works in x264? [21:30:29] <Dark_Shikari> http://akuvian.org/src/x264/overview_x264_v8_5.pdf talks about UMH [21:30:37] <Dark_Shikari> the x264 motion search is not fancy [21:30:41] <Dark_Shikari> the fanciest thing is tesa [21:30:56] <Dark_Shikari> eventually I should make it fancy by adding hierarchical search or something [21:37:23] <twnqx> just reading a few pages in seems to show name for a dozend software patents [21:37:38] <Dark_Shikari> ? [21:38:39] <BBB> http://www.ificandream.com/ <- that's ffmpeg [21:39:03] <Dark_Shikari> BBB: you mean x264 [21:39:05] <Dark_Shikari> and swscale [21:39:07] <Dark_Shikari> and some ffmpeg [21:39:15] <BBB> Dark_Shikari: you know too much :) but yes [21:39:17] <Dark_Shikari> I was at their set last week [21:39:24] <Dark_Shikari> I work for them [21:39:25] <BBB> I know you helped them :) [21:39:33] <Dark_Shikari> good good =p [21:39:40] <Dark_Shikari> so how are you involved in their plan to fill a house with cameras and sluts [21:40:09] <BBB> I guess if I'm bored at night I can always watch the girls have a pillowfight & more [21:40:16] <BBB> my wife might not agree with that [21:40:24] <Dark_Shikari> lol [21:40:34] <BBB> you know what I did btw [21:40:37] <BBB> you suggested me :) [21:40:56] <Dark_Shikari> Wait, which thing was it that you did [21:40:59] <Dark_Shikari> I don't remember [21:41:04] <BBB> lol [21:41:50] <BBB> I did the rtsp and video/audio input a/v sync [21:42:09] <Dark_Shikari> ahhh yes [21:42:14] <Dark_Shikari> you got it working? [21:42:20] <BBB> I think it works [21:43:15] <BBB> "works for me" [21:43:18] <BBB> and the video looks ok [21:43:21] <BBB> so I think it works in general [21:44:35] <Dark_Shikari> awesome. [22:38:14] <mru> ouch, I ran valgrind on python [22:50:43] <BBB> wbs: sorry I'm gonna be a pain today [22:51:02] <BBB> I think it's because work is causing me headaches or so [22:52:50] <janneg> mru: without suppressions file? [22:53:38] <mru> only whatever valgrind has by default [22:53:45] <mru> to squash the glibc errors [22:53:49] <wbs> BBB: no problem, always good when someone questions the things I suggest :-) will get back to the issues tomorrow, though [22:54:03] <BBB> sure [22:54:04] <mru> I got a flurry of use-after-free errors [22:54:05] <mru> scary [22:56:05] <BBB> is memcpy(..,.., 0); defined? [22:56:10] <BBB> man memcpy isn't really clear [22:56:47] <ohsix> n = 0 so nothing is copied [22:57:12] <BBB> so if (x) memcpy(la, lo, x); is redundant? [22:57:18] <mru> yes [22:57:45] <mru> the only thing undefined with memcpy is overlapping buffers [22:57:52] <mru> and invalid buffers of course [22:59:10] * BBB trying to simplify random pieces of code [23:36:22] <CIA-92> ffmpeg: stefano * r22212 /trunk/ffprobe.c: Cosmetics: use consistent spacing in the ffprobe.c options table.

1 0

IRC log for 2010-03-03
by irc＠mansr.com 04 Mar '10

04 Mar '10

[00:10:48] <CIA-92> ffmpeg: cehoyos * r22160 /trunk/libavcodec/vdpau.c: [00:10:48] <CIA-92> ffmpeg: Support B-frames when decoding MPEG-4 with VDPAU hardware acceleration. [00:10:49] <CIA-92> ffmpeg: Based on a patch by NVIDIA. [01:39:21] <CIA-92> ffmpeg: michael * r22161 /trunk/libavcodec/h264.h: [01:39:21] <CIA-92> ffmpeg: Load the whole left side of mv&ref only when needed. [01:39:21] <CIA-92> ffmpeg: 30 cpu cycles faster [01:39:52] <Dark_Shikari> woot more h264 stuff [01:40:32] <mru> those cycle counts are a bit meaningless without more context [01:40:42] <mru> is that per frame, per-mb, per-mv or what? [01:40:46] <Dark_Shikari> per mb [01:41:38] <astrange> http://git.ffmpeg.org/?p=ffmpeg;a=blob;f=libavcodec/mpeg12.c;h=09bac2d8603b… hmm can't qscale*quant_matrix[j] be done when the quant matrixes are loaded? [01:41:53] <Dark_Shikari> sounds very bad for cache if qscale varies often [01:42:26] <Dark_Shikari> then again, I think h264 does that. x264 definitely does [01:43:02] <astrange> well it doesn't vary more than once per mb [01:43:07] <Dark_Shikari> true [01:43:19] <Dark_Shikari> you could precalculate for all possible qscales [02:21:42] <CIA-92> ffmpeg: michael * r22162 /trunk/libavcodec/h264.h: Another 3 useless zeroing instructions. [02:36:19] <mru> lol at winmo-using idiot [03:09:19] <Compn> hah ohloh fixed it [03:09:20] <Compn> http://www.ohloh.net/p/ffmpeg/analyses/latest [03:09:35] <mru> about time [03:09:52] <mru> still haven't fixed autoconf claims [03:11:03] <Compn> haha [03:11:14] <Compn> should call it something different than configure [03:11:19] <Compn> call it ffconfigure :D [03:11:34] <mru> but it's easy to spot genuine autoconf [03:11:48] <mru> if "configure" is larger than C files combined, it's autoconf [03:12:10] <mru> and by larger I mean orders of magnitude larger [03:20:43] <peloverde> they still haven't fixed the c++ claims either [03:20:52] <mru> there is one c++ file [03:20:54] <mru> something beos [03:23:45] <peloverde> really? I can't seem to find it [03:24:06] <mru> libavdevice/beosaudio.cpp [03:25:12] <peloverde> ahh, there it is [03:25:26] <peloverde> for a while ohloh was counting all .h files as c++ [05:48:51] <elenril> Honoome: ping [08:12:17] <superdump> hmm [08:12:21] <superdump> hey DonDiego [08:12:32] <superdump> some bugs in the ffmpeg 0.5.1 release announcement [08:12:37] <superdump> i was just about to fix them :) [08:12:56] <superdump> they point to the 0.5.1 release notes and changelog [08:13:05] <superdump> and the name on the downloads page wasn't edited [08:13:43] <DonDiego> hmmm? [08:15:51] <superdump> DonDiego: i'm fixing it [08:15:53] <superdump> don't worry [08:16:37] <superdump> the version wasn't changed at the top of the release notes [08:16:53] <DonDiego> beat you to it [08:16:54] <superdump> and now i'm not really sure what the version name is supposed to be [08:16:56] <superdump> ok [08:17:27] <superdump> nor the date in the release notes [08:18:31] <DonDiego> imagine that the version name refers to the branch :) [08:20:31] <superdump> hehe [08:21:50] <superdump> oops [08:21:55] <DonDiego> ah, good catch :) [08:22:05] <superdump> better [08:22:12] <superdump> i thought my client needed quotes [08:22:13] <superdump> it seems not [08:23:27] <Dark_Shikari> superdump: so can I harass you to write an x264enc2 gstreamer module? ;) [08:23:37] <Dark_Shikari> I discussed with ds some various API ideas [08:23:45] <Dark_Shikari> to fix the disaster of the current one [08:23:50] <superdump> sure [08:24:11] <superdump> maybe in #gstreamer or a query though [08:24:19] <superdump> here doesn't seem an appropriate place :) [08:24:45] <Dark_Shikari> then let's bounce over there [08:26:00] <CIA-92> ffmpeg: diego * r22163 /branches/0.5/RELEASE: Add point release date. [08:28:13] <DonDiego> WVP2 [08:28:30] <DonDiego> does not have a mentor listed, but it's a first tier project - what gives? [08:28:50] <DonDiego> same for wma lossless and ralf [08:29:59] <Dark_Shikari> WVP2 is the single most important codec imo [08:30:26] <Dark_Shikari> maybe kostya could mentor it? [08:39:17] <DonDiego> why so important? [08:39:54] <Dark_Shikari> according to facebook statistics, it is the most popular missing codec [08:39:59] <Dark_Shikari> by a large margin [08:40:11] <Dark_Shikari> WMA Speech, WMA Pro, and Indeo 5 removed all the ones that were anywhere close [08:40:21] <Dark_Shikari> leaving WVP2 as the sore thumb sticking out, the last one we don't have. [08:40:44] <DonDiego> where is it used? [08:40:54] <Dark_Shikari> it's used by Windows Movie Maker I would guess. [08:41:11] <Dark_Shikari> iirc like 1-2% of all facebook video uploads were wvp2 [08:41:24] <kierank> wow [08:41:31] <superdump> what's the largest? h.264? :) [08:41:37] <Dark_Shikari> superdump: probably mjpeg [08:41:42] <superdump> mmm [08:41:47] <Dark_Shikari> cameras, cell phone cameras [08:41:48] <twnqx> not xvid? [08:41:55] <kierank> why xvid? [08:42:14] <kierank> mjpeg is understandable because of all the crappy cameras [08:51:58] <jai> no ralf eh :) [08:52:41] <astrange> does ralf have any marketshare? [08:52:45] <jai> nope [08:53:01] <astrange> tak has non-zero marketshare, which is bad for a closed source lossless codec [08:53:20] <jai> tak has a huge fanboi base over at HA [08:53:35] <kierank> we should RE those Red codecs [08:53:37] <KotH> HA? [08:53:42] <kierank> that would shut all the RED fanboys up [08:53:42] <astrange> hydrogenaudio [08:53:56] <jai> kierank: we should first fix our demuxer :| [09:05:48] <DonDiego> hey, what happened with justin's spectral extension patch for ac-3? [09:08:23] <superdump> hmm, if it didn't get merged, it probably got overreviewed and left [09:13:39] <jai> stuck in the review queue [09:13:53] <jai> justin didnt get around to posting a new patch [09:14:36] <jai> but i like how superdump phrased it :) [09:17:36] <CIA-92> ffmpeg: diego * r22164 /trunk/libavdevice/bktr.c: [09:17:36] <CIA-92> ffmpeg: Add _NETBSD_SOURCE definition to fix compilation on NetBSD. [09:17:36] <CIA-92> ffmpeg: NetBSD is unlikely to fix their headers and the FATE box passes it [09:17:36] <CIA-92> ffmpeg: as -D_NETBSD_SOURCE on the command line anyway. In this case, it's [09:17:36] <CIA-92> ffmpeg: better to keep the hack well-contained within this file. [09:17:37] <CIA-92> ffmpeg: Closes issue 886. [09:17:38] <CIA-92> ffmpeg: patch by Jorge Acereda, jacereda brainstorm es [09:23:24] <DonDiego> somebody prod justin to pick it up again.. [09:24:05] <superdump> maybe he doesn't have time [09:29:13] <DonDiego> maybe he just needs to get asked :) [09:39:02] <CIA-92> ffmpeg: pross * r22165 /trunk/libavcodec/iff.c: use intended const syntax [09:45:24] <CIA-92> ffmpeg: pross * r22166 /trunk/libavformat/bink.c: Support demuxing of streamed Bink files [09:47:48] <superdump> siretart: do you know who does the packaging for gst-ffmpeg? [09:48:12] <bilboed-pi> superdump, you might wanna specify the distro :) [09:48:32] <superdump> well, siretart does ffmpeg packages for ubuntu/debian [09:48:39] <superdump> and i'd like to know for both :) [09:49:27] <peloverde> packages.{debian.org,ubuntu.com}? [09:50:26] <peloverde> http://packages.debian.org/sid/gstreamer0.10-ffmpeg [09:51:23] <peloverde> Looks like Sebastian Dröge for both [09:51:36] <superdump> mmm [09:51:38] <superdump> slomo [09:51:40] <superdump> :) [09:51:43] <superdump> and sjoerd [09:52:46] <CIA-92> ffmpeg: pross * r22167 /trunk/libavcodec/binkaudio.c: Perform coefficient transformations in Bink Audio DCT decoder (issue1770) [09:53:10] <Dark_Shikari> pross-au: does that fix the audio artifacts? [09:53:48] <pross-au> Dark_Shikari: yep! [09:53:53] <Dark_Shikari> wooohoo [09:54:03] <Dark_Shikari> now we just need kostya to fix the speed bug in bink files [09:54:20] <pross-au> Is that all? [09:54:26] <pross-au> :D [09:54:32] <Dark_Shikari> and the seek issue [09:54:43] <andoma> it would be awesome to get AAC-HE in the 0.6 release [09:54:47] <pross-au> seeking is not practical [09:55:23] <Dark_Shikari> pross-au: I mean that if I click on the video, it crashes mplayer [09:55:29] <pross-au> oh what? [09:55:31] <Dark_Shikari> and of course it's practical [09:55:47] <Dark_Shikari> do it the same way you seek in anything else without an index [09:55:49] <pross-au> there is only one keyframe [09:55:49] <Dark_Shikari> Just Keep Decoding [09:55:51] <Dark_Shikari> And? [09:55:56] <Dark_Shikari> bink decodes quickly [09:56:06] <Dark_Shikari> if I hit forward, I expect it to decode faster than realtime until I get there. [09:56:09] <peloverde> andoma: HE-AAC would be awesome, but I feel like we've had this discussion every day this week. I'm still stalled on the same two vague review points [09:56:37] <pross-au> havent tried bink with mplayer [09:56:52] <andoma> peloverde: right :/ [09:57:06] <pross-au> but if bink seek is crashing, i will have a look at it [09:57:23] <peloverde> The sample rate issue is actually important the otherone is just kind of wishlisty as far as I'm concerned [09:57:45] <astrange> i think you could ignore the filterbank one, it's ok for now in my profiling [09:57:50] <astrange> (not much) [09:58:50] <peloverde> astrange: I agree, but the sample rate thing absolutely needs to play nice with the rest of ffmpeg [09:59:42] <astrange> but i do think you can factor sbr->k[4]][i + ENVELOPE_ADJUSTMENT_OFFSET][0] and phi[0/1][indexsine] out of the loop at the end of sbr_hf_assemble [10:10:04] <peloverde> I'll fix that right now [10:27:27] <pross-au> Dark_Shikari: mplayer does not crash here when i click in the window.. [10:58:29] <CIA-92> ffmpeg: michael * r22168 /trunk/libavcodec/h264.c: Simplify implicit_weight table init. [10:59:07] <elenril> is seeking in bink supposed to work? [11:21:21] <pross-au> elenril: seeking takes you back to frame '0' [11:31:42] <peloverde> astrange: I just overhauled sbr_hf_assemble() [11:55:25] * DonDiego cheers on peloverde [11:55:37] <DonDiego> "works with HTML 5" needs you :9 [11:55:38] <DonDiego> :) [12:07:01] <peloverde> How do we feel about memory vs speed tradeoffs [12:07:50] <peloverde> I can get 11% improvement from HE-AAC but it will cost doubling the synthesis buffers [12:10:13] <superdump> peloverde: well, doubling might be ok if the amount being doubled is not too large [12:11:07] <peloverde> It's a 4K increase per channel [12:13:00] <andoma> 4 Kelvin? [12:13:01] <iive> peloverde: how much memory does that mean in typical use? [12:13:34] <iive> aka 8192 for stereo? [12:13:49] <merbzt> http://i.imgur.com/yMgFT.jpg [12:13:53] <peloverde> 8192 kbytes for stereo [12:14:08] <peloverde> it's per channel actually used, not per max channels [12:14:24] <iive> 8MB... [12:15:05] <peloverde> err 8192 bytes per stereo [12:15:22] <peloverde> didn't mean to double count the 1024 [12:15:37] <peloverde> 8MB for 2048 channels ;) [12:15:55] <iive> that's nothing. not all devices have 8mb free memory, but i bet they could sqeeze 8k from somewhere. [12:16:32] * KotH would struggle to find 8kb of free memory on his devices [12:16:58] <iive> your devices don't have enough memory for the whole aac code, let alone data :P [12:17:14] <peloverde> I wound up replacing a per channel per frame memmove with an occasional memcpy [12:17:24] <peloverde> AAC can be done with much less memory than we do [12:17:45] <peloverde> (see my old aac-lowmem patch) [12:18:02] <merbzt> peloverde: did you look at the opencore aac decoder ? [12:18:07] <KotH> peloverde: can that part be easily isolated? [12:18:13] <merbzt> have they done any neat tricks ? [12:18:22] <KotH> peloverde: ie, would it be feasible to have a compile time switch to choose memory vs cpu? [12:19:01] <peloverde> merbzt: opencore IIRC is just the 3GPP refsoft from coding technologies (now dolby.de) under a different license [12:19:29] <merbzt> ok [12:19:57] <peloverde> KotH: It would be possible but it would add some complications to the code [12:20:04] <merbzt> peloverde: how much faster is the he code compared to faad ? [12:20:10] <KotH> peloverde: ok, then it's not feasible [12:20:13] <peloverde> also most people who care about lowmem also want fixed pont which we don't do... yet [12:20:41] <KotH> is there a use of he-aac for non-vidoe files? [12:20:41] <peloverde> merbzt: we are about 25% faster before this improvement [12:20:58] <peloverde> he-aac is used heavily by streaming music [12:21:15] <peloverde> http://www.shoutcast.com/ [12:21:17] <KotH> offline? [12:21:20] <iive> i thought the he is low quality?! [12:21:32] <KotH> if you have streaming, you've tcp, if you've tcp, you've enough memory for sure [12:21:43] <andoma> lot of tv broadcasting is starting to use aac-he now as well [12:21:56] <peloverde> there are portable players that support HE-AAC [12:22:06] <KotH> the only use case that cares about memory in that range would be portable mp3-players [12:22:08] <wbs> those shoutcast-aac-streams, they're progressive http downloads, right? [12:22:31] <peloverde> the 3GPP refsoft is a good starting point for most users [12:22:56] <merbzt> KotH: ie the rockbox guys [12:23:02] <peloverde> It's really high quality for refsoft, probably because coding was hoping to make up for it in licensing [12:23:04] <KotH> merbzt: exactly [12:23:29] <peloverde> 3GPP refsoft also supports floating point [12:25:29] <peloverde> however this particular speedup/memory tradeoff would be a very simple ifdef [12:27:18] <KotH> hmm... looks like most cpu's used for mp3 players have something in the range of 64k internal ram + some external attached... (but extermal mem might need to be mapped or copied first to be used) [12:29:43] <peloverde> I wish I had 64K when I was doing that stuff [12:30:40] * iive looking for his ancient apple ][e clone [12:30:52] <KotH> peloverde: that stuff? [12:31:57] <peloverde> Vivace Semiconductor VSP-100 and other Improv Systems Crescendo based platforms [12:32:52] <peloverde> the company is defunct now [12:36:53] <peloverde> http://web.archive.org/web/20080513081706/www.vivacesemi.com/technology/tec… [12:37:40] <merbzt> Real Media [12:37:44] <merbzt> cool :) [12:54:26] <thresh> haha, russian "linux-related" websites wrote about ffmpeg 0.5.1 [12:54:39] <thresh> mentioning changes from trunk as changes in 0.5.1 [12:54:43] <thresh> idiots [12:57:05] <merbzt> I think we need a pre written text that "news" sites can take [12:57:16] <merbzt> instead of writing crap [12:59:09] <thresh> yes, this would be awesome indeed [12:59:22] <thresh> however this is already written on a website, lol [13:00:01] <merbzt> I mean for 0.6 [13:00:11] <merbzt> 5.1 is already out [13:00:35] <merbzt> maybe even translate it [13:03:34] <jai> "FFmpeg Press Kit"? ;) [13:03:54] <kierank> lol [13:39:35] <superdump> mru: ping? [13:40:22] <mru> pong [13:43:05] <merbzt> anyone know what baptiste is up to ? [13:49:42] <superdump> mru: i was just wondering if there were any special kernel options needed for oprofile with an armv5l [13:50:05] <superdump> other than profiling, oprofile, have_oprofile and tracepoints [13:50:06] <mru> you need an armv5 with perf counters to begin with [13:50:11] <mru> I don't think there are many [13:50:16] <superdump> oh [13:50:25] <superdump> how can i tell? is it in cpuinfo? [13:50:28] <mru> you can use oprofile in timer mode [13:50:41] <superdump> yes, i have /dev/oprofile/cpu_type timer [13:50:44] <mru> less accurate but works everywhere [13:50:48] <superdump> ok [13:51:11] <superdump> then i guess that may have to do [13:51:46] <mru> you could also do profiling on an armv7 with caches, dual-issue, and branch pred turned off :-) [13:52:08] <mru> L2 caches [13:53:18] <superdump> :) [14:13:55] <jez9999> Anyone know why, in rtpproto.c, ffmpeg calls select(), but passes NULL for its timeout value, so it ends up blocking indefinitely? [14:16:50] <wbs> jez9999: no reason that I can see, I guess it should wait in shorter periods and at least check url_interrupt_cb(), like other uses of select [14:16:55] <wbs> patch welcome, I guess :-) [14:17:34] <mru> guys, please read http://hardwarebug.org/2010/03/03/ogg-objections/ [14:18:59] <bilboed-pi> comparing ogg (a streaming format by design) and iso (not a streaming format) is a bit of a fallacy [14:19:03] <bilboed-pi> (in the overhead section) [14:19:47] <kierank> add that the name "granule" sound stupid [14:19:48] <mru> ogg claims to be a general-purpose format [14:19:59] <bilboed-pi> lol [14:20:31] <bilboed-pi> indexes have been added to ogg a month back [14:20:36] <bilboed-pi> (yes, about friggin time) [14:21:38] <mru> what? [14:21:41] <mru> where is this? [14:21:45] <mru> I read the spec last night [14:22:25] <jez9999> BBB____: hey, i've noticed that rtpproto.c's rtp_read() function calls select(), but passes NULL for the timeout. [14:22:32] <jez9999> this means that it blocks indefinitely [14:22:36] <jez9999> presumably this is wrong [14:22:41] <bilboed-pi> mru, let me check [14:22:55] <BBB> jez9999: that's probably wrong, yes [14:23:08] <BBB> it should select() like the udp/tcp functions [14:23:26] <merbzt> http://www.inmethod.com/air-video/licenses.html [14:24:15] <jez9999> BBB: any reason the time value is set using microsecs and not millisecs?: tv.tv_usec = 100 * 1000; [14:24:28] <jez9999> could be tv.tv_sec = 100 [14:24:36] <mru> merbzt: are they doing anything wrong? [14:24:40] <wbs> jez9999: that's seconds, not milliseconds [14:24:46] <jez9999> ah [14:24:46] <jez9999> ok [14:25:08] <BBB> microseconds [14:25:09] <jez9999> well isn't a 10th of a second too short? [14:25:10] <BBB> so 0.1 sec [14:25:11] <bilboed-pi> mru, my bad, still a draft : http://wiki.xiph.org/Ogg_Index [14:25:16] <BBB> jez9999: no, because it loops [14:25:17] <jez9999> it's going to return quite often with no new data [14:25:22] <jez9999> oh i see [14:25:40] <BBB> jez9999: the timeout is so we cancel out of the loop through url_interrupt_cb [14:25:43] <mru> ewww, what an ugly wiki [14:25:46] <jez9999> i wonder whether xuggler has any way to access url_interrupt_cb. [14:25:46] <BBB> otherwise it loops [14:25:59] <bilboed-pi> mru, and this blog has a bit more details : http://pearce.org.nz/blog/ [14:26:04] <bilboed-pi> anyway, going home [14:26:25] * bilboed-pi is gonna have to add support for avcodec_align_dimensions2 in gst-ffmpeg :( [14:27:25] <merbzt> mru: they have some patches in there [14:27:32] <kierank> lol at the 32-bit frame counter [14:28:08] <merbzt> mru: might be worth to check for [14:29:11] <wbs> BBB: btw, had time to check this one? http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/2010-February/083999.html [14:29:15] <wbs> it should be quite straight forward [14:29:29] <BBB> I missed that one [14:29:33] <BBB> I wonder why I did [14:29:33] <BBB> anyway [14:29:41] <BBB> have to go to a meeting [14:29:45] <BBB> will be back and will check [14:29:49] <BBB> +/- 2 hrs [14:29:54] <wbs> ok, no hurry :-) [14:34:37] <iive> mru: in the first section, mapping thing sounds too complicated, add general example like "you cannot do stream copy of video from ogg to mkv, without knowing and supporting the exact codec and its mapping, even if you don't change even 1 bit of the data itself" [14:35:01] <mru> mapping _is_ too complicated [14:38:44] <mru> iive: also, I don't think stream copy is _that_ important [14:39:13] <iive> it is just example that is easy to understand. [14:39:29] <mru> I don't want to use contrived examples [14:41:04] <iive> well, it's your blog. but people would have hard time to understand why different mappings are such a problem. [14:42:33] <CIA-92> ffmpeg: michael * r22169 /trunk/libavcodec/ (h264_refs.c h264.c h264.h): Merge weight & offset tables, 15 cpu cycles faster. [14:42:42] <mru> would they understand why stream copy is important? [14:42:45] <mru> I don't... [14:43:07] <mru> people just want to play their films [14:46:44] <iive> well, after reading how horrible is ogg, they would like to convert their movies into something playbale... [14:46:58] <mru> I doubt they actually have any ogg files [14:47:07] <mru> when was the last time you saw one in the wild? [14:47:19] <kierank> on wikipedia :/ [14:51:39] <iive> mru: there was a time when a lot of anime groups supported the "new kid" ogg, at least for the ability to embed subtitles in it. So yeh... Fortunately they've long moved to mkv and/or mp4 [14:52:24] <iive> anyway, the copy is just simplified example of the common input processing system of every media player. [14:52:37] <iive> btw, does ogg have a way to signal keyframes? [14:52:46] <mru> no [14:52:53] <mru> codec mappings can define one [14:53:46] <iive> well, your explanation of seeking is missing this point completely. [14:54:12] <iive> it means that you must use codec parser to be able to seek... [14:57:32] <mru> ogg seeking sucks even _without_ that point [14:58:52] <DonDiego> nonetheless a point worth making.. [14:59:09] <DonDiego> something i never understood: [14:59:19] <DonDiego> vp3 worked fine in various containers [14:59:33] <DonDiego> there was no need to create a new container to begin with [14:59:39] <mru> ogg is much older [14:59:54] <mru> it was created for vorbis and vorbis only [15:00:03] <mru> which is indeed a bitch to store in other containers [15:00:11] <DonDiego> still theora could be designed to work in generic containers [15:00:12] <mru> because they botched the design [15:00:18] <mru> as could vorbis [15:00:32] <mru> but there's a lot of NIH over at xiph [15:04:01] <KotH> there is lots of NIH all over OSS ;) [15:04:41] <iive> by botched you mean, they intentionally made it dependent on ogg. [15:05:06] <mru> yes [15:08:31] <iive> the whole point here is that each aspect of ogg sucking multiplies the other aspects, making ogg suck exponentially. [15:09:05] <mru> I want to focus on the points monty hasn't dismissed already [15:09:14] <mru> but I'm adding a note to the seeking section [15:11:08] <jez9999> BBB: see issue 1790 - i'm writing a patch now [15:11:29] <DonDiego> mru: this should not be just for monty [15:11:45] <DonDiego> monty can answer the points if he wants to [15:11:56] <DonDiego> but they should be raised for the general public nonetheless [15:13:08] * KotH prints mru's blog and distributes it on the street [15:13:33] <mru> KotH: hold your horses, it's still in beta [15:17:33] * KotH holds his ponnies [15:24:11] <CIA-92> ffmpeg: gb * r22170 /trunk/libavcodec/vaapi_h264.c: [15:24:11] <CIA-92> ffmpeg: Cope with rev 22169 change: [15:24:11] <CIA-92> ffmpeg: Merge weight & offset tables. [16:14:14] <DonDiego> "In a large file with variable bitrate, 50 seeks might be required to find the correct position." [16:14:27] <DonDiego> add some numbers to this [16:14:38] <DonDiego> "large" and "variable" are quite vague [16:15:21] <DonDiego> "one should bear in mind that the Ogg format designed at a time" [16:15:23] <DonDiego> --> [16:15:29] <DonDiego> "one should bear in mind that the Ogg format WAS designed at a time" [16:16:00] * mru makes note not to write stuff after 5am in future [16:48:33] <CIA-92> ffmpeg: michael * r22171 /trunk/libavcodec/h264.h: move svq3 specific fields to the end of the context [16:50:34] <Anarhist> what's the credit policy of FFMpeg, if i submit the patch which i believe to be non-trivial (ie it took me a better part of the day to debug and get it to the point where it's something i'm proud of) can i add myself to the CREDITS within that same patch. also what are the chances of somebody saying "i could have done that in 5 minutes, so you are lame" [16:57:39] <BBB> Anarhist: CREDIT requires a non-trivial feature addition, I think [16:58:24] <BBB> Anarhist: but you could always try... [16:58:29] <Anarhist> ok, i probably won't give anything to myself probably, looking at the credits file, it seems that it's pretty small [16:59:03] <Anarhist> or maybe try, and if i get flamed, it's only internet [16:59:47] <mru> a day's work is not usually enough for a mention in CREDITS [17:00:34] <Anarhist> fair enough, it differs from project to project, so that's why i've asked [17:04:06] <mru> if you send a patch your name will be mentioned in the commit message [17:06:44] <DonDiego> "There is, however, a significant different there" [17:06:46] <DonDiego> ---> [17:06:51] <DonDiego> "There is, however, a significant differenCE there" [17:08:18] <Anarhist> well, that's cool i'm not really out for fame, i just wanted to know how it's done here [17:08:52] <BBB> most people in the CREDITS file have SVN access [17:09:04] <Anarhist> lol, i'm sorry that is funny [17:09:12] <BBB> you get SVN access after being involved and supplying multiple patches for a longer period of time [17:09:22] <BBB> it's vague :) [17:12:19] <mru> DonDiego: reload [17:15:47] <mru> there's some discussion at http://news.ycombinator.com/item?id=1164161 [17:16:42] <DonDiego> already? [17:16:52] * kierank posted it [17:16:59] <DonDiego> please mention what the standard terms they changed are [17:17:05] <DonDiego> maybe in a quick table [17:25:23] <CIA-92> ffmpeg: vitor * r22172 /trunk/libavcodec/ (vp6.c vp56.c): Plug some memory leaks in the VP6 decoder [17:26:51] <CIA-92> ffmpeg: vitor * r22173 /trunk/libavformat/nsvdec.c: [17:26:52] <CIA-92> ffmpeg: Plug memory leak in NSV demuxer. [17:26:52] <CIA-92> ffmpeg: Patch by Jai Menon. [17:27:09] <DonDiego> all in all the tone of the post could be a tad more neutral [17:27:49] <mru> it's hard... [17:29:59] <DonDiego> i know [17:30:14] <DonDiego> your timestamp article is much more neutral though [17:32:18] <CIA-92> ffmpeg: vitor * r22174 /trunk/ (8 files in 3 dirs): Plug memory leak in NUT muxer and demuxer [17:33:19] <iive> mru: actually i think you should add another chapter for the symbiotic link between ogg, vorbis and theora. A lot of people confuse ogg and vorbis. [17:36:45] <DonDiego> mru: i think the message of your post would benefit from being toned down a bit [17:37:02] <DonDiego> you can see the reaction on ycombinator.org already.. [17:37:16] <mru> any part in particular? [17:37:22] <DonDiego> let me see.. [17:37:49] <DonDiego> oh, and yes, a few quick introductory words about ogg vs. vorbis vs. theora vs. whatever might help [17:37:53] <mru> I guess I could drop the bit about the romans... [17:38:10] <DonDiego> same as you did in the timestamp article [17:39:23] <DonDiego> "True generality is evidently not a quality favoured by Xiph." [17:39:27] <DonDiego> could be misread.. [17:39:45] <mru> I could drop that [17:40:17] <DonDiego> the roman numeral comparison is actually good, it helps explain [17:40:31] <DonDiego> but the snide remark after that does not.. [17:41:03] <mru> I enjoyed writing that part... [17:41:12] <iive> btw, this thing about the romans, it's used by mkv to store the pack the 3 hears into extradata, and i think that it comes from some rfc, not sure if it was tcp or something. [17:41:46] <mru> I've never seen it attributed to anything but xiph [17:41:47] <DonDiego> i believe you, it is funny :) [17:41:50] <DonDiego> "True generality is evidently not a quality favoured by Xiph." [17:41:56] <DonDiego> say something about ogg there [17:42:08] <DonDiego> don't put words into the xiph people's mouths [17:42:18] <mru> xiph designed ogg [17:42:36] <DonDiego> "The Ogg format is clearly not a good choice for a low-latency application." [17:42:46] <DonDiego> same statement now directed at ogg instead of xiph [17:42:51] <DonDiego> s/same/comparable/ [17:44:20] <mru> so I'll remove the last 2 sentences in the roman paragraph? [17:45:20] <DonDiego> for example, yes [17:45:42] <DonDiego> it's nice that you gave a number for the amount of seeks now [17:46:00] <DonDiego> maybe you can add a second one for a file below a gig [17:46:18] <DonDiego> 10GB is a large file and not necessarily common depending on application [17:46:26] <janneg> mru: at least the SEI in h264 uses the same format: size=0; [17:46:34] <janneg> do{ [17:46:49] <janneg> size+= show_bits(&s->gb, 8); }while(get_bits(&s->gb, 8) == 255); [17:47:29] <mru> presumably that field is unlikely to ever need more than 2 bytes [17:47:59] <DonDiego> the last paragraph is somewhat flamish as well [17:47:59] <mru> in ogg a 20-byte field is _normal_ [17:48:00] <janneg> I would think so [17:48:34] <mru> DonDiego: which last paragraph? [17:48:46] <DonDiego> final words [17:48:47] <janneg> just to point out that the encoding is used elsewhere [17:48:51] <mru> about patents? [17:48:54] <mru> flamish? [17:49:03] <mru> you've become sensitive... [17:49:56] <janneg> it makes sense if the length is usually below 255 but could be longer in rare cases [17:50:14] <mru> yes [17:50:29] <mru> you have to look at the statistical distribution to choose a good encoding [17:50:53] <mru> if 5-10k is a normal value this is not a good encoding [17:59:51] <janneg> not to speak about raw yuv data, 16k just to encode the the length of a single 1080p frame [18:00:59] <mru> let's not go there [18:04:34] <iive> argh, can't find the rfc thing [18:04:38] <DonDiego> mru: no, not necessarily the patents, more like "certain organizations", "ferocity", "campaigners", etc.. [18:04:53] <mru> campaigner is bad now? [18:07:27] <DonDiego> not in itself [18:07:42] <DonDiego> but you're loading all the terms up with a lot of adjectives [18:07:43] <mru> how would you describe them? [18:08:17] <DonDiego> pick out some of what monty said [18:08:23] <DonDiego> and present it more neutrally [18:08:38] <DonDiego> then pick it apart based on technical merit [18:09:19] <DonDiego> but i guess it's not that important [18:09:20] <Compn> what url are you guys talking about? the hacker news entry ? [18:09:31] <DonDiego> i'm off home now [18:09:44] <DonDiego> i fixed the autobuilder at work enough for today :) [18:10:04] <mru> DonDiego: I thought a picking-apart was exactly what this was [18:10:37] <mru> Compn: he probably meant http://blog.gingertech.net/2010/02/20/googles-challenges-of-freeing-vp8/ [18:10:42] <mru> look for comments from monty [18:12:51] <DonDiego> it is a picking apart [18:13:06] <DonDiego> but at the end you only quickly touch on common replies [18:13:16] <DonDiego> in much less detail than the rest of the post [18:13:28] <DonDiego> it might be worth answering some of monty's points in more detail [18:13:40] <DonDiego> Compn: http://hardwarebug.org/2010/03/03/ogg-objections/ [18:14:28] <mru> DonDiego: I was trying to keep the amount of debating low [18:14:32] <Compn> ah i was going to check mru's blog, but i got distracted. trying to do 400 things at once is one or two too many [18:14:36] <DonDiego> ok, going home now, cu tommorrow [18:23:00] <Dark_Shikari> mru: why the hell didn't you mention matroska? [18:23:01] <Dark_Shikari> seriously [18:23:15] <Dark_Shikari> it is what we _NEED_ to do [18:23:17] <Dark_Shikari> read http://news.ycombinator.com/item?id=1164694 , no [18:23:18] <Dark_Shikari> *now [18:23:20] <Dark_Shikari> and go mention matroska [18:24:32] <elmojo> janneg: let me know if you want more help with BBB rendering - I got a C2Q with 4GB (8GB in a few days hopefully) [18:25:25] <ohsix> heh, doesn't that allege conspiracy when there is a valid reason for it existing (the ecosystem angle) [18:26:13] <Dark_Shikari> What conspiracy? [18:26:16] <Dark_Shikari> that isn't a conspiracy [18:26:31] <ohsix> whereas their realm of purview and interest is their own ecosystem, they aren't interested in things outside of it for their intent and purpose [18:26:39] <Dark_Shikari> the GPL existing is not a conspiracy [18:26:52] <Dark_Shikari> no seriously, I argued with an ogg advocate yesterday [18:26:56] <Dark_Shikari> he made EXACTLY THIS ARGUMENT [18:27:01] <Dark_Shikari> that Ogg is better because it doesn't let you use non-free formats [18:27:06] <Dark_Shikari> and that's why Ogg is more free [18:27:12] <ohsix> whom? is it public? [18:27:50] <ohsix> i'd have to take it under consideration to not make most of whats under the bullet points out to conspiracy [18:27:54] <Dark_Shikari> it was a debate in #ffmpeg [18:27:57] <Dark_Shikari> it's not a conspiracy! [18:28:02] <Dark_Shikari> it's quite open and obvious [18:28:12] <ohsix> heh [18:28:12] <Dark_Shikari> xiph obviously does not allow h264 in ogg because they don't want people putting h264 in ogg [18:28:15] <Dark_Shikari> what's conspiratorial about that? [18:28:34] <ohsix> is #ffmpeg also posted to michaels irc log list? [18:29:12] <Dark_Shikari> don't know [18:29:14] <Dark_Shikari> probably not [18:29:41] <ohsix> k [18:30:48] <ohsix> its just my opinion having not witnessed this conversation that it being omitted and being used as a pseudo proof is nonconvincing, i cant falsify your theory considering the entire statement as made [18:31:19] <Dark_Shikari> wait [18:31:25] <Dark_Shikari> so you are claiming there is not one person in the world who believes what I stated? [18:31:54] <ohsix> i'm not talking about beliefs [18:32:49] <mru> Dark_Shikari: do you have a log of that conversation? [18:32:52] <ohsix> i'm talking about the statement and why it looks conspiratorial to me, if i ever read the conversation you essentially make reference to, i may have a different opinion; as might any reader of the statement [18:34:54] <twnqx> i do have. [18:34:58] <twnqx> the log, that is [18:35:05] <Dark_Shikari> mru: can you just stuff matroska in that damn post? =p [18:35:26] <mru> Dark_Shikari: why? this is about ogg [18:35:38] <mru> and matroska overhead at least isn't all that stellar [18:36:03] <Dark_Shikari> But you should give an alternative [18:36:10] <Dark_Shikari> people will ignore your whining unless you say "Thus you should use...X" [18:36:18] <mru> I HATE PEOPLE [18:36:24] <Dark_Shikari> Like in my post you are one of the people ignoring the fact that Matroska exists [18:36:27] <Dark_Shikari> and just debating about Ogg [18:36:33] <Dark_Shikari> If you want to smack the Ogg people down, give them another option [18:36:37] <mru> why am I not allowed to recognise that something stinks without offering a ready solution? [18:36:47] <Dark_Shikari> You are, but you need to think practically here. [18:36:56] <Dark_Shikari> people will disregard your post by saying "ogg is the best we have" [18:36:59] <Dark_Shikari> when that is OBVIOUSLY A LIE. [18:37:04] <Dark_Shikari> (referring to patent-free formats) [18:37:17] <Dark_Shikari> in order to deal with that, you have to give an alternative. [18:37:45] <mru> ok, I'll add a section on alternatives [18:37:56] <mru> I'll think about it while I cook dinner [18:38:40] <twnqx> uh... pastebin only outputted / [18:38:42] <twnqx> :( [18:40:55] <twnqx> ohsix / mru: http://pastebin.org/100661 if you're really THAT bored [18:41:07] <mru> Dark_Shikari: the matroska spec is a bit messy... calculating the overhead will take some time [18:41:28] <ohsix> i dont think an alternative needs mentioning for objective statements, you muddle & bring in possible attacks from detractors for what you advocate; muddling your original objective, maybe have a follow up post on why matroska sucks too, then ref the earlier discussion; people can make their own judgement [18:41:54] <twnqx> overhead + gain through h.264 vs. less overhead + loss through theora.. hmmm [18:42:01] <ohsix> twnqx: thanks [18:42:19] <mru> h264 in ogg is trivial if you bother [18:42:49] <twnqx> well, i don't really care, i'm converting ogg on sight [18:42:50] <CIA-92> ffmpeg: rbultje * r22175 /trunk/ffserver.c: [18:42:50] <CIA-92> ffmpeg: Update to work with chunked encoding HTTP streams (as served by FFmpeg since [18:42:50] <CIA-92> ffmpeg: a few months now). Fixes issue 1738. [18:42:58] <ohsix> at the very least if you say why everything sucks, someone can pick something that sucks the least and be quite confident thats the best they can currently manage :P [18:43:19] <twnqx> mru: with seek index? :P [18:43:45] <BBB> I hate ffserver [18:44:23] <twnqx> my main reason to dislike ogg is mplayer's fail at playing it, e.g. automatically selecting the right audio stream by language [18:44:29] <BBB> anyway, another issue fixed... [18:44:38] <twnqx> oh, and failing to automatically enable subtitles etc [18:44:47] <ohsix> fwiw, right off in that #ffmpeg discussion, when i was using ffmpeg to do mkv stuff, it wouldn't seek either; i resorted to elementary streams and using mkvmerge [18:45:03] <twnqx> just mkvmerge the .mkv [18:45:04] <ohsix> i was no doubt doing something wrong [18:45:07] <twnqx> easier. [18:45:09] <twnqx> no [18:45:44] <mru> twnqx: well, blame ogg for not having a standard language tag [18:45:53] * twnqx blames ogg [18:45:58] <janneg> elmojo: sure, read http://www.jannau.net/bbb_videowall/ and ask if you have questions [18:46:12] <janneg> mru: which job did you choose? [18:46:25] <elmojo> janneg: trying to download the production files but no one is seeding it right now [18:47:26] <janneg> elmojo: I'm seeding, the piratebay tracker is obviously down, so you need to have dht enabled [18:48:28] <elmojo> dht enabled here... let me try another client [18:48:39] <Dark_Shikari> mru: I don't mean a comparison [18:48:43] <Dark_Shikari> I just mean a note about it as an alternative [18:50:27] <ohsix> fwiw, i asked the fellow to refine what he meant about ogg/mkv & gpl/bsd, first thing he said 10:48 <Anarhist> well, i'm reconsidering my ogg position at the moment [18:53:36] <Dark_Shikari> he did [18:53:38] <Dark_Shikari> I convinced him of mkv ;) [18:54:09] <Dark_Shikari> all I said was that such a thing was the argument he made at one point [18:54:18] <Dark_Shikari> which means there is at least one person who believes or believed such a thing. [18:54:26] <Dark_Shikari> meaning it's not a strawman. [18:54:45] <astrange> mkv mappings aren't so generic either [18:55:05] <Dark_Shikari> It's still more flexible though [18:55:10] <astrange> they hadn't heard of "generic" when they started it, so the codecs they had heard of all get weird special ones [18:55:11] <Dark_Shikari> not generic, sure, but at least they exist. [18:55:21] <Dark_Shikari> Would be better if they were _actually_ generic. [18:55:35] <astrange> (there's an old slashdot comment by christoph whoever it was saying that mov "doesn't support MPEG-2") [18:55:47] <ohsix> heh dont make assumptions, i dont think that conversation convinced anyone of anything; he went on to mention that you cant use it as a general container was something to look further into [18:56:04] <Dark_Shikari> obviously, I convinced him to look further into it ;) [18:56:46] <ohsix> its something his cursory understanding just missed; it wasn't exactly well argued huhuhu [19:05:15] <ohsix> i think its important that the guy was willing to defend his opinion even if it was poorly stated as "fact", but he is rationally assessing the fact that you cant use it as a general container now [19:24:20] <ohsix> heres the conversation i had with the guy if anyone is further interested http://pastebin.org/100673 [19:25:15] <Dark_Shikari> http://www.lyris-lite.net/2010/girl_hornet.png blu-ray quality folks [19:31:09] <andoma> ?? [19:31:55] <Dark_Shikari> just a screenshot from a blu-ray disk. [19:32:02] <Dark_Shikari> courtesy of "bad encoder land" [19:32:37] <CIA-92> ffmpeg: fenrir * r22176 /trunk/libavcodec/tta.c: Fixed overreads in TTA decoder with corrupted bistreams. [19:32:37] <CIA-92> ffmpeg: michael * r22177 /trunk/libavcodec/h264.h: Note about luma/chroma_weight tables and their datatype. [19:33:14] <CIA-92> ffmpeg: michael * r22178 /trunk/libavcodec/h264.c: cosmetic addition of {} [19:45:15] <CIA-92> ffmpeg: michael * r22179 /trunk/libavcodec/h264.h: remove unused left_border field from context. [19:48:46] <Yuvi> mru: could you elaborate on the advantages of splitting packets in mpeg-ts? (and whether they also apply to ps?) [19:51:11] <Yuvi> btw, #theora was funny, before your post was posted they were telling someone to use chained ogg instead of actually adding chapters to ogg [19:51:40] <mru> rotfl [19:52:02] <mru> chained ogg streams have no inter-relation whatsoever [19:53:40] <Yuvi> apparently giving each chained segment a different title will make it look like it has chapters in firefox [19:54:46] <elenril> chained ogg is something like segment linking in matroska? [19:55:03] <CIA-92> ffmpeg: fenrir * r22180 /trunk/libavcodec/dxva2_h264.c: Fixed DXVA2 H264 hwaccel compilation. [19:55:07] <Yuvi> except worse, since you don't know about it until you hit it in the middle of the file [19:55:15] <elenril> o_0 [19:55:33] <Dark_Shikari> add that to the post then. [19:55:56] <elenril> does ffmpeg support that? [19:56:40] <Yuvi> no, but in theory an application using lavf could if it watched for new streams and assumed chained ogg semantics for what to do with them [19:57:46] <elenril> btw did anyone except baptiste and michael see the playlist patch from gsoc? [19:58:44] <Yuvi> Dark_Shikari: 3rd bullet point in complexity [19:59:25] <Dark_Shikari> ah k. [19:59:37] <Yuvi> also, correct seeking is a lot more annoying than mru made it out to be [20:03:33] <Yuvi> and the broken continuations appears to be a bug in libogg that *still* has not been fixed, for at least 3 years [20:03:54] <mru> that's in *libogg*? [20:04:03] <ohsix> is there a bug # for that somewhere? [20:04:44] <mru> ouch, I've been slashdotted [20:05:13] <mru> webserver temporarily blocked until I get a ratelimit in place [20:05:45] <Dark_Shikari> er, you don't have a cache? [20:05:52] <Dark_Shikari> mru: start adding more points, quickly ;) [20:06:01] <mru> Dark_Shikari: adsl isn't coping [20:06:15] <Dark_Shikari> mru: you host it on an ADSL?!>!!? [20:06:17] <ohsix> 302 it to the .nyud.net url [20:06:17] <mru> do you have a caching proxy I could borrow? [20:06:35] <Dark_Shikari> I have a dreamhost account [20:06:44] <Dark_Shikari> if you want I can host a snapshot mirror or something [20:08:17] <mru> I usually get no more than 200 hits per day [20:08:24] <Dark_Shikari> as I said [20:08:28] <Dark_Shikari> give me a snapshot, and I will mirror it [20:08:30] <Dark_Shikari> and you can post a redirect [20:08:46] <Dark_Shikari> give me a tar or something [20:08:49] <Dark_Shikari> I can give you doom10.org/hardwarebug [20:09:18] <Dark_Shikari> hell if you want, give me the whole site, it really doesn't matter [20:09:25] <ohsix> http://www.coralcdn.org/ [20:09:34] <Dark_Shikari> coral is really slow [20:10:01] <Dark_Shikari> so mru, add the comment about matroska and then give me a snapshot [20:10:03] <Dark_Shikari> and I'll post it [20:10:38] <ohsix> its slow if it cant reach the origin; which is why you need to do it ASAP :< or manually prime it at the source [20:12:41] <ohsix> but he's going to have a hard time doing anything if his dsl is being overwhelmed [20:12:55] <Dark_Shikari> just give me a tarball, as I said. [20:13:44] <mru> as from wget -r ? [20:15:46] <ohsix> once its "dead" the article will probably be amended with the nyud bits anyways [20:16:21] <Dark_Shikari> mru: whatever you want [20:16:29] <Dark_Shikari> stuff it on mediafire, I'll mirror it, you set up a redirect [20:16:31] <Dark_Shikari> I don't care how you do it [20:16:40] <Dark_Shikari> just do it fast. [20:16:50] <mru> what's the rush? [20:17:43] <Dark_Shikari> you're on slashdot [20:17:50] <Dark_Shikari> it's better to get mirorred before you fall off the first page [20:18:01] <ohsix> (firehose, not /. proper) [20:18:12] <astrange> it's on my front page [20:18:20] <mru> http://news.slashdot.org/story/10/03/03/1913246/Technical-Objections-To-the… [20:18:29] <ohsix> fancy [20:18:52] <Dark_Shikari> Ah ok [20:22:06] <Vitor1001> mru is slashdotted... [20:23:11] <ohsix> Yuvi: is there a bug # for the continuation thing? [20:23:23] <Yuvi> ohsix: I don't think so [20:23:45] <ohsix> hm, how come it wasn't looked into 3 years ago [20:23:47] <andoma> Connecting to hardwarebug.org... [20:24:01] <andoma> wellwell [20:24:33] <mru> I had to block it while I get a mirror up [20:24:38] <mru> sorry [20:24:49] <Yuvi> it's admittedly hard to isolate (I haven't created such a file), since you need a packet whose size is modulo 255 and in the stream happens to end on a page [20:25:09] <andoma> mru: :) [20:25:33] <ohsix> if they knew they'd probably have fixed it :P or at least told whoever reported it to piss off [20:25:40] <Vitor1001> BTW, congrats mru for getting our point across... [20:27:23] <Yuvi> I think we told them when it was first reported and were told it was fixed (since it was produced with old software), then j managed to create another such file with fully updated libs [20:28:30] <ohsix> is that file available? [20:32:08] <iive> mru: found out why streamcopy is so important, it's actually from Dark_Shikari's blog. streamers and muxers actually do stream copy. [20:33:11] <Yuvi> ohsix: http://v2v.cc/~j/samples/breaking_ffmpeg.ogv is the newer one [20:35:37] <ohsix> heh those are some alien looking artifacts [20:35:54] <ohsix> could this be used to raise a bug with? i'm not familiar with what teh actual problem is [20:37:50] <CIA-92> ffmpeg: michael * r22181 /trunk/libavcodec/h264.h: [20:37:50] <CIA-92> ffmpeg: Move all context fields that are not used in the mb and block layers [20:37:50] <CIA-92> ffmpeg: to the end of the structure. [20:37:50] <CIA-92> ffmpeg: 4 cpu cycles faster in 3k cpu cycles [20:38:23] <Yuvi> the problem is that libogg sometimes will not set the continuation flag if a all of a packet's data is completed on the prior page, but it decided to put the terminal 0 segment on the next page [20:38:33] <twnqx> wow, michael really reads the details in the chat [20:38:48] <elmojo> janneg: should have the production files late tonight - you can send me the job you'd like for me to start first or I'll pick one [20:38:59] <Yuvi> so having such a file doesn't help for debugging except proving it still happens [20:39:10] <ohsix> hm [20:40:13] <ohsix> so it generates broken bitstreams? [20:40:34] <Yuvi> yes, which it happens to also accept without complaint [20:41:31] <Yuvi> it's also really easy to generate invalid bitstreams with libogg if you don't explicitly flush after the first header packet and also before any data packets [20:41:37] <Yuvi> which happens a lot [20:42:34] <Yuvi> and you won't know they're invalid because libogg doesn't complain in playing them [20:42:40] <ohsix> what are the practical implications if libogg also accepts these broken files? is what its doing out of spec or something? seems that if you could produce a bitstream thats repeatable from libogg then it could be looked at [20:43:30] <Yuvi> means that other ogg demuxers also have to handle these files, but don't know it because it's not in the spec [20:43:51] <Yuvi> sorta like how wine has to emulate windows bugs [20:44:16] <ohsix> hmm, so a fix could be just turning unmentioned behaviour into something documented, and leaving this 3 year thing where it is [20:44:29] <Yuvi> no [20:44:58] <Yuvi> well maybe, if you say "ignore the continued flag, it contains nothing useful" [20:45:25] <Yuvi> which would mean that in seeking, you can't emit the first packet you complete [20:45:32] <Yuvi> because you don't know if it's continued from former pages [20:46:16] <ohsix> oggz validate throws an error up for the file, dunno if its related, sec [20:46:45] <ohsix> http://pastebin.org/100712 [20:47:16] <ohsix> "terminal header page" sounds interesting though [20:47:27] <Yuvi> the second is the broken continuations, the first is the header stuff I was talking about I think [20:47:56] <Yuvi> thought ffmpeg2theora fixed that a while ago though [20:48:34] <ohsix> so the file exists thats broken when it was encoded, i'm wondering how to get libogg to produce the broken stream as is, now; so it can be fixed [20:49:38] <ohsix> or wait, oggz can chop/edit this file, if its broken after it copies it to another stream it could still be in there? (assuming it makes a full slog through the framing) [20:49:58] <Yuvi> oggz doesn't use libogg iirc [20:50:22] <ohsix> ahh [20:51:17] <ohsix> maybe they could promote the part of oggz that checks for that error to libogg for a while and see if reports come in of it happening, they could put a big fat THIS IS WRONG, POST BUG PLZ type message in there [20:52:47] <ohsix> ogginfo says its broken too, but in a different way, gap in sequence numbers "got x when expecting y" where ix is 343 and 34, and y is 2 in both cases [20:53:31] <ohsix> at the very least they can lint any file and fix anything thats evident as it happens in the future, if its reported [20:54:46] <ohsix> theres something about oggz being better or something than libogg in "oggz" the commands documentation [20:55:27] <ohsix> apparently it takes off most of the "shoot yourself in the foot" sharp corners that were in libogg [21:01:46] <CIA-92> ffmpeg: mstorsjo * r22182 /trunk/libavformat/rtpdec_h264.c: [21:01:46] <CIA-92> ffmpeg: Properly pad H.264 extradata when taken from fmtp SDP attributes [21:01:46] <CIA-92> ffmpeg: This fixes some valgrind warnings. [21:03:25] <mru> blog back up of sorts [21:03:58] <mru> I put a static mirror on ffmpeg.org and ratelimit connections locally [21:04:06] <mru> seems to stay afloat like that [21:11:04] <CIA-92> ffmpeg: michael * r22183 /trunk/libavcodec/ (h264_refs.c h264.c h264.h): [21:11:04] <CIA-92> ffmpeg: Reorder indexes in weight tables. [21:11:04] <CIA-92> ffmpeg: 5 cpu cycles faster. [21:15:39] * Vitor1001 can not understand why his patch (http://ffmpeg.pastebin.ca/1821836) does not fix (wrongly) issue 956 :( [21:28:46] <BBB> Vitor1001: can you make wma1/2dec output float? [21:29:04] <BBB> there's a issue tracker entry for that [21:29:11] <BBB> internals are float anyway [21:47:33] <CIA-92> ffmpeg: aurel * r22184 /trunk/libavformat/matroskadec.c: [21:47:33] <CIA-92> ffmpeg: matroskadec: timestamps are dts and not pts in ms vfw compatibility mode [21:47:33] <CIA-92> ffmpeg: original patch by elupus _at_ ecce _dot_ se [21:50:19] <CIA-92> ffmpeg: aurel * r22185 /trunk/libavformat/matroskadec.c: matroskadec: cosmetic indentation [21:52:33] <Vitor1001> BBB: I don't know if michael will be ok with making it slower... [21:52:49] <Vitor1001> Also I'm a little out of time :p [21:52:53] <BBB> oh ok [22:04:10] <BBB> Vitor1001: you're a math genius right? [22:04:27] <janneg> elmojo: pick any [22:04:30] <BBB> Vitor1001: in the first table on this page: http://projects.scipy.org/scipy/ticket/738, what is the number 0.38461538? [22:13:41] <drv> lol, googling for that number brings up http://blog.xkcd.com/2009/09/02/urinal-protocol-vulnerability/ [22:16:39] <drv> it's just 5/13 [22:18:14] <thresh> nicely done, xkcd [22:19:45] <mru> so guys, how can we take advantage of the slashdotting? [22:20:29] <Dark_Shikari> promote matroska [22:20:32] <superdump> donations? [22:20:34] <Dark_Shikari> remind people on slashdot that it's free [22:21:29] * mru should have stuck google ads on the blog :-) [22:21:42] <Dark_Shikari> doesn't make anything with /. [22:22:00] <Yuvi> I really don't get how xiph people think that codec-dependant timestamps aren't retarded [22:22:35] <Dark_Shikari> it allows them to control what formats people put in ogg [22:22:38] <Dark_Shikari> for them, it's awesome [22:23:24] <iive> Yuvi: it is not politically correct to call them retarded, you must call them "different" [22:23:28] <Dark_Shikari> no no [22:23:31] <Dark_Shikari> the correct term is palin-american [22:23:45] <Yuvi> heh [22:24:03] <Yuvi> I need to draw a diagram of what's frustrating me with seeking [22:25:09] <Yuvi> since *no other container* has this problem, since no other container defines timestamps in a completely codec-independant way, and allows packets to be split across pages, and allows multiple packets to be packed in one page [22:26:14] <Yuvi> and the timestamps could be the beginning or end of the assiociated packet [22:27:33] <j-b> Vitor1001: many thanks [22:28:57] <iive> Dark_Shikari: i'm quite sure all retarded people feel very offended by that term. [22:29:29] <BBB> drv: wooh, thanks [22:29:45] <BBB> drv: what about 0.34013605? [22:29:56] <CIA-92> ffmpeg: aurel * r22186 /trunk/libavcodec/ (vp6.c vp56.c): move vp6 huffman table freeing code, out of common vp56 code [22:30:01] * BBB has no idea why there's a number 5/13 in his code [22:37:54] <drv> BBB: maybe 50/147? [22:38:28] <BBB> 50/130 and 50/147... [22:38:31] <BBB> hmm, interesting [22:40:46] <drv> BBB: http://www.mindspring.com/~alanh/fracs.html looks handy, just found it now [22:41:36] <BBB> that's pretty cool [22:42:25] <drv> looks like it does it in a pretty terrible way, but useful nonetheless :) [22:42:31] <BBB> that's ok [22:42:33] <BBB> good enough for me [22:42:39] <BBB> unfortunately it doesn't handle e/pi/etc. [22:42:41] <BBB> but that's ok [22:43:16] <drv> yeah, i was considering writing something that knew about common stuff like pi, sqrt(2), etc. [22:43:25] <drv> but i'm lazy ;) [23:14:56] <mru> Dark_Shikari: what container/transport do your low-latency friends use? [23:18:08] <BBB> the ones I talk to use old-fashioned mpeg, or flv [23:19:42] <j-b> ts ? [23:21:05] <BBB> no, actual mpeg1 system [23:21:10] <BBB> you wouldn't believe it [23:21:55] <mru> mpeg1 system and mpeg2 ps are more or less equivalent [23:22:21] <mru> ps adds a few optional things that are sometimes nice [23:22:28] <mru> and the format is a bit cleaner [23:22:41] <mru> but there's nothing wrong with mpeg1 system as such [23:23:23] <BBB> well, it means they roughly limit themselves to mpeg1video, so they don't use h264/mpeg4 [23:23:29] <BBB> which is a little silly nowadays, if you as me [23:23:38] <BBB> but hey, they run a business, not me [23:24:01] <mru> if you control both ends, shoving anything inside mpeg1-system is trivial [23:24:47] <Dark_Shikari> mru: UDP [23:24:54] <BBB> mru: well, they only control the sending part [23:25:01] <mru> Dark_Shikari: and on top of that? [23:25:34] <BBB> I think they chose mpeg1sys/mpeg1vid b/c it works nicely within browsers [23:25:49] <BBB> IE, Firefox on Mac and Windows all support it [23:26:49] <Dark_Shikari> I don't know [23:26:53] <Dark_Shikari> probably something custom [23:26:56] <Dark_Shikari> or maybe something like FLV [23:26:59] <Dark_Shikari> i.e. trivially simple [23:27:03] <Dark_Shikari> I think it's a very very simple custom layer [23:27:06] <Dark_Shikari> For flash they use RTMP obviously [23:27:18] <Dark_Shikari> which is over TCP and thus crappier [23:28:29] <CIA-92> ffmpeg: conrad * r22187 /trunk/libavformat/matroskaenc.c: [23:28:29] <CIA-92> ffmpeg: matroskaenc: use "title" tag instead of "description" in track title. [23:28:29] <CIA-92> ffmpeg: Patch by Anton Khirnov < whyskas at gmail > [23:28:29] <CIA-92> ffmpeg: conrad * r22188 /trunk/libavcodec/vp3.c: Explictly separate decoding whether fragments are coded by plane [23:28:31] <CIA-92> ffmpeg: conrad * r22189 /trunk/libavcodec/vp3.c: [23:28:31] <CIA-92> ffmpeg: Do MC and IDCT in coding (hilbert) order [23:28:31] <CIA-92> ffmpeg: This increases the slice size to 64 pixels, due to having to decode an [23:28:31] <CIA-92> ffmpeg: entire chroma superblock row per slice. [23:28:32] <CIA-92> ffmpeg: This can be up to 6% slower depending on clip and CPU, but is necessary [23:28:32] <CIA-92> ffmpeg: for future optimizations that gain significantly more than was lost. [23:28:33] <CIA-92> ffmpeg: conrad * r22190 /trunk/libavcodec/vp3.c: [23:28:33] <CIA-92> ffmpeg: Delay translating DCT tokens into coefficients until immediately before IDCT [23:28:34] <CIA-92> ffmpeg: This is generally around 12% faster than the prior method of creating a [23:28:34] <CIA-92> ffmpeg: linked list for each block as tokens are read, but can be anywhere from [23:28:35] <CIA-92> ffmpeg: 8% to 28% faster depending on file and CPU. [23:29:15] <Dark_Shikari> Yuvi: anything else missing? [23:29:29] <Dark_Shikari> to be merged [23:29:37] <mru> lol, some idiot just posted a comment: "I did not finish your article ..." [23:30:02] <Dark_Shikari> btw, x264 is probably going to get slashdotted in the next couple weeks [23:30:08] <Dark_Shikari> we are about to announce the first open source blu-ray support [23:30:15] <mru> :-))) [23:30:24] <Yuvi> a few things, the only major one in terms of restructuring is MV handling [23:30:43] <Dark_Shikari> our plan is to make a free blu-ray and give it out with the announcement for download [23:30:49] <BBB> Dark_Shikari: decrypt support? [23:30:53] <Dark_Shikari> BBB: encode [23:30:56] <BBB> oh... [23:30:59] <Dark_Shikari> Make your own Blu-rays. [23:31:06] <BBB> who's working on decode/decrypt? [23:31:08] <Dark_Shikari> No more paying $100,000 for Blu-code. [23:31:11] <BBB> j-b? [23:31:21] <Dark_Shikari> and no more http://www.lyris-lite.net/2010/girl_hornet.png [23:31:22] <astrange> how do you create the system structure? [23:31:24] <j-b> BBB: ? [23:31:28] <Dark_Shikari> astrange: Well, that's an unsolved problem ;) [23:31:32] <astrange> i think i figured out how to make a dvd with mencoder once [23:31:34] <Dark_Shikari> But hopefully when encode is done for audio and video [23:31:38] <Dark_Shikari> someone will make authoring tools [23:31:45] <Dark_Shikari> since that will be the only thing left [23:31:46] <BBB> j-b: is anyone working on BR decrypt? [23:31:52] <mru> Dark_Shikari: wtf happened in that picture? [23:31:54] <Yuvi> did that ever happen for DVDs? [23:31:56] <Dark_Shikari> mru: awful encoder [23:32:04] <j-b> BBB: you mean, like http://bd.videolan.org .? [23:32:12] <thresh> 1080p, gif-style [23:32:17] <mru> Dark_Shikari: I can tell, but what did it fuck up? [23:32:26] <Dark_Shikari> I have no idea. [23:32:27] <mru> qp varying like mad? [23:32:33] <BBB> aha [23:32:35] <BBB> j-b: thnks [23:33:47] <j-b> BBB: wrappers for mplayer are there too [23:34:03] <BBB> can we merge that and libdvdnav/css into ffmpeg? [23:34:19] <j-b> no idea :D [23:34:21] <j-b> you tell me [23:34:27] <BBB> I say yes [23:34:33] <BBB> too bad it's all GPL [23:34:40] <BBB> well you can't have it all I guess [23:34:48] <j-b> GPL is cool :D [23:34:58] <astrange> find a good semantic mapping to avformatcontext and sure [23:35:02] <j-b> BBB: libdvdnav should be fixed. [23:35:10] <BBB> ? [23:35:20] <j-b> BBB: and libbluray is quite early stage still [23:35:27] <BBB> that much is clear [23:35:29] <BBB> but it's cool :) [23:36:06] <j-b> BBB: libbdnav should work [23:36:21] <j-b> but libaacs is still, complex, and lacking keys [23:36:24] <BBB> what do you mean dvdnav is broken byut bdnav should work? [23:36:29] <BBB> and how similar are they? [23:37:08] <j-b> different [23:37:25] <j-b> I mean dvdnav is broken, because it doesn't handle correctly new DVDs [23:37:40] <j-b> and bdnav should work in comparison to libaacs :) [23:37:49] <j-b> not in comparison to libdvdnav [23:39:11] <BBB> you should fix dvdnav then :) [23:39:21] <BBB> anyway, interesting stuff you guys have [23:39:23] <BBB> very interesting [23:39:49] <j-b> we didn't do anything [23:40:18] <j-b> last time I suggested patches for libdvdnav, I was more or less told to fuck off [23:40:22] <j-b> which I did [23:40:34] <BBB> see [23:40:38] <BBB> that's why it should go into ffmpeg [23:40:46] <BBB> at least we maintain stuff 10 years after [23:51:28] <richardus> thank you mr. hardwarebug.org for your post, it was very good. [23:51:55] <mru> my pleasure [23:54:35] <Yuvi> is there a way to get make test print all the diffs in one run? [23:54:50] <mru> make -k test [23:55:07] <Yuvi> thanks

1 0

IRC log for 2010-03-02
by irc＠mansr.com 03 Mar '10

03 Mar '10

[00:02:16] <CIA-92> ffmpeg: stefano * r22140 /trunk/ffmpeg.c: [00:02:16] <CIA-92> ffmpeg: Make ffmpeg print a message and abort if the name of the format [00:02:16] <CIA-92> ffmpeg: provided with -f was unknown. [01:32:22] * peloverde is starting to think that merging HE-AAC is more trouble than just permanently maintaining a fork [01:33:22] <DonDiego> what happened? :) [01:34:23] <janneg> still the sample rate issue? [01:34:24] <Dark_Shikari> DonDiego: same thing that happened with ffmpeg-mt [01:34:40] <DonDiego> what happened with ffmpeg-mt? [01:34:40] <peloverde> yes still the sample rate thing [01:34:55] <Dark_Shikari> DonDiego: laziness + fear of michael --> stays a fork [01:35:53] <peloverde> I go along with the most involved but preferred approach of testing and fixing each individual demuxer [01:36:13] <Dark_Shikari> oh god [01:36:16] <Dark_Shikari> the he-aac sample rate issue [01:36:17] <Dark_Shikari> oh dear. [01:36:33] <Dark_Shikari> that has to be one of the worst ideas I've ever seen in spec-world [01:36:34] <peloverde> and now concern is expressed that it may make it more difficult to support things down the road that are completely out of spec [01:37:07] <astrange> just break them before they exist and then become popular enough that they can't do it [01:37:45] <peloverde> The real solution is just to use explicitly signaled SBR [01:38:59] <peloverde> Or two have two top level audioObjects like SLS [01:39:08] <Dark_Shikari> here's a simpler way: allow codecs to override container information [01:39:13] <Dark_Shikari> e.g. if the container says "22khz" [01:39:16] <Dark_Shikari> but the codec says "44khz" [01:40:25] <janneg> gah, xbmc bundles even more libraries than mythtv [01:40:39] <peloverde> Due to assorted nonsense, implicit SBR isn't in the headers at all [01:41:02] <peloverde> so you need some way to figuring out that you need to decode a frame to get the real parameters [01:43:14] <peloverde> apparently xmbc does some cool stuff with VDPAU [01:43:51] <peloverde> s/xmbc/xbmc/ [01:44:43] <janneg> doubts that that's the reason to bundle python [01:45:25] * janneg just needs to check if his crystal hd card works [01:46:23] <janneg> the minimal ffmpeg h264 decoder I've wrote doesn't work [01:47:27] <DonDiego> peloverde: so what is missing for sbr to get merged? [01:48:48] <peloverde> I actually sent an e-mail out asking that, and got instructions on how to fix the demuxer issue [01:49:14] <peloverde> Basically I see two out stand complaints [01:49:29] <peloverde> 1) The demuxer/sample rate issue, certainly a valid concern [01:49:48] <peloverde> 2) The filterbank could be more efficient [01:50:29] <peloverde> the filterbank is on the right order of complexity, I have no doubt that it could be made more efficient in C code and could also be SIMDed [01:50:50] <peloverde> However i think requiring new SIMD code is really out of the scope of a new decoder [01:51:07] <peloverde> and writing really fast scalar C is a waste of time [01:51:51] <Kovensky> and tends to make the C harder to read [01:52:46] <peloverde> I've made offers to give anyone who wants to work on the filterbank the 3 pages of the spec that describe it [02:05:34] <peloverde> Redditors are retards comment of the day: "Except that H264 is just as patent-encumbered as Flash." does he seriously think there are no patents on the non-H.264 sections of flash? [02:25:27] <CIA-92> ffmpeg: michael * r22141 /trunk/libavcodec/h264.c: [02:25:27] <CIA-92> ffmpeg: Fix a bunch of bugs ive introduced recently that broke threaded decoding. [02:25:27] <CIA-92> ffmpeg: might also fix issue1788 [03:17:46] <CIA-92> ffmpeg: mru * r22142 /trunk/libavutil/intreadwrite.h: Fix build failure with fast_unaligned and non-gcc-compatible compilers [03:17:46] <CIA-92> ffmpeg: mru * r22143 /trunk/ (configure libavcodec/Makefile): Make lsp a separate configurable and select it from codecs needing it [03:20:02] <CIA-92> ffmpeg: darkshikari * r22144 /trunk/ffpresets/ (18 files): [03:20:02] <CIA-92> ffmpeg: Add presets for all of the x264 presets, including fastfirstpass versions. [03:20:02] <CIA-92> ffmpeg: Not 100% accurate, since not all x264 options have ffmpeg equivalents yet. [03:20:02] <CIA-92> ffmpeg: Patch by Lou Logan. [06:54:09] <elenril> morning [06:54:40] <kshishkov> it's called differently in your country [06:55:22] <elenril> my_country: no such file or directory [06:55:52] <kshishkov> one should have one [06:56:02] * kshishkov has Sweden for homeland [06:56:58] <elenril> not really [06:57:10] <kshishkov> really [06:57:56] * elenril fails to see how does nationalism help anything [06:58:17] <kshishkov> what does nationalism has to do with that? [06:58:53] <kshishkov> country != government or nation [06:59:28] <kshishkov> it's just a place you like and want to live there forever [07:01:15] <elenril> i'm pretty sure you don't like Sweden just for nice views [07:01:36] <elenril> (btw wtf happened with google) [07:02:16] <kshishkov> yes, other things in Sweden are also very good [07:03:10] <kshishkov> (btw nothing special - they just decided to fade in not so useful interface elements) [07:04:06] <elenril> they also forced button background colors [07:04:13] <elenril> but left text as is [07:04:25] <elenril> which is braindead [07:05:27] <kshishkov> you are strange - their goal is to make people _leave_ start page ASAP, not look at it for hours [07:05:38] <elenril> http://img683.imageshack.us/img683/6797/screen20100302080445.png [07:08:32] * elenril wonders if it's possible to set a dark theme for google [07:09:08] <peloverde> elenril, you probably could with a user stylesheet [07:09:22] <elenril> ah, :effort: [07:09:38] <peloverde> someone has probably already made one, all you need to do is find it [07:10:29] <kshishkov> peloverde: looks like you're holding FFmpeg 0.6 release [07:10:39] <kshishkov> oh, was not quick enough [07:11:47] <superdump> morning [07:12:01] <elenril> meh, 0.5.1 is holding 0.6 release [07:12:06] <kshishkov> morrow [07:12:23] <kshishkov> elenril: no, they are almost unrelated [07:12:44] <elenril> orly [07:13:00] <elenril> so they're waiting for sbr? [07:13:19] <kshishkov> we all are [07:13:50] * kshishkov readies a big shovel to bury libavcodec/libfaad.c [07:14:53] <elenril> they should wait for -mt too ;) [07:15:24] <kshishkov> nah, it's also quite parallel [07:16:35] <astrange> i have homework if someone wants it [07:16:42] <astrange> http://gitorious.com/~astrange/ffmpeg/ffmpeg-mt/blobs/master/libavcodec/h26… uncomment this and make it not crash [07:20:16] <kshishkov> does it crash right there? [07:20:31] <astrange> in mpegvideo [07:20:56] <kshishkov> probably you should modify last/next_picture_ptr after it's used [07:21:42] <kshishkov> I think it expects last_picture_ptr = &last_picture [07:23:41] <andoma> morning [07:23:49] <kshishkov> hej (: [07:33:56] * elenril wonders where to steal code for -escaping strings in c [07:34:27] <kshishkov> write one yourself in 5 seconds [07:35:04] <elenril> isn't there a better way to do it? [07:35:15] <kshishkov> of course not [07:39:33] * kshishkov wonders how to load 16 bytes into XMM register at once [07:40:05] <astrange> i think that's the most common number of bytes to load into one [07:40:16] <astrange> well, no, i guess that's sse float [07:40:35] <Dark_Shikari> kshishkov: how would you not load 16 bytes into an xmm register [07:40:36] <kshishkov> still, how to do it? I don't see anything except movd/movq [07:40:39] <Dark_Shikari> movdqa [07:40:42] <kshishkov> ah [07:40:48] <astrange> or movdqu or movaps or movups [07:41:05] <astrange> or loaddqu. does that one do anything useful? [07:41:32] <Dark_Shikari> lddqu improves performance across cacheline split loads on pentium 4E [07:41:41] <Dark_Shikari> it was never useful on any other chip. [07:41:49] <Dark_Shikari> nobody knows why they didn't just put the logic into movdqu [07:42:20] <astrange> one of the cacheline hint instructions on g5 did nothing and was a complete pipeline stall too [07:44:41] <Dark_Shikari> I love the corporate email systems that have a "recall" button [07:44:48] <Dark_Shikari> with some sort of implication that anyone respects such a thing [07:45:38] <twnqx> yeah, i love the recall emails on my blackberry [07:45:38] <kshishkov> "pretend I never got that mail" button is much more useful [07:45:48] <twnqx> always makes me read the original ones [08:03:25] <superdump> has anyone seen reynaldo in here since yesterday morning...? [08:05:43] <jai> Dark_Shikari: isnt that outlook specific? [08:05:59] <Dark_Shikari> I have no idea [08:09:00] <jai> well, it only works when everyone concerned is using exchange [08:09:08] <jai> and people havent read the original yet [08:09:18] <Dark_Shikari> of course [08:09:23] <Dark_Shikari> that's sorta the point of my comment =p [08:09:31] <Dark_Shikari> I love it when people do recalls to @gmail accounts [08:09:49] <jai> lol [08:10:05] <jai> people are too cute :) [08:13:18] <siretart`> morning [08:15:06] <KotH> grüezi wohl [08:15:07] <siretart`> seems phoronix has picked up diego's news update [08:15:48] <siretart`> hmm. perhaps they should have waited for the 0.5.1 release announcement :-) [08:17:02] <astrange> http://www.phoronix.com/forums/showthread.php?p=115034#post115034 [08:18:38] <elenril> o_0 they misspelled ffMPEG [08:22:43] <jai> anyone have opinions on how dvd audio encryption should be handled in lavc [08:24:03] <kshishkov> probably it should not be handled there at all [08:24:15] <kshishkov> decryption - yes [08:24:22] <superdump> they can write another mail about the release of 0.5.1 and 0.6 when they come if they want [08:24:38] <jai> currently, i link to libdvdcpxm [08:24:49] <astrange> how does the decryption work? [08:24:53] <twnqx> dvd audio encryption? [08:24:58] <twnqx> what's that even? [08:25:27] <kshishkov> astrange: mostly in the same fashion but inputs and outputs differ ;) [08:25:30] <astrange> and how large is the key? [08:47:34] <jai> twnqx: cppm [08:48:18] <twnqx> never even heard of it... but well :) [08:52:25] <merbzt> jai: we should support the crypto [08:52:49] <merbzt> jai: the keys I'm not sure [08:53:17] <jai> merbzt: you mean the keys hardcoded in libdvdcpxm? [08:53:24] <merbzt> but it might make better sense to add the support to libdvdread [08:53:28] <jai> hm [08:53:29] <merbzt> yes [08:54:54] <jai> merbzt: so your suggestion would be to do the decryption at the playback layer? [08:55:15] <merbzt> no [08:55:40] <merbzt> decrypt in lavf and let some other lib handle the key handling [08:55:57] <kshishkov> like asfcrypt support we have [08:56:33] <kshishkov> this way it's both supported and little to blame of lav* side [08:57:09] <twnqx> and libcss? [08:57:09] <twnqx> :> [08:58:38] <KotH> why should anyone blame lav* for key handling? [08:58:48] <KotH> i mean, those keys are public after all! [08:59:05] <jai> wait a minute, what was libavdevice for? [08:59:44] <jai> after decryption i still need to feed the dvda blocks into our demuxer [09:04:08] <jai> well, anyway, i'll first try and get the prerequisites committed [09:19:36] <superdump> i'm a bit concerned about reynaldo [09:19:54] <superdump> he lives near concepcion [09:24:24] <merbzt> :/ [09:25:00] <merbzt> superdump: did you try to mail him ? [09:25:15] <superdump> i sent him an SMS yesterday [09:25:30] <superdump> his domain is down, so i don't think mailing will help [09:26:17] <superdump> ah [09:26:19] <superdump> phew [09:26:23] <superdump> facebook says he's ok [09:27:48] <jai> \o/ [09:28:37] <merbzt> goodie [09:28:44] <peloverde> that's a relief [09:28:49] <merbzt> does it say anything more ? [09:31:43] <superdump> he says his opendot mail is down, but you can mail him on his osp account and he'll see it when his connection is up [09:31:49] <superdump> sounds like it's sporadic [09:32:14] <superdump> he said they're all ok but the situation is far from ideal [09:32:27] <superdump> still, he said they're 'sailing through it' [09:37:36] <pulczynski> Hello #ffmpeg ! I am working with video using ffmpeg as reader/demuxer from various stream to deinterlaced/scaled yuv4mpeg . Some source materials are partialy interlaced, partially progressive (tv archives is the source). I found "decombing" filter from handbrake would solve thouse issues ( more details : http://trac.handbrake.fr/wiki/Decomb ) . Otoh I found commercial software http://www.yuvsoft.com/technologies/deinterlacing/ . Is there any pl [09:38:22] <Dark_Shikari> your message was cut off at "there any pl" [09:38:33] <siretart`> smells like a question for #ffmpeg, not -devel. [09:38:58] <kshishkov> nah, it's a question of adding filter from Handbrake to lavfi [09:39:09] <Dark_Shikari> >implying lavfi will ever be finished [09:39:14] <pulczynski> Is there any plan implementing decomb filter in ffmpeg? [09:39:16] <Dark_Shikari> x264's filter interface will be done first [09:39:17] <pulczynski> If no my team will start develop yov4mpeg decomb filter (similiar to http://gitorious.org/y4m-logo ) - [09:39:20] <pulczynski> is anyone interested in participating in such project? [09:39:26] <Dark_Shikari> pulczynski: it should have decomb. [09:39:55] <astrange> is neuron2 decomb good? tfm is better and i thought mplayer pullup was too [09:40:01] <pulczynski> Dark_Shikari: great! Maybe we coud help somehow? [09:40:14] <superdump> there's probably already open source decomb code out there that could be just ported to lavfi [09:40:17] <astrange> i watched a 2004 fansub filled with mftoon and ivtc mismatches the other day, i assumed it was like that [09:40:29] <superdump> Dark_Shikari: i get the impression some people are using lavfi already [09:40:32] <pulczynski> superdump: havent heard of any except handbrake code [09:40:52] <astrange> yes, lavfi is functional in the fork, but i haven't looked at adding filters to it [09:41:09] <astrange> an ivtc would be complicated if it doesn't handle pts properly [09:43:31] <pulczynski> The reason i am planning implementing is as yov filter not ffmpeg filter is that i HAVA to use quite stable ffmpeg version, not lavfi fork. Any plans when lavfi goes stable? [09:43:38] <pulczynski> s/yov/yuv/ [09:43:55] <kshishkov> no idea on that [09:44:21] <Dark_Shikari> 2020 [09:44:23] <elenril> lavfi isn't finished? [09:44:36] * elenril thought it just doesn't have any filters [09:44:56] <kshishkov> elenril: it is not finished until it's in main SVN. And even then... [09:45:04] <astrange> is there a todo? [09:45:21] <astrange> http://wiki.multimedia.cx/index.php?title=Libavfilter is out of date [09:45:26] * elenril sees a libavfilter/ in his ffmpeg sources [09:46:22] <astrange> soc/libavfilter/TODO but it doesn't say which are merge requirements [09:56:45] <Kovensky> <astrange> is neuron2 decomb good? <-- telecide is pretty dumb compared to tfm, it's only advantage is that it's faster so it's less annoying in YATTA [09:58:25] <pulczynski> Kovensky: astrange: any opinion on http://www.yuvsoft.com/technologies/deinterlacing/ ? [10:00:13] <jai> elenril: it isnt integrated fully yet [10:00:29] <astrange> "Preserves scan rate (double rate)" [10:00:43] <jai> i see a bunch of todos floating around, but except stefano and vitor not many people work on it (afaik) [10:01:01] <astrange> i wouldn't call that a deinterlacer, it can be done by scaling each field 2x vertically and making them into frames [10:01:30] <astrange> which the mplayer filter tfields does. it can be a good idea sometimes [10:02:06] <astrange> i recommend looking at yadif or tdeint, they're pretty good and open source [10:02:14] <Kovensky> their scaler doesn't seem to be very good either, look at th blurriness [10:02:40] <pulczynski> well, in http://www.yuvsoft.com/pdf/Deinterlace.pdf it states : Uses two frames and two fields [10:02:43] <astrange> the best one i know is called tempgaussmc and is a really complicated avisynth script [10:02:47] <Kovensky> and there are still a few interlacing artifacts on those black bar thingies [10:02:53] <Dark_Shikari> tempgaussmc is awesome. [10:02:55] <Kovensky> astrange: a really slow one too [10:02:57] * kshishkov prefers lavf "blend" [10:03:08] * Kovensky suggests "weave" [10:03:10] <astrange> i like yadif over any blend as a realtime deint [10:03:41] <astrange> http://avisynth.org/mediawiki/upload/c/c8/TempGaussMC_beta1mod.avsi lavfi needs a layer to do all this [10:04:07] <pulczynski> Well, the problem in my situation is I would like filter to detect if deinterlaced is needed (our source files arent hinted with interlaced/progresive flag, so we have to look at the video before converting ) [10:10:43] <siretart`> DonDiego: hey there! [10:11:19] <DonDiego> moin [10:11:47] * DonDiego woke up old and fresh at the same time [10:11:52] <DonDiego> <--- birthday [10:12:05] <twnqx> congratulations [10:12:16] <KotH> congrats DonDiego [10:12:17] <siretart`> DonDiego: I've prepared some tarballs and signatures here as birthday present: http://wiki.tauware.de/~siretart/ffmpeg/ :-) [10:12:22] <andoma> DonDiego: but how old? [10:12:23] <siretart`> DonDiego: congrats :-) [10:12:42] <KotH> DonDiego: you're slowly moving towards pension age ;) [10:12:46] <kshishkov> andoma: you've said you're too old to trust you ;) [10:12:58] <andoma> kshishkov: yeah, I'm ancient [10:13:37] <kshishkov> andoma: ancient things only increase in value, you know [10:13:53] <DonDiego> well, let's not let the suspense build up infinitely [10:13:57] <DonDiego> i now am [10:14:02] <DonDiego> *drumroll* [10:14:12] * DonDiego pauses for dramatic effect [10:14:20] <DonDiego> 35 [10:14:58] <kshishkov> ah, non-round date [10:15:29] <DonDiego> i tend to call it 30.5 since after thirty the importance of age differences diminishes.. [10:15:43] <merbzt> indeed [10:15:49] <andoma> <- 30.2 in that case [10:15:59] <andoma> feels good [10:16:13] <peloverde> 30.-6 in that case [10:16:16] <superdump> happy birthday DonDiego [10:16:19] <Honoome_> DonDiego: oh happy birthday then :D [10:16:23] <peloverde> yes happy birthday [10:16:24] <superdump> what peloverde said [10:16:42] <kshishkov> I agree with previous orators [10:17:13] <kshishkov> andoma: actually it's worth measuring from 26 - no more ungdom biljett [10:17:22] <andoma> right [10:17:28] <KotH> ungwhat? [10:18:06] <kshishkov> people here should learn Swedish, it's FFmpeg after all [10:23:13] * superdump still gets ungdom biljett [10:23:18] <superdump> which is nice [10:26:06] <KotH> kshishkov: i know japanese, that's enough :) [10:26:27] * Honoome_ could settle for English [10:26:56] * KotH could settle for swiss german [10:27:15] * merbzt could settle for some chocolate [10:27:29] <peloverde> As a typical american I speak english, and I speak spanish poorly [10:28:29] <KotH> merbzt: no prob, just come here and i'll serve you some [10:28:56] <merbzt> good to know [10:29:00] <KotH> peloverde: uhmm.. a typical american doesnt speak english ;-> [10:29:42] <Honoome_> peloverde: americans speak english? [10:29:50] <peloverde> We speak american english... which is better. It is the official English of FFmpeg. [10:30:05] <jai> happy birthday DonDiego [10:30:09] <KotH> peloverde: nah, the official english of ffmpeg is C ;) [10:30:56] <peloverde> good old LANG=C never fails me [10:32:42] <wbs> peloverde: regarding that roundup case (concatenated AAC frames), I haven't got any clue on whether it's multiple RDBs, I haven't got any clue about AAC internals to comment on that [10:33:36] <wbs> peloverde: but these are headerless(?) packets, the rtp session has set up proper extradata, so if i've understood things correctly, the packets themselves have no ADTS headers..? [10:33:37] <peloverde> I'll have to take a close look at it. To tell you the truth I know very little about how AAC s streamed (except for progressive download MP4s :) ) [10:34:18] <peloverde> Either way it strikes me that the same fix might allow us to support both [10:35:37] <wbs> and as michael noted, the proper thing would be to split them outside of the decoder... but since faad managed to return the number of used bytes correctly, getting that capability to the ff aac decoder would be great too [10:37:38] <DonDiego> american english indeed fixes some glitches - i like it :) [10:37:59] <DonDiego> peloverde: Â¿asi que hablas castellano? [10:39:28] <peloverde> DonDiego: Estudiaba castellano por seis anos in colegio [10:40:06] <peloverde> Pero no hablo mucho hoy [10:40:08] <DonDiego> Â¿seis aÃ±os? es un montÃ³n.. [10:40:19] <DonDiego> te falta prÃ¡ctica.. [10:40:46] <merbzt> wbs: vÃ€lkommen ombord [10:40:58] <wbs> merbzt: tack :-) [10:41:55] <peloverde> Si, todavia leo y escha mehor de hablo y escrito [10:42:06] <merbzt> wbs: are you skilled in the art of Swedish or do you just know enough to get by ? [10:42:06] <peloverde> s/mehor/mejor/ [10:42:20] <wbs> merbzt: swedish just happens to be my native language :-) [10:42:55] <merbzt> wbs: coz you are swedish or a minority ? [10:43:34] <KotH> people who do not speak japanese are a minority... at least here ;) [10:43:44] <wbs> merbzt: swedish-speaking minority of finland, to be precise [10:44:03] <DonDiego> peloverde: "escha"? :) [10:44:17] <peloverde> escucho [10:44:34] <peloverde> typing has never been my strong suite, even in english [10:44:40] <DonDiego> :) [10:45:29] <merbzt> wbs: ic, it's best to know, before I assumed all Finnish people know a little bit of swedish [10:45:33] <merbzt> that was not the case [10:46:02] <wbs> merbzt: due to our minority and swedish being one of the official languages of finland, all the finns have to learn at least a bit of swedish in school, yes [10:46:19] <wbs> but in my case, it's my native language [10:47:33] <merbzt> goodie, more swedish speaking FFmpeg devs [10:47:44] <andoma> yep! [10:48:03] <merbzt> now we just need to convert Reimar, Kostya and Rob [10:48:04] * KotH has to find more swiss german speaking people [10:48:32] <merbzt> then we can really start #ffmpeg-dev-swedish [10:49:03] <DonDiego> ahem, i think the majority speak german actually :) [10:49:27] <wbs> merbzt: ah, now I realized who you are, too. :-) [10:50:42] <KotH> DonDiego: let's start #ffmpeg-dev-ger :) [10:51:00] <KotH> DonDiego: and a country called FFsoc! [10:55:07] <Rathann|work> hi guys [10:55:19] <KotH> heyo Rathann|work [10:55:44] <Rathann|work> I speak a bit German, enough to get by, but not enough for a technical conversation [10:56:13] <Rathann|work> and I'm learning French these days ;) [10:57:32] <benoit-> Rathann|work: good ! [10:58:48] <Rathann|work> merci [11:01:38] <DonDiego> mans speaks german quite well and understands mostly everything [11:01:50] <DonDiego> so we still keep you outnumbered :) [11:02:31] <DonDiego> you parvenus, you [11:03:37] <kshishkov> merbzt: no problem with converting me [11:04:00] <merbzt> I know, we just nee to finalize it [11:05:26] <KotH> yeah.. give him a chance to move out of the 4th world country ;) [11:05:53] <kshishkov> KotH: and we were 3rd world country just a month ago :( [11:06:03] <KotH> kshishkov: sic transit gloriam mundi ;) [11:06:38] <kshishkov> KotH: not so much of "gloria". BTW, how well do you know Latin? [11:07:03] <KotH> kshishkov: i studied it for half a year in high school... [11:07:13] <kshishkov> no accidents? [11:07:20] <KotH> kshishkov: ie about >15y ago [11:07:27] <KotH> accidents? [11:07:44] <kshishkov> you know, summoning by uttering the wrong word [11:07:52] <KotH> ah.. nah [11:08:01] <KotH> at least nothing unusual [11:08:15] <KotH> just the normal earth ghost, faries and stuff like that [11:08:16] <kshishkov> IIRC, you country _official_ name is Confederatia Helvetica [11:08:27] <KotH> confederati_o_ [11:08:43] <KotH> we are a patriarchaic country ;) [11:08:59] * kshishkov lives in a country where people seem to not know even one language properly [11:12:02] <KotH> i always told you to come here to .ch [11:12:19] <KotH> we know languages and we've chocolate [11:12:51] <kshishkov> if you convince your immigration board, fine with me [11:13:05] * kshishkov prefers cheese to chocolate though [11:13:17] <KotH> easiest to convince them is for you to have a job [11:13:35] <KotH> get a company who is interested in your skills to hire you [11:13:39] <KotH> hmm. [11:13:42] <KotH> kshishkov: try zattoo [11:13:54] <KotH> kshishkov: they have an office here in zürich [11:14:00] <kshishkov> why sudden accent? [11:14:01] <KotH> kshishkov: and they are using ffmpeg [11:14:10] <KotH> accent? [11:14:12] * KotH has no accent [11:14:32] <kshishkov> you said "try that too" with a definite German accent [11:15:51] <KotH> uhmm.. i have a german accent ^^' [11:16:02] <kshishkov> I also have German accent [11:16:11] <KotH> at least enough for people to recognize it [11:16:25] * KotH blames mru for not teaching him english properly [11:16:33] <kshishkov> yes, same story here. But I don't know German at all! [11:16:46] <KotH> you blame mru too? [11:17:14] <kshishkov> well, I can blame him but I'd never ask him to teach me English [11:17:45] * kshishkov speaks ARM assembly with x86 accent too and here's the case to blame mru [11:22:18] <KotH> let us all collectively blame mru! [11:22:31] <kshishkov> why? [11:22:47] <KotH> why not? [11:23:03] <kshishkov> he's done good things [11:23:03] <iive> KotH just loves to blame others... [11:23:20] * KotH blames iive for noticing [11:23:23] <kshishkov> iive: maybe he works for the government [11:24:13] <iive> hum, around here everybody blames the government for anything... so I can't tell. [11:24:42] <kshishkov> iive: well, that's the only way government "explains" anything here [11:39:21] <twnqx> for the german speaking population here... http://www.golem.de/1003/73518.html [11:40:55] <kshishkov> "dem Videoformat Bink" lacks audio part mentioned [11:40:57] <twnqx> rumors about the upcoming 0.6 spreading fast :P [11:41:37] <twnqx> isn't bink a container as well? [11:41:41] <kshishkov> it is [11:41:58] <kshishkov> and experimental AAC encoder is no news [11:43:17] <kshishkov> "Ab sofort bietet FFmepg ein Protokoll ..." if it's what I think it's a bit funny. [11:44:11] <elenril> and nobody mentioned all the metadata improvements :) [11:44:15] <twnqx> i have no clue what that part is about.... [11:44:42] <kshishkov> elenril: because that page muxer does not support metadata :P [11:45:39] <kshishkov> twnqx: I don't know German but that sentence sounds like "FFmpeg has become a protocol for converting/decoding multimedia data". [11:46:13] <kshishkov> and we don't have own RFC yet :( [11:47:56] <twnqx> no [11:49:10] <twnqx> it's more like... "ffmpeg offers a protocol for linking files and a tool to gather information(metadata?) from media files" [11:49:23] <kshishkov> that's ffprobe [11:49:33] <twnqx> so ffprobe is the new ffmpeg -i? :> [11:49:34] <kshishkov> and urlconcat then [11:49:41] <kshishkov> yes, it is [11:49:42] <twnqx> ah, never heard of that [13:30:39] <KotH> how are the current release plans for 0.6? [13:30:45] <KotH> s/how/what/ [13:30:50] * KotH blames mru [13:30:51] <kshishkov> it's in our wiki [13:31:35] <kshishkov> http://wiki.multimedia.cx/index.php?title=FFmpeg_Release_Plan#Things_that_n… [13:32:43] <peloverde> Is anyone actulally working on LATM at the moment? [13:34:43] <kshishkov> I don't think so [13:37:09] <merbzt> peloverde: not vital, but would be nice to get a DVB complete release [13:37:37] <peloverde> true, I just question it's feasibility for 0.6 if no one is working on it [13:37:38] <siretart`> KotH: either I or DonDiego need to write to ffmpeg-devel with details on the plan [13:38:09] <kshishkov> peloverde: we can settle on mere SBR support ;) [13:38:28] <superdump> peloverde: well there's that code that just takes one stream [13:38:35] <peloverde> SBR is more or less done [13:38:51] <merbzt> superdump: would be nice to have that code at least [13:39:15] <KotH> siretart`: a guestimate on ETA would be enough for me :) [13:39:42] <peloverde> Review seems to meander into offtopic tangents though [13:39:59] <merbzt> as usual then [13:40:09] <peloverde> LC feature requests are fine in general but seem non-germain to adding SBR [13:40:20] <merbzt> agree [13:40:36] <Rathann|work> meh, roundup cert is expired [13:41:10] <superdump> peloverde: and as it's functional, i think it's good to get it in [13:41:14] <kshishkov> so is Michael's key [13:42:59] <Rathann|work> indeed [13:44:43] <siretart`> KotH: the current plan is to branch on mar 13, and release on mar 20 [13:45:04] <KotH> siretart`: thanks [13:45:16] <Rathann|work> siretart`: anything I can do to help? I don't have much time though... [13:46:36] <siretart`> Rathann|work: I don't have specifc tasks at hand, but I'll ping you as soon as I have the "downstreams" wiki page drafted, OK? [13:46:52] <siretart`> maybe diego has something more specific? [13:46:55] <kshishkov> Rathann|work: search for critical bugs still need patching [13:48:31] <DonDiego> Yuvi: what's the status of your theora work? [13:48:46] <KotH> siretart`: apropos downstream [13:48:53] <KotH> siretart`: there is still this unused mailinglist :) [13:51:04] <superdump> siretart`: for 0.6? [13:51:47] <siretart`> KotH: yeah, I remember. Let me start with the wiki and point to that from there [13:51:57] <DonDiego> Rathann|work: netbsd status is apparently pending [13:52:08] <siretart`> superdump: sorry? [13:52:24] <superdump> siretart`: branch on march the 13th for 0.6 [13:53:07] <DonDiego> i'd like to restate that the most critical thing for the release is the theora work and the aac decoding [13:53:20] <DonDiego> remember the release name: "works with html 5" [13:54:05] <siretart`> superdump: yes, we're discussing 0.6 now. 0.5.1 is "ready" from my side, just awaiting publishing [13:54:15] <superdump> haven't we had a well-functioning theora decoder for some time already? [13:54:27] <superdump> siretart`: cool :) [13:54:36] <kshishkov> superdump: somebody also wants it to be faster than reference one [13:54:37] <DonDiego> it's slow and it does not support the latest features [13:54:52] <superdump> mmm [13:55:13] <superdump> they're extending the theora spec? [13:55:30] <kshishkov> look at vorbis [13:56:19] <KotH> superdump: guess why people are reluctant to adopt anything from xiph? [13:56:20] <DonDiego> 4:4:2 and 4:4:4 colorspace stuff [13:56:25] <DonDiego> something else i forget [14:01:01] <peloverde> uncoded 4MV [14:01:22] <DonDiego> peloverde: do you have a rough ETA for aac sbr? [14:01:49] <peloverde> It depends on review and what we decide to do on the demuxer issue [14:02:10] <DonDiego> hmm [14:03:45] <kierank> doesn't latm require chained demuxing? [14:03:47] <peloverde> general philosophy about emulating faad bugs in regular (non-SBR) AAC-LC isn't exactly helpful [14:03:51] <superdump> review -> michael wants someone who knows the algorithms to look over the filterbank and optimise it [14:04:14] <superdump> demuxer issue -> what to do with sample rates [14:26:48] <CIA-92> ffmpeg: diego * r22145 /branches/0.5/RELEASE: Mention licensing-related changes; some whitespace adjustments. [14:35:55] <DonDiego> ok, guys, do you know anything we may have forgotten about 0.5.1? [14:36:10] <kshishkov> yes, actually releasing it [14:43:19] <peloverde> were the AAC buffer checks backported? [14:43:51] <CIA-92> ffmpeg: diego * r22146 /branches/0.5/VERSION: Bump version to 0.5.1. [14:46:16] <DonDiego> geez [14:46:33] <DonDiego> motion-est.c compilation takes so long that it slows down parallel build enormously [14:46:57] <DonDiego> i can compile on a 16 core machine aptly-named "power" at work now [14:47:14] <DonDiego> but that file is the bottleneck [14:47:38] <DonDiego> all the other jobs finish before that one [14:47:41] <DonDiego> really all of them.. [14:48:50] <Compn> DonDiego : going to split it ? [14:48:59] <DonDiego> it should be split, yes [14:49:08] <DonDiego> but probably only michael can do it [14:50:25] <Compn> who split h264 from svq3 ? :) [14:50:39] <DonDiego> i tried, michael did it in the end [14:50:42] <Compn> ah [14:50:51] <DonDiego> i tried and failed that is [14:50:52] <Compn> tricky beast [14:51:04] <Compn> i remember you working on it, didnt know michael finished it [14:55:48] <superdump> so, reynaldo and family are ok and his house is ok too [14:55:58] <superdump> but they have to be wary of rioters and looters [14:56:34] <superdump> so even though they and their property are ok, it sounds like an unsafe place to be [14:58:07] <DonDiego> ouch [14:58:15] <DonDiego> he was in the earthquake area? [14:59:13] <DonDiego> oh, so "make test" fails for 0.5.1? [14:59:22] <DonDiego> seek regression test with asf.. [14:59:32] <mru> that's not good [15:01:31] <DonDiego> nope [15:01:44] <DonDiego> can anybody confirm/deny? [15:01:59] <DonDiego> power is an x86_64 box with gcc 4.4 [15:02:08] <DonDiego> let me try this at home :) [15:02:44] <superdump> DonDiego: yes, he lives in concepcion [15:03:14] <DonDiego> mru: btw, i'm so happy you made the regtests parallelizable.. [15:03:46] <DonDiego> crap, make seektest fails [15:04:13] <DonDiego> this will have to be investigated :-/ [15:04:25] <DonDiego> possibly the security fixes broke it.. [15:04:47] <mru> just the seek test failing? [15:05:07] <DonDiego> yes [15:05:17] <DonDiego> IIRC seektest is the last one.. [15:05:27] <mru> yes [15:05:28] <DonDiego> there were security fixes for the asf demuxer [15:05:42] <janneg> differs the test spec between the branch and trunk? [15:05:56] <DonDiego> can somebody confirm on their boxes? [15:06:49] <janneg> compiling the branch right now [15:06:55] <DonDiego> thx [15:07:08] <siretart`> confirmed here as well [15:07:20] <DonDiego> i compiled with --enable-gpl --enable-swscale --enable-postproc [15:07:28] <DonDiego> fsck [15:07:38] <DonDiego> well, glad we found it in time.. [15:08:16] <mru> janneg: want some render time on my quad-core? [15:09:06] <DonDiego> can somebody verify this on non-x86? [15:09:26] <janneg> mru: sure. the core2 quad or the i7? [15:09:36] <mru> c2q [15:09:38] <mru> 4GB [15:09:47] <mru> I need the i7 for "real" work [15:10:28] <janneg> mru: download a "job" file from http://www.jannau.net/bbb_videowall/jobs/4g/ and run it [15:11:32] <janneg> if /tmp is a tmpfs you need to define $TMP to a real directory [15:12:26] <janneg> and replace srcipts/render_settings.py with this file [15:12:31] <janneg> http://www.jannau.net/bbb_videowall/render_settings.py [15:13:40] <siretart`> DonDiego: it seems r22080 is causing the regression [15:14:15] <DonDiego> why didn't it break seektests on trunk? [15:14:37] <siretart`> not sure, I'm on it [15:15:24] <superdump> the tests use files with invalid packet size? [15:15:41] <DonDiego> geez, what a disgrace it would have been if we had released 0.5.1 with failing regtests.. [15:15:45] <superdump> the packet size code received some attention in trunk? [15:18:26] <mru> janneg: you're not doing any of those jobs? [15:19:40] <janneg> no, my quad still renders 01_intro-04 and KotH's xeon 02_rabbit-03 [15:19:57] <mru> I'll just start at the top then [15:22:33] <janneg> mru: I suspect that quite a few frame would OOM with 4G but the script that creates the job files ommits already completed frames [15:22:51] <siretart`> DonDiego: have the test files for the seek tests been altered in trunk? [15:23:55] <DonDiego> let me doublecheck.. [15:24:36] <janneg> siretart`: I dont think so [15:25:21] <siretart`> hm, do I understand correctly that tests/data/b-libav.y4m is the offending test and that this file is generated? [15:26:08] <mru> if codectest and lavftest pass, all files are generated correctly [15:26:37] <siretart`> running now.. [15:28:43] <janneg> mru: I think s/lavf/libav/ for 0.5 [15:28:55] <mru> could be [15:28:56] <janneg> both passes for me [15:32:42] <siretart`> confirmed [15:34:28] <janneg> siretart`: seek test refereences are not changed in trunk for those two files. formatting changes aside [15:34:28] <DonDiego> what are you confirming or disconfirming there? [15:35:06] <janneg> codectest and libavtest passing [15:37:09] <DonDiego> yes, it's seektest that creates the problem [15:37:36] <DonDiego> there have been a bunch of commits to asfdec.c between the branch and the security fix [15:38:31] <siretart`> DonDiego: reverting r22080 makes the seektest pass again [15:39:34] <siretart`> it seems to me that for some reason, we deal with a testfile that has a packet_size == 0 [15:40:41] <janneg> 19361 might fix it too [15:42:45] <siretart`> testing [15:43:21] <janneg> no, seektest is still failing [15:51:03] <mru> janneg: 2 frames rendered [15:53:13] <janneg> mru: yeah! only 12000 to go [15:55:46] <siretart`> DonDiego: okay, I've fixed the seektest by backporting r19270 [16:03:55] <CIA-92> ffmpeg: siretart * r22147 /branches/ (4 files in 2 dirs): (log message trimmed) [16:03:56] <CIA-92> ffmpeg: fix 'seektest' again [16:03:56] <CIA-92> ffmpeg: backport r19270 by rbultje: [16:03:56] <CIA-92> ffmpeg: Remove any reference to ASFContext.packet_size and replace it with [16:03:56] <CIA-92> ffmpeg: AVFormatContext.packet_size. See "[PATCH] asf*.c/h: use [16:03:56] <CIA-92> ffmpeg: AVFormatContext->packet_size instead of own copy" thread on ML. [16:03:57] <CIA-92> ffmpeg: and r19361 by reimar: [16:04:20] <siretart`> janneg: can you confirm that seektest is fixed now? [16:06:20] <BBB> huh? I fixed something? [16:10:33] <DonDiego> ok, let's test everywhere to make sure.. [16:13:30] <janneg> siretart`: seek regression test: success [16:13:45] <siretart`> :-) [16:14:02] <siretart`> make test passes for me [16:14:19] <DonDiego> ok [16:14:53] <DonDiego> i guess we can start rolling the tarballs.. [16:15:39] * mru fetches feathers [16:16:22] <Compn> rockbox irc logs making fun of Dark_Shikari in ffmpeg irc logs > http://www.rockbox.org/irc/log-20100301 [16:16:32] <Compn> and thus, the cycle is complete, for now we can make fun of rockbox irc logs [16:19:15] <DonDiego> ppc test also passed [16:19:18] <DonDiego> http://www1.mplayerhq.hu/~diego/index.html [16:19:21] <DonDiego> i'd like you guys to review my news entry [16:19:23] <DonDiego> i'm sure it could use some lovin' [16:20:20] <siretart`> the date needs to advance to 2. march [16:20:28] <siretart`> we are past samoa time now [16:20:49] <DonDiego> :) [16:20:59] <siretart`> rest reads fine to me [16:21:33] <DonDiego> fixed [16:22:43] <Compn> DonDiego : i think you should mention that the general code of .5.1 is a year old [16:23:09] <Compn> just so no one gets confused re: its status to svn [16:25:04] <siretart`> Compn: propose a wording [16:25:11] <jai> DonDiego: *newer [16:25:25] <jai> DonDiego: err, s/never/newer [16:25:46] <DonDiego> fixed [16:26:16] <jai> k [16:26:34] <Compn> siretart : am trying to form something, brain is jelly today ;\ [16:26:57] <siretart`> TBH, I think the fact that 0.5.1 is based on the 0.5 release branch and that we explictly reference an upcoming 0.6 release seems pretty clear to me already [16:27:05] <siretart`> so I'd rather leave it as it is [16:27:12] <Compn> i dont think its very clear [16:28:27] <siretart`> Hm. perhaps we can add "Please note that this is a maintenance only release; no new codecs, formats or other feature are being introduced" to the first paragraph [16:28:43] <Compn> that sounds good [16:28:58] <Compn> i mean, 'new point release' isnt defined anywhere, is my point [16:29:12] <Compn> to people who are unfamiliar with packaging [16:29:22] <Compn> or versioning i should say [16:29:37] <BBB> DonDiego: I read it yesterday, looks good to me [16:29:58] <BBB> dondiego: you might want to clear up that 0.5-compiled apps don't have to be recompiled to work wth 0.5.1 [16:30:17] <BBB> i.e. ABI compatibility [16:30:18] <jai> maybe replace MOV with MOV/MP4 [16:30:20] <BBB> this is a big thing [16:30:30] <jai> which makes more sense imho [16:32:15] <siretart`> BBB: does the sentence read clearer to you if the 'before upgrading to 0.6' part is moved to the front of the sentence? [16:37:39] <DonDiego> http://www1.mplayerhq.hu/~diego/index.html [16:37:44] <DonDiego> current version with typos fixed [16:37:50] <DonDiego> ok, tarballs... [16:39:01] <DonDiego> siretart`: i suggest you make a separate tarball [16:39:11] <DonDiego> then i upload mine and we compare checksums [16:39:25] <siretart`> they will not match because of timestamp issues [16:40:36] <DonDiego> huh? [16:40:39] <siretart`> I'd say publish the tarball with your signature, and I'll verify the *contents* against my checkout and will then send you my sig [16:41:20] <siretart`> tar stores timestamps and other meta information that will differ on two systems [16:41:39] * DonDiego learns something new every day [16:41:44] <DonDiego> well, then just diff the trees [16:41:59] <mru> someone should write a tardiff [16:42:06] <BBB> dondiego: it still reads like you "have to" recompile against 0.5.1 [16:42:18] <BBB> I think you should add "parallel installing of 0.6" in that sentence [16:42:25] <BBB> (last sentence) [16:42:32] <siretart`> mru: ptardiff does exist [16:43:00] <BBB> e.g. "Please note that distributors are recommended to recompile applications against 0.5.1 in order to allow parallel installation of the upcoming 0.6 release" [16:43:07] <BBB> or something like that [16:43:11] <BBB> does that make sense? [16:43:56] <siretart`> you cannot install 0.6 in paralell with 0.5.1 [16:44:42] <BBB> let me get something straight [16:44:50] <BBB> can you upgrade from 0.5 to 0.5.1 without recompiling applications? [16:45:08] <siretart`> yes, the ABI has changed in a compatible way. [16:45:36] <BBB> I suggest to explicitely state that in the release notes [16:45:48] <BBB> in some way [16:46:01] <BBB> I can't word it correctly, I think, but I suggest to add it like that, literally [16:48:40] * DonDiego scratches his head [16:48:53] <DonDiego> i get two different signatures for the same tarball [16:49:01] <DonDiego> on two different computers [16:49:13] <DonDiego> gpg --armor --detach-sign ffmpeg-0.5.1.tar.bz2 [16:49:21] <DonDiego> 1024-bit DSA key, ID 4757FCC5, created 2007-07-14 [16:49:21] <siretart`> sure. because gpg is including a timestamp [16:49:40] <DonDiego> that *does* make a bit of sense :) [16:50:02] <siretart`> so that you can very *when* a signature has been made [16:53:15] <BBB> PS thanks for doing the release guys! [16:53:20] <BBB> I hope you'll do 0.6 also [16:53:35] <siretart`> we will! [16:53:49] <BBB> (SFLC suggests we do a release every once in a while because it makes registration and defense of copyrights easier, apparently) [16:54:06] <mru> registration of copyrights? [16:54:16] <mru> didn't that go away with the Berne convention? [16:54:26] <BBB> not in the US, apparently [16:54:40] <mru> but they signed it, belatedly, right? [16:54:50] <mru> like 50 years after everybody else... [16:54:58] <peloverde> in the US registration has an impact in the damages calculation [16:55:01] * BBB no lawyer yo [16:55:17] <peloverde> but yes the US signed it [16:55:34] <mru> I trust your lawyers if they say it helps, I'm just a bit surprised [16:56:07] <kierank> can't you register copyright officially somewhere as well [16:56:20] <BBB> yes, that's exactly what I do [16:56:23] <BBB> US copyright office [16:56:31] <BBB> or, well, they do it for me [16:56:52] <BBB> one of the field entries is "first release code appeared in" [16:57:02] <BBB> I tend to provide a SVN revision, but they want an actual FFmpeg release also [16:57:14] <DonDiego> http://www.ffmpeg.org/releases/ [16:57:20] <DonDiego> siretart`: sign that stuff [16:57:31] <DonDiego> siretart`: do you want me to make a gz tarball of 0.5 as well? [16:57:33] <mru> can't every svn rev be considered a release for copyright purposes? [16:57:42] <BBB> mru: I think so [16:57:48] <BBB> but that hasn't been tested in court [16:57:56] <BBB> so better be conservative and provide as much info as possible [16:58:00] <mru> we even publish tarballs [16:58:08] <DonDiego> BBB: the idea is to make releases every once in a while now [16:58:12] <DonDiego> yearly or so [16:58:12] <CIA-92> ffmpeg: michael * r22148 /trunk/tests/ (copy.regression.ref copycooker.sh): Codec copy test. [16:58:16] <BBB> that would be cool [16:58:53] <DonDiego> i'm very happy about the help and cooperation i got from siretart, let's see how the rest of the team likes us handling 0.6 [16:59:16] <BBB> will you freeze SVN? :-p [16:59:23] <DonDiego> we'll see [16:59:28] <DonDiego> not very long in any case [16:59:37] <DonDiego> the problem with the freeze was the followind IMO: [16:59:38] <peloverde> Bah, I'm already gearing up for 0.7 [16:59:52] <DonDiego> there, i don't need to explain it [16:59:54] <DonDiego> :) [17:00:22] <DonDiego> the idea of a freeze is that everybody puts their stuff aside for a moment and *helps* with bug fixing and release work [17:00:29] <DonDiego> instead [17:00:44] <BBB> that's like saying "let's all put our stuff aside and optimize h264" [17:00:52] <BBB> not all of us are good at it, or interested in it [17:01:05] <DonDiego> people twiddled their thumbs and kept working on their private stuff to be integrated after the release [17:01:07] <BBB> theoretically speaking [17:01:31] <DonDiego> there are enough competent devs that could help [17:01:36] <DonDiego> they just chose not to [17:02:44] <siretart`> that problem is not specific to ffmpeg, and I feel that other projects handle that problem better [17:03:00] <DonDiego> motivating people is difficult [17:03:53] <BBB> that might not be that bad... [17:03:58] <DonDiego> i'm all ears if somebody has suggestions how to do this better [17:04:04] <BBB> most projects have a lack of people competent at coding [17:04:14] <BBB> I think this is one of the few projects that does not have that problem [17:04:22] <DonDiego> we have other problems [17:04:27] <BBB> to be lacking in people competent at release management might be considered a luxury problem [17:04:32] <DonDiego> we are not exactly strong in the diversity area [17:04:40] <DonDiego> improving, but not strong [17:04:41] <BBB> true... well, we can fix that [17:04:51] <DonDiego> and diversity is not appreciated sufficiently [17:05:04] <BBB> siretart appears a great catch as of lately :) [17:05:09] <DonDiego> yes [17:05:22] <DonDiego> as is stefano for example [17:05:23] <DonDiego> and you [17:05:28] <jai> hmm, a codec copy test, has it been tested on all archs? [17:05:37] <mru> obviously not [17:05:37] <DonDiego> but for example [17:05:39] <mru> it doesn't work [17:05:53] * BBB needs to learn more about video coding before he's useful [17:06:01] <BBB> I still don't understand how FFT works also [17:06:17] <jai> mru: right, thought so [17:06:22] <jai> ah, saw your mail [17:06:23] <DonDiego> if you measure the time i spent on this project, i get much less comparative appreciation than others that did other types of tasks [17:06:37] <DonDiego> BBB: i disagree completely [17:06:39] <BBB> DonDiego: true... so the problem there is exactly as you said [17:07:01] <DonDiego> we have plenty of hardcore coders [17:07:32] <BBB> anyway, you're asking a former autotools lover to appreciate your (and mru's) custom-made configure script... I'm not sure if I'm ready to surrender yet :) [17:07:38] <BBB> it is faster though :) [17:07:49] <mru> and more maintainable [17:07:51] <DonDiego> it's like a football team: you don't get stronger by getting another world-class striker, you need to have defenders as well [17:07:58] <mru> and does a lot more stuff [17:08:06] <BBB> haha :) [17:08:09] <DonDiego> well, the comparison breaks apart in several aspects, but you get my point.. [17:08:22] <siretart`> mru: you can do anything with m4 as well ;-) [17:08:33] <siretart`> painful, but should work. [17:08:41] <mru> not really [17:08:46] <mru> m4 is a macro language [17:08:51] <mru> you can't do loops and recursion [17:08:53] <DonDiego> BBB: well, i made a point of merging all the useful stuff you did in your build system fork :) [17:09:30] <siretart`> mru: http://www.gnu.org/software/m4/manual/m4.html#Conditionals - 6 Conditionals, loops, and recursion :-) [17:09:39] <DonDiego> 18:06 <@BBB> DonDiego: true... so the problem there is exactly as you said [17:09:49] <DonDiego> BBB: what were you answering there exactly? [17:09:54] <mru> siretart`: that's only static loops and recurstion [17:09:56] <mru> -t [17:10:05] <siretart`> yes [17:10:09] <mru> i.e. completely expanded by the preprocessor [17:10:19] <DonDiego> siretart`: please sign the tarballs :) [17:10:22] <mru> ffconf has runtime-decided loops and recursion [17:10:42] <mru> recursion in sh is a bit painful [17:10:45] <siretart`> aah, there they are [17:12:02] <drv> hm, use of AVFrame.reference in most codecs seem completely contrary to what the doxygen in avcodec.h says [17:12:29] <DonDiego> mru: https://roundup.ffmpeg.org/msg9596 <-- do you have an opinion? [17:12:31] <BBB> dondiego: that some stuff is not appreciated [17:13:20] <BBB> anyway, I agree most useful stuff in my auto* patches was merged [17:13:32] <CIA-92> ffmpeg: cehoyos * r22149 /trunk/libavcodec/h263dec.c: [17:13:32] <CIA-92> ffmpeg: Pass correct buffer-pointer and buffer-size to hardware accelerated [17:13:32] <CIA-92> ffmpeg: decoders when decoding packed B-frames. [17:13:46] <BBB> what's left is basically Makefile.am/configure.ac itself, and that's really just a matter of opinion. I agree it should not have been merged, it would have made the build considerably slower [17:14:05] <BBB> but hey, I'm still an auto* junkie :) [17:14:09] <mru> DonDiego: might as well, bsd ain't fixing it [17:14:41] <janneg> xbmc's autotool generated configure ran 7m22s on my atom [17:15:25] <siretart`> DonDiego: mailed [17:16:08] <DonDiego> now that i practically maintain the build for a project and half at work with autotools [17:16:29] <DonDiego> i agree that autotools can work much better than it is used in most cases [17:16:40] <DonDiego> i.e. people do horrible things to it [17:17:02] <DonDiego> they just don't understand build systems at all, or declarative programming with make [17:17:17] <CIA-92> ffmpeg: michael * r22150 /trunk/tests/ (copy.regression.ref copycooker.sh): Make sure we dont double test files and sort the list. [17:17:24] <DonDiego> i cleaned stuff up enormously [17:17:38] <DonDiego> but autotools are still horribly broken [17:17:54] <DonDiego> doing your own stuff is much too hard [17:18:21] <DonDiego> and the multiple indirection levels through all the different tools of the toolchain is just braindead [17:18:44] <DonDiego> it also prevents useful error messages [17:19:57] <DonDiego> the tools do not complain about your change to, say, configure.ac, but about some configure code that was generated through two layers of indirection and is difficult to associate to any particular change at the high level you operate on.. [17:21:15] <drv> autoconf-generated configure is quite fun to read too - a million lines of workarounds for obscure shells [17:21:23] <Kovensky> lolautoconf [17:21:40] <Kovensky> there's one good thing about using autotools though: a very well-known interface for the end users [17:21:44] <Kovensky> but... it's a trap :X [17:21:58] <DonDiego> and that's another point: braindead defaults - 1980s proprietary unix systems are assumed [17:22:06] <DonDiego> it's missing a --assume-sane-system [17:22:07] <siretart`> DonDiego: did you receive my mail? [17:22:24] <DonDiego> or --disable-checking-for-stuff-everybody-fixed-before-1991 [17:23:33] <mru> there's no point supporting those fossilised systems if you rely on *anything* modern anyway [17:23:42] <DonDiego> siretart`: yes, integrating them right now [17:23:43] <mru> and just about everything does [17:26:22] <DonDiego> siretart`: signatures integrated, please doublecheck [17:27:33] <siretart`> both signature match for me [17:30:00] <CIA-92> ffmpeg: michael * r22151 /trunk/tests/ (seek-regression.sh seek.regression.ref): [17:30:00] <CIA-92> ffmpeg: Remove the self reference in the seektest that prevented it from [17:30:00] <CIA-92> ffmpeg: testing new formats since 2 years namely r11831. [17:30:00] <CIA-92> ffmpeg: This likely will uncover bugs that gone unnoticed in the last 2 years [17:30:00] <CIA-92> ffmpeg: due to lack of testing. [17:30:25] <siretart`> uuh, sounds scary [17:35:03] <jai> lets see what happens to fate [17:35:33] <jai> also mxf regtest fail with gcc svn?? [17:35:36] <siretart`> grep: tests/ref/{acodec,lavf,vsynth1}/*: No such file or directory [17:35:53] <mru> michael shouldn't be writing shell scripts [17:36:21] <siretart`> oh, that might be my /bin/sh -> /bin/dash symlink? [17:36:56] <astrange> jai: what arch and configure flags? [17:37:19] <jai> astrange: http://fate.multimedia.cx/index.php?build_record=192490 [17:37:34] <jai> astrange: tl;dr arch == x86-32 [17:37:54] <jai> astrange: and usual fate configure flags [17:38:23] <jai> would have tried here but i dont want to waste time building gcc from svn [17:38:59] <jai> is there any way i could get the full stderr [17:39:22] <astrange> i can build it [17:40:01] <jai> astrange: cool, could you paste the full output if possible [17:45:51] <DonDiego> hrmpf [17:46:02] <DonDiego> where is rob when you need him? [17:46:04] <DonDiego> :) [17:46:07] <siretart`> ? [17:46:11] <DonDiego> http://www1.mplayerhq.hu/~diego/index.html#release_0.5.1 [17:46:28] <DonDiego> please review the text, something was still confusing.. [17:46:46] <DonDiego> i need rob to fix the heading colors.. [17:47:41] <jai> fate is going yellow now.. [17:47:53] <mru> oh no... [17:47:57] <astrange> text is fine (i always thought it was "SNOW" instead of "Snow") [17:48:28] <jai> also, as i said earlier, MOV/MP4 is better [17:51:22] <CIA-92> ffmpeg: mru * r22152 /trunk/tests/ (seek-regression.sh seek.regression.ref): [17:51:22] <CIA-92> ffmpeg: Revert "Remove the self reference in the seektest that prevented it from" [17:51:22] <CIA-92> ffmpeg: This reverts r22151. It prevents the seektest from running at all and [17:51:22] <CIA-92> ffmpeg: is thus of no use whatsoever. [17:51:55] <DonDiego> jai: open your eyes :) [17:51:59] <Dark_Shikari> lol [17:52:12] <jai> DonDiego: sorry, i should have refreshed :| [17:52:15] <jai> DonDiego: thx [17:53:29] <siretart`> DonDiego: add "Please note that this is a maintenance only release; no new codecs, formats or other feature are being introduced" to the first paragraph [17:57:27] <DonDiego> done [17:57:43] <DonDiego> somebody complained about the last paragraph being unclear [17:57:47] <DonDiego> BBB: please elaborate [17:58:11] <BBB> it could be interpreted as "you have to recompile" == "abi changed" [17:58:21] <Dark_Shikari> Should make a comment about how there _are_ new codecs [17:58:23] <BBB> but that could just be me [17:58:26] <Dark_Shikari> and a short list of the most notable ones [17:58:34] <Dark_Shikari> but that if you want them before 0.6, you have to use svn. [17:58:42] <Dark_Shikari> (Bink, Indeo 5, etc, etc) [17:58:43] <BBB> Dark_Shikari: check the entry below [17:58:47] <siretart`> BBB: well, the ABI has changed by introducing symbol versioning. you have to recompile, but not at once. [17:58:56] <Dark_Shikari> ah k [17:59:13] <BBB> so say "abi/api-compatible with 0.5" [17:59:14] <BBB> or so [17:59:34] <BBB> just to make it clear and have no freetards quote that to make their mistaken point that "ffmpeg sux0rs" [17:59:56] <BBB> but again, that's just me, I might be too negative in interpreting it [18:00:43] <siretart`> how about prepending "While this release is both API and ABI compatible with 0.5, please note that..."? [18:00:51] <siretart`> to the last sentence? [18:01:15] <BBB> that would be great [18:01:26] <DonDiego> can't they just recompile against 0.6? [18:01:41] * DonDiego hasn't been following that stuff too closely.. [18:01:54] <siretart`> that may or may not work. 0.6 may introduce API changes [18:02:14] <siretart`> in fact, avutil has bumped soname, which was the reason for the symbol versioning stunt [18:03:39] <DonDiego> reload [18:03:52] <DonDiego> see if that is clear enough.. [18:05:12] <siretart`> dondiego: prepend "While this release is both API and ABI compatible with 0.5, please note that..." before the very last sentence [18:05:55] <DonDiego> to the sentence i just changed? [18:05:57] <jai> whoa, 137 people in #ffmpeg [18:06:32] <DonDiego> releases draw crowds .. [18:06:41] <DonDiego> or is it because of my birthday? [18:06:53] * DonDiego waves at the crowd [18:07:00] <jai> yeah! [18:07:10] <jai> DonDiego: sadly no females [18:07:13] <siretart`> DonDiego: yes, BBB's point was to clarify that the change didn't break API/ABI [18:07:23] <jai> girls love vlc [18:07:25] * jai hides [18:07:46] <DonDiego> well, then they love ffmpeg devs, we power vlc after all ;) [18:07:46] <siretart`> girls love working players [18:08:15] <DonDiego> we'll have to make yvonne a committer eventually :) [18:08:23] <jai> girls dont know about my mplayer+fbdev :) [18:09:06] <DonDiego> ok, reload [18:09:09] <DonDiego> should be fine now [18:10:58] <siretart`> last sentence: "...recompile applications against 0.5.1 in order to make seamless upgrades to 0.6 becomes" [18:11:13] <astrange> the mxf regression test passed with gcc svn/darwin/i386 for me [18:11:25] <BBB> DonDiego: siretart: this sentence is great, thanks [18:11:44] <DonDiego> oops, double "that" :) [18:12:10] <jai> astrange: same ./configure as fate? [18:12:17] <siretart`> last sentence: "...recompile applications against 0.5.1 in order to make seamless upgrades to 0.6 possible" [18:12:18] <siretart`> even [18:12:31] <siretart`> wife just got home :-) [18:13:01] <DonDiego> http://www1.mplayerhq.hu/~diego/index.html#release_0.5.1 [18:13:05] <DonDiego> ok, i'm done [18:13:21] <DonDiego> change incorporated [18:13:24] <siretart`> sounds excellent to me! [18:13:28] <DonDiego> this sounds perfect :) [18:13:41] <DonDiego> i commit in two minutes or so [18:14:28] <astrange> only mostly the same [18:14:42] <DonDiego> ? [18:15:46] <jai> astrange: hmm, weird [18:18:18] <jai> could we get mike to rerun with V-2 or sth [18:18:19] * DonDiego goes for the leftover bottle of wine from yesterday [18:18:32] <jai> *V=2 [18:23:42] <astrange> i386+--enable-shared build failed [18:23:46] <astrange> /Users/astrange/Projects/video/ffmpeg/libswscale/rgb2rgb_template.c:141:9: error: can't find a register in class 'GENERAL_REGS' while reloading 'asm' [18:27:14] <jai> meh :/ [18:27:50] <jai> gcc -fsuck-less perhaps [18:27:50] <siretart`> DonDiego: dont forget to commit the website! :-) [18:33:39] * DonDiego watches CIA and raises his glass [18:34:38] * jai kicks CIA-92 [18:34:38] <CIA-92> ow [18:34:43] <DonDiego> lol [18:34:53] * DonDiego kicks CIA-92 again [18:34:59] * DonDiego kicks CIA-92 [18:34:59] <CIA-92> ow [18:35:48] <siretart`> \o/ [18:35:59] <siretart`> DonDiego: have a great party! [18:36:22] <DonDiego> party was yesterday [18:36:43] <DonDiego> but i'm getting dinner cooked by two pretty girls :) [18:36:54] <jai> O_O [18:37:06] <DonDiego> siretart`: spend a nice evening with your wife, you earned it! [18:37:07] <mru> bah, /me gets that all the time [18:37:16] <DonDiego> you wish :) [18:37:45] <BBB> is it me or is the release name of 0.5 and 0.5.1 the same? [18:38:08] <DonDiego> let's face it, nobody lives as good as ffmpeg release managers ... [18:38:23] <DonDiego> BBB: it is, let's just assume the branch has that name :) [18:38:56] <BBB> dondiego has yet to elaborate on who these two pretty girls are [18:39:10] <DonDiego> haha :) [18:39:40] <DonDiego> nena and valentina, german and italian :) [18:39:47] <jai> pics or it didnt happen [18:39:53] <jai> oh wait, this isnt 4chan [18:39:58] <mru> there are pretty german girls? [18:39:59] * mru ducks [18:41:55] <DonDiego> mru: you know nena, actually, she is my flatmate [18:44:00] * KotH makes a mental note to visit DonDiego and check the situation [18:44:54] <BBB> koth: account? [18:45:30] <BBB> (for foundation website) [18:45:39] <KotH> BBB: CH06 0023 0230 2967 2740K [18:45:45] <KotH> BBB: please only large amounts ;) [18:45:55] <KotH> oh.. [18:45:58] * KotH blames DonDiego [18:45:59] <BBB> *grin* [18:46:14] <kierank> swiss bank account, nice [18:46:18] <Dark_Shikari> so where is our CIA-92 [18:46:29] <BBB> if you send me invoices, I can reimburse you for the ff* websites [18:46:38] <KotH> lol [18:46:51] <BBB> add soem dummy charges for high traffic and downloads [18:46:57] <BBB> don't forget to make it look real [18:47:01] <BBB> I'm sure that works [18:47:04] * KotH can do that [18:47:10] <BBB> also, make up a domain hosting company name and logo [18:47:13] <BBB> that way it looks better [18:49:25] <KotH> actually, i'm looking for someone to finance a machine+hosting for various smallish OSS projects [18:49:46] * KotH wouldnt mind to get a few bucks for that ;) [18:50:15] <BBB> I'll see how quickly money flows in :) [18:52:02] <astrange> hmm rgb2rgb does look difficult to compile under pic [18:52:06] <astrange> it doesn't use mangle [20:52:37] <Dark_Shikari> Yuvi: better finish the faster theora before 0.6 release ;) [21:28:53] <Kovensky> http://arstechnica.com/apple/news/2010/03/apples-itc-complaint-names-htc-ph… [21:29:12] <Kovensky> # 6343263: Real-Time Signal Processing System for Serially Transmitted Data <-- so, they patented the decoding of streamed audio / video? [21:29:46] <Dark_Shikari> Kovensky: read the claims, not the title [21:29:53] <Kovensky> ic [21:30:25] <Kovensky> because those titles are so generic I doubt they're even patentable [21:30:25] <Kovensky> lol [21:33:20] <CIA-92> ffmpeg: vitor * r22153 /trunk/libavformat/r3d.c: Plug some memory leaks for truncated files [21:33:20] <CIA-92> ffmpeg: vitor * r22154 /trunk/libavformat/mtv.c: Plug memory leak for truncated files [21:42:55] <CIA-92> ffmpeg: mru * r22155 /trunk/tests/ (126 files in 5 dirs): Place regression test output files in subdirs per family [21:42:55] <CIA-92> ffmpeg: mru * r22156 /trunk/ (Makefile tests/regression-funcs.sh): Remove unused argument to test scripts [21:59:55] <CIA-92> ffmpeg: mru * r22157 /trunk/tests/ (ref/lavf/pixfmt lavf-regression.sh): [21:59:55] <CIA-92> ffmpeg: Place regtest-pixfmt output files in separate dir [21:59:55] <CIA-92> ffmpeg: This test generates many output files, and keeping them separate [21:59:55] <CIA-92> ffmpeg: is convenient. [21:59:56] <CIA-92> ffmpeg: mru * r22158 /trunk/ (116 files in 4 dirs): Run seektest on all generated files [21:59:57] <CIA-92> ffmpeg: mru * r22159 /trunk/tests/seek-regression.sh: Make seektest messages similar to other tests [22:00:34] <mru> there, that should work much better [22:21:19] <BBB> MrNaz: ping [22:25:13] <j-b> good evening, people from earth ! [22:31:53] <BBB> hey j-b [22:32:02] <BBB> j-b: is someone from the vlc team good at making websites? [22:33:38] <j-b> BBB: mouahha [22:33:44] <j-b> BBB: what to do ? [22:33:50] <BBB> foundation website [22:34:10] <j-b> ffmpeg.org is not good ? [22:34:43] <j-b> BBB: we are in the process of rewriting our website [22:34:50] <BBB> ffmpeg.org is for project [22:34:54] <BBB> I need the foundation website [22:34:58] <BBB> ffmtech.org [22:43:22] <BBB> I like the videolan website, particularly the "donate now" button :) [23:00:45] <janneg> mru: can I grab the rendered BBB frames somewhere? [23:10:19] <mru> janneg: it only managed 5 frames before the machine died [23:10:26] <mru> died as in not booting [23:10:40] <mru> might have overheated or something [23:10:52] <mru> it's been cooling off for a while, I'll try it again [23:12:13] * mru just found out someone's trying to shift 10 24core/64GB servers [23:12:16] <mru> janneg: interested? [23:14:19] <janneg> sure [23:14:35] <mru> 50kSEK interested? :-) [23:14:41] <mru> each [23:15:21] <janneg> not that [23:15:26] <janneg> interested [23:15:31] <mru> heh [23:27:40] <MrNaz> doh [23:27:43] <MrNaz> i missed BBB

1 0

IRC log for 2010-03-01
by irc＠mansr.com 02 Mar '10

02 Mar '10

[00:19:38] <iive> hum this change sounds .. fast. [00:23:34] <CIA-92> ffmpeg: aurel * r22125 /trunk/libavcodec/h264.c: revert r22112 which broke playback of cathedral-beta2-400extra-crop-avc.mp4 [00:26:30] <drv> heh, that sample plays totally wrong in win7 media player [02:22:58] <pentanol> hi anybody alive here? [02:24:27] <mfg> yes, but I dont count. [02:24:30] <pentanol> in sample avformat app I've seen fill_yuv_image() that do pictide on a screen? or where it output a stream? [02:26:18] <pentanol> also I've seen AVInputStream\AVOutputStream in ffmpeg.c source, but there function used in more low level obstraction.. [02:27:37] <pentanol> in output-example.c it looks lire read a file and then output, but don't even undertand where... [02:27:49] <pentanol> where that do output a stream? [07:23:49] <CIA-92> ffmpeg: benoit * r22126 /trunk/ffmpeg.c: [07:23:49] <CIA-92> ffmpeg: ffmpeg: copy stream metadata. [07:23:49] <CIA-92> ffmpeg: Patch by Anton Khirnov wyskasgmailcom [07:27:35] <CIA-92> ffmpeg: benoit * r22127 /trunk/libavformat/nutdec.c: [07:27:35] <CIA-92> ffmpeg: nutdec: make chapter start and length uint64_t to prevent overflows. [07:27:35] <CIA-92> ffmpeg: Patch by Anton Khirnov wyskas chez gmail punto com [09:16:09] <siretart> god morgon [09:17:44] <DonDiego> what language was that? [09:17:51] <thresh> moroning [09:18:07] <DonDiego> who are you calling a moron? [09:18:08] <DonDiego> ;) [09:19:09] <siretart> heh [09:19:47] <kshishkov> DonDiego: varför vet du inte svenska? [09:20:08] <DonDiego> ja nje gavariu po ruski [09:20:30] <kshishkov> but I was asking about Swedish, so that's not a reason [09:21:26] <kshishkov> FYI all of Swedish-British section of FFmpeg devs know what does "god morgon" mean [09:21:45] <thresh> even I do [09:21:57] <twnqx> i guess the german section can guess >_> [09:24:30] <kshishkov> I think it's the same story as with Russian language - while other languages from the same family evolved (and became a bit simpler), German/Russian remains the same beast and its speakers hardly can understand any other language [09:24:52] <kshishkov> (while others can understand each other quite well) [09:25:25] <elenril> dobré ráno? [09:25:50] <kshishkov> in Ukrainian that would be "dobriy ranok" [09:25:59] <twnqx> nah, i think dutch and swedish are borderline understandable [09:27:37] <kshishkov> try Danish then [09:27:44] <elenril> kshishkov: yeah, languages are like codecs [09:28:11] <twnqx> danish as well [09:28:17] <twnqx> when reading, at least [09:28:33] <twnqx> but needs context [09:29:06] <kshishkov> elenril: yeah, ineffective and mostly incomprehensible as well [09:30:48] * elenril thinks russian would correspond to mpeg4 [09:31:01] <kshishkov> msmpeg4 [09:31:17] <elenril> meh, that would be one of its ripoffs [09:31:27] <elenril> like ukrainian ;) [09:31:28] * elenril runs [09:32:41] * kshishkov reminds elenril that in times of Kievan Rus the place where certain city stands was called "Moscow Ukraine" [09:33:26] * elenril knows, hence the ;) [09:35:57] * elenril sighs [09:36:12] <elenril> michael wants me to write nice, general and extensible things again [09:36:26] <kshishkov> and that's against your nature? [09:36:29] <elenril> and i was so looking forward to just hacking it together somehow [09:36:32] <elenril> yeah, exactly [09:44:07] <mister_electroni> hola alguten ahi [09:44:32] <mister_electroni> hello [09:44:43] <kshishkov> that's better [09:44:57] <kshishkov> (unless you want to talk to DonDiego only) [09:45:19] <mister_electroni> No I like talk with everybody... [09:45:38] <mister_electroni> My english is no so good.... [09:47:04] <mister_electroni> I am looking to capture video with ffmpeg. [09:47:30] <mister_electroni> but still I don't know how to do... [09:47:54] <mister_electroni> someone help me? [09:48:11] <DonDiego> mister_electroni: ask in #ffmpeg [09:48:33] <mister_electroni> ok thanks and sorry.... [10:09:05] <pentanol> where output-example.c source output a stream? it looks like read audio and video from a file and then... [11:10:30] <siretart`> DonDiego: what's the status on 0.5.1? [11:11:32] <DonDiego> i'm on the phone right now [11:11:39] <DonDiego> let's do it in a few minute [11:11:39] <DonDiego> s [11:11:48] <siretart`> sure [11:12:37] <bilboed-pi> is 0.5.1 the same as 0.5.0 with only security fixes ? [11:12:44] <kshishkov> yes [11:12:58] <merbzt> and updated x264 interface [11:14:23] <merbzt> Vitor1001: we need to update the news on the homepage [11:14:46] <Vitor1001> merbzt: I agree. I think AMR deserves a mention. [11:14:47] <kshishkov> yes, AMR-NB decoder is worth mentioning [11:14:48] <DonDiego> bilboed-pi: and a few porting/packaging/license upgrades :9 [11:15:08] <merbzt> not indeo5 ? [11:15:11] <DonDiego> Vitor1001: then go for it right away before we make the release [11:15:18] <DonDiego> mention both [11:15:18] <merbzt> we have looots of news [11:15:34] <Vitor1001> I'm at work now, someone else volunteers? [11:15:42] <kshishkov> merbzt: it's useless as Bink [11:16:03] <Vitor1001> Bink also deserves a mention, like wmavoice [11:16:06] <merbzt> kshishkov: :) [11:16:12] <Vitor1001> and indeo [11:16:25] <Vitor1001> and sipr [11:16:43] <DonDiego> would someone please step forward and write a news update for all the new stuff? [11:16:46] <merbzt> and rtp work [11:16:48] <siretart`> bilboed-pi: kshishkov: and added symbol versioning! [11:16:51] <Vitor1001> But we'll have to do it again once we have HE-AAc ;) [11:17:08] <merbzt> and GSoC [11:17:17] <kshishkov> someone should RE Indeo Audio to close Intel stack of codecs along with the ones from Buffering Inc. [11:17:42] <siretart`> oh, and 0.5.1 comes with an LGPL'ed libswscale [11:17:55] <bilboed-pi> siretart, libswscale is finally entirely LGPL'ed ? [11:18:08] <siretart`> that's not what I said [11:18:09] <merbzt> C version [11:18:10] <kshishkov> bilboed-pi: it's usable [11:18:22] <bilboed-pi> oh ok, so it's still dogslow in LGPL [11:18:37] <kshishkov> 0.5.0 stuck with imgconvert which was even slower I think [11:19:52] <siretart`> DonDiego: and we should make it clear that 0.5.1 will be the only upgrade path to 0.6 for users that don't want or cannot recompile applications [11:20:09] <DonDiego> what do you mean by "only upgrade path"? [11:20:33] <kshishkov> no future 0.5.x releases [11:20:34] <DonDiego> and hold off, i'm writing the news entry while you guys keep up the random chatter [11:20:43] <siretart`> if you replace libavcodec52 from 0.5 with libavcodec52 from 0.6, the applications will randomly crash [11:20:48] <siretart`> this won't happen with 0.5.1 [11:26:56] <DonDiego> i will commit the following now: [11:27:00] <DonDiego> "We have been busy over the past few months. The results are new decoders for Indeo 5 and Bink video as well as AMR-NB, Sipr, Bink, MPEG-4 ALS and WMA Voice audio, an RTSP muxer, Bluray (PGS) subtitle support and the ffprobe tool for extracting information from multimedia files." [11:27:05] <DonDiego> anything missing? [11:27:19] <kshishkov> Sipro [11:27:27] <kshishkov> not Sipr [11:27:41] <kshishkov> also mention Bink only once [11:28:14] <kshishkov> also you have Changelog [11:28:51] <iive> kshishkov: is there bink audio? [11:29:08] <kshishkov> iive: yes, two of them [11:29:40] <iive> that's why bink appears twice, once for video and twice for audio. [11:30:01] <kshishkov> should be thrice then [11:30:30] <kshishkov> still, ILBM, CDG and concat protocol are worth mentioning, especially the latter [11:31:13] <iive> is aac sbr is svn already? [11:31:21] <DonDiego> no [11:32:06] <DonDiego> what is the concat protocol? [11:32:22] <DonDiego> finally ffmpeg can concatenate files? [11:32:34] <kshishkov> probably yes, never tried though [11:33:41] <pentanol> hello, could some one point me? there this snuppet output-example.c output a stream? on a screen? [11:34:13] <kshishkov> no, we have ffplay.c for outputting streams on a screen [11:34:24] <pentanol> I see [11:34:50] <pentanol> but where those snippet output it? [11:35:07] <pentanol> input liiks like from a file [11:35:12] <pentanol> looks* [11:35:39] <DonDiego> kshishkov: what is CDG and ILBM [11:35:40] <DonDiego> ? [11:36:02] <kshishkov> CD+g video format for karaoke mostly [11:36:32] <kshishkov> and if you don't know about image format ILBM then you had no Amiga nor even heard of Deluxe Paint [11:38:31] <DonDiego> k, how about [11:38:34] <DonDiego> "We have been busy over the past few months. Among other things, the [11:38:35] <DonDiego> results are an Indeo 5 video decoder as well as audio decoders for [11:38:35] <DonDiego> AMR-NB, Sipro, MPEG-4 ALS and WMA Voice, complete support for Bink, [11:38:35] <DonDiego> CDG and IFF PBM/ILBM bitmaps, an RTSP muxer, Bluray (PGS) subtitle [11:38:35] <DonDiego> support, a protocol for file concatenation and the ffprobe tool for [11:38:36] <DonDiego> extracting information from multimedia files." [11:40:01] <kshishkov> Some of us were busy, others were lazy. [11:40:48] <pentanol> hm, no one knows where output-example.c output a stream? [11:40:49] <kshishkov> and IIRC ffprobe was picked from some project at sourceforge [11:41:19] <pentanol> actually I need just encode\decode sample, this one quite well [11:41:41] <pentanol> but I still can't get it working [11:47:42] <pentanol> or there input and output in the same file? [11:58:53] <DonDiego> kshishkov: i think stefano is the author of ffprobe, dunno why he hosted it on sf [11:59:24] <DonDiego> anyway, committed [11:59:29] <kshishkov> good [12:18:44] <j-b> ruggles? [12:20:35] <kshishkov> unlikely [12:21:24] <KotH> pentanol: you are asking a user question in the development channel [12:21:29] <KotH> pentanol: please use #ffmpeg instead [12:21:57] <pentanol> but ther nobody knows it [12:22:08] <KotH> that is no excuse to ask here [12:22:24] <KotH> there is a reason why there is a strict seperation between user and developer channel [12:22:33] <kierank> it's like church and state [12:22:58] <KotH> (ie that the developers can discuss stuff w/o reading tons of irrelevant user questions that could be answered by reading the documentation or the code) [12:23:26] <siretart`> kierank: and which of the two are the developers? ;-) [12:23:34] <pentanol> it's not documenter [12:23:41] <pentanol> documented* [12:24:44] <kshishkov> kierank: guess who is the both head of Church of England and Queen of Commonwealth states though? [12:25:29] <DonDiego> pentanol: your question remains offtopic, sorry [12:28:33] <merbzt> pentanol: ask on the libav list [13:09:49] <KotH> could someone enlighten me a bit on shell expansion? i cannot find a solution in the docs [13:10:15] <KotH> i have a variable A='a b c "d e" f', which i pass to function [13:10:29] <KotH> there it gets asigned to B=$1 [13:10:52] <KotH> set +x tells, me that the assignemt is executed as B='a b c "d e" f' [13:11:18] <KotH> now i use B as a parameter to a command: blah $B [13:11:38] <KotH> but here the parametes get split as 'a' 'b' 'c' '"d' 'e"' 'f' [13:11:55] <kshishkov> try passing "$B" then [13:12:18] <KotH> already tried, then it gets passed as 'a b c "d e" f' [13:12:31] <KotH> instead of 'a' 'b' 'c' '"d e"' 'f' [13:14:46] <DonDiego> tricky stuff, experiment with IFS [13:15:29] <kshishkov> or use 'a b c d\te f' and substitute tab later if possible [13:16:55] <KotH> DonDiego: tried, doesnt work [13:17:08] <KotH> kshishkov: this approach has the same problem [13:18:17] <siretart`> KotH: can't you pass A='a b c d\ e f' to your function? [13:18:34] <KotH> siretart`: suffers from the same problem too [13:18:48] * KotH tried all the obvious ways already ^^' [13:19:02] <siretart`> and how about "a b c 'd e' f"? ;-) [13:20:41] <KotH> siretart`: same [13:20:50] <siretart`> ditch shell then ;-) [13:21:18] * KotH doesnt want to ^^' [13:21:32] <KotH> all the rest works just fine, it's just this little issue ^^' [13:22:04] * elenril would rewrite it in python [13:24:06] <siretart`> DonDiego: anything I can help you with regarding 0.5.1? [13:24:44] <DonDiego> remind me what still needs doing :) [13:24:59] <DonDiego> let me finish the news entry.. [13:28:18] <siretart`> do we want to amend the file RELEASE with changes in 0.5.1? [13:28:53] <DonDiego> yes, why not.. [14:12:00] <DonDiego> siretart`: what exactly did you want to add to the RELEASE file? [14:12:26] <siretart`> I pasted the diff yesterday, wait, I can repeat [14:13:19] <DonDiego> ah, found it, sorry [14:13:58] <siretart`> DonDiego: http://paste.debian.net/61975 [14:22:33] <DonDiego> hmm [14:22:47] <DonDiego> i feel we have a certain amount of duplication [14:23:01] <DonDiego> no scratch that, not really [14:23:15] <DonDiego> but there should be a bit more in the release notes [14:23:22] <DonDiego> license upgrade fixes [14:23:39] <DonDiego> not only upgrade, licensing-related in general [14:24:04] <DonDiego> also [14:24:19] <DonDiego> use "H.264" and "MLP" [14:31:24] <CIA-92> ffmpeg: diego * r22128 /trunk/doc/general.texi: [14:31:24] <CIA-92> ffmpeg: Fix AMR-NB entry in the supported audio codecs list. [14:31:24] <CIA-92> ffmpeg: The decoding and encoding rows were switched around. [14:36:35] <siretart`> DonDiego: the release notes are maintained where exactly? I thought the RELEASE file were the release notes... [14:42:17] <DonDiego> http://www1.mplayerhq.hu/~diego/index.html [14:42:25] <DonDiego> they are [14:47:12] <DonDiego> oh, i forgot the libx264 wrapper.. [14:48:18] <siretart`> and that symbol versioning is enabled now! [14:49:35] <DonDiego> that i mentioned.. [14:52:44] <siretart`> hm. "to help packagers" is a bit vague, we should make clear that distributors really should upgrade to 0.5.1 and rebuild their binaries as preparation step for 0.6 [14:53:19] <siretart`> applications that miss this step will cause horrible problems otherwise [14:54:08] <DonDiego> suggest a wording :) [14:54:59] <kshishkov> "merely for preserving ABI compatibility" [14:57:02] <siretart`> kshishkov: we are effectively changing ABI [14:57:11] <siretart`> so preserving is not exactly correct [14:57:16] <siretart`> how about this wording: [14:57:34] <siretart`> The backported symbol versioning change is enabled on platforms that support [14:57:34] <siretart`> it. This allows users to upgrade from 0.5.1 to the upcoming 0.6 release [14:57:34] <siretart`> without having to recompile their applications. Please note that distributors [14:57:35] <siretart`> have to recompile applications against 0.5.1 before upgrading to 0.6! [15:04:11] <DonDiego> ok, reload [15:07:15] <DonDiego> should be fine now [15:09:01] <DonDiego> anything left? [15:09:15] <DonDiego> i want to add us both as release managers to the MAINTAINERS file [15:09:22] <DonDiego> that's about it i think [15:09:39] <DonDiego> siretart`: will you commit that RELEASE file change? [15:10:11] <DonDiego> i need to run out for a moment to go shopping [15:10:26] <DonDiego> i'll be back in no more than an hour [15:26:50] * BBB hates xchat [15:26:57] <BBB> so if you have a tab completion, and want it to complete [15:26:59] <BBB> it turns yellow [15:27:04] <BBB> how do I make it actually complete? [15:27:18] <twnqx> Oo [15:27:20] <kshishkov> press it again? [15:27:30] <twnqx> it turns yellow? [15:27:36] <twnqx> never seen that happen [15:30:08] <KotH> you sure your xchat doesnt have hepatitis? [15:37:54] <BBB> kshishkov, I tried, then it actually inserts a tab (\t) [15:38:52] <kshishkov> BBB: Kahn axiom - if nothing helps, it's time to read that manual ;) [15:41:12] <mru> BBB: why don't you a proper irc client instead? [15:42:25] <BBB> I'm lazy and disinterested [15:42:39] <BBB> I think mac people don't use irc [15:42:46] <BBB> otherwise I'm sure there'd be something better than this [15:42:57] <mru> don't be a mac person then [15:43:17] <mru> doesn't irssi work on mac? [15:43:28] <Honoome_> there's macirssi [15:43:28] * kshishkov has used both XChat-aqua and Colloquy there, now stuck with irssi running in remote screen [15:43:51] <kshishkov> (never used autocompletion, so no problem here ;) [15:51:53] <BBB> can someone look at the audio clipping patch on the mailinglist? [15:52:12] <BBB> it's quite a nasty bug which causes some artifacts in decoding of wmavoice files (and possibly others) [16:13:24] <mru> BBB: fix the whole audioconvert madness instead [16:13:48] <kshishkov> s/fix/replace with something sane/ [16:15:23] <BBB> what do you have in mind? [16:15:32] <BBB> I doubt I would be able to come up with something that's better, honestly [16:15:41] <mru> something using simd [16:15:43] <kshishkov> liswscaler for audio [16:15:43] <BBB> although I'd write pix_fmt-style convert tables instead of this [16:15:51] <BBB> and then make each impl simd'able [16:16:01] <BBB> right, swscale for audio [16:16:05] <BBB> but that's a full soc project [16:16:08] <BBB> so no go right now [16:16:25] <kshishkov> you know, something to convert 5.1 48kHz to 2 ch 44.1 kHz without hassle [16:16:37] <BBB> kshishkov, go, go, go! [16:16:39] <BBB> I see a soc project [16:17:08] <kshishkov> okay, wiki awaits you [16:18:00] <BBB> who will mentor it? [16:18:27] <kshishkov> maybe Benajmin or Andreas [16:18:32] <kshishkov> *Benjamin [16:18:57] <kshishkov> or anybody who knows a thing about multichannel codecs [16:19:13] <kshishkov> and filters [16:19:15] <mru> BBB: does the wmavoice decoder output full -1.0--1.0 inclusive range? [16:19:34] <prupert> I think the #ffmpeg was the wrong place to ask this, so I am asking here: I have read that there are plans to add support for the Broadcom Crystal HD Hardware Decoder (BCM970012) to ffmpeg. Does anyone know if this will be purely for playback or are there plans to use it for transcoding to (so offloading some of the load from the CPU to the Decoder)? [16:20:28] <BBB> mru: yes [16:20:31] <janneg> prupert: playback is in the case of the crystal hd the same as decoding [16:20:38] <mru> BBB: that's your problem then [16:20:55] <BBB> mru: that's a feature, not a bug [16:21:04] <mru> can you make it output [-1.0, 1.0) in hideous maths notation? [16:21:25] <mru> or scale it by (1<<N)-1 instead [16:22:06] <mru> either of those is preferable [16:22:19] <BBB> [-1.0; 1.0) no [16:22:22] <mru> your patch still has clipping [16:22:23] <BBB> 1<<n-1: yes [16:22:36] <siretart`> DonDiego: done [16:22:37] <BBB> (1<<n)-1, I mean [16:22:41] <BBB> but that's not really right [16:22:53] <prupert> janneg: so, once support is added, it would make transcoding using fmpeg on the Intel Atom platform faster (or at the very least, less processor intensive)? [16:23:01] <BBB> mru: which do you prefer? [16:23:03] <mru> BBB: no, but it's better than clipping [16:23:06] <BBB> agreed [16:23:14] <janneg> prupert: yes [16:23:15] <BBB> the decoder internally clips overflows to 1.0 already [16:23:15] <CIA-92> ffmpeg: siretart * r22129 /branches/0.5/RELEASE: amend release notes for 0.5.1 [16:23:27] <BBB> so... it's not like we're clipping any less then [16:23:32] <BBB> the binary also clips [16:23:33] <prupert> awesome, thats great news, Imma off to eBay ;) thanks loads janneg [16:27:09] <BBB> mru: could you send some msgs to the mailinglist so we can discuss if others prefer the (1<<n)-1 over av_clip* use? [16:27:56] <kshishkov> BBB: due to filter nature you'd still have to use clipping I fear [16:28:40] <BBB> probably [16:28:46] <BBB> I didn't want to get into that discussion though [16:28:49] <BBB> my bug is simple [16:28:57] <BBB> 1.0*1<<n = 0x8000 [16:28:59] <BBB> which is -0x8000 [16:29:08] <mru> it's actually undefined [16:29:22] <mru> on some CPUs you get 0x7fff [16:29:27] <BBB> well, yeah [16:29:33] <BBB> but it happens to come down to 0x8000 here [16:29:36] <BBB> (as an int32) [16:29:43] <BBB> which clipped to int16 = -0x8000 [16:29:57] <BBB> that's my bug, I want that bug fixed [16:30:05] <BBB> I don't care much about the other filter-related bugs, yet [16:30:08] <BBB> that'll come later [16:30:13] <kshishkov> BBB: you probably won't encounter CPUs mru talked about in real life anymore [16:30:25] * mru looks at mips [16:30:44] <kshishkov> IIRC old Crays used 1-complement arithmetic but I saw one only in Technical Museum, Stockholm [16:30:52] <mru> that's not what I'm talking about [16:31:20] <mru> such a machine wouldn't have a problem at all [16:31:45] <kshishkov> it will have different problems though [16:31:46] <mru> the problem here is that the integer range is not symmetrical around zero [16:31:56] <kshishkov> you talked about overflow/saturation [16:32:08] <mru> converting 1.0*1<<31 to int is undefined [16:32:17] <mru> some CPUs wrap, some saturate [16:32:27] <mru> converting 1.0*1<<15 to int is always defined [16:32:57] <kshishkov> hmm, on 16-bit CPUs too? [16:33:22] <mru> they don't exist as far as we're concerned [16:33:36] <mru> nor do they have an FPU [16:33:43] <kshishkov> so no FFmpeg for my modem? [16:33:49] <BBB> ok, let's focus guys [16:33:55] <BBB> bug!!1122 [16:34:08] <mru> converting 1<<15 to int16_t is implementation-defined [16:34:27] <kshishkov> BBB: it's whole arithmetic is buggy. I'd suggest simply clipping result [16:34:27] <mru> meaning you can get anything, but the compiler has to document what happens [16:34:35] <BBB> kshishkov, my patch does that [16:34:39] <mru> slowly [16:48:37] <CIA-92> ffmpeg: cehoyos * r22130 /trunk/ffmpeg.c: [16:48:38] <CIA-92> ffmpeg: Don't let output pixel format influence input pixel format. [16:48:38] <CIA-92> ffmpeg: Patch by Chris Stones, chris D stones A gmail [16:53:23] <CIA-92> ffmpeg: cehoyos * r22131 /trunk/libavcodec/h263dec.c: Process packed bitstream also for VDPAU. [17:02:04] <gthreepwood> Hi all. I'm a computer science student currently doing a masters project on block matching algorithms. I want to create a varient of the MPEG-4 codec for testing purposes. I think ffmpeg is a great place to start and want to jump into the code right away. Does anyone have any tips on getting started? http://wiki.multimedia.cx/index.php?title=FFmpeg_codec_howto seems like a good starting point. [17:03:33] <BBB> gthreepwood, what do you want to do? [17:03:47] <BBB> if you want to modify the mpeg4 encoder/decoder, I'd suggest looking there [17:05:05] <gthreepwood> Okay, I'll have a look at that code. What do you think the easiest way will be for me to test the changes I make? Compile mplayer/mencoder against the modified libavcodec? [17:05:26] <jai> ffmpeg/ffplay [17:06:46] <siretart`> maybe ffprobe as well [17:08:56] <gthreepwood> I see, thanks. My changes will alter the structure of the encoded bitstream, does that complicate things or, as long as I modify both the encoder and decorder to support this change, will it be fine? [17:09:05] <jai> yes [17:10:38] <gthreepwood> Sorry, could you clarify your answer? [17:11:07] <BBB> he means it'll be fine [17:11:18] <BBB> mru: is float: inf/inf defined? [17:11:30] <BBB> or float: 0/0? [17:11:50] <mru> 0/0 == nan [17:12:52] <gthreepwood> Thanks. If you're interested, I'm looking at the effects of encoding the rotation of blocks as well as just their translation for motion compenstation. [17:13:15] <BBB> mru: ok, thanks [17:16:07] <mru> inf/inf is also nan [17:16:18] <mru> in ieee754 [17:20:57] <Dark_Shikari> gthreepwood: block matching algorithms? really? [17:21:03] <Dark_Shikari> that stuff has been beaten to death [17:21:13] <Dark_Shikari> also, if you want to work on motion estimation, pick a good encoder to start with [17:21:23] <mru> Dark_Shikari: exactly, more papers to plagiarise then [17:21:27] <gthreepwood> :) Any suggestions? [17:21:47] <Dark_Shikari> x264 obviously [17:22:07] <Dark_Shikari> but seriously, block-matching motion estimation has been beaten to death [17:22:22] <Dark_Shikari> no slow algorithm can possibly be better than sequential elimination [17:22:34] <Dark_Shikari> no ultra-fast algorithm can be much better than DIA, since x264's predictors are so overkill that even DIA is good [17:23:01] <Dark_Shikari> and in the middle, while there might be some gain to be had, the requirement that it must be SIMDable puts heavy restrictions on your options [17:23:21] <Dark_Shikari> the primary mistake I see people make is to test motion estimation algorithms in encoders with few or no predictors [17:23:28] <gthreepwood> I'm applying a new combinatorial rotation algorithm that is quite SIMDable [17:23:29] <Dark_Shikari> this tends to greatly inflate the benefit [17:23:36] <Dark_Shikari> don't use buzzwords, say what it actually does [17:23:39] <BBB> is this a science project? or corporate? [17:23:40] <Dark_Shikari> is it gradient descent? [17:24:04] <gthreepwood> no the algorithm just enumates all of the rotations for a block efficiently [17:24:42] <gthreepwood> BBB, a university project [17:24:44] <mru> Dark_Shikari: hadn't you noticed that academic projects always study either pie-in-the-sky or long-obsolete stuff, sometimes both [17:24:54] <Dark_Shikari> gthreepwood: oh, so it isn't a block-matching motion estimation project [17:24:56] * BBB kicks mru [17:25:08] <Dark_Shikari> you're writing a ROTATION-aware motion estimation algorithm [17:25:12] <Dark_Shikari> now _THAT_ is actually interesting [17:25:35] * BBB thinks Dark_Shikari isn't paying attention when he hears buzzwords [17:25:45] <Dark_Shikari> Now, you will have to find some way to signal the rotation amount in the bitstream, and you'll need to find a way to fill the holes created by rotation (e.g. on the corners) [17:26:10] <Dark_Shikari> and you will need to find a fast but good enough rotation interpolation algorithm so that the decoder doesn't get 5 times slower [17:26:12] <gthreepwood> Yes, all interesting problems :) [17:26:21] <Dark_Shikari> I've already designed a way to signal it in the bitstream though [17:26:22] <Dark_Shikari> it's trivial [17:26:43] <Dark_Shikari> with CABAC, here's how I'd do it: [17:26:53] <Dark_Shikari> 1) We start by assuming 0 degree rotation. [17:26:53] <mru> if pixels were triangular, we could use hexagonal blocks and rotations by pi/3 would leave no holes [17:27:22] <Dark_Shikari> 2) We get a bit. If the bit is 0, we stop, no rotation. If 1, we continue. [17:27:38] <Dark_Shikari> 3) We get a bit. If the bit is 0, we rotate by -90. If the bit is 1, we rotate by +90. [17:27:45] <Dark_Shikari> repeat, each time refining the rotation [17:27:50] <Dark_Shikari> so the next step, it'll go +/- 45 [17:27:54] <Dark_Shikari> then +/- 22.5 [17:27:57] <gthreepwood> I see, that's an interesting approach [17:28:05] <Dark_Shikari> thus the encoder can choose an arbitrary level of precision based on whatever is RD-optimal [17:28:13] <Dark_Shikari> and it simply writes an EOB bit at the end when it's done [17:28:20] <kshishkov> mru: "always study either pie-in-the-sky or long-obsolete stuff, sometimes both [17:28:22] <Dark_Shikari> and thanks to arithmetic coding, it's cheap. [17:28:26] <Dark_Shikari> Relatively. We hope. Maybe. [17:28:36] <kshishkov> mru: sounds like "academic study" definition [17:28:53] <Dark_Shikari> Though intuitively it seems as though it cannot actually code 180 degree rotations [17:28:58] <Dark_Shikari> thanks, Zeno's paradox [17:29:26] <gthreepwood> so you think I should be looking at modifying x264? I thought it might be a bit complex, although I haven't yet looked at the code [17:29:30] <Dark_Shikari> but anyways, if you wanted to do this in x264, you would need the following: [17:29:45] <Dark_Shikari> 1) Modify the motion compensation functions (x264_mb_mc and relatives) in common/macroblock.c [17:30:00] <Dark_Shikari> 2) Find some place in the macroblock cache to store the rotation of each block (h->mb.cache.rotation or something?) [17:30:09] <Dark_Shikari> I'd say that one rotation syntax element per partition is reasonable [17:30:17] <Dark_Shikari> so an 8x16 block would have two rotation syntax elements. [17:30:55] <Dark_Shikari> 3) Decide at what point you're going to do the rotation analysis and modify the motion search to consider it. [17:31:05] <Dark_Shikari> 4) Modify ffh264 decoder to do the same thing [17:31:54] <kshishkov> Dark_Shikari: does all that sounds to me only that "iterative systems" is the next logical step ;) [17:31:54] <Dark_Shikari> the primary reason I recommend x264, other than bias, is that nobody in this channel really understands any of the mpegvideo encoders in ffmpeg, especially not the motion estimation parts ;) [17:33:06] <gthreepwood> So the x264 code, that's in the separate x264 project, right? [17:33:21] <Dark_Shikari> yes [17:33:37] <gthreepwood> Thanks for your helpful comments [17:33:40] <kshishkov> decoder for it is still in FFmpeg though [17:34:01] <BBB> Dark_Shikari, nobody understands the decoder either :) [17:34:06] <Dark_Shikari> Yeah, but modifying encoders is much harder than changing decoders =p [17:34:10] <gthreepwood> If I have further questions relating to x264, where should I ask them? [17:34:12] <Dark_Shikari> since there's no analysis step [17:34:14] <Dark_Shikari> #x264dev [17:34:24] <Dark_Shikari> feel free to ask _anything_ [17:34:30] <Dark_Shikari> there are no stupid questions, only stupid people [17:35:01] <kshishkov> Dark_Shikari: but anime-related questions should be transferred to #mplayer-dev [17:35:24] <Dark_Shikari> no, #x264 [17:35:30] <Dark_Shikari> oh wait, that's _Touhou_ [17:35:35] <Dark_Shikari> yeah, anime goes to #mplayerdev [17:35:38] <kshishkov> my point exactly [17:37:09] <Dark_Shikari> But wait a minute... [17:37:11] <Dark_Shikari> what about a touhou anime...? [17:37:18] <kshishkov> not drawn yet [17:37:22] <Dark_Shikari> no, there is one [17:37:37] <Dark_Shikari> I use it for my 50kbps encoding tests [17:38:25] <jai> well, in that case cross-post to both channels [17:38:27] <jai> :) [17:38:41] <Dark_Shikari> gthreepwood: one more important thing to note; --dump-yuv in x264 dumps the internal state of the encoder to a file [17:38:48] <Dark_Shikari> this MUST match the output data from the decoder. [17:39:06] <Dark_Shikari> so whatever changes you make, the way to test that they worked is by doing that diff. [17:39:19] <Dark_Shikari> (also, cmp is generally better than diff for large yuvs) [17:39:49] <kshishkov> diff is not good for binary data anyway [17:40:45] <Dark_Shikari> last time I ran diff on yuvs, it ran out of memory [17:41:16] <kshishkov> maybe they were way > 50M [17:41:24] <jai> lol, roundup registration is broken? [17:41:27] <Dark_Shikari> 7GB each [17:41:39] <kshishkov> jai: could be [17:42:28] <jai> kshishkov: probably after the upgrade [17:42:32] <jai> lu_zero: ^^ [17:42:51] <kshishkov> jai: Luca has fixed something for ordinary user registration [17:43:16] <kshishkov> I remember somebody complained and was able to register later [17:43:19] <jai> if he doesnt care about the actual diff, maybe just keep track of the md5 [17:43:31] <jai> kshishkov: ah [17:44:05] <jai> there doesn't seem to be a registration page right now though [17:44:12] <jai> atleast i cant find it... [17:45:17] <kshishkov> https://roundup.ffmpeg.org/user?@template=register [17:45:25] <jai> hmm [17:45:36] <DonDiego> BBB: colloquy works fine as irc client on os x [17:45:52] <jai> well screw me then [17:46:03] <jai> kshishkov: is that accessible from the landing page? [17:46:20] <kshishkov> jai: don't care since I know how to construct URLs ;) [17:46:37] <jai> kshishkov: fair enough :) [17:46:58] <BBB> Vitor1001, postfilter progress is in codec repo [17:47:03] <BBB> Vitor1001, if you want to have a look [17:47:13] <BBB> Vitor1001, do we have code for MDF? e.g. in AAC? [17:49:24] <jai> hmm, our nsv maintainer doesnt seem to be around much [17:49:51] <DonDiego> siretart`: are you fine with the news entry? [17:49:58] <kshishkov> none of those Italians seems to be around much [17:50:37] <jai> he is probably busy with haiku ;) [17:51:09] <BBB> uhm... it doesn't ident? [17:51:26] <CIA-92> ffmpeg: diego * r22132 /trunk/MAINTAINERS: Add Reinhard and myself as release managers. [17:51:47] <kshishkov> jai: guess what nationality was always-absent maintainer of RM before some RV decoder maintainer and BBB took over? [17:51:55] <BBB> italian [17:51:57] <BBB> right? [17:52:02] <jai> kshishkov: roberto you mean? [17:52:18] <DonDiego> BBB: colloquy? it does ident for me.. [17:52:18] <kshishkov> yes [17:52:29] <jai> rtogni hasnt been active on the ML too i think [17:52:39] <BBB> DonDiego, is there a way to make it auto-ident to nickserv? [17:52:51] <kshishkov> yes, nor does not he REs new codecs :( [17:52:53] <BBB> BBB__: test [17:52:54] <DonDiego> yes [17:52:56] <jai> hmm, i always assumed mmu_man was french :) [17:53:01] <DonDiego> jai: he is [17:53:04] <BBB> dondiego: elaborate :) [17:53:07] <iive> roberto vanished at once, without any trace or word [17:53:26] <jai> DonDiego: ah, messed up context in that case :) [17:53:30] <DonDiego> BBB: gimme a sec [17:53:34] <kshishkov> and we see only 50% of Lucas here [17:53:39] <av500_at> janneg: ping see query [17:54:31] * BBB__ retries [17:55:09] <BBB> aha [17:55:10] <kshishkov> av500_at: http://b1.imgsrc.ru/w/wind_wing/0/17069990gWs.jpg [17:55:14] <DonDiego> BBB: see, it works :) [17:55:24] <BBB> dondiego: thanks, it was another prefs window :) [17:55:46] <BBB> aha, tab completion here is better [17:56:27] <av500_at> kshishkov: lol [17:57:17] <av500_at> janneg: i hope BBB is doing well [17:59:41] <CIA-92> ffmpeg: diego * r22133 /branches/ (0.5/MAINTAINERS 0.5): Add release managers, merged from trunk. [18:04:43] <CIA-92> ffmpeg: diego * r22134 /branches/0.5/RELEASE: If we are using partial release names we might as well try to be funny. [18:07:06] <BBB> av500_at: ARGH [18:07:19] <BBB> now my dock icon keeps blinking at me everytime you mention that video [18:07:29] * BBB might not like this after all [18:07:48] <kshishkov> BBB: change nick or kill av500 [18:08:12] <BBB> I prefer the second [18:08:46] <kshishkov> it's unlikely there will be a movie with the name like my nick. And users are too lazy to type it anyway [18:15:41] <elenril> irssi doesn't work on os x? ;) [18:15:55] <kshishkov> it does [18:17:12] <CIA-92> ffmpeg: vitor * r22135 /trunk/ (4 files in 2 dirs): Revert r22119 and partially revert 22120. [18:18:18] <Vitor1001> BBB: I will look at it later today or tomorrow [18:19:10] <Vitor1001> BBB: I looked very quickly, and I saw that "FilterFrameFrequencyDomainF()" is just a complex multiplication. [18:20:23] <Vitor1001> BBB: About the float clipping, did you look at the last messages of the thread I linked to? [18:21:01] <Vitor1001> Looks like a good solution to me... [18:27:16] <DonDiego> siretart`: http://www1.mplayerhq.hu/~diego/license.diff [18:29:13] <DonDiego> siretart`: http://www1.mplayerhq.hu/~diego/license.diff.txt [18:29:30] <DonDiego> i have nothing else pending [18:29:47] <DonDiego> if you're good with the news entry, we're ready to roll [18:29:55] * byteme` is getting more familiar with the code [18:30:25] <kshishkov> good [18:30:36] <BBB> Vitor1001: seems like you want to do it in the decoder [18:30:46] <BBB> Vitor1001: I'm not sure I agree, lots of code duplication in each decoder [18:30:53] <BBB> Vitor1001: but if you prefer that, then it's fine with me [18:31:07] <Vitor1001> BBB: Well, the problem about the clipping is that for some codecs it is not needed [18:31:10] <BBB> Vitor1001: my bug is that float:1.0 becomes int16:-0x8000, if you can fix that for me, I'm happy [18:31:21] <Vitor1001> but michael found a way to make this clipping to [-1:1] [18:31:52] <BBB> Vitor1001: I didn't rea the whole thread, I guess [18:31:58] <BBB> anyway [18:31:59] <BBB> again [18:32:03] <BBB> if it fixes th ebug, I'm ok with it [18:32:12] <BBB> I think the conv code right now is buggy, it requires input to be clipped already [18:32:20] <BBB> that should be fixed [18:32:23] <Dark_Shikari> Vitor1001: make it a codec pack [18:32:23] <Dark_Shikari> er [18:32:24] <Dark_Shikari> cap [18:32:35] <Vitor1001> BBB: http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/2009-August/073899.html [18:33:06] <Vitor1001> Dark_Shikari: That is a nice idea, patch welcome ;) [18:33:31] <Dark_Shikari> no, I'm suggesting doing it as part of what you're already doing [18:33:34] <Dark_Shikari> eliminating the code duplication [18:34:08] <BBB> Vitor1001: lrintf(-0.5)->-1 [18:34:09] <Vitor1001> There is a lot to be done also, mainly using dsputils for conversion [18:34:12] <BBB> (for input=float:0.0) [18:34:13] <BBB> that's not good [18:34:46] <janneg> av500_at: I can only speak for a single BBB instance. take 1 of the intro rendered fine on KotH's machine and my quadcore is busy rendering the last take of the intro [18:35:17] <Vitor1001> BBB: why? it is conversion for signed int. [18:35:28] <BBB> to signed int, right? [18:35:29] <janneg> with 0.0003 fps. sigh [18:35:39] <BBB> float->int16 [18:35:42] <BBB> input=float:0.0 [18:35:47] <Vitor1001> for unsigned it should be different [18:35:59] <Vitor1001> have to go now [18:36:00] <Vitor1001> brb [18:36:00] <BBB> out=32767.5*0.0-0.5=-0.5, lrintf(-0.5)=-1 [18:36:11] <BBB> =problem [18:36:26] <BBB> 0.0 -> 0 is correct, 0.0->-1 is bad [18:40:15] <kshishkov> it should not happen [18:40:44] <kshishkov> unless you have lim \sup{ x -> inf} - 1/x [18:53:42] * siretart` calls it a day. cu later! [19:02:39] <gthreepwood> Dark_Shikari, I can't seem to talk in #x264dev or #x264. What's wrong? [19:03:25] <ShadowJK> need registered nickname? [19:04:07] <kshishkov> I thought that Guybrush Threepwood is a Famous Pirate^TM already [19:04:14] <Dark_Shikari> gthreepwood: register your nick [19:04:25] <gthreepwood> Will do, thanks. [19:49:19] <siretart> DonDiego: still around? are we there yet? :-) [19:54:37] <kshishkov> siretart: release and forget about it already! We have 0.6 to prepare [19:57:06] <Vitor1001> BBB: I see the problem... [19:57:40] <CIA-92> ffmpeg: vitor * r22136 /trunk/libavcodec/celp_filters.c: Add commented-out unoptimized code to improve readability [19:57:58] <BBB> thanks for that commit :) [19:58:03] <BBB> I wish we would do that for code everywhere [19:58:08] <BBB> optimized code is often unreadable [19:58:30] <Vitor1001> BBB: Yeah, I should have done that since my optimization commit [19:59:49] <Vitor1001> BBB: The problem is that the range [INT_MIN; INT_MAX] is centered around 0.5 [20:00:18] <Vitor1001> Err, I mean -0.5 [20:01:34] <Vitor1001> Maybe just lrintf(*(const float*)pi * 32767) [20:01:43] <Vitor1001> Who cares it will never be -32768? [20:05:47] <Vitor1001> BTW, am I the only one who finds that tree.c:av_tree_enumerate() does not enumerate anything? [20:06:40] * elenril wonders if he should create a dummy stream for metadata muxer or fix all code that assumes at least one stream exists [20:10:54] <BBB> Vitor1001: mru also suggested (1<<n)-1 [20:10:58] <BBB> Vitor1001: I'm ok with that [20:11:18] <BBB> Vitor1001: please suggest that on ML, I'll send a new patch and apply [20:11:38] <BBB> it causes significant distortion in some of my samples [20:11:40] <Vitor1001> Remains to see if MN will like it. [20:11:45] <BBB> qcelp hack should also be removed [20:11:50] <BBB> it'll clean up qcelpdec :) [20:11:57] <Vitor1001> qcelp, amr, sipr, ... [20:12:20] <Vitor1001> But I think the clipping is more complicated. [20:12:24] <BBB> right [20:12:24] <BBB> anything float-based [20:12:58] <Vitor1001> Maybe having two sample formats: SAMPLE_FMT_FLT and SAMPLE_FMT_FLT_UNCLIP [20:13:06] <BBB> no... ewh [20:13:10] <BBB> asking for problems :) [20:13:18] <BBB> let's have one unified behaviour [20:13:21] <BBB> there's no reason not to [20:13:30] <Vitor1001> I know, but how to avoid clipping for codecs that does not need it? [20:13:33] <BBB> if you want me to do 23767/32768 as cliprange in my decoder I'll do it [20:13:44] <BBB> I just want it solved :) [20:13:53] <BBB> which codecs btw? [20:13:53] <Vitor1001> No, I'm talking about moving clipping to common code [20:13:59] <Vitor1001> I think it will be hard [20:14:03] <BBB> which codecs don't want that? [20:14:53] <Vitor1001> none ATM, mostly because those who could use dsputils.float_to_int16() [20:15:07] <Vitor1001> s/could use/could use use/ [20:27:42] <BBB> that function should never be used in codecs [20:27:46] <BBB> if the internals are float [20:27:50] <BBB> the codec should output float [20:27:57] <BBB> (and reversely for int) [20:28:19] <BBB> but anyway I'm blablabla'ing here, what do I know :) [20:28:34] <BBB> I thought there was an issue tracker entry to move wma1/2dec to float [20:37:13] <Vitor1001> BBB: If the codec is widely used and speed critical, converting output to float is a problem [20:37:28] <Vitor1001> dsputils.float_to_int16() is _much_ faster than C code [20:40:21] <BBB> I understand [20:41:03] <BBB> anyway, fix it in whatever way you feel is best [20:43:00] <CIA-92> ffmpeg: vitor * r22137 /trunk/libavcodec/celp_filters.c: Fix spelling in comment [20:46:46] * byteme` is now registered on freenode [20:59:16] <ramiro> who wants to have fun optimizing a strnlen implementation? http://pastebin.com/0NXhjhCj [20:59:56] <Dark_Shikari> are we allowed to overread the array? [20:59:57] <ramiro> this seems to be the code that gcc likes the best, everything else becomes huge. I'm not quite confident some compiler won't messup that post-increment in the while(). [21:00:00] <Dark_Shikari> can we assume that it's byte-aligned? [21:00:05] <Dark_Shikari> er, 8-byte aligned [21:00:07] <Dark_Shikari> or something like that [21:00:37] <ramiro> heh, that's the most important thing you *cannot* do (overread the array) [21:01:00] <Dark_Shikari> so you can't assume the input is aligned? [21:01:00] <ramiro> and no need for SSE either, just keep it plain and safe C... [21:01:06] <Dark_Shikari> that's crap [21:01:18] <Dark_Shikari> any program in which you need a fast strlen should have aligned data [21:03:41] <Dark_Shikari> also, the function sucks anyways [21:04:05] <twnqx> no utf support? :> [21:04:31] <Dark_Shikari> something like http://pastebin.com/dQtBLEJx should be faster [21:04:37] <Dark_Shikari> (not guaranteed to work) [21:09:35] <ramiro> doesn't work for strings greater than n. [21:10:10] <Dark_Shikari> er, what? the entire point is that it's not supposed to [21:10:11] <Dark_Shikari> it's strnlen [21:10:47] <Dark_Shikari> if you mean it's off by one, that was intentional, I didn't try to fix all the off by 1s [21:10:52] <Dark_Shikari> you can probably fix that by adding 1 to end or something [21:14:52] <ramiro> yes, it was off by 2 actually =) [21:20:31] <Dark_Shikari> is it faster now that it's fixed? [21:24:29] <ramiro> it's been hard to test actually... the strings are include file paths, so a couple hundred chars max. most of the time it's about 10 chars. [21:25:33] <ramiro> the code used to have strlen() and clip to n afterwards. so it would strlen the whole file (instead of each line), and potentially crash. [21:26:18] <ramiro> if anyone's interested, ccache might be upgraded to GPLv3: http://lists.samba.org/archive/ccache/2010q1/000475.html [21:59:49] <Dark_Shikari> what the fuck, I'm confused [22:00:02] <Dark_Shikari> my string starts with: [22:00:03] <Dark_Shikari> timebase=1/1000 cabac=1 ref=1 debl [22:00:14] <Dark_Shikari> sscanf( s, "timebase=%d/%d", &i, &j ) doesn't reutrn 2. [22:01:01] <Dark_Shikari> oh, blah, there was a character before the start and sscanf apparently needs a strstr attached. [22:51:35] <BBB> Dark_Shikari: you can add %.*s (or so) to skip random chars at the start, I forgot how it works exactly [23:03:48] <CIA-92> ffmpeg: stefano * r22138 /trunk/ffprobe.c: Clarify the error message issued by ffprobe in case of more than one file provided as input. [23:09:09] <mfg> does ftp://upload.ffmpeg.org allow anonymous uploads (as per developer.html)? I'm having trouble uploading a sample. [23:11:17] <CIA-92> ffmpeg: stefano * r22139 /trunk/ffplay.c: Add a check in the case more than one input file is provided to ffplay, make it complains and abort as just one input file is supported. [23:20:39] <Kovensky> mfg: samples.mplayerhq.hu/incoming [23:20:48] <mfg> ty

1 0