#1438: Make qOrbiter Play Media - Scope request

[stedaniels]

Hello golgoj4,

I'm sorry for causing this outburst:

#1438: Make qOrbiter Play Media
-----------------------------+----------------------
 Reporter:  golgoj4          |       Owner:  golgoj4
    Type:  feature_request  |      Status:  new
 Priority:  normal           |   Milestone:  1004
Component:  qOrbiter         |     Version:  1004
 Severity:  normal           |  Resolution:
 Keywords:                   |
-----------------------------+----------------------

Comment (by golgoj4):

 No, and stop asking. Tickets are not for annoying people to bug me.
 Tickets are for actual contributors. So stop wasting dev time making me
 think you were going to contribute anything usefull. Seriously.

 -tha management

I'm just used to collaborating with colleagues on projects by using comments on JIRA issues when something isn't clear for me or linked to design docs on the wiki.

That said, it was a genuine request for the scope of ticket. Having just finished rewiring my house with structured mains and low voltage wiring, my LinuxMCE installation and development time has opened up.

It's hard to know quite where to invest time hence why I asked about something that excited me, especially when it's being developed on a platform that I'm experienced with (Android and C++).

Soo.. is media playback merely to support previews or some halfway house between an Orbiter and an Android MD?

Thanks for your time,

Steve

[golgoj4]

1st off, my response wasnt very professional and ill be the 2nd (after possy) to point it out.

2nd, since obviously you weren't being inconsiderate so much as trying to get the actual scope of whats going on, here is the _general_ idea.

*every target for qOrbiter should have the ability to have media targeted to it, and to push media to the dcerouter.

Currently, im trying to decide between using the native multimedia capabilities on Android, or to try and roll in the Qt Mobility suite. Currently we arent natively compling android code so much as cross compiling which has left a little to be desired to get to some of the internals of android devices. Before I left for Boston, I got the qMediaPlayer device and plugin templates created, and the code merged on the qOrbiter side into its existing codebase. So right now im at the implementation stage of the media streaming / playing but have not really dug into it much yet as im doing training for Qt this week.

If you stop by irc, i can be more specific with the requirements to start playing with the media streams, though my personal plan is to get it working on linux 1st, then move to other platforms once i understand the in's and outs.

Once again sorry, nobody deserves to be yelled at for asking a reasonble answer to a question.

-the sometimes moody golgoj4

[l3mce]

I have a tendency to dump on people who do not understand scope when they are asking for it.

golgoj4 is a much nicer person than I am, which is why I made this post. http://forum.linuxmce.org/index.php/topic,12514.0.html

I want to yell at people for not helping, but asking "when it will be done" or "why it isn't working today" or "why it doesn't do X yet".


I wish only to say that when you devote 20 hrs a day to a project, and people seem to be "bitching" that what they want isn't working, your first instinct is to say... less than pleasant things. When you read a ticket hoping for some HELP, only to find what, on the surface, APPEARS to be yet ANOTHER complaint that some users ENTITLED feature does not work as desired... it is disheartening.

Yours was not such a ticket, but probably should not have been a ticket, instead a post. NOT that you did anything wrong... you are just dealing with sailors used to sharks. I know we all appreciate your interest in the project, and look forward to any contribution you can make to the project. It is a handful of people DOING on a particularly intricate clockwork, with many many gears. It is a complicated beast. Any relief is welcome.

[Marie.O]

Nobody should fear getting dump for asking. We are all learning.

[stedaniels]

Hi guys,

Thanks for the feedback so far. Sorry again for following the wrong course of action. I've been on golgoj4's side of this a few times in the past so know where he and you guys are coming from.  I just didn't know the protocol - nor did I make my intent clear from my ticket comment which is my fault.

Something we did on an issue tracker that we'd opened up to non technical users was to link to "commenting guidelines" around the comment area of the ticket, and also include a confirmation popup when users outside of a certain user group comment. The former is an easy fix, the latter was thought of as overkill but helped greatly ;-)

Anywho - to the task at hand.

Going Android native whilst easier would likely leave some edge cases untouched and also demand the need for wrappers for each platforms native media frameworks. Qt Mobility definitely seems the way to go, especially since it's multimedia API is compatible with Windows, Linux and Mac - just gotta back sure the right backends are available. I've got to admit, I've not touched Qt since I plated around with Symbian development quite some time ago!

I still don't understand why qOrbiter needs to be able to playback media - above and beyond previews - but I now seem to remember you saying that qOrbiter was destined to replace the Orbiter code on the MD's - which could answer that question for me. (My memory is terrible!)

Hoping to get qOrbiter up and running on some actual devices this weekend for testing!

[tschak909]

keep in mind, fellas... that we ALREADY have media playback on the media directors, the Xine and MPlayer Player, qorbiter simply needs to talk to them appropriately.

golgoj4's work mostly revolves around pushing media playback to android devices that would need to do playback (i.e. smart TV media boxes, or wanting to play back a movie on a tablet, etc.)

-Thom

[golgoj4]

Hi guys,

Thanks for the feedback so far. Sorry again for following the wrong course of action. I've been on golgoj4's side of this a few times in the past so know where he and you guys are coming from.  I just didn't know the protocol - nor did I make my intent clear from my ticket comment which is my fault.

Something we did on an issue tracker that we'd opened up to non technical users was to link to "commenting guidelines" around the comment area of the ticket, and also include a confirmation popup when users outside of a certain user group comment. The former is an easy fix, the latter was thought of as overkill but helped greatly ;-)

Anywho - to the task at hand.

Going Android native whilst easier would likely leave some edge cases untouched and also demand the need for wrappers for each platforms native media frameworks. Qt Mobility definitely seems the way to go, especially since it's multimedia API is compatible with Windows, Linux and Mac - just gotta back sure the right backends are available. I've got to admit, I've not touched Qt since I plated around with Symbian development quite some time ago!

I still don't understand why qOrbiter needs to be able to playback media - above and beyond previews - but I now seem to remember you saying that qOrbiter was destined to replace the Orbiter code on the MD's - which could answer that question for me. (My memory is terrible!)

Hoping to get qOrbiter up and running on some actual devices this weekend for testing!

My original thought was that anything should be a media target. If it can run qOrbiter, then Linuxmce should be able to send media to it to play, and it should be able to bounce its own media back to linuxmce. The first part will be a lot easier than the second part for sure.

I guess my thinking is this. I want to move the music stream to the kitchen while i make lunch. But I dont have a media director setup in there. But there is a desktop machine. So, I should be able to bounce a media stream to the qOrbiter running on that windows xp machine, and then it will use the native playback capabilities there to then start the stream which is still controllable from my android phone.

Hope im not being too confusing? But essentially, anything with a brain, i want to control / use as a media target for linuxmce.

And, damn you liblinphone for being written in c# :p
i gots more learnin' to do!

-golgoj4

I also like the idea about the comment guidelines or something similar for trac.

[david_a_dawson]

Might it not be more appropriate to have a second, media playing device that happens to be bundled with many (/ most) qorbiter installs?

That way you aren't giving qorbiter to much to do, and could have completely seperate implementations for android, desktop etc.

I had fun a wee or so ago prototyping a java based app using libvlc that could do that job (its presenting UPnP Media Renderer and basic DCE interfaces at the mo, and plays any media I have when passed an MRL, which is all of it as its on a UPnP accessible NAS).

Kind of clunky, but it did highlight that a simple media playing device doesn't appear to be that involved compared to the likes of qorbiter, as it just isn't doing a lot in comparison.

Dunno, am I talking crap?

[david_a_dawson]

Oh, I'd be happy to share or contribute that if you think it may be useful.

I'm a java dev, so the language choice came naturally, C++ still isn't really comfortable for me.   

That said, I'm not offended if not, I know this is C++ project.. 

:-)

[golgoj4]

I just happened to learn c++ first. Any and all code is welcome. I think the only guidelines are
*dce awareness
*acts like a proper linuxmce device

beyond that, i dont think anyone cares what language its in.

-golgoj4

[david_a_dawson]

Good good.
I'll clean it up and put it on github when I get a moment, sometime in the next few days.

[david_a_dawson]

Java DCE Implementation.

https://github.com/dawsonsystems/JavaDCE

Functional (and suprisingly slim!), but very hardcoded on event/ command ids.  Not something I want to keep and as soon as I can, I'll break that to make the lib agnostic to the ids that are present in the current system

This is inspired by a bit of code that someone at pluto wrote and then documented to an extent.  I forget the exact details, but I rewrote the lot in late 2010/ 2011 before life sent me south for a year.


Simple device that will boot and then sit in the taskbar doing nothing.

https://github.com/dawsonsystems/linuxmceagent

• Presents a UPnP interface to act as a Media Renderer, built using the Cling library
• Presents a DCE interface to play media.
• Uses libvlc (via a snazzy java wrapper) to do fullscreen video playback
• Has a simple java based image viewer for static pictures, so can display those to

The UPnp implementation is full of holes.  The DCE implementation only has one function, to play media.
The device template I'm going for implements the "Media Player Commands" and "Smart Media Player" command groups. Thats the idea anyway.
Currently it only responds to 'Play media' (37) when you pass it a MediaURL.

This is all dreadfully hard coded and semi developed... so please don't think it will work (esp the libvlc compilation, as i did it myself and its not very likely to function anywhere else than ubuntu 64 bit)

Anywho.  for those who are interested, I will continue development on my github account.

[golgoj4]

you sir, are awesome! I will be taking a look at this more in depth when i return from Day 1 of work (woohoo, work! )



-golgoj4

[golgoj4]

you sir, are awesome! I will be taking a look at this more in depth when i return from Day 1 of work (woohoo, work! )



-golgoj4

Also, because I like to make people's lives hard, I have some quick questions if you dont mind.

*How do you view the path of cross compiling qt (necessitas) vs flushing out the JavaDCE?
*Do you envision a method the two apps could talk to each other. Is there some type of interface i would need to provide on the Qt side?

The main thrust of the questions is I like to have a big picture view of things in my head. With desktop variants, i have a fairly defined idea of the involved parts. Android is still something thats in flux from that perspective and im just wondering if its time to start learning some java on my end.

Thanks for all your hard work on this and qOrbiter, its really appreciated.
-golgoj4

[david_a_dawson]

Also, because I like to make people's lives hard, I have some quick questions if you dont mind.

*How do you view the path of cross compiling qt (necessitas) vs flushing out the JavaDCE?
*Do you envision a method the two apps could talk to each other. Is there some type of interface i would need to provide on the Qt side?

The main thrust of the questions is I like to have a big picture view of things in my head. With desktop variants, i have a fairly defined idea of the involved parts. Android is still something thats in flux from that perspective and im just wondering if its time to start learning some java on my end.

Thanks for all your hard work on this and qOrbiter, its really appreciated.
-golgoj4

Howdy.  Congrats on the job!!

Not sure what you mean by flushing out?

As for comms.  dunno really. maybe via DCE?   It might be cool to have that anyway so that qorbiter can be embedded/ controller in a media director.  might be a similar interface.  Not sure I'm getting where you're going .... ;-)

I wrote this to run on desktop ubuntu.  I wasn't really thinking much further along than that, although given the correct dll for libvlc, it'd work on windows too with no modification.
It was me playing at an implementation for the 'desktop agent' that thshak has mentioned that we looked at a while ago.   

Once this is done though, and it media wise it can be controlled via the orbiters, and you add qorbiter into the bundle, it does seem a pretty good addition.

David