[FFmpeg-devel-irc] IRC log for 2010-08-23

[irc at mansr.com]

[00:30:08] <BBB> how do I create win64 binaries? </stupid question probably>
[00:35:42] <Dark_Shikari> with mingw64
[02:42:12] <CIA-11> ffmpeg: rbultje * r24871 /trunk/libavcodec/x86/vp8dsp.asm: Fix segfaults in VP8 SIMD code on Win64 (and FATE/win64 failures).
[02:55:21] <lu_zero> BBB: what was the issue?
[02:55:43] <BBB> using a native-size register instead of a 32-bit size register
[02:55:47] <BBB> it's always something trivial
[02:56:19] <BBB> the problem is that a function prototype of (uint8_t *dst, int stride, uint8_t *src, int src_stride, int h); doesn't guarantee 0-padding of the int arguments
[02:56:27] <BBB> so on the stack, the upper 32bits may be crap
[02:56:44] <BBB> dec <reg> then takes the crap into account
[02:56:46] <lu_zero> O_o?
[02:58:43] * lu_zero doesn't understand the solution
[02:58:58] <BBB> r4=native size
[02:59:10] <BBB> r4d makes it zero-pad the upper 32 bit and read only the lower 32 bits
[02:59:32] <BBB> so dec 1+(1<<32) is zero
[02:59:40] <lu_zero> ...
[02:59:42] <BBB> dec r4 becomes 1<<32 then
[02:59:45] <BBB> dec r4d becomes 0
[02:59:56] <BBB> because it ignores the higher 32 bits
[03:00:33] <lu_zero> astrange: may I troll about that as well =) ?
[03:00:41] <lu_zero> wonderful
[03:01:05] <BBB> lol :)
[03:01:11] <BBB> 32 vs. 64 bits is tricky
[03:01:15] <BBB> most of these issues are trivial
[03:01:27] <BBB> it's like programming a shell script that works on both linux and windows
[03:01:34] <BBB> or a source file that compiles on both msvc++ and gcc
[03:01:37] <BBB> it's not difficult
[03:01:39] <BBB> it's tricky
[03:01:42] <lu_zero> Dark_Shikari: where is the magic pixie dust (TM) accounting for it? =P
[03:01:45] <BBB> there's twenty ways to do it in valid C
[03:01:49] <BBB> there's 10 accepted by gcc
[03:01:54] <BBB> another 5 by msvc++
[03:01:59] <BBB> and only 2 accepted by both
[03:02:05] <BBB> same here
[03:02:18] <BBB> making the argument type long instead of int would also work, I think
[03:02:32] <lu_zero> BBB: that's fun because of the small troll-oriented discussion about inline asm vs full asm vs intrinsics
[03:02:35] <BBB> then the argument type is native-size instead of 32bits sizs
[03:02:47] <BBB> I know, I read you guys trolling :-p
[03:03:02] <lu_zero> yawn
[03:03:08] <lu_zero> and it's already morning =_=
[03:03:15] * BBB goes to bed in a little
[03:03:21] <BBB> I was about to say, shouldn't you be asleep now?
[03:03:27] <BBB> you're in inverted timemode
[03:03:44] <lu_zero> I overslept a bit so I woke up early
[03:04:35] * lu_zero wonders if he should troll mesa as well...
[03:04:46] <BBB> yes ye syes
[03:04:48] <BBB> trolling is fun
[03:05:03] <lu_zero> it's fun when you got a large chunk of C code replaced with a larger chunk of c++ code
[03:05:17] <lu_zero> and, wonder, not even es2gears works
[03:05:35] <lu_zero> (that to keep the C++ is always broken myth alive)
[03:06:15] <lu_zero> (in that case the glgs compiler)
[03:10:13] <BBB> I think the inline asm vs intrinsics vs yasm flamewar was better
[03:10:18] <BBB> please keep trolling on that one
[03:10:22] <BBB> it gave me a good laugh :-p
[03:11:06] * BBB sleep now
[03:11:09] <BBB> see you tomorrow :)
[04:11:02] <xxthink> Questions on the audio frame size calculation in ffmpeg
[04:11:13] <xxthink>             frame_size = (frame_size * 144000) / sample_rate;
[04:12:09] <xxthink> this is the calculation method in    ff_mpegaudio_decode_header
[04:12:26] <xxthink> what does 144000 stands for?
[04:12:43] <xxthink> is the sample size of an audio frame is 144?
[04:25:43] <_av500_> no
[04:27:36] <_av500_> 1152s/frame * 1000/8
[04:28:22] <_av500_>  /8 because you go from bytes to bits/s
[04:28:40] <xxthink> thank u!!!
[04:30:18] <xxthink> but this should be the average frame size
[04:33:03] <xxthink> is it right?
[04:38:17] <_av500_> framesize for a givem bitrate
[04:38:36] <_av500_> in layer 3 it is average
[04:38:49] <_av500_> as bitrate can change per frame
[04:38:54] <_av500_> and there is bit bucket as well
[04:46:39] <CIA-11> ffmpeg: reimar * r24872 /trunk/tests/ (ref/fate/truemotion1-15 ref/fate/truemotion1-24 fate.mak): Add truemotion1 tests.
[05:00:11] <lu_zero> god morgon
[05:03:24] <_av500_> gm
[05:38:07] <saintdev> interesting, the lame psymodel 0s the scalefactors greater than 39
[05:38:28] <Dark_Shikari> higher --> lower quality?
[05:38:52] <Dark_Shikari> i.e. any band with too high a scalefactor gets zeroed?
[05:39:39] <saintdev> Dark_Shikari: high scalefactors apply to higher frequencies
[05:40:16] <Dark_Shikari> so it's a lowpass
[05:40:30] <saintdev> in effect, yes
[05:42:01] <saintd3v> so what frequency does that translate to...
[05:42:09] <Dark_Shikari> it's a dynamic lowpass
[05:42:15] <Dark_Shikari> which everyone constantly says not to do
[05:42:36] <Dark_Shikari> theory: it's intended that this lowpass NOT lowpass any further than the preprocessing lowpass did.
[05:42:59] <Dark_Shikari> and instead it's intended to get rid of any stray HFs that ended up in because of the imperfectness of the DCT
[05:43:12] <Dark_Shikari> e.g. since a "lowpass in the DCT" doesn't match the concept of a "proper lowpass"
[05:43:17] <saintd3v> afaik lame doesn't do any preprocessing, but i've never looked into that
[05:43:26] <Dark_Shikari> o.0
[05:43:31] <Dark_Shikari> what about the frequency cutoff then?
[05:43:33] <Dark_Shikari> I know it has one
[05:43:58] <saintd3v> yeah, guess i'll have to look into that
[05:51:15] <saintd3v> wholly possible i've gotten something wrong, also
[05:51:44] <saintd3v> i'be been over everything a couple of times, and can't find any reason it would be wrong
[05:55:47] <kshishkov> saintd3v: even I remember phrase "applying polyphase filter ..." appearing when running LAME
[05:57:58] <saintdev> kshishkov: wouldn't that be the filter that is part of the transform process, along with the mdct?
[05:59:34] <pJok> god morgon, kshishkov
[06:00:27] <thresh> хмутро
[06:02:32] <pJok> twolame/toolame has psymodels afair
[06:02:40] <pJok> but those are for layer II audio
[06:03:20] <saintdev> i wonder how good they were?
[06:03:28] * saintdev adds them to the list to look into
[06:04:07] <pJok> i dont know how good they are, i just noticed when i had to actually get something to make better layer II audio than ffmpeg could spit out ;)
[06:04:19] <pJok> better as in predict peak levels
[06:04:25] <kshishkov> saintdev: Gabriel once told me LAME filters out high frequencies before transform
[06:05:31] <saintdev> understandable
[06:05:31] <pJok> though, the patch i have for ffmpeg to actually deliver on predictable peak levels is very ugly
[06:05:47] <saintdev> pJok: use the psymodel!
[06:06:27] <pJok> afair, the patch i have use the input audio level and lowers the output to the input level
[06:06:39] <pJok> uses*
[06:07:05] <pJok> works a treat, before that patch, i could never deliver a perfect peak for the tv stations, after that patch, its spot on every time
[07:21:14] <KotH> morge
[07:37:45] <kshishkov> s/morge/god morgon/
[07:38:19] <av500> s/god morgon/guten morgen/
[07:38:42] <av500> kshishkov: btw, I live in part of city called Eberstadt :)
[07:40:21] <pJok> av500, servus!
[07:44:26] * kshishkov looks at http://de.wikipedia.org/wiki/Darmstadt-Eberstadt#Pers.C3.B6nlichkeiten , sees no Vladimir
[07:44:47] <av500> kshishkov: its wikipedia, edit it....
[07:45:21] <av500> ukranian IP will seem less supicious....
[07:45:23] <av500> +s
[07:45:43] <av500> I can add you to Karlsruhe....
[07:47:53] <kshishkov> no, thanks. I prefer to leave as few traces as possible
[07:48:50] <av500> in german wikipedia, its easy, it will have deleted itself completely in a few years due to non-relevance
[08:03:01] <KotH> kshishkov: that's why you're in a publicly logged irc channel?
[08:03:03] <KotH> hoi DonDiego
[08:03:11] <KotH> DonDiego: back in good old germany?
[08:05:29] <DonDiego> only until tomorrow..
[08:05:57] <KotH> and then? back on the road again?
[08:17:05] <siretart> morning
[08:17:30] <kshishkov> KotH: well, at least I've never publicly disclosed my address
[08:17:50] <kshishkov> or phone number
[08:18:04] <KotH> well.. i had to
[08:18:27] <KotH> but then, people are still unable to find it anyways, although it's infront of their eyes
[08:19:39] <kshishkov> yes, majority of people are idiots or try hard to become one
[09:51:39] <atmos4> hi
[09:52:28] <atmos4> I'm looking for a quick hack to get ffmpeg to skip every second input frame on the demuxer level, because I have a proprietary security video, that stores multiple camera frames interleaved as h264-es
[09:52:41] <atmos4> so the decoder uses the wrong frames for reference
[09:52:53] <atmos4> any idea where I should look to hack this?
[11:07:00] <DonDiego> atmos4: hi, long time no see...
[11:07:24] <atmos4> hi Diego :-)
[11:31:45] <mru> am I the only one who finds these "insightful" blog posts titled "Why $foo" annoying?
[11:31:59] <_av500_> for which $foo?
[11:32:06] <janneg> all
[11:32:08] <mru> one I just came across: Why Americans cannot enjoy holidays
[11:32:12] <_av500_> ah
[11:32:57] <kshishkov> mru: you're not alone. But I just ignore such blogs wholesale
[11:33:06] <mru> I ignore them too
[11:33:09] <atmos4> just as useful as the 100 best/most awesome $something posts
[11:33:11] <mru> but I see the titles in various lists
[11:33:18] * elenril goes to write "why cannot mru enjoy insightful blagposts"
[11:35:11] * kshishkov refreains from pointing out to elenril that nobody here is likely to read his blog, including elenril himself
[11:35:34] <mru> maybe if he wrote a trope about it
[11:36:16] <elenril> kshishkov: that wouldn't be a nice thing to say
[11:36:24] <elenril> it's good you didn't
[11:36:29] <kshishkov> of course
[11:37:01] <_av500_> elenril: just write about trains and boars and he will read it!!!
[11:37:05] * kshishkov refrains from adding "especially if tvtropes is your blog"
[11:37:43] <kshishkov> _av500_: Czech locos were the best Soviet ones.
[11:37:59] <elenril> btw are there any tools for editing DLL relocation tables?
[11:38:04] <atmos4> The 100 most awesome photos of boars and trains
[11:38:12] * elenril inb4 dd
[11:38:13] <kshishkov> _av500_: and in Beograde you had Tatra trams
[11:38:37] <kshishkov> atmos4: for the latter, it's all in www.jarnvag.net
[11:38:42] <kierank> elenril: lordpe or whatever it's called
[11:38:58] * atmos4 wonders why find . -size 893 doesn't work, or find disagrees about filesize with ls =)
[11:39:21] <kshishkov> atmos4: it may be in blocks, man find
[11:39:33] <mru> try 893b
[11:39:36] <atmos4> yea, but 1024 doesn't work either
[11:39:48] <kshishkov> block size may be 4k
[11:39:49] <atmos4> b is no allowed
[11:39:51] <elenril> kierank: thanks, will try
[11:39:56] <atmos4> if no char ia appended it's bytes
[11:39:56] <mru> block size is probably 512b
[11:40:02] <atmos4> yea it is
[11:40:27] <mru> my man page says 512-byte blocks w/o suffix
[11:40:32] <mru> c for bytes
[11:40:39] <atmos4> oh =)
[11:40:43] <atmos4> yea -size 2 works =)
[11:40:49] <mru> and b for blocks
[11:41:28] * kshishkov enjoys looking at http://www.jarnvag.net/images/bild/lokguide/Rc61370Malmo2005.jpg
[11:43:13] <KotH> kshishkov: what's special about it?
[11:43:38] <kshishkov> KotH: sentimental value. It's one of the best Swedish locomotives after all
[11:45:35] <kshishkov> also I'd like to add that Nattåg was the only train where I could sleep with comfort
[11:45:49] * KotH wonders whether there is a swedish equivalent of a weaboo
[11:46:16] <elenril> lol
[11:46:32] <kshishkov> KotH, not all of us are Turks loving Japan, you know
[11:47:24] <CIA-11> ffmpeg: bindhammer * r24873 /trunk/libavcodec/ (a64enc.h a64tables.h a64multienc.c): Initial version of the a64 (multicolor charset) codec
[11:47:26] <CIA-11> ffmpeg: vitor * r24874 /trunk/tests/ (ref/fate/wmv8-drm fate2.mak): Add FATE test for WMV8 DRM
[11:48:03] * kshishkov waits for ref/fate/mp4-itunes-drm test
[11:48:38] <CIA-11> ffmpeg: bindhammer * r24875 /trunk/libavformat/a64.c: Corresponding muxer for the a64 codec
[11:48:42] <KotH> kshishkov: yes, some of us are swedophile ukranians living in germany ;)
[11:48:45] <_av500_> kshishkov: well, i guess i could mentor a M$ DRM gsoc :)
[11:49:27] * mru curses sigma designs
[11:49:39] <CIA-11> ffmpeg: bindhammer * r24876 /trunk/doc/general.texi: documentation added for the a64 codec
[11:49:47] <kshishkov> mru: ask skal for better sigma-oriented curses
[11:49:49] <KotH> mru: with a double barel?
[11:49:57] <mru> KotH: I'd love to
[11:50:40] <mru> latest kernel I can get is 2.6.22.19
[11:50:47] <_av500_> so?
[11:50:55] <_av500_> its good one :)
[11:51:13] <mru> ethernet driver is flaky at 1Gbps
[11:51:22] <mru> must insert 100Mbps switch
[11:51:33] <mru> then nfs over tcp is broken
[11:51:49] <mru> and the chip overheats easily
[11:51:52] <CIA-11> ffmpeg: bindhammer * r24877 /trunk/libavcodec/avcodec.h: added codec-ids for the a64 codec
[11:53:00] <mru> and there's still something wrong that I haven't figured out
[11:53:28] <CIA-11> ffmpeg: bindhammer * r24878 /trunk/ (4 files in 2 dirs): enabling codec and muxer by registering it in allcodec.c and allformat.c and adding files to the build-system
[11:53:29] <kshishkov> besides the fact such product exists at all?
[11:54:10] <mru> it's randomly failing tests
[11:54:17] <CIA-11> ffmpeg: lucabe * r24879 /trunk/libavformat/rtpdec.c: Do not use the server SSRC as client SSRC in the RTP demuxer
[11:54:43] <kshishkov> mru: sorry, are you talking about Sigma Designs porduct or SheevaPlug?
[11:54:51] <mru> sigma now
[11:54:58] <mru> I managed to stabilise the sheeva
[11:55:27] <mru> my stripping it down and placing it by a fan
[11:55:44] <mru> I propped it up behind the atx psu that's powering it
[11:55:51] <mru> airflow there is rather cool
[11:55:53] <KotH> lol
[11:56:11] <KotH> what's the point in having a fan-less thing that needs constant airflow of a fan?
[11:56:43] <mru> the sigma board has no fan either
[11:56:47] <mru> but it has two fan headers
[11:56:49] <mru> telling...
[11:56:57] <mru> but not enough power for more than one fan
[11:57:44] <kshishkov> KotH: what was the name of your box with HDD and wifi card not fitting inside?
[11:58:15] <mru> KotH: now imagine the sheeva boxed up in a plastic case with scarcely a hole together with an overheating psu
[11:59:12] <mru> in defence of the gdium, at least it remains stable even though it's close to melting
[12:01:49] <KotH> kshishkov: soekris net5501
[12:02:12] <KotH> kshishkov: and they got a nice mail from me, saying that their design is utter BS
[12:02:20] <KotH> kshishkov: though, for some reason, i didnt get a reply yet
[12:02:43] <kshishkov> I wonder why
[12:05:39] <KotH> interestingly, pcengines was quite interested in my complaints about the net5501 :)
[12:17:56] <CIA-11> ffmpeg: vitor * r24880 /trunk/ (Makefile tests/fate/mp3.mak): MP3 float decoder FATE tests
[12:26:32] <peloverde> oh no 3DNow! has been deprecated!
[12:27:11] <lu_zero> how so?
[12:27:36] <peloverde> http://blogs.amd.com/developer/2010/08/18/3dnow-deprecated/
[12:28:18] <CIA-11> ffmpeg: vitor * r24881 /trunk/tests/fate/mp3.mak: fix fate breakage, 10l to me (too much copy and pasting)
[12:33:43] <lu_zero> fun
[12:37:09] <kshishkov> who cares (and whose name is not Diego)?
[12:37:33] <mru> why would the diegos care?
[12:38:00] <peloverde> I care, which other vector instruction set requires you to shout its name
[12:38:36] <peloverde> maybe intel can add an "!" to SSSSSSE12
[12:40:39] <merbzt1> so my geode wont get any more support from amd ?
[12:40:44] <merbzt1> boho
[12:40:57] <merbzt1> I'll cry me a river
[12:41:01] * mru has two of those
[12:41:05] <mru> geodes
[12:41:06] <mru> not rivers
[12:41:48] * mru worked on them together with merbzt1's boss
[12:42:25] <merbzt1> Ic
[12:42:36] <twnqx> peloverde: they should add "SCHEI" in front.
[12:44:49] <peloverde> Can someone explain LIBAVCODEC_VERSION_MICRO to me? it seems to reset inconsistently
[12:45:11] <mru> what makes you believe there _is_ an explanation?
[12:46:31] <kshishkov> merbzt1: you have a suspicious IP.
[12:46:55] <kshishkov> mru: one Diego is known to have outdated AMD chip
[12:47:03] <kshishkov> mru: and caring for it
[12:47:28] <mru> they're not going to remove the instructions from existing chips
[12:47:32] <janneg> kshishkov: amd is not going to remove 3dnow! from old chips
[12:47:51] <kshishkov> peloverde: any change that significantly changes codec behaviour should bump micro, bumping mini or macro resets it
[12:47:56] <twnqx> btw, could someone apply the bitrate sanity checking patch, please?
[12:48:09] <mru> twnqx: you're doing it wrong
[12:48:17] <kshishkov> janneg: stupid people, haven't thought about kill switch
[12:48:25] <mru> you need to badger for a _review_ before you can bitch about having it applied
[12:48:27] <peloverde> kshishkov: then why do minor bumps not reset it half the time?
[12:48:28] <twnqx> mru: mailing list was last pinged last week
[12:48:33] <kshishkov> peloverde: though people often forget about it so it's rarely bumped
[12:48:42] <janneg> that would be even scarier than the planned and canceled in flights avition firmware for the dreamliner
[12:48:57] <peloverde> Can we add a hook to make it suck less?
[12:49:18] <mru> add a hook to the dreamliner?
[12:49:32] <mru> to stop it falling out of the sky?
[12:49:33] <kshishkov> peloverde: hook can't decide whether it's important or not
[12:49:59] <kshishkov> mru: that can be achieved with M$ Windows, plane will just randomly hang mid-air
[12:50:07] <peloverde> it bothers me quite a bit but not for any particularly good reason
[12:50:10] <janneg> http://news.infracritical.com/pipermail/scadasec/2010-August/001701.html
[12:50:11] <twnqx> kshishkov: hook can reset micro if minor is bumped?
[12:50:22] <merbzt1> kshishkov: what's the problem with my IP ?
[12:51:29] <kshishkov> merbzt1: it belongs to a company that tried to hire me (though too late :(
[12:52:07] <kshishkov> twnqx: well, it depends whether that hook is alowed to modify SVN repo in that way
[12:52:37] <mru> I will not have anything automatically change the repo
[12:53:24] <merbzt1> kshishkov: well they did hire me
[12:53:26] <kshishkov> it may send nag mail to cvslog
[12:53:32] <lu_zero> I'd rather have a river
[12:53:40] <lu_zero> (belated)
[12:54:01] <kshishkov> merbzt1: I'd rather work in Solna than in Karlsruhe too
[12:54:04] <peloverde> I'm not saying use a hook to rewrite the commit, i'm saying use it to reject the commit
[12:54:14] <mru> solna is a boring suburb
[12:54:30] <kshishkov> merbzt1: though it's not bad here despite not being Sweden
[12:54:47] <mru> sweden isn't nearly as great as you seem to believe
[12:55:10] <kshishkov> it's not great but it seems to fit me best
[12:55:31] <atmos4> anyone here knows the h.264 decoder and elementary stream demuxer code?
[12:56:32] <atmos4> I'd like to get ffmpeg to skip every other frame without feeding it to the decoder, because I have a h264 es stream that contain two video streams interleaved
[12:57:50] <merbzt1> atmos4: maybe look at the parser and see if that makes any sense
[13:01:54] <atmos4> yea, but which demuxer handles elementary streams?
[13:06:36] <atmos4> hmm, probably raw.c
[13:09:13] <peloverde> why did aac turn red on freebsd/clang?
[13:09:31] <mru> peloverde: typo by vitor
[13:09:34] <mru> already fixed
[13:09:38] <peloverde> ahh
[13:20:42] <CIA-11> ffmpeg: bindhammer * r24882 /trunk/libavcodec/avcodec.h: removed an unnecessary blank line
[13:24:35] <CIA-11> ffmpeg: bindhammer * r24883 /trunk/Changelog: Adding of a64-codec: there were changes to be documented in changelog
[14:05:43] <atmos4> KotH: btw. got the video to decode, if not quite correct by hacking the h264.c source
[14:06:13] <atmos4> ref frame handling is not quite correct, so thre are distortions on camera switch
[14:47:56] <CIA-11> ffmpeg: vitor * r24884 /trunk/ (ffmpeg.c tests/fate/mp3.mak):
[14:47:57] <CIA-11> ffmpeg: Make "-fs ss" mean "make output file of size equals or less than ss"
[14:47:57] <CIA-11> ffmpeg: instead of current "make output file of size less than ss".
[14:47:57] <CIA-11> ffmpeg: Also use it to make MP3 tests more readable (using -fs xxx where xxx is
[14:47:57] <CIA-11> ffmpeg: the requested output size, not something slightly lower).
[14:50:06] <peloverde> reddit logic: "did anybody write any code that uses 3DNow?" / "I would hope not, specially since AMD came out with the K10 which has a 128-bit FPU"
[15:01:22] <atmos4> :-)
[15:01:37] <atmos4> they did however abandon 3dnow in the new chips
[15:01:56] <atmos4> which doesn't really matter because they aslo support sse
[15:01:57] * kshishkov would rather apply Russian traditional weapon on AMD, Intel and x86[_64] in general
[15:02:10] <atmos4> :-)
[15:04:08] <atmos4> Dark_Shikari: are you around?
[15:04:52] <twnqx> tzar bomba?
[15:06:05] <Dark_Shikari> yes
[15:06:40] <thresh> kshishkov: ice cold weather?
[15:06:55] <thresh> or kalashnikov
[15:07:06] <_av500_> wooden club?
[15:07:31] <thresh> nano-wooden nano-club, then.
[15:08:41] <mru> shovel
[15:09:01] <_av500_> right
[15:09:16] <atmos4> Dark_Shikari: could you take a look at a video?
[15:09:46] <atmos4> I've got a h264-es stream form a security cam that doesn't decode correctly, and KoTH told me to ask you about it
[15:10:15] <atmos4> the es stream probably contains two different videstreams interleaved, but I'm not sure about it
[15:10:59] <Dark_Shikari> o.0
[15:11:42] <atmos4> with a hack in h264.c I got it to partially decode, it seems two camera views are decoded while the other two only decode the i-frames
[15:11:50] <Dark_Shikari> MVC?
[15:12:16] <atmos4> without the hack I only got grey garbadge with the occasional i-frame which are decoded correctly
[15:13:14] <atmos4> the videos were created by alogics dvr, but I couldn't find any playback sw
[15:13:54] <atmos4> for each video there is a filename.avd which contains video data and a .avh which contains metadata
[15:14:15] <kshishkov> thresh: вообще-то у вас главный по этому вопросу Нанотолий Чубайс, не правда ли?
[15:14:21] <atmos4> Dark_Shikari: should I send you a small clip?
[15:15:12] <thresh> kshishkov: он самый.
[15:15:19] <Dark_Shikari> if you want, but if it's some weird MVC shit I doubt there's much I can do
[15:16:02] <atmos4> the hack I used to get it to somewhat decode was in h264.c after the error "Frame num gap" I let it always return -1
[15:16:13] <kshishkov> thresh: рыжий-рыжий, конопатый, убил дедушку... чем?
[15:16:51] <thresh> kshishkov: нанолопатой, в духе времени.
[15:17:17] <kshishkov> thresh: вот-вот
[15:18:02] <atmos4> Dark_Shikari: ok sending by dcc or should I upload?
[15:20:45] <Dark_Shikari> upload
[15:28:07] <atmos4> ok, sent you a msg with the link
[15:29:27] <atmos4> Dark_Shikari: isn't MVC only used for 3D Video?
[15:29:38] <Dark_Shikari> no
[15:29:44] <Dark_Shikari> MVC can be used for any situation where you have multiple view
[15:29:47] <Dark_Shikari> like multiple cameras
[15:30:01] <atmos4> yea the video containt 4 cameras
[15:31:55] <Dark_Shikari> looks like it's just interleaved and you need to deinterleave it before playback
[15:32:00] <Dark_Shikari> nothing to do with the h264 stream, and not ffmpeg's job
[15:32:42] <CIA-11> ffmpeg: benoit * r24885 /trunk/libavutil/common.h: Add missing parentheses to AV_NE macro.
[15:33:49] <atmos4> Dark_Shikari: so it's 2 streams interleaved so it'S like A1,B1,A2,B2 in the stream?
[15:35:23] <Dark_Shikari> I have no idea
[15:35:27] <Dark_Shikari> It might be AAAABBBB...
[15:36:17] <atmos4> I had the idea of skipping every other frame in the demuxer before feeding video to the codec
[15:36:34] <atmos4> but I couldn't quite figure out where in the code to do that
[15:37:52] <_av500_> atmos4: why not read the spec and drop the right frames?
[15:38:03] <mru> :effort:
[15:38:04] <atmos4> which spec? =)
[15:38:13] <_av500_> mru: right
[15:39:00] <atmos4> _av500_: you mean the h.264 specs?
[15:39:46] <CIA-11> ffmpeg: mru * r24886 /trunk/libavformat/asfcrypt.c: asfcrypt: fix unaligned read in ff_asfcrypt_dec()
[15:40:07] <_av500_> atmos4: err, yes
[15:40:15] <atmos4> I don't have a spec for the .avd/.avh fileformat used by the cam, it's prorietary
[15:41:15] <atmos4> I tried serching for the frame header 00 00 01 00, but no luck
[15:41:29] <mru> that's not a frame header
[15:41:38] <atmos4> well pciture header
[15:41:42] <mru> not that either
[15:41:53] <atmos4> then what'S the sequence for frame header? =)
[15:42:03] <mru> why don't you read the spec and find out?
[15:42:09] <_av500_> :effort:
[15:42:16] <atmos4> well if you can point me to which of the 10 or so pdfs =)
[15:42:23] <mru> the h264 one of course
[15:42:25] <mru> there is only one
[15:42:46] <atmos4> hmm KoTH send me a bund of pdfs for h.264
[15:43:02] <mru> why did you get them from KotH and not from the ITU?
[15:43:20] <atmos4> because itu probably want's money for it
[15:43:27] <mru> they don't
[15:43:45] <atmos4> hmm thought the final h.264 spec wasn't public
[15:44:44] <mru> http://www.itu.int/rec/T-REC-H.264-201003-I
[15:45:08] <atmos4> thx
[15:45:21] <BBB> Dark_Shikari: don't you have win64?
[15:45:26] <Dark_Shikari> no
[15:45:29] <Dark_Shikari> well yes but I don't have mingw
[15:45:36] <Dark_Shikari> cygwin is win32 only
[15:45:44] <BBB> can you install mingw and go fix the remaining 2 win64 issues in vp8's asm?
[15:45:53] <BBB> it's probably somewhere subtle in the bilin code
[15:46:00] <BBB> 1 bilin test passes, 2 fail
[15:46:49] <atmos4> before I find what IO'm looking for in that PDF I'm quicker understanding the source
[15:47:23] <BBB> it doesn't output all frames for test vector 3 and 7
[15:47:27] <BBB> I have no idea why
[15:47:38] <BBB> ramiro said it worked with --disable-asm
[15:49:20] <Dark_Shikari> I dunno
[15:49:22] <Dark_Shikari> you should be able to do it
[15:50:01] <BBB> right, because I have very convenient access to a win64 box and you don't
[15:52:16] <CIA-11> ffmpeg: alexc * r24887 /trunk/libavcodec/x86/ (fft_3dn2.c fft_sse.c):
[15:52:16] <CIA-11> ffmpeg: imdct/x86: Use "s->mdct_size" instead of "1 << s->mdct_bits".
[15:52:16] <CIA-11> ffmpeg: It generates smaller cleaner code.
[15:52:47] <peloverde> I have a win64 box but I wouldn't know where to start looking
[15:53:28] <peloverde> Also in my experience mingw toolchains have been burdensome to install
[15:55:49] <peloverde> Is there any case where 3DNow!â„¢ is useful on x86-64?
[15:56:05] <mru> probably not
[15:56:21] <mru> sse2 is a superset iirc
[15:56:36] <mru> at least in terms of functionality
[15:56:37] <peloverde> I was thinking maybe we should disable it by default for x86_64, no need to carry around extra garbage object code
[16:00:25] <Dark_Shikari> no, 3dnow is useless
[16:00:35] <Dark_Shikari> peloverde: then you might as well disable all functions that are slower on amd64 cpus
[16:00:42] <Dark_Shikari> in many (but not all) cases, that includes mmx versions
[16:00:55] <peloverde> I was thinking *_c functions are still useful for debugging
[16:01:44] <Dark_Shikari> yes those should be kept obviously
[16:02:07] <BBB> I mentioned this yesterday already
[16:02:25] <BBB> all mmx/mmx2 versions should be disabled for x86-64 if >=sse2 are available
[16:02:37] <BBB> should=could I guess
[16:02:41] <BBB> it'd save some space
[16:08:14] <peloverde> Why do I get a "warning: section flags ignored on section redeclaration" on a line that doesn't declare a section at all
[16:09:10] <twice11> Maybe because gcc adds the default section to it.
[16:09:31] <peloverde> it's a yasm file
[16:09:43] <BBB> peloverde: dsputil_yasm.asm?
[16:09:57] <peloverde> libavcodec/x86/fft_mmx.asm
[16:10:05] <BBB> section .text align=16
[16:10:44] <peloverde> I'm getting it on line 47... "endstruc"
[16:11:19] <BBB> oh
[16:11:22] <BBB> I get it on line 31
[16:11:24] <BBB> which is that line
[16:23:42] <atmos4> hmm, if someone could point me at the right section of the h.264 itu spec where it desfribes the frame structure I'd be glad
[16:24:50] <Dark_Shikari> wow.  this is worse than I thought
[16:24:56] <Dark_Shikari> someone in #ffmpeg is complaining about ffmpeg encoding being slow
[16:25:04] <Dark_Shikari> so I went and tested 1080i ffmpeg mpeg-2 against x264 1080i
[16:25:11] <Dark_Shikari> ffmpeg: 22fps
[16:25:13] <Dark_Shikari> x264: 60fps
[16:25:26] <mru> comparable params?
[16:25:36] <Dark_Shikari> default settings in ffmpeg (well, with ildct/ilme)
[16:25:42] <atmos4> hmm I encoded qcif msmpeg4v2 today at 2000 fps
[16:25:47] <Dark_Shikari> --interlaced --preset ultrafast and similar vbv settings in x264
[16:25:55] <Dark_Shikari> only difference is ffmpeg probably has hpel on
[16:25:57] <atmos4> from qcif h264
[16:26:01] <Dark_Shikari> but I don't think you can turn that off on cli
[16:26:16] <Dark_Shikari> oh.  ffmpeg has b-frames on, lemme turn that off
[16:26:27] <Dark_Shikari> with b-frames off it's 34
[16:26:30] <Dark_Shikari> still way slower.
[16:27:16] <atmos4> probably x264 is better optimized for multicore encoding
[16:27:23] <Dark_Shikari> that is part of it
[16:27:26] <mru> x264 has faster ME
[16:27:29] <Dark_Shikari> also, -g 1 speeds up ffmpeg by over a factor of 2
[16:27:34] <Dark_Shikari> here's what's weird about that
[16:27:37] <Dark_Shikari> -me_method zero DOESNT
[16:27:43] <mru> wtf
[16:27:55] <Dark_Shikari> -me_method zero has near zero speed effect
[16:28:00] <Dark_Shikari> -g 1 gives me >80fps
[16:28:15] <Dark_Shikari> This suggests to me that something is weird.
[16:28:32] <mru> that doesn't only suggest, that _is_ weird
[16:29:01] <Dark_Shikari> x264 with keyint 1: 88fps, ffmpeg with keyint 1: 86fps
[16:29:08] <Dark_Shikari> mru: well, with -g 1, you can omit idct
[16:29:20] <mru> true
[16:29:26] <Dark_Shikari> and omit all reference frame handling
[16:29:36] <Dark_Shikari> which x264 _cant_
[16:29:48] <mru> but _does_ ffmpeg?
[16:29:57] <Dark_Shikari> I would assume so, because ffmpeg has a jpeg encoder/etc
[16:30:02] <Dark_Shikari> and michael wouldn't let that optimization bit get away
[16:30:11] <Dark_Shikari> but let me check
[16:30:31] <Dark_Shikari> I think this is why encoding is separated into encode and decode functions
[16:30:34] <Dark_Shikari> the latter of which does the idct
[16:30:36] <Dark_Shikari> so it doesn't have to be called
[16:30:40] <mru> michael often misses things
[16:30:44] <mru> and then refuses to add them later
[16:31:13] <Dark_Shikari> the architecture design strongly suggests this method though
[16:31:23] <Dark_Shikari> like, this is the only reason to build it like that
[16:32:22] <Dark_Shikari> yup
[16:32:23] <Dark_Shikari> if ((s->flags&CODEC_FLAG_PSNR) || !(s->encoding && (s->intra_only || s->pict_type==FF_B_TYPE) && s->avctx->mb_decision != FF_MB_DECISION_RD)) {
[16:32:29] <mru> ick
[16:33:15] <Dark_Shikari> so yeah, it avoids that entire decoding step if gopsize is 1
[16:33:55] <Dark_Shikari> I'm just rather surprised at how slow ffmpeg is.  I wonder if it's worse with interlacing, as this is 1080i
[16:42:19] <CIA-11> ffmpeg: vitor * r24888 /trunk/tests/fate2.mak: BinkAudio FATE tests
[17:27:28] <mru> 700 fate tests...
[17:28:09] <pJok> in non-mike tempo
[17:28:14] <mru> time for another test with the damn sigma chip
[17:28:22] <mru> this time using a usb-ethernet adaptor
[17:31:09] <mru> thankfully I have one that's supported by the ancient kernel
[17:31:27] <kierank> mru: popcorn hour?
[17:31:30] <mru> yes
[17:32:01] <mru> the onchip ethernet seems incredibly unstable
[17:33:13] <mru> don't know if silicon or driver is to blame
[17:34:19] <kierank> i assume it's impossible to access the h.264 decoding hardware?
[17:34:57] <CIA-11> ffmpeg: mru * r24889 /trunk/tests/fate-run.sh: fate: set LC_ALL=C to avoid locale interference
[17:43:42] <mru> kierank: impossible is a strong word
[17:47:18] <mru> since root access is easily obtained, and the sigma modules are there, reverse engineering it is certainly possible
[17:47:32] <mru> I have no intention of doing it myself though
[17:52:44] * saintdev lols at the asm bikeshed
[18:41:17] <mru> hah, now all tests pass on the sigma (except the broken swscale one)
[18:43:37] <kshishkov> isn't it proper MIPS chip anyway (i.e. better than Chinese)?
[18:44:11] <mru> it's a 74kf
[18:44:14] <Dark_Shikari> heh, interesting description from an nvidia guy
[18:44:19] <Dark_Shikari> the "managerial chain reaction"
[18:44:23] <mru> lol
[18:45:01] <Dark_Shikari> "
[18:45:01] <Dark_Shikari> Sorry for the delay, your proposition set off a chain reaction with our managers and their decisions.
[18:45:04] <Dark_Shikari> Let me reply to you when they make their mind."
[18:46:44] <saintdev> this to do with our talk a while ago?
[18:46:51] <Dark_Shikari> no
[18:47:15] <saintdev> something at work then?
[18:47:18] <Dark_Shikari> yes
[18:47:32] <saintdev> ic
[19:04:04] <merbanan> saintdev: did you post the window selection patches ?
[19:04:14] <saintdev> merbanan: yes
[19:05:39] <saintdev> merbanan: http://thread.gmane.org/gmane.comp.video.ffmpeg.devel/115869
[19:14:20] <merbanan> look at that
[19:14:55] <merbanan> an ok before I had the time to finish looking through the code
[19:17:20] <saintdev> alex already had it, he just had other stuff he was working on before he reviewed it
[19:20:01] <elenril> does that mean aacenc will suck even less?
[19:20:22] <saintdev> yes
[19:20:30] <elenril> \o/
[19:21:14] <saintdev> aacenc: now with 1% less suck
[19:21:44] <saintdev> ...well, not quite yet...
[19:22:40] <saintdev> still have to wait for alex to commit it.
[19:23:56] <merbanan> it looked ok, with the exception of psy_lame_window, friggin harry potter shit
[19:23:57] <peloverde> my MUA can't handle inline patches :(
[19:25:18] <saintdev> merbanan: wait till you see analysis o.O
[19:25:35] <saintdev> peloverde: want me to pastebin them?
[19:26:06] <peloverde> Actually, it looks like the raw view will git apply
[19:27:48] <peloverde> fuck, I had shit in my svn tree
[19:27:51] * peloverde hates svn
[19:28:15] <CIA-11> ffmpeg: alexc * r24890 /trunk/libavcodec/ (fft.h aacpsy.c):
[19:28:16] <CIA-11> ffmpeg: aacenc: Rename Psy3gpp* structs to AacPsy*
[19:28:16] <CIA-11> ffmpeg: This allows cleaner implementation of other psymodels using the existing
[19:28:16] <CIA-11> ffmpeg: structs. It also will make it easier to interchange individual parts of
[19:28:16] <CIA-11> ffmpeg: the psymodel to create hybrid models.
[19:28:16] <CIA-11> ffmpeg: Patch by: Nathan Caldwell <saintdev at gmail.com>
[19:28:17] <mru> in soviet russia svn hates you
[19:29:14] <saintdev> \o/
[19:29:31] <saintdev> erm fft.h
[19:30:31] <peloverde> see my above comment
[19:30:36] <saintdev> yeah
[19:30:37] <merbanan> saintdev: expect a flood of spam, alex forgot to obfuscate the email
[19:30:42] <peloverde> now I have to figure out how to revert this shit
[19:31:06] <saintdev> merbanan: heh
[19:31:09] <peloverde> merbanan: I'm agianst e-mail obsfucation, addresses are public in the archive
[19:31:26] <saintdev> peloverde: every little bit helps...
[19:31:27] <merbanan> peloverde: why, it's just one line
[19:31:32] <saintdev> if there
[19:31:34] <saintdev> gah
[19:31:44] <merbanan> just reply to the commit
[19:31:51] <BBB> the comment?
[19:31:57] <BBB> oh come on, leave it, just change the log msg
[19:32:03] <BBB> it's not like it breaks anything
[19:32:06] <saintdev> if there's one less bot that gets your email, that's several hundred less spams
[19:32:31] * mru doesn't notice a few hundred spams this way or that
[19:32:56] <mru> my filters discard thousands a day
[19:33:16] <peloverde> all the guides seem to use svn merge but that seems to fuck up all the svn:properties
[19:33:40] <mru> what are you trying to do?
[19:33:48] <peloverde> roll back that last commit
[19:33:52] <mru> why?
[19:34:03] <peloverde> because I had some changes in fft.h in my svn repo
[19:34:13] <mru> just undo the fft.h changes
[19:34:25] <DonDiego> mru: btw, i'm favor of dropping support for running make in subdirs
[19:34:32] <mru> DonDiego: I know that
[19:34:54] <DonDiego> well, start being in favor of that as well then
[19:35:08] <DonDiego> i'll start lobbying when i come back from holidays..
[19:35:10] <mru> I don't consider it highly important to break it
[19:35:19] <DonDiego> it's broken already
[19:35:27] <DonDiego> and it complicates the build system
[19:35:39] <DonDiego> not worth it at all
[19:36:53] <CIA-11> ffmpeg: alexc * r24891 /trunk/libavcodec/fft.h: Revert unintended changes to fft.h from r24890.
[19:37:03] <mru> DonDiego: well, then there's no hurry to fix it
[19:37:18] <peloverde> someone else can commit the other patch, using svn to deal with my own stuff is enough of a pain in the ass
[19:37:32] <saintdev> lol
[19:37:47] <mru> DonDiego: and the "complication" you think is there is a matter of 3 lines
[19:37:55] <mru> if that
[19:38:09] <DonDiego> i disagree
[19:38:15] * peloverde wishes he could just use git without all the git-svn bullshit
[19:38:20] <DonDiego> if we drop support for make in subdirs
[19:38:21] <mru> you can't disagree about facts
[19:38:35] <DonDiego> there is no more need for the subdir.mak/common.mak split
[19:38:38] <saintdev> git-svn isn't that bad.
[19:38:50] <mru> DonDiego: and why is that split bothering you so?
[19:38:53] <mru> it works
[19:38:53] <saintdev> much better than just using svn ;)
[19:39:05] <DonDiego> it's needlessly complicated
[19:39:06] <peloverde> dcommit is fucked, bisect is fucked, pulling from someone else is fucked
[19:39:19] <mru> DonDiego: it's two files where you want one
[19:39:23] <mru> hardly "more complicated"
[19:39:32] <DonDiego> as i said, needless complication
[19:39:39] <DonDiego> i never know where to look for what
[19:39:52] <mru> that only means you don't know how it works
[19:40:06] <mru> would you bundle all of libav* into one C file too?
[19:40:09] <DonDiego> it means that understanding it is harder than necessary
[19:40:16] <mru> to make it easier to know which file to check
[19:40:41] <mru> running make in subdirs is a very tiny part of it
[19:40:42] <DonDiego> the split is only for make in subdirs, it's for no other sane reason
[19:40:50] <merbanan> saintdev: can you email me the diff ?
[19:41:01] <DonDiego> so the split is arbitrary
[19:41:04] <mru> no
[19:41:11] <mru> the split is necessary
[19:41:12] <DonDiego> the splitting of files in lavc is not
[19:41:25] <DonDiego> necessary because of the subdirs thing
[19:41:26] <mru> the subdir.mak rules must not be applied to the top dir
[19:41:51] <mru> then you'd get a library instead of an ffmpeg executable
[19:42:11] <DonDiego> as i said, it's designed with subdir make in mind
[19:42:15] <mru> no
[19:42:19] <DonDiego> and it can be done simpler
[19:42:29] <mru> maybe a little
[19:42:45] <mru> but not for the reasons you seem to think
[19:43:04] <saintdev> merbanan: done
[19:43:23] <DonDiego> we shall see when i'm back
[19:43:30] <DonDiego> i'll pack my bag now..
[19:43:31] <mru> you shall not touch it
[19:44:16] <DonDiego> last i checked, you hadn't rooted my computers yet, so i'll program all i want :)
[19:44:19] * merbanan thinks that mru needs a hug
[19:44:27] <mru> DonDiego: you will not commit anything
[19:44:33] <DonDiego> i'm not threatening to commit anything
[19:44:37] <mru> good
[19:44:48] <mru> and you will not do it without a threat either
[19:45:14] <DonDiego> i'm not planning to commit anything in a haste
[19:45:31] <mru> haste or not, you will not touch the makefiles
[19:45:40] <mru> not until I'm confident you understand them
[19:45:52] <DonDiego> this obviously needs some investigation
[19:46:15] <mru> it works, what else do you want?
[19:47:39] <DonDiego> make in subdirs is broken, deps do not work because they list the subdir
[19:47:55] <mru> so don't build in subdirs dammit
[19:47:57] <DonDiego> and i want it simpler and easier to understand
[19:48:00] <mru> you didn't want to do that anyway
[19:48:18] <DonDiego> i don't want a broken feature in there
[19:48:33] <mru> if it doesn't work, the feature is by definition not there
[19:48:46] <DonDiego> much less if it drags along complexity
[19:48:55] <DonDiego> it breaks silently!
[19:49:01] <mru> I can't make it physically impossible to run make in a subdir
[19:49:13] <DonDiego> you can type 'make' but it does not run as reliably as in the top dir!
[19:49:33] <mru> well, that's what I call unsupported
[19:49:37] <mru> just the way you wanted it
[19:49:40] <DonDiego> pffff
[19:49:48] <mru> or what would you have? set fire to the computer?
[19:49:52] <DonDiego> this is evil
[19:49:53] <mru> that'll teach 'em
[19:50:34] <DonDiego> anyway, this discussion is pointless - i'll see how much i can simplify it, then we can talk again
[19:52:09] * lu_zero wonders if the "feature" is fixable
[19:55:48] <merbanan> saintdev: I think the mail got stuck in the spam filter
[19:56:49] <peloverde> where are your svn gods now?
[19:56:57] <mru> why don't you help me fix swscale instead?
[19:57:38] <peloverde> svn:externals, that's why
[19:57:46] * mru curses
[20:00:59] <CIA-11> ffmpeg: alexc * r24892 /trunk/libavcodec/aacpsy.c: (log message trimmed)
[20:00:59] <CIA-11> ffmpeg: acenc: LAME-inspired window decision
[20:00:59] <CIA-11> ffmpeg: This performs quite a bit better than the current 3GPP-inspired window decision
[20:00:59] <CIA-11> ffmpeg: on all the samples I have tested. On the castanets.wav sample it performs very
[20:00:59] <CIA-11> ffmpeg: similar to iTunes window selection, and seems to perform better than Nero.
[20:01:00] <CIA-11> ffmpeg: On fatboy.wav, it seems to perform at least as good as iTunes, if not better.
[20:01:01] <CIA-11> ffmpeg: Nero performs horribly on this sample.
[20:01:04] <janneg> peloverde: http://www.mplayerhq.hu/DOCS/tech/svn-howto.txt section 9. the copy method
[20:01:26] <saintdev> hmm, pastebin.org seems down, that would explain the wgetpaste hang :/
[20:01:54] <peloverde> applied it myself
[20:01:55] <saintdev> anyway besides the point now
[20:02:10] <saintdev> \o/
[20:02:14] <janneg> peloverde: yeah missed the commit
[20:02:22] * mru stabs libswscale with a rusty fork
[20:02:40] <peloverde> saintdev: if you could keep lines in commit messages to 80 cols it saves whomever else the trouble of reformatting
[20:02:58] <saintdev> libswscale stabs mru back with an even rustier appendage
[20:03:08] <saintdev> peloverde: ok
[20:03:17] <mru> saintdev: yes, that's libswscale
[20:04:19] <peloverde> Does this look like appropriate usage of libswscale? http://pastebin.com/FkkrXRjU
[20:05:00] <peloverde> because it is significantly slower than the chrome scaler which makes me think i'm doing something terribly wrong
[20:05:12] <mru> it's c++
[20:05:13] <mru> ught
[20:05:17] <mru> I can't read that
[20:05:24] <mru> worse that lsws itself
[20:05:26] <Dark_Shikari> peloverde: slower than the chrome scaler isn't very surprising
[20:05:32] <Dark_Shikari> iirc chrome scaler is multithreaded
[20:05:42] <Dark_Shikari> also, it uses sse
[20:05:51] <Dark_Shikari> are you just doing yuv2rgb?
[20:05:54] <Dark_Shikari> or actual scaling?
[20:06:01] <Dark_Shikari> Also, did you enable the asm flags?
[20:06:17] <Dark_Shikari> Also, the context creation shouldn't be in the benchmark
[20:06:18] <Dark_Shikari> that takes time
[20:06:25] <peloverde> both scaling and yuv2rgb
[20:06:53] <peloverde> maybe that's why I put it before "TimeTicks start = TimeTicks::HighResNow();"
[20:07:09] <DonDiego> wasn't ramiro supposed to work more on refactoring libswscale?
[20:07:36] <mru> I can hardly blame him for not doing it
[20:08:12] <Dark_Shikari> peloverde: is your asm enabled?
[20:08:16] <Dark_Shikari> I don't see the flags being set
[20:08:32] <peloverde> I have to set flags?
[20:08:46] <Dark_Shikari> yes..... hurrr
[20:08:51] <Dark_Shikari> cpuflags are 0 by default
[20:08:52] <Dark_Shikari> (off)
[20:09:13] <peloverde> Shouldn't it just check what I have when I init the context?
[20:09:24] <peloverde> this API seems retarded
[20:09:32] <Dark_Shikari> IT IS
[20:09:41] <mru> it's libswscale, _everything_ about it is retarded
[20:12:44] <saintdev> mru: LMAO
[20:13:01] <Dark_Shikari> it's no laughing matter
[20:13:04] <mru> did I say something funny?
[20:14:49] <peloverde> fascinating: http://pastebin.ca/1923584
[20:15:15] <peloverde> bilinear seems marginally faster than bilinear fast
[20:15:22] <Dark_Shikari> that seems unlikely
[20:15:24] <Dark_Shikari> fast bilinear is JIT'd
[20:16:08] <Dark_Shikari> it looks to me like they're the same speed, i.e. they're the same code
[20:16:20] <Dark_Shikari> this could mean that fast bilinear isn't working correctly, and it's falling back to bilinear
[20:16:23] <Dark_Shikari> OR
[20:16:33] <Dark_Shikari> that bilinear is an alias to fast bilinear
[20:17:26] <peloverde> updated: http://pastebin.ca/1923590
[20:18:34] <peloverde> funfact: a debug build of skia running under valgrind is 3 seconds per frame
[20:22:09] <peloverde> Is SSE not useful for scaling or is it missing for some other reason?
[20:22:21] <Dark_Shikari> because swscale hasn't been updated since 2000
[20:22:30] * peloverde facepalm
[20:22:31] <mru> it's missing because nobody is able to code for lsws
[20:22:57] <peloverde> And I thought aacenc was an embarrassment
[20:24:14] <janneg> Dark_Shikari: cpuflags matter only with --enable-runtime-cpudetect
[20:24:29] <peloverde> Also I thought kshishkov just rewrote the x86 optimizations recently
[20:24:29] <Dark_Shikari> janneg: then why is peloverde getting a difference?
[20:24:40] <Dark_Shikari> peloverde: the infrastructure is still horribly broken
[20:24:46] <Dark_Shikari> and that doesn't mean we have sse
[20:25:20] <peloverde> so realistically what can we do about it?
[20:25:53] <mru> write a new lib that beats it in ever possible way
[20:25:59] <mru> every
[20:26:22] <Dark_Shikari> with neon
[20:26:48] <mru> it will have to be faster on every x86 chip ever made
[20:26:54] <Dark_Shikari> lol
[20:26:57] <Dark_Shikari> even the via c3!
[20:27:11] <mru> s/ever made/michael knows of/
[20:27:52] * peloverde headdesk
[20:28:23] <BBB> lol :)
[20:28:35] <BBB> poor guy
[20:28:41] * BBB pets peloverde on the back
[20:28:45] <Dark_Shikari> so BBB, how's that vp8 encoder
[20:29:08] <BBB> I'm going through the rac writing functions in libvpx right now
[20:35:45] <saintdev> merbanan: finally got a failure message back. guess i typed the email wrong :P
[21:01:22] <DonDiego> saste: why are the libavfilter #includes ifdeffed?
[21:01:39] <DonDiego> they look harmless, so the #ifdefs are unnecessary..
[21:02:36] <mru> DonDiego: are you bored?
[21:02:50] <DonDiego> why?
[21:03:02] <mru> you seem to be looking for trivial nits to kick up a fuss over
[21:03:22] <DonDiego> no, i was about to apply the usleep in ffplay.c patch
[21:03:36] <DonDiego> and when i opened ffplay.c i noticed the pointless ifdeffery
[21:03:40] <mru> ah
[21:03:43] <mru> so typical
[21:03:59] <DonDiego> what? fixing one thing and noticing another?
[21:04:11] <mru> yes
[21:06:47] <mru> there, one swscale bug taken care of
[21:07:05] <mru> assuming it's not too pretty of course
[21:07:25] <DonDiego> you could fix more :)
[21:07:36] <DonDiego> flaming will not get you anywhere..
[21:07:44] <mru> this one gets fate back in the green
[21:08:22] <mru> not flaming will also not achieve anything
[21:08:24] <mru> apparently
[21:13:21] <janneg> cmov on atom is slow, right?
[21:13:26] <CIA-11> ffmpeg: diego * r24893 /trunk/ffplay.c:
[21:13:26] <CIA-11> ffmpeg: Add _XOPEN_SOURCE definition for usleep().
[21:13:26] <CIA-11> ffmpeg: patch by Dave Yeo, daveryeo telus net
[21:13:55] <mru> janneg: probably varies between isotopes
[21:14:10] <DonDiego> janneg: what is the status of your latm patch?
[21:16:30] <janneg> DonDiego: still trying to avoid working on mpeg-ts integration. I have to do it soon though since I've removed libfaad with latm from mythtv
[21:17:08] <DonDiego> latm in mpeg-ts?
[21:20:54] <janneg> latm is an audio multiplex format, the demuxer for it is finished but that doesn't help to get the audio data from the mpeg-ts demuxer to the aac decoder
[21:31:31] <janneg> not as fast as core2 but much fast than everything P4 based
[21:45:43] * janneg kicks CIA-11 
[21:45:44] <CIA-11> ow
[21:46:21] <janneg> ah it's missing libswscale patches
[21:50:35] <saste> DonDiego: libavfilter is not supposed to be mandatory for both ffmpeg, and ffplay.c
[21:51:01] <saste> DonDiego: as for the ifdeffery... they are not necessary
[21:51:28] <saste> but maybe who added those was concerned with making the ff* code appears like an external app
[21:55:38] <BBB> lol @ fate because it doesn't show the swscale revision number :-o
[21:59:22] <janneg> BBB: the other question is if the fate machines will pick up the libswscale change if noboby commits to ffmpeg
[21:59:52] <BBB> good point
[22:06:21] <CIA-11> libswscale: mru * r32010 /trunk/libswscale/swscale.c: swscale: remove unused macro parameter in BGR2UV template
[22:06:22] <CIA-11> libswscale: mru * r32011 /trunk/libswscale/ (swscale_template.c swscale.c): swscale: fix unaligned accesses in (RGB|BGR)32_1 to YUV conversion