[FFmpeg-devel-irc] IRC log for 2010-04-27

[irc at mansr.com]

[04:48:56] <pengvado> suppose I want a very low latency vlc reader. it gets bits one by one, and must return a decoded symbol as soon as the bits so far uniquely specify one.
[04:49:00] <pengvado> what's the best way to do that?
[04:49:06] <pengvado> the obvious way is to replace SHOW_UBITS, SKIP_BITS, LAST_SKIP_BITS, UPDATE_CACHE with some custom implementations and then call GET_VLC.
[04:49:47] <pengvado> but I can't do that in the same file as anything else, since it destroys those macros.
[05:07:16] <Dark_Shikari> why would you need a low latency reader?
[05:10:02] <pengvado> cabgt
[05:10:30] <pengvado> the jvt guys explained it all wrong
[05:11:12] <pengvado> I would explain it as: build a pair of huffman trees with different transition probabilities. read from one, write with he other.
[05:12:12] <pengvado> and it's the encoder that needs the low latency bitstream reader. the decoder can use the ordinary get_vlc.
[05:12:56] <Dark_Shikari> o.o0.o0o.0o.
[05:13:11] <Dark_Shikari> why the hell does the encoder need a bitstream reader
[05:13:12] <Dark_Shikari> my brain hurts
[05:14:13] <pengvado> because the groups are variable size. it treats the sequence of decisions-to-be-arithcoded as a bitstream, and reads huffman tokens from it. then it codes them with a different huffman table.
[05:14:48] <Dark_Shikari> ahhhhhh
[05:14:57] <Dark_Shikari> so which do you think is more promising for ffv2
[05:15:01] <Dark_Shikari> this or auto-sorting vlc tables?
[05:15:21] <pengvado> since you get to pick 2 trees and the bijection between their leaves, you get lots of degrees of freedom even with tiny trees, and thus get remarkably close to the ideal entropy.
[05:16:01] <pengvado> auto-sorting is only useful if you don't already know which vlcs will be more common than which others
[05:16:26] <Dark_Shikari> but doesn't that change all the time?
[05:17:10] <pengvado> not for lpc residual values. bigger values are rarer. period.
[05:17:31] <Dark_Shikari> oh, so you're not going to do the 2x2 block VLCs with this
[05:17:35] <Dark_Shikari> I see
[05:18:16] <pengvado> 2x2 block VLCs are fine for a fast mode, but they necessarily coarsen the neighbor context.
[05:18:36] <Dark_Shikari> ah k
[05:18:42] <Dark_Shikari> so fast mode can be 2x2 block VLCs
[05:18:45] <Dark_Shikari> slow mode can be CABGT
[05:18:52] <Dark_Shikari> with the goal being to make the slow mode still Not Very Slow
[05:44:05] <pJok> mornings
[06:08:13] <jai> morning
[06:08:37] <BastyCDGS> good morning jai
[06:08:49] <BastyCDGS> had you a nice sleep?
[06:09:06] * BastyCDGS wonders why voice mode is away from me again...isn't that stored permamently?
[06:09:24] <wbs> you need to identify to nickserv
[06:12:05] <BastyCDGS> done
[06:12:35] <BastyCDGS> have I to reopen ffmpeg-devel to get v back?
[06:17:45] <BastyCDGS> jai, nickserv reg done etc. and logged in but still not v mode
[06:17:49] <BastyCDGS> maybe you have to readd me?
[06:18:34] <BastyCDGS> btw, a nice article about dark shikari on heise
[06:18:36] <BastyCDGS> http://www.heise.de/meldung/Freier-H-264-Encoder-x264-nun-offiziell-Blu-ray-tauglich-986218.html
[06:19:13] <Dark_Shikari> BastyCDGS: our media storm was rather effective
[06:19:18] <Dark_Shikari> we got on dozens upon dozens upon dozens of sites
[06:19:37] <BastyCDGS> seems to be ;)
[06:19:40] <BastyCDGS> congratulations
[06:20:53] <Dark_Shikari> all you have to do is say "blu-ray" and you're on the news
[06:21:22] <BastyCDGS> lol or HDTV :D
[06:21:28] <BastyCDGS> or 3d cinema ;)
[06:21:40] <Dark_Shikari> or "google"
[06:21:55] * BastyCDGS yells blu-ray
[06:22:08] * BastyCDGS and waits for his news article...waiting...waiting...waiting...
[06:22:31] * BastyCDGS wonders that there's still no article about me :D
[06:23:13] <Dark_Shikari> yes, you have to yell _on slashdot_
[06:23:38] * BastyCDGS kicks slashdot
[06:27:42] <pJok> Dark_Shikari, congrats with the bluray capability :)
[06:28:37] <Dark_Shikari> sadly I didn't actually code much of it :)
[06:29:02] * Dark_Shikari just wrote VFR ratecontrol for 1/2-pass ABR
[06:29:11] <Dark_Shikari> And patchreviewed for hours on.
[06:29:13] <Dark_Shikari> *on end.
[06:29:30] <pJok> you still did some work ;)
[06:29:36] <BastyCDGS> well then you can turn on now to crack the AACS ;)
[06:29:50] <Dark_Shikari> we're about encoding, so we don't do AACS :)
[06:30:03] <BastyCDGS> I said crack it, not doing AACS :P
[06:30:34] <Dark_Shikari> I mean cracking too
[06:32:54] <BastyCDGS> then it's upon ffmpeg to crack AACS? :D
[06:33:26] <Dark_Shikari> libbluray
[06:33:49] <BastyCDGS> wooooooow, what a great c64 demo
[06:33:50] <BastyCDGS> http://www.youtube.com/watch?v=M-qEzv_IxuU
[06:33:59] <BastyCDGS> 320x200 in 16 colors
[06:34:00] <merbzt1> BastyCDGS: cracking AACS implies cracking AES
[06:34:38] <saintdev> no it doesn't
[06:34:41] <BastyCDGS> that will be very hard
[06:34:49] * pJok hands BastyCDGS libspc
[06:36:32] <saintdev> that's like saying cracking WEP implies cracking DES.
[06:36:48] <Dark_Shikari> AACS is already cracked
[06:37:07] <saintdev> exactly
[06:37:58] <BastyCDGS> AACS crack => ffmpeg git ;)
[06:38:57] <BastyCDGS> merbzt1, AES is only secure if you keep the key secure
[06:39:16] <BastyCDGS> and that's what all these copy protection schemes fail upon, they have to deliver the key
[06:39:52] <BastyCDGS> anyone watched BluREU yet?
[06:40:19] <saintdev> BastyCDGS: the problem is, the designer has to think of _every_ weakness
[06:40:26] <saintdev> the cracker has to only find one
[06:40:42] <aaronl> watched blureu
[06:40:57] <aaronl> i'm not really familiar with the c64 demoscene so i dont know how impressive it really is
[06:41:14] <aaronl> but i'm curious how much rom (or disk or tape or whatever) that took
[06:41:38] <merbzt1> saintdev: well to me a real crack is when you can decrypt without the having a key issued by the bluray authority
[06:42:02] <saintdev> merbzt1: true, but that in no way implies cracking AES.
[06:42:17] <BastyCDGS> try entering as AES key pw: IHatePirateBay
[06:42:22] <Dark_Shikari> merbzt1: encryption schemes are cracked all the time without having the key
[06:42:26] <BastyCDGS> if you have little look that's their master key :D
[06:42:29] <Dark_Shikari> in fact, that's the primary vulnerability in encryption
[06:42:34] <Dark_Shikari> the _algorithm_ is almost always fine
[06:42:38] <Dark_Shikari> the _implementation_ is usually faulty
[06:42:44] <Dark_Shikari> that's why they tell you to never, ever, ever, ever, ever roll your own
[06:42:49] <Dark_Shikari> because you will have holes.
[06:42:55] <BastyCDGS> s/look/luck
[06:43:27] <merbzt1> saintdev: well one way would be to crack AES
[06:43:44] <BastyCDGS> yes many people for example use a 32-bit RNG
[06:43:51] <saintdev> yes, but that is unlikely, and probably a waste of time for anyone who tries
[06:43:52] <BastyCDGS> for a 128 bit key which reduces effective key size to 32 bit
[06:43:57] <aaronl> and i wonder how the rickroll thing was done
[06:44:16] <merbzt1> aaronl: precomputed animation
[06:44:17] <aaronl> it basically looks like video playback, and i didn't know a c64 could do that
[06:45:13] <saintdev> AES has been proven to be very secure by YEARS of research from experts in encryption
[06:45:14] <merbzt1> saintdev: what other attack vectors on AACS are there then ?
[06:46:22] <saintdev> i'm not familiar enough with aacs to say, but you don't go attacking the strongest part of a safe.
[06:46:49] <Dark_Shikari> merbzt1: AACS is not an encryption scheme
[06:46:53] <saintdev> you look into the key handling
[06:46:53] <Dark_Shikari> that's the attack vector
[06:47:00] <Dark_Shikari> normally, in an encryption scheme, you have some encrypted data
[06:47:06] <Dark_Shikari> and you give it to person X, who has your key
[06:47:08] <Dark_Shikari> and person X decrypts it.
[06:47:16] <Dark_Shikari> You are trying to prevent person Y, who doesn't have the key, from reading it.
[06:47:18] * BastyCDGS was surprised about that demo too
[06:47:26] <BastyCDGS> if that goes on this way, we have in 2-3 years the first H264 decoder running at 1600x1200 :P
[06:47:26] <BastyCDGS> on c64
[06:47:38] <Dark_Shikari> With AACS, the blu-ray has some encrypted data
[06:47:41] <Dark_Shikari> and it gives it to person X, who has your key
[06:47:47] <Dark_Shikari> .... and it doesn't want person X to be able to read it
[06:48:01] <Dark_Shikari> The same person who has the key is the person who it doesn't want viewing the data.
[06:48:08] <Dark_Shikari> This is physically impossible.
[06:48:13] <Dark_Shikari> And this is why all DRM is doomed.
[06:48:29] <BastyCDGS> as I mentioned above the key creation itself can be the attack vector, too
[06:48:30] <Dark_Shikari> you cannot protect data when someone has physical access to it.
[06:48:32] <BastyCDGS> 32-bit RNG etc.
[06:49:05] <ohsix> except by the legal threats you can surround its circumvention
[06:49:17] <saintdev> ohsix: lol
[06:49:19] <Dark_Shikari> only in the US :)
[06:49:44] <ohsix> the threat is enough to keep people out without licenses though
[06:49:48] <merbzt1>  Dark_Shikari: CIplus is most likely not doomed
[06:50:06] <Dark_Shikari> ohsix: I'm pretty sure everyone rips DVDs without licenses =p
[06:50:06] <BastyCDGS> dark shikari is completely right with this
[06:50:11] <merbzt1> it is almost the same DRM model as Bluray
[06:50:19] <Dark_Shikari> merbzt1: why isn't it doomed then?
[06:50:22] <ohsix> but not everyone makes hardware
[06:51:26] <merbzt1> Dark_Shikari: the key is sent over encrypted busses
[06:51:52] <saintdev> and that prevented the PS3 from getting hacked?
[06:51:57] <saintdev> oh wait, no it didn't
[06:51:58] <merbzt1> tinker with the hardware and it will self destruct
[06:52:03] <saintdev> how about the Xbox
[06:52:10] <saintdev> nope, not that either...
[06:52:12] <saintdev> hmmm
[06:55:38] <aaronl> i don't think drm is usually intended to "prevent person X from viering the data" in a cryptographic sense; it's just supposed to make it hard, annoying, expensive, etc to do so
[06:55:43] <aaronl> *viewing
[06:56:06] <aaronl> and to some extent it can be pretty successful at that
[06:56:31] <aaronl> if the hardware is out there for a few years before getting hacked, that's probably considered a win
[06:56:48] <Dark_Shikari> aaronl: that's because the real purpose of DRM is to prevent legal format-shifting
[06:56:51] <Dark_Shikari> not piraacy
[06:56:56] <Dark_Shikari> the pirates break the DRM in 3 days and post the result on the pirate bay
[06:57:00] <Dark_Shikari> all the pirates get their copies
[06:57:11] <Dark_Shikari> The ordinary users who follow the law are screwed.
[06:57:15] <Dark_Shikari> Lesson: the law is for suckers.
[06:57:38] <aaronl> well as far as i know, nobody is pirating ps3 games yet
[06:57:46] <saintdev> just look at ubisoft, lol
[06:57:47] <aaronl> and they probably would be if not for the convoluted drm
[06:58:03] <Dark_Shikari> aaronl: you sure?
[06:58:05] <Dark_Shikari> just head to asia
[06:58:15] <Dark_Shikari> Doubt you'll be able to find a disc on the street that's legit in hong kong =p
[06:58:27] <Dark_Shikari> Also, microsoft killed over 1 million xbox live accounts the other day for playing with pirated games
[06:58:32] <aaronl> okay, maybe that's true
[06:58:49] <aaronl> but i doubt i could download a ps3 game on the pirate bay and play it
[06:58:58] <aaronl> and that would probably be possible otherwise
[06:59:07] <Dark_Shikari> probably not, because they use blu-ray discs
[06:59:11] <Dark_Shikari> and most people don't have burners
[06:59:30] <aaronl> don't they have hard drives?
[07:00:43] <ohsix> drm is the new dolby logo on the hifi
[07:02:06] <aaronl> i don't like drm at all, but the world that scares me isn't a world where everything's encumbered by drm that's uncircumventable, because that's obviously bullshit
[07:03:48] <aaronl> what i think is more likely is stuff that you can break it if you're really smart and willing to mess arond with fpgas, but pretty much no one has the time and motivation to deal with
[07:04:33] <saintdev> IMO CableCARD is a very well designed system
[07:04:43] <aaronl> or even things like the iphone where there are somewhat well-polished cracks out there, but then you have to live in fear of retribution from at&t or apple
[07:04:58] <aaronl> or microsoft in the xbox example
[07:05:31] <Dark_Shikari> I thought the whole point of jailbreaking your iphone was so you didn't have to use AT&T?
[07:05:44] <Dark_Shikari> =p
[07:06:45] <aaronl> for someone who uses at&t, i don't see the value proposition in jailbreaking it
[07:06:52] <aaronl> you can pirate apps, but come on, they all cost like $2
[07:07:12] <aaronl> and once you jailbreak it, all bets are off on things actually working
[07:07:23] <Dark_Shikari> yes, jailbraking is not very popular for one reason
[07:07:24] <Dark_Shikari> android exists
[07:07:32] <Dark_Shikari> If you want to actually do things with your phone, you buy an android
[07:07:59] <Dark_Shikari> if you want to live in locked down world where childrens' apps get banned because apple interpreted them as allowing "users to program", you use an iphone.
[07:08:39] <Dark_Shikari> And users are mostly choosing the former.  Though probably largely because AT&T sucks, and not for any DRM-related reasons.
[07:08:42] <saintdev> Dark_Shikari: no game of life either
[07:09:22] <Dark_Shikari> saintdev: zomg turing-complete automata
[07:10:07] <saintdev> read a blog post about why apple needs to ban the game of life, was quite funny
[07:10:48] <Dark_Shikari> the best post was the one about how apple's statement on "original programming languages" was a judgement on the natur of conciousness
[07:10:52] <Dark_Shikari> *nature
[07:10:56] <kshishkov> because any lifeform in that game on iHardware evolves into Steve Jobs?
[07:10:59] <Dark_Shikari> http://joeberkovitz.com/blog/2010/04/08/apple-takes-stance-on-consciousness/
[07:11:14] <aaronl> are you saying that android phones aren't sim-locked?
[07:11:24] <aaronl> or just that it's less of an ordeal to unlock them?
[07:11:27] <Dark_Shikari> Apple is implicitly taking a position that apps are not “originally written” in the minds of developers, in the form of cognitive representations of problems and their solutions.
[07:11:33] <Dark_Shikari> They are taking a position that the brain is not a translation tool for mapping from these representations into C, Objective-C, or what have you. They are subscribing to the theory of a “ghost in the machine”, implying that at some point an app crosses some magical boundary from being an mental thing into a physical thing that is “written” in some definite programming language.
[07:11:51] <Dark_Shikari> They are maintaining this because, if they weren’t, every single iPhone app would violate their licensing agreement by virtue of the developer’s mind itself being a tool that produces Objective-C as an “intermediary result”. Apple may thus be the first company to bet the farm on Cartesian dualism.
[07:11:57] <Dark_Shikari> <3
[07:12:20] <kshishkov> ok, you'll get A- on your essay for Philosophy class
[07:12:28] <Dark_Shikari> that was seriously the best blog post on that issue, ever
[07:13:06] <kshishkov> wow, Ubuntu just offered me to upgrade libav*
[07:13:14] <saintdev> lol
[07:14:01] <Dark_Shikari> yes, to 0.5.1!
[07:14:39] <KotH> salut
[07:14:53] <kshishkov> shalom
[07:16:24] <Dark_Shikari> bonjour
[07:16:34] <siretart> buna diminaca
[07:16:41] <Dark_Shikari> ni hao
[07:16:44] <kshishkov> hejsan
[07:17:08] <kshishkov> Dark_Shikari: "nimen hao" would be more correct since you greet a group of people
[07:17:27] <siretart> what language is this?
[07:17:33] <kshishkov> Chinese
[07:17:59] <Dark_Shikari> ohayo
[07:18:24] <kshishkov> おっす
[07:18:26] <Dark_Shikari> guten tag
[07:18:40] <kshishkov> guten morgen here
[07:20:24] <pJok> buenos dias
[07:20:25] <pJok> i think
[07:21:01] <kshishkov> goda morgnar
[07:21:30] <pJok> or was it buenos noches?
[07:21:48] <kshishkov> that's for "good night" in Spanish
[07:22:30] <pJok> then i recalled correctly
[07:23:10] <av500> dobro jutro
[07:23:32] <kshishkov> добрий ранок
[07:33:44] <KotH> aaronl: in .ch and .de, very few phones are sim locked
[07:34:04] <KotH> aaronl: in .ch you really have to search for a sim locked phone...
[07:48:58] <aaronl> i understand that
[07:48:58] <aaronl> i was talking about the US
[07:48:58] * aaronl is an americentric bastard
[07:49:37] <KotH> the us isnt the world
[07:50:02] <kshishkov> indeed
[07:50:31] <KotH> .o0(although it's the most agressive race in recent history)
[07:50:32] <aaronl> i'm visiting .ch and .de for the first time in july :)
[07:50:59] <aaronl> i think i'm pretty well-travelled for an american, but i've definitely neglected europe
[07:51:13] <aaronl> so this trip is very exciting
[07:51:18] <kshishkov> KotH: not mentioning people who started two world wars and very peaceful Russians
[07:51:38] <KotH> dont worry about europe... nothing here beside barbars and raceists
[07:51:55] <superdump> barbarians* racists* ?
[07:52:07] <KotH> yes, thanks
[07:52:15] <kshishkov> superdump: babers and long-distance runners
[07:52:25] <superdump> barbers and race drivers
[07:53:06] <kshishkov> yep
[08:22:49] <wbs> bilboed-pi: in gstreamer, is there any way to measure the amount of time spent in each element of a pipeline?
[08:23:24] <bilboed-pi> wbs, non trivially
[08:23:56] <bilboed-pi> wbs, are you the one emailing as wl2776 on gst-devel ?
[08:24:21] <wbs> nope, i'm not on those lists at all
[08:24:36] <bilboed-pi> ok
[08:24:59] <bilboed-pi> if it's an element you control, you can do it yourself in your element's chain method
[08:25:10] <bilboed-pi> if not... well it gets very tricky
[08:25:26] <wbs> no, I don't control it...
[08:25:37] <wbs> on the other hand, I control the previous and next elements
[08:25:54] <wbs> so in principle, I could grab timestamps at those points and diff them
[08:26:52] <bilboed-pi> wbs, also... maybe #gstreamer would be a better place (just realized that). mru's tourette syndrom might start kicking in otherwise :)
[08:27:13] <wbs> probably. just checking if there's something obvious I've missed :-)
[09:49:42] <kshishkov> mate!
[09:55:45] <pross-au> Gidday
[09:55:58] <pross-au> I heard something about the Ukraine the other day, but now i forget.
[09:56:02] <pross-au> It was an interesting factoid.
[09:56:35] <kshishkov> you should
[09:56:51] <kshishkov> April 26th is not only world international property day
[09:57:15] <pross-au> Yeah?
[09:57:20] <kshishkov> it's also the date when certain Ukrainian power plant suddenly output yearly norm of electricity
[09:57:23] <pross-au> April 25th was our 'Memorial Day'
[09:57:44] <BastyCDGS> sorry, internet was away until now
[09:57:48] <kshishkov> memorial for what? WWI veterans?
[09:57:51] <pross-au> How do you celebrate that anniversary kshishkov ?
[09:57:53] <BastyCDGS> hope I didn't miss anything important...
[09:57:55] <pross-au> kshishkov: yes
[09:58:19] <BastyCDGS> here in belgium there is something similar to a memorial day
[09:58:24] <BastyCDGS> but for WW2
[09:58:26] <kshishkov> pross-au: we don't since we can't get more funding for it
[09:58:37] <pross-au> Well ours is not called Memorial Day. It's called ANZAC day.
[09:58:42] <BastyCDGS> it's even a work-free day here
[09:58:46] <pross-au> But there are no more WWI veterans left
[09:59:07] <kshishkov> well, here WWI was screwed by 1917 revolutions
[09:59:16] <kshishkov> so nobody cares about it much
[09:59:21] <pross-au> It should be renamed to AUSCANUKUSNZ day
[09:59:24] <KotH> pross-au: you remind me that i wanted to visit the anzac grave yard in turkey...
[09:59:50] * kshishkov has not heard about Gallipoli at all
[09:59:52] <pross-au> KotH: lots trek there for the 25th April dawn service
[10:00:17] <pross-au> Of course, I find it wierd how we only remember back to WWI
[10:00:26] <pross-au> Its not like it was our major conflict
[10:00:37] <KotH> nope, it isnt
[10:00:55] <pross-au> Where are you from again KotH ?
[10:00:59] <KotH> kshishkov: it was one of the most blody battles during WWI
[10:01:07] <KotH> pross-au: from the other side of the trench :)
[10:01:16] <pross-au> Awesome
[10:01:28] * KotH has lost at least 6 family members there
[10:02:06] <BastyCDGS> oh, that's sad KotH
[10:02:10] <pross-au> Sorry to hear that
[10:02:11] <BastyCDGS> :(
[10:02:16] * kshishkov does not know his lieage that far
[10:02:19] <kshishkov> *lineage
[10:02:38] <pross-au> its only four generations ago kshishkov
[10:02:45] <kshishkov> so?
[10:03:05] <pross-au> thats nothing! a drop in the bucket as we say here
[10:03:26] <kshishkov> well, my grandparents know a little about their parents but that's all
[10:04:42] <pross-au> thankfully we have an excuse here
[10:04:54] <kshishkov> same excuse here
[10:05:04] <pross-au> 200 odd years is enough :P
[10:06:06] <kshishkov> here we had 1937-1939
[10:06:23] <kshishkov> and 1917-1921
[10:07:13] <BastyCDGS> my brother from my grandmother was shot down from behind while walking over a street by the nazis
[10:07:23] <BastyCDGS> s/my/the
[10:07:26] <pross-au> Is there mandatory service in the Ukraine?
[10:07:40] <kshishkov> for what?
[10:07:47] <pross-au> The armed services?
[10:07:54] <kshishkov> ah, of course
[10:08:01] <pross-au> Voluntary here
[10:08:19] <pross-au> there was constription in WW2
[10:08:38] <kshishkov> IIRC everybody here is still considered as military reserve till his death
[10:08:41] <pross-au> (that means forced service)
[10:09:13] <kshishkov> and we have conscription too of course!
[10:09:15] <pross-au> *conscription
[10:09:40] <BastyCDGS> well I'm afraid that if it comes hard on hard this will be just in every state handled this way
[10:09:52] <pross-au> Yes BastyCDGS
[10:10:07] <pross-au> Hence the FFmpeg Army
[10:10:24] <BastyCDGS> yes we transcode their weapons to flowers ;)
[10:10:47] <kshishkov> try prying a shotgun from mru's hands first
[10:11:16] <pross-au> more like transcoding digital feed from UCAS flights
[10:12:49] <BastyCDGS> well FFmpeg already helps on this ;) it allows us transcoding videos which show cruelty of war and hand that to people who couldn't play that format otherwise :)
[10:13:03] <BastyCDGS> so they awake what's really happening
[10:14:10] <pross-au> Cruetly would be watching that in Theora
[10:14:21] <pross-au> but i digress
[10:16:09] <kshishkov> we have "Victory" day on 9th of May for the ending of WWII and remembering people who fought there
[10:17:56] <BastyCDGS> http://noviomagus.tripod.com/background-history.htm
[10:18:41] <kshishkov> it was even worse for Ukraine
[10:22:55] <BastyCDGS> belgium has holiday on 9th november (end of ww1)
[10:24:51] <FUautotools> 9th?
[10:25:13] <BastyCDGS> 11th sorry
[10:25:31] <BastyCDGS> was mixing with 9-11 ;)
[10:25:50] <kshishkov> hmm, wasn't Belgium the place where Ypres is situated?
[10:26:10] <pross-au> BastyCDGS: thats because the rest of world say DAY then MONTH
[10:26:41] <kshishkov> pross-au: in his case it's 11.11
[10:26:56] <pross-au> 11:11 on the 11th of November. Yes we do that too.
[10:26:57] <BastyCDGS> yes i was mixing with WTC somehow ;)
[10:27:03] <BastyCDGS> just swapping day/month
[10:27:22] <BastyCDGS> and yes ypres is be
[10:27:41] <kshishkov> nice gases you did have there
[10:28:37] <BastyCDGS> gases?
[10:29:21] <kshishkov> http://en.wikipedia.org/wiki/Mustard_gas
[10:29:27] <FUautotools> gasses
[10:30:53] <BastyCDGS> i understood the word but I dunno what gases he means
[10:31:29] <kshishkov> look at the section "Use" or guess why that gas is sometimes called "Yperite"
[10:32:34] <BastyCDGS> oh you did mean nerve gases
[10:33:01] <FUautotools> Chlorine and Mustard gas are not nerve gases
[10:35:59] <BastyCDGS> I don't have expertise on this sorry
[10:36:15] <BastyCDGS> I really don't differ internally between poison/nerve gases
[10:36:34] <kshishkov> ok, then you can continue telling us about Amiga stuff
[10:37:26] <BastyCDGS> well I don't want that you interrupt your topic just because of me ;)
[10:40:44] <BastyCDGS> maybe you can just teach me something about this
[10:41:36] <KotH> pross-au: no need to be sorry, it was war time... and they defendet their homes, fully knowing what will happen
[10:42:22] <BastyCDGS> btw, I'm just reading than saddam was also using mustard against iran
[10:42:27] <BastyCDGS> s/than/that
[10:51:00] <pross-au> Amiga?
[10:51:25] <BastyCDGS> what's with the Amiga?
[10:51:44] <av500> pross-au: that used to be a computer
[10:51:47] <pross-au> I dunno
[10:51:54] <pross-au> Duh!
[10:51:54] <BastyCDGS> oh you didn't know it?
[10:52:08] <BastyCDGS> it was the most-known home computer in late 80's/first half 90's
[10:52:15] <BastyCDGS> and widespread
[10:52:19] <pross-au> Yes yes. Was somebody talking about amiga support
[10:52:29] <BastyCDGS> in ffmpeg?
[10:52:44] <pross-au> 20:40:20 <@kshishkov> ok, then you can continue telling us about Amiga stuf
[10:52:45] <BastyCDGS> I'm currently responsible for proper decoding of amiga specific formats ;)
[10:52:56] <pross-au> IFF HAM support
[10:52:59] <pross-au> Nice
[11:08:39] <KotH> ffmpeg - resistance is futile, your codec will be assimilated
[11:09:01] <kshishkov> say that to x264
[11:09:50] <BastyCDGS> aXximilated 264 times?
[11:09:51] <twnqx> the worst thing about that is the now cyclic dependency >_>
[11:10:15] <twnqx> (unless you build lonly libx264 first, then ffmpeg, then the x264 executable)
[11:20:00] <pross-au> its only a cyclic depenancy for as long as '264 stays current.
[11:21:01] <pross-au> h.265 is coming. then the process will start all over again.
[11:21:23] <spaam> pross-au: just wait for h266!
[11:21:29] <mru> h666
[11:22:06] <spaam> omg the codec for the beast?
[11:22:08] <pross-au> spaam: we will have run out of oil and uranium by then
[11:22:28] <mru> uranium, hardly
[11:22:30] <merbzt1> maybe even electrons
[11:22:33] <pross-au> surely that'll be vp66
[11:23:18] <pross-au> theres only 100 years supply of it or sth]
[11:24:00] <mru> and don't forget about the coal
[11:24:05] <mru> there's load of that
[11:24:14] <mru> unfortunately it's very filthy stuff
[11:24:39] <pross-au> We have heaps of coal and uranium here :P
[11:25:33] <pross-au> No guess as to which communist country it is all being sold to...
[11:27:04] <iive> pross-au: no, the currently mined one would be enough for that period, if not recycled. and there is more out there.
[11:28:23] <pross-au> iive: cool. so that 'earth hour' thing where everyone turns their lights of to conserve energy is just a crock of shit?
[11:28:34] <iive> yes
[11:29:30] <pross-au> Mr Fusion for everybody
[11:30:27] <iive> it's made up by activists who live in country that burns coal to produce electricity. Same one that have more fission reactors on ships than on ground
[11:31:29] <pross-au> The iron is that the west wants developing countries to curb their energy use.
[11:31:37] <pross-au> Irony
[11:32:07] <iive> well, west doesn't want these countries to have any kind of reactors.
[11:34:13] <KotH> well, the west doenst want these countries to develop at all, so that they can continue to exploit them
[11:35:16] <kierank> they also are nervous about unstable governments having access to nuclear material
[11:35:57] <KotH> unstable goverments? like teh US? israel? russia?
[11:36:22] <kierank> north korea, iran
[11:36:48] <pross-au> Unstable, as in out of the US and NATO's sphere of influence.
[11:37:06] <iive> kierank: these both have VERY stable governments. haven't changed in decades.
[11:37:16] <KotH> kierank: north koreas goverment has a longer record of staying on the same line than most "western" goverments
[11:37:21] <pross-au> Yep
[11:44:12] <frankuva> av_open_input_file works with rtmp:// but i am unable to define the filename to play on that rtmp url... how can i do that?
[11:47:35] <KotH> by asking in the right channel
[11:48:17] <frankuva> you mean #ffmpeg? i've asked there and got no reply. thanks for your warning i won't be disturbing you in this channel
[11:48:51] <BastyCDGS> maybe there was nobody able to answer your question
[11:48:59] <BastyCDGS> just try it there later again
[11:49:17] <BastyCDGS> remember ffmpeg is huge, not everyone knows everything in ffmpeg
[11:50:33] <merbzt1> frankuva: best bet is to ask on the mailinglist
[11:50:48] <frankuva> ok thank you all
[11:51:30] <BastyCDGS> btw, try to open a file the way you would do with a http:// also
[11:51:45] <BastyCDGS> I don't know about rtmp and alike, but if it's an url it probably has a similar scheme
[11:54:43] <frankuva> i have to run "C" version (code) of this command line: "-i station.flv -f flv rtmp://site.com/station". i am unable to specify that -i parameter so just calling it like http:// does not work because remote server says :" file not found" since i am unable to tell it station.flv"
[11:56:35] <BastyCDGS> try ...site.com/station#file.ext
[11:56:41] <BastyCDGS> if that doesn't work I dunno
[11:56:47] <BastyCDGS> or station/file.ext
[11:59:44] <av500> http://alvarez.site.ac.upc.edu/hdvideobench/ffmpeg-2dwave.html
[12:00:24] * BastyCDGS thinks of doing a parallel IFF-ILBM decoder :D
[12:00:28] <BastyCDGS> one core = one plane
[12:01:05] <BastyCDGS> just a #pragma omp parallel for would do it probably ;)
[12:01:12] <mru> bwaahhahaa
[12:01:15] <av500> omg parallel?
[12:06:25] <pentanol> hi I'm evaluating why ffmpeg crached on my arm and what I've http://codepad.org/NGVwmfhk
[12:06:44] <pentanol> with that, it well allocate memory in first
[12:07:54] <pentanol> but then..... when it tries open input stream and crached there   ic = avformat_alloc_context();
[12:08:44] * av500 does not get that pastebin
[12:09:15] <pentanol> there on codepad
[12:09:47] <kierank> perhaps get rid of all the junk so it is readable ?
[12:09:56] <pentanol> here list of commented option in AVOptions
[12:12:39] <pentanol> wich of these options really important?
[12:12:47] <BastyCDGS> av500 you don't know OpenMP?
[12:13:06] <pentanol> it's from./libavcodec/options.c
[12:18:30] <mru> BastyCDGS: of course we know of openmp
[12:18:43] <mru> we just don't believe it's all it's cracked up to be
[12:19:04] <mru> I've only seen it work well on schoolbook examples
[12:19:46] <BastyCDGS> that was going to av500 because he asked about parallel omp
[12:19:52] <BastyCDGS> sounds like he didn't knew it
[12:20:06] <av500> BastyCDGS: ignore what I say :)
[12:20:12] <BastyCDGS> lol ok ;)
[12:30:22] * KotH sometimes wonders whether some companies do not want to sell anything
[12:30:59] <KotH> device A in single pieces: 400EUR, device A in 1000 pcs: 250EUR, equivalent design self made: 150EUR
[12:34:53] <av500> 4) profit
[12:36:28] <KotH> they wont profit if they dont sell ;)
[12:43:53] <kshishkov> sometimes they do wicked things
[12:44:13] <kshishkov> like IBM software requiring something of IBM server level to run
[12:44:20] <kshishkov> even if intended for PCs
[12:45:12] <av500> kshishkov: there might be people at IBM to whom the PC is a novelty concept...
[12:46:17] <kshishkov> av500: they are long buried cutted corner down
[12:47:01] <av500> big iron ftw!
[12:48:16] <KotH> no coold feet in winter anymore!
[12:48:35] <kshishkov> av500: elephantine software
[12:48:57] <kshishkov> IBM is associated with elefants in some mysterious way
[12:49:26] * av500 prefers his bank to run on big iron and not mcaffee installed pcs
[12:49:46] <kshishkov> COBOL-driven?
[12:49:52] <av500> sure
[12:50:11] <av500> but I am biased, my mom used to be an ibm db2 admin
[12:50:40] <kshishkov> my friends works as an admin in regional office of one bank
[12:51:31] <av500> one day they took away her nice 3270 and gave her a PC emulator, since then pc network downtime was downtime for her too, never happened before...
[12:54:13] <kshishkov> no token ring for her anymore?
[12:54:28] <av500> no, the "new" pc ethernetwork took all that away :)
[12:57:19] <kshishkov> curse you DEC and Ethernet!
[12:57:37] <kshishkov> s/DEC/PARC/
[12:57:50] <twnqx> <KotH> device A in single pieces: 400EUR, device A in 1000 pcs: 250EUR, equivalent design self made: 150EUR
[12:57:59] <twnqx> do the 150€ cover the time spent as well?
[12:58:20] <twnqx> (except that time can actually be fun :P)
[13:00:07] <KotH> twnqx: engineering time is paid seperately
[13:00:21] <KotH> twnqx: and even if, the engineering costs are less than 100EUR/piece
[13:00:43] <twnqx> well, i had a similar effect with my PCBs (the fpga ones)
[13:00:49] <twnqx> cost for one: 200€
[13:00:55] <twnqx> cost for twentyfive: 200€
[13:00:56] <twnqx> >_>
[13:02:15] <KotH> lol
[13:02:35] <KotH> what about tooling costs?
[13:12:17] <twnqx> don't have the invoice here
[13:12:26] <twnqx> but yeah, ordering more would be cheaper
[13:49:34] <BastyCDGS> BBB, have you dealed with my patch in libavformat/iff.c?
[13:49:44] <BastyCDGS> seems really you forgotten one
[13:49:52] <BastyCDGS> btw, I'm shortly afk
[13:59:17] <BBB> spyfeng__: congratulations on your SoC project acceptance! :)
[14:11:46] <BastyCDGS> BBB, I'm back for a short time now
[14:12:12] <BastyCDGS> do you know which patch I meant?
[14:12:19] <BBB> they're applied
[14:12:23] <BBB> since 5 seconds ago :)
[14:12:43] <BastyCDGS> lol what a synchronity :D
[14:14:01] <BBB> also welcome to GSoC :)
[14:14:11] <BastyCDGS> thanx...
[14:14:11] <BBB> so stefano will help mentoring you right?
[14:14:22] <BastyCDGS> yes, although we didn't talk quite some time
[14:14:25] <BBB> I guess I'll help where I can, also andoma and mru might be helpful for you
[14:14:26] <BastyCDGS> but he said he's pretty busy
[14:14:30] <BBB> we'll see how it turns out
[14:15:28] <BastyCDGS> but I've to discuss much stuff right now here because of my exams on 12th may
[14:15:38] <BastyCDGS> so I'm just looking from time to time sorry for that
[14:19:22] <BBB> that's ok
[14:24:12] <kshishkov> BBB: what the task?
[14:25:19] <BBB> mod files
[14:25:22] <BBB> for him
[14:25:26] <BBB> spyfeng does MMS
[14:25:32] <kshishkov> yes, that's what I meant
[14:25:35] <BBB> I'm working wvp2, but not for GSoC
[14:25:49] <kshishkov> it's all not for GSoC but for FFmpeg ;)
[14:25:50] <BBB> slowly though :)
[14:25:55] <BBB> right
[14:26:02] <BBB> although $5k would be a nice stimulus package
[14:26:11] <kshishkov> tell that to mru
[14:26:26] <kierank> kshishkov: http://news.bbc.co.uk/1/hi/world/europe/8645869.stm
[14:26:27] <av500> gee, ppl only code for money these days?
[14:27:35] <kshishkov> kierank: I don't care, even more than I did not cared before
[14:27:49] <kshishkov> av500: unless they can code for fun
[14:28:20] <av500> kshishkov: is there an unkrainen gov tv channel, this is must fun to watch
[14:28:58] <BBB> ?
[14:29:09] <BBB> most if not all of my code was coded for no money
[14:29:22] <BBB> I'm just saying it's nice to get a dinner check at times :)
[14:30:35] <kshishkov> av500: I don't watch TV
[14:30:53] <kshishkov> BBB: yes, except for us it's cash-based economy
[14:31:41] <av500> mru: you have a nice url for why gcc and neon intrinsics sucks?
[14:32:39] <kierank> kshishkov: cheques are too advanced for .ua ?
[14:33:38] <mru> av500: http://hilbert-space.de/?p=22
[14:34:44] <kshishkov> kierank: yes, I've never seen any transaction with a cheque in my life. Cards are spreading slowly though
[14:35:25] <av500> card games are good way to transfer money
[14:35:47] <mru> I know a guy who earns a living in the casino
[14:35:51] <mru> (he works there)
[14:36:12] <kshishkov> mru: he could earn a fortune in casino if he _owned_ it
[14:36:33] <av500> kshishkov: not always, casino in formar eastern germany are all going bust
[14:37:03] <mru> I have a business plan: people will come to my house and give me their money
[14:37:04] <av500> somehow ex-socialists dont like to gamble
[14:37:07] <mru> how could that possibly go wrong?
[14:37:39] <kshishkov> mru: by omitting a clause of not taking anything from your house afterwards
[14:38:11] <av500> mru: depending on what services the "house" provides, it might work
[14:38:24] <mru> losing your money of course
[14:38:39] <kshishkov> sounds like tax office
[14:39:41] <av500> mru: thx for the link, coworker is rewriting in asm as we speak :)
[14:43:53] <kshishkov> is that hard? even _I_ can write asm
[14:44:59] <lu_zero> wbs: who broke ffmpeg as producer lately?
[14:45:14] <av500> kshishkov: not hard, ppl are just lazy
[14:45:33] <mru> writing asm is much easier than things like c++
[14:46:12] <lu_zero> mru: x86 asm makes me wonder
[14:46:37] <mru> even that is easier
[14:46:46] <mru> at least reading it is easier
[14:46:48] <kshishkov> than writing inline x86 asm
[14:47:07] <BBB> so having a table lut[][] which you access as lut[get_bits(..)][plane] didn't make it faster?
[14:47:31] <mru> where are those samples again?
[14:47:53] <av500> x86 asm makes me think I look at .sect random
[14:48:43] <BBB> http://samples.mplayerhq.hu/image-samples/24.iff
[14:48:58] <BBB> http://samples.mplayerhq.hu/image-samples/test.iff
[14:49:04] <BBB> http://samples.mplayerhq.hu/image-samples/ASH.LBM
[14:49:51] <BBB> http://samples.mplayerhq.hu/image-samples/atarist/iff/
[14:50:20] <BBB> BastyCDGS: which one do you use?
[14:59:54] <BastyCDGS> Ooze.iff (24bpp) and Heart.ILBM
[14:59:57] <BastyCDGS> (8bpp)
[15:00:36] <BastyCDGS> BBB, the lut table stuff...lut makes it compared to byte access up to 700-800% faster
[15:00:54] <BastyCDGS> but moving calculation of lut table outside function stack doesn't
[15:01:05] <mru> can you post the links to those files again?
[15:02:12] <BastyCDGS> of course
[15:02:52] <BastyCDGS> http://roundup.ffmpeg.org/issue1727 (no HAM/EHB support, some IFF ILBM files decodes incorrectly)
[15:02:52] <BastyCDGS> http://roundup.ffmpeg.org/issue1796 (IFF ILBM - bad aspect ratio with FFplay)
[15:03:07] <BastyCDGS> they're somewhere in the attachments
[15:03:36] <mru> which is which of those? 8/24-bit..
[15:03:46] <BBB> ooze is 24
[15:03:49] <BBB> heart is 8
[15:04:15] <BastyCDGS> exactly as BBB stated
[15:04:33] <mru> and you did a few minutes ago...
[15:06:07] <BBB> ooze looks weird
[15:06:11] <BBB> are we sure that's correct?
[15:06:44] <BastyCDGS> I can check it on my original amiga if you wish when I'm at home
[15:06:49] <BastyCDGS> but looks correctly to me
[15:06:52] <BastyCDGS> it's art not a photo
[15:06:57] <BBB> hm...
[15:07:01] <BBB> odd lines though
[15:08:12] <mru> how am I suppose to benchmark decoding a single frame?
[15:08:59] <BastyCDGS> just do after the unsigned i;
[15:09:02] <BastyCDGS> START_TIMER;
[15:09:15] <BastyCDGS> and at end of decodeplane8/32
[15:09:15] <BastyCDGS> STOP_TIMER("decodeplane32");
[15:09:19] <mru> a single frame isn't enough to be accurate
[15:09:30] <BBB> decodeplane8 is called per line
[15:09:31] <BBB> it's ok
[15:09:31] <BastyCDGS> this function is called around 8000 times then
[15:10:04] <mru> I'd prefer a longer sample
[15:11:43] <BastyCDGS> for (i = 0; i < 1000; ++) do; ffplay ooze.if; done :D
[15:11:50] <mru> no good
[15:11:54] <BBB> about 24.2k before patch here (decodeplane8()), 7.8k after
[15:11:57] <mru> that only measures the startup overhead
[15:12:01] <BBB> now let's try with a lut[][]
[15:12:07] <mru> 24k what?
[15:12:19] <BastyCDGS> BBB, that's almost the same I got
[15:12:22] <BastyCDGS> for 8bpp
[15:12:35] <BastyCDGS> if I remember right
[15:14:50] <lu_zero> wbs: 46ce50eeadf2d7 broke flux, is it working for you using other streaming muxers?
[15:15:32] <BBB> what's bits_per_coded_sample?
[15:15:34] <BBB> is it always 5?
[15:15:38] <BBB> or can it be 8 or something else?
[15:19:26] <BastyCDGS> for 8bpp it can be 1 to 8
[15:19:55] <BastyCDGS> for 24bpp it can theoretically 1 to 24, but practically it's 9 to 24, because 1 to 8 is handled by decodeplane8
[15:21:03] <BastyCDGS> btw, 0 planes are also legal on amiga, it's a 1 color image, thus only black, etc. although I doubt it would make sense to store a file with that ;)
[15:21:25] <mru> if it's possible, someone will do it
[15:21:42] <kshishkov> and encapsulate into mkv
[15:21:59] <BastyCDGS> the code should handle that though, the plane loop is simply not executed at all...
[15:22:06] <BastyCDGS> you don't have to write any pixels in that case ;)
[15:22:16] <wbs> lu_zero: yeah, it works just fine for me... which part is it that breaks things for you, ssrc or base_timestamp?
[15:22:56] <BBB> hmm
[15:23:01] <BBB> lut[][] = 8.6k dezicycles
[15:23:02] <BBB> amazing
[15:23:24] <BastyCDGS> BBB, could you align lut to 64? i.e. cache line?
[15:23:29] <BastyCDGS> and check if that changes?
[15:23:34] <BBB> umm...
[15:23:40] <lu_zero> wbs: probably the bug was in flux
[15:25:11] <BBB> no
[15:25:11] <BBB> s
[15:25:16] <BBB> still 8.6k
[15:25:46] <BastyCDGS> I think the reason why the calculation stuff is fastest when done inside loop that it puts all values directly to L1 cache on the fly
[15:26:06] <BastyCDGS> and are kept there
[15:26:38] <BastyCDGS> while using lut does only puts values to L1 which are read which calls stalls in the loop for each value once
[15:27:21] <BastyCDGS> maybe do a objdump -d on both and look on that
[15:27:36] <BBB> I can't see what it loads into L1 ;)
[15:28:53] <BastyCDGS> mov 0x0,[0x3c+ebp] => will put [03c+ebp] to L1
[15:29:09] <BastyCDGS> same for mov %cl,[0x40+ebp] etc.
[15:29:20] <BastyCDGS> so they're directly accessible in the loop without any stalls
[15:29:44] <BastyCDGS> have to sign off now, my train back to liege comes in 20 minutes...
[15:30:03] <BastyCDGS> I'll be back here around 19:30-20:00
[15:30:08] <mru> you guys don't have mobile internet?
[15:30:26] <BastyCDGS> I don't even have a mobile device anymore...
[15:30:30] <mru> BastyCDGS: did you see my reply on the ml a few minutes ago?
[15:30:55] <BastyCDGS> nope, will read it when home, also in 2 hours
[15:30:56] <mru> I might be out tonight btw
[15:31:07] <BastyCDGS> oh meeting a sweet girl? ;)
[15:31:13] <mru> maybe...
[15:31:18] <spaam> nice mru ;)
[15:31:18] <mru> no, just some friends
[15:31:33] <spaam> mru: you know what you have to do ;)
[15:31:37] <mru> some of which are girls
[15:31:47] <BastyCDGS> oh an orgy?
[15:31:49] <BastyCDGS> SCNR
[15:32:41] <BBB> I think gcc screws up
[15:32:51] <BBB> let me try something else
[15:32:56] <BastyCDGS> ok I'll to go now...otherwise my train will be away
[15:32:58] <BBB> I think it recalculates lut[][] eveyr iteration
[15:33:03] <BastyCDGS> we'll see again in 2h
[15:33:04] <mru> on arm doing the shift in the loop is obviously faster
[15:33:06] <BBB> while the first ([plane] is always the same
[15:33:13] <mru> since the shift comes for free there
[15:33:40] <BastyCDGS> BBB, one last idea
[15:33:58] <mru> and gcc isn't very smart about building that table
[15:34:01] <BastyCDGS> do a:
[15:34:01] <BastyCDGS> const uint32_t lut [] = &decodeplane8_tab[plane];
[15:34:05] <BastyCDGS> and refer to lut
[15:34:09] <BBB> I know
[15:34:11] <BBB> that's what I'm trying :)
[15:34:19] <BBB> I'm looking into where gcc screws up
[15:34:27] <BBB> but I changed a header accidently so it's rebuilding my tree
[15:34:31] <BBB> takes +/- 3 minutes...
[15:34:32] <BBB> :(
[15:34:46] <BastyCDGS> ok I'm away...see you soon ;)
[15:35:26] <BBB> mru: will get you the x86 numbers in a bit
[15:35:30] <BBB> my guess is that it's faster also
[15:35:34] <BBB> if you do it right
[15:38:21] <mru> my diff: http://pastie.org/937417
[15:42:43] <lu_zero> bug in flux fixed
[15:43:41] <BBB> 7.6k to 7.4k now
[15:43:47] <BBB> so slightly faster
[15:44:05] <BBB> with a 2D lut
[15:44:13] <BBB> is that faster on ARM, mru?
[15:44:38] <BBB> the shift-in-loop is definitely slower here
[15:44:42] <BBB> from 7.6k to ~8.5k
[15:45:38] <lu_zero> BBB: what are you doing?
[15:45:51] <BBB> doing basty's work :-p
[15:48:32] <wbs> lu_zero: good that it was fixable in flux, since i think the rtp muxer is much more standards compliant now
[15:50:07] <lu_zero> wbs: if fact I was wondering since the change made sense
[15:50:39] <lu_zero> and the fix in flux was quite simple
[16:01:46] <mru> BBB: 2d array is fine on arm as well
[16:02:49] <mru> and the patch I used http://pastie.org/937467
[16:06:42] <BBB> excellent, that's an exact replica of my patch, more or less
[16:06:49] <BBB> ok, let's have him re-do the effort then :)
[16:06:53] <BBB> we shouldn't make patches for him
[16:06:55] <BBB> that's no good :)
[16:09:12] <jai> on that note, i remember justin splitting patches for me at some point
[16:09:28] <jai> as a "demonstration"
[16:09:43] <BBB> we're doing the actual performance checks for him to show which is fastest
[16:09:47] <BBB> he only has to implement that one then
[16:09:51] <jai> ah
[16:09:59] <mru> he needs to learn proper benchmarking
[16:09:59] <BBB> ;)
[16:10:06] <BBB> right
[16:10:09] <BBB> he claimed this was slower
[16:10:12] <BBB> which we didn't believe
[16:10:15] <mru> as well as optimising for post-m68k cpus
[16:10:15] <BBB> we now show it really is faster
[16:10:18] <BBB> when doing it correctly
[16:11:10] <mru> the 2d table is only 512 bytes so it fits easily in cache
[16:11:19] <mru> there's no way rebuilding it on the fly is going to be faster
[16:12:09] <lu_zero> if you don't miss the cache
[16:12:17] <mru> it won't miss
[16:12:22] <mru> it's 512 bytes
[16:12:27] <mru> L1 cache is 16-32k
[16:12:39] * lu_zero thinks about perverted cache layouts
[16:12:40] <lu_zero> uhmm
[16:15:48] <BBB> mru is right, there's no way it could be slower
[16:16:08] <BBB> gotta run to a meeting now, I'll revert the int->unsigned parts that are unnecessary in a bit
[16:17:16] <mru> do they harm?
[16:18:55] <lu_zero> ok, now it's ffplay turn =P
[16:19:12] <mru> ffplay is not useful for benchmarking anything other than ffplay itself
[16:19:15] <mru> and possible sdl
[16:19:15] <lu_zero> the mpeg2 decoder pukes on master but works flawlessly
[16:19:26] <lu_zero> mru: yet another issue ^^
[16:19:42] * lu_zero is doing some checks with the rtsp stuff
[16:19:43] <mru> yeah, I realised that with your second line
[16:21:32] <lu_zero> the seeking is flawless now =)
[16:22:50] <BBB> \o/
[16:23:11] <wbs> lu_zero: i have to use -noframedrop for it to work reliably after seeks
[16:23:28] <wbs> but that's mainly an ffplay issue I think, probably same as Luca A filed on roundup today
[16:26:19] <nfl> BBB: hi could you create a "home document" for ffmpeg on the gsoc site?. that way the accepted students list will be shown.
[16:26:26] <lu_zero> yup
[16:29:04] <lu_zero> Compn: you wrote something like ffmpeg cannot play $unsupportedcodecidon'tknow in $containeri'mnotaware pointing a sample with no extension...
[16:34:23] <jai> that's one of the more retarded melange "features"
[16:35:36] <mru> that app is retarded through and through
[16:35:49] <mru> what fools wrote it?
[16:37:08] <jai> gsoc kids
[16:37:11] <jai> and some googlers
[16:37:14] <nfl> jai: you have to admit though that the map is cool ;)
[16:37:30] <jai> nfl: umm..that's got nothing to do with melange
[16:37:50] <jai> nfl: just use the google maps api, its pretty trivial
[16:37:54] <nfl> true, i was talking abt the home document
[16:38:55] <jai> yeah, i dont see why they can't autogen that based on the org description and data pulled from the db
[16:41:39] <nfl> somebody should bug them :)
[16:42:21] <jai> what's the point, they tag all UX issues as wontfix
[16:43:12] <nfl> why would they do that?
[16:44:35] <jai> good question :)
[16:49:03] <wbs> lu_zero: the sample compn pointed to was svq3 and qdm in a mov container, you have the same in sample*.mov in DSS, too
[16:55:14] <astrange> i don't suppose anyone remembers which mpeg-2 sample uses field pictures?
[16:55:17] <astrange> i know one of them does
[16:56:13] <mru> maybe the ones in MPEG2/interlaced
[16:56:22] <iive> you mean interlace?
[16:56:36] <astrange> there's two ways to do interlaced
[16:56:50] <astrange> field picture (like h264 PAFF) is much rarer but i found one in there
[16:57:00] <astrange> i think it might have been broken_ntsc.mpg
[16:57:37] <mru> sounds likely
[17:09:34] <peloverde> mru, http://people.xiph.org/~xiphmont/lj-pseudocut/o-response-1.html
[17:13:10] <mru> omg
[17:13:12] <mru> OMG
[17:13:19] <mru> *OH MY GOD*
[17:13:48] <elenril> sue him for misspeling your name
[17:13:57] <kierank> oh good more drama
[17:14:01] <mru> that would be hard
[17:14:07] <elenril> Ogg's Good Name << haha
[17:14:14] <kierank> holy shit that's long
[17:14:23] <mru> and he called mine tl;dr
[17:15:51] <Kovensky> <@Myrsloik> I have a hypothetical question for you...
[17:15:51] <Kovensky> <@Myrsloik> let's say the company I work at is going to build a bike shed, should I ask what color it's going to be?
[17:15:54] <Kovensky> <Plorkyeran> I don't know how you could possibly pass up the chance to argue over the color of a bike shed
[17:15:58] <kierank> are the patents for mp4 actually relevant?
[17:15:58] <Kovensky> <Plorkyeran> it'd be like a dream come true
[17:16:06] <mru> kierank: of course not
[17:16:52] <astrange> iirc the only patent on mp4 as a container format is on hinted streaming
[17:17:10] <peloverde> I thought BIFS had some patents (not that anyone uses BIFS)
[17:17:19] <mru> both of those are totally useless
[17:17:35] <mru> and ogg is hardly a replacement for either even if they were useful
[17:17:53] <Compn> lu_zero : rtsp://stream.diffusion.ens.fr/2008_10_03_albarede.mov
[17:17:53] <Compn> ?
[17:18:11] <KotH> Kovensky: please say hi to Myrsloik and ask him whether he is still working on the kknj rips
[17:18:20] <Kovensky> KotH: lol
[17:19:03] <mru> oh, I get it... monty has no sense of humour
[17:19:09] <mru> none whatsoever
[17:19:48] <kierank> oh god there's a next iteration of ogg
[17:19:54] <Kovensky> "By way of clarification, Ogg is for all codecs." <-- but no non-xiph codecs specify how they should be muxed in that, nor ogg makes any effort to do otherwise
[17:19:58] <Kovensky> kierank: yes, there is
[17:20:02] <kierank> transOgg
[17:21:26] <mru> wtf is wrong with monty?
[17:21:36] <mru> does he actually believe the crap he's spouting?
[17:22:05] <peloverde> I think he's kind of like Bill Joy who also started out pretty smart then turned into a total crackpot
[17:22:26] <mru> like rms
[17:22:39] <KotH> who's bill joy?
[17:22:40] <mru> only monty wasn't even half as smart to begin with
[17:22:45] <mru> KotH: sun guy
[17:23:07] <mru> wrote lots of early unix stuff
[17:23:15] <peloverde> KotH, Bill Joy was one of the Sun co-founders supposedly wrote BSD TCP in a weekend, also the original author of vi
[17:23:32] <mru> and this guy was actually inventing the stuff
[17:23:38] <mru> not just plagiarising it like rms
[17:24:05] <Kovensky> I need a t-shirt that says "I AM COMMITTEE".  <-- loses points for not suggesting "I AM BOSS"
[17:24:09] <KotH> hmm.. is the rant worth to read?
[17:24:17] <KotH> i mean... it's LOOOOOOOOOOOOOOOOOOOOOOOOOOONG
[17:24:38] <mru> he's mostly nitpicking
[17:24:40] <KotH> mru, peloverde: thanks
[17:24:50] <Kovensky> most of it is quoting mru and nitpicking
[17:25:25] <KotH> if it's just nitpicking w/o anything novel to learn, i rather finish my work here than waste my time
[17:26:34] <elenril> unfunny troll is unfunny
[17:26:48] <elenril> KotH: don't read it, it's boring
[17:26:50] <mru> at least I managed to annoy him
[17:27:14] * elenril goes back to hacking fortran code
[17:27:58] <KotH> elenril: you read it?
[17:28:05] <KotH> elenril: even though it was *effort* ?
[17:28:13] <elenril> some of it
[17:28:45] <mru> "the Google announcement"
[17:28:47] <mru> what announcement?
[17:29:17] <Kovensky> "It is also not possible to stream live in MP4 at all; the bitstream format simply does not have the feature" <-- well, you can, but with a small delay... right?
[17:29:25] <astrange> maybe vp8 is going to use ogg II?
[17:29:53] <astrange> i don't get why ogg is supposed to be streamable if it doesn't repeat headers and vorbis has 4KB headers
[17:29:59] <mru> Kovensky: mp4 does allow streaming with a delay
[17:30:33] <mru> but low-latency streaming with mp4 is impossible
[17:30:37] <mru> it wasn't designed for that
[17:30:54] <mru> it was designed for low-overhead and easy seeking in disk-based storage
[17:30:58] <Yuvi> mru: did you ever contribute to nut?
[17:31:02] <mru> and there it excels
[17:31:14] <mru> Yuvi: I've taken part in some discussions
[17:31:27] <mru> and I own the domain name :-)
[17:31:37] <elenril> lol
[17:32:08] <Yuvi> I could have sworn its sync didn't waste 64 bits like ogg does
[17:32:10] <Kovensky> <@mru> and there it excels <-- it's still extremely weak against corruption
[17:32:44] <mru> add reliable to the storage requirements
[17:32:46] <kierank> they talk about this transOgg format being complete yet it seems development was done in secret
[17:33:42] <KotH> kierank: if a group of experts work together, they will end up with a superior format. especially if they can work undisturbed by outside forces
[17:33:46] <KotH> kierank: see tarkin
[17:33:56] <mru> KotH: yes *experts*
[17:34:02] <mru> these are anti-experts
[17:34:10] <mru> see tarkin
[17:34:36] <KotH> well, i must say, that the tarkin ml was some quite interesting reading
[17:34:38] <mru> that list archive makes for some amusing reading
[17:34:44] <mru> lol
[17:34:50] <Kovensky> KotH: lol
[17:34:59] <peloverde> KotH, I suppose that's why AAC has some awful bitstream flaws that I managed to trip all over on my first implementation
[17:35:14] <Yuvi> he's completely wrong about overhead for mp4 quick start and needing special muxing to stream matroska...
[17:35:42] <KotH> imho we should invite monty to ffcon
[17:35:49] <KotH> ohfuck..
[17:35:58] <mru> would he dare?
[17:36:01] <KotH> does anyone have the time to organize ffcon?
[17:36:04] <kierank> i'd go just to see that
[17:36:19] * KotH has adresses for places and can help with contacts
[17:36:26] <KotH> but i've no time to do it :(
[17:36:30] <kierank> get rathann to organise it at cern ;)
[17:36:31] <mru> http://sv.wikipedia.org/wiki/Nyk%C3%B6pings_g%C3%A4stabud
[17:36:38] <jai> i assume it will be in EU?
[17:36:47] <BBB> nfl: already did
[17:36:50] <BBB> nfl: but it's not showing
[17:36:54] <BBB> nfl: I don't know why
[17:36:58] <KotH> kierank: .ch and especially GE is way too expensive
[17:36:58] <BBB> annoys the hell out of me
[17:36:59] <Kovensky> if you do it in the US in b4 you get raided by MPAA / RIAA
[17:37:16] <jai> lol
[17:37:16] <kierank> KotH: true
[17:37:25] <kierank> but it's a nice place to visit
[17:37:25] <mru> hey, let's ask mpaa for sponsorship :-)
[17:37:30] <KotH> mru: what's that?
[17:37:36] <mru> now *that* would be a good troll
[17:37:46] <kierank> get mpeg-la to sponsor
[17:37:49] <jai> FFCon - Brought to you by Jack Valenti?
[17:37:52] <mru> KotH: read the english version
[17:40:05] <KotH> mru: for this, we'd need the FFarmy
[17:40:07] <BastyCDGS> so I'm back
[17:40:15] <KotH> BastyCDGS: OH NOES!
[17:40:17] <KotH> ;)
[17:40:33] <Kovensky> what about the FFairforce
[17:40:35] <Kovensky> or airFForce
[17:40:39] <BastyCDGS> well you had 2 hours to run away, if you don't use it...:P
[17:41:33] <mru> may the FForce be with you
[17:41:39] <BBB> I can't find it
[17:41:43] <BBB> god damn google
[17:41:54] <nfl> BBB: thanks anyway
[17:42:06] <BastyCDGS> anything news regarding optimization
[17:42:16] <Yuvi> "This is bitchy livejournal material, not technical critique."
[17:42:17] <KotH> BastyCDGS: i was at the uni and came back :)
[17:42:25] <Kovensky> "index only noticeably improves seek performance in narrow interactive cases, such as HTTP range requests over a satellite or WWAN link. " <-- what about my poor ADSL that is not fast enough to watch youtube on the lowest quality without waiting for it to buffer the whole video before
[17:42:28] <BBB> nfl: sorry
[17:42:35] <BBB> nfl: can you give an example of other projects that have it?
[17:42:53] <mru> Kovensky: according to monty, you do not exist
[17:43:06] <jai> why is the homepage on melange even important?
[17:43:09] * mru once got this error message: You do not exist. Go away.
[17:43:09] <KotH> Kovensky: you dont even have to use such a fringe system
[17:43:18] <KotH> Kovensky: just think "mobile phones"
[17:43:51] <Kovensky> "there are some new use cases that finally make an index needed" <-- seeking on large video files in hard disk drives are a new use case?
[17:43:55] <Kovensky> s/are/is/
[17:43:58] <KotH> mru: deluser `whoami` ?
[17:44:02] <nfl> BBB:  ascend
[17:44:08] <jai> BBB: gentoo has one
[17:44:29] <KotH> mru: btw: are you gonna write an answer to taht answer?
[17:44:35] <BastyCDGS> mru, yesterday when you added me to voice list I wasn't registered at nickserv, so I'm away again...but I'm now logged in
[17:44:40] <BastyCDGS> with nickserv
[17:44:58] <mru> let's try again
[17:46:19] <BastyCDGS> thanx, I quit channel short and return should work then
[17:47:03] <BastyCDGS> hmm lost v again...
[17:47:05] <Kovensky> "when latencies are high, latency is in the seek, not the read" <-- it seems that he only considers satellite high-bandwidth connections
[17:47:11] <kierank> http://people.xiph.org/~xiphmont/hv40_for_ed/ oh noes xiph hosting patented file formats
[17:47:12] <BastyCDGS> why is this?
[17:47:19] <Kovensky> are rotating HDDs also considered high latency? =p
[17:47:33] <mru> 10ms is medium
[17:47:52] <mru> hmm, HDDs have a medium medium latency...
[17:50:48] <BastyCDGS> However, a (static) 2D array is faster than the original patch...
[17:51:00] <BastyCDGS> do you mean const static in the decodeplane8 function?
[17:51:36] <BBB> sloooooooooooooooooooooooooooooooooooow
[17:51:39] * BBB kicks google
[17:53:14] <Kovensky> KotH: <@Myrsloik> zfs: Mentar is the one "working" on them
[17:53:27] <BastyCDGS> please summarize up what is the fastest method for dp8 you found out then?
[17:53:31] <astrange> "them"?
[17:54:30] <KotH> Kovensky: oh.. damn...
[17:54:33] <KotH> Kovensky: ^^'
[17:54:48] <KotH> Kovensky: mixed up the M's ^^'
[17:59:35] <BBB> jai: can you as the gentoo folks how they did that?
[18:03:26] <mru> "When Xiph started out in the early ninties, MPEG was hardly dominant."
[18:03:35] <mru> WTFuuuuuuuuck
[18:03:52] <mru> in the 90s, there was MPEG and NOTHING ELSE
[18:04:12] <BastyCDGS> mru, you forgot IFF-ANIM :D
[18:04:26] <BastyCDGS> that existed in the 90s, too. ;)
[18:04:32] <mru> just toys
[18:04:46] <Kovensky> wasn't there Real and Indeo too?
[18:04:51] <mru> also toys
[18:04:52] <KotH> asf!
[18:05:03] <Kovensky> s/was/were/
[18:05:11] <mru> what was digital broadcast using?
[18:05:18] <mru> and are still using
[18:05:22] <Kovensky> there was digital broadcast?
[18:05:28] <kierank> in the early 90s?
[18:05:36] <KotH> hmm...
[18:05:38] <kierank> I thought mpeg-2 sd was standardised in '95 or so
[18:05:40] <Kovensky> that's mid to late 90s
[18:05:48] <Kovensky> at best
[18:06:00] <mru> and there is no public record of xiph before 98
[18:06:08] <BastyCDGS> one question about that i = b32 stuff in the 2nd for, I know that it isn't necessary but thought keep it for readibility
[18:06:11] <KotH> i remember that cable providers used digital links between the cities in the 90s, but dont remember when and dont know what they used
[18:06:37] <KotH> in .ch taht is
[18:06:44] <kierank> eurovision used mpeg-2 iirc then
[18:07:08] <BastyCDGS> BBB, so should I keep i = 32 or remove it?
[18:07:23] <mru> remove it
[18:07:28] <BastyCDGS> ok
[18:07:30] * KotH remembers the introduction of digital satelite broadcast in mid 90s
[18:07:45] <BastyCDGS> and change     const uint32_t lut[] = {0x0000000,
[18:07:45] <mru> KotH: and I'm sure they didn't use ogg
[18:07:50] <BastyCDGS> to     static const uint32_t lut[] = {0x0000000,
[18:07:52] <KotH> ofc not!
[18:07:56] <BastyCDGS> and keep the shifts inside?
[18:07:59] <KotH> iirc it was mpeg2
[18:08:02] <BastyCDGS> that's all for new patch?
[18:08:02] <KotH> but i'm not sure
[18:08:14] <mru> mpeg2 is likely
[18:08:21] <KotH> but it was definitly one of teh mpeg family
[18:08:48] <kierank> mpeg-2 implementations sucked a lot back then
[18:09:06] * KotH remembers the discussion in #mplayerdev about broadcasts and mpeg-ts back then
[18:09:27] <kierank> anything involving movement = blockfest
[18:09:28] <KotH> hmm.. wait... #mplayerdev was at least 5y later
[18:09:39] <mru> lol, monty doesn't even know his own invented terminology
[18:09:50] <KotH> i'm starting to mix up dates... looks like i'm getting old
[18:10:59] <KotH> ok.. time to go home
[18:11:02] <KotH> have a nice evening
[18:11:08] <KotH> and blame spaam!
[18:11:39] * _av500_ blames ash cloud
[18:11:58] <Kovensky> KotH:
[18:11:58] <Kovensky> <@Mentar> terrible source
[18:11:58] <Kovensky> <@Mentar> kinda hope we'll get a remaster
[18:13:00] <BBB> nfl: done
[18:13:03] <spaam> KotH: pff i dodnt do anything wrong :D
[18:13:35] <nfl> BBB: thanks :)
[18:13:56] <BBB> and... I'm on the map also now
[18:15:14] <BastyCDGS> hey I think I got it, you mean I should move the static const stuff from my 2nd patch where the static const is outside of any function just inside the loop?
[18:16:02] <BastyCDGS> s/loop/function
[18:16:34] <jai> BBB: ah, i see you did it
[18:16:38] <jai> BBB: sorry, was afk
[18:17:15] <BBB> BastyCDGS: yes you can do that
[18:17:31] <BBB> BastyCDGS: the compiler output is the same, just the namespace is different
[18:17:42] <jai> "Accurate Seeking API"?
[18:17:44] <jai> oh well...
[18:17:45] <BastyCDGS> ok so I guessed right that your left-out replies to my past questions were indicating that I was guessing wrong ;)
[18:17:59] <BBB> nope, you're right
[18:18:14] <BBB> I was just not reading all messages
[18:18:18] <BastyCDGS> ? but how it can then increase speed by 3%?
[18:18:18] <BBB> was a bit busy with other things
[18:18:27] <BBB> it's two-dimensional
[18:18:37] <BBB> lut[][] instead of lut[] << plane
[18:18:47] <BBB> so you don't calculate the entries anymore
[18:18:52] <BBB> they are in read-onloy memory
[18:18:56] <BBB> static const
[18:19:08] <BBB> you just use them directly, without any additional math in the inner loop
[18:19:10] <BBB> = faster
[18:25:29] <BastyCDGS> did you also check if it's faster the new way with inline or without?
[18:25:55] <mru> gcc probably inlines it regardless
[18:26:17] <BastyCDGS> well with the original patch it didn't
[18:26:28] <mru> because the function was huge
[18:29:44] <BastyCDGS> hmm runs lots slower for me
[18:29:54] <BastyCDGS> 8,6k instead 6,2k as my origin patch
[18:30:13] <BastyCDGS> const unsigned b32 = b & ~3;
[18:30:13] <BastyCDGS>     // 8 planes * 4-bit mask
[18:30:13] <BastyCDGS>     static const uint32_t lut[8][16] = {DECODEPLANE8(0), \
[18:30:13] <BastyCDGS>                                         DECODEPLANE8(1), \
[18:30:13] <BastyCDGS> [...]
[18:30:30] <BastyCDGS> init_get_bits(&gb, buf, buf_size * 8);
[18:30:30] <BastyCDGS>     for(i = 0; i < b32; i += 4) {
[18:30:30] <BastyCDGS>         const uint32_t v = lut[plane][get_bits(&gb, 4)];
[18:30:30] <BastyCDGS>       
[18:31:57] <BastyCDGS> or did I sth. wrong?
[18:31:57] <BastyCDGS> wasn't that the way you meant it be?
[18:32:53] <BastyCDGS> or did you mean:
[18:33:02] <BastyCDGS> const uint32_t v = decodeplane8_tab[plane][get_bits(&gb, 4)];
[18:36:30] <BastyCDGS> sorry, I'm a bit confused now
[18:49:23] <BastyCDGS> submitted a patch
[19:19:14] <BastyCDGS> one question what is the proper way to align a data structure within ffmpeg
[19:19:27] <BastyCDGS> should I just use gcc's alignment attribute or is there a macro for this?
[19:19:46] <BastyCDGS> I mean alignment of a const table
[19:19:50] <Dark_Shikari> DECLARE_ALIGNED
[19:19:57] <BastyCDGS> thanks
[19:21:17] <mru> time to go see those girls...
[19:23:45] <BastyCDGS> have fun with them ;)
[19:29:40] <BBB> the part where he boasts so much that he is going to see girls, makes it quite obvious how little chance he has to go somewhere with any of them tonight
[19:30:01] <BBB> btw mru, tactically speaking a single girl is always easier to corner than a group of girls
[19:30:54] <BastyCDGS> well he could train it here ;)
[19:30:54] <BastyCDGS> file:///home/basty/Desktop/datingsimulator/default.htm
[19:30:56] <BastyCDGS> oops
[19:31:00] <Dark_Shikari> lol
[19:31:24] <BastyCDGS> http://arianeb.com/dateariane/default.htm
[19:31:33] <saintdev> lol
[19:32:09] <jai> keeping it on the desktop is pretty handy :)
[19:32:27] <BastyCDGS> wtf, what's wrong with here?
[19:32:27] <BastyCDGS> DECLARE_ALIGNED(64, static const uint32_t, decodeplane8_tab[8][16])
[19:32:56] <BastyCDGS> yields: /home/basty/src/ffmpeg/libavcodec/iff.c:43: erreur: expected «=», «,», «;», «asm» or «__attribute__» before «decodeplane8_tab»
[19:33:49] <Dark_Shikari> first of all, aligning beyond 16 is generally useless
[19:33:53] <Dark_Shikari> you can't align to a value greater than the stack alignment
[19:34:14] <BastyCDGS> I wanted to align it on cache line boundary and check if that's the cause that the patch is getting such slow for me
[19:34:33] <Dark_Shikari> you can't do that in most cases for anything but memaligned data
[19:34:47] <Dark_Shikari> and you won't get any penalty for cacheline misalignment as long as you don't use unaligned loads
[19:35:29] <BastyCDGS> hmm maybe the bad perfomance for me results in different gcc?
[19:36:20] <BastyCDGS> btw, I downloaded the game above because the server crashed often upon playing
[19:36:36] <BastyCDGS> and according to murphy always when it got interesting ;)
[19:37:33] <BastyCDGS> just a hint, the game is completely uncensored, even at the final end...:P
[19:37:55] <BastyCDGS> it's even animated, but won't tell more here, if you want to check it out just play it :D
[19:38:31] <BBB> BastyCDGS: DECLARE_ALIGNED(64, static const uint32_t, decodeplane8_tab)[8][16]
[19:38:39] <BBB> the sizes go ourside the declare_aligned() macro
[19:38:51] <BBB> but I tried that already and it made no difference at all here
[19:39:16] <BBB> 64-byte alignment is a huge waste for a 512-byte table btw
[19:39:18] <BBB> ust so you know
[19:39:34] <BastyCDGS> doesn't work either :(
[19:39:36] <BastyCDGS> same error
[19:39:44] <BBB> add a ; at the end
[19:40:06] <BBB> I just used it and it worked just fine
[19:40:14] <BBB> see also libavcodec/vorbis_data.c
[19:40:16] <Dark_Shikari> BBB: er, why would it be a waste?
[19:40:35] <Dark_Shikari> ok, so in practice it's a waste because gcc is idiotic and doesn't know how to pack rodata properly
[19:40:41] <BBB> right
[19:40:48] <BBB> in theorry you could rearrange ro
[19:40:49] <Dark_Shikari> in before gcc devs complain that bin-packing is NP-complete
[19:40:52] <BBB> but gcc will just zero-pad it
[19:41:58] <BastyCDGS> still doesn't work
[19:42:08] <BastyCDGS> same error, gcc 4.2.4 bug?
[19:43:16] <BastyCDGS> DECLARE_ALIGNED(16, static const uint32_t, decodeplane8_tab)[8][16] = {DECODEPLANE8(0),
[19:43:17] <BastyCDGS>                                                  DECODEPLANE8(1),
[19:43:20] <BastyCDGS> ...
[19:43:21] <Yuvi> if it's global data, it's more likely to be an as/ld bug
[19:43:42] <Dark_Shikari> wtf is the [8][16] doing outside of the )
[19:43:59] <BBB> that's how vorbis_data does it
[19:44:15] <Yuvi> because of the #pragma align iirc
[19:44:18] <BBB> DECLARE_ALIGNED(16, static const float, vwin64)[32] = {
[19:44:27] <BastyCDGS> I took this as base
[19:44:49] <BBB> sorry, that's all I know
[19:44:54] <BastyCDGS> doesn't it work with 2D arrays?
[19:44:55] <BBB> if that doesn't work then I don't know
[19:44:57] <BBB> it does
[19:44:59] <BBB> I tested it
[19:45:19] <BastyCDGS> maybe you can use only basic data types?
[19:45:24] <BBB> no
[19:45:27] <BBB> I used uint32_t
[19:45:48] <BBB> anyway, it's not gonna help, I tested it :)
[19:45:51] <BastyCDGS> then it's clearly a bug
[19:46:22] <BBB> it works for vorbis_data.c right?
[19:46:27] <BastyCDGS> yes it works
[19:46:27] <BBB> looks more like a typo somewhere or so
[19:46:46] <BBB> what is DECODEPLANE8 defined as?
[19:47:14] <BastyCDGS> same as my latest patch
[20:00:12] <BastyCDGS> new patch submitted to ml
[20:08:47] <BastyCDGS> BBB: what about the 24bpp stuff? there wasn't a review yet
[20:08:54] <BBB> one thing at a time
[20:09:46] <BastyCDGS> well, if you want me fixing at least most critical stuff now, then please do now, since I want to go bed in some minutes
[20:09:53] <BastyCDGS> I'm horribly tired, didn't sleep last night
[20:10:57] <BastyCDGS> another thing I want to mention though, I discussed today with my chief at university if I can do GSoC while being at work
[20:11:07] <BastyCDGS> and combine that with my bachelor exam
[20:11:28] <BastyCDGS> well, he said, it could be something to do what we do at work (that means numeric library stuff)
[20:11:53] <BastyCDGS> stuff like interpolation, fft, etc. can be probably very well be included with my mod task
[20:12:38] <BastyCDGS> (don't confuse the bachelor exam with the education exams I have on 12th may until 21th)
[20:13:00] <BastyCDGS> I have to finish bachelor exam until 15th august
[20:27:52] <BBB> michael's 4-byte dst alignment suggestion is quite good, check that
[20:36:09] <bcoudurier> hi guys
[20:36:36] <BBB> hello bcoudurier's onjoin script
[20:37:37] <bcoudurier> hello BBB
[20:39:15] <BBB> :-p
[20:50:36] <BBB> BastyCDGS: ca you test which method is fastest for 32bpp also and re-send the best patch for that?
[20:50:56] <BastyCDGS> of course, but not tomorrow
[20:51:03] <BastyCDGS> s/tomorrow/today
[20:51:34] <BastyCDGS> btw, just figured out that (buf_size * 8) + bps - 1
[20:51:45] <BastyCDGS> + bps - 1 can be removed, the one test image remained the same
[22:10:07] <twnqx> omg
[22:10:14] <twnqx> sometimes it's so easy...
[22:10:19] <lu_zero> mru: monty loves you, isn't it?
[22:10:40] <twnqx> randomly browse the vendor's webpage, find the native 64bit of the app you try to make work on 64bit for free DL
[22:11:07] <twnqx> add some experimental, slightly patched driver from another vendor, happyness
[22:11:34] <iive> twnqx: sounds like windows.
[22:12:08] <twnqx> or the nightmare of commercial software on linux.
[22:15:04] <twnqx> funnily i received an email from the driver vendor, stating their driver works only up to 2.6.29
[22:15:35] <twnqx> i did not manage to compile an unpatched driver against that, but a slightly patched (change of include locations) works with 2.6.33
[23:59:43] <iive> there is something I don't understand in monty's refutal. He tries to refute mru 50 seeks in 10GB file, and he ends up with 17459 seeks... Even if real seeks are 3.5 or 4 times less, it is still HUGE number.