#jogamp @ irc.freenode.net - 20130426 05:06:15 (UTC)

20130426 05:06:15 -CatOut- Previous @ http://jogamp.org/log/irc/jogamp_20130425050601.html
20130426 05:06:15 -CatOut- This channel is logged @ http://jogamp.org/log/irc/jogamp_20130426050615.html
20130426 06:10:53 * DemoscenePassiv (~Lutsche@anon) has joined #jogamp
20130426 06:36:47 * hharrison (~chatzilla@anon) has joined #jogamp
20130426 06:37:21 <hharrison> good evening jogampers
20130426 06:37:35 <sgothel> good morning Harvey
20130426 06:38:06 <sgothel> & Dominik .. and all !
20130426 06:38:41 <hharrison> Looks like you've been having fun with cross compilers...reading through the recent gluegen stuff
20130426 06:39:23 <sgothel> yeah .. you know, what you are not doing yourself .. nobody else will :) .. or some phrase like that
20130426 06:39:56 <hharrison> I still don't know why gcc makes that so damn difficult
20130426 06:40:18 <sgothel> gcc is not the 'evil' here - it's a distribution/maintainer job
20130426 06:40:27 <hharrison> clang/llvm really got that part of the equation 'right'
20130426 06:40:29 <sgothel> .. to build proper multiarch cross compilers
20130426 06:40:56 <sgothel> i.e. it works w/ x86_32 and x86_64
20130426 06:41:06 <sgothel> clang has proper one for all ?
20130426 06:41:36 <hharrison> yeah, in gcc parlance, you can select 'target' with a switch to a single binary
20130426 06:41:39 <sgothel> multiarch is avail in gcc for years ..
20130426 06:41:54 <sgothel> gcc has same .. -march ARCH
20130426 06:42:11 <hharrison> I thought -march was for the same family only
20130426 06:42:21 <sgothel> and some did build Candian cross .. [1] -> [2] -> [3] :)
20130426 06:42:25 <hharrison> and really only affected instruction selection
20130426 06:42:37 <hharrison> ie i386/i486/i686
20130426 06:42:37 <sgothel> it shall affect everything
20130426 06:42:59 <sgothel> crosstools-ng can do it - would need to test if I have time :)
20130426 06:43:07 <hharrison> So you can say -march=aarch64 or -march=x86_64 to the same binary?
20130426 06:43:10 <sgothel> ofc .. binutils must be done this way as well
20130426 06:43:20 <sgothel> that is the idea ... why not ?
20130426 06:43:42 <sgothel> i.e. crosscompiler build does the same
20130426 06:43:45 <hharrison> I'm obvisouly out of date, I thought you couldn't build multiple backends into a single gcc
20130426 06:43:51 <sgothel> x86_64 -> arm
20130426 06:44:05 <sgothel> x32 x64 is the same
20130426 06:44:14 <sgothel> from a x32 perspective, x64 is alien
20130426 06:44:42 <sgothel> I did that actually in around .. err .. 2005 or so .. or even earlier
20130426 06:44:55 <hharrison> Oh, reeeeealy out of date then
20130426 06:45:10 <sgothel> was happy to find Dan Kegel's crossutils .. being maintained
20130426 06:45:49 <hharrison> I only ever found myself with a pile of binaries laying around gcc-i586, gcc-arm-oabi
20130426 06:45:52 <hharrison> etc
20130426 06:45:53 <sgothel> it's just the last bottom of the compiler which is affected anyways :)
20130426 06:46:14 <sgothel> more duty to the linker/binutils part .. especially the ARM sections
20130426 06:47:15 <sgothel> you can see in commits and blobs pushed to our /files folder .. needed to pick the low versioned ARM client libs :)
20130426 06:47:41 <sgothel> ld would use the lowest denominator to declare the ARM version .. it's a dirty business
20130426 06:48:01 <hharrison> <reads commits>...so you're a null == b kinda guy I see
20130426 06:48:23 <sgothel> embedded space - security - yes :)
20130426 06:48:24 * DemoscenePassiv (~Lutsche@anon) Quit (Ping timeout: 252 seconds)
20130426 06:49:14 <hharrison> I stopped doing that when I found I could turn on a findbugs warning to flag = inside an if() block, made it my own special compiler error
20130426 06:49:17 <sgothel> and the GLIBC version hack .. guess we are now quite compatible
20130426 06:49:55 <sgothel> but I like this and const/final - to make it easier to read .. and to avoid mistakes
20130426 06:50:04 <sgothel> also always embrace statements :)
20130426 06:50:22 <sgothel> push local stack stuff in inner blocks etc
20130426 06:50:39 <sgothel> so .. when you read it, you know 'whats on'
20130426 06:51:21 <hharrison> I have no real problem with the pattern, I'll try to remember in the future, feel free to send patches back for repair if I forget
20130426 06:51:24 <sgothel> Not quite Kafka yet, but I have time to improve :)
20130426 06:52:16 <sgothel> Sure .. usually I simple 'cleanup' things while reviewing .. often faster - however, bug things to send back - sure.
20130426 06:52:20 <hharrison> Good lord, that ATI mobile bug would be funny if it wasn't so tragic
20130426 06:52:29 <sgothel> hehe
20130426 06:52:34 <sgothel> 2 years old bug
20130426 06:52:50 <sgothel> so I bought a 550 EUR used notebook .. and I was lucky
20130426 06:52:58 <sgothel> 24h later - I don't need it anymore ..
20130426 06:53:02 <hharrison> hehe 'lucky'
20130426 06:53:30 <sgothel> maybe a new testnode later on
20130426 06:54:09 <sgothel> Wade went nuts w/ Bug 520 (same thing) .. hacking WGL like crazy
20130426 06:54:33 <sgothel> since: he didn't have access to that machine - conclusion: don't do it w/o access :)
20130426 06:55:24 <sgothel> guess we need to revalidate the quirks each year .. expiration date :)
20130426 06:56:21 <sgothel> so I guess I cont w/ RandR1.3 and try to find that monitor info for Windows and OSX as well, then GL4.3/ES3
20130426 06:56:45 <sgothel> later - more cleanup .. your URL/hash bug .. feel free to fix things when you have time :)
20130426 06:56:55 <hharrison> gnight!
20130426 06:57:09 * hharrison (~chatzilla@anon) Quit (Quit: ChatZilla 0.9.90 [Firefox 18.0.2/20130206104040])
20130426 08:54:35 * [Mike] (~Mike]@anon) Quit ()
20130426 10:07:40 <sgothel> 20th Anniversary .. http://www.ncsa.illinois.edu/Projects/mosaic.html .. good ole times :)
20130426 10:20:09 <sgothel> git clone https://github.com/alandipert/ncsa-mosaic :)
20130426 10:22:15 <sgothel> http://jogamp.org/files/screenshots/ncsa-mosaic/ :)
20130426 10:24:38 <xranby> sgothel: fun, that looks like a time machine!
20130426 10:24:47 <xranby> revisit the 90's
20130426 10:26:31 <xranby> oh lovely it have convrted all images to 16 colors?
20130426 10:26:54 <sgothel> strong png reader :)
20130426 10:27:21 <sgothel> errr jpeg I guess :)
20130426 10:28:08 <sgothel> yes, '94 or so I got in touch w/ Internet on a Solaris machine w/ that browser .. gopher .. etc .. mindblowing .. all the information
20130426 13:11:07 <xranby> sgothel: i have analyzed the FFMPEGmediaPlayer code and it needs some improvement http://forum.jogamp.org/JOGL-media-player-tp4027810p4029049.html
20130426 13:11:56 <xranby> the texFrames cache is not in use
20130426 13:39:20 <sgothel> 'the designer' got lucky 'eh ? :)
20130426 13:40:30 <sgothel> not threaded ?
20130426 13:49:02 <xranby> not threaded for what i can see
20130426 13:51:54 <sgothel> it's been a long time .. let the designer read his ole code :)
20130426 13:53:00 <sgothel> (I guess it's OK to use real names in forum if naming someone, so they don't need to look via git :)
20130426 14:02:31 <xranby> sgothel: sounds good, there is a TODO: off thread 'readNextPackage0(..)' in the code so i guess it was intended to be multithreaded at one time
20130426 14:04:43 <sgothel> yes .. now I remember hehe, the Android version is multithreaded, this still lacks ..
20130426 14:05:13 <sgothel> right .. so a multipacket buffer would be needed, .. 1-3 textures .. using TextureSequence functionality .. sort of
20130426 14:05:45 <sgothel> indeed .. an !video frame drops a video frame :)
20130426 14:08:06 <xranby> btw.. i figured out why enabeling audio decoding corrupted video... its a typo that make us use the videodecoder context to decode the audio frames
20130426 14:08:09 <sgothel> very good .. so a thread should fill texFrames .. etc will reply - good review
20130426 14:08:53 <xranby> for mpeg it was ok since the mpeg video decoder and mpeg audio decoder operates the same
20130426 14:09:00 <xranby> sort of
20130426 14:12:59 <sgothel> replied ..
20130426 14:13:11 <sgothel> sweet .. so we have a TODO here as well :)
20130426 14:14:08 <sgothel> hmm .. me currently tiddling w/ RandR 1.3 .. to get at least the monitor frequency - new drivers require this. I may stop then, i.e. not working on exposing coordinates of monitors.
20130426 14:14:45 <sgothel> All this would be actually a bit 'funny' anyways, since monitor / virtual-screen arrangement could be quite customized .. hmm
20130426 14:15:02 <sgothel> guess then it's time to fix our libav stuff :)
20130426 14:16:08 <sgothel> since you are already 'in it' .. do you like to add the frame-fill-thread using a ringbuffer [rotating index] for a/v ?
20130426 14:16:22 <sgothel> .. in java ofc
20130426 14:17:49 <sgothel> ?
20130426 14:20:13 <xranby> is there a circular buffer inside jogamp we can use? or do java provide one nowdays?
20130426 14:20:24 <xranby> i use my own circular buffer at work
20130426 14:20:56 <xranby> i agree that this is the right type of primitive to use since its multithread safe
20130426 14:21:02 <sgothel> a simple array w/ a rotating index (modulo) and a fillCounter incl one monitor object for locking would suffice
20130426 14:21:22 <sgothel> I did that for OpenMAX .. hmm but in native code I guess, lets see
20130426 14:22:03 <sgothel> must be in native code .. sorry
20130426 14:22:23 <sgothel> but you know what I mean - sure.
20130426 14:22:56 <sgothel> the locking can be similar to the Android impl. in our code .. simple monitor object (synchronized)
20130426 14:25:45 <sgothel> array is texFrames[textureCount] .. only the index needs to added in impl. and the threaded handling .. I guess the real magic comes w/ the get method, where we have to do the a/v sync
20130426 14:26:11 <sgothel> simple wait is there already .. well :)
20130426 14:26:54 <sgothel> you also mentioned audio is working now, i.e. extracting it ?
20130426 14:27:31 <sgothel> you fixed the typo ?
20130426 14:27:37 <xranby> sgothel: i have some work in progress code that is extracting sudio properly
20130426 14:27:50 <sgothel> you configure the audio target format ?
20130426 14:28:10 <xranby> sgothel: let me push what i have someplace and you may loko at it
20130426 14:28:13 <xranby> look
20130426 14:28:14 <sgothel> i.e. be-pcm16 (or whatever it's called) for JOAL ?
20130426 14:28:41 <xranby> i have implemented less than you expect
20130426 14:28:49 <xranby> no JOAL connection yet
20130426 14:29:06 <sgothel> today I am pretty wasted already and will take a nap soon .. :) hmm, but in the next days ..
20130426 14:29:37 <xranby> in the next days sounds good
20130426 14:29:46 <sgothel> so how do you like to cont. ? pick your toy: cont. audio, doing video threaded as well or shall I do that ?
20130426 14:30:22 <xranby> i will continue do code review for a start
20130426 14:30:32 <xranby> of what we have right now
20130426 14:30:47 <sgothel> a/v or everything ? :)
20130426 14:31:05 <sgothel> thats great ofc .. kudos!
20130426 14:31:21 <xranby> code review of a/v FFMPEGMediaPlayer
20130426 14:32:54 <sgothel> audio (like video) .. i.e. the whole 'sink' design IMHO should consider: [1] sink device/format, [2] 'can we decode directly into the sink ?', [3] 'do we need to copy data?' ..
20130426 14:33:00 <xranby> btw typo ...decode_audio4(pAV->pVCodecCtx -> ...decode_audio4(pAV->pACodecCtx
20130426 14:33:14 <sgothel> olala
20130426 14:34:01 <sgothel> thats what happens if you simply remove my comment tags .. but thx for trusting me so far :)
20130426 14:34:48 <sgothel> guess I am getting funny when awake for too long .. yawn
20130426 14:35:29 <xranby> from what i have understood of ffmpeg/libav is that av_read_frame always returns whole frame packets
20130426 14:35:47 <sgothel> right now we follow [2], i.e. copy decoded payload to sink (video -> texture)
20130426 14:35:52 <sgothel> I guess same goes for audio
20130426 14:36:23 <sgothel> maybe we could use an NIO buffer to decode in that directly for JOAL or other usage
20130426 14:36:43 <sgothel> that would be the AudioFrame .. I guess
20130426 14:36:54 <sgothel> (in Java <-> native)
20130426 14:37:09 <sgothel> right ?
20130426 14:37:52 <sgothel> are you in a bus ?
20130426 14:38:07 <xranby> i am soon on abug.. hmm not sure how to wo allocate the frame on the nio buffer
20130426 14:38:18 <xranby> usually you allocate a AVFrame using the libav api
20130426 14:38:33 <sgothel> but you can pass memory ptr there AFAIK ..
20130426 14:38:39 <xranby> and the decoded data will end up inside the AVFrame
20130426 14:38:40 <sgothel> thought we do something ..
20130426 14:39:37 <xranby> (you access the decoded data using (AVFrame)frame->data[0] )
20130426 14:39:38 <sgothel> we could allocate n AVFrame's in native code and keep it
20130426 14:40:07 <sgothel> then create NIO buffer from native and associate w/ Java's AudioFrame (like TextureFrame)
20130426 14:40:42 <sgothel> in JNI you can create an NIO ByteBuffer w/ given native memory
20130426 14:42:25 <xranby> sgothel: good!
20130426 14:42:45 <xranby> sgothel: please take a rest, hard working you
20130426 14:42:54 <sgothel> (*env)->NewDirectByteBuffer(env, (void*) (intptr_t) addr, capacity);
20130426 14:43:12 <sgothel> e.g.: jogl/make/config/jogl/gl-impl-CustomCCode-gles2.c
20130426 14:43:48 <sgothel> yup .. will stop annoying you .. and come back to this when having a fresh brain :)
20130426 16:29:20 * [Mike] (~Mike]@anon) has joined #jogamp
20130426 22:02:48 * DemoscenePassiv (~Lutsche@anon) has joined #jogamp
20130426 23:24:11 * DemoscenePassiv (~Lutsche@anon) Quit (Ping timeout: 268 seconds)
20130427 02:28:10 * [Mike] (~Mike]@anon) Quit ()
20130427 02:56:39 * [Mike] (~Mike]@anon) has joined #jogamp
20130427 03:21:45 * hharrison (~chatzilla@anon) has joined #jogamp
20130427 03:34:21 * hharrison (~chatzilla@anon) Quit (Quit: ChatZilla 0.9.90 [Firefox 18.0.2/20130206104040])
20130427 05:06:28 -CatOut- Continue @ http://jogamp.org/log/irc/jogamp_20130427050628.html