[FFmpeg-devel-irc] IRC log for 2010-06-20

[irc at mansr.com]

[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/62b32cbd5ff1e6f20ae5c530a1f0380baa9b44f9
[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?