Hello golgoj4,
I'm sorry for causing this outburst:
Quote#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
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
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.
Nobody should fear getting dump for asking. We are all learning.
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!
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
Quote from: stedaniels on April 20, 2012, 03:32:55 PM
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.
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?
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..
:-)
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
Good good.
I'll clean it up and put it on github when I get a moment, sometime in the next few days.
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.
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! :D )
-golgoj4
Quote from: golgoj4 on April 24, 2012, 04:17:19 PM
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! :D )
-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
Quote from: golgoj4 on April 24, 2012, 04:24:08 PM
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
Came across this - custom qml component for playing video
http://youtu.be/BLXomTRfpG0
maybe a good starting point.
-Coley.
well the truly annoying part is that im trying to implement the video player using Qt Mobility which would allow me to abstract the player within qOrbiter on different platforms. But Qt Mobility is not being co-operative (including the examples). Otherwise its stupid easy...
more to come soon!
-golgoj4
I think we all want to see media playback on hand-held devices, and I have some ideas regarding this that I thought I'd share.
First, we may have problems with the media formats supported on various devices. Android for instance, does not play flac files (afaik). And when you think about video files, I suspect it will be even more limitations (given the large number of format available).
So we have two options: use the native android media playback system, or implement a layer on top of that to support more formats. I don't know if qt-media uses the native android media system or adds support for more formats on its own, so using that may or may not be an advantage in this regard.
Using the native playback system will probably be more power-efficient than implementing decoding support, as hardware acceleration exists for the first option.
Adding decoding support for the same formats as the "standard" LMCE devices like Xine and Squeezeboxes to android or other devices will probably not be feasible.
Realizing that playing media seamlessly to hand-held devices probably needs transcoding, we are very much approaching what UPnP are attempting to do. Several of the media servera available do some kind of transcoding.
UPnP clients are available for android already, so they could be used for our purpose. What is missing in this picture is a LMCE-UPnP bridge.
During my work with the LMCE-Coherence media backend (which is still not released), I played around with the idea that we could create a bridge that exposed UPnP devices to LMCE and allow them to be added as a media player device in LMCE. I did not do any experiments regarding this, but I didn't find any show stoppers either.
Using this approach will enable us to use existing frameworks (UPnP clients/renderer on the device, UPnP media server - coherence), and also give us other benefits as well (possible to add other playback devices supporting UPnP).
I'm not saying what we should do, but simply stating that there are alternative ways to creating a new media player for Android. Maybe we end up doing both, just to see which approach works best. I will probably do the UPnP stuff anyway at some point, to support playing on UPnP clients.
This post is long enough already, but I can elaborate on the idea if anyone wants to listen.
br,
sambuca
Quote from: sambuca on April 25, 2012, 10:46:10 AM
I think we all want to see media playback on hand-held devices, and I have some ideas regarding this that I thought I'd share.
First, we may have problems with the media formats supported on various devices. Android for instance, does not play flac files (afaik). And when you think about video files, I suspect it will be even more limitations (given the large number of format available).
So we have two options: use the native android media playback system, or implement a layer on top of that to support more formats. I don't know if qt-media uses the native android media system or adds support for more formats on its own, so using that may or may not be an advantage in this regard.
Using the native playback system will probably be more power-efficient than implementing decoding support, as hardware acceleration exists for the first option.
Adding decoding support for the same formats as the "standard" LMCE devices like Xine and Squeezeboxes to android or other devices will probably not be feasible.
Realizing that playing media seamlessly to hand-held devices probably needs transcoding, we are very much approaching what UPnP are attempting to do. Several of the media servera available do some kind of transcoding.
UPnP clients are available for android already, so they could be used for our purpose. What is missing in this picture is a LMCE-UPnP bridge.
During my work with the LMCE-Coherence media backend (which is still not released), I played around with the idea that we could create a bridge that exposed UPnP devices to LMCE and allow them to be added as a media player device in LMCE. I did not do any experiments regarding this, but I didn't find any show stoppers either.
Using this approach will enable us to use existing frameworks (UPnP clients/renderer on the device, UPnP media server - coherence), and also give us other benefits as well (possible to add other playback devices supporting UPnP).
I'm not saying what we should do, but simply stating that there are alternative ways to creating a new media player for Android. Maybe we end up doing both, just to see which approach works best. I will probably do the UPnP stuff anyway at some point, to support playing on UPnP clients.
This post is long enough already, but I can elaborate on the idea if anyone wants to listen.
br,
sambuca
sambuca,
im always happy to listen. And I dont think we've really flushed out the 'best' way to do this as the methods / ideas everyone has brought up so far require serious consideration and thought.
Some things ive noticed so far on the Qt side
*Phonon, the multimedia playback system that is part of qt uses the native playback capabilities of the device / machine.
*This will change radically with Qt5 from my understanding
As an aside, im currently writing a qml plugin for video using the phonon system. got basic audio playback working, but once i finish i want to look hard at abstracting it so that we can more easily drop in replacement players.
also, im late now so ill continue with my thoughts later!
-golgoj4