[FFmpeg-devel-irc] IRC log for 2010-05-07

[irc at mansr.com]

[00:05:27] <Dark_Shikari> wow.  ffmpeg mpeg-2 did a surprisingly good job
[00:08:35] <Dark_Shikari> http://mirror05.x264.nl/Dark/compare/mpeg2.png
[00:09:51] <Dark_Shikari> like, seriously, I'm shocked
[00:10:37] <Dark_Shikari> wait.  that isn't mpeg-2.  that's mpeg-1.
[00:12:18] <Dark_Shikari> so http://mirror05.x264.nl/Dark/compare/mpeg1.png
[00:13:26] <kierank> that looks quite good
[00:13:40] <Dark_Shikari> better than theora, worse than dirac.
[00:13:50] <Dark_Shikari> I underestimated michael's encoder =p
[00:15:53] <kierank> who needs theora then...
[00:16:02] <Dark_Shikari> In motion mpeg1 looks kinda bad
[00:16:03] <Dark_Shikari> very smeary
[00:16:05] <Dark_Shikari> but so does theora
[00:16:19] <Dark_Shikari> I do largely think that the reason ffmpeg is better is because of better algorithms though
[00:16:29] <Dark_Shikari> theora is definitely better than mpeg-1.
[00:16:59] <astrange> you could implement psy-rd in the mpegvideo encoder without much work, do that and see if it gets better
[00:17:14] <Dark_Shikari> AQ is probably more useful
[00:17:28] <Dark_Shikari> mbtree is also ridiculously powerful on this clip
[00:44:32] <peloverde> the faac inspired quantizer search doesn't use psybands? how did I not know this?
[01:25:54] <CIA-7> ffmpeg: michael * r23039 /trunk/libavfilter/ (vsrc_buffer.h vsrc_buffer.c):
[01:25:54] <CIA-7> ffmpeg: Add "Memory buffer source filter" from SOC.
[01:25:54] <CIA-7> ffmpeg: This is needed by the current SOC-ffmpeg.c code.
[01:38:29] <Compn> theora always reminds me of vivo and rv30 for some reason
[01:39:07] <Compn> am i the only person who cares about vivo support anymore?
[01:51:53] * Kovensky never even saw a vivo file
[01:58:32] <Compn> gahh
[01:59:31] <Compn> vivo was so out there, it was a top 4 in the format war (mov/asf/rm/vivo)
[01:59:41] <kierank> it was?
[01:59:42] <Compn> at least, i think thats how i remember it
[02:03:30] <peloverde> I remember the other three
[02:04:21] <kierank> there was some vividas thing iirc
[02:06:15] <Compn> The Vivo format, obsolete today, was one of the first to be designed and used for internet streaming.
[02:06:23] <Compn> well, according to wikipedia ;p
[02:16:40] <astrange> vividas, hm
[02:16:42] <astrange> http://vividas.com/xml/player/osxia32lib.jpeg
[02:17:14] <astrange> seems to be vivo + xiph something,
[02:17:56] <kierank> the files were obfuscated somehow
[02:18:01] <kierank> mru wrote a descrambler iirc
[06:06:59] <KotH> moikka moi
[06:10:01] <av500> ja
[06:10:42] <merbzt> tere homikost
[06:45:42] * elenril stabs new sidebar at google
[06:46:20] * av500 notices google sidebar
[06:46:34] <elenril> that thing is pure EVIL
[06:48:43] <Tjoppen> bah
[06:49:03] <Dark_Shikari> what's so wrong with it
[06:51:34] <elenril> i just don't like
[06:51:35] <elenril> it
[06:51:48] <av500> cant your greaemonkey it away?
[06:51:54] <av500> you
[06:52:11] <elenril> installing yet another ff extension => another 300 mb ram lost
[06:52:25] * elenril just got rid of adblock yesterday for great justice
[06:53:25] <elenril> also wtf is with the search buttong using system colors for text, but forcing white as background
[06:54:22] <Tjoppen> does anyone have/know where to find any documentation for the AliasHandle (alis) tag in MOV? the specs mention it, but doesn't contain its definition. googling around didn't help
[06:55:00] <Tjoppen> reverse engineering what the demuxer does only resulted in the file being playable in ffplay, not any other player :/
[06:58:06] <wbs> I had the same issue, I tried hacking qt-faststart to create compressed moov atoms.. and the official qt player didn't play it, while ffplay worked just fine. ;P
[06:58:24] <Dark_Shikari> qt is hardly a very good or compatible player =p
[06:59:06] <wbs> no, but I'd think it should handle stuff in the qt spec
[06:59:20] <wbs> on the other hand, I haven't got any clue whether cmov is part of any official spec
[06:59:38] <av500> elenril: was it you who wanted to seek in flac?
[07:00:44] <elenril> there are people who don't want to seek in flac?
[07:00:53] <elenril> (except mru)
[07:01:18] <av500> this is quick and dirty rejectware: http://ffmpeg.pastebin.com/YBxmYhc4
[07:01:32] <Yuvi> chances are that there's some other atom you're not taking into account, for alis you have to change both dref and mdhd off the top of my head
[07:02:24] <Dark_Shikari> ok, I need more comedy options for the codec comparison
[07:02:30] <Dark_Shikari> bink and svq1 are pretty awesome
[07:02:41] <av500> there is always libcaca
[07:02:42] <Dark_Shikari> mpeg1, mpeg4, xvid, x264, dirac, theora are all up
[07:02:47] <Yuvi> the specs say it's an AliasHandle, which helpfully appears to be an opaque struct...
[07:02:48] <Dark_Shikari> but those aren't very good for comedy options
[07:03:28] <av500> Dark_Shikari: there is a nice url for all of there?
[07:03:31] <elenril> av500: nice
[07:03:32] <av500> of these
[07:03:35] <Yuvi> msvideo 1
[07:03:37] <Dark_Shikari> http://mirror05.x264.nl/Dark/compare
[07:03:41] <elenril> btw what happened to negative pts stuff?
[07:03:47] <av500> ah right
[07:03:53] <av500> need to pick up on that
[07:04:32] <av500> Dark_Shikari: bitrate?
[07:04:38] <Dark_Shikari> 14mbps at 1080p50
[07:07:12] <av500> why is xvid less? it refused?
[07:07:26] <Dark_Shikari> ohit is?
[07:07:37] <av500> 9.2M, all others are like 17
[07:07:38] <Dark_Shikari> wait, whoa
[07:07:55] <Dark_Shikari> the fuck is with xvid
[07:08:06] <Dark_Shikari> it must have thought the fps was 25
[07:08:22] <Dark_Shikari> let me fix that
[07:09:04] <Dark_Shikari> well xvid is going to get a lot better now.
[07:12:58] <av500> hmm, mpeg1 scores higher than the t-codec here
[07:13:14] <av500> or is that mpeg2?
[07:13:49] <Dark_Shikari> mpeg-1
[07:13:51] <Dark_Shikari> same thing anyways
[07:14:10] <Dark_Shikari> and yes it does, probably because ffmpeg is a better encoder
[07:14:35] <av500> but mpeg1 patents expired, no? so why use T? :)
[07:14:51] <Dark_Shikari> not until 2015
[07:14:57] <Dark_Shikari> also, because it's not xiph
[07:15:13] <av500> also, I rate vp7 as the 2nd best to x264
[07:15:25] <av500> so, vp8 must be awesome!!!
[07:15:27] * av500 hides
[07:15:28] <Dark_Shikari> lol
[07:15:40] <Dark_Shikari> I haven't gotten out any decent competitors yet though =p
[07:16:14] <kshishkov> PNG?
[07:16:46] <av500> strange, the face of the front guy is better in vp7, the one of the woman in black is better in x264
[07:16:55] <av500> x264 likes women more..
[07:17:13] <kshishkov> it was tuned for Touhou Project clips anyway...
[07:17:31] <av500> well, she does not have huge eyes...
[07:17:49] <kshishkov> it will be fixed in upcoming version of x264
[07:18:46] <av500> I want x264 to replace the lead female actor in every movie with River Tam
[07:20:26] <Dark_Shikari> I thought megan fox was the usual target of that
[07:20:34] <ohsix> thumbsy
[07:20:54] <elenril> she does not have huge eyes << at least she has a hat
[07:20:59] <Tjoppen> oops, forgot about my question here
[07:21:24] <Tjoppen> but yeah, the qt spec is quite lacking, despite (or because of?) its large scope
[07:21:35] <av500> Dark_Shikari: I expect it to be a configure option
[07:33:59] <kierank> Tjoppen: you could also on the mov mailing list; maybe even mp4-tech if you want
[07:36:16] <Tjoppen> I'm going to try staring at hexdumps of proper files muxed by final cut pro first
[07:38:36] <mru> Dark_Shikari: where did the pics go?
[07:39:46] <Dark_Shikari> mru: moved, I'm going to do a proper blind psy test on doom9
[07:41:07] <Dark_Shikari> http://forum.doom9.org/showthread.php?p=1397981
[07:50:22] <superdump> yey for svt
[07:50:24] <superdump> :)
[07:50:42] <Dark_Shikari> and 65mm film and absurdly short exposure times
[07:50:56] <kierank> hehe "VP8 (if you have the encoder for this, please contact me directly and we can arrange for just the decoded output to be uploaded)"
[07:51:21] <kierank> but yes afaik there are many non-google entities with an encoder
[07:51:34] <spaam> superdump: what did svt do this time ? :)
[07:52:07] <Dark_Shikari> spaam: create the most insanely high quality 2160p sources ever
[07:52:31] * superdump looks forward to the results
[07:52:49] <spaam> Dark_Shikari: ok :D
[07:55:19] <mru> Dark_Shikari: why mpeg1?
[07:55:22] <mru> why not mpeg2?
[07:55:32] <mru> does mpeg1 even allow such resolutions?
[07:57:50] <Dark_Shikari> ffmpeg defaulted to mpeg1
[07:57:58] <Dark_Shikari> and I doubt mpeg2 will give any different results
[07:58:02] <Dark_Shikari> they're nigh-identical on progressive content
[07:58:08] <mru> sure
[07:58:18] <Dark_Shikari> also, for some reason, mpeg-1 had more coherent motion vectors (less smearing) in ffmpeg than mpeg-4
[07:58:19] <mru> ffmpeg doesn't encode D-frames iirc
[07:58:31] <Dark_Shikari> maybe it's MV costs/mv pred
[07:58:34] <Dark_Shikari> wtf is a d-frame
[07:58:40] <mru> something they dropped in mpeg2
[07:58:53] <Dark_Shikari> what is it though
[07:59:02] <mru> don't remember
[07:59:12] <kierank> dc only frame, to aid fast seeking
[07:59:21] <Dark_Shikari> wait what
[07:59:32] <kierank> http://en.wikipedia.org/wiki/MPEG-1#D-frames
[07:59:33] <Dark_Shikari> wouldn't dc only look a bit crap?
[07:59:36] <mru> sounds useless
[07:59:50] <kierank> well consider the crap equipment at the time
[08:09:01] <CIA-7> ffmpeg: michael * r23040 /trunk/libavformat/asfdec.c:
[08:09:01] <CIA-7> ffmpeg: Favor chunk size over hitting the correct position after reading the chunk size in asf.
[08:09:01] <CIA-7> ffmpeg: Fixes issue1923
[08:09:10] <Dark_Shikari> oh yeah, so anyone want to fix theora decoding?
[08:09:12] <Dark_Shikari> currently borked
[08:09:18] <Dark_Shikari> decoder ignores the pixel offset
[08:09:27] <mru> oh that misfeature
[08:09:28] <Dark_Shikari> i.e. the cropflags
[08:09:35] <Dark_Shikari> mru: h264 has the same feature
[08:09:45] <mru> still a misfeature
[08:09:51] <Dark_Shikari> true.
[08:09:53] <mru> you only need bottom/left cropping
[08:09:56] <mru> never top/right
[08:10:00] <Dark_Shikari> yeah but theora decoder ignores bottom too.
[08:10:03] <mru> s/left/right
[08:10:36] <Dark_Shikari> this should really be fixed before 0.6
[08:14:10] <superdump> then poke siretart about it
[08:14:30] <mru> and Yuvi
[08:15:41] <Dark_Shikari> it was responsible for fucking up MSU's theora test btw
[08:15:51] <Dark_Shikari> they got hliariously low psnr/ssim scores on their 1080p clip
[08:15:56] <Dark_Shikari> because ffmpeg ignored the offsets
[08:16:20] * mru blames them for not checking better
[08:16:27] <mru> and for using the stupid offset in the first place
[08:16:52] <Dark_Shikari> yes its their fault for being idiots
[08:32:21] <kshishkov> isn't that a side effect of using Windows DIB decoding order somewhere?
[08:33:32] <mru> so don't do that then
[08:33:46] <kshishkov> ok, I won't, now tell Monty
[08:33:55] <mru> don't be monty then
[08:34:03] <kshishkov> I'm not
[08:34:46] <wbs> dib decoding order, as in, bottom to top?
[08:35:15] <kshishkov> yes
[08:35:22] <wbs> gah
[08:35:24] <kshishkov> in traditional Russian way
[08:35:27] * wbs facepalm
[08:35:41] <kshishkov> IIRC it occurs in some lousy JPEG hacks too
[08:42:49] <mru> no jpeg hack can beat the mad stuff that ijg guy is dreaming up
[08:43:54] <kshishkov> but that's also jpeg hacks
[08:44:31] <kshishkov> or do you treat it like theorazed JPEG?
[08:45:17] <mru> I wonder if that guy reads my blog...
[08:45:22] <mru> probably not
[08:45:58] <kshishkov> why should he read anything?
[08:46:16] <mru> when he can make stuff up
[08:47:18] <mru> he and monty should get together and design a codec
[08:47:33] * kshishkov thinks that Netherlands is the biggest supplier of popular information medium
[09:02:18] <Dark_Shikari> hmm.  xvid beats dirac.
[09:02:37] * Dark_Shikari thinks the decision to switch fullpel-only in dirac by default was _retarded_
[09:02:49] <av500> Dark_Shikari: url?
[09:02:55] <av500> (for the xvid)
[09:03:28] <Dark_Shikari> http://mirror05.x264.nl/Dark/Flash/compare/xvid.png
[09:05:43] <mru> fixed the bitrate?
[09:05:53] <Dark_Shikari> yes
[09:05:58] <Dark_Shikari> beats the shit out of ffmpeg mpeg4 too
[09:06:05] <Dark_Shikari> largely because it doesn't have the lolsmearing
[09:06:51] <mru> rather bad ringing though
[09:07:03] <Dark_Shikari> ringing?  in my 8x8dct-based video format?
[09:07:12] <superdump> Dark_Shikari: hmm, vp7 doesn't actually look too bad compared to theora
[09:07:18] <mru> and what's the patchy quality of the grass with all the codecs?
[09:07:29] <mru> superdump: _anything_ looks good beside theora
[09:07:30] <Dark_Shikari> mru: well, except for x264
[09:07:52] <Dark_Shikari> grass looks outright flawless in x264
[09:07:52] <mru> yes, except that
[09:08:01] <Dark_Shikari> two reasons
[09:08:03] <Dark_Shikari> AQ, MB-tree
[09:08:08] <Dark_Shikari> the grass predicts nearly perfectly from frame to frame
[09:08:13] <Dark_Shikari> unlike the trees, which occlude
[09:08:20] <mru> why do they turn some parts into a total blurfest and leave loads of detail in others?
[09:08:24] <Dark_Shikari> Thus, MB-tree says "make the grass really high quality, because it predicts so well between frames"
[09:08:32] <Dark_Shikari> mru: no AQ
[09:08:40] <mru> I mean the grass between the path and the water
[09:08:44] <Dark_Shikari> Yes
[09:09:09] <av500> Dark_Shikari: I will blog post now that theora beats svq1...
[09:09:13] <Dark_Shikari> lol
[09:09:20] <Dark_Shikari> I think we knew that
[09:09:36] <mru> why is the quality so variable across the grass?
[09:09:46] <Dark_Shikari> as I said, lack of AQ
[09:10:04] <Dark_Shikari> constant quantizer != constant visual quality
[09:10:28] <Dark_Shikari> if you have some value X, and you quantize it to some level of precision, the relative error depends on the magnitude of X
[09:10:35] <Dark_Shikari> thus, small values of X will have high relative error
[09:10:38] <Dark_Shikari> and large values will have low relative error
[09:10:47] <Dark_Shikari> thus, small values of X need to be quantized to higher precision than large values of X
[09:10:57] <Dark_Shikari> thus, to keep constant relative error, you need variable quantizer.
[09:10:58] <Dark_Shikari> qed.
[09:11:43] <mru> xvid does better on the bright areas
[09:11:55] <Dark_Shikari> constant quant codecs do better on the bright areas
[09:12:02] <Dark_Shikari> With the bits they stole from the grass ;)
[09:12:18] <mru> I mean the brighter parts of the grass
[09:12:22] <mru> are better than the dark parts
[09:12:25] <mru> of the grass
[09:12:26] <Dark_Shikari> Yes
[09:12:29] <Dark_Shikari> because they're higher-contrast
[09:12:32] <Dark_Shikari> higher-variance
[09:12:39] <Dark_Shikari> thus, they have lower relative error
[09:12:51] <av500> wanst dirac supposed to be good, but cpu extreme?
[09:12:53] <mru> x264 has some horrible ringing on the people
[09:13:12] <Dark_Shikari> it has lots of ringing everywhere
[09:13:16] <Dark_Shikari> that's just where it's most noticable
[09:13:25] <mru> yes
[09:13:28] <Dark_Shikari> the rest of the image masks it awa
[09:13:29] <Dark_Shikari> *away
[09:13:40] <Dark_Shikari> also, mb-tree hurts the people
[09:13:45] <Dark_Shikari> because they don't predict well between frames
[09:13:46] <mru> it's hard to tell ringing from actual grass
[09:13:47] <Dark_Shikari> (sorry, people)
[09:13:57] <mru> are they women by any chance?
[09:14:04] * mru always had trouble predicting women
[09:14:06] <Dark_Shikari> lol
[09:15:07] <Dark_Shikari> the really amazing thing is that x264 clip has quants through the roof (35-40)
[09:15:14] <Dark_Shikari> but you wouldn't guess it from the visual results.
[09:15:48] <Dark_Shikari> I'm curious how well the h265 proposals do
[09:17:35] * Kovensky never heard of anything about h265 other than "it exists"
[09:17:39] <Kovensky> or "will exist"
[09:17:59] * av500 waits for h666
[09:18:20] <Dark_Shikari> there are about 25 proposals
[09:18:30] <Dark_Shikari> the bbc one looks good.
[09:18:58] <superdump> gooooo bbc
[09:19:05] <superdump> if they actually make something good
[09:19:08] <astrange> http://ftp3.itu.int/av-arch/jctvc-site/2010_04_A_Dresden/ ?
[09:19:14] <Dark_Shikari> maybe I should have taken their offer to work on it
[09:19:26] <superdump> Dark_Shikari: really? 35-40? i would _not_ have guessed that at all
[09:19:29] <superdump> that's impressive
[09:19:29] <Dark_Shikari> astrange: yes
[09:19:39] <Dark_Shikari> A124 is the interesting one
[09:19:40] <Dark_Shikari> Oh.
[09:19:43] <Dark_Shikari> A125 was the real BBC one
[09:19:49] <Dark_Shikari> T. Davies' one
[09:20:46] <kierank> have you tried the A125 software on that svt clip?
[09:20:55] <Dark_Shikari> superdump: yeah, P-frames are 30-45, centered around 35-45
[09:20:58] <Dark_Shikari> kierank: software?
[09:21:12] <kierank> I mean A124
[09:21:12] <Dark_Shikari> the proposal came with software
[09:21:13] <Dark_Shikari> ?
[09:21:22] <kierank> a124 has software
[09:21:27] <Dark_Shikari> oh sweeet
[09:21:32] <Dark_Shikari> will do that
[09:21:36] <CIA-7> ffmpeg: michael * r23041 /trunk/libavfilter/vf_scale.c: Support setting flags for sws.
[09:21:46] <Dark_Shikari> superdump: 40-45 quant in the b-frame
[09:21:50] <superdump> :)
[09:21:55] <superdump> x264 voodoo magic
[09:22:16] <superdump> it's clear x264 wins, but maybe vp8 won't be godawful
[09:22:25] <Dark_Shikari> I think it will be.  too psnr-optimized
[09:22:48] <superdump> but maybe the if the specs are opened and the source opened, something can be done about it
[09:23:18] <Dark_Shikari> Maybe.
[09:23:20] <CIA-7> ffmpeg: michael * r23042 /trunk/libavfilter/ (Makefile allfilters.c): Enable vsrc_buffer
[09:23:29] <Dark_Shikari> I think it's just going to cause even more incompatibility
[09:23:32] <Dark_Shikari> apple and microsoft won't adopt it
[09:23:33] <astrange> it sounds like there might not be a base to improve from
[09:23:37] <Dark_Shikari> and yeah, that
[09:23:38] <merbzt> maybe the flying pigs are getting back from skiing vacation in hell also
[09:23:43] <astrange> if it doesn't have b-frames or better delta quant
[09:23:59] <astrange> (i know it doesn't have b-frames, but it might at least have skippable ones)
[09:24:00] <kshishkov> merbzt: you mean Iceland?
[09:24:14] <merbzt> kshishkov: about right
[09:24:15] <Dark_Shikari> oh sweet.  kierank, they have source
[09:24:35] <kierank> C++ ;)
[09:24:57] <lu_zero> as usual...
[09:25:05] * lu_zero points dirac
[09:28:50] <Dark_Shikari> what.  only a visual studio project file? :/
[09:29:36] <kierank> that too
[09:29:48] <Dark_Shikari> at least it compiled without errors
[09:30:05] <Kovensky> lol
[09:30:19] <mru> that's highly unusual
[09:31:09] <Dark_Shikari> .... this is going to take a long, long time.
[09:32:00] <Dark_Shikari> all of their samples are absurdly short
[09:32:14] <Dark_Shikari> this doesn't bode well for encoding a 1080p sample that's 500 frames
[09:32:36] <Dark_Shikari> wooohooo singlethreaded encoder with no asm
[09:32:46] <mru> the sample needs to be a few times longer than your rate control window
[09:32:54] <Dark_Shikari> it does constant qp only
[09:32:56] <lu_zero> btw what do they propose?
[09:32:57] <superdump> Dark_Shikari: well, they only need to encode one gop, right? and that's at most (being generous) 20 frames, right?
[09:33:06] <superdump> how many frames do they need?:)
[09:33:20] <Dark_Shikari> 24 frames is enough for anyone.
[09:33:33] * Dark_Shikari opens motion search file
[09:33:36] * Dark_Shikari sees 4000 lines of C++
[09:33:39] * Dark_Shikari runs like a little girl
[09:33:45] <mru> pirate rips use ~250-frame gops
[09:33:51] <kierank> a124 has rotation in it
[09:33:54] <lu_zero> I'd run faster
[09:33:58] <Dark_Shikari> holy fuck, a124 even has rotation?
[09:34:02] <superdump> i liked one of the comments on a slashdot article about ceph, the very high capacity distributed filesystem
[09:34:13] <superdump> something like 640 petabytes is enough for anyone
[09:34:14] <Dark_Shikari> a guy implemented that in x264 the other day
[09:34:24] <Dark_Shikari> it gave ~9% compression improvement on elephant's dream, apparently
[09:34:27] <Dark_Shikari> (and in libavcodec)
[09:34:33] <superdump> nifty
[09:34:39] <mru> and you can very well need many gops to properly test the rate control
[09:34:41] <superdump> how does that work?
[09:34:45] <Dark_Shikari> I don't fully trust his results, but either way it's pretty cool
[09:35:00] <Dark_Shikari> mru: I just use constant quality for any encoder which doesn't give good results ratecontrol-wise
[09:35:13] <iive> Dark_Shikari: h264 have rotation too?
[09:35:30] <mru> Dark_Shikari: but constant quality is mostly useless for practical purposes
[09:35:30] <Dark_Shikari> iive: no
[09:35:42] <mru> you almost always have some constraints
[09:35:44] <Dark_Shikari> mru: I'd say capped constant quality is useful for the vast majority of purposes
[09:36:25] <Dark_Shikari> oooh fun, they have in-intra motion vectors
[09:36:29] <superdump> for audio (music) constant quality is fine because the variability is insignificant compared to the space available on the storage medium
[09:36:31] <superdump> usually
[09:36:40] <mru> we're talking about video
[09:36:43] <superdump> right
[09:36:49] <mru> video will always be pushing the limits
[09:36:52] <mru> all the limits
[09:37:08] <superdump> i'm still not fond of constant quality modes for video
[09:37:14] <mru> instantaneous rate, total size, decoder speed etc
[09:37:22] <superdump> because some content will come along that will be much larger than i wanted
[09:37:31] <Dark_Shikari> oh dear.
[09:37:33] <Dark_Shikari> it's been 10 minutes
[09:37:36] <Dark_Shikari> output file is still 0kb
[09:37:39] <mru> lol
[09:37:41] <superdump> :)
[09:37:42] <Dark_Shikari> oh nevermind, it's 96kb now.
[09:37:46] <av500> Dark_Shikari: extrapolate
[09:37:50] <superdump> lol
[09:37:54] <Dark_Shikari> POC    0 ( I-SLICE, QP 35 )     811576 bits [Y 34.1849 dB    U 35.6192 dB    V 3
[09:37:57] <Dark_Shikari> 7.8339 dB]  [ET   333 ] [L0 ] [L1 ]
[09:38:00] <Dark_Shikari> One frame outputted, woohoo
[09:38:11] <kierank> lol
[09:38:13] <Dark_Shikari> And since it has only constant quant, getting the right bitrate is going to require newton's method
[09:38:29] * Kovensky pats D_S
[09:38:39] <Dark_Shikari> oh yeah, and this is using diamond motion search
[09:38:40] <iive> Dark_Shikari: somehow i hoped it would be 10 minutes in 94kb.
[09:38:41] <Dark_Shikari> not even full search
[09:38:58] <Dark_Shikari> oh wait, that was an I-frame.  I wonder how long P-frames take.
[09:39:26] <Kovensky> iive: can x264 do that for an absurdly long gop blankclip with dedup? =p
[09:39:44] <Dark_Shikari> "ET" I wonder if that means encoding time
[09:39:59] <mru> I think we all know what ET means...
[09:40:19] <mru> was this codec submitted by the area51 guys?
[09:40:36] <Dark_Shikari> samsung.  close enough
[09:40:51] <mru> those crazy koreans
[09:41:00] <Dark_Shikari> and bbc.
[09:41:19] <av500> those crazy brits
[09:41:32] <mru> the koreans are good people
[09:41:40] <mru> don't know if the same can be said of the brits
[09:41:47] <Dark_Shikari> the brits are funny people
[09:42:04] <Dark_Shikari> kierank: you deleted nutjobs.png!
[09:42:44] <kierank> gimme a minute to restore it
[09:43:17] <Dark_Shikari> still encoding the first P-frame.
[09:43:26] <kierank> https://dl.dropbox.com/u/2701213/nutjobs.PNG
[09:43:30] <Dark_Shikari> I think by the time this is done h265 will already be out
[09:43:37] <Dark_Shikari> mru: see above link
[09:43:58] <Kovensky> Dark_Shikari: what was it tuned for, cif? =p
[09:43:59] <kshishkov> Dark_Shikari: aren't they going to evaluate all encoders by committee?
[09:44:13] <CIA-7> ffmpeg: michael * r23043 /trunk/ffmpeg.c: avfilter support for ffmpeg
[09:44:14] <Dark_Shikari> a very very slow committee
[09:44:25] <Dark_Shikari> \o/
[09:44:28] <Dark_Shikari> \o/ \o/ \o/
[09:44:29] <wbs> \o/
[09:44:32] <Dark_Shikari> \o/ \o/ \o/ \o/ \o/
[09:45:00] <astrange> http://ftp3.itu.int/av-arch/jctvc-site/2010_04_A_Dresden/JCTVC-A023.doc want to order 4k test sequences?
[09:45:08] <astrange> or maybe you have to be in jvtvc
[09:45:26] <Dark_Shikari> let's take bets on the encoding time of this first P-frame at 1080p
[09:45:39] <kshishkov> well, if you test 16CIF or better you may end doing bad job on sub-DVD videos
[09:45:47] <Dark_Shikari> I will bet 800 seconds.
[09:46:18] <av500> Dark_Shikari: at least they pinned large  target marks at the right place...
[09:46:40] <Dark_Shikari> and I thought "seconds per frame" was slow
[09:46:44] <av500> I like it how ffplay handles the dirac sample: http://imagebin.ca/view/39LOqr2.html
[09:46:55] <av500> almost prefer it to the bink rendering
[09:46:59] <Dark_Shikari> ffmpeg handles it fine here
[09:47:08] <kshishkov> Dark_Shikari: well, you'll get reasonable "annual frames" rate though
[09:47:21] <Dark_Shikari> ugh, I think my 800 will end up being wrong
[09:49:04] <Dark_Shikari> >RD picture selection
[09:49:05] <Dark_Shikari> oh dear.
[09:49:11] <Dark_Shikari> >Max QP for RD picture selection
[09:49:13] <Dark_Shikari> oh dear oh dear.
[09:49:23] <Dark_Shikari> I get the feeling they're doing bruteforce RD of each B-frame's QP
[09:49:38] <mru> av500: wtf is that?
[09:50:08] <kshishkov> "it's your FFmpeg decoder on drugs^W^Wmiscompiled with icc"
[09:50:17] <av500> that is my ~1y old system ffmpeg
[09:50:50] <av500> ffmpeg-0.5.20592svn-0.pm.1.5
[09:50:55] <Dark_Shikari> god damn this thing is so slow that x264 better lose to it
[09:51:19] <astrange> decoding is 2.4x slower than jm, not surprising
[09:51:37] <Dark_Shikari> 12-tap luma interpolation
[09:51:40] <Dark_Shikari> <3
[09:51:41] <mru> ouch
[09:51:49] <Dark_Shikari> up to 64x64 transform size
[09:51:59] * mru wants wider simd
[09:52:04] <mru> much wider
[09:52:08] <Dark_Shikari> Yeah, at least this will make wide SIMD useful
[09:52:26] <mru> 128 bits is starting to look small
[09:52:27] <astrange> much wider than avx and you'll have a gpu
[09:52:38] <Dark_Shikari> astrange: gpu isn't much wider than avx
[09:52:43] <Dark_Shikari> usually it's like 16-wide or 32-wide
[09:52:46] <mru> hopefully it can be done in 16-bit arith
[09:52:49] <Dark_Shikari> which is only 16*8 = 128-bit
[09:52:51] <Dark_Shikari> or 256-bit
[09:52:57] <Dark_Shikari> mru: yes it can
[09:53:04] <Dark_Shikari> it's a combination of a 16-bit 16x16 transform, plus lifting
[09:53:13] <astrange> but there's a very wide pipeline for each warp
[09:53:18] <astrange> not sure how wide
[09:53:20] <Dark_Shikari> 16 or 32 is "very wide"?
[09:53:38] <Dark_Shikari> 970 seconds!  The first P-frame finished!
[09:53:46] <Dark_Shikari> POC    8 ( P-SLICE, QP 36 )     501680 bits [Y 34.1692 dB    U 35.5716 dB    V 3
[09:53:49] <Dark_Shikari> 8.4446 dB]  [ET   970 ] [L0 0 ] [L1 ]
[09:54:13] <iive> so ET is elapsed time ?
[09:54:21] <mru> faster than rendering BBB at least
[09:54:23] <Dark_Shikari> I think so.
[09:54:55] <iive> Dark_Shikari: i think it would be faster if you port/write some asm, while waiting for the next 10 frames.
[09:54:58] <Dark_Shikari> lol
[09:55:02] <Dark_Shikari> that's probably true.
[09:55:12] <Dark_Shikari> pengvado said it was faster to optimize JM than to wait for it to finish
[09:55:18] <av500> binary patch the running encoder....
[09:55:41] <Dark_Shikari> also, we apparently scared the shit out of the x264 ppc maintainer
[09:55:44] <Dark_Shikari> I showed him the NV12 patch
[09:55:46] * mru like binpatching stuff
[09:55:55] <Dark_Shikari> and said "you need to port the altivec"
[09:56:07] <mru> who's the maintainer?
[09:56:13] <Dark_Shikari> guilliame poirier
[09:56:14] <astrange> http://www.mysif.ru/Files/SIF1_v_1_01.exe you can encode through that while you're waiting
[09:56:19] <Dark_Shikari> (I can never spell that right)
[09:56:27] <mru> guillaume?
[09:56:28] <Dark_Shikari> astrange: oh, good point.  I should totally test SIF1
[09:56:49] <Dark_Shikari> astrange: encoder and decoder?
[09:56:58] <astrange> i haven't looked but i think so
[09:57:13] <Dark_Shikari> oh, its vfw
[09:58:05] <Dark_Shikari> >height must be a multiple of 16
[09:58:06] <Dark_Shikari> fuck you
[09:58:23] <Dark_Shikari> ugh, now I need code to pad the bottom of the frame in avisynth by repeating the last line
[09:59:16] <Dark_Shikari> aha.  I can use stackvertical because I'm a horrible person
[09:59:35] <astrange> stackvertical(c, flipvertical(c))
[10:01:01] <Dark_Shikari> I did:
[10:01:02] <Dark_Shikari> a=b.converttorgb().crop(0,1080-1,1920,1)
[10:01:02] <Dark_Shikari> a=stackvertical(a,a)
[10:01:02] <Dark_Shikari> a=stackvertical(a,a)
[10:01:02] <Dark_Shikari> a=stackvertical(a,a).converttoyv12()
[10:01:04] <Dark_Shikari> stackvertical(b,a)
[10:01:07] <Dark_Shikari> aka "lol"
[10:02:53] <Dark_Shikari> woohoo, sif1 is about 1000 times faster than a124
[10:03:20] <Dark_Shikari> mru: by the way, an nv12 internal representation is faster than yv12 for many purposes.
[10:03:28] <Dark_Shikari> especially on cpus with small caches.  hint hint.
[10:03:35] <iive> i missed the introduction. are these h265 candidates?
[10:03:44] <Dark_Shikari> sif1 is some random russian guy's codec
[10:03:48] <Dark_Shikari> a124 is an h265 candidate from bbc+samsung
[10:03:49] <CIA-7> ffmpeg: michael * r23044 /trunk/libavfilter/ (avfilter.c avfilter.h vf_scale.c vsrc_buffer.c defaults.c): Try to keep track of interlaced and top field first.
[10:04:14] <Dark_Shikari> a124 has encoded two frames so far.
[10:05:36] <mru> Dark_Shikari: nv12, is that the one with an interleaved uv plane?
[10:05:44] <Dark_Shikari> yes
[10:05:56] <mru> yeah, that should be faster in some cases
[10:06:02] <Dark_Shikari> it's 1% faster in x264, overall
[10:06:04] <Dark_Shikari> on x86
[10:06:09] <iive> Dark_Shikari: are you using it as native format?
[10:06:12] <Dark_Shikari> 4% faster on Some Magical Mystery CPU That Pengvado Can't Talk About
[10:06:13] <Dark_Shikari> iive: yes
[10:06:47] <mru> it also lets you do both chroma planes in parallel sometimes
[10:07:00] <Dark_Shikari> yes it helps for chroma motion search
[10:07:04] <Dark_Shikari> but nobody does fullpel chroma ME anyways
[10:07:15] <iive> Dark_Shikari: have you tested to have one line luma and one line chroma samples, using stride/linesize arithmetic?
[10:07:33] <Dark_Shikari> that won't help
[10:07:36] <siretart> superdump:  Dark_Shikari: fix it in trunk and make a remark in the commit message!
[10:07:41] <mru> it's not just in ME it's useful
[10:07:52] <Dark_Shikari> mru: chroma MC is complicated enough that it doesn't help there either,
[10:07:55] <Dark_Shikari> since you have to unpack to 16-bit anyways
[10:07:58] <Dark_Shikari> It does help in deblocking though.
[10:08:12] <mru> and sometimes transform
[10:08:31] <Dark_Shikari> no
[10:08:42] <Dark_Shikari> requires way too much munging for that
[10:08:53] <Dark_Shikari> in x264, we store frame data as NV12
[10:08:57] <Dark_Shikari> but cache data as YV12
[10:09:09] <Dark_Shikari> chroma MC thus effectively performs deinterleaving
[10:09:20] <mru> I'm not talking about x264 specifically
[10:09:36] <mru> 128-bit simd can do two 4x4 transforms in parallel
[10:09:55] <Dark_Shikari> you can do that without NV12
[10:10:04] <mru> sure
[10:10:09] <Dark_Shikari> it doesn't help you there imo
[10:10:21] <mru> doesn't harm either
[10:10:28] <Dark_Shikari> er... yes it does
[10:10:33] <mru> why?
[10:10:34] <Dark_Shikari> interleaved data is more messy to transform
[10:10:41] <Dark_Shikari> you can't do horizontal arithmetic as easily
[10:10:55] <mru> suppose my simd doesn't do horizontal arithmetic
[10:10:56] <Dark_Shikari> because a horizontal arithmetic operation becomes an operation between U and V
[10:11:02] <Dark_Shikari> instead of between adjacent U/V
[10:11:06] <Dark_Shikari> Sure, in that case maybe
[10:11:08] <Dark_Shikari> but that's shitty simd =p
[10:11:15] <mru> it's non-x86 simd
[10:11:29] <Dark_Shikari> blackfin?
[10:11:34] <mru> arm, ppc, anything
[10:11:45] <kshishkov> SWAR too
[10:11:49] <Dark_Shikari> neon has horizontal arithmetic
[10:11:50] <Dark_Shikari> vhadd, etc
[10:11:57] <mru> that's average
[10:12:07] <mru> vertical average
[10:12:07] <Dark_Shikari> er, whatever the one is that adds horizontally
[10:12:19] <mru> the only horizontal operation is vpadd
[10:12:22] <mru> pairwise add
[10:12:26] <Dark_Shikari> that's it?
[10:12:32] <mru> not useful in transform
[10:12:36] <Dark_Shikari> good thing transpose is fast then I guess
[10:12:55] <mru> it transposes pretty quickly, yes
[10:13:15] <mru> and the vertical ops are much better than x86
[10:13:30] <mru> vaddl and vaddw are very useful
[10:13:46] <mru> add and widen resp add to wide
[10:14:01] <mru> saves a separate unpack
[10:18:16] <CIA-7> ffmpeg: mru * r23045 /trunk/configure:
[10:18:16] <CIA-7> ffmpeg: SPARC: disable VIS for Niagara CPU
[10:18:16] <CIA-7> ffmpeg: The Niagara/T1 supports only a subset of VIS, and even this is very slow.
[10:18:16] <CIA-7> ffmpeg: Patch by Michael Kostylev <michael kostylev gmail>
[10:28:46] <Dark_Shikari> sif1 is done
[10:28:59] <Dark_Shikari> http://mirror05.x264.nl/Dark/Flash/compare/sif1.png
[10:29:36] <mru> a bit blurry
[10:29:53] <Dark_Shikari> It's surprisingly good
[10:30:00] <mru> yeah, it's not too bad
[10:30:05] <mru> much better than most
[10:30:10] <mru> what is that codec?
[10:30:11] <Dark_Shikari> oh, forgot to crop it
[10:30:13] <Dark_Shikari> sif1
[10:30:24] <mru> wtf is that?
[10:30:35] <Dark_Shikari> this random russian guy's custom codec
[10:30:44] <mru> oh, one of those
[10:30:56] <Dark_Shikari> Yeah.
[10:31:03] <Dark_Shikari> It's based on very large DCTs and an adaptive interpolation filter
[10:31:12] <mru> let me guess, no spec, no source
[10:31:18] <Dark_Shikari> yes source for the decoder
[10:31:21] <Dark_Shikari> Which is mostly inline asm.
[10:31:26] <mru> about to say
[10:31:37] <Dark_Shikari> It's One Of Those.
[10:31:41] <Dark_Shikari> But the idea is pretty sound.
[10:31:46] <Dark_Shikari> he isn't stupid
[10:31:58] <mru> that's why it's better than theora
[10:32:07] <Dark_Shikari> I'm really curious how it does in blind tests on the 0-10 scale
[10:32:11] <Dark_Shikari> it's much less sharp than vp7
[10:32:17] <Dark_Shikari> But it doesn't lose detail as badly in many areas
[10:32:22] <Dark_Shikari> IMO it may actually be better than vp7
[10:32:45] <mru> less sharp is better than full of block edges
[10:32:45] <Dark_Shikari> the quality is much more consistent
[10:33:07] <Dark_Shikari> x264 of course beats the shit out of it, but that's hardly surprising
[10:34:08] * av500 didnt know thresh wrote a codec in secret...
[10:34:09] <Dark_Shikari> damn, still only 2 frames done on the h265 encode
[10:34:18] <Dark_Shikari> I managed to do the entire SIF1 test in the time that one h265 frame was encoding
[10:35:03] <thresh> sounds like Dark_Shikari wrote one too just yet
[10:36:25] <Dark_Shikari> hmm, what other silly codecs can I test?
[10:36:26] <thresh> or does h265 exist?
[10:36:32] <mru> no
[10:36:34] <Dark_Shikari> thresh: I'm using the samsung+bbc A124 proposal
[10:36:39] <Dark_Shikari> and calling it "h265" for short
[10:36:43] <thresh> mmkay
[10:37:05] <mru> the final h265 will be some random picking of pieces from the various proposals
[10:37:08] <Dark_Shikari> yup
[10:37:24] <mru> such that everybody gets their share of patents in the pool
[10:37:26] <av500> Dark_Shikari: sif is patented! mozilla will never adopt it
[10:38:08] <Dark_Shikari> oh my god
[10:38:12] <Dark_Shikari> I just looked at their option handler
[10:38:16] <Dark_Shikari> the C++ one in A124
[10:38:21] <Dark_Shikari> They wrote their own option parser... using C strings.
[10:38:24] <Dark_Shikari> in a C++ program.
[10:38:35] <Dark_Shikari> It's like the worst possible combination of bad ideas ever.
[10:38:39] <thresh> maybe they just CP it
[10:38:48] <thresh> like, reusing code is good.
[10:40:14] * av500 assumes academic people suck at option parsers
[10:41:06] <mru> what's wrong with getopt?
[10:41:34] <mru> ~100 options ought to be enough for anyone
[10:43:15] <av500> hmmm "I assept the agreement (Download)", does it have a legal implication if I "assept" something?
[10:48:54] <Dark_Shikari> AGHHHHHHHHHHHHHHHH
[10:48:59] <Dark_Shikari> POC    4 ( B-SLICE, QP 37 )     158488 bits [Y 30.9774 dB    U 34.4570 dB    V 3
[10:49:02] <Dark_Shikari> 7.6592 dB]  [ET  2734 ] [L0 0 8 ] [L1 8 0 ]
[10:49:45] <Dark_Shikari> if I was involved in ITU I would disqualify these guys just for giving me an encoder that is so slow it's impossible to test
[11:10:04] <Tjoppen> hah. appearently my .mov files cause dumpster to segfault
[11:13:13] <Kovensky> your dumpster segfaults?
[11:16:22] <Tjoppen> it's a program for "diving into" MOV/MP4 files (heh)
[11:17:12] <Tjoppen> hexdump sort of thing. causing it to segfault is rather odd
[11:18:49] <Tjoppen> ah. "if (len&1) len += 1;", so I have to write a dummy NUL byte if the length is odd
[11:48:05] <CIA-7> ffmpeg: michael * r23046 /trunk/libavfilter/ (Makefile vf_pad.c allfilters.c): Add pad filter.
[11:51:47] <CIA-7> ffmpeg: mru * r23047 /trunk/configure:
[11:51:47] <CIA-7> ffmpeg: configure: update suncc SPARC CPU name mapping
[11:51:47] <CIA-7> ffmpeg: Patch by Michael Kostylev <michael kostylev gmail>
[11:52:54] <CIA-7> ffmpeg: michael * r23048 /trunk/ (configure tests/lavf-regression.sh): Enable libavfilter by default and fix pading for mxf-d10
[12:06:14] <CIA-7> ffmpeg: michael * r23049 /trunk/ffmpeg.c: Make sure get_filtered_video_pic() doesnt loose interlacedframe/ttf.
[12:17:13] <CIA-7> ffmpeg: michael * r23050 /trunk/ffmpeg.c:
[12:17:13] <CIA-7> ffmpeg: Remove messy pading hack in ffmpeg.c.
[12:17:13] <CIA-7> ffmpeg: Use avfilters if you want padding!
[12:43:27] <CIA-7> ffmpeg: stefano * r23051 /trunk/cmdutils.h: Document cmdutils.c:print_error().
[12:53:36] <CIA-7> ffmpeg: stefano * r23052 /trunk/doc/libavfilter.texi: Document the pad filter.
[13:01:45] <CIA-7> ffmpeg: michael * r23053 /trunk/libavfilter/vf_scale.c: c99 sucks. Replacing scanf("%i") by strtoul()
[13:24:15] <BBB> why can't I download from upload.mphq.hu anymore? koth?
[13:25:37] <mru> how are you accessing it?
[13:25:46] <kshishkov> usual permission problem
[13:26:02] <kshishkov> I've tried - some files from /incoming are downloading fine, some have 550 error
[13:26:47] <mru> can you tell me the name of one with a problem?
[13:26:52] <BBB> issue1502/
[13:26:54] <BBB> in incoming
[13:27:25] <BBB> I'm accessing it using the regular login, ftp://youknow@upload.mplayerhq.hu/
[13:27:36] <mru> try again
[13:27:42] <Dark_Shikari> so far the record is 4955 seconds for one frame
[13:27:45] <Dark_Shikari> :awesome: job samsung
[13:27:48] <BBB> that was quick
[13:27:54] <BBB> thanks mru
[13:27:56] <Dark_Shikari> I think their strategy is to make encoding take so long that everyone has to trust their tests on faith
[13:28:05] <mru> for some reason the file had absurd permissions
[13:28:06] <Dark_Shikari> since nobody has time to replicate their results
[13:30:11] * BBB has problems where his fingers want to send the email to sflc already, but his head  thinks he should wait a few minutes
[13:32:30] <mru> that file has ffmpeg written all over it
[13:34:00] <BBB> I know
[13:34:09] <BBB> I did nm and all symbols in my terminal were from ffmpeg
[13:34:12] <BBB> (without a grep)
[13:34:19] <BBB> which is a little funny and excessive
[13:34:40] <BBB> also, it's a radio app
[13:34:47] <BBB> why are there h264 symbols in it?
[13:34:52] <BBB> the thing doesn't even play video
[13:35:05] <Dark_Shikari> because disabling h264 doesn't disable the h264 stuff in dsputil?
[13:35:16] <BBB> hm...
[13:35:20] <BBB> fix it? :)
[13:35:47] <mru> some of that has been fixed
[13:35:56] <mru> I moved a bunch of h264 stuff out of dsputil
[13:36:06] <iive> isn't some of h264 stuff used by other codecs too?
[13:36:15] <mru> yes, those parts are still in dsputil
[13:36:18] <iive> svq3, vc1, rv34 ?
[13:37:56] <jai> btw, i still can't access samples.mphq :|
[13:38:21] <mru> jai: why is that?
[13:39:18] <jai> mru: HTTP request sent, awaiting response... 403 Forbidden
[13:39:38] <mru> url?
[13:39:47] <jai> mru: http://samples.mplayerhq.hu/Matroska/haruhi.mkv
[13:41:24] <mru> try again
[13:41:56] <jai> mru: works :)
[13:41:58] <jai> mru: thanks
[13:42:13] <mru> just shout if there are permission problems
[14:37:02] <Penumbra> Just wanted to say thanks for getting us a DV100 Decoder / Demuxer guys.  Any thoughts on a timeframe for an encoder?  Is there an ffmpeg roadmap somewhere I can refer to?
[14:37:28] <mru> roadmaps are for wimps
[14:37:38] <mru> heck, _roads_ are for wimps
[14:37:53] <Penumbra> so true
[14:38:29] <Dark_Shikari> mru: the first minigop finished!
[14:38:36] <Dark_Shikari> only took it about 4-5 hours
[14:39:13] <av500> \\\ooo///
[14:39:17] <av500> Dark_Shikari: what PC?
[14:40:02] <Dark_Shikari> core i7, 1.6ghz, with turbo boost (notable since it uses only one thread)
[14:40:07] <av500> Dark_Shikari: ask janneg if you can have his BBB cluster when he is done rendering :)
[14:40:16] <Dark_Shikari> can't cluster it really
[14:40:24] <Dark_Shikari> so, interesting notes about the compression results so far
[14:40:39] <Dark_Shikari> edge-wise it seems to be very good
[14:40:42] <Dark_Shikari> very minimal ringing
[14:40:53] <Dark_Shikari> probably due to the improved intra prediction
[14:41:08] <Dark_Shikari> no blocks whatsoever
[14:41:12] <Dark_Shikari> Also, blurry as hell.
[14:42:27] <Dark_Shikari> no banding either, due to the higher internal bit depth iirc
[14:42:59] <twnqx> 1. take green greid with 1 px spacing
[14:43:05] <twnqx> 2. add red pixels in between
[14:43:15] <twnqx> grid* of course... 3. encode
[14:43:22] <twnqx> 4. if result is ok, codec is ok :P
[14:43:53] <av500> twnqx: you forgot 3.5. decode
[14:44:10] <twnqx> well...ok.
[14:44:38] <av500> otherwise I have a very optimal encoder for you :)
[14:45:05] <kshishkov> mru: "heck, _roads_ are for wimps" <- so you're finally moving to Russia?
[14:46:42] <Penumbra> Or jamaica, omg.. Try driving out there in a rain storm.
[14:47:18] <kshishkov> try driving in Russian in any weather
[14:47:33] <Penumbra> Hmm.. To drive in Russian, must I think in Russian?
[14:48:01] * Penumbra fires forward missiles.
[14:48:02] <av500> thinking is not required
[14:48:26] <Penumbra> Oh good - I'm well prepared then.
[14:48:44] <kshishkov> http://www.tema.ru/travel/ee-7/_MG_0049.jpg
[14:49:05] <kshishkov> http://www.tema.ru/travel/ee-7/_MG_0055.jpg
[14:50:28] <kshishkov> and that's a rather major road through Siberia finished maybe two years ago
[14:51:46] <Penumbra> Hey, at least there's a guard rail :)
[14:52:27] <Penumbra> And those look about as bad as Jamaica roads.  When it rains, the busses forge their own roads.
[14:52:58] <av500> Penumbra: ffmpeg roadmap here: http://imagebin.ca/view/ptn3MsN4.html
[14:54:10] <av500> kshishkov: potholes are smaller than cars, counts a good road!
[14:54:27] <kshishkov> av500: FFmpeg road is E4 :P
[15:07:11] <mru> this is my idea of ffmpeg roadmap: http://imagebin.ca/view/RrbiZf.html
[15:07:58] <av500> so all that is left is OZ and argentina?
[15:09:45] <Compn> kshishkov : potholes! reminds me of detroit roads :)
[15:10:59] <av500> mru: the image you uploaded just before that is also not bad...
[15:11:01] <kshishkov> Compn: when Ford engineers went to USSR to build GAZ, local roads reminded them of Detroyt twenty years before that
[15:11:57] <mru> av500: that wasn't me... you wouldn't get such a small, grainy pic from me
[15:12:12] * mru has _standards_
[15:12:44] <av500> http://xkcd.com/598/
[15:12:52] <mru> is that the modem one?
[15:12:56] <av500> yup
[15:12:57] <kshishkov> those standards should mention small grainy pics, at least ITU T.80
[15:50:12] <peloverde> Did hulu just dump rtmpe or whatever didn't work on flash linux 64?
[15:51:30] <peloverde> Also, no spectral holes http://i.imgur.com/9Fo19.png
[16:21:43] <chris_c> I'm having some difficulty compiling ffmpeg.  I'm getting the following error: undefined reference to `sws_isSupportedOutput'.  Is this the right place to ask for help?
[16:23:39] <mru> no
[16:23:51] <av500> #ffmpeg
[16:23:58] <Dark_Shikari> your version of swscale likely doesn't match your version of ffmpeg
[16:24:29] <peloverde> if you checkoout and old version or from git swscale must be updated manually
[16:24:43] <chris_c> I'm trying to compile ffmpeg without swscale using --disable-swscale
[16:25:08] <av500> ah, the cmdutils bug
[16:25:28] <chris_c> known issue?
[16:26:00] <mru> av500: what bug?
[16:26:03] <av500> show_pix_fmts()
[16:26:26] <av500> misses some #if CONFIG_SWSCALE or so
[16:26:38] <av500> I had that when I compile audio decoders only I think
[16:26:54] <chris_c> any workaround?
[16:28:56] <av500> try: http://ffmpeg.pastebin.com/eH5PVatt
[16:31:06] <chris_c> I'll try your patch av500.  Thank you for the help.
[16:35:29] <av500> mru: I think all these are needed: http://ffmpeg.pastebin.com/rUQK7Ki6
[16:35:54] <mru> send 'em to the ml, build some cred
[16:36:02] <av500> k
[16:37:10] <av500> hey you sent one already :)
[16:37:23] <mru> yeah, but it ifdefs a bit too much I think
[16:37:36] <av500> thats what I thought
[16:37:43] <mru> feel free to reply then
[16:37:45] <av500> ok
[17:54:19] <CIA-7> ffmpeg: mru * r23054 /trunk/libavfilter/vf_pad.c: vf_pad: fix mixed code and declarations
[19:16:59] <mru> Dark_Shikari: your blog post is on HN now
[19:25:07] <BBB> what is hn?
[19:26:49] <janneg> news.ycombinator.com/
[19:41:23] <Dark_Shikari> oh wow
[19:41:30] <Dark_Shikari> someone is stalking my blog and submitting it to hn =p
[20:05:06] <KotH> jai: yes, i block certain ips
[20:05:21] <KotH> jai: if you've problems downloading, please tell me which ip you're comming from
[20:05:32] <KotH> Dark_Shikari: hn?
[20:05:58] <jai> KotH: hi, no problems now, mru did something that fixed it :)
[20:06:45] <mru> KotH: one file wasn't readable by the web server
[20:06:46] <KotH> jai: probably unblock your ip :)
[20:06:51] <KotH> oh..
[20:06:54] <jai> ah
[20:07:01] <BBB> it was a permission issue right?
[20:07:04] <KotH> that's a different issue
[20:07:10] <BBB> I suppose mru did an elegant version of chmod a+r ...
[20:07:23] <jai> ah, my guess was wrong then, sorry for the noise
[20:07:23] <KotH> there are certain files, that can only be downloaded if you use the developer login
[20:07:39] <KotH> (because they are downloaded so often, that they create too much traffic)
[20:07:47] <jai> right, will try with that next time before complaining :)
[20:08:02] <mru> Kovensky: is Matroska/haruhi.mkv one of those?
[20:08:50] <mru> KotH: ^^
[20:08:55] <ramiro> which filter does avfilter-lavf enable?
[20:08:55] <mru> damn tab completion
[20:08:56] <KotH> i think so
[20:09:15] <mru> what's in that file?
[20:09:43] <KotH> it's probably just the name that does it
[20:09:49] <jai> good for checking subtitle sync
[20:10:01] <KotH> haruhi is one of the more popular animes of the last 2-3 years
[20:10:48] <jai> that too :)
[20:12:03] <KotH> looks like a full version of the ending of haruhi, with complex ass subs
[20:12:16] <KotH> and part of the subs are rendered wrong
[20:12:19] <KotH> ^''
[20:12:54] <_av500_> bouillabaisse ftw!!!
[20:13:06] <KotH> gesundheit!
[20:13:10] <mru> not a word you see every day
[20:13:46] <_av500_> yup
[20:13:50] <KotH> not a dish you eat everyday either
[20:14:35] * KotH remember having cooked one in secondary school or so
[20:14:40] <mru> a dish I'd rather never eat
[20:14:43] <KotH> or maybe highschooll... dont remember
[20:14:50] <KotH> why not?
[20:15:00] <mru> shellfish, blegh
[20:18:43] <KotH> oh.. i forgot... you dont eat any sea food
[20:19:21] * mru doesn't eat insects
[20:19:27] <mru> doesn't matter if they live in the sea
[20:20:31] <ramiro> http://james-iry.blogspot.com/2009/05/brief-incomplete-and-mostly-wrong.html is mostly boring, but there's a brilliant quote: "1940s - Various "computers" are "programmed" using direct wiring and switches. Engineers do this in order to avoid the tabs vs spaces debate."
[20:22:09] <mru> I thought most of that was funny
[20:22:27] <mru> maybe you need to read up on computer history
[20:23:03] <jai> KotH: in mplayer?
[20:23:23] <KotH> jai: ack
[20:23:30] <ramiro> yes, probably. but most of the parts I understood were "meh.." jokes...
[20:23:35] <KotH> jai: though an quite old version, ahvent updated in ages
[20:24:46] <jai> KotH: ah, renders fine here btw
[20:24:47] <mru> "LISP remains an influential language in key algorithmic techniques such as recursion and condescension"
[20:24:57] <mru> so that's what cond means...
[20:26:10] <KotH> jai: also the kanji on the right side?
[20:26:18] <KotH> jai: those are turned by 90° here
[20:31:11] * elenril finds the brief history more funny each time he reads it
[20:31:12] <astrange> erik naggum is gone so the level of lisp programmer anger has gone down
[20:31:57] <mru> "1983 - Bjarne Stroustrup bolts everything he's ever heard of onto C to create C++."
[20:32:17] <mru> probably the most accurate description ever
[20:33:28] <Dark_Shikari> lol
[20:39:37] <mru> hi mmu_man
[20:39:51] <mmu_man> plop
[20:39:51] <mru> what's the status of ffmpeg on beos/haiku these days?
[20:39:57] <KotH> jai: current mplayer still renders the kanjis wrong
[20:40:19] <mru> I haven't seen any fixes or patches since my last threat to delete stuff
[20:40:37] <mmu_man> mru I had to hack some more *INT64_C() and PRI*() crap around, thx :^)
[20:40:57] <mru> haiku doesn't have a working libc?
[20:41:07] <mmu_man> it does
[20:41:15] <mru> then no hacks should be needed
[20:41:23] <mmu_man> Haiku should have those stupid macros now
[20:41:25] <mmu_man> BeOS doesn't
[20:41:31] <mru> screw beos
[20:41:50] <mru> I'll only go so far to support a dead OS
[20:42:28] <mmu_man> I tried to add them from configure as -D to avoid patching but passing quotes screws up anyway
[20:42:40] <mru> patch the system, not ffmpeg
[20:43:14] <mmu_man> I'm not the vendor
[20:43:20] <mmu_man> (not anymore :p)
[20:43:23] <mru> but it's your computer, no?
[20:43:34] <jai> KotH: oh, /me doesn't grok kanji :)
[20:43:35] <mmu_man> ...
[20:44:15] <KotH> jai: learn some ;)
[20:44:27] * mru knows a handful, but probably not that one
[20:44:58] <mmu_man> a hangul ?
[20:45:01] <mmu_man> ah, handful ;)
[20:45:08] * mru knows all hangul
[20:45:44] <mru> except the historic ones no longer used
[20:45:50] <mmu_man> want to contribute a korean translation in Haiku ?
[20:46:01] <mru> I said I know hangul, not korean
[20:46:18] <mmu_man> contribute an input method then ;)
[20:46:33] <mru> XIM supports it
[20:46:42] <mru> oh right... you don't run X :-)
[20:46:42] <mmu_man> X ? as in X11 ?
[20:46:43] <mmu_man> bleh
[20:46:54] <mru> X is great
[20:47:03] <mmu_man> aren't you the one talking all day long about ditching antique stuff ? ;)
[20:47:09] <mmu_man> X is great
[20:47:22] <mru> X is used today
[20:47:24] <mru> beos is not
[20:47:26] <mru> that's the difference
[20:47:30] <mru> C is also old
[20:47:43] <mmu_man> not the pile of overly colorful crap you usually put atop
[20:47:58] <saintd3v> mru: that whole paragraph on C++ is gold.
[20:48:12] <mmu_man> don't get me started on C++ I'm not in the mood
[20:48:37] <saintd3v> mmu_man: only if it involves skynet...
[21:00:32] <mmu_man> btw, what's up with this Orange thingy ?
[21:00:37] <peloverde> It is a syntax error to write FORTRAN while not wearing a blue tie.
[21:00:42] <mmu_man> I could try to contact them in french directly
[21:02:18] <mru> let our lawyers handle it
[21:03:02] <mmu_man> Yeah Go Eben, Go :)
[21:04:01] <ramiro> I'm curious. how are developers supposed to test their iphone apps if all programs must come from the app store?
[21:04:46] <mru> I think it's possible to run your own apps with the phone in the dock or something
[21:05:02] <mru> probably a tad more inconvenient
[21:05:13] <mmu_man> cool, so if you want to test a battery indicator ;)
[21:05:25] * mru has no apple gear
[21:05:50] * mmu_man only has a macbook pro but he had no choice on it, and he can still install what he wants, including another OS if needed
[21:05:52] <wbs> when you pay up for a iphone developer account, you can get developer provisioning profiles for your device, so you're able to install apps through xcode onto your device, and run it both connected and disconnected
[21:06:01] <_av500_> if you sign up to the appl dev foo, you can self sign test apps
[21:06:10] <_av500_> and give them to a few ppl
[21:06:19] <mmu_man> pay ?
[21:06:23] <mmu_man> did he say pay ?
[21:06:25] <mmu_man> bleh
[21:06:28] <mru> pay for the right to write apps?
[21:06:30] <mru> no thanks
[21:06:44] <_av500_> $99 afaik
[21:06:45] <wbs> you can also sign apps for so called "ad hoc distribution", that they can install through itunes, but you're limited to a max of 100 devices or so
[21:06:49] <mmu_man> didn't Steevo criticise Flash for notr being open ? ;)
[21:06:57] <_av500_> what wbs said
[21:06:58] <ramiro> per year?
[21:07:05] <_av500_> iirc
[21:07:08] <wbs> ramiro: yeah
[21:07:13] <ramiro> yikes
[21:07:16] <mru> mmu_man: did anyone ever say his jobsness had to be rational?
[21:07:27] <ramiro> and how hard is it to jailbreak? =)
[21:07:34] <mru> not
[21:07:38] <mmu_man> mru he's anything but rational
[21:07:50] <mru> of course not
[21:07:55] <mru> no cult leaders are ever rational
[21:07:55] <wbs> ramiro: not hard for a techy guy, but it's a bit limited market to distribute apps on
[21:08:54] <wbs> and the best thing is of course that dynamic linking is forbidden, so if you want to use third party libs, they have to be statically linked, so to comply with lgpl, you have to hand out object files
[21:08:57] <ramiro> hm, I was more interested in running an ssh deamon for FATE
[21:09:25] <wbs> ah, that should be very well possible, you're usually able to install openssh-server with a few clicks
[21:09:30] <mru> ramiro: I've been told that's impossible
[21:10:05] <ramiro> why?
[21:10:10] <_av500_> mru: should work on a jailbroken one
[21:10:16] <_av500_> i sshed into mine
[21:10:22] <mru> because it's against the will of the jobs I guess
[21:10:32] <mru> will it do nfs though?
[21:10:40] <mru> that's pretty much required for fate
[21:10:42] <wbs> not easily at least
[21:10:50] <mru> or some network filesystem
[21:10:56] <ramiro> sshfs?
[21:10:58] <_av500_> mru: it wont netboot :)
[21:11:47] <ramiro> anyways, that would be fun to try, if I do get an iPhone...
[21:11:51] <wbs> I tried hacking something together to run regtests by transferring samples/binaries back and forth without any network filesystem, but the connection was so unreliable so I wasn't able to run a full test round
[21:12:06] <mmu_man> mru well, in case you didn't notice you assumed the role of (benevolent ?) dictator on ffmpeg recently :p
[21:12:25] <ramiro> I'm not using it on the streets. I'm fine with my nokia 1108, the flashlight that supports SMS.
[21:12:27] <wbs> it was android in that case; the connection utility adb (used for doing remote commands or file transfers) gave spurious errors every 100 executions or so ;P
[21:12:29] <ramiro> and calls too
[21:12:30] <mru> mmu_man: not at all
[21:12:36] <mmu_man> tss tss
[21:12:36] <mru> I only rule over a couple of provinces
[21:13:04] <mmu_man> ah so you're a vassal ? :p
[21:14:43] <_av500_> lol http://www.theregister.co.uk/2006/01/11/exception_handling/page2.html
[21:15:14] <mru> "When should you raise an exception?"
[21:15:18] <mru> why, never of course
[21:15:26] <mru> unless you're hardware
[21:15:50] <_av500_> wbs: yes, adb can suck
[21:16:19] <mru> wbs: but android can run anything, no?
[21:16:36] <_av500_> anything?
[21:16:56] <wbs> anything, as in runs binaries and whatnot without jailbreaking, yeah
[21:17:47] <mru> so you could install sshd
[21:18:05] <_av500_> network is tricky
[21:18:15] <_av500_> android polices net access
[21:18:20] <ramiro> gprs!
[21:18:29] <wbs> you don't have root on devices (unless you root it, which is more or less like jailbreaking i guess)
[21:18:29] <mru> but why bother? it's just linux anyway
[21:18:50] <wbs> with a very special libc ;P
[21:19:00] <_av500_> wbs: just put another one
[21:19:11] <mru> if we wanted to test stuff on android, I'd suggest doing a custom-built one with ssh and nfs support
[21:19:33] <_av500_> compiling ffmpeg gainst bionic
[21:19:34] <mru> or link against the android libc on top of a normal linux install
[21:20:01] <Yuvi> ramiro: it's possible, but when I tried running fate on my ipod it still wasn't done after 6 hours
[21:20:09] <BBB> ramiro: developer program allows you to install profiles on your phone
[21:20:15] <BBB> with a profile installed, you can test self-compiled apps also
[21:20:20] <BBB> no dock or anything necessary
[21:20:24] <BBB> it's just like a regular app
[21:21:13] <ramiro> Yuvi: well the ipod has no neon right?
[21:21:15] <Yuvi> doesn't help that each ssh connection took ~5 seconds to setup for some reason
[21:21:17] <BBB> you install it directly in xcode, it is pretty well-integrated and has "export to device" functionality built-in
[21:21:23] <Yuvi> ramiro: ipod touch 3g does
[21:21:41] <ramiro> oh, you have one of the good ones...
[21:21:45] <mru> not the 8GB one
[21:21:48] <Yuvi> no, mine's first gen
[21:22:05] <ramiro> mine's whatever was cheapest in 2008 with 80gb
[21:22:20] <Yuvi> so a classic, without iphone os
[21:22:23] <ramiro> an ipad might be interesting to test.
[21:22:37] <peloverde> I feel like the pre iphone OS ipods are no longer relevant
[21:23:04] <BBB> you can't install apps on them, so what's the point?
[21:23:16] <ramiro> what os do the classic ipods have?
[21:23:19] <BBB> peloverde: target audience was teen-twenty kids
[21:23:22] <ramiro> BBB: you can play music!
[21:23:23] <ramiro> hehe
[21:23:25] <BBB> peloverde: they play games
[21:23:31] <BBB> peloverde: they want the ipod touch nowadays
[21:23:42] <BBB> I sometimes see grandpas in the subway with a classic ipod
[21:23:46] <BBB> otherwise they've vanished
[21:23:50] * _av500_ wants the classic
[21:23:54] <BBB> my wife has one, she never uses it, uses the iphone instead
[21:24:05] <mmu_man> if anyone has a spare iPad... I'd port Haiku to it :p
[21:24:07] <Yuvi> ramiro: no real os afaik
[21:24:14] <peloverde> I don't use my ipod video anymore
[21:24:16] <mmu_man> hmm well I'm too busy anyway
[21:24:18] <peloverde> ramiro, rockbox
[21:24:21] <peloverde> at least on mine
[21:24:31] <mru> ipad is just a bigger iphone
[21:24:39] <BBB> cannot call
[21:24:42] <mru> here's a cheaper option: http://appadvice.com/appnn/2010/04/humor-free-iphonetoipad-upgrade/
[21:24:42] <_av500_> heretics
[21:25:05] <Yuvi> mru: I thought so too until I used one
[21:25:25] <mru> I guess it's slightly more effective in a bar fight
[21:25:41] <peloverde> I really don't know what I'd do with an iPad if I had one
[21:25:43] <_av500_> in a german beer bar?
[21:25:57] <mru> there's usually no fight without beer
[21:26:11] * mru usually stays out of fights
[21:26:24] <ramiro> unless they're virtual
[21:26:32] * mru lacks the required physique
[21:26:41] <mru> don't know about _av500_ ...
[21:27:06] <KotH> not roughless enough
[21:27:39] <ramiro> KotH could kill us with his bare hands.
[21:27:52] <mru> no doubt
[21:28:06] <KotH> yes, i could... unless you put up a fight ;)
[21:28:52] * mru thought KotH practised some form of martial arts
[21:29:00] <mru> don't they teach the force choke there?
[21:29:13] <_av500_> marsian arts?
[21:29:17] <KotH> nope...
[21:29:28] <mru> _av500_: martian
[21:29:29] <KotH> and even if they would, it's not of much use
[21:29:34] <mru> is the adjective form of mars
[21:29:54] <KotH> the one who wins isnt the one who is stronger or better trained, it's the one who has more will to win
[21:29:58] * _av500_ prefers martini
[21:30:09] <mru> shaken, not stirred
[21:30:22] <_av500_> what mru said
[21:30:24] * KotH stirs up som edust
[21:30:31] <KotH> s/ e/e /
[21:32:59] <KotH> mru: next time you're in .ch, i'll take you to our training
[21:33:18] <KotH> mru: to see and learn, with eyes unclouded :)
[21:34:51] <_av500_> wipe on wipe off...
[22:13:01] <CIA-7> ffmpeg: stefano * r23055 /trunk/libavfilter/vf_scale.c:
[22:13:01] <CIA-7> ffmpeg: Log input size, input format and swscale flags used for conversion in
[22:13:01] <CIA-7> ffmpeg: config_props().
[22:13:01] <CIA-7> ffmpeg: Useful for debugging.
[22:13:01] <CIA-7> ffmpeg: stefano * r23056 /trunk/libavfilter/vf_scale.c:
[22:13:02] <CIA-7> ffmpeg: Make config_props() show conversion information before to create the
[22:13:03] <CIA-7> ffmpeg: swscale context.
[22:13:03] <CIA-7> ffmpeg: This makes eventual warnings issued in case of swscale context
[22:13:04] <CIA-7> ffmpeg: creation failure to be shown after the conversion information rather
[22:13:04] <CIA-7> ffmpeg: than before, which is slightly less confusing.
[23:18:48] <mru> there's a hole in the spectrum, dear alex, dear alex...
[23:30:28] <spaam> oh no
[23:32:03] <kierank> haha monty is speaking at streaming media east
[23:32:09] <kierank> http://blog.streamingmedia.com/the_business_of_online_vi/2010/05/adobe-cbs-and-theora-discuss-html5-and-web-video-standards-next-week.html
[23:34:09] <mru> what's the matter spaam?
[23:34:15] <mru> did you miss the traam?
[23:35:06] <spaam> mru: mm :(
[23:35:37] <mru> poor spaam, now he has to walk home
[23:35:43] <mru> because pigs can't fly...
[23:36:20] <spaam> can you make them fly dear mru ?:O
[23:36:39] <spaam> make them fly for me. plz mr mru
[23:37:07] <mru> pig who can fly, that would be a lie
[23:38:18] <mru> but for those who are nice, I'll put devils on ice