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

[irc at mansr.com]

[00:00:56] <BBB> there's more wrong with his response
[00:01:01] <BBB> but I'm sure that'll be a nice flamewar
[00:01:04] * BBB goes home
[00:03:52] <iive> of course there is... but.... this is ....
[00:24:15] <saintdev> i like the /. comment "Of course the DESIGNER sees no problems with the format."
[00:26:34] <bcoudurier> monty has his head in his ass
[00:26:51] <bcoudurier> obviously he covered his ears when people were speaking of smooth streaming
[00:27:05] <bcoudurier> I mean you can stream mp4
[00:27:12] <bcoudurier> it's new
[00:27:22] <bcoudurier> like the "skeleton" crap he finds excuse with
[00:28:27] <mru> back
[00:28:29] <bcoudurier> each line you read, the more crap you read
[00:28:41] <mru> anything happen?
[00:28:44] <bcoudurier> wtf is he talking about MTU and ogg pages spanning udp pakets
[00:28:54] <bcoudurier> man, TS was designed to go over _sattelite_
[00:28:57] <mru> yeah, he lost me there
[00:34:59] <bcoudurier> also I don't understand why ogg requires the pages 0 to be headers for codecs
[00:35:09] <bcoudurier> when it is so much design around streaming
[00:35:16] <mru> nobody understands anything about ogg
[00:35:20] <bcoudurier> this doesn't make sense
[00:35:48] <mru> none of it does
[00:36:38] <bcoudurier> well he can try as much as he want to justify the "granule" thing
[00:36:42] <bcoudurier> it was a stupid idea
[00:37:27] <bcoudurier> storing the frame duration, and a "resync" timestamps would be a good idea IMHO
[00:38:14] <Yuvi> I don't really like storing the frame duration unless it's semantically impossible to write it wrong
[00:38:17] <Yuvi> like in mp4
[00:38:45] <mru> frame duration is only useful when it doesn't last until the next frame begins
[00:38:48] <mru> e.g. subtitles
[00:38:56] <mru> for video it's pointless
[00:39:30] <bcoudurier> frame duration is the most compact way
[00:39:42] <bcoudurier> that's why mp4 has so low overhead
[00:39:51] <bcoudurier> basically all timestamps are compressed to one
[00:40:20] <Yuvi> for cfr. with vfr it doesn't gain much
[00:40:29] <bcoudurier> indeed
[00:40:33] <bcoudurier> who does vfr ?
[00:40:45] <Yuvi> anime mainly
[00:40:53] <bcoudurier> everything is cfr except the crap your phone records
[00:40:55] <bcoudurier> anime is cfr
[00:41:05] <bcoudurier> it is _broadcasted_ in cfr
[00:41:24] <bcoudurier> so unless you find the original copy in the studio
[00:41:29] <bcoudurier> which _may_ be vfr
[00:41:32] <Yuvi> no, there's a ton of mixed 24/30 where cgi is 30 and the rest is 24, or overlay is 30, etc
[00:41:47] <bcoudurier> wtf are you talking about
[00:42:04] <bcoudurier> in your head
[00:42:43] <iive> bcoudurier: telecine
[00:42:55] <bcoudurier> telecine is cfr
[00:43:21] <iive> yes, but the broadcast mixex telecined and progressive content
[00:43:38] <iive> when you remove the telecine, you end up with different framerate
[00:43:51] <bcoudurier> different does not mean variable
[00:44:05] <bcoudurier> technically :>
[00:44:36] <bcoudurier> besides no broadcaster nor theater
[00:44:41] <bcoudurier> supports mixed framerates
[00:45:20] <iive> well, if format doesn't allow change of framerate then you need to use format with vfr
[00:45:51] <iive> or worse, use common divider, like these 120fps avi.
[00:46:51] <Yuvi> it's also not too hard to decimate the duplicate frames to get the original fps given how clean dtv is
[00:47:38] <bcoudurier> what broadcaster do duplicate frames ?
[00:47:44] <Yuvi> studio
[00:48:02] <Yuvi> if it's drawn at say 12 fps
[00:48:08] <mru> fairly long sections each with internally constant frame rate are also stored efficiently in mp4
[00:48:24] <bcoudurier> for anime ? yes, but that is still cfr
[00:48:28] <mru> you'd never have "randomly" variable frame rates
[00:49:04] <bcoudurier> and for audio it's always compressed
[00:49:20] <bcoudurier> except for vorbis though hehe
[00:49:38] <Yuvi> eac3, flac, and dca allow for varying frame sizes too
[00:50:40] <Yuvi> but yeah, mp4 storing only duration works well for essentially all content
[00:51:17] <bcoudurier> is that used in practice ?
[00:51:26] <bcoudurier> our flac encoder uses fixed frame size
[00:51:41] <Yuvi> I thought flake used it, which is basically our encoder
[00:53:00] <Yuvi> flake does, guess ours doesn't though
[00:53:05] <bcoudurier> doesn't seem to be changed during encode_frame
[00:54:29] <bcoudurier> well and I hope this is not too common, otherwise mkv becomes a real nightmare
[00:55:56] <Yuvi> amendment: essentially all content minus subtitles
[00:56:14] <Yuvi> forgot that those are a bit annoying in mp4
[00:56:48] <bcoudurier> I agree
[00:56:56] <bcoudurier> but where are they not annoying ?
[00:57:16] <mru> dvd subtitles are easy
[00:57:31] <mru> dvb are nightmare
[00:57:41] <bcoudurier> how does dvd store displaying duration ?
[00:57:58] <mru> in the payload
[00:58:12] <mru> since obviously the PS layer can't do it
[00:58:18] <bcoudurier> indeed
[00:58:38] <bcoudurier> I thought dvb was 2 packets, like display, stop
[00:59:07] <bcoudurier> how does mkv do btw ?
[00:59:07] <mru> dvb has a horrible system with multiple overlapping windows, custom glyphs and god know what else
[00:59:13] <Yuvi> mkv is easy for muxing, demuxing can be annoying depending on how hard you want to look for them or your system doesn't support overlapping subtitles
[00:59:13] <mru> which is stupid
[00:59:34] <mru> because in reality nobody uses anything more than one rectangular window anyway
[01:00:19] <bcoudurier> mkv_write_ass_block looks scary to me
[01:00:56] <Yuvi> cause they stripped the redundant bits out of the ass line and added a new one so that the original ass file can be recovered exactly
[01:01:58] <bcoudurier> also how do you mux them in mkv, do you use the same mechanism as audio ?
[01:02:03] <bcoudurier> like packed frames into a bloc
[01:02:21] <Yuvi> no, one event per block, and a mandatory duration
[01:02:50] <bcoudurier> seems pretty straight forward
[01:03:29] <Yuvi> the trick is that start time+duration can be much greater than the next subtitle's start time (and often is)
[01:04:40] <bcoudurier> yes
[01:05:00] <bcoudurier> for mp4 I would store stts as the delta between sbus timestamps
[01:05:07] <bcoudurier> and store display duration as well
[01:05:29] <Yuvi> sbus?
[01:05:47] <bcoudurier> subs
[01:05:50] <Yuvi> ah
[01:06:11] <Yuvi> I know quicktime only allows stts to be the duration for subs
[01:06:14] <Yuvi> so no overlapping events
[01:06:31] <Yuvi> and no ending before the stts duration
[01:06:39] <bcoudurier> yes
[01:07:09] <bcoudurier> no ending before >
[01:07:15] <bcoudurier> ? huh that's odd
[01:07:26] <Yuvi> and it also doesn't like discontinuous subtitle events from edts
[01:07:45] <bcoudurier> huh that's fucked
[01:08:00] <Yuvi> yeah, it treats the entire sample as basically a static image
[01:08:23] <Yuvi> except for closed captions
[01:09:19] <Yuvi> the no discontinuous events is more that it doesn't tell the renderer to do stuff until too late, so it freezes for a half second on each new sub
[01:09:43] <bcoudurier> buggy
[01:12:29] <Yuvi> so basically you just have to have a blank sample instead of no sample
[01:27:00] <ramiro> great. I had to shut down 3 virtual boxes to have enough ram to compile one c++ file. it took 21% of the system's 4gb of memory...
[01:27:39] <hyc> it's c++, is that so surprising?
[01:27:47] * hyc sticks to C
[01:28:00] <mru> is that all it took? you lucky bastard...
[01:36:28] <mru> slashdot is depressing
[01:37:38] <Yuvi> reddit doesn't like you either
[01:39:50] <mru> any sensible comment gets flagged as troll
[01:40:10] <hyc> yeah, I pretty much had to stop commenting
[01:40:52] <hyc> I'm the leading authority in the software fields in which I work. nobody else, on slashdot or anywhere, has any business rating the correctness of my statements.
[02:38:08] <ramiro> hmm, who exactly calls collect2, and who calls ld?
[02:39:33] <mru> gcc -> collect2 -> ld
[02:39:47] <mru> collect2 is mostly a wrapper around ld
[02:41:00] <ramiro> and gcc reads the specs to choose which flags to pass to collect2?
[02:41:14] <mru> guess so
[02:41:23] <mru> it's a bit shrouded in mystery
[02:41:32] <mru> gcc devs like it that way
[02:41:42] <ramiro> heh
[02:42:09] <mru> makes it harder to interface third-party tools to it
[02:42:18] <mru> like, heaven forbid, a proprietary linker
[02:42:47] <peloverde> or even a gnu linker rewrite :)
[02:42:52] <hyc> collect2 was only introduced because of g++
[02:43:10] <mru> what's special there?
[02:43:24] <hyc> if you didn't have to worry about stupid C++ constructors and destructors, there would be no need for collect2
[02:44:09] <Kovensky> <@ramiro> great. I had to shut down 3 virtual boxes to have enough ram to compile one c++ file. it took 21% of the system's 4gb of memory... <-- I can't compile firefox here, g++ hits an ICE because cc1plus gets ENOMEM after allocating the world on one file
[02:44:40] <mru> compiling firefox is all but impossible on my laptop
[02:44:48] <mru> starts swapping like crazy
[02:44:58] <Kovensky> I tried giving more swap
[02:45:06] <Kovensky> but then I just lost communication to the box and had to hard reboot it
[02:45:10] <mru> I need a new laptop
[02:45:18] <ramiro> or more ccache slaves!
[02:45:22] <ramiro> oops, distcc
[02:45:29] <mru> funny, building firefox killed my laptop too once
[02:45:50] <hyc> hm, I build seamonkey with no trouble on a laptop with 2GB
[02:45:52] <Kovensky> ramiro: would distcc save ram? =p
[02:46:11] <mru> it would build on another machine, presumably with more ram
[02:46:16] <Kovensky> the box where I tried to compile firefox has 1.3G RAM, but runs ZFS, so ~ 300MB go to the ARC
[02:46:42] <mru> my i7/12G has no problem building it in tmpfs
[02:46:57] <Kovensky> oh you
[02:47:23] <Compn> those intel i7 commercials are annoying
[02:47:31] <mru> haven't seen them
[02:47:33] <Compn> 'it speeds up your computer as you work'
[02:47:34] <Dark_Shikari> well they are good chips.
[02:47:39] * mru doesn't watch commercials
[02:47:50] <hyc> it's probably time to start over from scratch. a new libc with no runtime patches for C++ support
[02:47:53] <Compn> it just sounds so hokey
[02:48:04] <hyc> and a new set of compiler/assembler/linker tools
[02:48:07] <Dark_Shikari> mru: http://images.anandtech.com/graphs/amdphenomiix6_042610231918/22621.png
[02:48:18] <Kovensky> the intel commercial here has a guy at some kind of cafeteria yelling that intel's chips are the best, that there's no room for competition, that it just destroys everyone else without a doubt, etc, etc, etc, and then shows a sad robot that overhead the ordeal
[02:48:20] <Dark_Shikari> aka "hooooly fuck the 980X is o.0"
[02:48:24] <Compn> hyc : dalias started working on his own uclibc thing, its in mplayer repo somewheres
[02:48:26] <Kovensky> very annoying and not a good commercial at all
[02:48:43] <hyc> I could just resurrect the C library we wrote for the Atari ST
[02:48:48] <mru> what's magic in the 980X?
[02:48:50] <Compn> hyc : and there is tinycc aka tcc created by fabrice
[02:48:54] <Dark_Shikari> mru: two more cores
[02:48:59] * mru has only a meagre 940
[02:49:01] <saintdev> i can has 12 threads
[02:49:04] <mru> oh, that explains it
[02:49:13] <hyc> I think I looked at tinycc, but it's x86 only
[02:49:22] <Dark_Shikari> it's almost exaclty 50% faster
[02:49:23] * Kovensky only has a meager T2370 and a Sempron2800+
[02:49:31] <mru> tinycc is a toy compiler
[02:49:44] * Kovensky wonders why not clang, other than "eew C++"
[02:50:00] <hyc> that's enough reason
[02:50:05] <mru> I'm curious to see what happens with pathscale
[02:50:08] <mru> probably also c++
[02:50:12] <Kovensky> lol
[02:50:35] <hyc> I think the llvm project has some interesting ideas, but they're missing the most obvious
[02:50:38] <Kovensky> what about pcc, that openbsd likes for wtf knows why
[02:50:43] <mru> what's the difference between i5 and i7 anyway?
[02:50:49] <Kovensky> s/wtf/only de rant/
[02:50:59] <Kovensky> hyc: which is?
[02:51:12] <mru> make something that works
[02:51:14] <hyc> llvm should be focusing on cross-compiling binaries
[02:51:21] <ohsix> hyc: its more than x86 now, has been for ages
[02:51:29] <hyc> bidirectional LVM - machine translation
[02:51:37] <mru> not interesting
[02:51:42] <mru> certainly not for open source
[02:51:47] <hyc> right now they only go from bytecode to machine. go from machine back to bytecode.
[02:52:00] <hyc> and then you can retarget any application to any hardware.
[02:52:09] <hyc> just need to wrap the right runtime library around it.
[02:52:20] <Compn> sounds like java :P
[02:52:26] <mru> you'd always lose something in the conversion
[02:52:42] <mru> the llvm bytecode is still more expressive than machine code
[02:52:50] <hyc> mru: not enough to matter
[02:53:16] <hyc> I was running MSDOS binaries translated to 68000 on my Atari ST back in 1986
[02:53:20] <mru> well, compilers suck badly enough at compiling C code with all manner of hints
[02:53:29] <mru> that was a different world
[02:53:40] <hyc> my first few were hand-translated, but I got it automated pretty smoothly
[02:53:52] <mru> it's relatively easy to emulate x86 on 68k
[02:54:07] <mru> or translate for that matter
[02:54:09] <hyc> yes, that was a different world where self-modifying code was still pretty common
[02:54:21] <hyc> today mosst object code is a lot more well-behaved
[02:54:25] <mru> you have more registers, and the instruction set has a direct equivalent for most things
[02:54:32] * Kovensky points at the senseless copy protections everywhere
[02:54:49] <hyc> because CPU's have separate I$ and D$ and can't cope with writes to the instruction stream
[02:54:53] <mru> the biggest catch might be the separate data and addres registers
[02:55:19] <Kovensky> link not related: http://insomnia.ac/commentary/pc_game_piracy/
[02:55:19] <mru> hyc: it can be done, but you need to invalidate the I$ somehow
[02:55:32] * Kovensky sleeps
[02:55:39] <hyc> sure, but that is an obvious explicit instruction
[02:55:57] <hyc> you can bring all of this up to the bytecode level
[02:57:26] <hyc> it's not like the old days where you had to know the hardware memory map, because code was routinely peeking/poking dedicated I/O registers
[02:58:00] <hyc> user-level apps on an OS with VM and memory protection - they have no choice but to be well-bheaved
[02:58:06] <hyc> behaved
[02:58:22] <ohsix> behooved, betrothed
[03:01:10] <hyc> and you don't have to only do static analysis
[03:01:59] <hyc> you have a VM.... you can use an approach like valgrind and actually trace the execution path of the machine code, when turning it into the bytecode
[03:03:48] <peloverde> what about libraries?
[03:05:03] <hyc> what about them?
[03:07:22] <peloverde> well if you are retargeting some useful app from win/x86 to arm/linux you are going to have to suck in half of the win32 api
[03:07:50] <hyc> hasn't wine already done that?
[03:08:03] <hyc> so all you need is to retarget the wine librarys from x86 to arm
[03:08:20] <peloverde> wine has huge swaths of missing features
[03:08:34] <mru> usually the ones you need
[03:08:40] <peloverde> indeed
[03:08:43] <hyc> sure, but it also already has a large base of apps that work
[03:08:51] <hyc> or people wouldn't bother with it
[03:09:32] <hyc> regardless of whether wine is complete or not, it has > 0 functionality.
[03:09:45] <mru> I guess those people run entirely different apps than the ones I've tried
[03:09:47] <hyc> so if you absolutely wanted to get a win/x86 app to arm/linux
[03:10:12] <hyc> it would be better to start by converting wine to arm, than to start from scratch
[03:11:14] <peloverde> It might be better just to reimplement the app or reverse engineer the missing functionality than to retarget the binary
[03:11:15] <ohsix> sounds like a job for qemu
[03:11:39] <peloverde> or run it on an emulator
[03:11:41] <hyc> qemumight work, but it would always be the slowest
[03:12:03] <hyc> binary recompilation/translation would get you native execution speed
[03:12:12] <mru> that's what I doubt
[03:12:21] <hyc> and yes, just recompiling the app would be ideal.
[03:12:24] <peloverde> reverse engineering can get you even bigger improvements
[03:12:26] <ohsix> tcg, translating the whole thing still wouldn't get you the best you could get
[03:12:32] <peloverde> look at the codecs FFmpeg has reversed
[03:12:38] <hyc> but there may be some apps that you can't get the source code for any more, perhaps it's lost.
[03:13:07] <peloverde> hexrays
[03:13:56] <hyc> don't be silly. if youdon't think you can reliably convert machine code to usable bytecode, what makes you think you can fully decompile it all the way back to C source?
[03:14:03] <mru> hyc: didn't stop us implementing RVxx, VP[56], indeo, wma, etc
[03:14:21] <peloverde> Because the C code gets fixed up by a human being
[03:14:21] <mru> hyc: I don't think a machine can do that either
[03:14:26] <hyc> mru: sure, at significant labor cost.
[03:14:29] <ohsix> hexrays is just for rapid comprehension
[03:14:33] <mru> machines can't even compile C to asm
[03:15:01] <hyc> I think, you spend the labor on the machine code to bytecode framework, and then you don't have to sweat any more.
[03:15:52] <ohsix> the problem is universal representation and a form that covers its manipulation in a useful manne
[03:15:55] <ohsix> r
[03:16:06] <mru> I think reverse engineering everything is less effort than making such a thing work
[03:16:18] <peloverde> mru, agreed
[03:16:48] <hyc> ohsix: if you believe that's a problem, then you must also believe that LLVM and JVM are inherently failures
[03:17:03] <mru> jvm is a failure
[03:17:06] <ohsix> heh
[03:17:08] <mru> most people agree on that
[03:17:12] <hyc> can't disagree with that ;)
[03:17:53] <mru> the problem is that compiled code has less information than source code
[03:18:18] <mru> for instance, if you see a load instruction on x86, you can't know anything about its alignment
[03:18:18] <hyc> then you must also believe that gcc is inherently doomed, because it is a single frontend for multiple backends
[03:18:44] <mru> the gcc frontends parse code into a high-level language-neutral representation
[03:19:07] <ohsix> translation from a higher level to a lower level can freely discard semantics from the constraints of the higher level
[03:19:15] <hyc> how is high-level language-neutral rep in any way different from bytecode?
[03:19:25] <hyc> the old gcc used RTL
[03:19:31] <mru> gcc still uses rtl
[03:19:36] <hyc> there were no source-level semantics preserved in RTL
[03:19:48] <mru> things like alignment constraints are preserved
[03:20:42] <mru> I don't know llvm bytecode, but it could easily preserve more than any specific machine code
[03:21:07] <mru> like separating aligned and unaligned loads
[03:21:42] <Yuvi> yeah, it keeps alignment
[03:22:19] <mru> it could also include non-code annotations
[03:22:44] <hyc> so worst-case you get some performance hits because you have to turn some unaligned word-sized loads into byte ops
[03:22:58] <mru> that was just one example
[03:23:07] <hyc> yes
[03:23:19] <hyc> I'm sure there are other problems, and each of them can be solved
[03:23:50] <mru> that's what I don't think
[03:23:57] <peloverde> what would you do about unions where types can change size based on architecture and union punning is used?
[03:24:09] <ohsix> but theres no universal way to discover semantics from a bit of code, even when not in isolation
[03:24:15] <mru> not until I can have a crystal ball with pci interface
[03:24:31] <ohsix> takes people and inferences, theories being disproven to really hone in on it
[03:25:16] <hyc> peloverde: re: unions, type sizes - you use bytes.
[03:25:21] <ohsix> which is not an unreasonable way to resolve some of the stickier problems, but then you have an open set of solvers to run on something that still would miss things
[03:25:35] <hyc> how did people do less-than-64-bit ops on Alpha...
[03:25:48] <mru> load modify store
[03:25:58] <peloverde> but address sizes change
[03:25:58] <mru> sometimes with sparse mappings
[03:26:12] <mru> in the end, it all boils down to the halting problem
[03:26:20] <mru> and we know that's impossible to solve
[03:26:29] <peloverde> or would your 32-bit program still be limited to 4GB?
[03:27:03] <hyc> sure, that would be OK as a first effort
[03:27:18] <hyc> and not an issue for this example, x86 to arm
[03:28:00] <mru> a lot of apps nowadays are for x86_64
[03:28:02] <hyc> "impossible to solve" == no algorithm. but heuristics are ok.
[03:28:09] <hyc> not on windows
[03:28:37] <mru> look, after a decade of work, wine is still nowhere near ready
[03:28:39] <hyc> you don't need a mathematical proof that it will be 100% correct
[03:28:46] <mru> and that's emulating windows on its native platform
[03:28:51] <hyc> you only need it to come close
[03:28:57] <hyc> and wine is a poor example
[03:29:03] <mru> emulating windows on _another_ architecture isn't going to be easy
[03:29:17] <ohsix> who will be bodging over the failures though; you cant run every program ever and you eventually want someone to use it, no?
[03:29:25] <hyc> I used to work at Locus Computing, andwe had PC-Merge back then running full Windows concurrent with Unix
[03:29:50] <hyc> wine's lack of progress is no indication of the scope of the task. it's been done before, well.
[03:30:08] <mru> one problem is that the scope is growing
[03:30:24] <mru> 15 years ago win32 was much simpler
[03:30:41] <mru> and apps were simpler too
[03:31:38] <hyc> I suppose
[03:32:33] <ohsix> every new release of windows ends up with new coverage and facilities over bits something like wine still has to maintain; but never got very far with in the first place
[03:34:11] <hyc> and if you had machine-level translation, all of that maiintenance/verification would go a lot faster
[03:34:38] <hyc> CPus are faster, mmemory sizes are larger, overall system complexit increases. fine.
[03:35:01] <hyc> that justmakes it all the more clear that you should be using machine resources for these jobs, not brainpower
[03:35:58] <hyc> the scope of the problem is not unbounded. it is completely contained in a PC. it is completely contained in a Vmware or virtualbox instance.
[03:36:57] <ohsix> they just do a decent job bodging over the unvirtualizable bits and the rest is mostly orthogonal
[03:37:39] <peloverde> VMWare solves a simpler problem slower
[03:37:52] <hyc> the point remains - the problem is probably beyond the scope that any human programmer wants to address directly
[03:38:09] <hyc> but it is not beyond the scope of a too
[03:38:10] <hyc> tool
[03:38:13] <mru> and the problem of automating it well is probably bigger
[03:38:33] <peloverde> but people right here solve that problem all the time voluntarily
[03:39:13] <peloverde> (not the problem of automating it, the problem of translating it)
[03:39:41] <ohsix> automation would be for the bodges and stuff where it just falls flat
[03:39:46] <hyc> yes, but as you pointed out, translating for wine is still incomplete. and yet complete PC virtual environments are commonplace.
[03:40:16] <mru> hardware virtualisation is "trivial"
[03:40:29] <ohsix> ^
[03:40:32] <hyc> or qemu, emulating the complete system on a foreign architecture
[03:40:34] <mru> certainly on modern hardware
[03:40:39] <mru> and on old big iron
[03:41:02] <hyc> qemu works, but it's too slow
[03:41:04] <ohsix> raw x86 only has a few problematic and old instructions that you just need to scan for
[03:41:21] <mru> hw virt isn't conceptually quite similar to multi-processing with virtual memory
[03:41:27] <mru> you just have one more level
[03:42:07] <hyc> hw virt isn't what I'm talking about... full system emulation.
[03:42:11] <mru> qemu translates one basic block at a time to native machine code and caches them
[03:42:16] <hyc> like running virtualPC on 68K or sparc
[03:42:35] <mru> that's also a trivial task
[03:42:56] <mru> trivial to do correctly, hard to do fast
[03:43:13] <mru> which is why we compile to native machine code when possible
[03:43:16] <hyc> and?? you don't think you can analyze an arbitrary piece of machine code, one basic nlock at a time?
[03:43:22] <hyc> block
[03:43:45] <mru> and expect to recover all the information available at source level, no
[03:43:52] <hyc> nobody cares about that
[03:43:55] <mru> I do
[03:44:06] <hyc> you just need to turn it into an executable stream for the current machine
[03:44:08] <mru> and I suspect most of the others here too
[03:44:16] <mru> it'll be a slow one
[03:45:03] <hyc> there's no reason for that.
[03:45:19] <mru> yes there is, and I just told you what it is
[03:45:22] <hyc> you can do all the usual data flow analysis of a good compiler/optimizer
[03:45:25] <mru> no
[03:45:32] <mru> you're missing essential information
[03:45:40] <mru> such as source-level types
[03:46:08] <hyc> types are for humans. computers don't care.
[03:46:12] <mru> oh yes they do
[03:46:15] <ohsix> wat you do is turn them all into loops and do mathematical transformations on them!11
[03:46:37] <mru> what did you think all the strict aliasing was about?
[03:46:42] <mru> and pointer alignment
[03:46:57] <mru> and const declarations
[03:47:03] <hyc> strict aliasing == nonsense. couldn't stand that crap.
[03:47:12] <mru> that's your personal opinion
[03:47:20] <mru> don't let that get in the way of facts
[03:47:21] <hyc> const - is embedded in the binary already
[03:47:35] <hyc> because consts will be in a different segment from writable data
[03:48:15] <mru> void foo(const int *x) { do stuff with x; }
[03:48:17] <hyc> pointer alignment - is embodied in the instructions that operate on a pointer
[03:48:24] <mru> not on x86 and ppc
[03:48:48] <mru> in a function like above, when compiled there's no way of knowing the pointer target is const
[03:48:59] <hyc> nor is there any need to know
[03:49:07] <mru> might be
[03:49:18] <hyc> the object code will either atteempt to write thru it or not.
[03:49:32] <hyc> if the compiler did its job correctly, the object code will be consistent
[03:49:53] <mru> well, what are you waiting for?
[03:50:07] <mru> write that perfect decompiler, translator, or whatever you want to call it
[03:50:19] <mru> do what nobody has managed to do for 40 years of computing
[03:50:28] <mru> or however long they've been trying
[03:50:35] <hyc> how many have actually tried?
[03:50:52] <hyc> it's been mostly ignored
[03:50:55] <mru> only a bunch of phd studends per year per university
[03:51:26] <hyc> oh well, that's their problem
[03:51:35] <mru> you're not making a lot of sense
[03:51:49] <mru> either you do it, or you shut up
[03:52:03] <hyc> I already did an x86 to 68k translator
[03:52:10] <hyc> it's on the Atari software archives
[03:52:18] <mru> oooooh, impressive
[03:52:38] <mru> and how good was it?
[03:52:52] <mru> as I said, doing it at all isn't the hard part
[03:53:03] <mru> it's doing it well that's close to impossible
[03:53:13] <hyc> it worked for the apps I was interested in. MS Word 1.something, fractint
[03:53:28] <mru> now you're talking about correctness
[03:53:34] <mru> how fast was the result?
[03:53:35] <hyc> you have to start somewhere
[03:53:57] <mru> dammit, do you know how much people pay me to convert C code into assembler?
[03:54:16] <hyc> nope. why should that concern me?
[03:54:30] <hyc> you know how many years I worked on gcc for free?
[03:54:38] <hyc> 68K and i860
[03:54:53] <peloverde> because converting assembler to assembler is significantly more difficult
[03:55:26] <mru> one week of my money would buy a very good compiler
[03:55:35] <mru> but they still think I'm worth it
[03:55:48] <hyc> I also routinely ported assembly code between my 68K at home and the IBM 370 mainframe at the computing center
[03:56:07] <hyc> you make it sound like it's impossible. it's not.
[03:56:27] <mru> it's impossible to recover lost information
[03:56:36] <hyc> true
[03:56:38] <mru> and the process of compiling source code loses information
[03:56:49] <hyc> but the lost information isn't always necessary
[03:57:02] <mru> maybe not all of it
[03:57:09] <mru> but enough of it is
[03:57:30] <mru> another example: volatile
[03:57:51] <mru> you can't tell from the asm whether something was declared volatile or the compiler just had to spill a register
[03:58:15] <ohsix> or it really likes reading the contents of something
[03:58:20] <hyc> lol
[03:58:26] <mru> yeah, or it simply sucks
[03:58:42] <mru> gcc does that a lot
[03:58:45] <ohsix> yea, cant rule that out either
[03:58:49] <mru> if you worked on it you should know
[03:58:58] <hyc> true. but the latter case (reading the contents of something) is pretty rare. e.g. hardware register accesses
[03:59:10] <mru> but you can't know for sure
[03:59:11] <ohsix> needless loads in some of the passes cant be removed simply because the semantics have already been discarded, so it has to leave the loads in
[03:59:29] <hyc> right
[04:00:01] <mru> so moving from a register-starved machine to one with more registers, you'll probably be forced to do some redundant memory accesses
[04:00:02] <hyc> but that's ok. your aim is to duplicate the behavior of the original code.
[04:00:13] <peloverde> that still seems faster than emulating, presumably this is a somewhat lossy process speedwise, just less lossy than emulation
[04:00:17] <mru> and if the source allows unaligned accesses, but not the target, well...
[04:00:26] <ohsix> but faster enough than emulation to warrant the exercise
[04:00:44] <mru> I never considered emulation as an alternative
[04:00:59] <hyc> no, emulation kinda sucks.
[04:01:05] <peloverde> emulation is the next best alternative is it not?
[04:01:08] <hyc> but a lot of people use it if they have no better choice
[04:01:08] <ohsix> drc can be pretty fast
[04:01:18] <hyc> I think this is a better choice than emulation.
[04:01:33] <mru> when is recompiling from source not an option?
[04:01:40] <peloverde> yes
[04:01:57] <peloverde> if recompiling from source were an option you'd just do that
[04:02:02] <hyc> well in my case, I didn't have the source code to MSWord 1.0
[04:02:17] <mru> that's atypical
[04:02:35] <ohsix> probably not a lot of volatile or type punning going on there either
[04:03:09] <mru> and good luck doing anything sensible with simd
[04:03:37] <mru> for example, sse and neon implementations often look very different
[04:04:08] <peloverde> presumably generating scalar code or shittier simd on the target is an option
[04:04:18] <peloverde> because it is till faster than emulation
[04:04:26] <mru> you'd have to decompose the instructions into scalar operations, reconstruct the high-level loops, transform those into something efficient for the target insn set, and then compile them
[04:04:36] <mru> modern compilers suck horribly at the easy parts there
[04:04:39] <ohsix> basically all you're left with for semantics is the actual instructions you'd want to transform, and if you mess with those you have a malfunctioning program
[04:05:13] <mru> your flaw is comparing to emulation
[04:05:27] <peloverde> what is you next best alternative then?
[04:05:29] <mru> you should be comparing to the best feasible option, not the worst
[04:05:43] <hyc> the best feasible option is recompiling the source
[04:05:44] <ohsix> broken in untestable or verifiable ways
[04:06:00] <hyc> but you wouldn't even be looking down this path if that were an option
[04:06:07] <peloverde> if you had the source why would you compile to x86 then retarget to ARM?
[04:06:11] <mru> but it is almost always an option
[04:06:16] <hyc> and in my case, that wasn't an option
[04:06:32] <mru> guess what, it's not 1983 anymore
[04:06:33] <hyc> and you'll find a lot of enterprises with legacy apps that never had source code available
[04:06:39] <hyc> sold by vendors who are long out of business
[04:06:46] <mru> they keep the old hardware available too
[04:07:01] <hyc> for as long as they can, sure
[04:07:01] <ohsix> msword 1.0 is probably fully comprehendable from the byte code :O
[04:07:09] <peloverde> if it's legacy emulation should be fast enough
[04:07:17] <mru> that too
[04:07:21] <hyc> but old hardware has stiff maintenance costs, and probably is nowhere near power efficient
[04:07:36] <mru> some companies are willing to pay for it
[04:07:52] <mru> some old vax parts can fetch a good price
[04:08:36] <hyc> peloverde: why settle for "good enough", particularly when emulation will consume far more CPU resources than otherwise
[04:08:54] <mru> emulation is much less error-prone
[04:09:04] <mru> presumably these legacy apps are very important
[04:09:07] <peloverde> because good enough is availible right now
[04:09:08] <hyc> just because I buy a new machine whose CPU can emulate the legacy system at 2x speed, why would I, if it means running 100% utilization
[04:09:12] <mru> you won't want them to malfunction
[04:09:49] <hyc> I'd rather be running at 10x speed and 1% CPU utilization...
[04:10:12] <peloverde> If your MS-DOS business app from 1983 ran fine on a 286 it will work plenty fin on an emulator on an i7
[04:10:35] <hyc> and as you guys have pointed out, probably those legacy apps don't have any complexities to be translated
[04:10:39] <mru> or anything else built in the last 10 years
[04:11:02] <mru> you're building a spaceship to drive around the block in
[04:11:06] <mru> there's just no point
[04:11:16] <peloverde> and you don't have to hire a single person to write this elaborate system
[04:12:04] <hyc> mru: I'm surprised to hear you say that. you seem to spend hours to shave 10% off a codec's runtime.
[04:12:22] <ohsix> that's nothing like the same thing
[04:12:23] <peloverde> "spaceship to drive around the block" perfect metaphor
[04:12:43] <ohsix> and those changes have multiple consumers and for the scope of the project do much more than that 10%
[04:13:14] <mru> hyc: and you're willing to spend months or years to _add_ 10% to the runtime
[04:14:22] <hyc> I believe the end result will be a net-win in time saved.
[04:14:46] <mru> I don't
[04:15:07] <ohsix> it would have limited motility too
[04:15:29] <peloverde> I think if it were a net win, you'd see it being done just like emulators and visualization
[04:15:44] <mru> s/vis/virt/ ?
[04:15:53] <peloverde> yes
[04:16:12] <mru> actually, machine translators have been made
[04:16:18] <mru> there was fx32 for alpha
[04:16:24] <peloverde> apparently my spellcheck doesn't like "virtualization"
[04:16:26] <mru> translated x86 code to alpha
[04:16:31] <hyc> yes, which ran faster than real x86
[04:16:46] <mru> on hardware that was twice as fast to begin with
[04:17:03] <mru> and again, translating from x86 to alpha is fairly easy
[04:17:10] <mru> alpha has 32 registers
[04:17:11] <hyc> still, it was better than emulation
[04:17:23] <mru> you can just reserve 8 of those for the translated ones
[04:18:04] <peloverde> It only worked for a very small niche
[04:18:18] <ohsix> and when it didn't work, it was transparent to the user
[04:19:04] <peloverde> The programs had to run on the same, specific, OS it had one source architecture and one target architecture and the target architecture had more registers
[04:19:42] <peloverde> And despite it's existence NT on alpha was a flop
[04:19:55] <hyc> well, x86 to *anything* will probably have more registers available
[04:24:22] <peloverde> It wouldn't surprise me if something pops up to go from Windows on x86 to Windows on ARM or Mac OS X on x86 to OS X on ARM, but I wouldn't want to run Windows or OS X as a target OS
[04:24:38] <mru> windows on arm, lol
[04:24:54] <mru> that is so going to die
[04:25:58] <hyc> full windows, or winmo7?
[04:26:22] <mru> there has never been a full windows for arm
[04:26:25] <peloverde> i'm sure full windows on ARM exists somewhere inside MS
[04:26:57] <ohsix> eh @ that
[04:27:34] <mru> winmo is totally lagging behind hw development
[04:27:36] <hyc> kinda wonder. does M$ have any reason to stay on x86?
[04:27:40] <mru> and I don't see many new devices coming out
[04:27:55] <mru> windows is probably a bitch to port
[04:28:02] <peloverde> the main reason to use windows is the huge binary only software library
[04:28:16] <hyc> yes, which comes back to ... translation ...
[04:28:23] <mru> nobody uses windows for the features alone
[04:28:25] <hyc> they've already ported windows to MIPS and itanium
[04:28:39] <mru> but we don't know how much effort that was
[04:28:48] <mru> nor how well it worked
[04:28:59] <mru> nor if those ports are still up to date
[04:29:07] <peloverde> It's *supposedly* trivial
[04:29:17] <hyc> hm, there are windows server deployments on itanium, so some folks must think it works ok
[04:29:18] <peloverde> Isn't Windows on Itanium still supported
[04:29:45] <hyc> it's been end-of-life'd
[04:29:48] <mru> itanium isn't supported for much longer
[04:29:50] <mru> if at all
[04:29:53] <mru> by intel
[04:30:15] <mru> the original one
[04:30:28] <peloverde> Windows Server 2008 R2 stil supports itanium
[04:30:41] <peloverde> that is their newest server OS
[04:31:39] <ohsix> porting isn't 0 effort, its not hard since NT's inception; its just pretty useless
[04:31:43] <hyc> yes. pretty sure that is the final update
[04:32:39] <peloverde> anyway the problem with a windows port is most software is binary only
[04:33:09] <peloverde> so it's only really used when their is also a paradigm shift like embedded or game console
[04:33:12] <hyc> http://blogs.technet.com/windowsserver/archive/2010/04/02/windows-server-2008-r2-to-phase-out-itanium.aspx
[04:34:43] <hyc> so anyway, no, I wouldn't invest any time in a binary translator for x86 to itanium...
[04:35:08] <hyc> nor x86 to sparc
[04:37:29] <peloverde> I wouldn't invest any time in either of those either
[04:38:34] <peloverde> but i'd go further and say I wouldn't bother investing an time in any binary translator because the binary-only programs I care about don't run well in wine
[04:39:20] <hyc> that sounded like a non-sequitur
[04:39:38] <hyc> but what apps do you care about?
[04:40:46] <peloverde> MS Word, Excel, to a lesser extent MATLAB
[04:40:51] <hyc> I have to admit, it's been a long time since I've needed a particular windows app
[04:41:01] <mru> matlab?
[04:41:06] <mru> that has linux builds
[04:41:27] <peloverde> I said binary only not windows only
[04:41:41] <superdump> morning
[04:41:44] <mru> you mentioned wine
[04:42:04] <hyc> yeah, that was the non-sequitur part
[04:43:15] <peloverde> everything I use in linux except for a driver and a browser plugin I have source code for
[04:43:16] <ohsix> theres some irony in bringing up itanium wjen you're talking about retargeting x86 code
[04:43:50] <mru> doesn't it have hw emulator?
[04:45:09] <ohsix> peloverde: which driver?
[04:45:16] <peloverde> nvidia
[04:45:32] <ohsix> ah, drag
[04:46:18] <superdump> mru: you've been called a moron on slashdot
[04:46:25] <peloverde> so I would rather have llvm be a good c/c++ compiler because most of the code I run is compiled c/c++
[04:46:36] <mru> superdump: I've been called a lot of things lately
[04:46:48] <superdump> http://rss.slashdot.org/~r/Slashdot/slashdot/~3/UsKme8j8QdI/Ogg-Format-Accusations-Refuted
[04:47:38] <peloverde> it seemed to not be a refutation as much as a list of nitpicks and minor corrections disguised as a rebuttal
[04:47:59] <verb3k> Where can I find gsoc projects accepted for 2010? The gsoc website doesn't list the projects in the org page
[04:49:15] <peloverde> the response it got on proggit surprised me considering proggit seems to have microsoft's cock in it's collective mouth
[04:53:03] <peloverde> slashdot doesn't seem to be drinking the coolaid for the most part in the comments
[04:53:57] <mru> I only saw a few sensible comments there, and they were all marked troll
[04:54:26] <peloverde> As per slashdot the top comment is a joke
[04:54:44] <peloverde> The next one is anti-ogg
[04:54:48] <mru> I don't mind jokes
[04:55:16] <mru> ranking has changed since I looked a few hours ago
[04:55:49] <peloverde> The third one is pro-ogg, 4 and 5 are anti
[04:56:07] <peloverde> blol 6 thinks you are an mpeg astotrufer
[04:56:16] <Dark_Shikari> lol
[04:56:30] <mru> yeah, that was funny
[04:56:53] <mru> I don't understand why monty keeps going on about nut though
[04:56:58] <mru> I didn't mention it even once
[04:57:16] <peloverde> because ogg is indefensible
[04:57:23] <peloverde> the best he can do is tear down a straw man
[04:58:16] <peloverde> sigh, why do i never have slashdot modpoints when I need them
[05:00:07] <peloverde> oh well at least I get to tag some new foes
[05:08:38] <peloverde> brand new foes: bit01 (644603), Jesus_666 (702802), DaMattster (977781), kiwieater (1799016)
[05:11:51] <peloverde> mostly for missing the point completely (talking about how great vorbis is, how good enough theora is) or astroturfing allegations
[05:14:18] <peloverde> The number of people that have an opinion on this matter but wind up talking about vorbis or theora in a non-container-interface capacity is mind boggling
[05:14:51] <peloverde> It's like they don't bother to read anything but their religion compels them to weigh in anyway
[05:15:40] <ohsix> for real
[06:26:45] <av500> "...An index is only marginally useful in Ogg for the complexity added; it adds no new functionality and seldom improves performance noticeably. Why add extra complexity if it gets you nothing? ..."
[06:26:47] <av500> wtf?
[07:39:05] <KotH> bon giorno
[07:43:05] <pengvado> first version of CABGT done
[07:43:20] <Dark_Shikari> how does it perform?
[07:43:26] <pengvado> it works, it compresses within 0.3% of CABRC, and in unit test it's 1.4x faster to decode
[07:43:35] <pengvado> but when plugged into actual FFV1, it's slower
[07:44:21] <pengvado> I suppose it could be cache misses from all those huffman tables...
[07:45:31] <Dark_Shikari> use smaller tables?
[07:45:34] <Dark_Shikari> how large do the tables end up?
[07:45:48] <Dark_Shikari> that actually sounds like a serious practical problem with CABGT.
[07:46:03] <Dark_Shikari> even if it saves a dozen clocks, that's one miss...
[07:51:04] <benoit-> hi
[07:52:32] <pengvado> total of 119 symbols in 8 huffman trees. which expands to 2048 LUT entries after flattening.
[07:52:35] <pengvado> which could be 119*2+2048 bytes with a custom implementation, but is 2048*4 bytes with the standard get_vlc().
[07:52:49] <Dark_Shikari> hmm.  that shouldn't be enough to cause massive increases in cache misses
[07:56:56] <pengvado> http://akuvian.org/src/x264/cabgt.0.diff
[07:57:21] <pengvado> (patch made from my ffv2 tree, so there might be some conflicts with mainline, but should be simple enough)
[08:00:33] <Dark_Shikari> what's with the lfg random stuff?
[08:00:46] <Dark_Shikari> also, er, wouldn't branch mispredictions be more of a worry than cache misses?
[08:02:45] <Dark_Shikari> what's with bitswap_32?
[08:02:54] <Dark_Shikari> oh.  an actual bit swap
[08:07:57] <pengvado> lfg random stuff is the unit test
[08:09:37] <pengvado> you mean the branch around get_vlc2?
[08:09:48] <pengvado> how is that different from the branch around refill in cabrc?
[08:10:35] <pengvado> btw, there's several useless instructions in gcc's output, but I can't find any C that eliminates them, and I'm not ready for asm
[08:10:53] <Dark_Shikari> well you should do some actual benching of cache misses/etc
[08:10:56] <Dark_Shikari> to check that your theory is correct
[08:51:42] <pengvado> cachegrind says
[08:51:42] <pengvado> CABRC: instructions executed: 55,574,444,565. D refs: 20,276,925,172. L1D misses: 74,439,371. L2 misses: 18,129,485.
[08:51:46] <pengvado> CABGT: instructions executed: 66,501,922,459. D refs: 18,054,494,330. L1D misses: 112,887,770. L2 misses: 18,380,171.
[08:52:09] <ohsix> <3
[10:02:11] <lu_zero> yawn
[10:02:13] <lu_zero> good morning
[10:02:33] <kshishkov> it's good day but good morning to you
[10:02:43] <lu_zero> =)
[10:29:48] <Yuvi> Does mpeg-ts have patents?
[10:30:21] <pross-au> That is an intractable question
[10:30:42] <Yuvi> Does it have known patents?
[10:34:16] <Yuvi> Guess so given a search...
[10:35:23] <av500> hmm: Both the DAB royalty to Philips and the AAC royalty to Via Licensing apply to DMB. In addition there is licence fee applicable for MPEG Transport Stream (TS) used in DMB.
[10:35:32] <av500> The $0.50 per-unit licence fee for the MPEG TS is payable to MPEG LA.
[11:33:14] <BastyCDGS> a wonderful day to all...
[11:33:19] <kshishkov> ok
[11:33:46] <KotH> BastyCDGS: especially to kshishkov, isnt it? ;)
[11:34:02] <BastyCDGS> oh what's with you, kishkov?
[11:34:15] <kshishkov> KotH: you know, days are quite better here near Rhine
[11:34:24] <BastyCDGS> and also a wonderful day to IFF decoder, I just fixed the bug that some IFF files decode wrong ;)
[11:34:27] <KotH> kshishkov: hmm? rhine?
[11:34:31] <KotH> kshishkov: did you move to germany?
[11:34:35] <kshishkov> KotH: yes
[11:34:43] <BastyCDGS> oh where in germany?
[11:34:44] <elenril> permanently?
[11:34:50] <kshishkov> hopefully
[11:34:54] <elenril> \o/
[11:34:54] <KotH> \o/
[11:34:58] <elenril> lol
[11:35:00] <kshishkov> BastyCDGS: Karlsruhe
[11:35:10] <BastyCDGS> ahh nice
[11:35:19] <KotH> oh.. that isnt that far
[11:35:25] <BastyCDGS> that's pretty close where my family lives (Freiburg)
[11:36:41] <iive> kshishkov: congratulations.
[11:38:52] <BastyCDGS> YEAH! With new patch ALL remaining IFF decoding errors are resolved, just tried on all samples which decoded wrong before
[11:38:55] <BastyCDGS> except HAM/EHB ;)
[11:39:24] <kshishkov> you'd better test _all_ files anyway
[11:39:36] * elenril thinks gluing fortran and c code together with python is fun
[11:39:42] <BastyCDGS> I now create the heavy opt patches based on this
[11:39:51] <BastyCDGS> and them I commit HAM ;)
[11:39:57] <BastyCDGS> s/commit/submit
[11:40:48] <mru> why would you need python for that?
[11:41:00] <mru> fortran and c can be compiled and linked directly
[11:41:16] <elenril> most of the code is python, it's easier that way
[11:41:26] <elenril> only the ode solver is fortran
[11:41:43] <elenril> and the ode system is in c
[11:43:41] <merbzt> kshishkov: \o/
[12:11:40] <benoit-> kshishkov: congrats !
[12:20:41] <wbs> siretart: hey, regarding ffmpeg packaging for debian/ubuntu, what about packaging qt-faststart as a separate package?
[12:24:44] <BastyCDGS> submitted heavy opt patch for dp8 based on IFF line rounding up to next word boundary to ml
[12:26:19] <siretart> wbs: err, technically, this would be possible, but I don't really understand the merit for this.
[12:26:53] <kshishkov> siretart: for really clueless users who don't associate it with FFmpeg, I presume
[12:27:19] <wbs> siretart: in some cases, I bring my own libav* in my own app, but may want to simply apt-get in qt-faststart (without having a system-wide installed libav*)
[12:27:21] <kshishkov> also it does not have any external dependencies
[12:27:37] <merbzt> BastyCDGS: so just a 70%  improvement :)
[12:27:55] <BastyCDGS> 70%??
[12:27:59] <BastyCDGS> it's almost 400%
[12:28:04] <siretart> wbs: a single utility binary package feel really too much overhead to me. perhaps we can include it in some other package?
[12:28:18] <merbzt> er 30% of the previous time
[12:28:23] <merbzt> good work
[12:28:52] <BastyCDGS> 53429 vs 14492
[12:28:53] <BastyCDGS> ;)
[12:28:58] <BastyCDGS> I used a larger file this time
[12:28:59] <wbs> siretart: hmm, what other packages are built from the source package, libav* and the main ffmpeg package?
[12:29:47] <siretart> wbs: http://packages.debian.org/sid/source/ffmpeg
[12:30:16] <merbzt> BastyCDGS: did you update the Roundup tickets ? if the bugfix took care of them
[12:30:51] <wbs> hmm, ok.. so if a separate package is too much overhead, I guess I can live with the current packaging
[12:31:29] <siretart> wbs: there is an open request to seperate out ffplay to a package of it's own already, which I'm currently considering
[12:31:39] <wbs> hmm, ok
[12:31:51] <siretart> but I guess this wouldn't help you here very much
[12:32:04] <wbs> the point in this case, from my part, is that qt-faststart wouldn't have any other deps than libc, more or less
[12:32:09] <siretart> wbs: what's your usecase for not wanting to install any system libavcodec package?
[12:32:58] <wbs> siretart: a custom app with a built-in static copy of lav* (pinned to the version I've tested it with), but i'd like to run qt-faststart using system() or something like that
[12:33:52] <siretart> wbs: okay, but what's the problem with installing debian's libavcodec package?
[12:34:09] <siretart> if you link statically, the system lib will be ignored
[12:34:26] <BastyCDGS> merbzt, is it okay, when I do this when the patch has been commited to git?
[12:34:48] <wbs> siretart: there's no concrete problem in doing that, it just feels unnecessary since qt-faststart doesn't need any of it
[12:35:55] <siretart> wbs: well, let me put it this way: I certainly won't introduce new binary package if that doesn't solve any problems
[12:36:31] <wbs> ok, then consider the feature request dropped :-)
[12:36:35] <siretart> as for ffplay, seperating it out would allow users to avoid the SDL dependencies
[12:36:50] <siretart> which can be considered as a problem in some cases
[12:37:12] <mru> sdl is a problem, I'll agree to that
[12:37:38] <siretart> ah, we've found a volunteer to port ffplay to libvo :-)
[12:37:46] * mru prefers poking the hardware directly :-)
[12:38:09] <av500>  /dev/dsp and /dev/fb should be all you need
[12:38:19] <av500> or /dev/mem actually
[12:38:32] <kshishkov> mru: blame crappy X11 protocol implementations
[12:38:44] <KotH> siretart: which libvo?
[12:38:44] <mru> kshishkov: x11 is not to blame for sdl
[12:38:55] <twnqx> av500: how would you get the interrupts back :X
[12:39:08] <KotH> siretart: "the" libvo, mplayers libvo, xines libvo or vlcs libvo?
[12:39:13] <kshishkov> KotH: our own libavoutput
[12:39:22] <KotH> ah.. libavo
[12:39:33] <mru> isn't that lavd?
[12:39:34] <siretart> KotH: at the implementor's choice :-)
[12:39:37] <KotH> .o0(wonders when a libova will be made)
[12:39:43] <av500> twnqx: I dont want your interrupt back, you can keep it
[12:39:48] <siretart> libass is a nice one
[12:39:58] <kshishkov> KotH: ask that at #mplayerdev, they should know
[12:40:29] <KotH> kshishkov: mplayers libvo is based on "the" libvo... or vice versa.. nobody knows anymore
[12:40:44] <KotH> kshishkov: xine and vlc build their own
[12:41:28] <KotH> siretart: only if it's a nice ass ;-)
[12:41:30] <kshishkov> KotH: I meant your "libova" question, I know a bit about libmpeg2 vo
[12:43:00] <merbzt> BastyCDGS: you can add a comment that a patch fixing this bug is posted on the mailinglist
[12:43:36] <BastyCDGS> isn't that what I wrote already regarding this patch, enough?
[12:44:36] <mru> http://blog.axant.it/archives/278
[12:44:51] <mru> whos blog is that?
[12:45:16] <merbzt> BastyCDGS: you did ? then there is no need to do anythjing until the fix is committed
[12:45:37] <BastyCDGS> that's what I wrote:
[12:45:42] <BastyCDGS> I have fixed the wrong IFF decoding issue in the IFF decoder.
[12:45:42] <BastyCDGS> The reason is that the IFF docs say that each line in the BODY chunk has
[12:45:42] <BastyCDGS> it's width rounded up to next 16-bit boundary, such that each new line
[12:45:42] <BastyCDGS> begins on a word boundary (address divisible by 2).
[12:45:42] <BastyCDGS> Please review and apply.
[12:45:43] <BastyCDGS> I will do the heavy optimization stuff now based on this.
[12:46:18] <av500> mru: Barbato Luca
[12:46:29] <av500> http://www.axant.it/legalinfo?lang=it
[12:46:56] <mru> lu_zero: thanks
[12:47:39] <av500> actually, the mention of feng should have given it away, no? :)
[12:48:11] <mru> yeah, I guess
[12:54:37] <ohsix> heh, that reads as "i dislike ogg and didn't read what was posted"
[12:56:03] <av500> ohsix: not reading is a prerequisite for all succesful internet discussion :)
[12:56:11] <ohsix> :]
[12:56:33] <ohsix> doesn't have much weight though; and we know the internet is of finite size
[13:03:14] <KotH> av500: "successful" is a very strong precondition ;)
[13:06:11] <ohsix> trench warfare doesn't gain you any territory
[13:09:07] <BastyCDGS> mru, I just tried your idea with decodeplane32
[13:09:21] <BastyCDGS> is twice as slow than my original heavy opt of dp32
[13:09:29] <mru> I don't believe you
[13:09:37] <mru> I don't think your lying
[13:09:43] <mru> but I think you made a mistake somewhere
[13:09:56] <BastyCDGS> that's what I'm just figuring out right now
[13:10:25] <BastyCDGS> I started with a table on stack pointing to the 4 masks
[13:13:53] <BastyCDGS> declaring const uint32_t lut[4][16]; and memcpy from static table gives original speedup
[13:14:56] <mru> don't memcpy
[13:14:59] <mru> never, ever memcpy
[13:15:06] <mru> what good could that possibly do
[13:15:10] <BastyCDGS> yes I know was just as test ;)
[13:15:18] <BastyCDGS> s/as/a
[13:18:23] <BastyCDGS> hey BBB ;)
[13:23:37] <BastyCDGS> mru, I dunno why, but the original method or memcpy is twice as fast than anything else I tried...
[13:23:55] <BastyCDGS> should I submit a patch with current state and let someone look on it?
[13:24:35] <BBB___> mornin'
[13:24:59] <BBB___> I'd stop messing around with performance after your table-patch
[13:25:01] <BBB___> work on iff/anim
[13:25:07] <BastyCDGS> morning? it's 15:24 (GMT+02) here ;)
[13:25:10] <BBB___> that was and is the qualification task :)
[13:25:14] <BBB___> it's 9:25 here :)
[13:25:24] <mru> BastyCDGS: if adding a memcpy makes it look faster you're doing something wrong
[13:25:53] <jai> i second BBB :)
[13:26:09] <BBB> the table patch is good and makes a huge difference
[13:26:13] <BBB> that's good
[13:26:29] <BastyCDGS> BBB, I dunno if you already realized but I fixed the bug displaying some IFF's wrong ;)
[13:26:36] <jai> also if you _really_ want to optimize stuff/write asm, the h264 or vc1 decoders are much more useful targets
[13:26:40] <BBB> I just reviewed that :)
[13:28:24] <BastyCDGS> oh thanks, I just wrote * 2 because I'm afraid that mru then again complains about readability ;)
[13:28:30] <av500> BastyCDGS: irc is on UGT timezone...
[13:29:40] <BastyCDGS> BBB, the & 1 rounding will probably be slower (creates a larger instruction) than shl eax,1
[13:30:32] <mru> instruction prefetch on modern cpus is large enough the size of an single instruction rarely matters
[13:34:35] <hyc> ? most Intels fetch 16 bytes at a time, new AMDs 32 bytes at a time
[13:34:49] <BastyCDGS> mru, you're right, with & it shifts one bit less to right which is faster on some CPUs anyway
[13:34:59] <BastyCDGS> so I will use the &~1 rounding ;)
[13:35:07] <hyc> and the AMD optimization guide syas to avoid more than 2-3 branches per 16 bytes
[13:35:25] <hyc> so instruction size/placement does need to be taken into consideration
[13:35:59] <mru> hyc: 16 bytes is enough to hold several of the larger instructions
[13:36:37] <mru> instruction size is only a problem if decode stalls waiting for fetch
[13:36:47] <mru> or if the code size increases so much that you get I-cache misses
[13:37:04] <mru> adding a byte to one instruction won't be noticed
[13:37:12] <kshishkov> or it's German Instruction Word CPU
[13:37:14] <BastyCDGS> well this code is called anyway only once (it's in decode_init), so that shouldn't be a problem ;)
[13:37:45] <mru> init code is totally irrelevant
[13:37:59] <hyc> typically true, yeah
[13:38:19] <BastyCDGS> well unless I don't bloat it up from 16 bytes to 1 MB ;)
[13:38:22] <hyc> (unless you're talking about libgcrypt, which does a full "self-test" when you initialize it. sigh.)
[13:42:40] <hyc> this code reminds me of M68K, it was faster to add a number to itself than to do a 1 bit shift
[13:43:06] <hyc> Then they added a barrel shifter in 68020 and idt didn't matter any more
[13:45:13] <mru> and then there's the ARM
[13:45:19] <mru> free shift with every instruction
[13:45:24] <mru> (almost)
[13:46:53] <BastyCDGS> hyc, on yes on m68k add.l dx,dx was 2 cycles faster than lsl.l #1,dx
[13:47:08] <hyc> yep
[13:47:16] <av500> can we try to make ffmpeg faster on existing cpus :)
[13:47:29] <mru> and future ones
[13:47:44] <hyc> sorry, I still fire up my 68030 Atari TT every once in a while to compile my code
[13:47:48] <hyc> ;)
[13:48:00] <kshishkov> FFmpeg?
[13:48:06] <hyc> and apparently some Amiga folks are doing the same. rtmpdump
[13:49:42] <hyc> If you guys need some nice and fast 68020 dsputil let me know, I've still got my fft libraries around here somewhere
[13:50:07] <mru> they probably use a slow base algorithm
[13:50:20] <mru> since the one we use in ffmpeg wasn't known when that code was likely written
[13:50:50] <hyc> I wrote this at JPL back in 1992
[13:51:13] <mru> our fft algorithm is more recent
[13:51:44] <hyc> hard to believe you could trim the ops down any further
[13:52:06] <mru> well, djb did
[13:52:16] <hyc> and most of my colleagues there had spent their lives doing signal processing
[13:52:24] <hyc> I'll have to read up on it
[13:52:26] <BastyCDGS> BBB, submitted new patch
[13:52:28] <hyc> compare notes..
[13:53:46] <hyc> http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/2007-August/034193.html
[13:53:51] <hyc> 2007?
[13:54:27] <hyc> oh yeah, I also have a pretty good DSP56001 fixed point fft
[13:54:36] <hyc> but now we're really reaching...
[13:57:41] <BastyCDGS> BBB, the + bps - 1 stuff was there because the original code did divide by bps after it...rounding up
[14:01:00] <merbzt> mru: we use a regular splitradix fft, although highly optimized
[14:01:29] <merbzt> djb wrote a paper about the "tangent fft"
[14:02:14] <BBB> BastyCDGS: I'm not quite sure what that means, but do it all separately
[14:02:14] <merbzt> less mac's but the structure was harder to optimize
[14:02:18] <BBB> don't do 10 things in a patch
[14:02:19] <BBB> it's confusing
[14:02:45] <BastyCDGS> I have shortened the new patch a lot, have you reviewed it?
[14:02:52] <mru> merbzt: ok, I must have been confused by all the fft talk back when we replaced it
[14:02:54] <BBB> not yet, I'm busy with some other stuff
[14:03:00] <BBB> you don't want to know what I do for a living :)
[14:03:23] <BastyCDGS> (including a mathematical proof that bps - 1 will cause buffer overflow error with new width code ;)
[14:04:04] <merbzt> I think that for some platforms/cpu's a radix2 fft might be the fastest one
[14:04:08] <BBB> I know it's a rounding up
[14:04:17] <av500> BBB: you study bugs under a magnifiying glass?
[14:04:18] <BBB> but I'm not convinced that you don't need the rounding anymore all of a sudden
[14:04:25] <BBB> av500: mice, not bugs :)
[14:04:42] <BBB> check http://ronald.bitfreak.net/publications.php and click the "article" links at the bottom
[14:05:00] <BastyCDGS> BBB, just read the math proof
[14:05:06] <BastyCDGS> that should clarify it
[14:05:18] <BBB> why don't you need the roundup there anymore?
[14:05:31] <BBB> I'll review later, need to do some real work also ;)
[14:05:32] <BastyCDGS> because the old code didn't do it on decode_init and even this is wrong
[14:05:46] <BBB> if it does it, it's probably fine
[14:05:51] <BastyCDGS> the IFF specs say that each line of a BODY chunk MUST start on a word-boundary
[14:05:54] <BBB> so give me a few hours and I'll commit if it's ok with me
[14:05:58] <merbzt> hyc: if we get a fixed point fft, I guess that we'll reimport the one in Rockbox, it should be quite fast on current fixed point platforms
[14:05:59] <mru> BBB: you slice and dice mice?
[14:06:04] <BBB> mru: yes
[14:06:12] <BBB> chop-chop-chop
[14:06:26] <BastyCDGS> BBB, so you're stuck to keyboard only now? ;)
[14:06:34] <kshishkov> mru: wanna mice and chips?
[14:06:42] <hyc> optical, mechanical, or biological.... :P
[14:06:46] <BastyCDGS> I just want the wire ;)
[14:06:52] <kierank> plenty of mice at my local supermarket
[14:07:03] <CIA-7> ffmpeg: stefano * r22972 /trunk/libavformat/file.c:
[14:07:03] <CIA-7> ffmpeg: Make file_open() return the error code set in errno if open() fails,
[14:07:03] <CIA-7> ffmpeg: rather than always ENOENT.
[14:07:03] <CIA-7> ffmpeg: stefano * r22973 /trunk/ffmpeg.c:
[14:07:04] <CIA-7> ffmpeg: Make ffmpeg use print_error() to make apparent the exact cause of
[14:07:04] <CIA-7> ffmpeg: failure happened when trying to open the output file.
[14:08:32] <CIA-7> ffmpeg: rbultje * r22974 /trunk/libavcodec/iff.c: (log message trimmed)
[14:08:33] <CIA-7> ffmpeg: Switch some ints to unsigned (they can only have positive values, this allows
[14:08:33] <CIA-7> ffmpeg: compiler to optimize some math from mul/div to shr/shl). Also add a cast to
[14:08:33] <CIA-7> ffmpeg: uint32_t when calling decodeplane32(), this silences a compiler warning.
[14:09:25] <av500> guys, are there patents behind .mp4 (as the container)?
[14:09:32] <BBB> maybe
[14:09:32] <av500> (known ones)
[14:09:33] <CIA-7> ffmpeg: Lastly, in decodeplane8/32(), flatten a double-loop into a single-loop and
[14:09:33] <CIA-7> ffmpeg: calculate the length once before entering the loop instead of during every
[14:09:33] <CIA-7> ffmpeg: iteration (since it doesn't change).
[14:09:33] <CIA-7> ffmpeg: rbultje * r22975 /trunk/libavcodec/iff.c:
[14:09:34] <CIA-7> ffmpeg: Move some branches outside looped code. Should improve the generated asm (and
[14:09:34] <CIA-7> ffmpeg: thus performance) slightly.
[14:09:34] <CIA-7> ffmpeg: Patch by Sebastian Vater <cdgs.basty googlemail com>.
[14:09:35] <CIA-7> ffmpeg: rbultje * r22976 /trunk/libavcodec/iff.c:
[14:09:35] <BBB> the spec says yes
[14:09:36] <CIA-7> ffmpeg: Reidnent after r22795.
[14:09:36] <CIA-7> ffmpeg: Patch by Sebastian Vater <cdgs.basty googlemail com>.
[14:09:43] <av500> it does?
[14:10:34] <mru> there are known patents on bifs and hint tracks for streaming
[14:10:40] <mru> neither of which are needed
[14:11:20] <av500> ok
[14:11:39] * BastyCDGS kicks these software patent guys into the sun
[14:14:40] <BBB> hey cia is back alive :)
[14:14:58] <BastyCDGS> BBB, just wondered because it took such long ;)
[14:14:58] <jai> as in the intelligence agency?
[14:15:03] <jai> oh ok
[14:15:16] <jai> just realized the context
[14:15:24] * jai kicks CIA-7 
[14:15:26] <CIA-7> ow
[14:15:44] <BastyCDGS> jai, if he would mean the other CIA, he wouldn't probably put a happy smile there ;)
[14:16:03] <jai> :)
[14:16:20] <BastyCDGS> but I'm still stuck with dp32
[14:16:25] <KotH> BastyCDGS: unless he works for them ;)
[14:16:32] <BastyCDGS> still twice as slow :(
[14:16:56] <BastyCDGS> I think dp32 is faster when using my original patch (I guess I run out of registers always here)
[14:17:13] <BastyCDGS> also the realtime calculation is much less effort (the shift is only calculated once)
[14:17:15] <av500> anybody has a copy of 14496-14 for me?
[14:17:20] <BastyCDGS> the remaining are simply MOV's...
[14:17:47] <BastyCDGS> mru, if you don't dare, I'ld like keep the original dp32 patch and just change it to reflect the new bug-fix patch
[14:18:01] <wbs> av500: http://albin.abo.fi/~mstorsjo/c051533_ISO_IEC_14496-12_2008.pdf
[14:18:25] <wbs> av500: got it somewhere publicly recently, but don't remember exactly where
[14:18:32] <BBB> BastyCDGS: for optimization, learn to look at disassembly and "help" gcc
[14:18:34] <mru> http://standards.iso.org/ittf/PubliclyAvailableStandards/
[14:18:38] <BBB> BastyCDGS: otherwise I have no good ideas :)
[14:18:54] <BBB> I'll look later
[14:18:54] <mru> hmm, that doesn't have -14
[14:18:56] <mru> only -12
[14:19:07] <mru> but -12 is the good one anyway
[14:19:08] <wbs> ah, sorry, it was -12 that I had, too
[14:19:10] <BastyCDGS> BBB, believe me I already did this and it puts a lot of shifts when using a static const
[14:19:13] <mru> -14 is mostly useless
[14:19:24] <BastyCDGS> in the inner loop
[14:19:47] <BastyCDGS> thus there are more shifts in the inner loop with dp32-static patch than there are shifts in whole dp32 with dp32 original patch
[14:20:11] <BastyCDGS> besides this dp32 non-static patch saves 6k bytes of memory
[14:20:21] <av500> mru: ok, -12 I had :)
[14:20:52] <BastyCDGS> mru, so please you would decide?
[14:21:17] <BastyCDGS> BBB, you of course can also decide ;)
[14:21:47] <av500> wbs: you have -14 too?
[14:22:04] <BBB> BastyCDGS: need to review it
[14:22:05] <wbs> av500: no, I think I got it from the url mru gave
[14:22:17] <BBB> BastyCDGS: like dp8, mru and I came up with a better way
[14:22:21] <BBB> BastyCDGS: might happen here also
[14:22:29] <av500> ah
[14:22:30] <BBB> BastyCDGS: so give us some time, optimization isn't an easy thing at times :)
[14:22:44] <BBB> BastyCDGS: in the mean time, look at iff/anim
[14:22:47] <BastyCDGS> with dp8 we solved that by killing one register, so there wasn't stack shuffle in the inner loop
[14:22:55] <BastyCDGS> BBB, I want to do HAM/EHB first
[14:22:57] <BBB> we might be able to do that for dp32 also
[14:23:03] <BBB> ok, then do ham/ehb :)
[14:23:06] <BBB> go go go :)
[14:23:16] <BastyCDGS> libavcodec/iff.c is already ready for HAM ;)
[14:24:13] <av500> wbs: but no -14 there :(
[14:24:22] <BastyCDGS> sorry meant libavformat/iff.c
[14:26:10] <BBB> so do libavcodec/iff.c ! :)
[14:29:27] <BastyCDGS> just preparing dp32-patch
[14:29:30] <BastyCDGS> then I go on ;)
[14:29:51] <BastyCDGS> because that patch is unsastified anyway, I will keep the START/STOP_TIMER with the patch
[14:29:58] <BastyCDGS> so I save you guys some typing time ;)
[14:33:52] <BastyCDGS> dp32 patch submitted to ml
[15:20:37] <BastyCDGS> one question, how gets the palette data in frame[1] gets created?
[15:20:48] <kshishkov> by decoder
[15:21:39] <BastyCDGS> no I mean the structure...
[15:21:45] <kshishkov> you simply write 256 32-bit numbers containing R*65536+G*256+B
[15:22:00] <BastyCDGS> the thing is set bps == 12 for indicate HAM6 and bps == 18 for indicate HAM8
[15:22:23] <BastyCDGS> kshishkov when I write to first element I get segfault
[15:22:34] <kshishkov> check PIX_FMT_
[15:22:54] <BastyCDGS> is 24bpp but that's correct
[15:23:07] <BastyCDGS> the thing that I need the color map for convert HAM6/8 image to 24bpp
[15:23:30] <kshishkov> palette is available only for PIX_FMT_PAL9
[15:23:33] <kshishkov> *PAL8
[15:23:52] <BastyCDGS> oh then I have to use extradata stuff
[15:24:11] <kshishkov> yes, that sounds more correct
[15:27:52] <BastyCDGS> oh
[15:28:03] <BastyCDGS> or is it legal to allocate a palette manually if 24bpp?
[15:28:07] <BastyCDGS> that would be more easy
[15:28:25] <BastyCDGS> and assign it to frame[1]?
[15:28:43] <kshishkov> nope
[15:29:01] <BastyCDGS> I'll need such a thing for EHB though
[15:29:07] <kshishkov> allocate it in context if you want
[15:29:20] <BastyCDGS> because the EHB palette is twice as large as normal palette
[15:31:26] <BastyCDGS> oh got it
[15:35:12] <BastyCDGS> does av_freep check if the pointer is NULL before freeing it?
[15:35:21] <kshishkov> of course
[15:39:35] <BastyCDGS> thanks...HAM6/8 decoding works...just colors are wrong ;)
[15:39:44] <BastyCDGS> but that's because I didn't do the actual HAM decoding yet
[15:39:52] <BastyCDGS> it justs decodes as normal 24bpp right now
[15:39:58] <BastyCDGS> but window opens and is recognizeable ;)
[15:44:22] <BastyCDGS> BBB, HAM6/8 decoding works almost perfectly
[15:44:29] <BBB> that was quick
[15:44:32] <BastyCDGS> just the actual decoding has to be done properly and it's finished
[15:44:33] <BBB> ok, on to iff/anim :)
[15:45:20] <mru> btw current svn gives different output for ooze on x86 and arm
[15:45:30] <BBB> lol :)
[15:45:49] <BastyCDGS> mru, is arm be?
[15:45:53] <mru> no
[15:46:01] <kshishkov> "maybe"
[15:46:06] <mru> not the one I'm using
[15:46:14] <kshishkov> IIRC, ARM and MIPS may be any endian
[15:46:23] <mru> depends on the implementation
[15:46:29] <BastyCDGS> mru, is 8pp decoded correctly?
[15:46:35] <mru> armv7 doesn't support true BE anymore
[15:46:46] <mru> heart is fine
[15:47:06] <BastyCDGS> how does the output differ?
[15:47:11] <BastyCDGS> could you supply a screenshot?
[15:47:22] <mru> 8241de83c0ed5012eff486fca2e1d3f4 x86
[15:47:25] <mru> 9fc3fddd3ff59946fb3ab81e380385c5 arm
[15:47:40] * mru watches it in md5
[15:47:49] <BastyCDGS> should I decode that image in my brain? :D
[15:49:58] <kshishkov> no, you should verify your code
[15:50:04] <BBB> mru: they're only ~8% different
[15:50:09] <BBB> that's not so much
[15:50:15] <BBB> pure randomness would be ~50% different
[15:50:41] <mru> md5 doesn't work like that
[15:50:43] <mru> and you know that
[15:50:45] <BBB> duh :-p
[15:50:56] <kshishkov> neither does Theory of Probability
[15:50:59] <BBB> btw it's not his code, peter ross wrote this I think
[15:51:00] <BastyCDGS> do you apply md5 on raw image output?
[15:51:08] <mru> yes
[15:51:12] <av500> not on the jpg?
[15:51:16] <av500> :)
[15:51:40] <BastyCDGS> do you see a difference in the actual image though?
[15:51:49] <mru> didn't look
[15:52:04] <av500> BastyCDGS: wrong approach
[15:52:11] <BastyCDGS> what do you think is causing this? the actual code or gcc output?
[15:52:21] <kshishkov> code
[15:52:55] <BastyCDGS> mru, could you check if the original code before my patches does show the same behaviour?
[15:54:40] <mru> a bunch of 00 bytes from x86 are ff from arm
[15:55:09] <kshishkov> may be padding
[15:56:35] <mru> the differences come in bursts of 6 bytes
[15:56:39] <mru> 2664 bytes apart
[15:56:48] <mru> that's 666*4
[15:56:56] <mru> width=666
[15:57:33] <kshishkov> devilous!
[15:57:34] <mru> near the end of each line
[15:57:46] <BBB> overreading?
[15:57:48] <kshishkov> sounds like line end padding to me
[15:57:50] <BBB> maybe his patch fixes it
[15:57:57] <BBB> try that patch he posted
[15:58:00] <kshishkov> BBB: no, may be not zeroing it
[15:58:10] <BastyCDGS> as I said the old IFF decoding is wrong
[15:58:15] <BBB> there's a memset(0) before each call to decodeplane8/32()
[15:58:19] <BBB> so that's not it
[15:58:25] <BBB> I think it's overreading of non-null data
[15:58:56] <BastyCDGS> which image you're doing this?
[15:59:03] <mru> ooze
[16:00:01] <BastyCDGS> MRLake.iff showed white pixels (which would be the ff's) with the old code too where it shouldn't
[16:00:53] <BastyCDGS> could you try ooze with my patch which also fixes MRLake.iff?
[16:03:02] <BastyCDGS> BBB, regarding iff-anim, before I really continue this, all issues with IFF-ILBM itself should be solved
[16:03:06] <av500> maybe there are some bad pixels oozing in?
[16:03:11] <BastyCDGS> after HAM/EHB there's still missing:
[16:03:14] <BastyCDGS> masking & transparent
[16:03:19] <BastyCDGS> and maybe DPaint color cycling
[16:03:45] <BastyCDGS> a image with mask isn't decoded properly now
[16:04:00] <BastyCDGS> masking asks a extra bpp which has to be skipped completely (which the current code doesn't do)
[16:04:07] <BastyCDGS> s/asks/adds
[16:04:47] <BastyCDGS> masks are added by sprite editors on amiga which save IFF-ILBM
[16:05:05] <BastyCDGS> masks allow the amiga hardware blitter to do extreme fast transparent drawing
[16:05:17] <BastyCDGS> mask bpp = all other bpps ORed together
[16:05:51] <BastyCDGS> thus in the mask bpp a bit is set when remaining planes have color index != 0
[16:23:07] <av500> mru: ...kill neon intrinsics, replace them by assembler in separate file to save kittens
[16:23:42] <mru> who has neon intrinsics?
[16:24:01] <av500> my coworker, until just now :)
[16:24:07] <mru> commit message?
[16:24:11] <av500> yup
[16:24:17] <mru> :-)
[16:24:26] <av500> seems he likes kittens
[16:24:41] <mru> who doesn't?
[16:24:51] <kshishkov> av500: then you know how to intimidate him next time
[16:25:00] <kshishkov> mru: me
[16:25:11] <mru> you're afraid of kittens?
[16:25:23] <av500> kshishkov: I threatened him with killing kittens of course
[16:25:25] <kshishkov> nope, I prefer cat way - I ignore them, they ignore me
[16:26:02] <mru> cats are nice
[16:26:35] <mru> then there's The Cat of course...
[16:26:46] <mru> av500 knows what I'm talking about
[16:26:47] <av500> speaking of which
[16:26:54] <elenril> http://tvtropes.org/pmwiki/pmwiki.php/Main/CatsAreMean
[16:27:24] <BastyCDGS> is such a thing ISO C?
[16:27:27] <BastyCDGS> uint8_t ham_row[avctx->width];
[16:27:27] <kshishkov> "If cats looked like frogs we'd realize what nasty, cruel little bastards they are. Style. That's what people remember."
[16:27:32] <BastyCDGS> gcc accepts it
[16:27:36] <mru> BastyCDGS: don't do that
[16:27:45] <mru> it's legal c99 but it's a bad idea
[16:28:12] <BastyCDGS> I need a tmp buffer which does a decodeplane8 in a pal buffer
[16:28:19] <mru> why?
[16:28:20] <BastyCDGS> and then want to call decodeham on it
[16:28:27] <BastyCDGS> it's the fastest way of decoding ham
[16:28:50] <mru> I would have though a single pass would be faster
[16:28:54] <mru> +t
[16:28:54] * av500 prefers slicing ham
[16:29:02] * kshishkov prefers skinka
[16:29:07] <mru> same thing, no
[16:29:47] <kshishkov> you can allocate it once in init time in context and reuse it for many times
[16:29:53] <BastyCDGS> you have to decode all planes first before you can decode HAM itself
[16:30:00] <BastyCDGS> per line
[16:30:13] <mru> right
[16:30:26] <mru> well, then av_malloc() a temp buffer and stick it in the context
[16:30:33] <BastyCDGS> okay
[16:30:38] <mru> never, ever use variable-length arrays
[16:31:02] <av500> y?
[16:31:08] <mru> they're evil
[16:31:18] <av500> so is google but I use ot
[16:31:19] <av500> izt
[16:31:21] <av500> it
[16:31:30] <av500> so why?
[16:31:48] <mru> what happens if the size is absurdly large?
[16:31:51] <kshishkov> well, VLA don't have any checks on their size IIRC
[16:31:57] <mru> A: you blow the stack and die
[16:32:01] <mru> if you're lucky
[16:32:16] <kshishkov> and in any case you won't be handling error
[16:32:19] <mru> also, some compilers simply call malloc() when they see a VLA
[16:32:31] <mru> with no error checking, of course
[16:32:35] <iive> also, valgrind can't detect out of memory access with them.
[16:32:38] <mru> so if the malloc fails, you die
[16:32:39] <BastyCDGS> ok nuff said ;)
[16:33:09] <kierank> [17:32] <@mru> also, some compilers simply call malloc() when they see a VLA --> why's that?
[16:33:16] <mru> furthermore, with gcc the function with the vla requires a frame pointer
[16:33:20] <mru> -> eats one extra reg
[16:33:32] <mru> and a function with a vla can't be inlined by gcc
[16:33:39] <mru> for the same reason more or less
[16:33:57] <mru> kierank: because they were written like that
[16:35:02] <mru> av500: anyway, what of the cat?
[16:35:36] <av500> I ask you, no?
[16:35:51] <mru> 17:26 <+av500> speaking of which
[16:36:10] <av500> speaking of which, what of the cat?
[16:37:33] <mru> doing her thing I guess, as cats do
[17:22:26] <BastyCDGS> BGRA means always that blue is at bits 24..31?
[17:22:34] <BastyCDGS> and alpha at 0..7?
[17:22:53] <BastyCDGS> PIX_FMT_BGR32
[17:22:56] <BastyCDGS> to be exact
[18:28:34] <ramiro> anyone got "libavcodec.a(avpacket.o) has local relocation entries in non-writable section" linking lavc with the apple toolchain i686? (ffmpeg is configure with -mdynamic-no-pic)
[18:30:40] <BastyCDGS> jai, I've a huge problem
[18:31:04] <BastyCDGS> HAM decoder outputs garbarge
[18:31:08] <jai> BastyCDGS: what would that be
[18:31:16] <astrange> ramiro: are you building a shared library?
[18:31:17] <BastyCDGS> avctx->bits_per_coded_sample must this be changed after decode_init from 12 and 18 to 24
[18:31:25] <BastyCDGS> ?
[18:31:33] <BastyCDGS> I use 12 and 18 to indicate HAM streams
[18:32:28] <ramiro> astrange: lav* are built as static libraries, but then they're linked together as a shared library (with some other stuff)
[18:32:39] <astrange> use -Wl,-read_only_relocs,suppress
[18:33:04] <jai> BastyCDGS: isnt that set in the demuxer?
[18:33:05] <ramiro> in ffmpeg's extra ldflags or the dylib I'm building?
[18:33:24] <BastyCDGS> yes it's set in the demuxer and evaluated in the decoder
[18:33:38] <BastyCDGS> the decoder checks if bpp = 12 || bpp = 18 and calls HAM decoding stuff
[18:33:41] <astrange> in the dylib link line
[18:33:45] <BastyCDGS> it sets PIX_FMT_BGA32
[18:33:55] <BastyCDGS> but keeps bpp = 12 set
[18:34:00] <BastyCDGS> resp. bpp = 18
[18:34:56] <jai> BastyCDGS: and the problem is?
[18:35:18] <BastyCDGS> the output is complete garbarge and I'm pretty sure the ham decoder is correct according to specs (I even looked at disasm output)
[18:35:36] <jai> BastyCDGS: pastebin your code
[18:35:48] <jai> BastyCDGS: diff against lavc/iff.c would be fine
[18:36:16] <BastyCDGS> here's a routine doing an unHAM:
[18:36:19] <BastyCDGS> http://home.comcast.net/~erniew/lwsdk/sample/iff/load.c
[18:36:26] <BastyCDGS> for comparision
[18:38:10] <BastyCDGS> http://pastebin.org/190155
[18:43:06] <BastyCDGS> case 1 => modify blue, case 2 = modify red and case 3 = modify green in decodeham
[18:44:54] <ramiro> astrange: thanks, that seems to have worked. now if I could just get libtool to create a .dylib instead of a .so...
[18:50:47] <astrange> find the libtool target type that does -dynamiclib and not -bundle
[18:51:07] <astrange> they're seperate types on mach-o but the same thing in elf
[18:51:52] <jai> BastyCDGS: got a sample?
[18:52:46] <BastyCDGS> jai: DCC?
[18:52:51] <BastyCDGS> if yes, just accept
[18:53:19] <jai> BastyCDGS: k
[18:53:48] <BastyCDGS> waiting for accept ;)
[18:55:18] <BastyCDGS> if it doesn't work (i.e. no receive window appears at you):
[18:55:19] <BastyCDGS> http://roundup.ffmpeg.org/issue1727
[18:56:11] <jai> bleh, the port is blocked i guess
[18:56:26] <jai> i'll grab the samples from roundup
[18:57:01] <jai> BastyCDGS: "A1200Power.iff"?
[18:57:26] <BastyCDGS> A400T_HAM6.IFF and A400T_HAM8.IFF
[18:58:42] <ramiro> astrange: hm, sorry, I don't understand.
[18:59:11] <_av500_> BastyCDGS: what alghorith is/was used to create ham images?
[19:00:04] <jai> BastyCDGS: could you dcc the sample again
[19:00:55] <BastyCDGS> dcc request sent
[19:01:25] <jai> BastyCDGS: meh, still doesnt work
[19:01:55] <jai> BastyCDGS: btw, which file on roundup?
[19:03:45] <BastyCDGS> guess it's one of the rar files
[19:04:04] <BastyCDGS> ilbm.rar
[19:04:37] <jai> ok
[19:07:28] <jai> BastyCDGS: also, are you NAT'd?
[19:07:36] <BastyCDGS> yes
[19:07:39] <jai> ah
[19:07:41] <jai> that explains it
[19:08:07] <jai> your client needs to use the router ip i guess
[19:08:26] <jai> with the forwarding in place
[19:09:07] * elenril wonders when will people start using ipv6
[19:09:35] <Dark_Shikari> never.
[19:09:45] <jai> elenril: this is the third world, we dont have ipv6
[19:09:48] <elenril> evil lies
[19:10:02] <elenril> jai: it's very hard to get ipv6 here too
[19:10:13] <BastyCDGS> my ISP doesn't have native ipv6 too
[19:10:16] <jai> BastyCDGS: basically, dcc_own_ip or whatever should be your router ip and dcc_port should be correctly forwarded
[19:10:31] <jai> elenril: .cz?
[19:10:34] <elenril> yes
[19:10:38] <jai> ah
[19:41:06] <BastyCDGS> jai
[19:41:09] <BastyCDGS> I found it
[19:41:27] <BastyCDGS> colors still wrong but at least I get a recognizable image ;)
[19:41:31] <BastyCDGS> memset(s->ham_buf, 0, avctx->width);
[19:41:53] <BastyCDGS> was before
[19:41:54] <BastyCDGS> memset(row, 0, avctx->width << 2);
[19:42:09] <BastyCDGS> since I was decoding into s->hambuf instead of row I had to clear that out instead lol
[19:42:42] * BastyCDGS *bangshisheadonthewall*
[20:01:17] <CIA-7> ffmpeg: stefano * r22972 /trunk/libavformat/file.c:
[20:01:17] <CIA-7> ffmpeg: Make file_open() return the error code set in errno if open() fails,
[20:01:17] <CIA-7> ffmpeg: rather than always ENOENT.
[20:01:17] <CIA-7> ffmpeg: stefano * r22973 /trunk/ffmpeg.c:
[20:01:18] <CIA-7> ffmpeg: Make ffmpeg use print_error() to make apparent the exact cause of
[20:01:18] <CIA-7> ffmpeg: failure happened when trying to open the output file.
[20:01:30] <CIA-7> ffmpeg: rbultje * r22974 /trunk/libavcodec/iff.c: (log message trimmed)
[20:01:30] <CIA-7> ffmpeg: Switch some ints to unsigned (they can only have positive values, this allows
[20:01:30] <CIA-7> ffmpeg: compiler to optimize some math from mul/div to shr/shl). Also add a cast to
[20:01:30] <CIA-7> ffmpeg: uint32_t when calling decodeplane32(), this silences a compiler warning.
[20:01:30] <CIA-7> ffmpeg: Lastly, in decodeplane8/32(), flatten a double-loop into a single-loop and
[20:01:30] <CIA-7> ffmpeg: calculate the length once before entering the loop instead of during every
[20:01:30] <CIA-7> ffmpeg: iteration (since it doesn't change).
[20:01:31] <CIA-7> ffmpeg: rbultje * r22975 /trunk/libavcodec/iff.c:
[20:01:48] <CIA-7> ffmpeg: Move some branches outside looped code. Should improve the generated asm (and
[20:01:48] <CIA-7> ffmpeg: thus performance) slightly.
[20:01:48] <CIA-7> ffmpeg: Patch by Sebastian Vater <cdgs.basty googlemail com>.
[20:01:48] <CIA-7> ffmpeg: rbultje * r22976 /trunk/libavcodec/iff.c:
[20:01:48] <CIA-7> ffmpeg: Reidnent after r22795.
[20:01:48] <CIA-7> ffmpeg: Patch by Sebastian Vater <cdgs.basty googlemail com>.
[20:01:49] <CIA-7> ffmpeg: rbultje * r22977 /trunk/libavformat/iff.c:
[20:01:49] <CIA-7> ffmpeg: Make the IFF demuxer a little more standards-compliant, e.g. respect the size
[20:01:50] <CIA-7> ffmpeg: fields of common media header chunks (these can have different sizes depending
[20:01:50] <CIA-7> ffmpeg: on the type of IFF file you read), better handle odd sizes (like RIFF, every
[20:01:51] <CIA-7> ffmpeg: field is padded to word) and handle headerchunks after the BODY chunk.
[20:01:53] <CIA-7> ffmpeg: Patch by Sebastian Vater <cdgs.basty googlemail com>.
[20:01:53] <CIA-7> ffmpeg: rbultje * r22978 /trunk/libavformat/iff.c:
[20:01:54] <CIA-7> ffmpeg: Reindent after rr22977.
[20:01:54] <CIA-7> ffmpeg: Patch by Sebastian Vater <cdgs.basty googlemail com>.
[20:01:55] <CIA-7> ffmpeg: lucabe * r22979 /trunk/libavdevice/v4l2.c: Simplify some output messages in the v4l2 input device
[20:01:56] <CIA-7> ffmpeg: lucabe * r22980 /trunk/libavdevice/v4l2.c: Reduce the verbosity of the v4l2 input device
[20:01:56] <CIA-7> ffmpeg: stefano * r22981 /trunk/libavutil/ (error.c error.h):
[20:01:57] <CIA-7> ffmpeg: Drop AVERROR_NOTSUPP at the next major bump, use AVERROR(ENOSYS)
[20:01:57] <CIA-7> ffmpeg: instead which is semantically equivalent.
[20:02:10] <jai> not cool
[20:02:24] <BastyCDGS> what is not cool?
[20:02:33] <jai> the flood
[20:02:45] <CIA-7> ffmpeg: Avoid to show bogus values, which may confuse both the human and the
[20:02:45] <CIA-7> ffmpeg: machine reader.
[20:02:45] <CIA-7> ffmpeg: Based on a patch by Robert Kr?ger $(echo lsvfhfs at tjhobm7.ef | tr "b-za" "a-z").
[20:02:45] <CIA-7> ffmpeg: stefano * r22984 /trunk/ffprobe.c: Reindent after the last commit.
[20:02:45] <CIA-7> ffmpeg: cehoyos * r22985 /trunk/libavformat/riff.c:
[20:02:45] <CIA-7> (8 lines omitted)
[20:02:47] <BastyCDGS> should I pastebin updated code?
[20:02:50] <jai> BastyCDGS: also, good that you got it working :)
[20:02:50] <ramiro> tell CIA-7 to use pastebin
[20:03:05] <jai> BastyCDGS: if it works, then send the patch right?
[20:03:09] * mru kicks CIA-7 
[20:03:10] <CIA-7> ow
[20:03:19] <BastyCDGS> I see an image but colors are wrong
[20:03:23] <BastyCDGS> image itself is perfect
[20:03:49] <jai> palette ordering is correct i assume?
[20:04:40] <BastyCDGS> when I write 0xFF0000 to *dst I get blue background
[20:05:00] <BastyCDGS> ham decoding does that way
[20:05:22] <BastyCDGS> where I'm not sure is ham_pal
[20:05:39] <BastyCDGS> it's PIX_FMT_BGR32
[20:06:22] <BastyCDGS> s->ham_palbuf[i] = AV_RL24( avctx->extradata + i*3 );
[20:06:29] <BastyCDGS> remember that ham_palbuf goes into *dst
[20:07:25] <BastyCDGS> AV_RL24 should put if i=0 and extradata[0] = 0xFF0000 a 0x0000FF value into ham_palbuf[i] right?
[20:08:52] <CIA-7> ffmpeg: jai_menon * r22988 /trunk/libavutil/log.h: Fix typo.
[20:28:44] <BastyCDGS> I got it
[20:28:48] <BastyCDGS> it's perfect now!
[20:29:07] <BastyCDGS> HAM6/8 works!!!!!!!!!!!!!!!!!!!!!!!!
[20:29:08] <BastyCDGS> yeah!!!!!!!!!!!
[20:29:10] <BastyCDGS> party time!
[20:40:47] * Compn waits patiently for ffmpeg to get files in rar/zip support
[20:41:00] * Compn should put it up as qual task :)
[20:41:47] <pJok> Compn, patch welcome ;)
[20:45:08] <_av500_> Compn: why stop there, make it play alt.binaries....
[20:45:30] <reddwarf> hi
[20:46:25] <reddwarf> I'm having problems with a lot of apps trying to compile with post-r22965 ffmpeg versions
[20:46:50] <reddwarf> "/usr/include/libavutil/common.h:154: error: 'UINT64_C' was not declared in this scope"
[20:47:34] <reddwarf> it seems that macro is defined or not depending of  __STDC_CONSTANT_MACROS being defined before stdint.h is included
[20:47:51] <reddwarf> so probably it's not a good idea to use it in a header?
[20:47:58] <mru> it's a very good idea to use
[20:48:00] <mru> it's standard C
[20:48:15] <mru> you might as well say it's not a good idea to use string constants
[20:48:19] <mru> or arrays
[20:48:24] <mru> or pointers
[20:48:36] <mru> or any arbitrary feature you broken compiler/libc doesn't support
[20:48:39] <j-b> pointers are bad
[20:48:44] <_av500_> pointers are dangerous!
[20:48:44] <j-b> arrays too.
[20:48:48] <j-b> they are!
[20:48:59] <j-b> VB.Net for everyone!
[20:49:05] <mru> guess what, living is dangerous
[20:49:07] <mru> you might die
[20:49:12] <Compn> Implementation of AVFilter infrastructure and various audio filters <~~ is this 'in progress'?
[20:49:14] <mru> in fact, I can guarantee you will
[20:49:17] <_av500_> pointers can dangle and array never know when to stop
[20:50:05] <reddwarf> but if I have to trust http://linux.die.net/man/3/uint64_c the macro is not always defined
[20:50:24] <mru> trust the offical spec
[20:50:58] <mru> http://www.opengroup.org/onlinepubs/009695399/basedefs/stdint.h.html
[20:50:59] <reddwarf> this can sound stupid, but can give me you a link please?
[20:51:03] <reddwarf> thanks
[20:51:31] <mru> no mention of conditional definition there
[20:56:35] <BastyCDGS> HAM6/8 support patch submitted to ml
[20:56:41] <BastyCDGS> works like a charm for me ;)
[21:01:07] <pJok> av500, why not play .torrents right away?
[21:01:37] <mru> torrents don't work like that
[21:01:48] <Tjoppen> BastyCDGS: that sounds just like the thing that a friend of mine would find awesome, since he's fan of 80's hardware and such
[21:01:59] <reddwarf> the stdint.h header from glibc says the "ISO C99" specifies the definition should be conditional
[21:02:00] <pJok> mru, i know
[21:02:13] <mru> reddwarf: that's a lie
[21:02:21] <reddwarf> following the draft from Wikipedia: http://www.open-std.org/jtc1/sc22/WG14/www/docs/n1256.pdf it seems true
[21:02:33] <mru> don't believe wikipedia
[21:02:35] <lu_zero> yawn
[21:02:37] <reddwarf> the official standard isn't free, true?
[21:02:49] <mru> the one I linked is the official standard
[21:02:54] <lu_zero> j-b: you are sick
[21:02:57] <reddwarf> well, it's a link to a PDF from open-std.org
[21:03:09] <mru> don't trust drafts
[21:03:13] <j-b> lu_zero: I know. I like you too!
[21:03:43] <BastyCDGS> mru, non mod 4 check and handling isn't necessary anymore since number of bits is always divisible by 8/16.
[21:03:44] <lu_zero> theheh
[21:03:59] <mru> the official iso c99 spec has the exact same text as the SUS document
[21:06:28] <reddwarf> ok, I trust you
[21:07:40] <reddwarf> have somebody reported this to glibc?
[21:07:41] <reddwarf> without a copy of the standard an my poor C knowledge I don't feel as being able to "win" in such a bug report
[21:12:52] <Kovensky> indeed, gl fighting with drepper
[21:13:00] <mru> reddwarf: are you building a c++ app?
[21:14:53] <reddwarf> I saw the problem in more than a single openSUSE package... right now I'm looking at Amarok: yes, C++
[21:15:12] <mru> that could have different rules
[21:15:24] <mru> c++ is a totally different language from C
[21:15:32] <mru> unfortunately part of the syntax is confusingly similar
[21:15:51] <BBB> do we need to include <stdint.h> for the macro to work?
[21:16:12] <mru> of course
[21:16:17] <mru> it's defined there
[21:20:23] <reddwarf> so it could be that C++ really needs __STDC_CONSTANT_MACROS?
[21:20:28] <BastyCDGS> just updated my HAM6/8 patch, please ignore the previous only
[21:20:44] <mru> reddwarf: possibly, I don't the c++ spec on hand
[21:20:45] <janneg> reddwarf: yes
[21:21:00] <mru> but there's nothing we can do about that
[21:21:04] <janneg> at least with the current spec
[21:21:10] <mru> it would be an error for us to define that macro
[21:21:32] <mru> since that might mess with the calling app in some way
[21:22:03] <janneg> no idea if it's included in C++0x
[21:22:35] <reddwarf> and even if defined in the header, a C++ app could include stdint.h before common.h and your definition would have no effect
[21:23:19] <reddwarf> change it for a manual ULL suffix is an option?
[21:24:25] <mru> ull might not do what you want
[21:26:34] <janneg> C++0x should have a C99 compatible <cstdint>
[21:27:06] <BastyCDGS> yes you also can still include in C++ the gold <stdint.h> stuff
[21:28:19] <bcoudurier> hi guys
[21:28:47] <Dark_Shikari> hi bcoudurier's onjoin script
[21:33:22] <bcoudurier> hello Dark_Shikari
[21:34:06] <reddwarf> well, not a nice situation... any advice? be it for libavutil or apps that use it?
[21:34:27] <BastyCDGS> HAM support indentation patch submitted to ml
[21:39:08] * Kovensky awaits for CHEESE support
[21:39:32] <lu_zero> reddwarf: problems with the inline functions?
[21:40:29] * lu_zero reads up there...
[21:40:37] <lu_zero> damn I NEED a working bx...
[21:40:51] <janneg> reddwarf: libav* uses C99 if you want to use it from C++ you're on your own
[21:44:00] <reddwarf> do you think a local openSUSE patch to ffmpeg to use ULL instead of UINT64_C would break something knowing we just use GNU tools and only on x86 and x86-64?
[21:44:55] <_av500_> reddwarf: what package is that?
[21:44:55] <janneg> reddwarf: where's the problem defining __STDC_CONSTANT_MACROS before includeing libav* headers?
[21:45:33] <reddwarf> just less work: a single patch vs multiple patches
[21:45:53] <bcoudurier> LL is different than UINT64_C
[21:46:03] <reddwarf> the one from http://packman.links2linux.org/package/ffmpeg
[21:46:17] <lu_zero> reddwarf: you might patch the pkgconfig file and be happy...
[21:46:48] <janneg> reddwarf: 23:24 <@mru> ull might not do what you want
[21:48:32] <reddwarf> but if I limit myself to x86 and x86-64 it's still not safe? no idea of what the difference between ULL and UINT64_C is...
[21:48:42] <reddwarf> yes, the pkg-config idea is not bad
[21:48:51] <mru> that's a *very* bad idea
[21:49:13] <lu_zero> mru: which one and why?
[21:49:17] <mru> pkgconfig
[21:49:22] <reddwarf> for sure there including libav* without using pkg-config, but that would be less
[21:49:29] <BastyCDGS> reddwarf what is exactly the problem here that you want to do this?
[21:49:30] <mru> you'll get different behaviour depending on whether the caller uses pkgconfig or not
[21:49:57] <lu_zero> if the caller doesn't use pkg-config... well...
[21:50:08] <lu_zero> the caller is using C++ already
[21:50:23] <mru> if the caller doesn't use pkgconfig, then the caller is smart and should not be punished
[21:50:23] <janneg> and -D__STDC_CONSTANT_MACROS is unecessary for C99 apps
[21:50:41] <mru> in fact, defining that in C99 has undefined behaviour
[21:50:53] <mru> it's reserved namespace you're not allowed to step on
[21:51:37] <lu_zero> mru: not using pkg-config means that the caller is using some kind of euristic
[21:52:07] <mru> not at all
[21:52:12] <mru> it means the caller is doing the right thing
[21:52:19] <mru> #include <libavcodec/avcodec.h>
[21:52:19] <mru> done
[21:52:48] <lu_zero> #include <libavcodec/avcodec.h> isn't enough...
[21:52:51] <lu_zero> and you know it =P
[21:52:57] <mru> not enough for what?
[21:53:04] <mru> not for lavf of course
[21:53:07] <_av500_> it is enough here
[21:53:09] <mru> it was an example
[21:53:29] <mru> you should of course include the headers that declare the stuff you need
[21:53:31] <lu_zero> _av500_: how so O_O?
[21:54:09] <_av500_> lu_zero: ?
[21:54:09] <BastyCDGS> just a question...
[21:54:26] <BastyCDGS> here's a list of other IFF formats which do pix/snd, what do you think of making a demuxer/decoder for them?
[21:54:28] <BastyCDGS> http://lclevy.free.fr/amiga/formats.html
[21:57:31] <lu_zero> _av500_: just including the header in an empty file and feeding gcc is something that checks for presence
[21:58:08] <_av500_> empty?
[21:59:01] <lu_zero> _av500_: we were talking about having a way to check for libavsomething
[21:59:08] <lu_zero> isn't it ^?^
[22:00:00] <_av500_> we were talking about what is needed besides including libavcodec/avcodec.h, no?
[22:00:08] <_av500_> like e,g, pkgconfig
[22:01:23] <BastyCDGS> regarding HAM, I just read that there's also HAM4/5: http://www.winfuture-forum.de/index.php?showtopic=65125&st=15
[22:01:41] <BastyCDGS> If you wish I support them also I need some files for testing...
[22:07:15] <lu_zero> pkg-config --cflags sometimes is helpful indeed (luckily we _do_ not need that for ffmpeg though)
[22:08:22] <mru> if that's "helpful" you're dealing with a very, very broken package
[22:13:25] <reddwarf> well, I think I have an example where pkg-config cflags is useful
[22:13:53] <reddwarf> in GNU libc and libpthread provide duplicated functions, thead safe and not thread safe
[22:14:17] <mru> you're wrong
[22:14:35] <reddwarf> ?
[22:14:44] <mru> pkg-config isn't useful
[22:14:45] <mru> ever
[22:15:23] <lu_zero> mru: the idea of having a small tool that tells you if a package is available and how to link to it is good
[22:15:30] <reddwarf> if a library if compiled with -pthread it will use the functions from libpthread at compile time
[22:15:36] <mru> lu_zero: no it's not
[22:15:49] <mru> something is available if the headers and libs exist
[22:16:02] <lu_zero> and then?
[22:16:03] <reddwarf> but if an app doesn't uses pthread directly it will not use -pthread if pkg-config doesn't says it
[22:16:04] <mru> libs should link to whatever they need
[22:16:18] <mru> -pthread is not a standard compiler flag
[22:16:24] <reddwarf> since libc will be before libpthread at link time will not the library fail?
[22:16:24] <mru> what if you're not compiling with gcc?
[22:16:38] <mru> besides, there are no such duplicate functions
[22:16:50] <BastyCDGS> I made a screenshot showing ffmpeg an HAM8 image ;)
[22:16:51] <BastyCDGS> http://www.freeimagehosting.net/uploads/65b09211c2.png
[22:16:58] <BastyCDGS> but wonder why it got such small
[22:18:49] <kierank> i can't tell if the comments on that livejournal post are trolls or genuine
[22:18:54] <BastyCDGS> uploaded it to my hp: http://www.cdgs-crew.com/HAM.png
[22:18:59] <BastyCDGS> here is it in original size ;)
[22:21:42] <reddwarf> both nm -D /lib64/libc.so.6 | grep ' open$' and nm -D /lib64/libpthread.so.0 | grep ' open$' say the libraries export an open() function
[22:24:45] <lu_zero> readelf -s states that libpthread.so's open is und...
[22:25:29] <reddwarf> here it returns: "  482: 000000000000e380   128 FUNC    WEAK   DEFAULT   14 open"
[22:26:08] <reddwarf> being 14 the .text section
[22:27:13] <reddwarf> Linux with GNU tools, could be different in other systems
[22:27:50] <lu_zero> readelf -s /lib/libpthread.so.0 | grep open 22: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND fopen at GLIBC_2.2.5 (9)
[22:28:43] <reddwarf> fopen is indeed undefined also here, but open isn't
[22:28:58] <BastyCDGS> fopen???
[22:29:08] <BastyCDGS> how that can be?
[22:29:26] <lu_zero> reddwarf: right =P
[22:30:13] <mru> first of all, notice that those definitions are not global
[22:30:41] <reddwarf> the thing is that an app will add libc and then libA, and then libA will add libpthread... since the symbol resolution order is global, pthread function will never be called
[22:30:42] <mru> and they are weak
[22:30:52] <mru> will never take precedence over a non-weak definition
[22:31:02] <reddwarf> libc also defines it weak
[22:35:52] <reddwarf> the fact is I never saw an app fails because of this, but in theory couldn't it fail since the functions libA sees at compile time are thread-safe and at runtime non thread-safe?
[22:36:41] <lu_zero> at compile time it cannot see it at all =)
[22:39:39] <mru> those functions are there make those calls cancellation points for threads
[22:57:26] <reddwarf> someone gave me a complicated explanation about this... but yours make more sense!
[22:59:20] <mru> I'm not sure of the mechanism by which the pthread ones override libc
[22:59:26] <mru> but it's not as simple as linking order
[23:18:15] <BastyCDGS> one question is there already support for color cycling in libavfilter?
[23:18:22] <BastyCDGS> I mean shuffling around color indices
[23:18:58] <BastyCDGS> it should feature the following: choose start/end color indices set a time when the next shift goes
[23:19:15] <BastyCDGS> and decide if shuffle forward/backward/pingpong/random
[23:23:55] <saste> BastyCDGS: that should be pretty easy to implement
[23:24:17] <BastyCDGS> just want be sure before I start doing it that it just doesn't already exist
[23:26:04] <BastyCDGS> http://home.comcast.net/~erniew/lwsdk/docs/filefmts/ilbm.html
[23:26:15] <BastyCDGS> regarding this read: 4. Nonstandard Data Chunks