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

[irc at mansr.com]

[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;arch=i386;stamp=1268044870
[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 at chise:~ # if [ 15 -gt 50 ] ;then echo gt; else echo lt; fi
[10:45:55] <KotH> lt
[10:45:55] <KotH> attila at 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 at chise:~ # a=15; if [ $a -gt 50 ] ;then echo gt; else echo lt; fi
[10:46:34] <KotH> lt
[10:46:34] <KotH> attila at 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/ec1d0c77/attachment.patch
[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/662f92aa/attachment.patch 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.