JogAmp IRC Chat Logs

#jogamp @ irc.freenode.net - 20130427 05:06:28 (UTC)

20130427 05:06:28 -CatOut- Previous @ http://jogamp.org/log/irc/jogamp_20130426050615.html
20130427 05:06:28 -CatOut- This channel is logged @ http://jogamp.org/log/irc/jogamp_20130427050628.html
20130427 08:19:05 * [Mike] (~Mike]@anon) Quit (Read error: Connection reset by peer)
20130427 11:46:58 * DemoscenePassiv (~Lutsche@anon) has joined #jogamp
20130427 18:52:06 * DemoscenePassiv (~Lutsche@anon) Quit (Ping timeout: 245 seconds)
20130427 20:01:22 * xranby_ac100 (~xranby@anon) has joined #jogamp
20130427 20:03:25 <sgothel> good evening
20130427 20:04:18 <sgothel> figured how to do the multi-monitor thingy for Windows and RandR13 .. and I guess OSX is similar - but will change 'ScreenMode' API
20130427 20:05:54 <sgothel> proper representation will be [Screen] 1:n - [MonitorDevices] 1:n - [MonitorModes] ; .. and [Screen] 1:m - [MonitorModes]; m >= n
20130427 20:07:13 <sgothel> due to different underlying APIs: MonitorMode: [resolution, refresh-rate, rotation]; MonitorDevice: [sizeMM, screenPortion]
20130427 20:08:17 <sgothel> 1st object relation; 2nd: has_a
20130427 20:10:57 <sgothel> Like on XRandR13 rotation is part of the MonitorDevice (Output), but on Windows MonitorMode - hence pushing it down to form common denominator
20130427 20:13:14 <xranby_ac100> rotated monitor screens, funky
20130427 20:13:58 <sgothel> oh - and [Screen] is the virtual - screen, w/ virtual screen size (i.e. all together)
20130427 20:14:01 <xranby_ac100> sgothel: can they rotate any angle or are they locked at 90 degree angles
20130427 20:14:37 <sgothel> depends .. common denominator: 90 degr steps, XRandR13 has a transformation matrix
20130427 20:14:49 <xranby_ac100> so screen is a large virtual square where the attached monitors are viewpoerts that may overlap inside this virtual screen?
20130427 20:15:15 <sgothel> yup - this is true already, hence current ScreenMode OO relation is broken
20130427 20:15:47 <sgothel> it's more difficult to find proper names that click :)
20130427 20:16:27 <sgothel> so I hope above names do click .. makes sense, somewhat aligned to RandR, just Output -> MonitorDevice, and Mode -> MonitorMode
20130427 20:16:42 <sgothel> was like VOut* .. but I guess that doesn't read well
20130427 20:17:11 <sgothel> your 'viewport' -> screenPortion
20130427 20:17:30 <sgothel> but we can name it viewport
20130427 20:17:44 <sgothel> [x, y, width, height]
20130427 20:18:52 <sgothel> screenPortion, portion or viewport ? the more I read it, I like viewport best
20130427 20:19:11 <sgothel> portion reminds me of food now :)
20130427 20:20:46 <xranby_ac100> i think viewport is an established word in computer graphics so it may make sence to apply it in the pyshical work of screens and monitors as well
20130427 20:22:03 <sgothel> well, I like it since it's shorter - maybe also b/c used to it as well. establishment sounds so .. :)
20130427 20:22:13 <sgothel> viewport it is :)
20130427 21:06:01 <xranby_ac100> ffmpeg/libav <3 its our ticket to remove use of javax.sound for audio format decoding
20130427 21:07:00 <xranby_ac100> https://jogamp.org/bugzilla/show_bug.cgi?id=684
20130427 21:27:50 <sgothel> https://jogamp.org/bugzilla/show_bug.cgi?id=684#c3
20130427 21:28:23 <sgothel> JOAL cannot depend on libav!
20130427 21:29:38 <sgothel> pls check Julien's JOAL repo, he started the WAV header parsing already.
20130427 21:29:51 <sgothel> Since he didn't provide unit tests yet .. etc, this is pending ..
20130427 21:30:10 <sgothel> (but he could use it in his game though, he claimed)
20130427 21:32:33 <xranby_ac100> ok, i will take a look at his work
20130427 21:34:45 <sgothel> I also earmarked a simple ULEB16 type of get methods in IOUtil, i.e. reading 16bit, 32bit signed or unsigned values from a stream in either: LE, BE or native-endian w/o using Buffer class.
20130427 21:35:09 <sgothel> this should unify the manual code in JPEGDecoder (it's in there), and ElfParser, .. etc
20130427 21:35:29 <sgothel> also WavParser in JOAL would need that, or has something already
20130427 21:36:01 <sgothel> ULEB16 SLEB16 would be most simple, 32bit depends how to swizzle thing - which may be different:)
20130427 21:36:34 <sgothel> ElfParser uses 'native endian' format, i.e. the platform endian format
20130427 21:37:40 <sgothel> thx a lot Xerxes
20130427 21:40:57 <xranby_ac100> sgothel: thank you, its good and healthy progress by all jogampers to resolve the plumbing issues
20130427 21:42:46 <sgothel> yes. and all the bug reports and forum replies really help widening the semantical coverage. such a complex project, you just cannot 'have it all' at once in your mind :)
20130427 22:18:26 <xranby_ac100> sgothel: i find the media player code fun and fashinating to study. like we mentioned at fosdem, if we can start use OMX on the raspberry pi it would speed up decoding a lot
20130427 22:19:46 <sgothel> sure .. would be sweet to resurrect OMX, it's for sure on the list .. and we make good progress to 2.0.2 I think - and fun doing it w/ you
20130427 22:19:59 <xranby_ac100> nice that the GLMediaPlayerFactory can be tuned to test available implementations in order thus we may check if the OMXGLMediaPlayer is avail before picking the fallback FFMPEG implementatino
20130427 22:20:29 <sgothel> ofc, hw-accel should be preferred
20130427 22:21:04 <sgothel> even though .. I suspect some hw-accel code is injected in libav/gstreamer somewhere as well .. hmm
20130427 22:21:16 <sgothel> (from Ti .. or others)
20130427 22:21:44 * xranby_ac100 adds OMX it to the GLMediaPlayerFactory list and test what happens
20130427 22:22:37 <sgothel> well well .. :)
20130427 22:22:48 <sgothel> opens door to lots of work I guess :)
20130427 22:24:43 <xranby_ac100> i second that : java: symbol lookup error: /tmp/jogamp_0000/file_cache/jln297002639117460009/jln3566792821811833529/libjogl_desktop.so: undefined symbol: OMX_Init
20130427 22:25:15 <xranby_ac100> jaja first step make sure it bail out nicely without taking down the jvm
20130427 22:43:16 <xranby_ac100> but this also calls for a test on the raspberry pi that should have this symbol loaded :D
20130427 22:45:09 <xranby_ac100> sgothel: i try to keep my github in sync to include minor fixes to the FFMPEG & OMX backend
20130427 22:45:28 <xranby_ac100> all rebased on top of the current jogl master
20130427 22:45:50 <xranby_ac100> i will keep rebasing untill merged
20130427 22:49:06 <xranby_ac100> This link gives a quite good view of what is going on in experimentation land https://github.com/xranby/jogl/network
20130427 23:07:22 * xranby_ac100 (~xranby@anon) Quit (Ping timeout: 256 seconds)
20130427 23:07:59 <sgothel> good night
20130427 23:10:47 * xranby_ac100 (~xranby@anon) has joined #jogamp
20130427 23:10:57 <sgothel> still there :)
20130427 23:11:12 <sgothel> I have ~3 hrs left for hacking :)
20130427 23:11:21 <xranby_ac100> yes, my computer locks up quite bad when runnign out of ram
20130427 23:11:51 <xranby_ac100> so i had to reboot.. the browser consumed to much memory while i was simultaniously compiling
20130427 23:12:00 <xranby_ac100> sgothel: cool
20130427 23:12:24 <xranby_ac100> still working on the xrandr thing?
20130427 23:12:26 <sgothel> http://www.commodore.ca/products/kim1/k1032_lg.jpg
20130427 23:12:38 <sgothel> 32k memory expansion module for c64 :)
20130427 23:12:40 <sgothel> yes
20130427 23:12:56 <xranby_ac100> thank you, all memory expansions are welcome
20130427 23:13:11 <xranby_ac100> .. thus i should enable swap on a usb drive
20130427 23:16:28 <xranby_ac100> 4g swapfile added on drive dh0
20130427 23:47:48 <xranby_ac100> writing notes to yourself what to do is a quite effective way to get things done
20130427 23:48:33 <sgothel> expressing things in words just itself often helps formulating better / clear thought :)
20130428 00:05:27 <xranby_ac100> ok one sub work item closer to audio with ffmpeg we now have a way to calculate the decoded buffer size used by the frame.
20130428 00:06:41 <sgothel> 'good to know' :) - nice
20130428 00:24:51 <xranby_ac100> sgothel: https://github.com/xranby/jogl/commit/7d7ebe01b8079ebf87fbf17a5b7b0f974b56c13d still quite a lot of boilerplate code to dynamically lookup one method symbol but hey cool that it work
20130428 00:26:26 <xranby_ac100> i plan to implement a similar OMXDynamicLibraryBundleInfo to check if the OMX_Init is available
20130428 00:26:52 <xranby_ac100> so that we can fallback to FFMPEG if OMX is not avail
20130428 00:26:58 <sgothel> I agree - this was the 'best' I could bring up in short time, i.e. to be flexible .. maybe we find a more beautiful way, however .. sufficient, especially the optional/variants stuff
20130428 00:27:11 <sgothel> buffer size .. will that vary ?
20130428 00:27:27 <xranby_ac100> i guess it depends on the codec?!
20130428 00:27:52 <sgothel> maybe .. so we need to take this into account for our n-frame buffers, i.e. dynamic resize if too small
20130428 00:28:36 <sgothel> usually audio is small, so you could use 2x buffer size always
20130428 00:28:47 <sgothel> video .. well, I frames are the biggest ofc :)
20130428 00:29:03 <sgothel> but video is no problem, since we dump it to GL right away
20130428 00:29:55 <sgothel> AFAIK libav does cache a few buffers to avoid alloc/free .. sure they must do
20130428 00:30:33 <sgothel> Note: you know the libav version for new function ? if so, pls add in the end
20130428 00:30:41 <xranby_ac100> libav also have to handle all the crazy bidirectional frames :)
20130428 00:31:01 <xranby_ac100> that can only be decoded when a future frame is avail
20130428 00:31:06 <sgothel> yup .. a bwd diff for rewind :)
20130428 00:31:27 <sgothel> oh
20130428 00:31:42 <xranby_ac100> thus we need to update the video frame code to check if there is more frames available inside the packet
20130428 00:31:57 <xranby_ac100> one packet may contain n frames
20130428 00:32:10 <xranby_ac100> I frame B frame P frame
20130428 00:32:27 <xranby_ac100> B frames are bidirectional and depend on both the I frame and the P frame
20130428 00:32:46 <sgothel> packet != frame
20130428 00:32:57 <xranby_ac100> correct
20130428 00:32:59 <sgothel> thought libav's 'frame' is one frame
20130428 00:33:22 <sgothel> isn't pAV frame oriented ?
20130428 00:33:26 <xranby_ac100> sure.. you extract one frame from the packet at a time
20130428 00:34:04 <sgothel> ay .. don't see whole code now, but yes ofc .. all frames of a packet .. so if we deal w/ a packet, must be cached then
20130428 00:34:37 <sgothel> to simplify the upcoming java thread collecting 'em
20130428 00:37:40 <xranby_ac100> are you familiar how to use the weaker references in java
20130428 00:37:41 <xranby_ac100> ?
20130428 00:38:08 <xranby_ac100> in order to create an efficient cache that can clear up automagically if the GC wants
20130428 00:38:11 <sgothel> well .. sort of .. GC can collect them, I don't like it :)
20130428 00:38:45 <sgothel> especially for embedded, I am old fashioned and hence like to use pre-allocated stuff .. and immutable :)
20130428 00:38:57 <sgothel> hence the fixed n-buffer frame idea
20130428 00:39:23 <sgothel> i.e. if start goes well, we shall stay that way and not increase 'that much' if at all
20130428 00:40:06 <sgothel> some players (libav has a method for that) .. do scan the media a bit to gather stats for buffers, etc ..
20130428 00:40:20 <sgothel> at least to get fps, .. so on and so forth
20130428 00:40:32 <sgothel> android does same
20130428 00:41:00 <sgothel> hence, we have to init stream, then we know whats going on and are able to allocate - we do this already AFAIK
20130428 00:41:11 <sgothel> (API wise)
20130428 00:41:41 <sgothel> if machine doesn't have space for 3 buffered frames .. well :)
20130428 00:42:02 <xranby_ac100> the usecase that may need larger caches is fast seeks
20130428 00:42:26 <xranby_ac100> we can worry about that in the future
20130428 00:42:33 <sgothel> oh .. seek operates differently .. you tell libav a new timepos
20130428 00:42:48 <sgothel> they manage the input-decoded-data cache themselves ..
20130428 00:43:00 <sgothel> we only deal w/ output ..
20130428 00:43:28 <sgothel> i.e. incoming frame we dispatch to decoder is alloced by libav
20130428 00:43:32 <sgothel> right ?
20130428 00:44:22 <xranby_ac100> right libav allicates the frame
20130428 00:44:50 <sgothel> // Retrieve detailed stream information
20130428 00:44:51 <sgothel> if(HAS_FUNC(sp_avformat_find_stream_info)) {
20130428 00:44:51 <sgothel> if(sp_avformat_find_stream_info(pAV->pFormatCtx, NULL)<0) {
20130428 00:44:51 <sgothel> (*env)->ReleaseStringChars(env, jURL, (const jchar *)urlPath);
20130428 00:44:51 <sgothel> JoglCommon_throwNewRuntimeException(env, "Couldn't find stream information");
20130428 00:44:51 <sgothel> return;
20130428 00:44:51 <sgothel> }
20130428 00:44:52 <sgothel> -> what I meant w/ gathering stats
20130428 00:46:35 <sgothel> if(sp_av_read_frame(pAV->pFormatCtx, &packet)>=0) { <- I see what you mean ..
20130428 00:46:53 <sgothel> packet is freed afterwards
20130428 00:47:35 <xranby_ac100> i had trouble with issuing a manual free of the packet
20130428 00:47:41 <sgothel> looks like a user shall loop 'till fails ?
20130428 00:47:52 <xranby_ac100> i got a double free :/
20130428 00:48:06 <xranby_ac100> so something in the audio decoder had already freed it
20130428 00:48:08 <sgothel> b/c sp_av_read_frame() looks like frame based
20130428 00:48:59 <sgothel> freed the packet ? hmm, or the frame [data] .. sounds familiar
20130428 00:49:53 <xranby_ac100> https://github.com/xranby/jogl/commit/8f76a78351b46533d81f4851d0d994e7c8dec0e0
20130428 00:49:56 <sgothel> AFAIK it relates who allocated the p*Frame
20130428 00:50:11 <xranby_ac100> line 693
20130428 00:50:17 <sgothel> I was reading libav source code to know :)
20130428 00:50:41 <sgothel> olala
20130428 00:50:55 <sgothel> but it worked for dealing w/ video only !
20130428 00:51:09 <sgothel> maybe skip only if dealing w/ audio .. hmm
20130428 00:51:25 <sgothel> sure it's packet double free .. and not the frame .. ? hmm
20130428 00:51:40 <xranby_ac100> not sure
20130428 00:51:47 <sgothel> 'pAV->pAFrame ' you allocated that one ?
20130428 00:51:53 <xranby_ac100> yes
20130428 00:53:27 <sgothel> fascinating
20130428 00:53:45 <xranby_ac100> its allocated inside the initialization function https://github.com/xranby/jogl/blob/8f76a78351b46533d81f4851d0d994e7c8dec0e0/src/jogl/native/libav/jogamp_opengl_util_av_impl_FFMPEGMediaPlayer.c#L487
20130428 00:54:03 <xranby_ac100> setStream0
20130428 00:55:42 <sgothel> right, like pAV->pVFrame. I guess there are diff. alloc methods in libav .. dunno
20130428 00:55:52 <sgothel> this one reuses internal memory AFAIK
20130428 00:56:08 <sgothel> (but .. quite long time ago I went through it ..)
20130428 00:56:49 <xranby_ac100> possible that our code may need to cleanup the frame in between uses
20130428 00:58:33 <xranby_ac100> sgothel: thank you for input, i will sleep on it and think about the threaded vframe cacher
20130428 00:58:52 <sgothel> good night
20130428 00:58:57 <xranby_ac100> good night
20130428 01:00:40 <xranby_ac100> sgothel: btw sp_av_read_frame is a confusing named function because what it do is reading a packet from the container
20130428 01:01:23 <sgothel> hmm .. so loop till eop then ..
20130428 01:02:44 <xranby_ac100> yes i will try update the video code to loop and decrease the packet.size and increase the packet.data in between decode runs so that i can extract all frames from the packet
20130428 01:03:03 <xranby_ac100> similar to how the audio loop work right now
20130428 01:03:30 <xranby_ac100> the libav decode api examples also recommend this kind of loop
20130428 01:03:48 <sgothel> looking fwd to it .. nice
20130428 01:04:50 <xranby_ac100> no problem, cheers, fun hacking
20130428 01:05:00 <sgothel> cheers
20130428 01:05:01 <xranby_ac100> good night and sleep well
20130428 01:05:10 <sgothel> u2
20130428 02:26:14 * [Mike] (~Mike]@anon) has joined #jogamp
20130428 04:03:57 * DemoscenePassiv (~Lutsche@anon) has joined #jogamp
20130428 04:24:13 * DemoscenePassiv (~Lutsche@anon) Quit (Ping timeout: 256 seconds)
20130428 05:06:42 -CatOut- Continue @ http://jogamp.org/log/irc/jogamp_20130428050642.html