[00:54:47] <Dark_Shikari> mru: nice faad patch :) [01:14:40] <saintd3v> Dark_Shikari: yes it is :) [01:14:57] <saintd3v> peloverde: thanks for all you work on the aac decoder [03:08:09] <Compn> well sorry i derailed the 'removing libfaad wrapper' movement mru [03:08:23] * Compn sleeps [03:12:54] <saintdev> Compn, me too. i'll be glad to see it gone [04:54:32] <saintdev> peloverde: ping [05:26:19] <astrange> make fate would be more useful if the 4xm test didn't fail on unpatched builds [06:10:52] <peloverde> saintd3v, pong kind of quickly if you are around otherwise tomorrow [06:12:53] <saintdev> peloverde: i found he-aac a stream that gives some errors, would you be interested? [06:13:00] <peloverde> yes [06:13:17] <saintdev> peloverde: http://91.121.18.185:7260 [06:13:34] <saintdev> [aac @ 0x3166ff0]channel element 1.9 is not allocated [06:13:58] <saintdev> hmm, not giving me the other errors it was before [06:14:23] <peloverde> post it on roundup, i'll check it out in the AM [06:14:41] <saintdev> eek segfault [06:15:06] <saintdev> hmm, and now it's not giving any error [06:15:11] <saintdev> what is going on [06:15:33] <peloverde> odd, It may use some odd feature in a strange way on occasion [06:16:06] <peloverde> I've only tested against the conformance files and the CT identification file(s) [06:16:43] <saintdev> could it be because it's joining in the middle of the stream, and maybe not getting a full frame to start with? [06:17:23] <peloverde> you need an SBR "IDR" frame + a PS "IDR" frame to get full quality [06:18:04] <peloverde> until then SBR will run in pure upsampling mode and PS will run in channel duplication mode [06:18:51] <peloverde> and (may?) spam errors? [06:19:34] <saintdev> ok, maybe that's it. i'll get a reliable sample for you to look at anyway [06:19:45] <_av500_> peloverde: kudos for PS! [06:19:47] <saintdev> just in case ;) [06:19:56] <saintdev> _av500_: agreed \o/ [06:20:01] <peloverde> _av500_, thanks [06:20:11] <peloverde> saintd3v, broken samples appreciated [06:20:30] <_av500_> peloverde: next stop ffaacenc? [06:21:10] <peloverde> in theory that's what I'm working on, there will probably be a few weeks of minor PS fixups [06:24:04] <peloverde> I felt more competent taking money for psdec seeing as I'm at this point more decoder competent but we will see [09:11:14] <KotH> morge [09:59:51] <mru> astrange: what of fate? [10:01:19] <astrange> let me re-configure and see what the problem was... it was the wrong md5 on 4xm [10:01:35] <astrange> i assume if you give the wrong path to --samples it will actually notice? [10:01:57] <mru> as in tests fail, yes [10:03:17] <mru> well, it works here [10:03:25] <astrange> +++ tests/data/fate/4xm2010-06-20 03:02:42.000000000 -0700 -88a53430410d1cec5ed46846652ffd51 +d41d8cd98f00b204e9800998ecf8427e [10:03:55] <astrange> ...yeah, that's the empty file md5 [10:04:22] <mru> the only md5 I've bothered to memorise [10:04:26] <mru> well, not all of it [10:11:59] <astrange> no, it fails with the right path. is my rsync url out of date? [10:12:21] <mru> what's the md5 of your 4xm test file? [10:12:38] <mru> should be 9c16fcadaf51f93be3a51b8fc92cc119 [10:14:00] <astrange> it's... a symlink pointing to something i don't have [10:14:01] <astrange> lrwxrwxrwx 1 astrange astrange 49B Jan 25 2009 TimeGatep01s01n01a02_2.4xm -> ../../game-formats/4xm/TimeGatep01s01n01a02_2.4xm [10:14:13] <astrange> better try it again without symlinks [10:14:24] <mru> tell rsync to follow links [10:16:55] * mru is itching to delete the faad wrapper... [10:19:19] <Compn> wow, another stereoscopic patch for mplayer [10:19:25] <Compn> what is it with the resurgance of 3d? :P [10:19:54] <mru> of course you need two patches for stereoscopic video [10:20:31] <mru> they figured out a cheap way to project polarised images [10:21:14] <elenril> mru: so what are you waiting for [10:21:24] <elenril> everybody seems to agree [10:21:32] <mru> I was hoping michael would comment [10:21:35] <mru> but he probably won't [10:24:10] <mru> ok, here it comes [10:25:00] <CIA-92> ffmpeg: mru * r23653 /trunk/ (5 files in 3 dirs): Remove libfaad wrapper [10:28:03] <elenril> \o/ [10:29:07] <elenril> maybe this needs a changelog entry [10:30:08] <mru> yeah, guess it does [10:30:14] <mru> I always forget about that [10:32:45] <CIA-92> ffmpeg: mru * r23654 /trunk/Changelog: ChangeLog: note libfaad wrapper removal [10:39:51] <mru> astrange: btw, pts tracking with libavcodec is a bitch [10:40:05] <Dark_Shikari> nevermind sometimes it just doesn't work [10:40:10] <mru> I use 3 different methods [10:40:19] <mru> reordered_opaque when that works [10:41:11] <mru> if that fails, I track coded_picture_number [10:42:02] <astrange> i'm surprised that i couldn't find a file that patch regressed on [10:42:10] <mru> if that fails, I try pts out = dts in [10:42:31] <mru> and finally I fall back on incrementing pts by frame duration [10:42:38] <mru> for constant frame rate [10:42:47] <mru> so 4 methods in fact [10:42:48] <astrange> for files with missing dts the pre-reorderd pts can be 1 2 3 4, and then 1 4 2 3 comes out instead of 1 2 3 4 [10:43:04] <mru> which codec? [10:43:15] <astrange> since there's no buffering it only sees the problem when it gets to 2, so it can only correct it to 1 4 5 6 and you lose two pts values [10:43:17] <mru> I don't think all codecs support reordered_opaque properly [10:43:30] <astrange> divx with packed b-frames. or ffmpeg streamcopy .h264 to .mp4 and play that [10:43:50] <astrange> streamcopy from h264 is broken because the parser doesn't generate dts [10:43:57] <mru> streamcopy h264 to mp4 will produce an invalid file [10:44:13] <mru> mp4 requires pts and dts for all frames [10:44:29] <Dark_Shikari> invalid? last I recall it just fails [10:44:32] <mru> if you lie to the muxer, you get what you deserve [10:44:43] <mru> Dark_Shikari: depends on how you lie [10:44:48] <Dark_Shikari> I mean in ffmpeg. [10:44:57] <mru> as long as dts is increasing, ffmpeg is happy [10:44:58] <Dark_Shikari> and generating dts is trivial [10:45:12] <Dark_Shikari> The problem is that ffmpeg doesn't have a universal system for doing it [10:45:16] <mru> generating dts is usually just counting frames [10:45:20] <Dark_Shikari> and instead forces you to repeat the same dts-generation code in every single demuxer [10:45:21] <astrange> i think vfr + packed b-frames might regress with the patch... [10:45:27] <astrange> hmm, i might actually have a 120fps avi that would do that [10:45:37] <Dark_Shikari> but 120fps isn't vfr [10:45:53] <astrange> the avi demuxer reads it as vfr [10:45:54] <mru> avi is never vfr [10:46:06] <Dark_Shikari> astrange: oh, by dropping null frames [10:46:07] <astrange> it uses drop frames, not 120fps coded frames [10:46:10] <mru> sometimes people set a stupidly high fps and pad with null frames [10:46:18] <Dark_Shikari> well, even if avi isn't vfr, the demuxer is [10:46:19] <mru> for a fake vfr effect [10:49:39] <Dark_Shikari> dunno, seems perfectly "real" vfr to me [10:49:43] <Dark_Shikari> a _crappy_ way of doing it, for sure [10:49:59] <Dark_Shikari> inefficient, as it's O(duration * timebase denominator) in overhead instead of O(frames) [10:50:01] <mru> fake at container level [10:50:10] <mru> avi officially doesn't allow vfr [10:50:23] <mru> how could it without timestamps? [10:50:38] <mru> and null packets only get you so far [10:50:57] <Dark_Shikari> are null packets a container level feature? [10:51:01] <Dark_Shikari> or an abuse of the bitstream [10:51:05] <mru> container abuse [10:51:05] <Dark_Shikari> i.e. something done on codec level [10:51:15] <mru> zero-sized avi packet [10:51:20] <Dark_Shikari> ah [10:51:37] <Dark_Shikari> I would say that's "real vfr, horribly inefficient, in a way that isn't specified by the container" [10:52:16] <Dark_Shikari> either way, just semantics. [10:54:35] <mru> suppose your average rate is something normal but with random jitter [10:54:49] <mru> requiring a time base of 1us or so [10:54:59] <mru> then most of your avi file would be null packets [10:54:59] <Dark_Shikari> as I said, horribly inefficient =p [10:55:08] <mru> that's beyond horrible [10:55:11] <Dark_Shikari> Most VFR doesn't have such a crazy timebase though. [10:55:16] <Dark_Shikari> millisecond is common enough. [10:55:24] <Dark_Shikari> for ms precision, it wouldn't be utterly unusable, just bad. [10:56:11] <astrange> i think windows programs just force the closest available time on frames [10:57:04] <mru> for playback you obviously have to quantise at the display refresh rate anyway [11:41:29] <CIA-92> ffmpeg: cehoyos * r23655 /trunk/libavformat/spdif.c: [11:41:29] <CIA-92> ffmpeg: Add IEC958 data_types for DTS-HD (data burst described in IEC 61937-5), [11:41:29] <CIA-92> ffmpeg: E-AC-3 (61937-3 Edition 2) and TrueHD (61937-9). [12:34:23] * lu_zero is back [12:34:51] <lu_zero> ffrtsp is taking a bit of time before starting, beside that isn't different than live555 so far [12:51:29] <Honoome> lu_zero: already back from cinisello? [13:01:15] <CIA-92> ffmpeg: vitor * r23656 /trunk/libavcodec/mpegaudiodec.c: [13:01:15] <CIA-92> ffmpeg: Fix breakage in compilation with --disable-mpegaudio-hp introduced in [13:01:15] <CIA-92> ffmpeg: r23646. [13:32:29] <Vitor1001> mru: aliasing in C sucks [13:32:49] <Vitor1001> no wonder there are a lot of code that is just way faster in fortran :p [13:33:07] <mru> hmm... fortran in ffmpeg... [13:33:27] <Vitor1001> :p [13:33:36] <Vitor1001> Its ugly as hell [13:33:41] <mru> I know [13:33:56] <mru> we could write polyglots for those who don't have a fortran compiler [13:33:59] <Vitor1001> fortran written by scientist is even better [13:34:23] <Vitor1001> s/fortran/fortran code/ [13:34:41] <Vitor1001> I wonder why C does not have some attribute for pointer that guarantees that [13:34:55] <Vitor1001> 1- Pointers with this attribute are either identical or do not alias [13:35:15] <Vitor1001> 2- They are as much aligned as the most restrictive instruction of the platform [13:35:16] <Vitor1001> ? [13:36:32] <mru> attributes wouldn't cut it [13:36:45] <Vitor1001> You can call it a new type... [13:36:51] <mru> same problem [13:37:02] <Vitor1001> You can cast it to a pointer without a warning, but not the inverse. [13:37:05] <mru> what if you have four pointers which are pairwise identical or disjoint [13:37:23] <mru> and crosswise aliasing is entirely impossible [13:38:32] <mru> or any ident-or-disjoint n-tuples [13:39:24] <Vitor1001> If the compiler really need to know, it can always insert a if(a==b){ ... } else {...}, no? [13:39:56] <mru> the compiler is free to insert whatever it wants [13:40:05] <mru> as long as the code is semantically equivalent [13:40:20] <Vitor1001> So where would such a strategy fail? [13:40:27] <mru> you'll often see compiler check for alignment [13:40:42] <Vitor1001> I suppose you are not talking about gcc? [13:41:00] <mru> even gcc does that sometimes iirc [13:41:12] <mru> armcc certainly does [15:22:12] <nfl> merbzt: ping [16:59:38] <CIA-92> ffmpeg: ramiro * r23657 /trunk/configure: [16:59:38] <CIA-92> ffmpeg: Use ${strip} variable instead of just plain "strip". The former already has a [16:59:38] <CIA-92> ffmpeg: leading cross_prefix in it. Fixes cross-compilation for darwin. [17:16:20] <CIA-92> ffmpeg: alexc * r23658 /trunk/libavcodec/ (ps.c ps.h): Remove iid_mode from the PS context. [17:29:41] <CIA-92> ffmpeg: alexc * r23659 /trunk/libavcodec/ps.c: Document the PS_BASELINE define. [17:53:34] <peloverde> Does it ever seem like disable-everything behaves a little wonky sometimes? [18:00:48] <mru> explain [18:01:17] <mru> I assume you're enabling some stuff afterwards [18:01:22] <peloverde> yes [18:01:23] <mru> or are you running full debian mode? [18:01:51] <peloverde> consider ./configure --disable-everything {--enable aac specific stuff} --enable-ffmpeg [18:02:08] <peloverde> It doesn't build FFmpeg because it needs the buffer filter [18:02:29] <mru> I suppose we could make it auto-select that [18:02:36] <mru> the question is which should take precedence [18:03:11] <peloverde> Also that same setup still seems to find and enable SDL and ffplay by default [18:04:01] <mru> --disable-everything doesn't seem to disable quite everything [18:05:38] <peloverde> indeed [18:06:11] <_av500_> --disable-everything on its own should build nothing in the end, no? [18:06:48] <mru> it only disables codecs etc [18:07:04] <mru> not building anything at all is much simpler [18:07:06] <mru> don't run make [18:07:12] <peloverde> IMHO it should disable the ffprogs as well [18:07:37] <mru> whatever we do, someone will be inconvenienced [18:08:18] <peloverde> nobody is happy, the sign of a good compromise [18:12:26] <peloverde> wonderful... a regression (I think) somewhere deep inside SBR [18:14:47] <mru> it's not a regression if it never worked [18:16:15] <peloverde> That's what I'm checking [18:16:36] <peloverde> I really need to get this AAC stuff inside FATE [18:17:14] <mru> we need to rewrite fate properly [18:17:41] <mru> having mike as single point of failure is not acceptable [18:17:51] <mru> and he's way too slow to react [18:18:13] <peloverde> The bulk of AAC can be tested by PSNR and/or off-by-1 [18:27:06] <KotH> mru: feel free to rewrite fate ;-) [18:27:39] <mru> no time right now [18:28:19] <peloverde> And the answer is never worked or broke before I merged SBR [18:28:38] <mru> time to bisect the private repo [18:50:48] <peloverde> Woohoo it's a confirmed regression [18:56:08] <mru> so fix it, what are you waiting for? [18:57:08] <twnqx> christmas! [18:57:14] <twnqx> sorry, couldn't resist. [18:58:10] * mru wonders whether the queen has the power to move christmas [19:05:40] * peloverde would gladly revert this commit, but some claimed in the review that it was "cleaner," so I need to figure out how to properly fix it [19:05:56] <mru> which commit? [19:07:25] <peloverde> http://github.com/aconverse/ffmpeg-heaac/commit/62b32cbd5ff1e6f20ae5c530a1f0... [19:12:20] <mru> sure, it's cleaner [19:12:24] <mru> but if it's also wrong... [19:13:30] <mru> I'd still try to split it by sign [19:13:47] <mru> might be nicer [19:22:07] <peloverde> found it [19:24:58] * peloverde kicks CIA-92 [19:24:59] <CIA-92> ow [19:25:08] <CIA-92> ffmpeg: alexc * r23660 /trunk/libavcodec/aacsbr.c: 10l: aacsbr: Fix f_master[2] calculation when k2diff == -1. [19:28:53] <peloverde> I enjoy how the CT PS signaling testsuite uses SBR features not found in the SBR testsuite [19:38:56] <CIA-92> ffmpeg: alexc * r23661 /trunk/libavcodec/ps.c: [19:38:56] <CIA-92> ffmpeg: Allow PS envelope fixup when ps->num_env_old <= 1. [19:38:56] <CIA-92> ffmpeg: It is already rejected by the "source >= 0 && source != ps->num_env" 0 envelope [19:38:56] <CIA-92> ffmpeg: case and is perfectly legally for the suppressed final envelope case. [19:54:02] <Dark_Shikari> is that ban on german ips or whatever still up? [19:54:08] <Dark_Shikari> I recall there was some ip block from ffmpeg.org [19:54:17] <mru> there are many blocks [19:54:27] <mru> half of china is blocked [19:54:27] <Dark_Shikari> there was some rather large one that has hit an unreasonable number of users [19:54:31] <Dark_Shikari> iirc [19:54:39] <Dark_Shikari> something like "blocking half of germany" [19:54:47] <mru> arcor is blocked [19:54:57] <Dark_Shikari> why? [19:55:07] <mru> some idiot with dynamic ip is hammering our server [19:55:52] <Dark_Shikari> yeah, there are a lot of users in #ffmpeg who can't download ffmpeg. [19:55:56] <Dark_Shikari> it's kinda annoying. [19:56:16] <mru> tell them to track down and kill the idiot [19:56:33] <Dark_Shikari> it would be useful if they knew some bit of identifying information =p [19:56:56] <Dark_Shikari> still, blocking millions of users because of one idiot is kinda silly [19:57:10] <mru> we don't like it either [19:57:17] <Dark_Shikari> then why do it? [19:57:28] <Dark_Shikari> bandwidth is cheap [19:57:47] <mru> no [19:58:09] <Dark_Shikari> no what [19:58:10] <mru> if we use too much bandwidth our sponsors will get angry [19:58:24] <Dark_Shikari> "sponsors"? [19:58:33] <Dark_Shikari> Fuck, you can get an unlimited-bandwidth host for $10 a month [19:58:56] <mru> not with the capacity of ours [19:59:25] <mru> dual xeon, 6GB ram [19:59:29] <mru> piles of diskspace [19:59:48] <Dark_Shikari> But you don't need that for a user-facing server [19:59:49] <Dark_Shikari> we have no php [20:00:20] <Dark_Shikari> you could serve our entire website off a beagleboard [20:00:49] <mru> right now our load average is 0.7 [20:01:02] <Dark_Shikari> yes, that's because of svn, probably [20:01:07] <mru> yes, mostly [20:01:38] <mru> now it's 0.8 [20:03:02] <mru> we average close to 10Mbps out [20:04:20] <Dark_Shikari> so.... [20:04:22] <mru> those "free" hosting services are only good for small blogs [20:04:24] <Dark_Shikari> if we switched to git [20:04:45] <Dark_Shikari> I imagine we could cut down rather a lot on that load average [20:05:12] <osaft> Arcor is blocked?_? [20:05:17] <Dark_Shikari> mru: our website *is* a small blog [20:05:20] <SpeedsterF2> hi [20:05:22] <Dark_Shikari> in terms of size and traffic [20:05:25] <Dark_Shikari> it's the svn that's the problem [20:05:41] <SpeedsterF2> I am the arcor user that has frequent connection problems [20:05:58] <mru> Dark_Shikari: fine, you take over [20:06:21] <mru> see if you can manage the availability we've had until now [20:06:31] <Dark_Shikari> you mean totally shit availability? [20:06:32] <SpeedsterF2> I just wonder why i can access ffmpeg.org from time to time, but on other days i fail [20:06:37] <Dark_Shikari> where millions of users can't access the website most of the time? [20:06:43] <Dark_Shikari> where svn takes 5 minutes for a checkout? [20:06:50] <Dark_Shikari> the current "availability" is laughable [20:07:04] <mru> in the last year we've had _one_ unplanned outage lasting more than an hour or so [20:07:08] <Dark_Shikari> you can't just block half the world and then say "oh, well we're highly available to the rest of it" [20:07:32] <CIA-92> ffmpeg: alexc * r23662 /trunk/libavcodec/ps.c: Use memcpy() where appropriate in PS stereo processing remapping. [20:07:38] <Dark_Shikari> "we're highly available to 127.0.0.1" [20:07:43] <mru> $ time svn co svn://svn.ffmpeg.org/ffmpeg/trunk ffmpeg.svn [20:07:46] <mru> real 0m7.088s. [20:08:07] <Dark_Shikari> ok, try this then [20:08:10] <Dark_Shikari> "time svn log > /dev/null" [20:08:18] <mru> that's svn being full of suck [20:08:38] <Dark_Shikari> lol [20:08:48] <peloverde> time git svn clone... [20:08:54] <Dark_Shikari> so... git .... [20:09:04] <mru> git svn clone obviously doesn't matter [20:09:14] <mru> fetching every rev sequentially has to take a while [20:09:28] <Dark_Shikari> 50.5 seconds [20:09:47] <peloverde> When we switch to git, it will make life a lot easier [20:09:53] <Dark_Shikari> 0.13 seconds to get the git log of x264 [20:10:00] <Dark_Shikari> Yes sure it's shorter, but not 500 times =p [20:10:06] <Dark_Shikari> what's git-svn say for ffmpeg's log? [20:10:14] <mru> git clone of ffmpeg takes 20s here [20:10:51] <Dark_Shikari> what about git log of ffmpeg? [20:11:37] <Kovensky> git log is generated locally, it doesn't count [20:11:48] <Kovensky> the only git times that matter are clone, fetch and push [20:12:23] <Kovensky> well, clone is "syntatic" sugar for init + remote + fetch, so yeah, fetch and push [20:12:30] <Kovensky> (+ checkout) [20:13:10] <Dark_Shikari> Kovensky: no, it does count [20:13:21] <Dark_Shikari> the whole point is that it's local, so it's faster. [20:13:50] <Kovensky> oic, I thought the discussion was about the server itself [20:14:02] <SpeedsterF2> I just want to mention that blocking arcor keeps me from accessing URLs like http://git.ffmpeg.org/?p=ffmpeg;a=shortlog or http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/, too [20:14:02] <CIA-92> ffmpeg: alexc * r23663 /trunk/libavcodec/ps.c: Cosmetics: whitespace. [20:14:26] <SpeedsterF2> I use those to keep being up to date on the discussions / development process [20:14:56] <peloverde> "time git clone git://git.ffmpeg.org/ffmpeg" real 3m1.161s [20:15:37] <Kovensky> peloverde: what about git://repo.or.cz/FFMpeg-mirror.git (yes, with uppercase M) [20:17:57] <mru> peloverde: what's your downstream bandwidth? [20:19:51] <Dark_Shikari> wow, that git server is slow [20:19:57] <Dark_Shikari> I'm only getting like 150 KBps [20:20:02] <Dark_Shikari> and my connection is 10mbit [20:20:55] <peloverde> Kovensky: real 5m0.676s [20:21:45] <elenril> Dark_Shikari: no, you're just in a wrong place [20:21:54] <elenril> Receiving objects: 100% (116165/116165), 35.97 MiB | 7.58 MiB/s, done. [20:21:55] <peloverde> mru, I'm paying for 15mbps but I get far less than that [20:22:50] <mru> elenril: .cz probably has poor external lines [20:23:09] <Dark_Shikari> 2m16s [20:23:11] <mru> peloverde: I usually get 18-20Mbps down [20:23:38] <peloverde> I'm getting 3.74 Mbps down atm :( [20:24:00] <mru> explains the difference in clone time [20:24:26] <peloverde> It's better weekdays during the day [20:24:32] <peloverde> but it still is super shitty [20:24:48] <peloverde> sadly it's the only ISP I can get around here [20:25:14] <mru> there's a bit of competition here [20:25:18] <mru> though not much at the high end [20:25:55] <peloverde> The best government money can buy gave the major telcos money to build out fiber, but they never seemed to deliver on that [20:27:01] <mru> Dark_Shikari: anyhow, I'm looking at that idct_dc again [20:27:16] <mru> and it's mysteriously failing in a couple of cases [20:27:23] * SpeedsterF2 has to leave now [20:27:35] <SpeedsterF2> thanks for your investigations [20:28:25] <SpeedsterF2> I hope that there will be a way for me to access natsuki services via my arcor ISP in the future [20:28:42] <Dark_Shikari> mru: "failing" as in "not matching C"? [20:28:51] <Dark_Shikari> or "being totally utterly wrong" [20:28:59] <SpeedsterF2> Or i have to find a (free) proxy to hide my "identity" [20:29:02] <mru> C not matching C [20:29:48] <Dark_Shikari> mru: o.0 0.o o.0 [20:32:54] <lu_zero> O_o? [20:35:15] <peloverde> ಠ_ಠ [20:37:01] <Kovensky> <@Dark_Shikari> wow, that git server is slow <@Dark_Shikari> I'm only getting like 150 KBps <-- inorite [20:37:09] <Kovensky> <@Dark_Shikari> and my connection is 10mbit <-- wasn't it 1gbit [20:38:17] <Dark_Shikari> at school [20:38:21] <Dark_Shikari> now I'm at a condo in oc [21:14:43] <BBB> Tjoppen: so I think I need more background info, what exactly isn't working with http seeking? is it just the fact that it hangs? [21:14:53] <BBB> I mean, seek isn't supposed to work if content-range is missing [21:19:05] <mru> Dark_Shikari: ugh, block_last_index isn't always correct [21:19:52] <Dark_Shikari> sounds like a bug [21:21:19] <Tjoppen> BBB: well, first of all you can't rewind [21:21:26] <mru> Dark_Shikari: yes, probably [21:21:44] <mru> Dark_Shikari: block_last_index says 0 even though block[63] == 1 [21:21:47] <mru> in one case [21:21:49] <Tjoppen> also, it is entirely possible that the server accepts Range but doesn't yet know the size of the file [21:22:20] <BBB> the way for a server to indicate that it supports range is by sending out content-range [21:22:27] <Tjoppen> I've managed to get non-finished uploads playing this way [21:22:28] <BBB> afaict [21:24:34] <Tjoppen> or rather, it's a bit more serious: if for some reason the server uses chunked encoding but provides a content-range, it would still beak [21:24:45] <Tjoppen> *break [21:25:06] <BBB> ? [21:25:16] <Dark_Shikari> mru: what video format [21:25:19] <mru> mpeg2 [21:25:31] <BBB> Tjoppen: look, if you want this to work, then first it needs to work for the broken cases it's trying to fix [21:27:02] <Dark_Shikari> mru: oh wow, so not even something with e.g. ac pred [21:27:30] <Tjoppen> well, the only thing that is broken is that it can end up sending the headers using chunked encoding [21:29:49] <BBB> I cannot reproduce that [21:29:59] <BBB> it doesn't seek here, ever [21:30:03] <BBB> because content-range is missing [21:30:07] <BBB> and is_streamed is 1 [21:30:10] <BBB> so it doesn't ever seek [21:30:15] <BBB> it doesn't even attempt to [21:30:22] <BBB> it just continues playing [21:30:27] <BBB> (try e.g. a .rm file) [21:30:36] <BBB> that sounds like correct behaviour to me [21:31:21] <Tjoppen> try saying content-range: 0- [21:33:29] <mru> found something [21:33:39] <mru> mpeg12.c line 940 [21:34:19] <mru> what's that all about? [21:34:53] <Dark_Shikari> I have no idea wtf. [21:38:27] <BBB> Tjoppen: ok, so I have fixed that now by using url_write instead of http_write [21:38:35] <BBB> I still can't reproduce it, but it's better either way [21:38:48] <BBB> so now all that's left is that chunked_size isn't reset after a seek? [21:39:10] <CIA-92> ffmpeg: rbultje * r23664 /trunk/libavformat/http.c: [21:39:10] <CIA-92> ffmpeg: Use url_write(), not http_write(), for sending the HTTP headers. This prevents [21:39:10] <CIA-92> ffmpeg: them from being sent using chunked encoding (I don't think this ever happened, [21:39:10] <CIA-92> ffmpeg: but either way it would be wrong). [21:41:08] <BBB> Tjoppen: ok, so that's fixed also now [21:41:21] <BBB> Tjoppen: now, still, it doesn't actually seek, so what do you suggest I do about that? [21:41:53] <CIA-92> ffmpeg: rbultje * r23665 /trunk/libavformat/http.c: [21:41:53] <CIA-92> ffmpeg: Reset chunksize back to zero (= no chunked encoding) after each new open [21:41:53] <CIA-92> ffmpeg: connection (e.g. a seek). This fixes the theoretical case where a server [21:41:53] <CIA-92> ffmpeg: sends a file first using chunked encoding, and then using non-chunked [21:41:53] <CIA-92> ffmpeg: encoding. [21:41:59] <mru> Dark_Shikari: I don't understand the purpose of that mismatch variable [21:42:13] <Dark_Shikari> mru: neither do I [21:42:16] <Dark_Shikari> ask michael [21:42:24] <Dark_Shikari> oh. [21:42:29] <Dark_Shikari> dct mismatch? [21:42:43] <Dark_Shikari> Oh god. [21:42:45] <Dark_Shikari> I see what he's doing. [21:42:56] <mru> please explain [21:43:13] <Dark_Shikari> To account for dct mismatch, he's randomly adjusting the last coeff [21:43:23] <Dark_Shikari> based on the number of nonzero coeffs [21:44:05] <mru> it's xoring the lsb of all coeffs into the last one [21:44:12] <Dark_Shikari> yes [21:44:40] <mru> which of course sprinkles +-1 all over the final block [21:45:12] <Dark_Shikari> yes [21:45:15] <Dark_Shikari> to dither the dct mismatch [21:45:26] <mru> urg [21:45:39] <Dark_Shikari> and it doesn't set the last nonzero coeff properly [21:45:46] <Dark_Shikari> stupid. [21:45:46] <mru> the last bit I noticed [21:45:56] <Dark_Shikari> check the svn blame on that [21:46:01] <mru> since forever [21:46:06] <Dark_Shikari> I wonder when [21:46:12] <Dark_Shikari> and if the omission of adjusting the last nonzero coeff was intentional [21:47:59] <BBB> Tjoppen: I even removed all checks [21:48:05] <BBB> Tjoppen: the fileserver example simply doesn't seek [21:48:12] <BBB> Tjoppen: the behaviour of http.c is correct [21:49:00] <BBB> Tjoppen: if my commits leave an actual bug now, I'd be happy to help, but I think apart from the case where chunked and non-chunked encoding are mixed, http.c is doing the correct thing right now [21:50:15] <mru> Dark_Shikari: it's been there from the start [21:50:27] <Dark_Shikari> mru: WHAT [21:50:36] <Dark_Shikari> er [21:50:42] <Dark_Shikari> have you checked cvs history? [21:50:45] <mru> yes [21:50:54] <Dark_Shikari> it was added in the initial commit of the mpeg decoder? [21:50:57] <Dark_Shikari> by michael or fabrice? [21:51:08] <mru> initial commit [21:51:10] <mru> fabrice [21:51:15] <Dark_Shikari> ..... holy shit [21:51:19] <Dark_Shikari> I think we can justify removing it then [21:51:19] <Dark_Shikari> lol [21:51:19] <mru> initial commit of _ffmpeg itself_ [21:51:23] <Dark_Shikari> LOL [21:51:51] * elenril thinks this need to go into quotes [21:52:29] <mru> since the beginning of time, the big bang [21:53:01] <Dark_Shikari> ok, feel free to propose removing that [21:53:02] <Dark_Shikari> lol [21:53:55] <BBB> Dark_Shikari: I added some macros to create simple h8/h16 variants of the mc function [21:54:22] <BBB> Dark_Shikari: there is no easyway of macroing my way towards a v8/v16 right? I simply made a quick C function calling the v4 one twice with different src/dst offsets [21:54:33] <BBB> (and then h+v as C functions calling both) [21:54:39] <CIA-92> ffmpeg: alexc * r23666 /trunk/libavcodec/ps.c: Rename PS bitstream reading functions to have a read_ prefix. [21:54:58] <mru> Dark_Shikari: you propose just removing the dithering? [21:55:08] <mru> I'm fine with that [21:57:59] <Dark_Shikari> mru: yes [21:58:13] <Dark_Shikari> BBB: what did you do to macro it? [21:58:16] <Dark_Shikari> link? [21:59:21] <BBB> http://ffmpeg.pastebin.com/RGxXeekQ [21:59:30] <BBB> I didn't remove the splats yet, I haven't coded this weekend [21:59:32] <BBB> maybe monday or so [22:00:08] <Dark_Shikari> that's wasteful [22:00:23] <Dark_Shikari> do w8 by calling it many times, not by %rep [22:00:26] <Dark_Shikari> or even by templating it [22:00:33] <Dark_Shikari> templating or %rep needlessly increases code size [22:00:39] <Dark_Shikari> there's no speed benefit really [22:01:07] <BBB> http://ffmpeg.pastebin.com/at9WQzzR [22:01:11] <BBB> that's what I do for v8/v16 [22:01:19] <BBB> should I do that for h8/16 as well? [22:03:01] <Dark_Shikari> yes [22:03:11] <Dark_Shikari> well, ideally you should do it in asm [22:03:15] <Dark_Shikari> that would eliminate the calling overhead [22:03:22] <Dark_Shikari> i.e. in x264 where I showed you NXN_DCT [22:03:24] <Dark_Shikari> is a good example [22:03:26] <Dark_Shikari> but you can do that later. [22:03:48] <BBB> uhm, right, but then it needlessly increases codesize again, no? [22:03:54] <Dark_Shikari> no [22:03:56] <CIA-92> ffmpeg: alexc * r23667 /trunk/libavcodec/ps.c: psdec: Replace a division with a shift. [22:04:01] <Dark_Shikari> just calling code [22:04:11] <Dark_Shikari> this allows you to skip most of the calling convention [22:04:19] <BBB> oooo [22:04:19] <Dark_Shikari> but it's tricky, you can do that much later. [22:04:20] <BBB> right [22:04:28] <BBB> I see what you mean [22:04:38] <BBB> right, because C will re-put all stuff to the stack [22:04:46] <Dark_Shikari> in x86_32. [22:04:50] <BBB> whereas I don't need to, I can just jmp [22:05:09] <BBB> or, well, call x.aftersetup [22:05:12] <BBB> then increase dst/src [22:05:16] <BBB> and then do the same thing again [22:05:27] <Dark_Shikari> yup [22:05:31] <Dark_Shikari> it's skip_prologue in x264 [22:05:38] <Dark_Shikari> this also lets you load global constants into registers once at the start [22:06:00] <BBB> I'll do that later, I figure the gain is rather small [22:06:18] <BBB> I'll rewrite h8/16 to do this, first/for-now [22:07:11] <Dark_Shikari> Yeah, stick with the current bit for now [22:07:52] <BBB> so next, I was looking into the loopfilter [22:08:05] <BBB> that's the top hit in my performance test (shark) [22:08:24] <CIA-92> ffmpeg: cehoyos * r23668 /trunk/libavcodec/dca.c: [22:08:25] <CIA-92> ffmpeg: Fix typo in macro name. [22:08:25] <CIA-92> ffmpeg: Patch by Nick Brereton, nick nbrereton net [22:08:52] <BBB> 8 functions, with 6 of them taking 7.7-10.2% each of total time in the video thread [22:09:21] <Dark_Shikari> the real question you'll want to consider is whether the vp8 loopfilter is faster in 8-bit or 16-bit [22:09:22] <CIA-92> ffmpeg: alexc * r23669 /trunk/libavcodec/ps.c: psdec: Simplify filter addressing by incrementing the "in" pointer. [22:09:25] <Dark_Shikari> also, the loopfilter is generally pretty difficult to do [22:09:36] <BBB> yeah, it looks complex [22:10:01] <BBB> lot of clipping (both int8 as well as uint8) [22:10:06] <BBB> and lots of conditionals [22:10:13] <BBB> (if(...) { ... } [22:10:38] <BBB> which looks particularly complex if you want to do multiple rows at once, you can't conditionally do one row and not the other (?) [22:10:55] <Dark_Shikari> You should start by looking at existing loopfilter code [22:10:57] <Dark_Shikari> e.g. VP3 and h264 [22:11:22] <Dark_Shikari> I would suggest doing idct first though [22:11:25] <Dark_Shikari> it's only one function and it's easier [22:11:42] <BBB> that's only 2.1% of total calling time [22:11:47] <BBB> seems like it isn't really relevant [22:12:01] <BBB> even ff_emulated_edge_mc() takes more time (3.1%) [22:12:07] <mru> 2.1% is relevant [22:12:11] <BBB> shouldn't that be optimized btw? [22:12:20] * mru considers down to 1% certainly relevant [22:12:26] <mru> smaller ones too if there are many [22:13:44] <BBB> right, but you start with the stuff taking 10% right? [22:13:45] <Dark_Shikari> BBB: it's highly relevant [22:13:48] <BBB> especially if there's 6 of them [22:13:50] <Dark_Shikari> it will be much more time once you optimize other things [22:13:56] <Dark_Shikari> if ff_emulated_edge_mc takes more time, something is horribly wrong [22:14:03] <BBB> it takes 3.1% [22:14:04] <Dark_Shikari> edge mc shouldnt' be used that much unless your test video is 160x120 [22:14:15] <BBB> that's true [22:14:20] <BBB> maybe I should check, my conditional may be broken [22:14:25] <Dark_Shikari> Probably [22:14:33] <CIA-92> ffmpeg: alexc * r23670 /trunk/libavcodec/ps.c: psdec: IPD/OPD reset is no longer needed by the context initializer. [22:16:21] <BBB> it looks alright [22:16:42] <Dark_Shikari> Make sure it is. [22:16:58] <Dark_Shikari> e.g. by printing mvs and verifying by hand [22:21:55] <BBB> it looks fine, it's a little broad, I'm finetuning it [22:25:27] * mru waits for michael to react [22:30:23] <Dark_Shikari> it violates the spec?!?! [22:30:28] <Dark_Shikari> WHAT? [22:30:32] <Dark_Shikari> THE SPEC MANDATES THIS? [22:32:40] <mru> apparently [22:32:42] <astrange> at least it was only in one spec [22:33:03] <mru> why weren't you here a few minutes ago? [22:33:12] <astrange> coincidence [22:33:24] <mru> conspiracy [22:33:25] <astrange> can you do an idct_dc_plus_last that handles the mismatch and still have it be simple? [22:34:21] <Dark_Shikari> yes [22:34:32] <Dark_Shikari> it'd be complicating it just for mpeg-2 though [22:34:39] <Dark_Shikari> and would make the rest of the code slower because you'd have to check it [22:37:15] <bcoudurier> interesting, work on mpeg-2 coming up ? [22:37:46] <Dark_Shikari> we want to add an idct_dc for mpeg-alike codecs [22:38:05] <Dark_Shikari> i.e. start merging some of the changes I made in my ipad-optimized flv decoder [22:38:58] <bcoudurier> that is cool [22:39:00] <Dark_Shikari> bcoudurier: so why does mpeg-2 have mismatch control [22:39:02] <Dark_Shikari> but nothing else does? [22:39:13] <mru> someone realised it was a silly idea [22:39:17] <bcoudurier> no idea [22:40:18] <bcoudurier> http://lists.mpegif.org/pipermail/mp4-tech/2002-June/000815.html [22:40:40] <bcoudurier> gary sullivan seems to speak in that thread [22:40:54] <BBB> Dark_Shikari: maybe some company had a patent on it and wanted to get cash fast? [22:41:37] <mru> ok, new patch [22:41:39] <bcoudurier> Then the complexity of every [22:41:39] <bcoudurier> implementation is reduced and no funny "mismatch control" [22:41:39] <bcoudurier> tweaking of coefficient values is needed. And every [22:41:39] <bcoudurier> decoder will produce exactly the same pictures. [22:43:26] <mru> "oddification" heh [22:47:32] <kierank> did anybody else not receive any of the emails in that mpeg-2 thread? [22:53:00] <bcoudurier> peloverde, congrats on PS [22:53:05] <peloverde> thanks [22:53:29] <bcoudurier> nice work [22:57:17] <bcoudurier> anybody know people at netflix ? [22:58:04] <Tjoppen> BBB: sry, was doing other stuff. I can re-check to see if it still causes a problem [22:58:13] <Dark_Shikari> I'd like to talk to them at some point, as I know they make some use of x264 [22:59:21] <Dark_Shikari> mru: just read that email. I love gary's response [23:00:21] <bcoudurier> astrange, after the pts patch, you might want to change the condition in do_video_out to <= 0.6 instead of 1.1 [23:01:29] <bcoudurier> and I belive it would be now better to have a flag AVFMT_HAS_PTS to formats having them [23:02:01] <bcoudurier> for avi you want to use dts and assume pts of outputed picture is dts and use a fifo [23:02:04] <BBB> Tjoppen: thanks [23:03:31] <astrange> yes i think so [23:03:40] <astrange> that would go better in libavformat [23:04:16] <bcoudurier> lately I found that png in mov is a nice way to do lossless with quicktime, is there any yuv lossless supported by quicktime ? [23:04:22] <bcoudurier> astrange, yes indeed [23:04:26] <CIA-92> ffmpeg: alexc * r23671 /trunk/libavcodec/aacsbr.c: aacsbr: Make dk signed. There is no point in it being unsigned. [23:05:04] <bcoudurier> ah astrange, I had a question for you, what happened to myuv and y420 fourccs in quicktime ? [23:06:06] <astrange> i never figured out what myuv was [23:06:19] <bcoudurier> I guess it was for the mpeg2 playback [23:06:28] <bcoudurier> 4:2:0 yuv planar or something [23:06:47] <astrange> yeah, it's "mpeg 4:2:0", but i don't see how it differed from y420 [23:06:57] <astrange> maybe the different chroma position [23:07:17] <astrange> they should both work in mov files [23:07:51] <astrange> i think the closest thing to a lossless yuv codec is prores (which is only mostly-lossless), there are some third-party ones [23:08:06] <astrange> like sheervideo, x264encoder lossless mode + perian, some ffvhuff encoder + perian [23:10:13] <peloverde> For all the talk of Macs being super good for multimedia, quicktime does have some strange holes [23:12:04] <bcoudurier> prores is 4:2:2 10bit [23:12:06] <bcoudurier> but it uses dct [23:12:47] <astrange> FCP and co ignore the system when they have to, but still have problems (compressor uses the same awful encoder as quicktime, i think they had to ship MainConcept to get bluray support) [23:12:59] <bcoudurier> it operates at very high bitrates so its "visually lossless" [23:13:19] <bcoudurier> I never got y420 working in quicktime X [23:15:25] <kierank> prores/aic and similar are there just for market segmentation [23:15:51] <astrange> hmm... file a bug [23:16:53] <bcoudurier> aic is 4:2:0 [23:25:09] <bcoudurier> astrange, do you have a working y420 sample ? [23:26:05] <astrange> nope [23:28:26] <RTFM_FTW> heh y420 shouldn't be difficult to work with anymore [23:28:32] <RTFM_FTW> (on Mac OS X) [23:28:49] <RTFM_FTW> specifically with APIs like IOSurface and friends [23:29:01] <RTFM_FTW> which are now documented :) [23:46:05] <peloverde> Is there a good way to use a tablegen in two different codecs? [23:46:42] <mru> whatever sintable does [23:46:45] <mru> and costable [23:46:57] <mru> those are used in several places [23:56:26] <bcoudurier> what's the best denoise filter around ? [23:57:01] <mru> memset(0) :-) [23:57:04] <Kovensky> <@bcoudurier> peloverde, congrats on PS <-- did it get enabled by default on mplayer btw?