[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;a... [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/ec1d0c... [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/662f92... 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.