Log from #neuros IRC channel

<swoag>

before we dive into the osdmain refactoring discussion, got a quick question,

<swoag>

does anyone have experiences with Gstreamer?

<Ycros>

I've messed with it

<Ycros>

not too much on the programming side

[10:19]

<crweb>

I have a little.

[10:21]

<swoag>

how mature is it? for example, what type of file parser plugins does it support?

[10:21]

<crweb>

i don't really support things by the gnome foundation. Also, gstreamer is known to have an ABI that just changes to often

[10:21]

<swoag>

ABI?

<Ycros>

I don't think gstreamer is done my the gnome foundation, it's developed by fluendo

<crweb>

Ycros: its the connection to freedesktop that i really dont' like much. And the influence of gnome devs on gstreamer

<Ycros>

primarily anyway

<Ycros>

I know quite a few gstreamer developers in person

<crweb>

swoag: application binary interface

<Ycros>

it's much better now than it used to be

<Ycros>

what's wrong with freedesktop?

<Ycros>

anyway.

<crweb>

Ycros: not now.

<Ycros>

crweb: I agree, thus "anyway."

<Ycros>

swoag: are you looking to use it to parse container formats?

<swoag>

Just wondering if it is a good idea to use Gstreamer to replace NMS...

<Ycros>

probably not

[10:25]

<Ycros>

infact no, not with the way your codecs work

[10:25]

<crweb>

swoag: yeah, not with the codec kernel modules

[10:25]

<crweb>

swoag: having the codec kernel modules, you already have 90% of what gstreamer is.

[10:26]

<swoag>

from what I understand, Gstreamer is really a light framework to provide a high-level abstraction for

[10:26]

<swoag>

multimedia funcitons.

[10:27]

<swoag>

thus it is basically doing what NMS does, well more because it also handles the A/V sync for example.

[10:27]

<Ycros>

swoag: basically, gstreamer has the concept of elements and building pipelines out of elements

[10:27]

<Ycros>

elements can be anything like sources, codecs, effects, sinks (destinations)

<Ycros>

and you can chain them together

<Ycros>

it does do sync and a whole bunch of other stuff which I haven't looked into in great detail

<Ycros>

I don't think that's going to help you

<swoag>

Ycros, crweb: has any of you played with its plugins?

<Ycros>

don't you feed the dsp a file, container and all?

<crweb>

swoag: that what i meant. the plugins, are codecs

<Ycros>

I've played a bit with plugins, and building pipelines

<Ycros>

but not much

<Ycros>

managed to get a simple shoutcast relay going using the gst-test cli tool

<swoag>

crweb, I guess plugins cover more than codecs.

<crweb>

swoag: there are other plugins but stuff for alsa, firewire, etc

<swoag>

again, my guess would be at least 3 types of plugins,

<swoag>

codec, HW, and file parsers --- for decoding pipe line

<crweb>

swoag: if you were going to use gstreamer, you'd probably create a nms plugin that handles all file types

<Ycros>

swoag: and effects I think as well

<Ycros>

aye

<Ycros>

you'd have one element which wraps the dsp

<Ycros>

and then everything else can work around that

<Ycros>

that would make sense, but I'm still not sure what you want to get out of gstreamer that you don't already get

<crweb>

but the only benifit really would be that, you have the gstreamer api

<Ycros>

hmm k

[10:32]

<crweb>

which isn't much of a benifit since the binary interface is what causes so many problems for developers

[10:32]

<Ycros>

you do get access to demuxers

[10:32]

<Ycros>

crweb: I think it's fairly stable now

<Ycros>

crweb: but I could ask the gstreamer devs about it

<Ycros>

also, you gain interesting network streaming plugins

<Ycros>

... subtitle parsing... do we do subtitles?

<crweb>

Ycros: that gets a little more complicated

<crweb>

Ycros: cause your media handler/codecs would have to support the streaming

<Ycros>

tag parsing

<Ycros>

I'm just scrolling through the gstreamer elements and mentioning anything that seems might be useful

<swoag>

Using Gstreamer at least provides us more standard programming APIs (their element/link/pipe model seems very flexible),

<swoag>

and provides us more file format support out of box.

[10:35]

<crweb>

swoag: whats the benifit with support more file formats if the dsp can't play them?

[10:35]

<swoag>

say there is a .XYZ file that contains MPEG4 video and MP3 audio, if Gstreamer has that support, we'd just use it out of box.

<Ycros>

yeah

<Ycros>

swoag: I don't think you're going to be able to easily integrate it

<swoag>

Ycros, why?

<Ycros>

because of the way the codecs work

[10:37]

<Ycros>

then again... hmm

[10:37]

<swoag>

what happens if we 'can' wrap the Codecs in V4Linux or OSS interface?

[10:38]

so on the OSD the A/V sync problem is not due to the codecs but due to NMS?

<swoag>

sourcerror, A/V sync problem is not due to the codecs, nor because of NMS

<swoag>

sourcerror, problem is from the middle layer between NMS and the codecs

<Ycros>

I don't really know how you feed data to the codecs, I think someone once mentioned you just point them at a file, but I could be wrong

ingenient layer or neuros layer?

<Ycros>

swoag: who's layer is that?

[10:40]

<swoag>

and I am thinking to ditch that middle layer (vendor proprietary) and switch to Gstreamer.

[10:40]

ah.

[10:40]

<crweb>

swoag: well, theres no gstreamer plugins that will work with our dsp

[10:41]

<swoag>

crweb, sorry, I wasn't clear on the question,

[10:41]

<swoag>

this question is actually a question for OSD2.0. ;-)

[10:41]

<crweb>

swoag: oh, well you won't have to work much. davinci already has gstreamer support is what i hear

[10:42]

<Ycros>

crweb: no, but I think the idea is we wrap ours, and then use all the other interesting bits

[10:42]

<swoag>

crweb, sort of. that is why I want to see what you guys think.

[10:42]

<Ycros>

swoag: oh, osd 2.0

[10:43]

<Ycros>

that's different then

[10:43]

<Ycros>

I haven't heard anything about the 2.0 (I've been busy and not here for quite a while)

<swoag>

anyway, just wanted to get some quick thoughts on Gstreamer,

<swoag>

let's switch back to osdmain refactoring?

<Ycros>

well, I like gstreamer

wiki.neurostechnology.com

<Ycros>

:P

[10:45]

<crweb>

swoag: it would be a good step. It is a good project.

[10:45]

<Ycros>

okay, osdmain refactoring

[10:46]

<swoag>

so, what are the major points in regard to that? can someone summarize?

[10:46]

<swoag>

(or I should look at the wiki page? looking...)

[10:46]

<crweb>

[10:47]

<crweb>

they pretty much covered all my points before i got to write them down :)

[10:49]

<swoag>

as I am reading,

[10:49]

<swoag>

MVC, yes, that is the implementation model.

[10:50]

<swoag>

however, from my limited Java experience, MVC is good in theory and hard to achieve in practice,

[10:51]

<crweb>

swoag: MVC is in qt, gtk, java, etc nowdays

[10:51]

<swoag>

separating V from MC is good enough, I guess.

[10:52]

<Ycros>

swoag: implementations differ slightly

[10:52]

<Ycros>

I know java does it a bit differently

[10:53]

<swoag>

Ycros, ya, and that is what I referred to.

[10:53]

<Ycros>

(assuming you're talking about the way swing does it)

[10:53]

<crweb>

doc.trolltech.com

[10:54]

<crweb>

i've been using mvc a lot in qt lately, i like it a lot.

[10:54]

<Ycros>

the view and controller in swing are collapsed into the same class

[10:55]

<Ycros>

hehe

[10:55]

<Ycros>

but that's irrelevant

[10:55]

<Ycros>

I guess

<Ycros>

crweb: oh, I see qt does it too then

<Ycros>

makes sense in the case of gui components

and even if they are in the same class you can have separation of data model even if it is an api to r/w data structures. it allows multiple access to the model.

<swoag>

I personally think it is crucial to separate the view part out, as long as MC part is done in OO way, porting/expanding is pretty easy.

<Ycros>

aye

[10:57]

<crweb>

i agree.

[10:57]

<swoag>

strictly applying MVC to each piece of the project will do nothing but slowing down the development significantly. ;-)

[10:58]

hmm...

[10:58]

<crweb>

well, qt compbines the vc which makes sense to me, but i use it regularly

[10:59]

<swoag>

alright, we settled on this one then.

[10:59]

<crweb>

models shouldn't have controls. the controls can change depending on the view.

[11:00]

<swoag>

moving forward to Nano-X WM...

[11:01]

<swoag>

I am not working on it any more, but yes, it will be in place.

[11:01]

<swoag>

- Split into multiple apps

[11:02]

<swoag>

to start with, we might take Media player out first.

[11:03]

<swoag>

- Abstraction for config/setting scrns

[11:04]

<swoag>

This may be something down the road, the Graphic designer is still actively changing the GUI,

[11:05]

<swoag>

those that are sharing similar looking today may change tomorrow.

[11:05]

<swoag>

thus a generic config/settings scrn may not worth the effort?

[11:05]

<crweb>

swoag: was the abstraction for configure screens, or config functions?

[11:06]

<swoag>

idea was from sourcerror, thought he meant the scrns?

[11:06]

<crweb>

swoag: qt has a nice settings interface where you have a settings object and just use setValue("key","value")

[11:06]

I meant that you can abstract creating a screen with a list of settings...

just feed it a data structure and you have any number of config screens you want.

<swoag>

sourcerror, that is what I understood, but as I explained, not many of them share the same looking.

have different kind of data types INT, STRING, IPADDR, DOUBLE, ...

MEDIA_PATH, MEDIA_DEVICE

TIME, TIME_DATE

<crweb>

those really aren't going to be useful outside of the main app though

<Ycros>

it's another model/view abstraction

yea any sub-app could use it for quickly creating a configuration and not even need to write much Controller View code.

[11:09]

grok MVC :)

[11:11]

<cr-tablet>

what was the last thing i said?

[11:12]

<swoag>

cr-tablet == crweb?

[11:12]

<cr-tablet>

oh, yeah

[11:12]

<crweb>

not sure what happened

[11:13]

<swoag>

to abstract on the MC layer for all those settings?

[11:13]

<swoag>

I believe that is what you meant, crweb?

[11:14]

<crweb>

basically

[11:14]

<crweb>

we can't predict every setting a developer may want to use

[11:14]

<crweb>

and each app will be different....

[11:15]

<crweb>

we'd never beable to provide enough key's in the data structure to make it a useful system

[11:15]

<crweb>

which is why most go for a developer supplys a key string, and T value

[11:16]

no keys. you don't predict all settings. you create a data structure that lists different setting types, label, and a pointer to where to write the data back to. { type, label, &value } Pass a list of these to a config screen that accepts it and builds the screen. It can even manage splititng it into multiple pages.

[11:16]

<crweb>

you're still not going to predict the format of every setting that needs to be viewed

[11:17]

some things are custom if you want to get fancy. But the OSD should have a similar look and feel for most things anyway.

[11:17]

<crweb>

i don't think it should

[11:17]

<crweb>

the osd should across its own apps

different argument. we were talking about OSDmain and sub apps that want to play along wiht the look and feel provided.

<crweb>

but i don't see this being useful to the community, as they probably won't look like the osd apps to begin with

<swoag>

most of the duplicated code really is because of the widget,

<crweb>

community apps i mean, probably won't look anything like the osd apps, so why should thier settings screens?

<swoag>

FRAME is currently not able to manage focus for its children,

[11:19]

<swoag>

that is why most of the duplicated code comes from.

[11:19]

<swoag>

it is in the plan to fix that.

[11:19]

swoag: but this can also manage layout which is good right?

[11:20]

<swoag>

layout management will probably not be part of the support.

[11:21]

<crweb>

drawing the config screen shouldn't be complicated enough to warrant an autogenerating system

[11:21]

no I mean abstracting a config screen maker will do the layout and this is good, right? even less boiler plate code.

[11:21]

<swoag>

anyway, config/settings refactoring may not seem that important as soon as settings becomes a standalone app.

[11:22]

<swoag>

let's move on to the cooler part?

[11:22]

you get consistency and simple abstraction for repetitive (read 'error prone') copy paste code.

[11:22]

<crweb>

sourcerror but its not repedative. You only need 1 ip address config screen

[11:23]

I can't convince you of the value of abstractions.

[11:23]

<crweb>

sourcerror: auto generation of screens isn't abstraction though.

[11:24]

<crweb>

swoag: yeah, the seperation of libs into parts is my major push

[11:24]

<swoag>

alright,

[11:24]

<swoag>

- Splitting cooler

[11:25]

<swoag>

how about splitting it into 3 parts?

[11:25]

<crweb>

swoag: gui code shouold be in gui libs, media code in media libs, network code in network

[11:25]

<swoag>

nmc, utility, nx

[11:26]

<swoag>

actually, IMO, or in the MC-V view, we only need to split it into two parts,

[11:26]

<crweb>

swoag: i was thinking: cooler-media(nms, IR blasting, scheduling), cooler-gui (widgets, layouts etc),

[11:26]

<swoag>

utility and nx

[11:27]

<crweb>

swoag: well the more parts the better, lets us develop without having aspects we dont' need

[11:27]

<swoag>

splitting cooler further may get us confusion in the future, or get us into an endless-splitting situationg? ;-)

[11:27]

<crweb>

i don't think it will. most toolkits are split like this

<swoag>

today cooler-media contains nms, IR, scheduling,

<swoag>

tomorrow, IR grows, and we need a cooler-IR lib?

<crweb>

swoag: i mean, if my firmware doesn't need cooler-gui then i don't have to put it on flash.

<crweb>

swoag: no, you name by system. not by feature

[11:29]

<swoag>

crweb, ya, isn't good enough to have two systems? utility and gui?

[11:29]

<swoag>

GUI is really the biggest problem of current cooler, I think.

[11:30]

<crweb>

for example, qt-core (non-gui code like QString, QSettings, etc), qt-sql (sql abstrations) qt-gui (widgets), qt-network( tcp, udp etc)

[11:30]

<crweb>

swoag: well, kinda. 3 would be better

[11:30]

<crweb>

swoag: multimedia is a system, and gui is a system. so where do we put things like custom data structures that aren't media, or gui?

[11:31]

<crweb>

but they are still useful

[11:31]

<crweb>

say, cooler's functions for using samba

[11:31]

<crweb>

you could throw it in to cooler-media.. however, that would make me duplicate a ton of binary code as, other toolkits have samba support

[11:32]

<crweb>

i should beable to use the media system, and expect to only have the media system

[11:32]

<crweb>

especially with it being embedded

[11:33]

<swoag>

what is your suggestion again? media, gui, and?

<crweb>

i dunno. cooler-core

<swoag>

and core contains?

<swoag>

everything else?

<crweb>

stuff like.. settings structures

<crweb>

code that is used in gui's but isn't actually widgets

<crweb>

but could be useful to other toolkits

Maybe a cooler-extra if necessary later?

<crweb>

like the settings i talked about

<swoag>

well, I really think most settings belong to osdmain.

<crweb>

swoag: you're still thinking osdmain

<crweb>

swoag: you are building a toolkit for other devs to use

[11:36]

<crweb>

swoag: pretend there is no osdmain. How is osdmain going to write and read to a settings file?

[11:36]

<swoag>

crweb, understood, but depending on what level you want to put this support at.

[11:36]

<crweb>

i'm not talking about showing the settings

<crweb>

the level i want it at is, a developer could call readsetting(x);

<crweb>

and have the info

<swoag>

in my view, cooler only provides you the basics to help build _your_ SW, while osdmain is _the_ shipped SW from Neuros.

<swoag>

thus anything that is specific to osdmain does not need to be exposed into cooler.

<crweb>

swoag: right. why can't we share a settings structure between the two?

<crweb>

swoag: osdmain should just be widgets

<crweb>

swoag: which is the entire point of this discussion. The toolkit should have the common tools.

<swoag>

I don't agree with you there.

<crweb>

thats why its called a toolkit

<crweb>

swoag: well, my statement is a little extreme, obviously there is logic code and stuff in osdmain

<swoag>

Take OSD as a PC for a moment, osdmain will be the default Media player,

<swoag>

most of the settings for this media player shall not be exposed, IMO.

<swoag>

in stead,

[11:40]

<swoag>

cooler provides you support to access your HDD, network, multimedia HW, and a GUI toolkit etc.

[11:40]

<crweb>

swoag: again i think you're thinking to specific

[11:41]

<crweb>

swoag: a settings doesn't actually have "any settings"

[11:41]

<crweb>

its just a interface for developers to use to easily read and write a file that stores settings

<swoag>

crweb, no, I am not only referring to specific settings (like playmode),

<swoag>

but also the way you store away the key/value pair,

<swoag>

to me it is an osdmain layer shared code.

<crweb>

i don't think theres anything wrong with providing an interface to easily read and write settings in cooler that developers can use to easily write/read stored info

[11:43]

<crweb>

swoag: osdmain settings sure. but whats under those settings, where are they stored? In a file? with key,value? why should every application written have to write a parser and writer?

[11:43]

<swoag>

obviously it is a vague line to draw. we surely can pulling that out to cooler, I just want to limit cooler to more HW specific code, or platform code,

<swoag>

for example, what if you don't like the key/value approach?

<crweb>

swoag: it doesn't matter, the developer never sees the key/value

<crweb>

swoag: and if he/she doesn't like it, then it doesn't "have" to be used

<crweb>

its a toolkit.

[11:46]

<crweb>

if you're going to limit it that much to only HW and only platform stuff that is useful for building osdmain, i don't think its fair to call it a toolkit. nor can we expect developers to really grasp it as a viable system to develop with

[11:47]

<crweb>

you are right osdmain has its own settings, for playing etc

[11:47]

<crweb>

but why can't osdmain save/read from the cooler provided settings file interface?

[11:47]

<swoag>

no, no reason cant.

[11:48]

<swoag>

as I said, it is a vague line to draw at,

[11:48]

<crweb>

as long as it doesn't spill into providing "exact" settings. i don't think its to vague..

[11:48]

<swoag>

key/value settings is not a good example (I think it'd be better moved up to cooler),

<crweb>

well thats all i'm talking about. Just functions for writing and reading from file.config that is a file that uses the same format as the read/write functions

<swoag>

what I am saying is I don't think it is a good idea to move all osdmain shared code (currently under src/system, and src/settings) up into cooler.

<crweb>

right, i'm talking about tools

<crweb>

i could care less about what varilable and values osdmain uses for something

[11:51]

<swoag>

so, back to the splitting.

[11:51]

<crweb>

library code: store this value in this key in y file

[11:52]

<crweb>

yeah, so something like that would be in cooler-core

[11:52]

<crweb>

its non-gui and non-media

[11:52]

<crweb>

just simple library provided to ease development

[11:53]

<crweb>

and as Shadow12 suggested maybe one day an extras

[11:54]

<crweb>

which is just stuff that that is used in osdmain or other apps that could be useful for other apps

[11:55]

<swoag>

alright, let's start with the following,

[11:55]

<swoag>

cooler-core:

[11:55]

<swoag>

hw specific/platform code

<swoag>

generic system code (like the settings example)

<swoag>

cooler-gui:

<swoag>

cooler-media:

<swoag>

nms client and shared code

<swoag>

cooler-extra:

<swoag>

other?

<crweb>

sounds good to me

<crweb>

one question though

Sounds good here too

<crweb>

what exactly is hw specific code?

<swoag>

is video signal present?

<crweb>

swoag: i'm curious because, if we are going to use cooler on other hardware eventually in the future

<swoag>

turn on/off LED

<crweb>

it would probably be nice to have the hw specific stuff in something hw specific

<swoag>

good point.

<crweb>

that way the libs are across all hardware

<swoag>

cooler-hw?

<crweb>

or abstraction plugins?

so where does the IR go in this scheme... cooler-hw?

<crweb>

yes, actually both

<crweb>

swoag: cooler-hw, and have cooler-hw an abstraction

<swoag>

IR support goes to cooler-hw.

* nerochiaro just got back, is catching up

<crweb>

swoag: that way cooler-hw we can just use the same api, but have cooler-hw use plugins for different hardware

<swoag>

and yes it should be an HAL.

<crweb>

yeah, that would be excellent

cooler-media,cooler-hw,cooler-gui,cooler-core and cooler-extra

thats it right?

<crweb>

should we name it hw?

<crweb>

why not cooler-hal

ok

<swoag>

agreed.

cooler-media,cooler-hal,cooler-gui,cooler-core and cooler-extra

<crweb>

sounds good to me

<crweb>

most excellent

<swoag>

ok with me.

by the way, if you want to hide all the libs from an app that doesn't care you can have a shell lib 'cooler' that links to the others.

<crweb>

going to help with newbie devs too

<swoag>

sorry, I've got about 15 minutes left...