Personal tools
You are here: Home development IRCMeetingJulyTwo

<IOhannes> right
<holzi> ok, maybe then its better to use no exceptions
<matju> holzi: actually imho it's better to have that abstraction layer, considering my plans to redesign the errors system in pd, so that pd patches can actually receive error messages *and* understand them without any parsing.
--- nicb is now known as nicbafk
<matju> aalex: PDP is written in C.
<aalex> oh, ok
<aalex> IOhannes, hi
<holzi> matju: I was away and have not read your plans yet, so what does this mean for us ?
<matju> aalex: well, there are things for which C is really not worth it, and in that case, there'd be no point of supporting C; but for this project, supporting C is not only nice, it's required.
<aalex> I see....
<matju> aalex: however there are ways to make C wrappers for C++ libraries. a C++ library needs not have to be bogged down because "C is more standard" or such.
<aalex> right. a C++ lib can be used in a C prog
<matju> holzi: i have not fully stated my plans about errors yet. (there are limits to monologuing on pd-list)
<matju> holzi: (or pd-dev)
<holzi> ok, error reporting: only return values or also pds error ?
<holzi> matju: ok, I will read it
<matju> holzi: read what?
<holzi> pd list
<matju> holzi: i haven't written it on pd-list or pd-dev
<holzi> ok, then I won't read it ;)
<matju> holzi: actually, i may have mentioned the idea in 2006 or 2005, but without any reply.
<matju> holzi: i'll tell you:
<matju> holzi: if there is a "file not found" problem, for example, instead of error("file not found: '%s'", filename), you'd have an anything-message in which s="filenotfound" and $1=filename
<holzi> ok, and why ?
<matju> holzi: so that a patch can handle "filenotfound"
<matju> holzi: but assuming that a C++ FileNotFound exception is an object that has an attribute that is the filename, it becomes easy or easier to support that system if available, or pd's system by converting to string using some kind of virtual toString().
<holzi> ok, I see, however, so again, do you think that it would be better to use error ?
<matju> holzi: error() rather than...?
<matju> holzi: it's better to use error() rather than post(), for errors.
<holzi> only return values
<holzi> post would also be in m_pd.h
<IOhannes> because a word says more than a thousand numbers...
<holzi> thats true ;)
<matju> holzi: at the moment it's better to use pd_error() rather than error(), though my idea is to change error() so that pd_error() becomes obsolete.
<holzi> yeah, however, I mean one error function from m_pd.h
<matju> IOhannes: if all words are numbered, a word says as much as a single number, but i wouldn't like to number all words (not any further than what the ascii code already achieves...)
<holzi> so now I would say yes
<matju> holzi: supposing everything is done geared towards today's Miller's pd. then the best is to use pd_error().
<IOhannes> matju, i have not been waiting for something along this...
<holzi> yeah - so we will include m_pd.h and use pd_error !
<holzi> now threading ;)
<IOhannes> just a sec
<matju> IOhannes: i mean that a long enough enum{} does the job, but the problem is that the enum{} has to be maintained and that it's not worth it on today's computer.
<IOhannes> matju, i know what you meant...(probably)
<IOhannes> using exceptions we can have both a message (string) and an error-code (number); which would then (by the parent class) be translated into a pd_error()
<IOhannes> or whatever; just keep stuff abstract enough
<matju> IOhannes: i remember too well getting ERROR#216 from Microware's OS and having to swap diskettes so that I could type the error database query "error 216" which would tell me what it is. Then if i made a mistake doing that, I'd get another numbered ERROR, so i'd get stuck.
<IOhannes> so should we use words (as in "dictionary"!) or numbers?
<matju> IOhannes: imho, error numbers at this point are useless. the only reason they'd be used in new APIs is by compatibility with old-school C programmers.
<IOhannes> you are most likely right; however using a more abstract concept (like exception) allows us to have whatever we pick of all worlds.
<matju> IOhannes: words, or series of words... anything you can feed to gensym.
<IOhannes> ok, i think we are all in-line here
<IOhannes> so let's move on to threads...
<holzi> yep
<_thomas_> IOhannes: another thing, do you think we should use gstreamer in any way or not?
<_thomas_> (yust to throw it in)
<IOhannes> just to recapitulate (for those who have not had the joys of living in graz...):::
<matju> IOhannes: internally, VideoIO can use threads like various pd externs already do, as long as they don't have anything to do with m_pd.h
<matju> IOhannes: once you reach m_pd.h with threads, you have to make sure you're being threadsafe.
<IOhannes> the question was: should the API encapsulate threads
<IOhannes> or should the host take care of that?
<holzi> matju: I thought that the threading should be done in the host application (like e.g. in GEM) and the framework is not threaded
<IOhannes> i used "API"  is in a  synonymous way to "framework"
<matju> IOhannes: in what way does the host pickup the data?
<holzi> matju: you get frames
<IOhannes> it calls a function in the plugin: getFrame()
<IOhannes> or something like that
<matju> holzi: one complete frame at a time?
<_thomas_> yes a complete frame
<IOhannes> at least that was the idea
<IOhannes> tadaaa...and now come the cache optimizers::
<IOhannes> (don't wait for me...)
<matju> one characteristic of GridFlow is that it does not need to use complete frames at a time, though in practice this is rarely used for IO because other libraries tend to work with full frames only.
<IOhannes> which IO-libs do support partially frames?
<_thomas_> i'm sorry, i have a rehearsal and have to leave now. but i will read the records afterwards...
<IOhannes> just a last word, _thomas_ : gstreamer would be cool as a plugin; why not use it?
<matju> IOhannes: i don't think that there are any, except those that have to do with interlacing, but GridFlow doesn't support interlacing as a way to get a partial frame.
<matju> _thomas_: does it happen every monday?
<_thomas_> okay
<_thomas_> for me it would be ok
<IOhannes> _thomas_, do you rehearse every monday?
<holzi> no, just today
<matju> i had a last word too: why would VideoIO need to be put in a host? could it work with GEM and with GF in the same patch?
<IOhannes> _thomas_, ok, so let's meet next monday same time same place again
--> federico__ ( has joined #dataflow
<IOhannes> matju, does "host" imply an exclusive usage?
<matju> IOhannes: i agree with next monday 18:00 UTC, but i don't know whether the others would.
<IOhannes> i haven't thought so?
<matju> IOhannes: i don't know
<holzi> hm, IOhannes and matju, can we email again about next monday because thomas is already away
<matju> IOhannes: i mean i don't know about what "host" implies yet.
<IOhannes> ok; i just use "host" for the "application" (Gem, GF, pdp) that wants to use the frameword
<matju> holzi: ok
<IOhannes> holzi, ok
<IOhannes> :-)
<holzi> matju: GF and GEM could link both to those plugins
<-- Mnabil_work has quit (Remote closed the connection)
<matju> holzi: what about colourspaces? (that's the next topic)
<IOhannes> so should threads be in the "host" or in the "plugin"?
<holzi> matju: I thought about that the framework only gives the colorspace of the movie, so the conversion should be done in the host
<aalex> do you guys plan to make this as an external that every host can "understand", or as a set of functions?
<aalex> i guess the latter
<IOhannes> (where the "plugin" can inherit threading capabilities from the parent class)
<holzi> aalex: it should be a video input/output framework for GEM, GF and maybe also PD (file, stream, firewire, ... writing and reading)
<IOhannes> aalex, yes
<matju> actually, we can continue the meeting as long as the people who left can get back on that topic at the beginning of next meeting
<aalex> holzi, you're the one that is doing the google SOC?
<holzi> I have some more time, so lets continue ;)
<matju> and as long as it makes sense to brainstorm with the remaining people.
<holzi> aalex: no, my brother
<aalex> not really?
<aalex> :) 
<holzi> aalex: no, I am only little bit thinking about it - but I won't do the coding actually
<matju> holzi: "conversion should be done in the host" is the bane of Video4Linux, and already GEM/PDP/GF cover a bunch of different colourspaces.
<IOhannes> aalex, i think of it as a number of binaries which are all loaded at once (which doesn't imply that it must be "only-once") and which register themself as e.g. a "stream in plugin"
<holzi> matju: yeah, but also GEM/PDP/GF already have routines for the conversion ?
<matju> holzi: *which* conversions in particular?
<aalex> threading : does that imply that if the pd "scheduler" is full, the frame rate would go down automagically ? (as in Gem and J1tter) 
<holzi> matju: YUV2RGB and etc
<IOhannes> aalex, then Gem/GF/pdp/... can just ask whether one of the registered plugins finds itself fit to handle a certain connection string. e.g. "rtsp://"
<matju> holzi: which version of YUV ? which version of RGB, even?
<aalex> IOhannes, nice design. a set of pd_linux, or so (.so) 
<IOhannes> aalex, yep!
<matju> holzi: RGB can be 2:3:2, 5:5:5, 5:6:5, 8:8:8, 16:16:16, 32:32:32
<holzi> matju: yes, GEM/PDP/GF have already implemented all these conversions (at least GEM) - so why code it once more ?
<aalex> holzi, or why code it only once :) 
<holzi> (all different kinds of YUV)
<IOhannes> aalex, because it has been done already
<matju> holzi: YUV can have various numbers of bits too, but also signed vs unsigned, macropixels, and "video-style" vs "JPEG-style".
<IOhannes> aalex, and so you can choose the exact  flavour of color conversion
<IOhannes> holzi, it is an illusion to believe in _all_
<holzi> matju: I know, IOhannes: of course ;)
<holzi> what do you think IOhannes about the color conversions ?
<IOhannes> and even more: what about byte, int, float? (regardless of the colorspace)
<matju> holzi: well, so far, i'm not convinced that GEM can support PDP's YUV... can it really?
<IOhannes> why should it?
<IOhannes> there are 2 things:
<matju> IOhannes: yes, GF supports float RGB images, and I actually *use* that feature, and that's part of one of my pdconvention papers for 2007.
<holzi> matju: I don't know which YUV version pdp supports, but it's possible to convert between the two
<IOhannes> ... two things: speed vs. ease-of-use
<IOhannes> i think we should support both:
<matju> holzi: are we thinking about converting in the simplest way possible, or converting in the fastest way possible?
<IOhannes> a) allow the host to enforce a certain format it needs
<matju> IOhannes: ok, we're thinking the same thing at once.
<holzi> matju: simplest way ;)
<IOhannes> ... (probably from a small set of available formats)
<IOhannes> b) present the data in the "natural" format
<IOhannes> (which is fast as it doesn't need any conversion; and probably the host can make sense of it on its own)
<matju> holzi: so are you ok with multi-step conversions that disadvantage PDP and GF but not GEM because GEM wouldn't need the extra step because of the particular combination of converters included in VideoIO ?
<holzi> IOhannes: why? at least in GEM there are already the conversion routines (I guess also in GF/PDP) ...
<IOhannes> matju, ?
<matju> holzi: GF/PDP have different conversion routines than GEM has.
<holzi> matju: hm, I don't really understand you - if pdp uses yuv and the video is in yuv there won't be an additional conversion ?
<matju> holzi: which kinds of yuv ?
<holzi> matju: don't know
<holzi> yet
<IOhannes> the conversion might be less about muladds but about copying, rearranging,...
<IOhannes> with modern computers this can be the most demanding task...
<matju> converting between various flavours of macropixels can also involve decisions about interpolation
<matju> i don't mean decisions during one conversion, nothing to hurt the pipeline, but just to decide in advance how a reduced frame has to be reinflated to a bigger size, and vice-versa.
<matju> and if interpolation (of order above 0) is used, then this requires muladds.
<holzi> yes but IMHO this is not the job of this framework
<matju> converting from "video" yuv to "jpeg" yuv is also a muladd job
<IOhannes> (everything is a muladd job somehow...)
<holzi> ;)
<matju> though in either case this is not muladds across channels, so at least it's not that kind of trouble.
<IOhannes> holzi, you think the framework should NOT be able to do any conversions?
<matju> holzi: if it's not the job of this framework, then that framework still has to be providing video in *some* format, and if you pick GEM's format, then you're making VideoIO primarily for GEM.
<rdz> sorry, does 'muladd' mean 'multiplication and addition operation' or similar?
<IOhannes> rdz, yes
<holzi> matju: I meant colorspace conversions
<matju> holzi: i'm talking about colorspace conversions.
<IOhannes> problem is: all those libs that could be utilized by the framework do have different colorspaces
<matju> holzi: if it's not the job of this framework, then that framework still has to be providing video in *some* colorspace, and if you pick GEM's colorspaces, then you're making VideoIO primarily for GEM.
<IOhannes> (yes, RGB24 might be quite common, but there are loads of others)
<holzi> matju: I meant providing the video in the colorspace it is (e.g. a YUVsomething video in YUV, a RGB video in RGB, ...)
<holzi> matju+IOhannes: but this was only my idea so far, so maybe this does not make sense ...
<IOhannes> have a look at to get an impression of what "RGB" means (or "YUV")
<IOhannes> so matju, what is your idea to make it "optimal"?
<IOhannes> how does GF wants the data presented?
<holzi> thanks for the link
<holzi> matju: yes, how does GF wants the data ?
<matju> you can configure [#in videodev], the camera input, so that it provides RGB 0-255 or YUV 0-255 or Greyscale, but that information may be presented as bytes, shorts, ints, "longs" (64-bit) or floats or doubles.
<holzi> so this sounds quite similar to GEM ...
<matju> holzi: GEM doesn't support non-byte values, does it?
<-- eerne ( has left #dataflow
<holzi> matju: no, but the same colorspaces AFAIK
--> eerne ( has joined #dataflow
<holzi> pdp also needs bytes I think ?
<matju> holzi: ok, depends on what "colorspace" means, what's the scope of that word.
<matju> holzi: i'm pretty sure that PDP's YUV is based on shorts, isn't?
<holzi> i am looking ...
<matju> errata: isn't it?
<IOhannes> matju, holzi it is
<matju> IOhannes: it is shorts?
<IOhannes> afair, it is
<matju> IOhannes: he explained it in pdconvention, but that was a while ago
<matju> IOhannes: and i'm not even sure whether he stated that during his presentations or while having beers with us
<IOhannes> yep; iirc, U&V are signed shorts (which makes everything a lot simpler)
<holzi> IOhannes, matju: however, I think it should be bytes in the framework
<matju> IOhannes: yeah, unsigned values really suck the principle out of UV.
<matju> holzi: because GEM uses bytes.
<holzi> and GF
<holzi> and I don't know if someone ever includes it into pdp
<matju> holzi: GF's bytes are optional. on average people use ints in GF.
<IOhannes> that's a bad reason.
<holzi> matju: ok, then its different
<matju> holzi: PDP doesn't look like the framework is gonna be much modified ever again.
<holzi> IOhannes: of course you are right
<IOhannes> nevertheless i think it is true that most non-packed formats _are_ using bytes
<IOhannes> (even though Gem is also using em...)
<holzi> matju: it dont know what you mean
<matju> holzi: <holzi> and I don't know if someone ever includes it into pdp
<matju> holzi: what does that line mean?
<holzi> matju: you mean pdp won't be modified or the videoIO framework won't be modified again ? I guess you mean the first one - then yes, that's what I thought.
<matju> holzi: i mean: the PDP framework doesn't look like it's going to be modified ever again
<holzi> yep
<rdz> matju, does that mean that pdp won't ever make us of a future videoIO?
<holzi> so, matju, do you think bytes are okay for gridflow ?
--- nicbafk is now known as nicb
<matju> rdz: no, it means that VideoIO support would be as a plugin, not as a modification of the PDP framework itself.
<IOhannes> sorry guys, i think i have to leave now
<matju> holzi: bytes might be okay.
<IOhannes> (as you probably have noticed i got quieter and quieter)
<rdz> matju, but still, someone needs to make that plugin work in pdp, right?
<matju> IOhannes: see you next monday (prolly)
<IOhannes> apart from that, bytes are most likely the simplest way to go
<holzi> I have to leave too unfortunately, but I will write a mail about the next meeting !
<matju> rdz: yes, someone would have to, and Tom might do it if it's not too much work
<IOhannes> rdz, yes; but that shouldn't be too complicated; it is just somebody has to do the work
<holzi> matju: ok, so lets say bytes for now - if you have further rejections just mail ... ;)
<matju> holzi: ok.
<IOhannes> ok, good night everybody, everywhere...
<-- IOhannes ( has left #dataflow ("snoozing")
<holzi> sercus IOhannes !

Powered by IEM Powered by Plone Section 508 WCAG Valid XHTML Valid CSS Usable in any browser